Zhenyu,
On 2020-07-27 15:51, Zhenyu Ye wrote:
Hi Marc,
On 2020/7/26 1:40, Marc Zyngier wrote:
On 2020-07-24 14:43, Zhenyu Ye wrote:
Now in unmap_stage2_range(), we flush tlbs one by one just after the
corresponding pages cleared. However, this may cause some
performance
problems when
The following commit has been merged into the irq/urgent branch of tip:
Commit-ID: aa251fc5b936d3ddb4b4c4b36427eb9aa3347c82
Gitweb:
https://git.kernel.org/tip/aa251fc5b936d3ddb4b4c4b36427eb9aa3347c82
Author:Marc Zyngier
AuthorDate:Sat, 25 Jul 2020 13:30:55 +01:00
On Tue, 30 Jun 2020 21:37:46 +0800, Zenghui Yu wrote:
> Booting the latest kernel with DEBUG_ATOMIC_SLEEP=y on a GICv4.1 enabled
> box, I get the following kernel splat:
>
> [0.053766] BUG: sleeping function called from invalid context at
> mm/slab.h:567
> [0.053767] in_atomic(): 1,
On Mon, 27 Jul 2020 22:17:33 +0800, Joakim Zhang wrote:
> This patch intends to implement intmux PM.
>
> ChangeLogs:
> V2->V3:
> 1. allocate u32 saved_reg for a per channel.
>
> V1->V2:
> 1. add more detailed commit message.
> 2. use u32 for 32bit HW registers.
> 3. fix
Hi Zenghui,
On 2020-07-27 04:50, Zenghui Yu wrote:
Hi Marc,
On 2020/6/30 21:37, Zenghui Yu wrote:
Booting the latest kernel with DEBUG_ATOMIC_SLEEP=y on a GICv4.1
enabled
box, I get the following kernel splat:
[0.053766] BUG: sleeping function called from invalid context at
Hi Stephen,
On 2020-07-26 23:10, Stephen Rothwell wrote:
Hi all,
Commit
e5c19cf32b68 ("irqchip/stm32-exti: Use the
hwspin_lock_timeout_in_atomic() API")
is missing a Signed-off-by from its committer.
Looks like I fat-fingered a b4 invocation! Thanks for the heads up,
will be fixed in a
On 2020-07-24 14:43, Zhenyu Ye wrote:
Now in unmap_stage2_range(), we flush tlbs one by one just after the
corresponding pages cleared. However, this may cause some performance
problems when the unmap range is very large (such as when the vm
migration rollback, this may cause vm downtime too
On 2020-07-25 16:57, Suman Anna wrote:
Suman,
Hi Marc,
[...]
@@ -244,8 +295,14 @@ static int pruss_intc_probe(struct
platform_device *pdev)
return -ENOMEM;
for (i = 0; i < MAX_NUM_HOST_IRQS; i++) {
+ if (intc->invalid_intr & BIT(i))
+ continue;
+
On Fri, 17 Jul 2020 17:06:33 -0700, Saravana Kannan wrote:
> Made a series out of the previous v2 patch + some example uses of the
> macros.
>
> Not sure if the MTK changes work (just compile tested), but saw that
> Hanks was trying to make those drivers into tristate. So I assume
> they'll work
On Fri, 17 Jul 2020 16:07:17 +0200, Alexandre Torgue wrote:
> EXTI lines are mainly used to wake-up system from CStop low power mode.
> Currently, if a device wants to use a EXTI (direct) line as wakeup line,
> it has to declare 2 interrupts:
> - one for EXTI used to wake-up system (with
On Mon, 20 Jul 2020 17:23:28 +0800, Zenghui Yu wrote:
> The GICv4.1 spec tells us that it's CONSTRAINED UNPREDICTABLE to issue a
> register-based invalidation operation for a vPEID not mapped to that RD,
> or another RD within the same CommonLPIAff group.
>
> To follow this rule, commit
On Fri, 24 Jul 2020 11:41:56 -0700, Florian Fainelli wrote:
> cpu_logical_map is only defined for CONFIG_SMP builds, when we are in an
> UP configuration, the boot CPU is 0.
Applied to irq/irqchip-5.9, thanks!
[1/1] irqchip/irq-bcm7038-l1: Guard uses of cpu_logical_map
commit:
On Sat, 18 Jul 2020 17:28:53 -0700, Randy Dunlap wrote:
> Drop the repeated word "the" in a comment.
Applied to irq/irqchip-5.9, thanks!
[1/1] irqchip: irq-bcm2836.h: drop a duplicated word
commit: b48489d82fcf61f229a892c7e1b559be15c95916
Cheers,
M.
--
Without deviation from the
On Mon, 20 Jul 2020 11:42:37 +0100,
Joakim Zhang wrote:
>
> When system suspended, we could explicitly disable clock to save power.
> And we need save registers' state since it could be lost after power
> off.
>
> Implement PM which will:
> 1) Without CONFIG_PM, clock is always on after probe
ood measure, I've added this on top, adding the missing bits to
the debugfs entries:
diff --git a/kernel/irq/debugfs.c b/kernel/irq/debugfs.c
index 4f9f844074db..d44fc8a5dab2 100644
--- a/kernel/irq/debugfs.c
+++ b/kernel/irq/debugfs.c
@@ -120,6 +120,9 @@ static const struct irq_bit_descr irqdata_states[] = {
BIT_MASK_DESCR(IRQD_WAKEUP_STATE),
BIT_MASK_DESCR(IRQD_WAKEUP_ARMED),
+ BIT_MASK_DESCR(IRQD_DEFAULT_TRIGGER_SET),
+ BIT_MASK_DESCR(IRQD_HANDLE_ENFORCE_IRQCTX),
+ BIT_MASK_DESCR(IRQD_AFFINITY_ON_ACTIVATE),
};
static const struct irq_bit_descr irqdesc_states[] = {
FWIW:
Acked-by: Marc Zyngier
Tested-by: Marc Zyngier
M.
--
Without deviation from the norm, progress is not possible.
Hi both,
On Fri, 24 Jul 2020 21:03:50 +0100,
Thomas Gleixner wrote:
>
> John,
>
> John Keeping writes:
> > On Fri, 17 Jul 2020 18:00:02 +0200
> > Thomas Gleixner wrote:
> > It seems that this patch breaks perf events on RK3288 because the PMU
> > interrupts that should be per-cpu are now all
On 2020-07-22 20:59, Jason Gunthorpe wrote:
On Wed, Jul 22, 2020 at 07:52:33PM +0100, Marc Zyngier wrote:
Which is exactly what platform-MSI already does. Why do we need
something else?
It looks to me like all the code is around managing the
dev->msi_domain of the devices.
The intended
On Tue, 21 Jul 2020 17:02:28 +0100,
Dave Jiang wrote:
>
> From: Megha Dey
>
> Add support for the creation of a new DEV_MSI irq domain. It creates a
> new irq chip associated with the DEV_MSI domain and adds the necessary
> domain operations to it.
>
> Add a new config option DEV_MSI which
On 2020-07-21 10:27, Grzegorz Jaszczyk wrote:
Hi Marc,
First of all thank you very much for your review. I apologize in
advance if the description below is too verbose or not detailed
enough.
On Fri, 17 Jul 2020 at 14:36, Marc Zyngier wrote:
Suman, Grzegorz,
On Wed, 15 Jul 2020 14:38:05
Hi Zenghui,
On 2020-07-20 03:27, Zenghui Yu wrote:
Hi Marc,
On 2020/7/17 19:07, Marc Zyngier wrote:
On Thu, 09 Jul 2020 14:49:59 +0100,
Zenghui Yu wrote:
The GICv4.1 spec tells us that it's CONSTRAINED UNPREDICTABLE to
issue a
register-based invalidation operation for a vPEID not mapped
On 2020-07-17 18:50, Saravana Kannan wrote:
On Fri, Jul 17, 2020 at 3:49 AM Marc Zyngier wrote:
Hi Saravana,
Thanks for re-spinning this one.
On Fri, 17 Jul 2020 03:44:47 +0100,
Saravana Kannan wrote:
>
> Compiling an irqchip driver as a platform driver needs to bunch of
&g
On Thu, 16 Jul 2020 20:08:20 +0100,
Rob Herring wrote:
>
> On Thu, 16 Jul 2020 11:16:30 +0800, Tiezhu Yang wrote:
> > Fix the following typos in loongson,liointc.yaml:
> > children -> child
> > fron -> from
> > connected -> connect
> > it's -> its
> >
> > Fixes: b6280c8bb6f5 ("dt-bindings:
On Wed, 15 Jul 2020 02:38:57 +0900, Masahiro Yamada wrote:
> This is passed to irq_domain_add_linear(), which accepts a pointer
> to a const structure.
Applied to irq/irqchip-5.9, thanks!
[1/1] irqchip/ativic32: Constify irq_domain_ops
commit: 605a2cf566e130c77fc2cc77fac37fb901fc868a
On Tue, 7 Jul 2020 10:12:44 +0800, Tiezhu Yang wrote:
> Check the return value of irq_domain_translate_onecell() and
> irq_domain_translate_twocell(), fix potential resource leak
> and dead lock, do some code cleanups about Loongson to make
> it more clean and readable.
>
> v2:
> - In order to
On Fri, 10 Jul 2020 23:18:21 +, John Stultz wrote:
> This patch series provides exports and config tweaks to allow
> the qcom-pdc driver to be able to be configured as a permement
> modules (particularlly useful for the Android Generic Kernel
> Image efforts).
>
> This was part of a larger
On Tue, 14 Jul 2020 22:22:45 +0800, Wei Yongjun wrote:
> The sparse tool complains as follows:
>
> drivers/irqchip/irq-mips-gic.c:49:1: warning:
> symbol '__pcpu_scope_pcpu_masks' was not declared. Should it be static?
> drivers/irqchip/irq-mips-gic.c:620:6: warning:
> symbol
On Thu, 16 Jul 2020 16:39:05 +0800, Zenghui Yu wrote:
> The is_fwnode_irqchip() helper will check if the fwnode_handle is empty.
> There is no need to perform a redundant check outside of it.
Applied to irq/irqchip-5.9, thanks!
[1/1] genirq/irqdomain: Remove redundant NULL pointer check on
On Thu, 9 Jul 2020 15:30:10 -0700, Florian Fainelli wrote:
> This patch series contains a number of updates for Broadcom STB L2
> interrupt controllers to enable them as wake-up interrupt controllers,
> and add missing compatible strings that should be matched.
>
> Thanks!
>
> Florian Fainelli
On Thu, 9 Jul 2020 16:41:41 -0700, Florian Fainelli wrote:
> We need to have a definition for cpu_logical_map[] which on ARM
> platforms is provided by asm/smp_plat.h. This header is not
> automatically included from linux/smp.h and untangling it is a bit
> difficult.
Applied to irq/irqchip-5.9,
On Mon, 6 Jul 2020 10:11:15 +0200, Alexandre Torgue wrote:
> Now that the hwspin_lock_timeout_in_atomic() API is available use it.
>
> Signed-off-by: Fabien Dessenne
> Signed-off-by: Alexandre Torgue
>
> diff --git a/drivers/irqchip/irq-stm32-exti.c
> b/drivers/irqchip/irq-stm32-exti.c
>
On Fri, 10 Jul 2020 10:37:47 +0100,
Alexandre Torgue wrote:
>
> Hi Marc,
>
> On 7/10/20 11:31 AM, Marc Zyngier wrote:
> > Alexandre,
> >
> > On Wed, 08 Jul 2020 05:57:24 +0100,
> > kernel test robot wrote:
> >>
> >> [1 ]
> >>
Suman, Grzegorz,
On Wed, 15 Jul 2020 14:38:05 +0100,
Grzegorz Jaszczyk wrote:
>
> Hi Marc,
>
> > On 7/8/20 5:47 AM, Marc Zyngier wrote:
> > > On 2020-07-08 08:04, Grzegorz Jaszczyk wrote:
> > >> On Sun, 5 Jul 2020 at 22:45, Marc Zyngier wrote:
> >
On Thu, 09 Jul 2020 14:49:59 +0100,
Zenghui Yu wrote:
>
> The GICv4.1 spec tells us that it's CONSTRAINED UNPREDICTABLE to issue a
> register-based invalidation operation for a vPEID not mapped to that RD,
> or another RD within the same CommonLPIAff group.
>
> To follow this rule, commit
On Fri, 10 Jul 2020 21:59:17 +0100,
Suman Anna wrote:
Hi Suman,
[...]
>
> Hi Marc,
>
> On 7/2/20 12:44 PM, Marc Zyngier wrote:
> > On 2020-07-02 15:17, Grzegorz Jaszczyk wrote:
> >> From: Suman Anna
> >>
> >> The PRUSS INTC
Hi Saravana,
Thanks for re-spinning this one.
On Fri, 17 Jul 2020 03:44:47 +0100,
Saravana Kannan wrote:
>
> Compiling an irqchip driver as a platform driver needs to bunch of
> things to be done right:
> - Making sure the parent domain is initialized first
> - Making sure the device can't be
On 2020-07-16 20:32, Joakim Zhang wrote:
Add runtime PM support for intmux interrupt controller.
Same as the previous patch. The changes are significant enough
that you need to write a proper change log.
Signed-off-by: Joakim Zhang
---
drivers/irqchip/irq-imx-intmux.c | 31
On 2020-07-16 20:32, Joakim Zhang wrote:
Add system PM support for intmux interrupt controller.
Care to be a little more descriptive?
Signed-off-by: Joakim Zhang
---
drivers/irqchip/irq-imx-intmux.c | 59
1 file changed, 59 insertions(+)
diff --git
Hi Greg,
On 2020-07-16 12:58, Greg KH wrote:
On Wed, Jul 15, 2020 at 01:56:11PM +0100, Marc Zyngier wrote:
This is a backport of the series that recently went into 5.8. Note
that the first patch is more a complete rewriting than a backport, as
the vdso implementation in 5.4 doesn't have much
On 2020-07-16 01:58, Salil Mehta wrote:
From: Marc Zyngier [mailto:m...@kernel.org]
Sent: Wednesday, July 15, 2020 5:09 PM
To: yuzenghui
Hi Zenghui,
On 2020-07-09 11:41, Zenghui Yu wrote:
> Hi All,
>
> I had seen the following lockdep splat when booting a guest on my
> Kunpeng 92
Hi Zenghui,
On 2020-07-09 11:41, Zenghui Yu wrote:
Hi All,
I had seen the following lockdep splat when booting a guest on my
Kunpeng 920 with GICv4 enabled. I can also trigger the same splat
on v5.5 so it should already exist in the kernel for a while. I'm
not sure what the exact problem is
, except that
it would disable it for 64bit userspace as well, which is a shame.
Instead, add a new vdso_clock_mode, which signals that the vdso
isn't usable for compat tasks. This gets checked in the
__arch_get_hw_counter() helper.
Signed-off-by: Marc Zyngier
Acked-by: Mark Rutland
Cc: sta
a way to disable the 32bit view of the
vdso without impacting its 64bit counterpart, by providing a
"no-compat" vdso clock_mode, and plugging this feature into the
1418040 detection code.
Marc Zyngier (3):
arm64: Introduce a way to disable the 32bit vdso
arm64: arch_timer: Allow an
that limits the vdso to 64bit tasks.
Signed-off-by: Marc Zyngier
Acked-by: Mark Rutland
Cc: sta...@vger.kernel.org
Link: https://lore.kernel.org/r/20200706163802.1836732-4-...@kernel.org
Signed-off-by: Will Deacon
Signed-off-by: Marc Zyngier
---
drivers/clocksource/arm_arch_timer.c | 8
1
Commit c1fbec4ac0d701f350a581941d35643d5a9cd184 upstream.
As we are about to disable the vdso for compat tasks in some circumstances,
let's allow a workaround descriptor to express exactly that.
Signed-off-by: Marc Zyngier
Acked-by: Mark Rutland
Cc: sta...@vger.kernel.org
Link: https
: e35a6ae0eb3a ("pinctrl/msm: Setup GPIO chip in hierarchy")
Signed-off-by: Douglas Anderson
Reviewed-by: Marc Zyngier
Linus, I assume you will get this one via the pinctrl tree once you
are happy with it?
Thanks,
M.
--
Jazz is not dead. It just smells funny...
Hi Doug,
On 2020-07-13 16:26, Douglas Anderson wrote:
Depending on how you look at it, you can either say that:
a) There is a PDC hardware issue (with the specific IP rev that exists
on sc7180) that causes the PDC not to work properly when configured
to handle dual edges.
b) The dual edge
On Sat, 11 Jul 2020 00:27:45 +0100,
Stephen Boyd wrote:
>
> Quoting John Stultz (2020-07-10 15:44:18)
> > On Thu, Jul 9, 2020 at 11:02 PM Stephen Boyd wrote:
> > >
> > > Does it work? I haven't looked in detail but I worry that the child
> > > irqdomain (i.e. pinctrl-msm) would need to delay
On Fri, 10 Jul 2020 17:10:55 +0100,
Doug Anderson wrote:
>
> Hi,
>
> On Fri, Jul 10, 2020 at 2:03 AM Marc Zyngier wrote:
> >
> > Hi Doug,
[...]
> >
> > > + type = val ? IRQ_TYPE_EDGE_FALLING : IRQ_TYPE_EDGE_RISING;
> > > +
> > >
On Fri, 10 Jul 2020 15:56:42 +0100,
Valentin Schneider wrote:
>
> While digging around IRQCHIP_EOI_IF_HANDLED and irq/resend.c, it has come
> to my attention that the IRQ resend situation seems a bit precarious for
> the GIC(s). Below is a (somewhat structured) dump of my notes/thoughts
> about
Alexandre,
On Wed, 08 Jul 2020 05:57:24 +0100,
kernel test robot wrote:
>
> [1 ]
> Hi Alexandre,
>
> I love your patch! Perhaps something to improve:
>
> [auto build test WARNING on stm32/stm32-next]
> [also build test WARNING on soc/for-next v5.8-rc4 next-20200707]
> [If your patch is
Hi Doug,
On Wed, 08 Jul 2020 22:16:25 +0100,
Douglas Anderson wrote:
>
> As per Qualcomm, there is a PDC hardware issue (with the specific IP
> rev that exists on sc7180) that causes the PDC not to work properly
> when configured to handle dual edges.
>
> Let's work around this by emulating
("irqdomain: Add the missing assignment of
domain->fwnode for named fwnode")
Reported-by: Andy Shevchenko
Signed-off-by: Thomas Gleixner
Cc: sta...@vger.kernel.org
Urgh, that's pretty disastrous. My bad. Thanks a lot for having
put this patch together.
Acked-by: Marc Zyngier
If
On 2020-07-08 18:48, Lad Prabhakar wrote:
From: Marian-Cristian Rotariu
Basic support for the RZ/G2H SoC.
Signed-off-by: Marian-Cristian Rotariu
Signed-off-by: Lad Prabhakar
---
arch/arm64/boot/dts/renesas/r8a774e1.dtsi | 652 ++
1 file changed, 652 insertions(+)
On 2020-07-08 08:04, Grzegorz Jaszczyk wrote:
On Sun, 5 Jul 2020 at 22:45, Marc Zyngier wrote:
On 2020-07-05 14:26, Grzegorz Jaszczyk wrote:
> On Sat, 4 Jul 2020 at 11:39, Marc Zyngier wrote:
>>
>> On 2020-07-03 15:28, Grzegorz Jaszczyk wrote:
[...]
>> It still begs th
qchip/irq-sl28cpld.c | 96 ++
3 files changed, 105 insertions(+)
create mode 100644 drivers/irqchip/irq-sl28cpld.c
Acked-by: Marc Zyngier
Given the dependency on the MFD patches, I assume this will
be routed to that subsystem. Please let me know if you want
it to be han
On 2020-07-07 18:36, Catalin Marinas wrote:
On Mon, Jun 01, 2020 at 10:47:13PM +0800, Zhenyu Ye wrote:
@@ -59,6 +69,47 @@
__ta; \
})
+/*
+ * __TG defines translation granule of the system, which is decided
by
+ * PAGE_SHIFT.
).
* From v1:
- Reworked following Mark's feedback (patches #2 and #3)
- Reworked patch #4 after Will's comments
- patches #1 to #3 are now cc stable
- Applied Mark's AB to patch #1
Marc Zyngier (4):
arm64: Introduce a way to disable the 32bit vdso
arm64: arch_timer: Allow an workaround
vdso_clock_mode, which signals that the vdso
isn't usable for compat tasks. This gets checked in the new
vdso_clocksource_ok() helper, now provided for the 32bit vdso.
Cc: sta...@vger.kernel.org
Acked-by: Mark Rutland
Signed-off-by: Marc Zyngier
---
arch/arm64/include/asm/vdso/clocksource.h
.
For that, make sure that on entering the kernel from a 32bit tasks,
userspace access to cntvct gets enabled, and disabled returning to
userspace, while it never gets changed for 64bit tasks.
Signed-off-by: Marc Zyngier
---
arch/arm64/kernel/entry.S | 40 +++
1
Signed-off-by: Marc Zyngier
---
drivers/clocksource/arm_arch_timer.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/clocksource/arm_arch_timer.c
b/drivers/clocksource/arm_arch_timer.c
index a8e4fb429f52..6c3e84180146 100644
--- a/drivers/clocksource/arm_arch_timer.c
+++ b
As we are about to disable the vdso for compat tasks in some circumstances,
let's allow a workaround descriptor to express exactly that.
Cc: sta...@vger.kernel.org
Signed-off-by: Marc Zyngier
---
arch/arm64/include/asm/arch_timer.h | 1 +
drivers/clocksource/arm_arch_timer.c | 3 +++
2 files
On 2020-07-06 02:19, Tiezhu Yang wrote:
When I test the irqchip code of Loongson, I read the related code of
other
chips in drivers/irqchip and I find some potential resource leaks in
the
error path, I think it is better to fix them.
v2:
- Split the first patch into a new patch series which
On 2020-07-05 14:26, Grzegorz Jaszczyk wrote:
On Sat, 4 Jul 2020 at 11:39, Marc Zyngier wrote:
On 2020-07-03 15:28, Grzegorz Jaszczyk wrote:
[...]
It still begs the question: if the HW can support both edge and level
triggered interrupts, why isn't the driver supporting this diversity?
I
On Wed, 1 Jul 2020 08:07:09 -0400, Peng Hao wrote:
> update_vmid() just has one parameter "vmid".The other parameter
> "kvm" is no longer used.
Applied to kvm-arm64/next-5.9, thanks!
[1/1] KVM: arm64: Drop long gone function parameter documentation
commit:
On Wed, 1 Jul 2020 16:02:06 +0200, Alexander Graf wrote:
> PENDBASER and PROPBASER define the outer caching mode for LPI tables.
> The memory backing them may not be outer sharable, so we mark them as nC
> by default. This however, breaks Windows on ARM which only accepts
> SameAsInner or RaWaWb
On Mon, 22 Jun 2020 11:33:12 +, James Morse wrote:
> KVM's target_table indirection is a relic from 32bit where different
> CPUs had different reset values for ACTLR. All 64bit CPUs have the
> same behaviour here, but we support different targets, that all map
> to the same behaviour.
>
>
On Thu, 25 Jun 2020 14:14:05 +0100, David Brazdil wrote:
> Refactor files in arch/arm64/kvm/hyp to compile all code which runs in EL2
> under nVHE into separate object files from the rest of KVM. This is done in
> preparation for being able to unmap hyp code from EL1 and kernel code/data
> from
On 2020-07-05 12:22, Andy Shevchenko wrote:
On Sun, Jul 05, 2020 at 11:28:56AM +0100, Marc Zyngier wrote:
On 2020-07-05 11:07, Andy Shevchenko wrote:
> On Sun, Jul 5, 2020 at 12:32 PM Marc Zyngier wrote:
> >
> > The meson UART driver triggers a lockdep splat at boot time, due
On Thu, 25 Jun 2020 14:14:13 +0100,
David Brazdil wrote:
>
> tlb.c contains code for flushing the TLB, with code shared between VHE/nVHE.
> Because common code is small, duplicate tlb.c and specialize each copy for
> VHE/nVHE.
>
> Signed-off-by: David Brazdil
> ---
>
similarity index 62%
> rename from arch/arm64/kvm/hyp/tlb.c
> rename to arch/arm64/kvm/hyp/nvhe/tlb.c
> index d063a576d511..9513ad41db9a 100644
> --- a/arch/arm64/kvm/hyp/tlb.c
> +++ b/arch/arm64/kvm/hyp/nvhe/tlb.c
> @@ -4,8 +4,6 @@
> * Author: Marc Zyngier
> */
>
Hi David,
On Thu, 25 Jun 2020 14:14:12 +0100,
David Brazdil wrote:
>
> From: Andrew Scull
>
> hyp-init.S contains the identity mapped initialisation code for the
> non-VHE code that runs at EL2. It is only used for non-VHE.
>
> Adjust code that calls into this to use the prefixed symbol
On 2020-07-05 11:07, Andy Shevchenko wrote:
On Sun, Jul 5, 2020 at 12:32 PM Marc Zyngier wrote:
The meson UART driver triggers a lockdep splat at boot time, due
to the new expectation that the driver has to initialize the
per-port spinlock itself.
It remains unclear why a double
: a3cb39d258ef ("serial: core: Allow detach and attach serial device for
console")
Cc: Andy Shevchenko
Cc: Greg Kroah-Hartman
Signed-off-by: Marc Zyngier
---
drivers/tty/serial/meson_uart.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/tty/serial/meson_uart.c b/drivers/
| 4
kernel/irq/chip.c | 13 -
5 files changed, 34 deletions(-)
For the whole series, and assuming that there is no regression
(can't imagine any for unused code):
Reviewed-by: Marc Zyngier
Thanks,
M.
--
Jazz is not dead. It just smells funny...
On 2020-07-03 15:28, Grzegorz Jaszczyk wrote:
On Thu, 2 Jul 2020 at 19:24, Marc Zyngier wrote:
On 2020-07-02 15:17, Grzegorz Jaszczyk wrote:
> From: Suman Anna
>
> The Programmable Real-Time Unit Subsystem (PRUSS) contains a local
> interrupt controller (INTC) that can handle va
On 2020-07-02 15:17, Grzegorz Jaszczyk wrote:
From: Suman Anna
The K3 AM65x and J721E SoCs have the next generation of the PRU-ICSS
IP,
commonly called ICSSG. The PRUSS INTC present within the ICSSG supports
more System Events (160 vs 64), more Interrupt Channels and Host
Interrupts
(20 vs
On 2020-07-02 15:17, Grzegorz Jaszczyk wrote:
From: David Lechner
This implements the irq_get_irqchip_state and irq_set_irqchip_state
callbacks for the TI PRUSS INTC driver. The set callback can be used
by drivers to "kick" a PRU by enabling a PRU system event.
"enabling"? That'd be
On 2020-07-02 15:17, Grzegorz Jaszczyk wrote:
From: Suman Anna
The PRUSS INTC has a fixed number of output interrupt lines that are
connected to a number of processors or other PRUSS instances or other
devices (like DMA) on the SoC. The output interrupt lines 2 through 9
are usually connected
On 2020-07-02 15:17, Grzegorz Jaszczyk wrote:
From: Suman Anna
The Programmable Real-Time Unit Subsystem (PRUSS) contains a local
interrupt controller (INTC) that can handle various system input events
and post interrupts back to the device-level initiators. The INTC can
support upto 64 input
On 2020-07-02 11:28, Mark Rutland wrote:
On Wed, Jul 01, 2020 at 05:18:23PM +0100, Marc Zyngier wrote:
As we are about to disable the vdso for compat tasks in some
circumstances,
let's allow a workaround descriptor to provide the vdso_clock_mode
that
matches the platform.
Signed-off-by: Marc
On 2020-07-02 14:23, Valentin Schneider wrote:
On 30/06/20 11:15, Marc Zyngier wrote:
On 2020-06-25 19:25, Valentin Schneider wrote:
Also, while staring at this it dawned on me that IPI's don't need the
eoimode=0 isb(): due to how the IPI flow-handler is structured, we'll
get a
gic_eoi_irq
On 2020-06-25 19:25, Valentin Schneider wrote:
On 24/06/20 20:58, Marc Zyngier wrote:
@@ -852,8 +841,7 @@ void arch_send_wakeup_ipi_mask(const struct
cpumask *mask)
#ifdef CONFIG_IRQ_WORK
void arch_irq_work_raise(void)
{
- if (__smp_cross_call)
- smp_cross_call
ARM64_WORKAROUND_1418040 requires that AArch32 EL0 accesses to
the virtual counter register are trapped and emulated by the kernel.
This makes the vdso pretty pointless, and in some cases livelock
prone.
Provide a workaround entry that limits the vdso to 64bit tasks.
Signed-off-by: Marc Zyngier
vdso_clock_mode, which signals that the vdso
isn't usable for compat tasks. This gets checked in the new
vdso_clocksource_ok() helper, now provided for the 32bit vdso.
Signed-off-by: Marc Zyngier
---
arch/arm64/include/asm/vdso/clocksource.h | 7 +--
arch/arm64/include/asm/vdso
As we are about to disable the vdso for compat tasks in some circumstances,
let's allow a workaround descriptor to provide the vdso_clock_mode that
matches the platform.
Signed-off-by: Marc Zyngier
---
arch/arm64/include/asm/arch_timer.h | 3 +++
drivers/clocksource/arm_arch_timer.c | 3 +++
2
detection code.
I haven't put any Cc stable for now, but I believe we need to do
something for older kernels.
Marc Zyngier (3):
arm64: Introduce a way to disable the 32bit vdso
arm64: arch_timer: Allow an workaround descriptor to provide
vdso_clock_mode
arm64: timers: Disable the c
On Tue, 30 Jun 2020 21:41:26 +0800, Zenghui Yu wrote:
> As per the GICv3 specification, GIC{D,R}_SEIR are not assigned and the
> locations (0x0068) are actually Reserved. GICR_MOV{LPI,ALL}R are two IMP
> DEF registers and might be defined by some specific micro-architecture,
> Linux doesn't use
On 2020-06-30 14:41, Zenghui Yu wrote:
As per the GICv3 specification, GIC{D,R}_SEIR are not assigned and the
locations (0x0068) are actually Reserved. GICR_MOV{LPI,ALL}R are two
IMP
DEF registers and might be defined by some specific micro-architecture,
Linux doesn't use them.
As they're not
On 2020-06-29 10:49, Kunihiko Hayashi wrote:
Hi Marc,
On 2020/06/27 18:48, Marc Zyngier wrote:
On Thu, 18 Jun 2020 09:38:09 +0100,
Kunihiko Hayashi wrote:
The misc interrupts consisting of PME, AER, and Link event, is
handled
by INTx handler, however, these interrupts should be also
On 2020-06-25 19:25, Valentin Schneider wrote:
On 24/06/20 20:58, 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
---
drivers/irqchip
The following commit has been merged into the irq/urgent branch of tip:
Commit-ID: 005c34ae4b44f085120d7f371121ec7ded677761
Gitweb:
https://git.kernel.org/tip/005c34ae4b44f085120d7f371121ec7ded677761
Author:Marc Zyngier
AuthorDate:Sun, 21 Jun 2020 14:43:15 +01:00
.org
Fixes: 9173c5ceb035 ("PM / devfreq: rk3399_dmc: Pass ODT and auto power down
parameters to TF-A.")
Signed-off-by: Marc Zyngier
---
* From v2:
- Trimmed down commit message
- Cc stable
drivers/devfreq/rk3399_dmc.c | 42
1 file changed, 23 inserti
On 2020-06-25 19:25, Valentin Schneider wrote:
On 24/06/20 20:57, Marc Zyngier wrote:
@@ -696,9 +696,76 @@ void handle_IPI(int ipinr, struct pt_regs *regs)
if ((unsigned)ipinr < NR_IPI)
trace_ipi_exit_rcuidle(ipi_types[ipinr]);
+}
+
+/* Legacy version, should go away o
Hi Chanwoo,
On Mon, 29 Jun 2020 03:43:37 +0100,
Chanwoo Choi wrote:
>
> Hi Marc,
>
> On 6/23/20 12:28 AM, Marc Zyngier wrote:
[...]
> It looks good to me. But, I think that it is not necessary
> fully kernel panic log about NULL pointer. It is enoughspsp
> just mentio
Hi Zenghui,
On 2020-06-29 10:39, Zenghui Yu wrote:
Hi All,
Booting the latest kernel with DEBUG_ATOMIC_SLEEP=y on a GICv4.1
enabled
box, I get the following kernel splat:
[0.053766] BUG: sleeping function called from invalid context at
mm/slab.h:567
[0.053767] in_atomic(): 1,
On 2020-06-29 12:29, Chanwoo Choi wrote:
Hi Enric and Mark,
On 6/29/20 8:05 PM, Enric Balletbo i Serra wrote:
Hi Chanwoo and Marc,
On 29/6/20 13:09, Chanwoo Choi wrote:
Hi Enric,
Could you check this issue? Your patch[1] causes this issue.
As Marc mentioned, although rk3399-dmc.c handled
On 2020-06-28 13:48, Aleksandar Markovic wrote:
нед, 28. јун 2020. у 14:06 Marc Zyngier је написао/ла:
On 2020-06-28 12:25, Aleksandar Markovic wrote:
> сре, 24. јун 2020. у 10:40 Marc Zyngier је написао/ла:
>>
>> On 2020-06-24 08:44, Tiezhu Yang wrote:
>> > [git send
On 2020-06-28 12:25, Aleksandar Markovic wrote:
сре, 24. јун 2020. у 10:40 Marc Zyngier је написао/ла:
On 2020-06-24 08:44, Tiezhu Yang wrote:
> [git send-email failed due to too many commands,
> so only cc the major related email and resend it,
> sorry for that]
This is becomin
On 2020-06-27 00:15, Valentin Schneider wrote:
On 26/06/20 12:58, Marc Zyngier wrote:
On 2020-06-25 19:26, Valentin Schneider wrote:
On 24/06/20 20:58, Marc Zyngier wrote:
@@ -801,26 +802,15 @@ void show_ipi_list(struct seq_file *p, int
prec)
unsigned int cpu, i;
for (i = 0; i
On Sat, 30 May 2020 16:34:27 +0200, Oscar Carter wrote:
> In an effort to enable -Wcast-function-type in the top-level Makefile to
> support Control Flow Integrity builds, there are the need to remove all
> the function callback casts in the acpi driver.
>
> The first patch creates a macro called
1201 - 1300 of 9391 matches
Mail list logo
