* Re: [PATCH v7 12/24] iommu/arm-smmu-v3: Add support for VHE
From: Will Deacon @ 2020-05-21 14:16 UTC (permalink / raw)
To: Jean-Philippe Brucker
Cc: devicetree, kevin.tian, jacob.jun.pan, jgg, linux-pci, joro,
Jonathan.Cameron, fenghua.yu, hch, linux-mm, iommu, zhangfei.gao,
catalin.marinas, felix.kuehling, xuzaibo, robin.murphy,
christian.koenig, linux-arm-kernel, baolu.lu
In-Reply-To: <20200519175502.2504091-13-jean-philippe@linaro.org>
On Tue, May 19, 2020 at 07:54:50PM +0200, Jean-Philippe Brucker wrote:
> ARMv8.1 extensions added Virtualization Host Extensions (VHE), which allow
> to run a host kernel at EL2. When using normal DMA, Device and CPU address
> spaces are dissociated, and do not need to implement the same
> capabilities, so VHE hasn't been used in the SMMU until now.
>
> With shared address spaces however, ASIDs are shared between MMU and SMMU,
> and broadcast TLB invalidations issued by a CPU are taken into account by
> the SMMU. TLB entries on both sides need to have identical exception level
> in order to be cleared with a single invalidation.
>
> When the CPU is using VHE, enable VHE in the SMMU for all STEs. Normal DMA
> mappings will need to use TLBI_EL2 commands instead of TLBI_NH, but
> shouldn't be otherwise affected by this change.
>
> Signed-off-by: Jean-Philippe Brucker <jean-philippe@linaro.org>
> ---
> drivers/iommu/arm-smmu-v3.c | 31 ++++++++++++++++++++++++++-----
> 1 file changed, 26 insertions(+), 5 deletions(-)
Acked-by: Will Deacon <will@kernel.org>
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 v7 07/24] iommu/io-pgtable-arm: Move some definitions to a header
From: Will Deacon @ 2020-05-21 14:16 UTC (permalink / raw)
To: Jean-Philippe Brucker
Cc: devicetree, kevin.tian, jacob.jun.pan, jgg, linux-pci, joro,
Jonathan.Cameron, fenghua.yu, hch, linux-mm, iommu, zhangfei.gao,
catalin.marinas, felix.kuehling, xuzaibo, robin.murphy,
christian.koenig, linux-arm-kernel, baolu.lu
In-Reply-To: <20200519175502.2504091-8-jean-philippe@linaro.org>
On Tue, May 19, 2020 at 07:54:45PM +0200, Jean-Philippe Brucker wrote:
> Extract some of the most generic TCR defines, so they can be reused by
> the page table sharing code.
>
> Signed-off-by: Jean-Philippe Brucker <jean-philippe@linaro.org>
> ---
> drivers/iommu/io-pgtable-arm.h | 30 ++++++++++++++++++++++++++++++
> drivers/iommu/io-pgtable-arm.c | 27 ++-------------------------
> MAINTAINERS | 3 +--
> 3 files changed, 33 insertions(+), 27 deletions(-)
> create mode 100644 drivers/iommu/io-pgtable-arm.h
Acked-by: Will Deacon <will@kernel.org>
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 v1 2/4] arm: dts: mt7623: add display subsystem related device nodes
From: Matthias Brugger @ 2020-05-21 14:09 UTC (permalink / raw)
To: Frank Wunderlich, CK Hu, Philipp Zabel, David Airlie,
Daniel Vetter, dri-devel, linux-arm-kernel, linux-mediatek,
linux-kernel, Rob Herring, Mark Rutland, devicetree, chunhui dai,
Ryder Lee, Bibby Hsieh
In-Reply-To: <20190416145848.11932-3-frank-w@public-files.de>
Hi Frank,
On 16/04/2019 16:58, Frank Wunderlich wrote:
> From: Ryder Lee <ryder.lee@mediatek.com>
>
> Add display subsystem related device nodes for MT7623.
>
> Cc: CK Hu <ck.hu@mediatek.com>
> Signed-off-by: chunhui dai <chunhui.dai@mediatek.com>
> Signed-off-by: Bibby Hsieh <bibby.hsieh@mediatek.com>
> Signed-off-by: Ryder Lee <ryder.lee@mediatek.com>
>
> additional fixes:
>
> [hdmi,dts] fixed dts-warnings
> author: Bibby Hsieh <bibby.hsieh@mediatek.com>
>
> [dtsi] fix dpi0-node
> author: Ryder Lee <ryder.lee@mediatek.com>
>
> Signed-off-by: Frank Wunderlich <frank-w@public-files.de>
> Tested-by: Frank Wunderlich <frank-w@public-files.de>
> =2D--
> arch/arm/boot/dts/mt7623.dtsi | 177 ++++++++++++++++++
> arch/arm/boot/dts/mt7623n-bananapi-bpi-r2.dts | 85 +++++++++
> arch/arm/boot/dts/mt7623n-rfb-emmc.dts | 85 +++++++++
> 3 files changed, 347 insertions(+)
>
[...]
>
> + display_components: dispsys@14000000 {
> + compatible =3D "mediatek,mt7623-mmsys",
> + "mediatek,mt2701-mmsys";
> + reg =3D <0 0x14000000 0 0x1000>;
> + power-domains =3D <&scpsys MT2701_POWER_DOMAIN_DISP>;
> + };
> +
mmsys problem is fixed now, so feel free to rebase your patches on linux-next or
my for-next branch and resend.
Would love to see graphics being supported on the bananapi-r2.
Regards,
Matthias
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: Possible race while masking IRQ on Allwinner A20
From: Jérôme Pouiller @ 2020-05-21 14:08 UTC (permalink / raw)
To: Marc Zyngier
Cc: Marc Dorval, Chen-Yu Tsai, Thomas Gleixner, Maxime Ripard,
linux-arm-kernel
In-Reply-To: <faca3f8ee1269b70b46a271dbdf00265@kernel.org>
On Thursday 21 May 2020 15:39:09 CEST Marc Zyngier wrote:
> On 2020-05-21 14:28, Jérôme Pouiller wrote:
> > On Thursday 21 May 2020 10:02:48 CEST Marc Zyngier wrote:
> >> On 2020-05-21 08:26, Maxime Ripard wrote:
> >> > On Tue, May 19, 2020 at 10:59:26AM +0200, Jérôme Pouiller wrote:
> > [...]
> >> >> Nevermind, I tried to use a level triggered IRQ (and my request is on
> >> >> this part). As you can see in the wfx driver (in bus_sdio.c and
> >> >> bh.c), I use a threaded IRQ for that. Unfortunately, I receive some IRQs
> >> >> twice.
> >> >> I traced the problem, I get:
> >> >>
> >> >> QSGRenderThread-981 [000] d.h. 247.485524: irq_handler_entry: irq=80 name=wfx
> >> >> QSGRenderThread-981 [000] d.h. 247.485547: irq_handler_exit: irq=80 ret=handled
> >> >> QSGRenderThread-981 [000] d.h. 247.485600: irq_handler_entry: irq=80 name=wfx
> >> >> QSGRenderThread-981 [000] d.h. 247.485606: irq_handler_exit: irq=80 ret=handled
> >> >> irq/80-wfx-260 [001] .... 247.485828: io_read32: CONTROL: 0000f046
> >> >> irq/80-wfx-260 [001] .... 247.486072: io_read32: CONTROL: 0000f046
> >> >> kworker/1:1H-116 [001] .... 247.486214: io_read: QUEUE: 8b 00 84 18 00 00 00 00 01 00 15 82 2b 48 01 1e 88 42 30 00 08 6b d7 c3 53 e0 28 80 88 67 32 af ... (192 bytes)
> >> >> kworker/1:1H-116 [001] .... 247.493097: io_read: QUEUE: 00 00 00 00 00 00 00 00 06 06 00 6a 3f 95 00 60 00 00 00 00 08 62 00 00 01 00 5e 00 00 07 28 80 ... (192 bytes)
> >> >> [...]
> >> >>
> >> >> On this trace, we can see:
> >> >> - the hard IRQ handler
> >> >> - the IRQ acknowledge from the thread irq/80-wfx-260
> >> >> - the access to the data from kworker/1:1H-116
> >> >>
> >> >> As far as I understand, the first call to the IRQ handler (at
> >> >> 247.485524) should mask the IRQ 80. So, the second IRQ (at 247.485600)
> >> >> should not happen and the thread irq/80 should be triggered only once.
> >> >>
> >> >> Do you have any idea of what is going wrong with this IRQ?
> >> >
> >> > That's pretty weird indeed. My first guess was that you weren't using
> >> > IRQF_ONESHOT, but it looks like you are. My next lead would be to see
> >> > if the mask / unmask hooks in the pinctrl driver are properly called
> >> > (and actually do what they are supposed to do). I'm not sure we have
> >> > any in-tree user of a threaded IRQ attached to the pinctrl driver, so
> >> > it might have been broken for quite some time.
> >>
> >> What is certainly puzzling is that this driver doesn't seem to use
> >> threaded IRQs at all. Instead, it uses its own workqueue that seems
> >> to bypass the core IRQ subsystem altogether. So any guarantee we'd
> >> expect goes at of the window.
> >>
> >> It is also pretty unclear to me how whether the HW supports switch
> >> from edge to level signalling. The request_irq() call definitely asks
> >> for edge, and I don't know how you'd instruct the HW to change its
> >> signalling method (in general, it isn't possible).
> >
> > You are talking about the wfx driver? Be sure you read the right
> > version
> > of the driver. The ability to use a level-triggered IRQ does not exist
> > in
> > the stable tree. You have to check the "staging-next" tree from
> > Greg[1].
>
> Right. It still remains that in this (new) code, the threaded handler
> seems to kick a workqueue, and returns saying "I'm done". With a level
> triggered interrupt, this is likely to result in an interrupt storm if
> nothing masks the interrupt.
The core the threaded IRQ handler is in bh.c/wfx_bh_request_rx():
control_reg_read(wdev, &cur);
prev = atomic_xchg(&wdev->hif.ctrl_reg, cur);
complete(&wdev->hif.ctrl_ready);
queue_work(system_highpri_wq, &wdev->hif.bh);
The call to control_reg_read() acknowledge the IRQ (and get the length of
data to read). After this function, the IRQ line is down (then, indeed the
read of data is done from a workqueue).
Concerning the hard IRQ handler, we use the default IRQ handler, that
indeed just return IRQ_WAKE_THREAD. Since we also specify IRQF_ONESHOT,
the IRQ should be masked until the threaded IRQ ends.
(You may wonder why the driver does not call wfx_bh_request_rx() from a
regular IRQ handler. It is because control_reg_read() is not atomic.)
--
Jérôme Pouiller
_______________________________________________
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 v11 1/3] dt-bindings: i2c: npcm7xx: add NPCM I2C controller
From: Rob Herring @ 2020-05-21 14:08 UTC (permalink / raw)
To: Tali Perry
Cc: devicetree, tmaimon77, wsa, avifishman70, venture, openbmc,
kfting, brendanhiggins, ofery, linux-kernel, yuenn, robh+dt,
linux-i2c, andriy.shevchenko, linux-arm-kernel, benjaminfair
In-Reply-To: <20200520095113.185414-2-tali.perry1@gmail.com>
On Wed, 20 May 2020 12:51:11 +0300, Tali Perry wrote:
> Added device tree binding documentation for Nuvoton BMC
> NPCM I2C controller.
>
> Signed-off-by: Tali Perry <tali.perry1@gmail.com>
> ---
> .../bindings/i2c/nuvoton,npcm7xx-i2c.yaml | 62 +++++++++++++++++++
> 1 file changed, 62 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/i2c/nuvoton,npcm7xx-i2c.yaml
>
My bot found errors running 'make dt_binding_check' on your patch:
Error: Documentation/devicetree/bindings/i2c/nuvoton,npcm7xx-i2c.example.dts:22.28-29 syntax error
FATAL ERROR: Unable to parse input tree
scripts/Makefile.lib:312: recipe for target 'Documentation/devicetree/bindings/i2c/nuvoton,npcm7xx-i2c.example.dt.yaml' failed
make[1]: *** [Documentation/devicetree/bindings/i2c/nuvoton,npcm7xx-i2c.example.dt.yaml] Error 1
make[1]: *** Waiting for unfinished jobs....
Makefile:1300: recipe for target 'dt_binding_check' failed
make: *** [dt_binding_check] Error 2
See https://patchwork.ozlabs.org/patch/1294210
If you already ran 'make dt_binding_check' and didn't see the above
error(s), then make sure dt-schema is up to date:
pip3 install git+https://github.com/devicetree-org/dt-schema.git@master --upgrade
Please check and re-submit.
_______________________________________________
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 0/2] ARM: Allow either FLATMEM or SPARSEMEM on the multiplatform build
From: Mike Rapoport @ 2020-05-21 14:07 UTC (permalink / raw)
To: Russell King - ARM Linux admin
Cc: Florian Fainelli, Arnd Bergmann, Stephen Boyd, Kevin Cernekee,
Doug Berger, Gregory Fong, linux-arm-kernel
In-Reply-To: <20200521123327.GQ1059226@linux.ibm.com>
On Thu, May 21, 2020 at 03:33:29PM +0300, Mike Rapoport wrote:
> On Thu, May 21, 2020 at 01:03:08PM +0100, Russell King - ARM Linux admin wrote:
> > On Thu, May 21, 2020 at 11:18:23AM +0300, Mike Rapoport wrote:
> > > (resendig for the correct address and with mailing list cc'ed, sorry for
> > > the noise)
> > >
> > > Hi,
> > >
> > > Following the discussion at [1], I'm resending the patches that enable
> > > memory model selection in menuconfig and such.
> > >
> > > These patches do not change the way the configuration is generated from the
> > > defconfigs and they do not change explicit selection of SPARSEMEM for
> > > platforms that have "select ARCH_ENABLE_SPARSEMEM".
> > >
> > > The mere change is that when a user runs an interactive configuration they
> > > will be allowed to select between FLATMEM and SPARSMEM, which is not the
> > > case today.
> > >
> > > There is indeed some awkwardness in, e.g. removal of
> > > ARCH_SPARSEMEM_DEFAULT, but this is what memory model selection logic in
> > > mm/Kconfig imposes.
> > >
> > > For example, below is the diffs of the configurations generated with
> > > 'make rpc_defconfig' and 'make defconfig':
> > >
> > > $ diff -s old/rpc_defconfig new/rpc_defconfig
> > > Files old/rpc_defconfig and new/rpc_defconfig are identical
> > >
> > > $ diff -u old/defconfig new/defconfig
> > > --- old/defconfig 2020-05-20 17:51:01.832649705 +0300
> > > +++ new/defconfig 2020-05-20 18:15:21.084385880 +0300
> > > @@ -674,6 +674,9 @@
> > > CONFIG_AEABI=y
> > > # CONFIG_OABI_COMPAT is not set
> > > CONFIG_ARCH_HAS_HOLES_MEMORYMODEL=y
> > > +CONFIG_ARCH_SELECT_MEMORY_MODEL=y
> > > +CONFIG_ARCH_FLATMEM_ENABLE=y
> > > +CONFIG_ARCH_SPARSEMEM_ENABLE=y
> > > CONFIG_HAVE_ARCH_PFN_VALID=y
> > > CONFIG_HIGHMEM=y
> > > CONFIG_HIGHPTE=y
> > > @@ -1061,6 +1064,9 @@
> > > #
> > > # Memory Management options
> > > #
> > > +CONFIG_SELECT_MEMORY_MODEL=y
> > > +CONFIG_FLATMEM_MANUAL=y
> > > +# CONFIG_SPARSEMEM_MANUAL is not set
> > > CONFIG_FLATMEM=y
> > > CONFIG_FLAT_NODE_MEM_MAP=y
> > > CONFIG_ARCH_KEEP_MEMBLOCK=y
> >
> > Right, but the question is whether we want to offer flatmem for rpc.
> > It isn't allowed today, and so far no one has said why it's a
> > desirable change to make.
>
> With ARCH_RPC=y (or ARCH_SA1100 or ARCH_EP93XX for that matter)
> ARCH_MULTIPLATFORM=n which prevents ARCH_SELECT_MEMORY_MODEL from being
> enabled and since any of these machines explicitly selects
> ARCH_SPARSEMEM_ENABLE, the only available memory model would be
> SPARSEMEM.
>
> I played a bit with menuconfig and if any of the platforms requiring
> sparsemem is selected, the menu allowing the user to choose the memory
> model disappears.
Ah, when either of these patforms will become a part of the
multiplatform build, the only option for multiplatform build will be
sparsemem.
So it would be nice if somebody could check the cost of using sparsemem
vs flatmem, espessially on low end machines.
> > --
> > RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
> > FTTC for 0.8m (est. 1762m) line in suburbia: sync at 13.1Mbps down 424kbps up
--
Sincerely yours,
Mike.
_______________________________________________
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 06/11] irqchip/gic-v3: Configure SGIs as standard interrupts
From: Valentin Schneider @ 2020-05-21 14:04 UTC (permalink / raw)
To: Marc Zyngier
Cc: Sumit Garg, kernel-team, Russell King, Jason Cooper,
Catalin Marinas, linux-kernel, Thomas Gleixner, Will Deacon,
linux-arm-kernel
In-Reply-To: <20200519161755.209565-7-maz@kernel.org>
On 19/05/20 17:17, Marc Zyngier wrote:
> Change the way we deal with GICv3 SGIs by turning them into proper
> IRQs, and calling into the arch code to register the interrupt range
> instead of a callback.
>
> Signed-off-by: Marc Zyngier <maz@kernel.org>
> ---
> drivers/irqchip/irq-gic-v3.c | 91 +++++++++++++++++++++---------------
> 1 file changed, 53 insertions(+), 38 deletions(-)
>
> diff --git a/drivers/irqchip/irq-gic-v3.c b/drivers/irqchip/irq-gic-v3.c
> index 23d7c87da407..d57289057b75 100644
> --- a/drivers/irqchip/irq-gic-v3.c
> +++ b/drivers/irqchip/irq-gic-v3.c
> @@ -1163,10 +1142,36 @@ static void gic_raise_softirq(const struct cpumask *mask, unsigned int irq)
>
> static void gic_smp_init(void)
> {
> - set_smp_cross_call(gic_raise_softirq);
> + struct irq_fwspec sgi_fwspec = {
> + .fwnode = gic_data.fwnode,
> + };
> + int base_sgi;
> +
> cpuhp_setup_state_nocalls(CPUHP_AP_IRQ_GIC_STARTING,
> "irqchip/arm/gicv3:starting",
> gic_starting_cpu, NULL);
> +
> + if (is_of_node(gic_data.fwnode)) {
> + /* DT */
> + sgi_fwspec.param_count = 3;
> + sgi_fwspec.param[0] = GIC_IRQ_TYPE_SGI;
> + sgi_fwspec.param[1] = 0;
> + sgi_fwspec.param[2] = IRQ_TYPE_EDGE_RISING;
> + } else {
> + /* ACPI */
> + sgi_fwspec.param_count = 2;
> + sgi_fwspec.param[0] = 0;
> + sgi_fwspec.param[1] = IRQ_TYPE_EDGE_RISING;
> + }
> +
> + /* Register all 8 non-secure SGIs */
> + base_sgi = __irq_domain_alloc_irqs(gic_data.domain, -1, 8,
> + NUMA_NO_NODE, &sgi_fwspec,
> + false, NULL);
So IIUC using irq_reserve_ipi() would require us to have a separate IPI
domain, so instead here we can use a fwspec + the 'regular' GIC domain.
One thing I see is that by not going through irq_reserve_ipi(), we don't set
data->common->ipi_offset. I think this is all kzalloc'd, and we want an
offset of 0 so it all works out, but this feels somewhat fragile.
> + if (WARN_ON(base_sgi <= 0))
> + return;
> +
> + set_smp_ipi_range(base_sgi, 8);
> }
>
> static int gic_set_affinity(struct irq_data *d, const struct cpumask *mask_val,
> @@ -1289,6 +1296,13 @@ static int gic_irq_domain_map(struct irq_domain *d, unsigned int irq,
>
> switch (__get_intid_range(hw)) {
> case SGI_RANGE:
> + irq_set_percpu_devid(irq);
> + irq_domain_set_info(d, irq, hw, chip, d->host_data,
> + handle_percpu_devid_fasteoi_ipi,
> + NULL, NULL);
> + irq_set_status_flags(irq, IRQ_NOAUTOEN);
FWIW IRQ_NOAUTOEN is already set by irq_set_percpu_devid_flags(), so that's
not required. I know we do that for (E)PPIs, I think I already have a small
patch stashed somewhere regarding that.
> + break;
> +
> case PPI_RANGE:
> case EPPI_RANGE:
> irq_set_percpu_devid(irq);
_______________________________________________
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 04/11] ARM: Allow IPIs to be handled as normal interrupts
From: Valentin Schneider @ 2020-05-21 14:03 UTC (permalink / raw)
To: Russell King - ARM Linux admin
Cc: Sumit Garg, kernel-team, Jason Cooper, Marc Zyngier, linux-kernel,
Catalin Marinas, Thomas Gleixner, Will Deacon, linux-arm-kernel
In-Reply-To: <20200519222447.GJ1551@shell.armlinux.org.uk>
On 19/05/20 23:24, Russell King - ARM Linux admin wrote:
> On Tue, May 19, 2020 at 05:17:48PM +0100, Marc Zyngier wrote:
>> In order to deal with IPIs as normal interrupts, let's add
>> a new way to register them with the architecture code.
>>
>> set_smp_ipi_range() takes a range of interrupts, and allows
>> the arch code to request them as if the were normal interrupts.
>> A standard handler is then called by the core IRQ code to deal
>> with the IPI.
>>
>> This means that we don't need to call irq_enter/irq_exit, and
>> that we don't need to deal with set_irq_regs either. So let's
>> move the dispatcher into its own function, and leave handle_IPI()
>> as a compatibility function.
>>
>> On the sending side, let's make use of ipi_send_mask, which
>> already exists for this purpose.
>
> You say nothing about the nesting of irq_enter() and irq_exit()
> for scheduler_ipi().
>
> Given that lockdep introduced the requirement that hard IRQs can't
> be nested, are we sure that calling irq_exit() twice is safe?
>
> Looking at irqtime_account_irq(), it seems that will cause double-
> accounting of in-interrupt time, since we will increment
> irq_start_time by just over twice the the period spent handling
> the IPI.
>
> I think the rest of irq_exit() should be safe, but still, this
> behaviour should be documented at the very least, if not avoided.
>
x86 does the same (though IIUC only when tracing reschedule IPI's), and
MIPS has the same issue as it also uses generic IRQ IPI's - so although
it's not ideal, I think we can live with it.
_______________________________________________
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/11] arm64: Allow IPIs to be handled as normal interrupts
From: Valentin Schneider @ 2020-05-21 14:03 UTC (permalink / raw)
To: Marc Zyngier
Cc: Sumit Garg, kernel-team, Russell King, Jason Cooper,
Catalin Marinas, linux-kernel, Thomas Gleixner, Will Deacon,
linux-arm-kernel
In-Reply-To: <20200519161755.209565-4-maz@kernel.org>
On 19/05/20 17:17, Marc Zyngier wrote:
> In order to deal with IPIs as normal interrupts, let's add
> a new way to register them with the architecture code.
>
> set_smp_ipi_range() takes a range of interrupts, and allows
> the arch code to request them as if the were normal interrupts.
^^^
s/the/they/
> A standard handler is then called by the core IRQ code to deal
> with the IPI.
>
> This means that we don't need to call irq_enter/irq_exit, and
> that we don't need to deal with set_irq_regs either. So let's
> move the dispatcher into its own function, and leave handle_IPI()
> as a compatibility function.
>
> On the sending side, let's make use of ipi_send_mask, which
> already exists for this purpose.
>
> Signed-off-by: Marc Zyngier <maz@kernel.org>
> ---
> arch/arm64/Kconfig | 1 +
> arch/arm64/include/asm/smp.h | 5 ++
> arch/arm64/kernel/smp.c | 92 +++++++++++++++++++++++++++++++-----
> 3 files changed, 86 insertions(+), 12 deletions(-)
>
> diff --git a/arch/arm64/kernel/smp.c b/arch/arm64/kernel/smp.c
> index 061f60fe452f..93ba0025e7b9 100644
> --- a/arch/arm64/kernel/smp.c
> +++ b/arch/arm64/kernel/smp.c
> @@ -247,6 +254,8 @@ asmlinkage notrace void secondary_start_kernel(void)
> */
> notify_cpu_starting(cpu);
>
> + ipi_setup(cpu);
> +
> store_cpu_topology(cpu);
> numa_add_cpu(cpu);
>
> @@ -374,6 +383,8 @@ void cpu_die(void)
>
> local_daif_mask();
>
> + ipi_teardown(cpu);
> +
Would it make sense to move it up to say __cpu_disable()? I'm thinking it
would make sense to bunch this up with the toggling of the cpu_online_mask
bit, and FWIW it'd match with the comment atop the cpuhp callsite.
Once the CPU is set as offline, all it has left to do is to go die in
do_idle(), so AFAICT we can do that IPI teardown anywhere inbetween.
> /* Tell __cpu_die() that this CPU is now safe to dispose of */
> (void)cpu_report_death();
>
_______________________________________________
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 V1 RESEND 1/3] perf/imx_ddr: Add system PMU identifier for userspace
From: John Garry @ 2020-05-21 14:00 UTC (permalink / raw)
To: Will Deacon, Rob Herring
Cc: Mark Rutland, devicetree, Joakim Zhang,
linux-kernel@vger.kernel.org, NXP Linux Team, Shawn Guo,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE
In-Reply-To: <20200521130415.GB5949@willie-the-truck>
On 21/05/2020 14:04, Will Deacon wrote:
> On Wed, May 20, 2020 at 09:23:41AM -0600, Rob Herring wrote:
>> On Wed, May 20, 2020 at 1:33 AM Will Deacon <will@kernel.org> wrote:
>>>
>>> On Tue, May 19, 2020 at 12:51:25PM -0600, Rob Herring wrote:
>>>> On Tue, May 12, 2020 at 03:31:13PM +0800, Joakim Zhang wrote:
>>>>> +static ssize_t ddr_perf_identifier_show(struct device *dev,
>>>>> + struct device_attribute *attr,
>>>>> + char *page)
>>>>> +{
>>>>> + struct ddr_pmu *pmu = dev_get_drvdata(dev);
>>>>> +
>>>>> + return sprintf(page, "%s\n", pmu->devtype_data->identifier);
>>>>
>>>> Why do we need yet another way to identify the SoC from userspace?
>>>
>>> I also really dislike this. What's the preferred way to identify the SoC
>>> from userspace?
>>
>> /proc/cpuinfo? ;)
>
> The *SoC*!
>
>> For an non-firmware specific case, I'd say soc_device should be. I'd
>> guess ACPI systems don't use it and for them it's dmidecode typically.
>> The other problem I have with soc_device is it is optional.
>
Hi Will,
> John -- what do you think about using soc_device to expose this information,
> with ACPI systems using DMI data instead?
Generally I don't think that DMI is reliable, and I saw this as the
least preferred choice. I'm looking at the sysfs DMI info for my dev
board, and I don't even see anything like a SoC identifier.
As for the event_source device sysfs identifier file, it would not
always contain effectively the same as the SoC ID.
Certain PMUs which I'm interested in plan to have probe-able
identification info available in future.
Thanks,
John
_______________________________________________
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 v8 04/14] media: platform: Change the fixed device node number to unfixed value
From: Tomasz Figa @ 2020-05-21 13:59 UTC (permalink / raw)
To: Xia Jiang
Cc: drinkcat, devicetree, mojahsu, srv_heupstream, Rick Chang,
senozhatsky, linux-kernel, maoguang.meng, Mauro Carvalho Chehab,
sj.huang, Rob Herring, Matthias Brugger, Hans Verkuil,
linux-mediatek, Marek Szyprowski, linux-arm-kernel, linux-media
In-Reply-To: <20200403094033.8288-5-xia.jiang@mediatek.com>
Hi Xia,
On Fri, Apr 03, 2020 at 05:40:23PM +0800, Xia Jiang wrote:
> Change device node number from 3 to -1 because that the driver will
> also support jpeg encoder.
>
Thanks for the patch. The change is correct, but I think the commit
message doesn't really explain the real reason for it. Perhaps something
like
"The driver can be instantiated multiple times, e.g. for a decoder and
an encoder. Moreover, other drivers could coexist on the same system.
This makes the static video node number assignment pointless, so switch
to automatic assignment instead."
WDYT?
Best regards,
Tomasz
_______________________________________________
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] perf: arm_dsu: Support DSU ACPI devices.
From: Sudeep Holla @ 2020-05-21 13:55 UTC (permalink / raw)
To: Tuan Phan
Cc: Mark Rutland, linux-kernel, Sudeep Holla, patches, Will Deacon,
linux-arm-kernel
In-Reply-To: <1589229160-18558-1-git-send-email-tuanphan@os.amperecomputing.com>
On Mon, May 11, 2020 at 01:32:40PM -0700, Tuan Phan wrote:
> Add ACPI node probing device support. Each DSU ACPI node
> defines a "cpus" package with a per cpu MPIDR element.
>
> Signed-off-by: Tuan Phan <tuanphan@os.amperecomputing.com>
> ---
> Changes in v2:
> - Removed IRQF_SHARED.
> - Fixed ACPI runtime detection.
>
> The ACPI binding spec for DSU ACPI node is under beta and located
> in ARM server group under project "ACPI on ARM".
>
> drivers/perf/arm_dsu_pmu.c | 71 ++++++++++++++++++++++++++++++++++++++++------
> 1 file changed, 63 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/perf/arm_dsu_pmu.c b/drivers/perf/arm_dsu_pmu.c
> index 70968c8..784d177 100644
> --- a/drivers/perf/arm_dsu_pmu.c
> +++ b/drivers/perf/arm_dsu_pmu.c
> @@ -11,6 +11,7 @@
> #define DRVNAME PMUNAME "_pmu"
> #define pr_fmt(fmt) DRVNAME ": " fmt
>
> +#include <linux/acpi.h>
> #include <linux/bitmap.h>
> #include <linux/bitops.h>
> #include <linux/bug.h>
> @@ -603,18 +604,21 @@ static struct dsu_pmu *dsu_pmu_alloc(struct platform_device *pdev)
> }
>
> /**
> - * dsu_pmu_dt_get_cpus: Get the list of CPUs in the cluster.
> + * dsu_pmu_dt_get_cpus: Get the list of CPUs in the cluster
> + * from device tree.
> */
> -static int dsu_pmu_dt_get_cpus(struct device_node *dev, cpumask_t *mask)
> +static int dsu_pmu_dt_get_cpus(struct platform_device *pdev)
> {
> int i = 0, n, cpu;
> struct device_node *cpu_node;
> + struct dsu_pmu *dsu_pmu =
> + (struct dsu_pmu *) platform_get_drvdata(pdev);
>
> - n = of_count_phandle_with_args(dev, "cpus", NULL);
> + n = of_count_phandle_with_args(pdev->dev.of_node, "cpus", NULL);
> if (n <= 0)
> return -ENODEV;
> for (; i < n; i++) {
> - cpu_node = of_parse_phandle(dev, "cpus", i);
> + cpu_node = of_parse_phandle(pdev->dev.of_node, "cpus", i);
> if (!cpu_node)
> break;
> cpu = of_cpu_node_to_id(cpu_node);
> @@ -626,11 +630,54 @@ static int dsu_pmu_dt_get_cpus(struct device_node *dev, cpumask_t *mask)
> */
> if (cpu < 0)
> continue;
> - cpumask_set_cpu(cpu, mask);
> + cpumask_set_cpu(cpu, &dsu_pmu->associated_cpus);
> }
> return 0;
> }
>
> +/**
> + * dsu_pmu_acpi_get_cpus: Get the list of CPUs in the cluster
> + * from ACPI.
> + */
> +static int dsu_pmu_acpi_get_cpus(struct platform_device *pdev)
> +{
> + int i, cpu, ret;
> + const union acpi_object *obj;
> + struct acpi_device *adev = ACPI_COMPANION(&pdev->dev);
> + struct dsu_pmu *dsu_pmu =
> + (struct dsu_pmu *) platform_get_drvdata(pdev);
> +
> + ret = acpi_dev_get_property(adev, "cpus", ACPI_TYPE_PACKAGE, &obj);
I don't see any property "cpus" in the document:
DEN 0093 A (Generic ACPI for Arm Components 1.0) [1]
Is there any newer updates that I need to look at ?
--
Regards,
Sudeep
[1] https://static.docs.arm.com/den0093/a/DEN0093_ACPI_Arm_Components_1.0.pdf
_______________________________________________
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] hwrng: exynos - fix runtime pm imbalance on error
From: Lukasz Stelmach @ 2020-05-21 13:52 UTC (permalink / raw)
To: Dinghao Liu
Cc: linux-samsung-soc, Herbert Xu, Arnd Bergmann, Greg Kroah-Hartman,
kjlu, linux-kernel, Krzysztof Kozlowski, Kukjin Kim, linux-crypto,
Matt Mackall, linux-arm-kernel
In-Reply-To: <20200520131911.16813-1-dinghao.liu@zju.edu.cn>
[-- Attachment #1.1: Type: text/plain, Size: 1221 bytes --]
It was <2020-05-20 śro 21:19>, when Dinghao Liu wrote:
> pm_runtime_get_sync() increments the runtime PM usage counter even
> the call returns an error code. Thus a pairing decrement is needed
> on the error handling path to keep the counter balanced.
>
> Signed-off-by: Dinghao Liu <dinghao.liu@zju.edu.cn>
> ---
> drivers/char/hw_random/exynos-trng.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/drivers/char/hw_random/exynos-trng.c b/drivers/char/hw_random/exynos-trng.c
> index 8e1fe3f8dd2d..133e017db577 100644
> --- a/drivers/char/hw_random/exynos-trng.c
> +++ b/drivers/char/hw_random/exynos-trng.c
> @@ -165,9 +165,8 @@ static int exynos_trng_probe(struct platform_device *pdev)
> clk_disable_unprepare(trng->clk);
>
> err_clock:
> - pm_runtime_put_sync(&pdev->dev);
> -
> err_pm_get:
> + pm_runtime_put_sync(&pdev->dev);
> pm_runtime_disable(&pdev->dev);
>
> return ret;
You are right. I will accept the patch, when you remove the err_clock
label and and change goto instructions above to point to
err_pm_get. There is no point in having two labels.
Thank you.
--
Łukasz Stelmach
Samsung R&D Institute Poland
Samsung Electronics
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
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 v8 03/14] media: platform: Improve getting and requesting irq flow for bug fixing
From: Tomasz Figa @ 2020-05-21 13:47 UTC (permalink / raw)
To: Xia Jiang
Cc: drinkcat, devicetree, mojahsu, srv_heupstream, Rick Chang,
senozhatsky, linux-kernel, maoguang.meng, Mauro Carvalho Chehab,
sj.huang, Rob Herring, Matthias Brugger, Hans Verkuil,
linux-mediatek, Marek Szyprowski, linux-arm-kernel, linux-media
In-Reply-To: <20200403094033.8288-4-xia.jiang@mediatek.com>
On Fri, Apr 03, 2020 at 05:40:22PM +0800, Xia Jiang wrote:
> Delete platform_get_resource operation for irq.
> Return actual value rather than EINVAL when fail to get and request
> irq.
>
> Signed-off-by: Xia Jiang <xia.jiang@mediatek.com>
> ---
> drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c | 7 ++-----
> 1 file changed, 2 insertions(+), 5 deletions(-)
>
Reviewed-by: Tomasz Figa <tfiga@chromium.org>
Best regards,
Tomasz
_______________________________________________
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 v8 02/14] media: platform: Improve queue set up flow for bug fixing
From: Tomasz Figa @ 2020-05-21 13:46 UTC (permalink / raw)
To: Xia Jiang
Cc: drinkcat, devicetree, mojahsu, srv_heupstream, Rick Chang,
senozhatsky, linux-kernel, maoguang.meng, Mauro Carvalho Chehab,
sj.huang, Rob Herring, Matthias Brugger, Hans Verkuil,
linux-mediatek, Marek Szyprowski, linux-arm-kernel, linux-media
In-Reply-To: <20200403094033.8288-3-xia.jiang@mediatek.com>
On Fri, Apr 03, 2020 at 05:40:21PM +0800, Xia Jiang wrote:
> Add checking created buffer size follow in mtk_jpeg_queue_setup().
>
> Signed-off-by: Xia Jiang <xia.jiang@mediatek.com>
> ---
> v8: no changes
> ---
> drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c | 7 +++++++
> 1 file changed, 7 insertions(+)
>
Reviewed-by: Tomasz Figa <tfiga@chromium.org>
Best regards,
Tomasz
_______________________________________________
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 v8 01/14] media: platform: Improve subscribe event flow for bug fixing
From: Tomasz Figa @ 2020-05-21 13:45 UTC (permalink / raw)
To: Xia Jiang
Cc: drinkcat, devicetree, mojahsu, srv_heupstream, Rick Chang,
senozhatsky, linux-kernel, maoguang.meng, Mauro Carvalho Chehab,
sj.huang, Rob Herring, Matthias Brugger, Hans Verkuil,
linux-mediatek, Marek Szyprowski, linux-arm-kernel, linux-media
In-Reply-To: <20200403094033.8288-2-xia.jiang@mediatek.com>
Hi Xia,
On Fri, Apr 03, 2020 at 05:40:20PM +0800, Xia Jiang wrote:
> Let v4l2_ctrl_subscribe_event() do the job for other types except
> V4L2_EVENT_SOURCE_CHANGE.
>
> Signed-off-by: Xia Jiang <xia.jiang@mediatek.com>
> ---
> v8: no changes
> ---
> drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
Reviewed-by: Tomasz Figa <tfiga@chromium.org>
Best regards,
Tomasz
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: Possible race while masking IRQ on Allwinner A20
From: Marc Zyngier @ 2020-05-21 13:39 UTC (permalink / raw)
To: Jérôme Pouiller
Cc: Marc Dorval, Chen-Yu Tsai, Thomas Gleixner, Maxime Ripard,
linux-arm-kernel
In-Reply-To: <4055631.Zo4jul7Flx@pc-42>
On 2020-05-21 14:28, Jérôme Pouiller wrote:
> On Thursday 21 May 2020 10:02:48 CEST Marc Zyngier wrote:
>> On 2020-05-21 08:26, Maxime Ripard wrote:
>> > On Tue, May 19, 2020 at 10:59:26AM +0200, Jérôme Pouiller wrote:
> [...]
>> >> Nevermind, I tried to use a level triggered IRQ (and my request is on
>> >> this part). As you can see in the wfx driver (in bus_sdio.c and
>> >> bh.c), I use a threaded IRQ for that. Unfortunately, I receive some IRQs
>> >> twice.
>> >> I traced the problem, I get:
>> >>
>> >> QSGRenderThread-981 [000] d.h. 247.485524: irq_handler_entry: irq=80 name=wfx
>> >> QSGRenderThread-981 [000] d.h. 247.485547: irq_handler_exit: irq=80 ret=handled
>> >> QSGRenderThread-981 [000] d.h. 247.485600: irq_handler_entry: irq=80 name=wfx
>> >> QSGRenderThread-981 [000] d.h. 247.485606: irq_handler_exit: irq=80 ret=handled
>> >> irq/80-wfx-260 [001] .... 247.485828: io_read32: CONTROL: 0000f046
>> >> irq/80-wfx-260 [001] .... 247.486072: io_read32: CONTROL: 0000f046
>> >> kworker/1:1H-116 [001] .... 247.486214: io_read: QUEUE: 8b 00 84 18 00 00 00 00 01 00 15 82 2b 48 01 1e 88 42 30 00 08 6b d7 c3 53 e0 28 80 88 67 32 af ... (192 bytes)
>> >> kworker/1:1H-116 [001] .... 247.493097: io_read: QUEUE: 00 00 00 00 00 00 00 00 06 06 00 6a 3f 95 00 60 00 00 00 00 08 62 00 00 01 00 5e 00 00 07 28 80 ... (192 bytes)
>> >> [...]
>> >>
>> >> On this trace, we can see:
>> >> - the hard IRQ handler
>> >> - the IRQ acknowledge from the thread irq/80-wfx-260
>> >> - the access to the data from kworker/1:1H-116
>> >>
>> >> As far as I understand, the first call to the IRQ handler (at
>> >> 247.485524) should mask the IRQ 80. So, the second IRQ (at 247.485600)
>> >> should not happen and the thread irq/80 should be triggered only once.
>> >>
>> >> Do you have any idea of what is going wrong with this IRQ?
>> >
>> > That's pretty weird indeed. My first guess was that you weren't using
>> > IRQF_ONESHOT, but it looks like you are. My next lead would be to see
>> > if the mask / unmask hooks in the pinctrl driver are properly called
>> > (and actually do what they are supposed to do). I'm not sure we have
>> > any in-tree user of a threaded IRQ attached to the pinctrl driver, so
>> > it might have been broken for quite some time.
>>
>> What is certainly puzzling is that this driver doesn't seem to use
>> threaded IRQs at all. Instead, it uses its own workqueue that seems
>> to bypass the core IRQ subsystem altogether. So any guarantee we'd
>> expect goes at of the window.
>>
>> It is also pretty unclear to me how whether the HW supports switch
>> from edge to level signalling. The request_irq() call definitely asks
>> for edge, and I don't know how you'd instruct the HW to change its
>> signalling method (in general, it isn't possible).
>
> You are talking about the wfx driver? Be sure you read the right
> version
> of the driver. The ability to use a level-triggered IRQ does not exist
> in
> the stable tree. You have to check the "staging-next" tree from
> Greg[1].
Right. It still remains that in this (new) code, the threaded handler
seems to kick a workqueue, and returns saying "I'm done". With a level
triggered interrupt, this is likely to result in an interrupt storm if
nothing masks the interrupt.
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 v6 2/3] arm64: Move fault address and fault code into kernel_siginfo
From: kbuild test robot @ 2020-05-21 13:34 UTC (permalink / raw)
To: Peter Collingbourne, Catalin Marinas, Evgenii Stepanov,
Kostya Serebryany, Vincenzo Frascino, Dave Martin, Will Deacon,
Oleg Nesterov, Eric W. Biederman
Cc: kbuild-all, Andrey Konovalov, Kevin Brodsky, clang-built-linux,
Peter Collingbourne, Linux ARM, Richard Henderson
In-Reply-To: <20200521022943.195898-3-pcc@google.com>
[-- Attachment #1: Type: text/plain, Size: 9832 bytes --]
Hi Peter,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on arm-perf/for-next/perf]
[also build test WARNING on linus/master v5.7-rc6]
[cannot apply to arm64/for-next/core next-20200519]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system. BTW, we also suggest to use '--base' option to specify the
base tree in git format-patch, please see https://stackoverflow.com/a/37406982]
url: https://github.com/0day-ci/linux/commits/Peter-Collingbourne/arm64-Expose-FAR_EL1-tag-bits-in-sigcontext/20200521-103345
base: https://git.kernel.org/pub/scm/linux/kernel/git/will/linux.git for-next/perf
config: arm64-randconfig-r005-20200520 (attached as .config)
compiler: clang version 11.0.0 (https://github.com/llvm/llvm-project 3393cc4cebf9969db94dc424b7a2b6195589c33b)
reproduce (this is a W=1 build):
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# install arm64 cross compiling tool for clang build
# apt-get install binutils-aarch64-linux-gnu
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=arm64
If you fix the issue, kindly add following tag as appropriate
Reported-by: kbuild test robot <lkp@intel.com>
All warnings (new ones prefixed by >>, old ones prefixed by <<):
>> arch/arm64/kernel/traps.c:283:55: warning: format specifies type 'unsigned int' but the argument has type 'unsigned long' [-Wformat]
WARN(1, "ESR 0x%x is not DABT or IABT from EL0n", esr);
~~ ^~~
%lx
include/asm-generic/bug.h:124:29: note: expanded from macro 'WARN'
__WARN_printf(TAINT_WARN, format); ^~~~~~
include/asm-generic/bug.h:92:17: note: expanded from macro '__WARN_printf'
__warn_printk(arg); ^~~
arch/arm64/kernel/traps.c:826:26: warning: initializer overrides prior initialization of this subobject [-Winitializer-overrides]
[ESR_ELx_EC_UNKNOWN] = "Unknown/Uncategorized",
^~~~~~~~~~~~~~~~~~~~~~~
arch/arm64/kernel/traps.c:825:28: note: previous initialization is here
[0 ... ESR_ELx_EC_MAX] = "UNRECOGNIZED EC",
^~~~~~~~~~~~~~~~~
arch/arm64/kernel/traps.c:827:22: warning: initializer overrides prior initialization of this subobject [-Winitializer-overrides]
[ESR_ELx_EC_WFx] = "WFI/WFE",
^~~~~~~~~
arch/arm64/kernel/traps.c:825:28: note: previous initialization is here
[0 ... ESR_ELx_EC_MAX] = "UNRECOGNIZED EC",
^~~~~~~~~~~~~~~~~
arch/arm64/kernel/traps.c:828:26: warning: initializer overrides prior initialization of this subobject [-Winitializer-overrides]
[ESR_ELx_EC_CP15_32] = "CP15 MCR/MRC",
^~~~~~~~~~~~~~
arch/arm64/kernel/traps.c:825:28: note: previous initialization is here
[0 ... ESR_ELx_EC_MAX] = "UNRECOGNIZED EC",
^~~~~~~~~~~~~~~~~
arch/arm64/kernel/traps.c:829:26: warning: initializer overrides prior initialization of this subobject [-Winitializer-overrides]
[ESR_ELx_EC_CP15_64] = "CP15 MCRR/MRRC",
^~~~~~~~~~~~~~~~
arch/arm64/kernel/traps.c:825:28: note: previous initialization is here
[0 ... ESR_ELx_EC_MAX] = "UNRECOGNIZED EC",
^~~~~~~~~~~~~~~~~
arch/arm64/kernel/traps.c:830:26: warning: initializer overrides prior initialization of this subobject [-Winitializer-overrides]
[ESR_ELx_EC_CP14_MR] = "CP14 MCR/MRC",
^~~~~~~~~~~~~~
arch/arm64/kernel/traps.c:825:28: note: previous initialization is here
[0 ... ESR_ELx_EC_MAX] = "UNRECOGNIZED EC",
^~~~~~~~~~~~~~~~~
arch/arm64/kernel/traps.c:831:26: warning: initializer overrides prior initialization of this subobject [-Winitializer-overrides]
[ESR_ELx_EC_CP14_LS] = "CP14 LDC/STC",
^~~~~~~~~~~~~~
arch/arm64/kernel/traps.c:825:28: note: previous initialization is here
[0 ... ESR_ELx_EC_MAX] = "UNRECOGNIZED EC",
^~~~~~~~~~~~~~~~~
arch/arm64/kernel/traps.c:832:27: warning: initializer overrides prior initialization of this subobject [-Winitializer-overrides]
[ESR_ELx_EC_FP_ASIMD] = "ASIMD",
^~~~~~~
arch/arm64/kernel/traps.c:825:28: note: previous initialization is here
[0 ... ESR_ELx_EC_MAX] = "UNRECOGNIZED EC",
^~~~~~~~~~~~~~~~~
arch/arm64/kernel/traps.c:833:26: warning: initializer overrides prior initialization of this subobject [-Winitializer-overrides]
[ESR_ELx_EC_CP10_ID] = "CP10 MRC/VMRS",
^~~~~~~~~~~~~~~
arch/arm64/kernel/traps.c:825:28: note: previous initialization is here
[0 ... ESR_ELx_EC_MAX] = "UNRECOGNIZED EC",
^~~~~~~~~~~~~~~~~
arch/arm64/kernel/traps.c:834:22: warning: initializer overrides prior initialization of this subobject [-Winitializer-overrides]
[ESR_ELx_EC_PAC] = "PAC",
^~~~~
arch/arm64/kernel/traps.c:825:28: note: previous initialization is here
[0 ... ESR_ELx_EC_MAX] = "UNRECOGNIZED EC",
^~~~~~~~~~~~~~~~~
arch/arm64/kernel/traps.c:835:26: warning: initializer overrides prior initialization of this subobject [-Winitializer-overrides]
[ESR_ELx_EC_CP14_64] = "CP14 MCRR/MRRC",
^~~~~~~~~~~~~~~~
arch/arm64/kernel/traps.c:825:28: note: previous initialization is here
[0 ... ESR_ELx_EC_MAX] = "UNRECOGNIZED EC",
^~~~~~~~~~~~~~~~~
arch/arm64/kernel/traps.c:836:22: warning: initializer overrides prior initialization of this subobject [-Winitializer-overrides]
[ESR_ELx_EC_ILL] = "PSTATE.IL",
^~~~~~~~~~~
arch/arm64/kernel/traps.c:825:28: note: previous initialization is here
[0 ... ESR_ELx_EC_MAX] = "UNRECOGNIZED EC",
^~~~~~~~~~~~~~~~~
arch/arm64/kernel/traps.c:837:24: warning: initializer overrides prior initialization of this subobject [-Winitializer-overrides]
[ESR_ELx_EC_SVC32] = "SVC (AArch32)",
^~~~~~~~~~~~~~~
arch/arm64/kernel/traps.c:825:28: note: previous initialization is here
[0 ... ESR_ELx_EC_MAX] = "UNRECOGNIZED EC",
^~~~~~~~~~~~~~~~~
arch/arm64/kernel/traps.c:838:24: warning: initializer overrides prior initialization of this subobject [-Winitializer-overrides]
[ESR_ELx_EC_HVC32] = "HVC (AArch32)",
^~~~~~~~~~~~~~~
arch/arm64/kernel/traps.c:825:28: note: previous initialization is here
[0 ... ESR_ELx_EC_MAX] = "UNRECOGNIZED EC",
^~~~~~~~~~~~~~~~~
arch/arm64/kernel/traps.c:839:24: warning: initializer overrides prior initialization of this subobject [-Winitializer-overrides]
[ESR_ELx_EC_SMC32] = "SMC (AArch32)",
^~~~~~~~~~~~~~~
arch/arm64/kernel/traps.c:825:28: note: previous initialization is here
[0 ... ESR_ELx_EC_MAX] = "UNRECOGNIZED EC",
^~~~~~~~~~~~~~~~~
arch/arm64/kernel/traps.c:840:24: warning: initializer overrides prior initialization of this subobject [-Winitializer-overrides]
[ESR_ELx_EC_SVC64] = "SVC (AArch64)",
^~~~~~~~~~~~~~~
arch/arm64/kernel/traps.c:825:28: note: previous initialization is here
[0 ... ESR_ELx_EC_MAX] = "UNRECOGNIZED EC",
^~~~~~~~~~~~~~~~~
arch/arm64/kernel/traps.c:841:24: warning: initializer overrides prior initialization of this subobject [-Winitializer-overrides]
vim +283 arch/arm64/kernel/traps.c
236
237 static unsigned long esr_to_error_code(unsigned long esr, unsigned long far)
238 {
239 /*
240 * If the faulting address is in the kernel, we must sanitize the ESR.
241 * From userspace's point of view, kernel-only mappings don't exist
242 * at all, so we report them as level 0 translation faults.
243 * (This is not quite the way that "no mapping there at all" behaves:
244 * an alignment fault not caused by the memory type would take
245 * precedence over translation fault for a real access to empty
246 * space. Unfortunately we can't easily distinguish "alignment fault
247 * not caused by memory type" from "alignment fault caused by memory
248 * type", so we ignore this wrinkle and just return the translation
249 * fault.)
250 */
251 if (!is_ttbr0_addr(untagged_addr(far))) {
252 switch (ESR_ELx_EC(esr)) {
253 case ESR_ELx_EC_DABT_LOW:
254 /*
255 * These bits provide only information about the
256 * faulting instruction, which userspace knows already.
257 * We explicitly clear bits which are architecturally
258 * RES0 in case they are given meanings in future.
259 * We always report the ESR as if the fault was taken
260 * to EL1 and so ISV and the bits in ISS[23:14] are
261 * clear. (In fact it always will be a fault to EL1.)
262 */
263 esr &= ESR_ELx_EC_MASK | ESR_ELx_IL |
264 ESR_ELx_CM | ESR_ELx_WNR;
265 esr |= ESR_ELx_FSC_FAULT;
266 break;
267 case ESR_ELx_EC_IABT_LOW:
268 /*
269 * Claim a level 0 translation fault.
270 * All other bits are architecturally RES0 for faults
271 * reported with that DFSC value, so we clear them.
272 */
273 esr &= ESR_ELx_EC_MASK | ESR_ELx_IL;
274 esr |= ESR_ELx_FSC_FAULT;
275 break;
276 default:
277 /*
278 * This should never happen (entry.S only brings us
279 * into this code for insn and data aborts from a lower
280 * exception level). Fail safe by not providing an ESR
281 * context record at all.
282 */
> 283 WARN(1, "ESR 0x%x is not DABT or IABT from EL0\n", esr);
284 esr = 0;
285 break;
286 }
287 }
288
289 if (is_compat_task()) {
290 /* Use the compat FSR WnR */
291 return !!(esr & ESR_ELx_WNR) << FSR_WRITE_SHIFT;
292 }
293
294 return esr;
295 }
296
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 47550 bytes --]
[-- Attachment #3: Type: text/plain, Size: 176 bytes --]
_______________________________________________
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 03/14] PCI: cadence: Add support to use custom read and write accessors
From: Kishon Vijay Abraham I @ 2020-05-21 13:33 UTC (permalink / raw)
To: Rob Herring
Cc: devicetree, Lorenzo Pieralisi, Arnd Bergmann, Greg Kroah-Hartman,
linux-kernel, Tom Joseph, linux-pci, Bjorn Helgaas, linux-omap,
linux-arm-kernel
In-Reply-To: <20200520220724.GA636352@bogus>
Hi Rob,
On 5/21/2020 3:37 AM, Rob Herring wrote:
> On Wed, May 06, 2020 at 08:44:18PM +0530, Kishon Vijay Abraham I wrote:
>> Add support to use custom read and write accessors. Platforms that
>> don't support half word or byte access or any other constraint
>> while accessing registers can use this feature to populate custom
>> read and write accessors. These custom accessors are used for both
>> standard register access and configuration space register access of
>> the PCIe host bridge.
>>
>> Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
>> ---
>> drivers/pci/controller/cadence/pcie-cadence.h | 107 +++++++++++++++---
>> 1 file changed, 94 insertions(+), 13 deletions(-)
>
> Actually, take back my R-by...
>
>>
>> diff --git a/drivers/pci/controller/cadence/pcie-cadence.h b/drivers/pci/controller/cadence/pcie-cadence.h
>> index df14ad002fe9..70b6b25153e8 100644
>> --- a/drivers/pci/controller/cadence/pcie-cadence.h
>> +++ b/drivers/pci/controller/cadence/pcie-cadence.h
>> @@ -223,6 +223,11 @@ enum cdns_pcie_msg_routing {
>> MSG_ROUTING_GATHER,
>> };
>>
>> +struct cdns_pcie_ops {
>> + u32 (*read)(void __iomem *addr, int size);
>> + void (*write)(void __iomem *addr, int size, u32 value);
>> +};
>> +
>> /**
>> * struct cdns_pcie - private data for Cadence PCIe controller drivers
>> * @reg_base: IO mapped register base
>> @@ -239,7 +244,7 @@ struct cdns_pcie {
>> int phy_count;
>> struct phy **phy;
>> struct device_link **link;
>> - const struct cdns_pcie_common_ops *ops;
>> + const struct cdns_pcie_ops *ops;
>> };
>>
>> /**
>> @@ -299,69 +304,145 @@ struct cdns_pcie_ep {
>> /* Register access */
>> static inline void cdns_pcie_writeb(struct cdns_pcie *pcie, u32 reg, u8 value)
>> {
>> - writeb(value, pcie->reg_base + reg);
>> + void __iomem *addr = pcie->reg_base + reg;
>> +
>> + if (pcie->ops && pcie->ops->write) {
>> + pcie->ops->write(addr, 0x1, value);
>> + return;
>> + }
>> +
>> + writeb(value, addr);
>> }
>>
>> static inline void cdns_pcie_writew(struct cdns_pcie *pcie, u32 reg, u16 value)
>> {
>> - writew(value, pcie->reg_base + reg);
>> + void __iomem *addr = pcie->reg_base + reg;
>> +
>> + if (pcie->ops && pcie->ops->write) {
>> + pcie->ops->write(addr, 0x2, value);
>> + return;
>> + }
>> +
>> + writew(value, addr);
>> }
>
> cdns_pcie_writeb and cdns_pcie_writew are used, so remove them.
>
>>
>> static inline void cdns_pcie_writel(struct cdns_pcie *pcie, u32 reg, u32 value)
>> {
>> - writel(value, pcie->reg_base + reg);
>> + void __iomem *addr = pcie->reg_base + reg;
>> +
>> + if (pcie->ops && pcie->ops->write) {
>> + pcie->ops->write(addr, 0x4, value);
>> + return;
>> + }
>> +
>> + writel(value, addr);
>
> writel isn't broken for you, so you don't need this either.
>
>> }
>>
>> static inline u32 cdns_pcie_readl(struct cdns_pcie *pcie, u32 reg)
>> {
>> - return readl(pcie->reg_base + reg);
>> + void __iomem *addr = pcie->reg_base + reg;
>> +
>> + if (pcie->ops && pcie->ops->read)
>> + return pcie->ops->read(addr, 0x4);
>> +
>> + return readl(addr);
>
> And neither is readl.
Sure, I'll remove all the unused functions and avoid using ops for readl and
writel.
>
>> }
>>
>> /* Root Port register access */
>> static inline void cdns_pcie_rp_writeb(struct cdns_pcie *pcie,
>> u32 reg, u8 value)
>> {
>> - writeb(value, pcie->reg_base + CDNS_PCIE_RP_BASE + reg);
>> + void __iomem *addr = pcie->reg_base + CDNS_PCIE_RP_BASE + reg;
>> +
>> + if (pcie->ops && pcie->ops->write) {
>> + pcie->ops->write(addr, 0x1, value);
>> + return;
>> + }
>> +
>> + writeb(value, addr);
>> }
>>
>> static inline void cdns_pcie_rp_writew(struct cdns_pcie *pcie,
>> u32 reg, u16 value)
>> {
>> - writew(value, pcie->reg_base + CDNS_PCIE_RP_BASE + reg);
>> + void __iomem *addr = pcie->reg_base + CDNS_PCIE_RP_BASE + reg;
>> +
>> + if (pcie->ops && pcie->ops->write) {
>> + pcie->ops->write(addr, 0x2, value);
>> + return;
>> + }
>> +
>> + writew(value, addr);
>
> You removed 2 out of 3 calls to this. I think I'd just make the root
> port writes always be 32-bit. It is all just one time init stuff
> anyways.
>
> Either rework the calls to assemble the data into 32-bits or keep these
> functions and do the RMW here.
The problem with assembling data into 32-bits is we have to read/write with
different offsets. We'll give PCI_VENDOR_ID offset for modifying deviceID,
PCI_INTERRUPT_LINE for modifying INTERRUPT_PIN which might get non-intuitive.
Similarly in endpoint we read and write to MSI_FLAGS (which is at offset 2) we
have to directly use MSI capability offset.
And doing RMW in the accessors would mean the same RMW op is repeated. So if we
just have cdns_pcie_rp_writeb() and cdns_pcie_rp_writew(), the same code will
be repeated here twice.
IMHO using ops is a lot cleaner for these cases. IMHO except for removing
unused functions and not changing readl/writel, others should use ops.
Kindly let me know what you think.
Thanks
Kishon
_______________________________________________
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 v8 5/5] dt-bindings: chosen: Document linux, low-memory-range for arm64 kdump
From: Rob Herring @ 2020-05-21 13:29 UTC (permalink / raw)
To: Chen Zhou
Cc: Simon Horman, John.p.donnelly, Baoquan He, Will Deacon,
devicetree, Catalin Marinas, Linux Doc Mailing List, kexec,
linux-kernel@vger.kernel.org, Ingo Molnar, Arnd Bergmann,
Hanjun Guo, Thomas Gleixner, pkushwaha, dyoung,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE
In-Reply-To: <20200521093805.64398-6-chenzhou10@huawei.com>
On Thu, May 21, 2020 at 3:35 AM Chen Zhou <chenzhou10@huawei.com> wrote:
>
> Add documentation for DT property used by arm64 kdump:
> linux,low-memory-range.
> "linux,low-memory-range" is an another memory region used for crash
> dump kernel devices.
>
> Signed-off-by: Chen Zhou <chenzhou10@huawei.com>
> ---
> Documentation/devicetree/bindings/chosen.txt | 25 ++++++++++++++++++++
> 1 file changed, 25 insertions(+)
chosen is now a schema documented here[1].
> diff --git a/Documentation/devicetree/bindings/chosen.txt b/Documentation/devicetree/bindings/chosen.txt
> index 45e79172a646..bfe6fb6976e6 100644
> --- a/Documentation/devicetree/bindings/chosen.txt
> +++ b/Documentation/devicetree/bindings/chosen.txt
> @@ -103,6 +103,31 @@ While this property does not represent a real hardware, the address
> and the size are expressed in #address-cells and #size-cells,
> respectively, of the root node.
>
> +linux,low-memory-range
> +----------------------
> +This property (arm64 only) holds a base address and size, describing a
> +limited region below 4G. Similar to "linux,usable-memory-range", it is
> +an another memory range which may be considered available for use by the
> +kernel.
Why can't you just add a range to "linux,usable-memory-range"? It
shouldn't be hard to figure out which part is below 4G.
Rob
[1] https://github.com/devicetree-org/dt-schema/blob/master/schemas/chosen.yaml
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: Possible race while masking IRQ on Allwinner A20
From: Jérôme Pouiller @ 2020-05-21 13:28 UTC (permalink / raw)
To: Marc Zyngier
Cc: Marc Dorval, Chen-Yu Tsai, Thomas Gleixner, Maxime Ripard,
linux-arm-kernel
In-Reply-To: <7b8772cbdb9ed907981b18a0ffbc7762@kernel.org>
On Thursday 21 May 2020 10:02:48 CEST Marc Zyngier wrote:
> On 2020-05-21 08:26, Maxime Ripard wrote:
> > On Tue, May 19, 2020 at 10:59:26AM +0200, Jérôme Pouiller wrote:
[...]
> >> Nevermind, I tried to use a level triggered IRQ (and my request is on
> >> this part). As you can see in the wfx driver (in bus_sdio.c and
> >> bh.c), I use a threaded IRQ for that. Unfortunately, I receive some IRQs
> >> twice.
> >> I traced the problem, I get:
> >>
> >> QSGRenderThread-981 [000] d.h. 247.485524: irq_handler_entry: irq=80 name=wfx
> >> QSGRenderThread-981 [000] d.h. 247.485547: irq_handler_exit: irq=80 ret=handled
> >> QSGRenderThread-981 [000] d.h. 247.485600: irq_handler_entry: irq=80 name=wfx
> >> QSGRenderThread-981 [000] d.h. 247.485606: irq_handler_exit: irq=80 ret=handled
> >> irq/80-wfx-260 [001] .... 247.485828: io_read32: CONTROL: 0000f046
> >> irq/80-wfx-260 [001] .... 247.486072: io_read32: CONTROL: 0000f046
> >> kworker/1:1H-116 [001] .... 247.486214: io_read: QUEUE: 8b 00 84 18 00 00 00 00 01 00 15 82 2b 48 01 1e 88 42 30 00 08 6b d7 c3 53 e0 28 80 88 67 32 af ... (192 bytes)
> >> kworker/1:1H-116 [001] .... 247.493097: io_read: QUEUE: 00 00 00 00 00 00 00 00 06 06 00 6a 3f 95 00 60 00 00 00 00 08 62 00 00 01 00 5e 00 00 07 28 80 ... (192 bytes)
> >> [...]
> >>
> >> On this trace, we can see:
> >> - the hard IRQ handler
> >> - the IRQ acknowledge from the thread irq/80-wfx-260
> >> - the access to the data from kworker/1:1H-116
> >>
> >> As far as I understand, the first call to the IRQ handler (at
> >> 247.485524) should mask the IRQ 80. So, the second IRQ (at 247.485600)
> >> should not happen and the thread irq/80 should be triggered only once.
> >>
> >> Do you have any idea of what is going wrong with this IRQ?
> >
> > That's pretty weird indeed. My first guess was that you weren't using
> > IRQF_ONESHOT, but it looks like you are. My next lead would be to see
> > if the mask / unmask hooks in the pinctrl driver are properly called
> > (and actually do what they are supposed to do). I'm not sure we have
> > any in-tree user of a threaded IRQ attached to the pinctrl driver, so
> > it might have been broken for quite some time.
>
> What is certainly puzzling is that this driver doesn't seem to use
> threaded IRQs at all. Instead, it uses its own workqueue that seems
> to bypass the core IRQ subsystem altogether. So any guarantee we'd
> expect goes at of the window.
>
> It is also pretty unclear to me how whether the HW supports switch
> from edge to level signalling. The request_irq() call definitely asks
> for edge, and I don't know how you'd instruct the HW to change its
> signalling method (in general, it isn't possible).
You are talking about the wfx driver? Be sure you read the right version
of the driver. The ability to use a level-triggered IRQ does not exist in
the stable tree. You have to check the "staging-next" tree from Greg[1].
[1] https://kernel.googlesource.com/pub/scm/linux/kernel/git/gregkh/staging/+/staging-next/drivers/staging/wfx/bus_sdio.c#109
--
Jérôme Pouiller
_______________________________________________
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 V1 RESEND 1/3] perf/imx_ddr: Add system PMU identifier for userspace
From: Mark Rutland @ 2020-05-21 13:26 UTC (permalink / raw)
To: Will Deacon
Cc: Rob Herring, devicetree, john.garry, Joakim Zhang, linux-kernel,
linux-imx, shawnguo, linux-arm-kernel
In-Reply-To: <20200520073304.GA23534@willie-the-truck>
On Wed, May 20, 2020 at 08:33:04AM +0100, Will Deacon wrote:
> On Tue, May 19, 2020 at 12:51:25PM -0600, Rob Herring wrote:
> > On Tue, May 12, 2020 at 03:31:13PM +0800, Joakim Zhang wrote:
> > > +static ssize_t ddr_perf_identifier_show(struct device *dev,
> > > + struct device_attribute *attr,
> > > + char *page)
> > > +{
> > > + struct ddr_pmu *pmu = dev_get_drvdata(dev);
> > > +
> > > + return sprintf(page, "%s\n", pmu->devtype_data->identifier);
> >
> > Why do we need yet another way to identify the SoC from userspace?
>
> I also really dislike this. What's the preferred way to identify the SoC
> from userspace? It's needed so that the perf userspace tool can describe
> perf events that are supported for the PMU, as this isn't probe-able
> directly from the hardware. We have the same issue with the SMMUv3 PMCG [1],
> and so we need to solve the problem for both DT and ACPI.
Worth noting that while in this case it happens to identify the SoC,
in general you can have distinct instances of system IP in a single
system, so I do think that we need *something* instance-specific, even
if that's combined with SoC info.
Where IP gets reused across SoCs, it makes sense for that to not depend
on top-level SoC info.
Thanks,
Mark.
>
> Will
>
> [1] https://lore.kernel.org/r/1587120634-19666-1-git-send-email-john.garry@huawei.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: [RFC/RFT PATCH 0/2] crypto: add CTS output IVs for arm64 and testmgr
From: Ard Biesheuvel @ 2020-05-21 13:23 UTC (permalink / raw)
To: Gilad Ben-Yossef
Cc: Stephan Mueller, Eric Biggers, Linux Crypto Mailing List,
Linux ARM
In-Reply-To: <CAOtvUMc8PhToLDVO+Y4NVhVkA6B7yndp3gbaeaQZJtrW_NSzaw@mail.gmail.com>
On Thu, 21 May 2020 at 15:01, Gilad Ben-Yossef <gilad@benyossef.com> wrote:
>
> Hi Ard,
>
> Thank you for looping me in.
>
> On Wed, May 20, 2020 at 10:09 AM Ard Biesheuvel <ardb@kernel.org> wrote:
> >
> > On Wed, 20 May 2020 at 09:01, Stephan Mueller <smueller@chronox.de> wrote:
> > >
> > > Am Mittwoch, 20. Mai 2020, 08:54:10 CEST schrieb Ard Biesheuvel:
> > >
> > > Hi Ard,
> > >
> > > > On Wed, 20 May 2020 at 08:47, Stephan Mueller <smueller@chronox.de> wrote:
> > ...
> > > > > The state of all block chaining modes we currently have is defined with
> > > > > the
> > > > > IV. That is the reason why I mentioned it can be implemented stateless
> > > > > when I am able to get the IV output from the previous operation.
> > > >
> > > > But it is simply the same as the penultimate block of ciphertext. So
> > > > you can simply capture it after encrypt, or before decrypt. There is
> > > > really no need to rely on the CTS transformation to pass it back to
> > > > you via the buffer that is only specified to provide an input to the
> > > > CTS transform.
> > >
> > > Let me recheck that as I am not fully sure on that one. But if it can be
> > > handled that way, it would make life easier.
> >
> > Please refer to patch 2. The .iv_out test vectors were all simply
> > copied from the appropriate offset into the associated .ctext member.
>
> Not surprisingly since to the best of my understanding this behaviour
> is not strictly specified, ccree currently fails the IV output check
> with the 2nd version of the patch.
>
That is what I suspected, hence the cc:
> If I understand you correctly, the expected output IV is simply the
> next to last block of the ciphertext?
Yes. But this happens to work for the generic case because the CTS
driver itself requires the encapsulated CBC mode to return the output
IV, which is simply passed through back to the caller. CTS mode itself
does not specify any kind of output IV, so we should not rely on this
behavior.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: Possible race while masking IRQ on Allwinner A20
From: Jérôme Pouiller @ 2020-05-21 13:12 UTC (permalink / raw)
To: Maxime Ripard
Cc: Marc Zyngier, Marc Dorval, Thomas Gleixner, Chen-Yu Tsai,
linux-arm-kernel
In-Reply-To: <20200521072634.6ig7jcuy5tmvmojf@gilmour.lan>
On Thursday 21 May 2020 09:26:34 CEST Maxime Ripard wrote:
[...]
> On Tue, May 19, 2020 at 10:59:26AM +0200, Jérôme Pouiller wrote:
[...]
> > The chip WF200 allows to use a dedicated line for the IRQ (aka
> > "Out-Of-Band" IRQ). So I have enabled this feature with a edge triggered
> > IRQ. However, I missed some IRQs. Indeed, it seems that Allwinner use a
> > 32KHz clock to sample the IRQs. It is not fast enough for us. I think it
> > explains why we miss some IRQs (using the attribute "input-debounce"[2],
> > I tried to enable the 24Mhz clock, but without success).
>
> Without success as in you couldn't make it use the 24MHz clock, or using it
> didn't change anything?
I didn't make the change myself, but it seems that the board was unable
to run correctly when the attribute "input-debounce" was used. Since
"input-debounce" impacts the whole GPIO bank, I think it has impacted
other devices.
Finally, I didn't spend so much time on this and I don't know if it the
24Mhz clock has been finally correctly enabled.
--
Jérôme Pouiller
_______________________________________________
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 V1 RESEND 1/3] perf/imx_ddr: Add system PMU identifier for userspace
From: Will Deacon @ 2020-05-21 13:04 UTC (permalink / raw)
To: Rob Herring
Cc: Mark Rutland, devicetree, John Garry, Joakim Zhang,
linux-kernel@vger.kernel.org, NXP Linux Team, Shawn Guo,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE
In-Reply-To: <CAL_JsqJfQ0PFy5mmwSG4aM91ghq5xiAEPR2YZOymws+BfGa+uA@mail.gmail.com>
On Wed, May 20, 2020 at 09:23:41AM -0600, Rob Herring wrote:
> On Wed, May 20, 2020 at 1:33 AM Will Deacon <will@kernel.org> wrote:
> >
> > On Tue, May 19, 2020 at 12:51:25PM -0600, Rob Herring wrote:
> > > On Tue, May 12, 2020 at 03:31:13PM +0800, Joakim Zhang wrote:
> > > > +static ssize_t ddr_perf_identifier_show(struct device *dev,
> > > > + struct device_attribute *attr,
> > > > + char *page)
> > > > +{
> > > > + struct ddr_pmu *pmu = dev_get_drvdata(dev);
> > > > +
> > > > + return sprintf(page, "%s\n", pmu->devtype_data->identifier);
> > >
> > > Why do we need yet another way to identify the SoC from userspace?
> >
> > I also really dislike this. What's the preferred way to identify the SoC
> > from userspace?
>
> /proc/cpuinfo? ;)
The *SoC*!
> For an non-firmware specific case, I'd say soc_device should be. I'd
> guess ACPI systems don't use it and for them it's dmidecode typically.
> The other problem I have with soc_device is it is optional.
John -- what do you think about using soc_device to expose this information,
with ACPI systems using DMI data instead?
Will
_______________________________________________
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