* Re: [PATCH v10 1/3] dt-bindings: Add keypad devicetree documentation
From: Marco Felsch @ 2020-05-28 9:24 UTC (permalink / raw)
To: Fengping Yu
Cc: Dmitry Torokhov, linux-mediatek, linux-input, Yingjoe Chen,
Andy Shevchenko, linux-arm-kernel
In-Reply-To: <20200528084143.36482-2-fengping.yu@mediatek.com>
On 20-05-28 16:41, Fengping Yu wrote:
> From: "fengping.yu" <fengping.yu@mediatek.com>
...
> + mediatek,debounce-us:
> + description: Debounce interval in microseconds
> + maximum: 256000
Nit, I would mention that 16000 is the default value which is applied if
not given.
Appart of this feel free to add my:
Reviewed-by: Marco Felsch <m.felsch@pengutronix.de>
Regards,
Marco
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH] ARM: omap2: drop broken broadcast timer hack
From: Arnd Bergmann @ 2020-05-28 9:19 UTC (permalink / raw)
To: arm, Tony Lindgren
Cc: Rob Herring, Grygorii Strashko, Geert Uytterhoeven, Arnd Bergmann,
Lokesh Vutla, Keerthy, Santosh Shilimkar, linux-kernel,
Tero Kristo, Olof Johansson, linux-omap, afzal mohammed,
linux-arm-kernel
The OMAP4 timer code had a special hack for using the broadcast timer
without SMP. Since the dmtimer is now gone, this also needs to be dropped
to avoid a link failure for non-SMP AM43xx configurations:
kernel/time/tick-broadcast.o: in function `tick_device_uses_broadcast':
tick-broadcast.c:(.text+0x130): undefined reference to `tick_broadcast'
Fixes: 2ee04b88547a ("ARM: OMAP2+: Drop old timer code for dmtimer and 32k counter")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
arch/arm/mach-omap2/Kconfig | 1 -
arch/arm/mach-omap2/timer.c | 6 ------
2 files changed, 7 deletions(-)
diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index ca74473f01df..ec4450a5c296 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -67,7 +67,6 @@ config SOC_AM43XX
select ARM_GIC
select MACH_OMAP_GENERIC
select HAVE_ARM_SCU
- select GENERIC_CLOCKEVENTS_BROADCAST
select HAVE_ARM_TWD
select ARM_ERRATA_754322
select ARM_ERRATA_775420
diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
index 2d4ea386fc38..786336ee27ef 100644
--- a/arch/arm/mach-omap2/timer.c
+++ b/arch/arm/mach-omap2/timer.c
@@ -46,12 +46,6 @@ void set_cntfreq(void)
omap_smc1(OMAP5_DRA7_MON_SET_CNTFRQ_INDEX, arch_timer_freq);
}
-#if !defined(CONFIG_SMP) && defined(CONFIG_GENERIC_CLOCKEVENTS_BROADCAST)
-void tick_broadcast(const struct cpumask *mask)
-{
-}
-#endif
-
#if defined(CONFIG_SOC_OMAP5) || defined(CONFIG_SOC_DRA7XX)
/*
--
2.26.2
_______________________________________________
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 PATCH] iommu/arm-smmu: Add module parameter to set msi iova address
From: Shameerali Kolothum Thodi @ 2020-05-28 9:15 UTC (permalink / raw)
To: Auger Eric, Jean-Philippe Brucker
Cc: Robin Murphy, Joerg Roedel, iommu@lists.linux-foundation.org,
Linux Kernel Mailing List, Alex Williamson, Srinath Mannam,
BCM Kernel Feedback, Will Deacon, Linux ARM
In-Reply-To: <0076d965-b180-fc44-103c-9bc9d73fe7f2@redhat.com>
> -----Original Message-----
> From: Auger Eric [mailto:eric.auger@redhat.com]
> Sent: 28 May 2020 09:54
> To: Jean-Philippe Brucker <jean-philippe@linaro.org>
> Cc: Will Deacon <will@kernel.org>; Joerg Roedel <joro@8bytes.org>;
> iommu@lists.linux-foundation.org; Shameerali Kolothum Thodi
> <shameerali.kolothum.thodi@huawei.com>; Linux Kernel Mailing List
> <linux-kernel@vger.kernel.org>; Alex Williamson
> <alex.williamson@redhat.com>; Srinath Mannam
> <srinath.mannam@broadcom.com>; BCM Kernel Feedback
> <bcm-kernel-feedback-list@broadcom.com>; Robin Murphy
> <robin.murphy@arm.com>; Linux ARM <linux-arm-kernel@lists.infradead.org>
> Subject: Re: [RFC PATCH] iommu/arm-smmu: Add module parameter to set msi
> iova address
>
> Hi,
>
> On 5/28/20 10:38 AM, Jean-Philippe Brucker wrote:
> > [+ Shameer]
> >
> > On Thu, May 28, 2020 at 09:43:46AM +0200, Auger Eric wrote:
> >> Hi,
> >>
> >> On 5/28/20 9:23 AM, Jean-Philippe Brucker wrote:
> >>> On Thu, May 28, 2020 at 10:45:14AM +0530, Srinath Mannam wrote:
> >>>> On Wed, May 27, 2020 at 11:00 PM Robin Murphy
> <robin.murphy@arm.com> wrote:
> >>>>>
> >>>> Thanks Robin for your quick response.
> >>>>> On 2020-05-27 17:03, Srinath Mannam wrote:
> >>>>>> This patch gives the provision to change default value of MSI IOVA base
> >>>>>> to platform's suitable IOVA using module parameter. The present
> >>>>>> hardcoded MSI IOVA base may not be the accessible IOVA ranges of
> platform.
> >>>>>
> >>>>> That in itself doesn't seem entirely unreasonable; IIRC the current
> >>>>> address is just an arbitrary choice to fit nicely into Qemu's memory
> >>>>> map, and there was always the possibility that it wouldn't suit
> everything.
> >>>>>
> >>>>>> Since commit aadad097cd46 ("iommu/dma: Reserve IOVA for PCIe
> inaccessible
> >>>>>> DMA address"), inaccessible IOVA address ranges parsed from
> dma-ranges
> >>>>>> property are reserved.
> >>>
> >>> I don't understand why we only reserve the PCIe windows for DMA
> domains.
> >>> Shouldn't VFIO also prevent userspace from mapping them?
> >>
> >> VFIO prevents userspace from DMA mapping iovas within reserved regions:
> >> 9b77e5c79840 vfio/type1: check dma map request is within a valid iova
> range
> >
> > Right but I was asking specifically about the IOVA reservation introduced
> > by commit aadad097cd46. They are not registered as reserved regions within
> > the IOMMU core, they are only taken into account by dma-iommu.c when
> > creating a DMA domain. As VFIO uses UNMANAGED domains, it isn't aware
> of
> > those regions and they won't be seen by vfio_iommu_resv_exclude().
> >
> > It looks like the PCIe regions used to be common until cd2c9fcf5c66
> > ("iommu/dma: Move PCI window region reservation back into dma specific
> > path.") But I couldn't find the justification for this commit.
>
> Yes I noticed that as well when debugging the above mentioned case
> before and after cd2c9fcf5c66. I do not remember about the rationale of
> removing the DMA host brige windows from the resv regions. Did it break
> a legacy case?
> >
I think yes. And going through the ML discussions, this was done so because with the
" vfio/type1: Add support for valid iova list management" series you reported
an issue with Seattle platform. See the full discussion here,
https://lore.kernel.org/patchwork/patch/889012/
Cheers,
Shameer
> > The thing is, if VFIO isn't aware of the reserved PCIe windows, then
> > allowing VFIO or userspace to choose MSI_IOVA_BASE won't solve the
> problem
> > reported by Srinath, because they could well choose an IOVA within the
> > PCIe window...
> I agree with you
>
> Thanks
>
> Eric
> >
> > Thanks,
> > Jean
> >
> >> but it does not prevent the SW MSI region chosen by the kernel from
> >> colliding with other reserved regions (esp. PCIe host bridge windows).
> >>
> >> If they were
> >>> part of the common reserved regions then we could have VFIO choose a
> >>> SW_MSI region among the remaining free space.
> >> As Robin said this was the initial chosen approach
> >> [PATCH 10/10] vfio: allow the user to register reserved iova range for
> >> MSI mapping
> >> https://patchwork.kernel.org/patch/8121641/
> >>
> >> Some additional background about why the static SW MSI region chosen by
> >> the kernel was later chosen:
> >> Summary of LPC guest MSI discussion in Santa Fe (was: Re: [RFC 0/8] KVM
> >> PCIe/MSI passthrough on ARM/ARM64 (Alt II))
> >>
> https://lists.linuxfoundation.org/pipermail/iommu/2016-November/019060.ht
> ml
> >>
> >> Thanks
> >>
> >> Eric
> >>
> >>
> >> It would just need a
> >>> different way of asking the IOMMU driver if a SW_MSI is needed, for
> >>> example with a domain attribute.
> >>>
> >>> Thanks,
> >>> Jean
> >>>
> >>>>>
> >>>>> That, however, doesn't seem to fit here; iommu-dma maps MSI
> doorbells
> >>>>> dynamically, so they aren't affected by reserved regions any more than
> >>>>> regular DMA pages are. In fact, it explicitly ignores the software MSI
> >>>>> region, since as the comment says, it *is* the software that manages
> those.
> >>>> Yes you are right, we don't see any issues with kernel drivers(PCI EP)
> because
> >>>> MSI IOVA allocated dynamically by honouring reserved regions same as
> DMA pages.
> >>>>>
> >>>>> The MSI_IOVA_BASE region exists for VFIO, precisely because in that
> case
> >>>>> the kernel *doesn't* control the address space, but still needs some way
> >>>>> to steal a bit of it for MSIs that the guest doesn't necessarily know
> >>>>> about, and give userspace a fighting chance of knowing what it's taken.
> >>>>> I think at the time we discussed the idea of adding something to the
> >>>>> VFIO uapi such that userspace could move this around if it wanted or
> >>>>> needed to, but decided we could live without that initially. Perhaps now
> >>>>> the time has come?
> >>>> Yes, we see issues only with user-space drivers(DPDK) in which
> MSI_IOVA_BASE
> >>>> region is considered to map MSI registers. This patch helps us to fix the
> issue.
> >>>>
> >>>> Thanks,
> >>>> Srinath.
> >>>>>
> >>>>> Robin.
> >>>>>
> >>>>>> If any platform has the limitaion to access default MSI IOVA, then it can
> >>>>>> be changed using "arm-smmu.msi_iova_base=0xa0000000" command
> line argument.
> >>>>>>
> >>>>>> Signed-off-by: Srinath Mannam <srinath.mannam@broadcom.com>
> >>>>>> ---
> >>>>>> drivers/iommu/arm-smmu.c | 5 ++++-
> >>>>>> 1 file changed, 4 insertions(+), 1 deletion(-)
> >>>>>>
> >>>>>> diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
> >>>>>> index 4f1a350..5e59c9d 100644
> >>>>>> --- a/drivers/iommu/arm-smmu.c
> >>>>>> +++ b/drivers/iommu/arm-smmu.c
> >>>>>> @@ -72,6 +72,9 @@ static bool disable_bypass =
> >>>>>> module_param(disable_bypass, bool, S_IRUGO);
> >>>>>> MODULE_PARM_DESC(disable_bypass,
> >>>>>> "Disable bypass streams such that incoming transactions from
> devices that are not attached to an iommu domain will report an abort back to
> the device and will not be allowed to pass through the SMMU.");
> >>>>>> +static unsigned long msi_iova_base = MSI_IOVA_BASE;
> >>>>>> +module_param(msi_iova_base, ulong, S_IRUGO);
> >>>>>> +MODULE_PARM_DESC(msi_iova_base, "msi iova base address.");
> >>>>>>
> >>>>>> struct arm_smmu_s2cr {
> >>>>>> struct iommu_group *group;
> >>>>>> @@ -1566,7 +1569,7 @@ static void
> arm_smmu_get_resv_regions(struct device *dev,
> >>>>>> struct iommu_resv_region *region;
> >>>>>> int prot = IOMMU_WRITE | IOMMU_NOEXEC |
> IOMMU_MMIO;
> >>>>>>
> >>>>>> - region = iommu_alloc_resv_region(MSI_IOVA_BASE,
> MSI_IOVA_LENGTH,
> >>>>>> + region = iommu_alloc_resv_region(msi_iova_base,
> MSI_IOVA_LENGTH,
> >>>>>> prot,
> IOMMU_RESV_SW_MSI);
> >>>>>> if (!region)
> >>>>>> return;
> >>>>>>
> >>>
> >>> _______________________________________________
> >>> linux-arm-kernel mailing list
> >>> linux-arm-kernel@lists.infradead.org
> >>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> >>>
> >>
> >
> > _______________________________________________
> > linux-arm-kernel mailing list
> > linux-arm-kernel@lists.infradead.org
> > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> >
_______________________________________________
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 11/26] arm64: mte: Add PROT_MTE support to mmap() and mprotect()
From: Catalin Marinas @ 2020-05-28 9:14 UTC (permalink / raw)
To: Peter Collingbourne
Cc: linux-arch, Szabolcs Nagy, Andrey Konovalov, Kevin Brodsky,
linux-mm, Evgenii Stepanov, Vincenzo Frascino, Will Deacon,
Dave P Martin, Linux ARM
In-Reply-To: <CAMn1gO5ApcHOgQ_oLjiGDdCx9znz7N50w-BbzGPYpAzPQC3OQQ@mail.gmail.com>
On Wed, May 27, 2020 at 11:57:39AM -0700, Peter Collingbourne wrote:
> On Fri, May 15, 2020 at 10:16 AM Catalin Marinas
> <catalin.marinas@arm.com> wrote:
> > To enable tagging on a memory range, the user must explicitly opt in via
> > a new PROT_MTE flag passed to mmap() or mprotect(). Since this is a new
> > memory type in the AttrIndx field of a pte, simplify the or'ing of these
> > bits over the protection_map[] attributes by making MT_NORMAL index 0.
>
> Should the userspace stack always be mapped as if with PROT_MTE if the
> hardware supports it? Such a change would be invisible to non-MTE
> aware userspace since it would already need to opt in to tag checking
> via prctl. This would let userspace avoid a complex stack
> initialization sequence when running with stack tagging enabled on the
> main thread.
I don't think the stack initialisation is that difficult. On program
startup (can be the dynamic loader). Something like (untested):
register unsigned long stack asm ("sp");
unsigned long page_sz = sysconf(_SC_PAGESIZE);
mprotect((void *)(stack & ~(page_sz - 1)), page_sz,
PROT_READ | PROT_WRITE | PROT_MTE | PROT_GROWSDOWN);
(the essential part it PROT_GROWSDOWN so that you don't have to specify
a stack lower limit)
I don't like enabling this by default since it will have a small cost
even if the application doesn't enable tag checking. The kernel would
still have to zero the tags when mapping the stack and preserve them
when swapping out.
Another case where this could go wrong is if we want enable some
quiet monitoring of user programs: the libc enables PROT_MTE on heap
allocations but keeps tag checking disabled as it doesn't want any
SIGSEGV; the kernel could enable async TCF and log any faults
(rate-limited). Default PROT_MTE stack would get in the way. Anyway,
this use-case is something for the future, so far these patches rely on
the user solely driving the tag checking mode.
I'm fine, however, with enabling PROT_MTE on the main stack based on
some ELF note.
--
Catalin
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [RESEND PATCH v11 3/3] configs: defconfig: Add CONFIG_KEYBOARD_MTK_KPD=m
From: Fengping Yu @ 2020-05-28 9:01 UTC (permalink / raw)
To: Yingjoe Chen, Dmitry Torokhov, Andy Shevchenko, Marco Felsch
Cc: fengping.yu, linux-mediatek, linux-arm-kernel, linux-input
In-Reply-To: <20200528090144.54033-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
* [RESEND PATCH v11] Add matrix keypad driver support for Mediatek SoCs
From: Fengping Yu @ 2020-05-28 9:01 UTC (permalink / raw)
To: Yingjoe Chen, Dmitry Torokhov, Andy Shevchenko, Marco Felsch
Cc: linux-mediatek, linux-arm-kernel, linux-input
Change since v10:
- add wakeup source setting in probe function
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 | 95 ++++++++
arch/arm64/configs/defconfig | 1 +
drivers/input/keyboard/Kconfig | 11 +
drivers/input/keyboard/Makefile | 1 +
drivers/input/keyboard/mtk-kpd.c | 206 ++++++++++++++++++
5 files changed, 314 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
* [RESEND PATCH v11] Add matrix keypad driver support for Mediatek SoCs
From: Fengping Yu @ 2020-05-28 9:07 UTC (permalink / raw)
To: Yingjoe Chen, Dmitry Torokhov, Andy Shevchenko, Marco Felsch
Cc: linux-mediatek, linux-arm-kernel, linux-input
Change since v10:
- add wakeup source setting in probe function
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 | 95 ++++++++
arch/arm64/configs/defconfig | 1 +
drivers/input/keyboard/Kconfig | 11 +
drivers/input/keyboard/Makefile | 1 +
drivers/input/keyboard/mtk-kpd.c | 206 ++++++++++++++++++
5 files changed, 314 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] clk: versatile: undo some dependency changes
From: Arnd Bergmann @ 2020-05-28 9:08 UTC (permalink / raw)
To: Stephen Boyd
Cc: Rob Herring, Linus Walleij, linux-kernel@vger.kernel.org,
Michael Turquette, Sudeep Holla, linux-clk, Linux ARM
In-Reply-To: <159062606969.69627.15005677857751012104@swboyd.mtv.corp.google.com>
On Thu, May 28, 2020 at 2:34 AM Stephen Boyd <sboyd@kernel.org> wrote:
>
> Quoting Arnd Bergmann (2020-05-27 06:40:33)
> > SP810 and ICST are selected by a couple of platforms, most but
> > not all in the versatile family:
> >
> > WARNING: unmet direct dependencies detected for CLK_SP810
> > Depends on [n]: COMMON_CLK [=y] && COMMON_CLK_VERSATILE [=n]
> > Selected by [y]:
> > - ARCH_REALVIEW [=y] && (ARCH_MULTI_V5 [=n] || ARCH_MULTI_V6 [=n] ||
> > ARCH_MULTI_V7 [=y])
> >
> > WARNING: unmet direct dependencies detected for ICST
> > Depends on [n]: COMMON_CLK [=y] && COMMON_CLK_VERSATILE [=n]
> > Selected by [y]:
> > - ARCH_REALVIEW [=y] && (ARCH_MULTI_V5 [=n] || ARCH_MULTI_V6 [=n] || ARCH_MULTI_V7 [=y])
> > - ARCH_VEXPRESS [=y] && ARCH_MULTI_V7 [=y]
> > - ARCH_ZYNQ [=y] && ARCH_MULTI_V7 [=y]
> >
> > Change back the Kconfig logic to allow these to be selected
> > without the main option.
> >
> > Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> > ---
>
> Is this similar to
> https://lore.kernel.org/r/20200527181307.2482167-1-robh@kernel.org
> ?
It's similar, but that version still breaks ZYNQ when CONFIG_COMPILE_TEST
is disabled.
Arnd
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [RESEND PATCH v11 2/3] drivers: input: keyboard: Add mtk keypad driver
From: Fengping Yu @ 2020-05-28 9:01 UTC (permalink / raw)
To: Yingjoe Chen, Dmitry Torokhov, Andy Shevchenko, Marco Felsch
Cc: fengping.yu, linux-mediatek, linux-arm-kernel, linux-input
In-Reply-To: <20200528090144.54033-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 | 206 +++++++++++++++++++++++++++++++
3 files changed, 218 insertions(+)
create mode 100644 drivers/input/keyboard/mtk-kpd.c
diff --git a/drivers/input/keyboard/Kconfig b/drivers/input/keyboard/Kconfig
index 28de965a08d5..c55230c4c344 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 || 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..2900487c8f60
--- /dev/null
+++ b/drivers/input/keyboard/mtk-kpd.c
@@ -0,0 +1,206 @@
+// 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/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;
+ 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;
+ unsigned int irq;
+ u32 debounce;
+ bool wakeup;
+ 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;
+ }
+
+ 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, MTK_KPD_DEBOUNCE,
+ debounce * 32 / 1000 & MTK_KPD_DEBOUNCE_MASK);
+
+ keypad->clk = devm_clk_get(&pdev->dev, "kpd");
+ if (IS_ERR(keypad->clk))
+ return keypad->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;
+
+ irq = platform_get_irq(pdev, 0);
+ if (irq < 0)
+ return irq;
+
+ ret = devm_request_threaded_irq(&pdev->dev, irq,
+ NULL, kpd_irq_handler, 0,
+ MTK_KPD_NAME, keypad);
+ if (ret) {
+ dev_err(&pdev->dev, "Failed to request IRQ#%d:%d\n",
+ irq, 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, wakeup);
+}
+
+static const struct of_device_id kpd_of_match[] = {
+ { .compatible = "mediatek,mt6779-keypad" },
+ { .compatible = "mediatek,mt6873-keypad" },
+ { /* 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
* [RESEND PATCH v11 1/3] dt-bindings: Add keypad devicetree documentation
From: Fengping Yu @ 2020-05-28 9:01 UTC (permalink / raw)
To: Yingjoe Chen, Dmitry Torokhov, Andy Shevchenko, Marco Felsch
Cc: fengping.yu, linux-mediatek, linux-arm-kernel, linux-input
In-Reply-To: <20200528090144.54033-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 | 95 +++++++++++++++++++
1 file changed, 95 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..586cd196dd00
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/mtk-kpd.yaml
@@ -0,0 +1,95 @@
+# SPDX-License-Identifier: GPL-2.0
+%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,mt6873-keypad"
+
+ 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,mt6779-keypad";
+ 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 1/3] KVM: arm64: Stop writing aarch32's CSSELR into ACTLR
From: Marc Zyngier @ 2020-05-28 8:57 UTC (permalink / raw)
To: James Morse
Cc: stable, Julien Thierry, kvmarm, linux-arm-kernel,
Suzuki K Poulose
In-Reply-To: <20200526161834.29165-2-james.morse@arm.com>
Hi James,
On 2020-05-26 17:18, James Morse wrote:
> aarch32 has pairs of registers to access the high and low parts of
> 64bit
> registers. KVM has a union of 64bit sys_regs[] and 32bit copro[]. The
> 32bit accessors read the high or low part of the 64bit sys_reg[] value
> through the union.
>
> Both sys_reg_descs[] and cp15_regs[] list access_csselr() as the
> accessor
> for CSSELR{,_EL1}. access_csselr() is only aware of the 64bit
> sys_regs[],
> and expects r->reg to be 'CSSELR_EL1' in the enum, index 2 of the 64bit
> array.
>
> cp15_regs[] uses the 32bit copro[] alias of sys_regs[]. Here CSSELR is
> c0_CSSELR which is the same location in sys_reg[]. r->reg is
> 'c0_CSSELR',
> index 4 in the 32bit array.
>
> access_csselr() uses the 32bit r->reg value to access the 64bit array,
> so reads and write the wrong value. sys_regs[4], is ACTLR_EL1, which
> is subsequently save/restored when we enter the guest.
Huhuh... Nice catch.
>
> ACTLR_EL1 is supposed to be read-only for the guest. This register
> only affects execution at EL1, and the host's value is restored before
> we return to host EL1.
>
> Rename access_csselr() to access_csselr_el1(), to indicate it expects
> the 64bit register index, and pass it CSSELR_EL1 from cp15_regs[].
>
> Cc: stable@vger.kernel.org
> Signed-off-by: James Morse <james.morse@arm.com>
> ----
> Providing access_csselr_cp15() wouldn't work as with VHE CSSELR_EL1 is
> loaded on the CPU while this code runs. access_csselr_cp15() would have
> to map it back the 64bit resgister to use vcpu_write_sys_reg(). We may
> as well do it in the table.
>
> arch/arm64/kvm/sys_regs.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
> index 51db934702b6..2eda539f3281 100644
> --- a/arch/arm64/kvm/sys_regs.c
> +++ b/arch/arm64/kvm/sys_regs.c
> @@ -1302,7 +1302,7 @@ static bool access_clidr(struct kvm_vcpu *vcpu,
> struct sys_reg_params *p,
> return true;
> }
>
> -static bool access_csselr(struct kvm_vcpu *vcpu, struct sys_reg_params
> *p,
> +static bool access_csselr_el1(struct kvm_vcpu *vcpu, struct
> sys_reg_params *p,
> const struct sys_reg_desc *r)
> {
> if (p->is_write)
> @@ -1566,7 +1566,7 @@ static const struct sys_reg_desc sys_reg_descs[]
> = {
>
> { SYS_DESC(SYS_CCSIDR_EL1), access_ccsidr },
> { SYS_DESC(SYS_CLIDR_EL1), access_clidr },
> - { SYS_DESC(SYS_CSSELR_EL1), access_csselr, reset_unknown, CSSELR_EL1
> },
> + { SYS_DESC(SYS_CSSELR_EL1), access_csselr_el1, reset_unknown,
> CSSELR_EL1 },
> { SYS_DESC(SYS_CTR_EL0), access_ctr },
>
> { SYS_DESC(SYS_PMCR_EL0), access_pmcr, reset_pmcr, PMCR_EL0 },
> @@ -2060,7 +2060,7 @@ static const struct sys_reg_desc cp15_regs[] = {
>
> { Op1(1), CRn( 0), CRm( 0), Op2(0), access_ccsidr },
> { Op1(1), CRn( 0), CRm( 0), Op2(1), access_clidr },
> - { Op1(2), CRn( 0), CRm( 0), Op2(0), access_csselr, NULL, c0_CSSELR },
> + { Op1(2), CRn( 0), CRm( 0), Op2(0), access_csselr_el1, NULL,
> CSSELR_EL1 },
> };
>
> static const struct sys_reg_desc cp15_64_regs[] = {
This is a departure from the way we deal with 32bit CP15 registers.
We deal with this exact issue in a very different way for other
CP15 regs, by adjusting the index in the sys_regs array (see the
way we handle the VM regs).
How about something like this (untested):
diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
index 12d07e7ced82..515c0c11a668 100644
--- a/arch/arm64/kvm/sys_regs.c
+++ b/arch/arm64/kvm/sys_regs.c
@@ -1321,10 +1321,16 @@ static bool access_clidr(struct kvm_vcpu *vcpu,
struct sys_reg_params *p,
static bool access_csselr(struct kvm_vcpu *vcpu, struct sys_reg_params
*p,
const struct sys_reg_desc *r)
{
+ int reg = r->reg;
+
+ /* See the 32bit mapping in kvm_host.h */
+ if (p->is_aarch32)
+ reg = r->reg / 2;
+
if (p->is_write)
- vcpu_write_sys_reg(vcpu, p->regval, r->reg);
+ vcpu_write_sys_reg(vcpu, p->regval, reg);
else
- p->regval = vcpu_read_sys_reg(vcpu, r->reg);
+ p->regval = vcpu_read_sys_reg(vcpu, reg);
return true;
}
Ideally, I'd like the core sys_reg code to deal with this sort
of funnies, but I'm trying to keep the change minimal...
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 related
* Re: [RFC PATCH] iommu/arm-smmu: Add module parameter to set msi iova address
From: Auger Eric @ 2020-05-28 8:53 UTC (permalink / raw)
To: Jean-Philippe Brucker
Cc: Robin Murphy, Joerg Roedel, iommu, shameerali.kolothum.thodi,
Linux Kernel Mailing List, Alex Williamson, Srinath Mannam,
BCM Kernel Feedback, Will Deacon, Linux ARM
In-Reply-To: <20200528083851.GB414784@myrica>
Hi,
On 5/28/20 10:38 AM, Jean-Philippe Brucker wrote:
> [+ Shameer]
>
> On Thu, May 28, 2020 at 09:43:46AM +0200, Auger Eric wrote:
>> Hi,
>>
>> On 5/28/20 9:23 AM, Jean-Philippe Brucker wrote:
>>> On Thu, May 28, 2020 at 10:45:14AM +0530, Srinath Mannam wrote:
>>>> On Wed, May 27, 2020 at 11:00 PM Robin Murphy <robin.murphy@arm.com> wrote:
>>>>>
>>>> Thanks Robin for your quick response.
>>>>> On 2020-05-27 17:03, Srinath Mannam wrote:
>>>>>> This patch gives the provision to change default value of MSI IOVA base
>>>>>> to platform's suitable IOVA using module parameter. The present
>>>>>> hardcoded MSI IOVA base may not be the accessible IOVA ranges of platform.
>>>>>
>>>>> That in itself doesn't seem entirely unreasonable; IIRC the current
>>>>> address is just an arbitrary choice to fit nicely into Qemu's memory
>>>>> map, and there was always the possibility that it wouldn't suit everything.
>>>>>
>>>>>> Since commit aadad097cd46 ("iommu/dma: Reserve IOVA for PCIe inaccessible
>>>>>> DMA address"), inaccessible IOVA address ranges parsed from dma-ranges
>>>>>> property are reserved.
>>>
>>> I don't understand why we only reserve the PCIe windows for DMA domains.
>>> Shouldn't VFIO also prevent userspace from mapping them?
>>
>> VFIO prevents userspace from DMA mapping iovas within reserved regions:
>> 9b77e5c79840 vfio/type1: check dma map request is within a valid iova range
>
> Right but I was asking specifically about the IOVA reservation introduced
> by commit aadad097cd46. They are not registered as reserved regions within
> the IOMMU core, they are only taken into account by dma-iommu.c when
> creating a DMA domain. As VFIO uses UNMANAGED domains, it isn't aware of
> those regions and they won't be seen by vfio_iommu_resv_exclude().
>
> It looks like the PCIe regions used to be common until cd2c9fcf5c66
> ("iommu/dma: Move PCI window region reservation back into dma specific
> path.") But I couldn't find the justification for this commit.
Yes I noticed that as well when debugging the above mentioned case
before and after cd2c9fcf5c66. I do not remember about the rationale of
removing the DMA host brige windows from the resv regions. Did it break
a legacy case?
>
> The thing is, if VFIO isn't aware of the reserved PCIe windows, then
> allowing VFIO or userspace to choose MSI_IOVA_BASE won't solve the problem
> reported by Srinath, because they could well choose an IOVA within the
> PCIe window...
I agree with you
Thanks
Eric
>
> Thanks,
> Jean
>
>> but it does not prevent the SW MSI region chosen by the kernel from
>> colliding with other reserved regions (esp. PCIe host bridge windows).
>>
>> If they were
>>> part of the common reserved regions then we could have VFIO choose a
>>> SW_MSI region among the remaining free space.
>> As Robin said this was the initial chosen approach
>> [PATCH 10/10] vfio: allow the user to register reserved iova range for
>> MSI mapping
>> https://patchwork.kernel.org/patch/8121641/
>>
>> Some additional background about why the static SW MSI region chosen by
>> the kernel was later chosen:
>> Summary of LPC guest MSI discussion in Santa Fe (was: Re: [RFC 0/8] KVM
>> PCIe/MSI passthrough on ARM/ARM64 (Alt II))
>> https://lists.linuxfoundation.org/pipermail/iommu/2016-November/019060.html
>>
>> Thanks
>>
>> Eric
>>
>>
>> It would just need a
>>> different way of asking the IOMMU driver if a SW_MSI is needed, for
>>> example with a domain attribute.
>>>
>>> Thanks,
>>> Jean
>>>
>>>>>
>>>>> That, however, doesn't seem to fit here; iommu-dma maps MSI doorbells
>>>>> dynamically, so they aren't affected by reserved regions any more than
>>>>> regular DMA pages are. In fact, it explicitly ignores the software MSI
>>>>> region, since as the comment says, it *is* the software that manages those.
>>>> Yes you are right, we don't see any issues with kernel drivers(PCI EP) because
>>>> MSI IOVA allocated dynamically by honouring reserved regions same as DMA pages.
>>>>>
>>>>> The MSI_IOVA_BASE region exists for VFIO, precisely because in that case
>>>>> the kernel *doesn't* control the address space, but still needs some way
>>>>> to steal a bit of it for MSIs that the guest doesn't necessarily know
>>>>> about, and give userspace a fighting chance of knowing what it's taken.
>>>>> I think at the time we discussed the idea of adding something to the
>>>>> VFIO uapi such that userspace could move this around if it wanted or
>>>>> needed to, but decided we could live without that initially. Perhaps now
>>>>> the time has come?
>>>> Yes, we see issues only with user-space drivers(DPDK) in which MSI_IOVA_BASE
>>>> region is considered to map MSI registers. This patch helps us to fix the issue.
>>>>
>>>> Thanks,
>>>> Srinath.
>>>>>
>>>>> Robin.
>>>>>
>>>>>> If any platform has the limitaion to access default MSI IOVA, then it can
>>>>>> be changed using "arm-smmu.msi_iova_base=0xa0000000" command line argument.
>>>>>>
>>>>>> Signed-off-by: Srinath Mannam <srinath.mannam@broadcom.com>
>>>>>> ---
>>>>>> drivers/iommu/arm-smmu.c | 5 ++++-
>>>>>> 1 file changed, 4 insertions(+), 1 deletion(-)
>>>>>>
>>>>>> diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
>>>>>> index 4f1a350..5e59c9d 100644
>>>>>> --- a/drivers/iommu/arm-smmu.c
>>>>>> +++ b/drivers/iommu/arm-smmu.c
>>>>>> @@ -72,6 +72,9 @@ static bool disable_bypass =
>>>>>> module_param(disable_bypass, bool, S_IRUGO);
>>>>>> MODULE_PARM_DESC(disable_bypass,
>>>>>> "Disable bypass streams such that incoming transactions from devices that are not attached to an iommu domain will report an abort back to the device and will not be allowed to pass through the SMMU.");
>>>>>> +static unsigned long msi_iova_base = MSI_IOVA_BASE;
>>>>>> +module_param(msi_iova_base, ulong, S_IRUGO);
>>>>>> +MODULE_PARM_DESC(msi_iova_base, "msi iova base address.");
>>>>>>
>>>>>> struct arm_smmu_s2cr {
>>>>>> struct iommu_group *group;
>>>>>> @@ -1566,7 +1569,7 @@ static void arm_smmu_get_resv_regions(struct device *dev,
>>>>>> struct iommu_resv_region *region;
>>>>>> int prot = IOMMU_WRITE | IOMMU_NOEXEC | IOMMU_MMIO;
>>>>>>
>>>>>> - region = iommu_alloc_resv_region(MSI_IOVA_BASE, MSI_IOVA_LENGTH,
>>>>>> + region = iommu_alloc_resv_region(msi_iova_base, MSI_IOVA_LENGTH,
>>>>>> prot, IOMMU_RESV_SW_MSI);
>>>>>> if (!region)
>>>>>> return;
>>>>>>
>>>
>>> _______________________________________________
>>> linux-arm-kernel mailing list
>>> linux-arm-kernel@lists.infradead.org
>>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>>>
>>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v10 3/3] configs: defconfig: Add CONFIG_KEYBOARD_MTK_KPD=m
From: Fengping Yu @ 2020-05-28 8:41 UTC (permalink / raw)
To: Yingjoe Chen, Dmitry Torokhov, Andy Shevchenko, Marco Felsch
Cc: fengping.yu, linux-mediatek, linux-arm-kernel, linux-input
In-Reply-To: <20200528084143.36482-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 v10 2/3] drivers: input: keyboard: Add mtk keypad driver
From: Fengping Yu @ 2020-05-28 8:41 UTC (permalink / raw)
To: Yingjoe Chen, Dmitry Torokhov, Andy Shevchenko, Marco Felsch
Cc: fengping.yu, linux-mediatek, linux-arm-kernel, linux-input
In-Reply-To: <20200528084143.36482-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 | 206 +++++++++++++++++++++++++++++++
3 files changed, 218 insertions(+)
create mode 100644 drivers/input/keyboard/mtk-kpd.c
diff --git a/drivers/input/keyboard/Kconfig b/drivers/input/keyboard/Kconfig
index 28de965a08d5..c55230c4c344 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 || 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..2900487c8f60
--- /dev/null
+++ b/drivers/input/keyboard/mtk-kpd.c
@@ -0,0 +1,206 @@
+// 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/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;
+ 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;
+ unsigned int irq;
+ u32 debounce;
+ bool wakeup;
+ 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;
+ }
+
+ 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, MTK_KPD_DEBOUNCE,
+ debounce * 32 / 1000 & MTK_KPD_DEBOUNCE_MASK);
+
+ keypad->clk = devm_clk_get(&pdev->dev, "kpd");
+ if (IS_ERR(keypad->clk))
+ return keypad->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;
+
+ irq = platform_get_irq(pdev, 0);
+ if (irq < 0)
+ return irq;
+
+ ret = devm_request_threaded_irq(&pdev->dev, irq,
+ NULL, kpd_irq_handler, 0,
+ MTK_KPD_NAME, keypad);
+ if (ret) {
+ dev_err(&pdev->dev, "Failed to request IRQ#%d:%d\n",
+ irq, 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, wakeup);
+}
+
+static const struct of_device_id kpd_of_match[] = {
+ { .compatible = "mediatek,mt6779-keypad" },
+ { .compatible = "mediatek,mt6873-keypad" },
+ { /* 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
* [PATCH v10 1/3] dt-bindings: Add keypad devicetree documentation
From: Fengping Yu @ 2020-05-28 8:41 UTC (permalink / raw)
To: Yingjoe Chen, Dmitry Torokhov, Andy Shevchenko, Marco Felsch
Cc: fengping.yu, linux-mediatek, linux-arm-kernel, linux-input
In-Reply-To: <20200528084143.36482-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 | 95 +++++++++++++++++++
1 file changed, 95 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..586cd196dd00
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/mtk-kpd.yaml
@@ -0,0 +1,95 @@
+# SPDX-License-Identifier: GPL-2.0
+%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,mt6873-keypad"
+
+ 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,mt6779-keypad";
+ 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
* [PATCH v11] Add matrix keypad driver support for Mediatek SoCs
From: Fengping Yu @ 2020-05-28 8:41 UTC (permalink / raw)
To: Yingjoe Chen, Dmitry Torokhov, Andy Shevchenko, Marco Felsch
Cc: linux-mediatek, linux-arm-kernel, linux-input
Change since v10:
- add wakeup source setting in probe function
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 | 95 ++++++++
arch/arm64/configs/defconfig | 1 +
drivers/input/keyboard/Kconfig | 11 +
drivers/input/keyboard/Makefile | 1 +
drivers/input/keyboard/mtk-kpd.c | 206 ++++++++++++++++++
5 files changed, 314 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: [RFC PATCH] iommu/arm-smmu: Add module parameter to set msi iova address
From: Jean-Philippe Brucker @ 2020-05-28 8:38 UTC (permalink / raw)
To: Auger Eric
Cc: Will Deacon, Joerg Roedel, iommu, shameerali.kolothum.thodi,
Linux Kernel Mailing List, Alex Williamson, Srinath Mannam,
BCM Kernel Feedback, Robin Murphy, Linux ARM
In-Reply-To: <527f25a4-ca5a-10da-150f-0b4ea3839635@redhat.com>
[+ Shameer]
On Thu, May 28, 2020 at 09:43:46AM +0200, Auger Eric wrote:
> Hi,
>
> On 5/28/20 9:23 AM, Jean-Philippe Brucker wrote:
> > On Thu, May 28, 2020 at 10:45:14AM +0530, Srinath Mannam wrote:
> >> On Wed, May 27, 2020 at 11:00 PM Robin Murphy <robin.murphy@arm.com> wrote:
> >>>
> >> Thanks Robin for your quick response.
> >>> On 2020-05-27 17:03, Srinath Mannam wrote:
> >>>> This patch gives the provision to change default value of MSI IOVA base
> >>>> to platform's suitable IOVA using module parameter. The present
> >>>> hardcoded MSI IOVA base may not be the accessible IOVA ranges of platform.
> >>>
> >>> That in itself doesn't seem entirely unreasonable; IIRC the current
> >>> address is just an arbitrary choice to fit nicely into Qemu's memory
> >>> map, and there was always the possibility that it wouldn't suit everything.
> >>>
> >>>> Since commit aadad097cd46 ("iommu/dma: Reserve IOVA for PCIe inaccessible
> >>>> DMA address"), inaccessible IOVA address ranges parsed from dma-ranges
> >>>> property are reserved.
> >
> > I don't understand why we only reserve the PCIe windows for DMA domains.
> > Shouldn't VFIO also prevent userspace from mapping them?
>
> VFIO prevents userspace from DMA mapping iovas within reserved regions:
> 9b77e5c79840 vfio/type1: check dma map request is within a valid iova range
Right but I was asking specifically about the IOVA reservation introduced
by commit aadad097cd46. They are not registered as reserved regions within
the IOMMU core, they are only taken into account by dma-iommu.c when
creating a DMA domain. As VFIO uses UNMANAGED domains, it isn't aware of
those regions and they won't be seen by vfio_iommu_resv_exclude().
It looks like the PCIe regions used to be common until cd2c9fcf5c66
("iommu/dma: Move PCI window region reservation back into dma specific
path.") But I couldn't find the justification for this commit.
The thing is, if VFIO isn't aware of the reserved PCIe windows, then
allowing VFIO or userspace to choose MSI_IOVA_BASE won't solve the problem
reported by Srinath, because they could well choose an IOVA within the
PCIe window...
Thanks,
Jean
> but it does not prevent the SW MSI region chosen by the kernel from
> colliding with other reserved regions (esp. PCIe host bridge windows).
>
> If they were
> > part of the common reserved regions then we could have VFIO choose a
> > SW_MSI region among the remaining free space.
> As Robin said this was the initial chosen approach
> [PATCH 10/10] vfio: allow the user to register reserved iova range for
> MSI mapping
> https://patchwork.kernel.org/patch/8121641/
>
> Some additional background about why the static SW MSI region chosen by
> the kernel was later chosen:
> Summary of LPC guest MSI discussion in Santa Fe (was: Re: [RFC 0/8] KVM
> PCIe/MSI passthrough on ARM/ARM64 (Alt II))
> https://lists.linuxfoundation.org/pipermail/iommu/2016-November/019060.html
>
> Thanks
>
> Eric
>
>
> It would just need a
> > different way of asking the IOMMU driver if a SW_MSI is needed, for
> > example with a domain attribute.
> >
> > Thanks,
> > Jean
> >
> >>>
> >>> That, however, doesn't seem to fit here; iommu-dma maps MSI doorbells
> >>> dynamically, so they aren't affected by reserved regions any more than
> >>> regular DMA pages are. In fact, it explicitly ignores the software MSI
> >>> region, since as the comment says, it *is* the software that manages those.
> >> Yes you are right, we don't see any issues with kernel drivers(PCI EP) because
> >> MSI IOVA allocated dynamically by honouring reserved regions same as DMA pages.
> >>>
> >>> The MSI_IOVA_BASE region exists for VFIO, precisely because in that case
> >>> the kernel *doesn't* control the address space, but still needs some way
> >>> to steal a bit of it for MSIs that the guest doesn't necessarily know
> >>> about, and give userspace a fighting chance of knowing what it's taken.
> >>> I think at the time we discussed the idea of adding something to the
> >>> VFIO uapi such that userspace could move this around if it wanted or
> >>> needed to, but decided we could live without that initially. Perhaps now
> >>> the time has come?
> >> Yes, we see issues only with user-space drivers(DPDK) in which MSI_IOVA_BASE
> >> region is considered to map MSI registers. This patch helps us to fix the issue.
> >>
> >> Thanks,
> >> Srinath.
> >>>
> >>> Robin.
> >>>
> >>>> If any platform has the limitaion to access default MSI IOVA, then it can
> >>>> be changed using "arm-smmu.msi_iova_base=0xa0000000" command line argument.
> >>>>
> >>>> Signed-off-by: Srinath Mannam <srinath.mannam@broadcom.com>
> >>>> ---
> >>>> drivers/iommu/arm-smmu.c | 5 ++++-
> >>>> 1 file changed, 4 insertions(+), 1 deletion(-)
> >>>>
> >>>> diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
> >>>> index 4f1a350..5e59c9d 100644
> >>>> --- a/drivers/iommu/arm-smmu.c
> >>>> +++ b/drivers/iommu/arm-smmu.c
> >>>> @@ -72,6 +72,9 @@ static bool disable_bypass =
> >>>> module_param(disable_bypass, bool, S_IRUGO);
> >>>> MODULE_PARM_DESC(disable_bypass,
> >>>> "Disable bypass streams such that incoming transactions from devices that are not attached to an iommu domain will report an abort back to the device and will not be allowed to pass through the SMMU.");
> >>>> +static unsigned long msi_iova_base = MSI_IOVA_BASE;
> >>>> +module_param(msi_iova_base, ulong, S_IRUGO);
> >>>> +MODULE_PARM_DESC(msi_iova_base, "msi iova base address.");
> >>>>
> >>>> struct arm_smmu_s2cr {
> >>>> struct iommu_group *group;
> >>>> @@ -1566,7 +1569,7 @@ static void arm_smmu_get_resv_regions(struct device *dev,
> >>>> struct iommu_resv_region *region;
> >>>> int prot = IOMMU_WRITE | IOMMU_NOEXEC | IOMMU_MMIO;
> >>>>
> >>>> - region = iommu_alloc_resv_region(MSI_IOVA_BASE, MSI_IOVA_LENGTH,
> >>>> + region = iommu_alloc_resv_region(msi_iova_base, MSI_IOVA_LENGTH,
> >>>> prot, IOMMU_RESV_SW_MSI);
> >>>> if (!region)
> >>>> return;
> >>>>
> >
> > _______________________________________________
> > linux-arm-kernel mailing list
> > linux-arm-kernel@lists.infradead.org
> > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> >
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [RFC/RFT PATCH 0/2] crypto: add CTS output IVs for arm64 and testmgr
From: Ard Biesheuvel @ 2020-05-28 8:33 UTC (permalink / raw)
To: Herbert Xu
Cc: Eric Biggers, Stephan Mueller, Linux Crypto Mailing List,
Linux ARM
In-Reply-To: <20200528073349.GA32566@gondor.apana.org.au>
On Thu, 28 May 2020 at 09:33, Herbert Xu <herbert@gondor.apana.org.au> wrote:
>
> Ard Biesheuvel <ardb@kernel.org> wrote:
> > Stephan reports that the arm64 implementation of cts(cbc(aes)) deviates
> > from the generic implementation in what it returns as the output IV. So
> > fix this, and add some test vectors to catch other non-compliant
> > implementations.
> >
> > Stephan, could you provide a reference for the NIST validation tool and
> > how it flags this behaviour as non-compliant? Thanks.
>
> I think our CTS and XTS are both broken with respect to af_alg.
>
> The reason we use output IVs in general is to support chaining
> which is required by algif_skcipher to break up large requests
> into smaller ones.
>
> For CTS and XTS that simply doesn't work. So we should fix this
> by changing algif_skcipher to not do chaining (and hence drop
> support for large requests like algif_aead) for algorithms like
> CTS/XTS.
>
The reason we return output IVs for CBC is because our generic
implementation of CTS can wrap any CBC implementation, and relies on
this output IV rather than grabbing it from the ciphertext directly
(which may be tricky and is best left up to the CBC code)
For CTS itself, as well as XTS, returning an output IV is meaningless,
given that
a) the implementations rely on the skcipher_walk infrastructure to
present all input except the last bit in chunks that are a multiple of
the block size,
b) neither specification defines how chaining of inputs should work,
regardless of whether the preceding input was a multiple of the block
size or not.
The CS3 mode that we implement for CTS swaps the final two blocks
unconditionally. So even if the input is a whole multiple of the block
size, the preceding ciphertext will turn out differently if any output
happens to follow.
For XTS, the IV is encrypted before processing the first block, so
even if you do return an output IV, the subsequent invocations of the
skcipher need to omit the encryption, which we don't implement
currently.
So if you are saying that we should never split up algif_skcipher
requests into multiple calls into the underlying skcipher, then I
agree with you. Even if the generic CTS seems to work more or less as
expected by, e.g., the NIST validation tool, this is unspecified
behavior, and definitely broken in various other places.
_______________________________________________
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 v10] Add matrix keypad driver support for Mediatek SoCs
From: fengping.yu @ 2020-05-28 8:21 UTC (permalink / raw)
To: Marco Felsch
Cc: Dmitry Torokhov, linux-mediatek, linux-input, Yingjoe Chen,
Andy Shevchenko, linux-arm-kernel
In-Reply-To: <20200528071916.2zxch46lbimxet2u@pengutronix.de>
Hi Marco:
I am sorry, I think I misunderstand your suggestion about wakeup member
in patch v9.
Keypad is a wakeup source, so I mis-remove wakeup source setting in the
probe function.
I will modify this in the next patch.
Thanks.
On Thu, 2020-05-28 at 09:19 +0200, Marco Felsch wrote:
> Hi,
>
> this version looks nice to me =) One last question.
>
> On 20-05-28 13:33, Fengping Yu wrote:
> >
> > Change since v9:
> > - modify KEYBOARD_MTK_KPD config dependent item
> > - remove wakeup member of mtk_keypad struct
>
> You also removed the device wakeup capability completely, was this
> intended? What I mean is that we don't need that member within the
> driver state struct.
>
> Regards,
> Marco
>
> > - remove default pinctrl state set
> > - modify request irq failed return value
> > - add space of kepad matching table
> > - modify align issue
> >
> > 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 | 95 +++++++++
> > arch/arm64/configs/defconfig | 1 +
> > drivers/input/keyboard/Kconfig | 11 +
> > drivers/input/keyboard/Makefile | 1 +
> > drivers/input/keyboard/mtk-kpd.c | 201 ++++++++++++++++++
> > 5 files changed, 309 insertions(+)
> > create mode 100644 Documentation/devicetree/bindings/input/mtk-kpd.yaml
> > create mode 100644 drivers/input/keyboard/mtk-kpd.c
> >
> > --
> > 2.18.0
> >
>
> _______________________________________________
> Linux-mediatek mailing list
> Linux-mediatek@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-mediatek
_______________________________________________
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/2] drm/mxsfb: Call drm_crtc_vblank_on/off
From: Daniel Vetter @ 2020-05-28 8:25 UTC (permalink / raw)
To: Stefan Agner
Cc: Marek Vasut, Pengutronix Kernel Team, Fabio Estevam,
Intel Graphics Development, DRI Development, Laurent Pinchart,
Daniel Vetter, Daniel Vetter, Shawn Guo, Sascha Hauer, Linux ARM,
NXP Linux Team
In-Reply-To: <c8294901e201cd40a41111b05ecccd43@agner.ch>
On Thu, May 28, 2020 at 10:19:46AM +0200, Stefan Agner wrote:
> On 2020-05-28 10:06, Daniel Vetter wrote:
> > On Thu, May 28, 2020 at 9:56 AM Stefan Agner <stefan@agner.ch> wrote:
> >>
> >> Hi Daniel,
> >>
> >> On 2020-05-28 07:46, Daniel Vetter wrote:
> >> > On Wed, May 27, 2020 at 11:47:56AM +0200, Daniel Vetter wrote:
> >> >> mxsfb has vblank support, is atomic, but doesn't call
> >> >> drm_crtc_vblank_on/off as it should. Not good.
> >> >>
> >> >> With my next patch to add the drm_crtc_vblank_reset to helpers this
> >> >> means not even the very first crtc enabling will vblanks work anymore,
> >> >> since they'll just stay off forever.
> >> >>
> >> >> Since mxsfb doesn't have any vblank waits of its own in the
> >> >> enable/disable flow, nor an enable/disable_vblank callback we can do
> >> >> the on/off as the first respectively last operation, and it should all
> >> >> work.
> >> >>
> >> >> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> >> >> Cc: Marek Vasut <marex@denx.de>
> >> >> Cc: Stefan Agner <stefan@agner.ch>
> >> >> Cc: Shawn Guo <shawnguo@kernel.org>
> >> >> Cc: Sascha Hauer <s.hauer@pengutronix.de>
> >> >> Cc: Pengutronix Kernel Team <kernel@pengutronix.de>
> >> >> Cc: Fabio Estevam <festevam@gmail.com>
> >> >> Cc: NXP Linux Team <linux-imx@nxp.com>
> >> >> Cc: linux-arm-kernel@lists.infradead.org
> >> >
> >> > Ping for some ack/review on this one here, it's holding up the subsystem
> >> > wide fix in patch 2.
> >>
> >> Sorry for the delay.
> >>
> >> I guess that has the same effect as patch 14 in Laurent's patchset would
> >> have:
> >> https://lore.kernel.org/dri-devel/20200309195216.31042-15-laurent.pinchart@ideasonboard.com/
> >
> > Uh, looking at that patch I realized that mxsfb indeed calls
> > drm_vblank_init before mode_config.num_crtc is set. Which means it
> > never had working vblank support in upstream. That also explains the
> > lack of fireworks, since all other drivers that actually do initialize
> > vblank support have the drm_crtc_vblank_on/off calls - without them
> > the driver doesn't survive for very long.
> >
> > tldr; I don't need this patch here to apply the 2nd one, so no
> > conflict potential at all. And the patch from Laurent does fix up
> > everything correctly, so we should be good.
>
> Uh I see, that is somehow unfortunate and fortunate at the same time!
>
> Ok, I hope we get this cleaned up soon.
I recommend igt tests for actually making sure your driver does something,
instead of just thinking you've enabled a feature :-)
-Daniel
>
> --
> Stefan
>
> > -Daniel
> >
> >> But should be rather trivial to rebase. So until Laurent's patchset is
> >> ready, we can go with this fix.
> >>
> >> Acked-by: Stefan Agner <stefan@agner.ch>
> >>
> >> --
> >> Stefan
> >>
> >> >
> >> > Thanks, Daniel
> >> >
> >> >> ---
> >> >> drivers/gpu/drm/mxsfb/mxsfb_drv.c | 2 ++
> >> >> 1 file changed, 2 insertions(+)
> >> >>
> >> >> diff --git a/drivers/gpu/drm/mxsfb/mxsfb_drv.c b/drivers/gpu/drm/mxsfb/mxsfb_drv.c
> >> >> index 497cf443a9af..1891cd6deb2f 100644
> >> >> --- a/drivers/gpu/drm/mxsfb/mxsfb_drv.c
> >> >> +++ b/drivers/gpu/drm/mxsfb/mxsfb_drv.c
> >> >> @@ -124,6 +124,7 @@ static void mxsfb_pipe_enable(struct drm_simple_display_pipe *pipe,
> >> >> drm_panel_prepare(mxsfb->panel);
> >> >> mxsfb_crtc_enable(mxsfb);
> >> >> drm_panel_enable(mxsfb->panel);
> >> >> + drm_crtc_vblank_on(&pipe->crtc);
> >> >> }
> >> >>
> >> >> static void mxsfb_pipe_disable(struct drm_simple_display_pipe *pipe)
> >> >> @@ -133,6 +134,7 @@ static void mxsfb_pipe_disable(struct drm_simple_display_pipe *pipe)
> >> >> struct drm_crtc *crtc = &pipe->crtc;
> >> >> struct drm_pending_vblank_event *event;
> >> >>
> >> >> + drm_crtc_vblank_off(&pipe->crtc);
> >> >> drm_panel_disable(mxsfb->panel);
> >> >> mxsfb_crtc_disable(mxsfb);
> >> >> drm_panel_unprepare(mxsfb->panel);
> >> >> --
> >> >> 2.26.2
> >> >>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
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/2] drm/mxsfb: Call drm_crtc_vblank_on/off
From: Stefan Agner @ 2020-05-28 8:19 UTC (permalink / raw)
To: Daniel Vetter
Cc: Marek Vasut, Fabio Estevam, Intel Graphics Development,
DRI Development, Laurent Pinchart, Pengutronix Kernel Team,
Daniel Vetter, Shawn Guo, Sascha Hauer, Linux ARM, NXP Linux Team
In-Reply-To: <CAKMK7uGzbadiY1EQKQvQcBND4Ja73WZRF8-DoxLJNTsGBJS0jw@mail.gmail.com>
On 2020-05-28 10:06, Daniel Vetter wrote:
> On Thu, May 28, 2020 at 9:56 AM Stefan Agner <stefan@agner.ch> wrote:
>>
>> Hi Daniel,
>>
>> On 2020-05-28 07:46, Daniel Vetter wrote:
>> > On Wed, May 27, 2020 at 11:47:56AM +0200, Daniel Vetter wrote:
>> >> mxsfb has vblank support, is atomic, but doesn't call
>> >> drm_crtc_vblank_on/off as it should. Not good.
>> >>
>> >> With my next patch to add the drm_crtc_vblank_reset to helpers this
>> >> means not even the very first crtc enabling will vblanks work anymore,
>> >> since they'll just stay off forever.
>> >>
>> >> Since mxsfb doesn't have any vblank waits of its own in the
>> >> enable/disable flow, nor an enable/disable_vblank callback we can do
>> >> the on/off as the first respectively last operation, and it should all
>> >> work.
>> >>
>> >> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
>> >> Cc: Marek Vasut <marex@denx.de>
>> >> Cc: Stefan Agner <stefan@agner.ch>
>> >> Cc: Shawn Guo <shawnguo@kernel.org>
>> >> Cc: Sascha Hauer <s.hauer@pengutronix.de>
>> >> Cc: Pengutronix Kernel Team <kernel@pengutronix.de>
>> >> Cc: Fabio Estevam <festevam@gmail.com>
>> >> Cc: NXP Linux Team <linux-imx@nxp.com>
>> >> Cc: linux-arm-kernel@lists.infradead.org
>> >
>> > Ping for some ack/review on this one here, it's holding up the subsystem
>> > wide fix in patch 2.
>>
>> Sorry for the delay.
>>
>> I guess that has the same effect as patch 14 in Laurent's patchset would
>> have:
>> https://lore.kernel.org/dri-devel/20200309195216.31042-15-laurent.pinchart@ideasonboard.com/
>
> Uh, looking at that patch I realized that mxsfb indeed calls
> drm_vblank_init before mode_config.num_crtc is set. Which means it
> never had working vblank support in upstream. That also explains the
> lack of fireworks, since all other drivers that actually do initialize
> vblank support have the drm_crtc_vblank_on/off calls - without them
> the driver doesn't survive for very long.
>
> tldr; I don't need this patch here to apply the 2nd one, so no
> conflict potential at all. And the patch from Laurent does fix up
> everything correctly, so we should be good.
Uh I see, that is somehow unfortunate and fortunate at the same time!
Ok, I hope we get this cleaned up soon.
--
Stefan
> -Daniel
>
>> But should be rather trivial to rebase. So until Laurent's patchset is
>> ready, we can go with this fix.
>>
>> Acked-by: Stefan Agner <stefan@agner.ch>
>>
>> --
>> Stefan
>>
>> >
>> > Thanks, Daniel
>> >
>> >> ---
>> >> drivers/gpu/drm/mxsfb/mxsfb_drv.c | 2 ++
>> >> 1 file changed, 2 insertions(+)
>> >>
>> >> diff --git a/drivers/gpu/drm/mxsfb/mxsfb_drv.c b/drivers/gpu/drm/mxsfb/mxsfb_drv.c
>> >> index 497cf443a9af..1891cd6deb2f 100644
>> >> --- a/drivers/gpu/drm/mxsfb/mxsfb_drv.c
>> >> +++ b/drivers/gpu/drm/mxsfb/mxsfb_drv.c
>> >> @@ -124,6 +124,7 @@ static void mxsfb_pipe_enable(struct drm_simple_display_pipe *pipe,
>> >> drm_panel_prepare(mxsfb->panel);
>> >> mxsfb_crtc_enable(mxsfb);
>> >> drm_panel_enable(mxsfb->panel);
>> >> + drm_crtc_vblank_on(&pipe->crtc);
>> >> }
>> >>
>> >> static void mxsfb_pipe_disable(struct drm_simple_display_pipe *pipe)
>> >> @@ -133,6 +134,7 @@ static void mxsfb_pipe_disable(struct drm_simple_display_pipe *pipe)
>> >> struct drm_crtc *crtc = &pipe->crtc;
>> >> struct drm_pending_vblank_event *event;
>> >>
>> >> + drm_crtc_vblank_off(&pipe->crtc);
>> >> drm_panel_disable(mxsfb->panel);
>> >> mxsfb_crtc_disable(mxsfb);
>> >> drm_panel_unprepare(mxsfb->panel);
>> >> --
>> >> 2.26.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: [V9, 1/2] media: dt-bindings: media: i2c: Document OV02A10 bindings
From: Dongchun Zhu @ 2020-05-28 8:04 UTC (permalink / raw)
To: Sakari Ailus
Cc: Mark Rutland, Rob Herring, Andy Shevchenko, srv_heupstream,
devicetree, Linus Walleij,
Shengnan Wang (王圣男), Tomasz Figa,
Bartosz Golaszewski, Sj Huang, Nicolas Boichat,
moderated list:ARM/Mediatek SoC support, Louis Kuo,
Matthias Brugger, Cao Bing Bu, Mauro Carvalho Chehab,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
Linux Media Mailing List
In-Reply-To: <20200528072332.GW7618@paasikivi.fi.intel.com>
Hi Sakari,
On Thu, 2020-05-28 at 10:23 +0300, Sakari Ailus wrote:
> Hi Dongchun,
>
> On Thu, May 28, 2020 at 11:34:42AM +0800, Dongchun Zhu wrote:
> > Hi Sakari, Rob,
> >
> > On Thu, 2020-05-28 at 00:16 +0300, Sakari Ailus wrote:
> > > Hi Rob, Dongchun,
> > >
> > > On Wed, May 27, 2020 at 09:27:22AM -0600, Rob Herring wrote:
> > > > > > > + properties:
> > > > > > > + endpoint:
> > > > > > > + type: object
> > > > > > > + additionalProperties: false
> > > > > > > +
> > > > > > > + properties:
> > > > >
> > > > > Actually I wonder whether we need to declare 'clock-lanes' here?
> > > >
> > > > Yes, if you are using it.
> > >
> > > Dongchun, can you confirm the chip has a single data and a single clock
> > > lane and that it does not support lane reordering?
> > >
> >
> > From the datasheet, 'MIPI inside the OV02A10 provides one single
> > uni-directional clock lane and one bi-directional data lane solution for
> > communication links between components inside a mobile device.
> > The data lane has full support for HS(uni-directional) and
> > LP(bi-directional) data transfer mode.'
> >
> > The sensor doesn't support lane reordering, so 'clock-lanes' property
> > would not be added in next release.
> >
> > > So if there's nothing to convey to the driver, also the data-lanes should
> > > be removed IMO.
> > >
> >
> > However, 'data-lanes' property may still be required.
> > It is known that either data-lanes or clock-lanes is an array of
> > physical data lane indexes. Position of an entry determines the logical
> > lane number, while the value of an entry indicates physical lane, e.g.,
> > for 1-lane MIPI CSI-2 bus we could have "data-lanes = <1>;", assuming
> > the clock lane is on hardware lane 0.
> >
> > As mentioned earlier, the OV02A10 sensor supports only 1C1D and does not
> > support lane reordering, so here we shall use 'data-lanes = <1>' as
> > there is only a clock lane for OV02A10.
> >
> > Reminder:
> > If 'data-lanes' property is not present, the driver would assume
> > four-lane operation. This means for one-lane or two-lane operation, this
> > property must be present and set to the right physical lane indexes.
> > If the hardware does not support lane reordering, monotonically
> > incremented values shall be used from 0 or 1 onwards, depending on
> > whether or not there is also a clock lane.
>
> How can the driver use four lanes, considering the device only supports a
> single lane??
>
I understood your meaning.
If we omit the property 'data-lanes', the sensor should work still.
But then what's the meaning of the existence of 'data-lanes'?
If this property 'data-lanes' is always optional, then why dt-bindings
provide the interface?
In the meantime, if omitting 'data-lanes' for one sensor(transmitter)
that has only one physical data lane, MIPI receiver(e.g., MIPI CSI-2)
shall enable four-lane configuration, which may increase consumption of
both power and resource in the process of IIC communication.
_______________________________________________
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/RFC] arm64/kernel: Fix return value when cpu_online() fails in __cpu_up()
From: Will Deacon @ 2020-05-28 8:12 UTC (permalink / raw)
To: Nobuhiro Iwamatsu
Cc: Mark Rutland, catalin.marinas, Signed-off-by : Gavin Shan,
Yuji Ishikawa, linux-arm-kernel
In-Reply-To: <20200527233457.2531118-1-nobuhiro1.iwamatsu@toshiba.co.jp>
On Thu, May 28, 2020 at 08:34:57AM +0900, Nobuhiro Iwamatsu wrote:
> If boot_secondary() was successful, and cpu_online() was an error in
> __cpu_up(), -EIO was returned, but 0 is returned by commit d22b115cbfbb7
> ("arm64/kernel: Simplify __cpu_up() by bailing out early").
> Therefore, bringup_wait_for_ap() causes the primary core to wait for a
> long time, which may cause boot failure.
> This commit sets -EIO to return code under the same conditions.
>
> Fixes: d22b115cbfbb7 ("arm64/kernel: Simplify __cpu_up() by bailing out early")
> CC: Signed-off-by: Gavin Shan <gshan@redhat.com>
> CC: Catalin Marinas <catalin.marinas@arm.com>
> CC: Mark Rutland <mark.rutland@arm.com>
> Tested-by: Yuji Ishikawa <yuji2.ishikawa@toshiba.co.jp>
> Signed-off-by: Nobuhiro Iwamatsu <nobuhiro1.iwamatsu@toshiba.co.jp>
> ---
> arch/arm64/kernel/smp.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/arch/arm64/kernel/smp.c b/arch/arm64/kernel/smp.c
> index 061f60fe452f7..ea677680e4277 100644
> --- a/arch/arm64/kernel/smp.c
> +++ b/arch/arm64/kernel/smp.c
> @@ -137,6 +137,7 @@ int __cpu_up(unsigned int cpu, struct task_struct *idle)
> if (cpu_online(cpu))
> return 0;
>
> + ret = -EIO;
> pr_crit("CPU%u: failed to come online\n", cpu);
> secondary_data.task = NULL;
> secondary_data.stack = NULL;
This appears to restore the old behaviour, so looks good to me. I'd probably
just replace the final 'return ret' with 'return -EIO' since it's never
going to be anything else.
Also -- aren't you in a pretty serious mess if the CPU starts but doesn't
come online? I think the patch is fine, but this really shouldn't happen,
right? Could you share your dmesg?
Either way:
Acked-by: Will Deacon <will@kernel.org>
Catalin -- do you want to take this (the problematic change was introduced
during the last merge window afaict)?
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 1/2] drm/mxsfb: Call drm_crtc_vblank_on/off
From: Daniel Vetter @ 2020-05-28 8:06 UTC (permalink / raw)
To: Stefan Agner
Cc: Marek Vasut, Fabio Estevam, Intel Graphics Development,
DRI Development, Laurent Pinchart, Pengutronix Kernel Team,
Daniel Vetter, Shawn Guo, Sascha Hauer, Linux ARM, NXP Linux Team
In-Reply-To: <7911368105b92200b661f0fed39f5642@agner.ch>
On Thu, May 28, 2020 at 9:56 AM Stefan Agner <stefan@agner.ch> wrote:
>
> Hi Daniel,
>
> On 2020-05-28 07:46, Daniel Vetter wrote:
> > On Wed, May 27, 2020 at 11:47:56AM +0200, Daniel Vetter wrote:
> >> mxsfb has vblank support, is atomic, but doesn't call
> >> drm_crtc_vblank_on/off as it should. Not good.
> >>
> >> With my next patch to add the drm_crtc_vblank_reset to helpers this
> >> means not even the very first crtc enabling will vblanks work anymore,
> >> since they'll just stay off forever.
> >>
> >> Since mxsfb doesn't have any vblank waits of its own in the
> >> enable/disable flow, nor an enable/disable_vblank callback we can do
> >> the on/off as the first respectively last operation, and it should all
> >> work.
> >>
> >> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> >> Cc: Marek Vasut <marex@denx.de>
> >> Cc: Stefan Agner <stefan@agner.ch>
> >> Cc: Shawn Guo <shawnguo@kernel.org>
> >> Cc: Sascha Hauer <s.hauer@pengutronix.de>
> >> Cc: Pengutronix Kernel Team <kernel@pengutronix.de>
> >> Cc: Fabio Estevam <festevam@gmail.com>
> >> Cc: NXP Linux Team <linux-imx@nxp.com>
> >> Cc: linux-arm-kernel@lists.infradead.org
> >
> > Ping for some ack/review on this one here, it's holding up the subsystem
> > wide fix in patch 2.
>
> Sorry for the delay.
>
> I guess that has the same effect as patch 14 in Laurent's patchset would
> have:
> https://lore.kernel.org/dri-devel/20200309195216.31042-15-laurent.pinchart@ideasonboard.com/
Uh, looking at that patch I realized that mxsfb indeed calls
drm_vblank_init before mode_config.num_crtc is set. Which means it
never had working vblank support in upstream. That also explains the
lack of fireworks, since all other drivers that actually do initialize
vblank support have the drm_crtc_vblank_on/off calls - without them
the driver doesn't survive for very long.
tldr; I don't need this patch here to apply the 2nd one, so no
conflict potential at all. And the patch from Laurent does fix up
everything correctly, so we should be good.
-Daniel
> But should be rather trivial to rebase. So until Laurent's patchset is
> ready, we can go with this fix.
>
> Acked-by: Stefan Agner <stefan@agner.ch>
>
> --
> Stefan
>
> >
> > Thanks, Daniel
> >
> >> ---
> >> drivers/gpu/drm/mxsfb/mxsfb_drv.c | 2 ++
> >> 1 file changed, 2 insertions(+)
> >>
> >> diff --git a/drivers/gpu/drm/mxsfb/mxsfb_drv.c b/drivers/gpu/drm/mxsfb/mxsfb_drv.c
> >> index 497cf443a9af..1891cd6deb2f 100644
> >> --- a/drivers/gpu/drm/mxsfb/mxsfb_drv.c
> >> +++ b/drivers/gpu/drm/mxsfb/mxsfb_drv.c
> >> @@ -124,6 +124,7 @@ static void mxsfb_pipe_enable(struct drm_simple_display_pipe *pipe,
> >> drm_panel_prepare(mxsfb->panel);
> >> mxsfb_crtc_enable(mxsfb);
> >> drm_panel_enable(mxsfb->panel);
> >> + drm_crtc_vblank_on(&pipe->crtc);
> >> }
> >>
> >> static void mxsfb_pipe_disable(struct drm_simple_display_pipe *pipe)
> >> @@ -133,6 +134,7 @@ static void mxsfb_pipe_disable(struct drm_simple_display_pipe *pipe)
> >> struct drm_crtc *crtc = &pipe->crtc;
> >> struct drm_pending_vblank_event *event;
> >>
> >> + drm_crtc_vblank_off(&pipe->crtc);
> >> drm_panel_disable(mxsfb->panel);
> >> mxsfb_crtc_disable(mxsfb);
> >> drm_panel_unprepare(mxsfb->panel);
> >> --
> >> 2.26.2
> >>
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
_______________________________________________
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] arm64: vdso32: force vdso32 to be compiled as -marm
From: Peter Smith @ 2020-05-28 8:05 UTC (permalink / raw)
To: Nick Desaulniers, Robin Murphy
Cc: Naohiro Aota, Stephen Boyd, Arnd Bergmann, Catalin Marinas,
Masahiro Yamada, LKML, david.spickett@linaro.org, Manoj Gupta,
Kristof Beyls, Luis Lozano, Nathan Chancellor, Vincenzo Frascino,
Will Deacon, Victor Campos, Linux ARM
In-Reply-To: <CAKwvOd=Zxm9TDPNd4Qvn6Ru==FLasiP1xWXMM7ji08VWRjBu2g@mail.gmail.com>
> From: Nick Desaulniers <ndesaulniers@google.com>
> Sent: 27 May 2020 21:31
> To: Robin Murphy
> Cc: Catalin Marinas; Will Deacon; Naohiro Aota; Stephen Boyd; Masahiro Yamada; LKML; Manoj Gupta; Luis Lozano; Nathan Chancellor; Vincenzo Frascino; Linux ARM; Kristof Beyls; Victor Campos; david.spickett@linaro.org; Arnd Bergmann; Peter Smith
> Subject: Re: [PATCH] arm64: vdso32: force vdso32 to be compiled as -marm
>
> On Wed, May 27, 2020 at 1:14 PM Nick Desaulniers
> <ndesaulniers@google.com> wrote:
> >
> > On Wed, May 27, 2020 at 12:28 PM Robin Murphy <robin.murphy@arm.com> wrote:
> > >
> > > On 2020-05-27 18:55, Nick Desaulniers wrote:
> > > > On Wed, May 27, 2020 at 6:45 AM Robin Murphy <robin.murphy@arm.com> wrote:
> > > >>
> > > >> On 2020-05-26 18:31, Nick Desaulniers wrote:
> > > >>> Custom toolchains that modify the default target to -mthumb cannot
> > > >>> compile the arm64 compat vdso32, as
> > > >>> arch/arm64/include/asm/vdso/compat_gettimeofday.h
> > > >>> contains assembly that's invalid in -mthumb. Force the use of -marm,
> > > >>> always.
> > > >>
> > > >> FWIW, this seems suspicious - the only assembly instructions I see there
> > > >> are SWI(SVC), MRRC, and a MOV, all of which exist in Thumb for the
> > > >> -march=armv7a baseline that we set.
> > > >>
> > > >> On a hunch, I've just bodged "VDSO_CFLAGS += -mthumb" into my tree and
> > > >> built a Thumb VDSO quite happily with Ubuntu 19.04's
> > > >> gcc-arm-linux-gnueabihf. What was the actual failure you saw?
> > > >
> > > > From the link in the commit message: `write to reserved register 'R7'`
> > > > https://godbolt.org/z/zwr7iZ
> > > > IIUC r7 is reserved for the frame pointer in THUMB?
> > >
> > > It can be, if you choose to build with frame pointers and the common
> > > frame pointer ABI for Thumb code that uses r7. However it can also be
> > > for other things like the syscall number in the Arm syscall ABI too.
> >
> > Ah, right, with -fomit-frame-pointer, this error also goes away. Not
> > sure if we prefer either:
> > - build the compat vdso as -marm always or
> > - disable frame pointers for the vdso (does this have unwinding implications?)
> > - other?
> >
> > > I
> > > take it Clang has decided that writing syscall wrappers with minimal
> > > inline asm is not a thing people deserve to do without arbitrary other
> > > restrictions?
> >
> > Was the intent not obvious? We would have gotten away with it, too, if
> > wasn't for you meddling kids and your stupid dog! /s
> > https://www.youtube.com/watch?v=hXUqwuzcGeU
> > Anyways, this seems to explain more the intentions:
> > https://reviews.llvm.org/D76848#1945810
> > + Victor, Kristof (ARM)
>
> And maybe some other useful data points regarding warning on use of r7
> and frame pointers.
> https://github.com/ClangBuiltLinux/linux/issues/701#issuecomment-591325758
> https://bugs.llvm.org/show_bug.cgi?id=45826
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94986
>
> + Peter (ARM)
> + David, Arnd (Linaro)
> --
> Thanks,
> ~Nick Desaulniers
Hello Nick,
The AAPCS has only recently (28th January 2020) been updated with a
specification of the frame pointer and frame chain.
My understanding is that neither gcc nor clang implement this part yet.
Historically the frame pointer in Thumb has not been defined in the
AAPCS with implementations falling back to historic definitions of
fp = r7 in Thumb and fp = r11 in Arm. The use of different frame
pointer registers in Arm and Thumb state makes it difficult to
construct a frame chain with interworking. My understanding of the
AAPCS is that it has been changed to make the frame pointer r11 on
both Arm and Thumb to make unwinding possible, at the expense of r11
being harder to access from 16-bit Thumb instructions. There are 4
levels of conformance with respect to construction of frame records
and frame chain as it is likely some platforms will want to persist
with r7.
An implementation of the latest version of the AAPCS would permit
a frame pointer and use of r7 as a reserved register. Although as
you'll need to support older compilers this may not be an option.
I suggest using Arm if you need a frame pointer, and disable the
frame pointer if you want/need to use Thumb. My understanding is that
runtime unwinding using the frame pointer in Thumb is already difficult
due to Arm and Thumb functions using different registers for the frame
pointer.
Hope this helps
Peter
_______________________________________________
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