[Please use my kernel.org address in the future. The days of this
arm.com address are numbered...]
On 29/08/2019 19:11, Lina Iyer wrote:
> Introduce a new domain for wakeup capable GPIOs. The domain can be
> requested using the bus token DOMAIN_BUS_WAKEUP. In the following
> patches, we will speci
On 26/08/2019 12:59, Lubomir Rintel wrote:
> On Fri, 2019-08-23 at 10:42 +0100, Marc Zyngier wrote:
>> On 23/08/2019 08:21, Lubomir Rintel wrote:
>>> On Thu, 2019-08-22 at 11:31 +0100, Marc Zyngier wrote:
>>>> On 22/08/2019 10:26, Lubomir Rintel wrote:
>>>&g
On 29/08/2019 17:16, Jerome Brunet wrote:
> This patchset adds support for the new sm1 SoC family in the Amlogic gpio
> interrupt controller.
>
> Jerome Brunet (2):
> dt-bindings: interrupt-controller: new binding for the meson sm1 SoCs
> irqchip/meson-gpio: Add support for meson sm1 SoCs
>
>
On 29/08/2019 07:39, Jianyong Wu wrote:
> Currently in arm64 virtualization environment, there is no mechanism to
> keep time sync between guest and host. Time in guest will drift compared
> with host after boot up as they may both use third party time sources
> to correct their time respectively.
On 29/08/2019 07:39, Jianyong Wu wrote:
> Currently, ptp_kvm modules implementation is only for x86 which includs
> large part of arch-specific code. This patch move all of those code
> into related arch directory.
>
> Signed-off-by: Jianyong Wu
> ---
> arch/x86/kvm/arch_ptp_kvm.c | 92
On 28/08/2019 16:31, Jiaxun Yang wrote:
>
> On 2019/8/28 下午2:59, Marc Zyngier wrote:
>> On Wed, 28 Aug 2019 08:27:05 +0800
>> Jiaxun Yang wrote:
>>
>>> On 2019/8/28 上午12:45, Marc Zyngier wrote:
>>>> On 27/08/2019 09:52, Jiaxun Yan
On Wed, 28 Aug 2019 08:27:05 +0800
Jiaxun Yang wrote:
> On 2019/8/28 上午12:45, Marc Zyngier wrote:
> > On 27/08/2019 09:52, Jiaxun Yang wrote:
> >> This controller appeared on Loongson-3 family of chips as the primary
> >> package interrupt source.
> >
On 27/08/2019 09:52, Jiaxun Yang wrote:
> This controller appeared on Loongson-3 family of chips as the primary
> package interrupt source.
>
> Signed-off-by: Jiaxun Yang
> ---
> drivers/irqchip/Kconfig | 9 ++
> drivers/irqchip/Makefile | 1 +
> drivers/irqchip/irq-ls3-ioin
On 27/08/2019 09:52, Jiaxun Yang wrote:
> This controller appeared on Loongson-3 family of chips to receive interrupts
> from PCH chip.
>
> Signed-off-by: Jiaxun Yang
> ---
> drivers/irqchip/Kconfig | 8 ++
> drivers/irqchip/Makefile | 1 +
> drivers/irqchip/irq-ls3-htintc.c
On 26/08/2019 22:25, Pavel Tatashin wrote:
> On Mon, Aug 26, 2019 at 3:13 PM Marc Zyngier wrote:
>>
>> On Mon, 26 Aug 2019 15:00:50 -0400
>> Pavel Tatashin wrote:
>>
>>> Marc Zyngier added the support for kexec and GICv3 for EFI based systems.
>>&
Fixes: ffc5089196446 ("[PATCH] Create kallsyms_lookup_size_offset()")
Cc: Masami Hiramatsu
Cc: Arnaldo Carvalho de Melo
Cc: Peter Zijlstra
Cc: Will Deacon
Cc: Catalin Marinas
Signed-off-by: Marc Zyngier
---
kernel/kallsyms.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff
On 23/08/2019 08:21, Lubomir Rintel wrote:
> On Thu, 2019-08-22 at 11:31 +0100, Marc Zyngier wrote:
>> On 22/08/2019 10:26, Lubomir Rintel wrote:
>>> Hi,
>>>
>>> this is a second spin of a patch set that adds support for the Marvell
>>> MMP3 processor.
Hi Julien,
On 22/08/2019 17:11, Julien wrote:
> Hi Marc,
>
> On 06/08/19 11:01, Marc Zyngier wrote:
>> GICv3.1 allows up to 80 PPIs (16 legaci PPIs and 64 Extended PPIs),
>> meaning we can't just leave the old 16 hardcoded everywhere.
>>
>> We also need to
On 22/08/2019 10:26, Lubomir Rintel wrote:
> Hi,
>
> this is a second spin of a patch set that adds support for the Marvell
> MMP3 processor. MMP3 is used in OLPC XO-4 laptops, Panasonic Toughpad
> FZ-A1 tablet and Dell Wyse 3020 Tx0D thin clients.
>
> Compared to v1, there's a handful of fixes
On 21/08/2019 12:30, Linus Walleij wrote:
> On Wed, Aug 21, 2019 at 10:13 AM Marc Zyngier wrote:
>
>> Linus: do you want to take this patch (daa19fe5b082) through your tree
>> instead in order to avoid the conflict when this hit the other Linus?
>> It shouldn't c
On Wed, 21 Aug 2019 07:03:35 +0100,
Stephen Rothwell wrote:
Hi Stephen,
>
> Hi all,
>
> Today's linux-next merge of the gpio tree got a conflict in:
>
> drivers/gpio/gpio-ixp4xx.c
>
> between commit:
>
> daa19fe5b082 ("gpio/ixp4xx: Register the base PA instead of its VA in
> fwnode")
>
On 19/08/2019 15:25, Zenghui Yu wrote:
> Hi Marc,
>
> On 2019/8/6 18:01, Marc Zyngier wrote:
>> Add the required support for the ESPI range, which behave exactly like
>> the SPIs of old, only with new funky INTIDs.
>>
>> Signed-off-by: Marc Zyngier
>>
On 19/08/2019 15:26, Zenghui Yu wrote:
> Hi Marc,
>
> On 2019/8/6 18:01, Marc Zyngier wrote:
>> gic_configure_irq is currently passed the (re)distributor address,
>> to which it applies an a fixed offset to get to the configuration
>> registers. This offset is constant
Hi Mars,
On 19/08/2019 12:42, Mars Cheng wrote:
> Hi Marc
>
> On Mon, 2019-08-19 at 10:40 +0100, Marc Zyngier wrote:
>> On 19/08/2019 10:21, Mars Cheng wrote:
>>> this adds initial MT6779 dts settings fo board support,
>>> including cpu, gic, timer, ccf, pinctr
On 19/08/2019 10:21, Mars Cheng wrote:
> this adds initial MT6779 dts settings fo board support,
> including cpu, gic, timer, ccf, pinctrl, uart...etc.
>
> Signed-off-by: Mars Cheng
> ---
> arch/arm64/boot/dts/mediatek/Makefile|1 +
> arch/arm64/boot/dts/mediatek/mt6779-evb.dtsi |
On Mon, 12 Aug 2019 13:52:56 +0100,
Bartosz Golaszewski wrote:
>
> From: Bartosz Golaszewski
>
> We currently have a dedicated function to map the interrupt simulator
> offsets to global interrupt numbers. This is something that irq_domain
> should handle.
>
> Create a linear irq_domain when i
On Fri, 16 Aug 2019 20:41:22 +0200
Lubomir Rintel wrote:
> On Fri, 2019-08-09 at 13:12 +0100, Marc Zyngier wrote:
> > On 09/08/2019 10:31, Lubomir Rintel wrote:
> > > The "regs" property of the "mrvl,mmp2-mux-intc" devices are silly. They
> > >
> Ignore them by setting the maximum threshold.
> >
> > Signed-off-by: Christoph Hellwig
>
> If you're happy with this, could one of you ack it so we can merge it
> with the rest of this series through the RISC-V tree?
Sure, no problem.
Acked-by: Marc Zyngier
Than
On Tue, 13 Aug 2019 16:40:27 +0100,
Dmitry Osipenko wrote:
>
> 13.08.2019 17:50, Marc Zyngier пишет:
> > On Sun, 11 Aug 2019 19:30:44 +0100,
> > Dmitry Osipenko wrote:
> >>
> >> Make coding style to conform to the kernel's standard by fixing che
est later.
>
> On Mon, Jul 08, 2019 at 10:36:14AM +0100, Marc Zyngier wrote:
> > On 07/07/2019 14:22, Aleix Roca Nonell wrote:
> > > This driver adds support for the RTD1296 and RTD1295 interrupt
> > > controller (intc). It is based on both the BPI-SINOVOIP project and
On Sun, 11 Aug 2019 19:30:44 +0100,
Dmitry Osipenko wrote:
>
> Make coding style to conform to the kernel's standard by fixing checkpatch
> warnings about "line over 80 characters".
The last time I used a VT100 was about 30 years ago. I still think
this was one of the most brilliant piece of equ
On Sun, 11 Aug 2019 19:30:43 +0100,
Dmitry Osipenko wrote:
>
> There is no point in touching of the COP (ARM7TDMI auxiliary boot/firmware
> CPU) because COP's interrupts should be related only to an old multimedia
> firmware that is not applicable to the upstream kernel. Hence let's remove
> ever
On 09/08/2019 10:31, Lubomir Rintel wrote:
> From: Andres Salomon
>
> On mmp3, there's an extra set of ICU registers (ICU2) that handle
> interrupts on the extra cores. When masking off interrupts on MP1,
> these should be masked as well.
>
> We add a new interrupt controller via device tree to
On 09/08/2019 10:31, Lubomir Rintel wrote:
> The "regs" property of the "mrvl,mmp2-mux-intc" devices are silly. They
> are offsets from intc's base, not addresses on the parent bus. At this
> point it probably can't be fixed.
>
> On an OLPC XO-1.75 machine, the muxes are children of the intc, not
On 09/08/2019 10:31, Lubomir Rintel wrote:
> The lack of chained_irq_exit() leaves the muxed interrupt masked on MMP3.
> For reasons unknown this is not a problem on MMP2.
>
> Signed-off-by: Lubomir Rintel
> ---
> drivers/irqchip/irq-mmp.c | 9 -
> 1 file changed, 8 insertions(+), 1 dele
r(...);
> -... }
> |
> ...
> -dev_err(...);
> )
> ...
> }
> //
>
> While we're here, remove braces on if statements that only have one
> statement (manually).
>
> Cc: Thomas Gleixner
> Cc: Jason Cooper
> Cc: Marc Zyngier
> Cc: Greg Kroah
On 07/08/2019 14:56, Thomas Gleixner wrote:
> Megha,
>
> On Tue, 6 Aug 2019, Megha Dey wrote:
>> On Sat, 2019-06-29 at 09:59 +0200, Thomas Gleixner wrote:
>>> On Fri, 21 Jun 2019, Megha Dey wrote:
>>
>> Totally agreed. The request to add a dynamic MSI-X infrastructure came
>> from some driver team
On 06/08/2019 15:57, Marc Zyngier wrote:
> To allocate its fwnode that is then used to allocate an irqdomain,
> the driver uses irq_domain_alloc_fwnode(), passing it a VA as an
> identifier. This is a rather bad idea, as this address ends up
> published in debugfs (and we want to mo
x27; already present!
and many more... Evidently, we expect something a bit more informative
than ptrval, and certainly we want all of our domains, not just
the first one.
For that, turn the %p used to generate the fwnode name into something
that won't be repainted (%pa). Give
named fwnode by using the device GUID as
an identifier. It is allegedly unique, and can be traced back to
the original device.
Signed-off-by: Marc Zyngier
---
drivers/pci/controller/pci-hyperv.c | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/drivers/pci/controlle
Do not expose the base VA (it appears in debugfs). Instead,
record the PA, which at least can be used to precisely identify
the associated irqchip and domain.
Signed-off-by: Marc Zyngier
---
drivers/gpio/gpio-ixp4xx.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers
Do not expose the distributor's VA (it appears in debugfs). Instead,
record the PA, which at least can be used to precisely identify
the associated irqchip and domain.
Signed-off-by: Marc Zyngier
---
drivers/irqchip/irq-gic.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --
Do not expose the ITS' VA (it appears in debugfs). Instead, record
the PA, which at least can be used to precisely identify the associated
irqchip and domain.
Signed-off-by: Marc Zyngier
---
drivers/irqchip/irq-gic-v3-its.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --
Do not expose the distributor's VA (it appears in debugfs). Instead,
record the PA, which at least can be used to precisely identify
the associated irqchip and domain.
Signed-off-by: Marc Zyngier
---
drivers/irqchip/irq-gic-v3.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff
ciate with. This is solved by using a named fwnode instead,
using the device GUID.
Finally, irq_domain_alloc_fwnode() is changed to pa a pionter to a PA,
which can be safely advertised in debugfs.
Marc Zyngier (8):
irqchip/gic-v3: Register the distributor's PA instead of its VA in
fwnode
Do not expose the base VA (it appears in debugfs). Instead,
record the PA, which at least can be used to precisely identify
the associated irqchip and domain.
Signed-off-by: Marc Zyngier
---
drivers/irqchip/irq-ixp4xx.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers
Do not expose the frame's VA (it appears in debugfs). Instead,
record the PA, which at least can be used to precisely identify
the associated irqchip and domain.
Signed-off-by: Marc Zyngier
---
drivers/irqchip/irq-gic-v2m.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --
Hi Vladimir,
On 06/08/2019 11:15, Vladimir Murzin wrote:
> Hi Marc,
>
> On 8/6/19 11:01 AM, Marc Zyngier wrote:
>> As is it usual for the GIC, it isn't disallowed to put together a system
>> that is majorly inconsistent, with a distributor supporting the
>> extend
GICv3.1 introduces support for new interrupt ranges, one of them being
the Extended SPI range (ESPI). The DT binding is extended to deal with
it as a new interrupt class.
Reviewed-by: Lokesh Vutla
Signed-off-by: Marc Zyngier
---
.../devicetree/bindings/interrupt-controller/arm,gic-v3.yaml | 5
Add the required support for the ESPI range, which behave exactly like
the SPIs of old, only with new funky INTIDs.
Signed-off-by: Marc Zyngier
---
drivers/irqchip/irq-gic-v3.c | 85 --
include/linux/irqchip/arm-gic-v3.h | 17 +-
2 files changed, 85
range. Boo.
In order to make our life less hellish, let's introduce a set of primitives
that will allow ranges to be identified easily and offsets to be remapped.
So far, there is no functionnal change.
Signed-off-by: Marc Zyngier
---
drivers/irqchip/irq-gic-v3.c | 112 +++
Update the GICv3 binding to allow interrupts in the EPPI range.
Signed-off-by: Marc Zyngier
---
.../devicetree/bindings/interrupt-controller/arm,gic-v3.yaml | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git
a/Documentation/devicetree/bindings/interrupt-controller/arm,gic
When evaluating potential quirks matched by reads of the IIDR
register, skip the quirk entries that use a "compatible"
property attached to them, as these are DT based.
Signed-off-by: Marc Zyngier
---
drivers/irqchip/irq-gic-common.c | 2 ++
1 file changed, 2 insertions(+)
diff --git
It looks like the HIP06/07 SoCs have extra bits in their GICD_TYPER
registers, which confuse the GICv3.1 code (these systems appear to
expose ESPIs while they actually don't).
Detect these systems as early as possible and wipe the fields that
should be RES0 in the register.
Signed-off-by:
As we're about to have a variable number of PPIs, let's make the
allocation of the NMI refcounts dynamic. Also apply some minor
cleanups (moving things around).
Signed-off-by: Marc Zyngier
---
drivers/irqchip/irq-gic-v3.c | 47 ++--
1 file changed, 34
As is it usual for the GIC, it isn't disallowed to put together a system
that is majorly inconsistent, with a distributor supporting the
extended ranges while some of the CPUs don't.
Kindly tell the user that things are sailing isn't going to be smooth.
Signed-off-by: Marc Zyngie
configuration register for the considered interrupt.
At the same time, move part of the error handling back to the
individual drivers, as things are about to change on that front.
Signed-off-by: Marc Zyngier
---
drivers/irqchip/irq-gic-common.c | 14 +-
drivers/irqchip/irq-gic-v3.c
Expand the pre-existing PPI support to be able to deal with the
Extended PPI range (EPPI). This includes obtaining the number of PPIs
from each individual redistributor, and compute the minimum set
(just in case someone builds something really clever...).
Signed-off-by: Marc Zyngier
---
drivers
Again, PPIs are becoming a variable set. Let's hack the PPI partition
code to make the top-level array dynamically allocated.
Signed-off-by: Marc Zyngier
---
drivers/irqchip/irq-gic-v3.c | 14 +++---
1 file changed, 11 insertions(+), 3 deletions(-)
diff --git a/drivers/irqchip/ir
.
No functional change.
Signed-off-by: Marc Zyngier
---
drivers/irqchip/irq-gic-common.c | 19 ---
drivers/irqchip/irq-gic-common.h | 2 +-
drivers/irqchip/irq-gic-v3.c | 22 +++---
drivers/irqchip/irq-gic.c| 2 +-
drivers/irqchip/irq-hip04.c | 2
/ihi0069/latest (version E)
* From v1:
- Tighten ESPI range matching
- Added a warning to detect inconsistent distributor/cpu interface
configurations
- Added quirks to handle HIP06/07 erratum 161010803 which unexpectedly
advertise ESPI support
Marc Zyngier (12):
irqchip/gic: Rework
On 03/08/2019 18:33, Martin Blumenstingl wrote:
> Hi Marc,
>
> On Sat, Aug 3, 2019 at 11:12 AM Marc Zyngier wrote:
>>
>> Hi Martin,
>>
>> On Thu, 01 Aug 2019 18:42:42 +0100,
>> Martin Blumenstingl wrote:
>>
>> [...]
>>
>
On 05/08/2019 14:06, Steven Price wrote:
> On 03/08/2019 19:05, Marc Zyngier wrote:
>> On Fri, 2 Aug 2019 15:50:08 +0100
>> Steven Price wrote:
>>
>> Hi Steven,
>>
>>> This series add support for paravirtualized time for arm64 guests and
>>
t;> $ echo " [ ...]"
>>"[, [ ...]] ...]"
>> > /sys/bus/platform/drivers/gpio-virt-agg/new_device
>>
>> Likewise, virtual GPIO controllers can be destroyed after use:
>>
>> $ echo gpio-virt-agg. \
>>
Hi Martin,
On Thu, 01 Aug 2019 18:42:42 +0100,
Martin Blumenstingl wrote:
[...]
> > > +static void ltq_ebu_irq_handler(struct irq_desc *desc)
> > > +{
> > > + struct irq_domain *domain = irq_desc_get_handler_data(desc);
> > > + struct irq_chip *irqchip = irq_desc_get_chip(desc);
> > > +
On 31/07/2019 23:41, Suman Anna wrote:
> From: "Andrew F. Davis"
>
> 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
On 31/07/2019 23:41, Suman Anna wrote:
> The PRUSS INTC receives a number of system input interrupt source events
> and supports individual control configuration and hardware prioritization.
> These input events can be mapped to some output interrupt lines through 2
> levels of many-to-one mapping
Hi Thomas,
Here's a small bunch of fixes from the irqchip department. Nothing
major, just a number of fixes for error paths, a GPCv2 irq_set_type()
fix, and a bunch of /* fall-though */ annotation to keep the build
quiet.
Please pull.
M.
The following changes since commit 3dae67ce600caa
On 30/07/2019 11:58, Chuhong Yuan wrote:
> Thomas Gleixner 于2019年7月30日周二 下午5:17写道：
>>
>> On Mon, 29 Jul 2019, Chuhong Yuan wrote:
>>
>>> strncmp(str, const, len) is error-prone.
>>> We had better use newly introduced
>>> str_has_prefix() instead of it.
>>
>> Can you please provide a proper explana
[+ Zhou Yanjie]
Paul,
On 27/07/2019 20:17, Paul Cercueil wrote:
> Get the virq number from the IRQ domain instead of calculating it from
> the hardcoded irq base.
>
> Signed-off-by: Paul Cercueil
> ---
> drivers/irqchip/irq-ingenic.c | 7 ++-
> 1 file changed, 6 insertions(+), 1 deletion(-
On 29/07/2019 01:11, Matteo Croce wrote:
> Mark switch cases where we are expecting to fall through,
> fixes the following warnings:
>
> drivers/irqchip/irq-gic-v3.c: In function ‘gic_cpu_sys_reg_init’:
> ./arch/arm64/include/asm/sysreg.h:853:2: warning: this statement may fall
> through [-Wimpli
On 29/07/2019 00:19, Matteo Croce wrote:
> Mark switch cases where we are expecting to fall through,
> fixes a 130+ lines warning.
>
> Signed-off-by: Matteo Croce
> ---
> arch/arm64/kvm/hyp/debug-sr.c | 30 ++
> 1 file changed, 30 insertions(+)
>
> diff --git a/arch/
On 28/07/2019 23:53, Matteo Croce wrote:
> Mark switch cases where we are expecting to fall through,
> fixes the following warning:
>
> In file included from ./arch/arm64/include/asm/kvm_emulate.h:19,
> from arch/arm64/kvm/regmap.c:13:
> arch/arm64/kvm/regmap.c: In function ‘vcpu_
On Sat, 27 Jul 2019 18:53:15 +0100,
Martin Blumenstingl wrote:
>
> EBU provides an interrupt line for the PCI_INTA interrupt. Route
> easy50712's PCI interrupt to EBU so the interrupt line is configured
> correctly (using IRQ_TYPE_LEVEL_LOW, this was previously hardcoded in
> the PCI driver) and
Hi Martin,
On Sat, 27 Jul 2019 18:53:13 +0100,
Martin Blumenstingl wrote:
>
> The PCI_INTA on Lantiq SoCs is a chained interrupt:
> EBU configures the interrupt type, has a registers to enable/disable
> and ACK the interrupt. This is chained with the ICU interrupt where the
> parent interrupt of
On Tue, 25 Jun 2019 16:47:17 +0100,
Charles Keepax wrote:
>
> GPL-2.0-only is the preferred way of expressing v2 of the GPL, update
> the code to use this.
>
> Signed-off-by: Charles Keepax
> ---
> drivers/irqchip/irq-madera.c | 2 +-
> include/linux/irqchip/irq-madera.h | 2 +-
> 2 file
ot;)
> Signed-off-by: Wen Yang
> Cc: Thomas Gleixner
> Cc: Jason Cooper
> Cc: Marc Zyngier
> Cc: Geert Uytterhoeven
> Cc: Chris Brandt
> Cc: Simon Horman
> Cc: linux-kernel@vger.kernel.org
> ---
> drivers/irqchip/irq-renesas-rza1.c | 15 ---
>
On Mon, 15 Jul 2019 13:09:50 +0100,
Zhou Yanjie wrote:
>
> Add the interrupt-controller bindings for the JZ4760 Soc and
> the JZ4760B Soc from Ingenic.
>
> Signed-off-by: Zhou Yanjie
> ---
> Documentation/devicetree/bindings/interrupt-controller/ingenic,intc.txt | 2
> ++
> 1 file changed, 2
On Tue, 23 Jul 2019 11:39:10 +0100,
Nishka Dasgupta wrote:
>
> Each iteration of for_each_child_of_node puts the previous node, but
> in the case of a return from the middle of the loop, there is no put,
> thus causing a memory leak. Add an of_node_put before the return in
> three places.
> Issue
On Fri, 26 Jul 2019 10:32:57 +0100,
Shaokun Zhang wrote:
>
> From: Nianyao Tang
>
> In its_vpe_init, when its_alloc_vpe_table fails, we should free
> vpt_page allocated just before, instead of vpe->vpt_page.
> Let's fix it.
>
> Cc: Thomas Gleixner
> C
On Fri, 26 Jul 2019 12:28:26 +0100,
Anders Roxell wrote:
>
> When fall-through warnings was enabled by default the following warning
> was starting to show up:
>
> In file included from ../arch/arm64/include/asm/cputype.h:132,
> from ../arch/arm64/include/asm/cache.h:8,
>
On Fri, 26 Jul 2019 12:27:10 +0100,
Anders Roxell wrote:
>
> When fall-through warnings was enabled by default the following warnings
> was starting to show up:
>
> ../arch/arm64/kvm/hyp/debug-sr.c: In function ‘__debug_save_state’:
> ../arch/arm64/kvm/hyp/debug-sr.c:20:19: warning: this stateme
Hi Anders,
On Fri, 26 Jul 2019 12:27:05 +0100,
Anders Roxell wrote:
>
> When fall-through warnings was enabled by default, commit d93512ef0f0e
> ("Makefile: Globally enable fall-through warning"), the following
> warnings was starting to show up:
>
> In file included from ../arch/arm64/include/
On Fri, 26 Jul 2019 09:51:45 +0800
Shaokun Zhang wrote:
> From: Nianyao Tang
>
> In its_vpe_init, when its_alloc_vpe_table fails, we should free
> vpt_page allocated just before, instead of vpe->vpt_page.
> Let's fix it.
>
> Cc: Thomas Gleixner
> Cc:
On Tue, 23 Jul 2019 14:52:34 -0700
pher...@codeaurora.org wrote:
Hi Prakruthi,
> Hi,
>
> I have been working on a interrupt controller driver that uses tree
> based mapping for its domain (irq_domain_add_tree(..)).
> If I understand correctly, the clients get a mapping when they call
> platform_
On 23/07/2019 13:59, Lokesh Vutla wrote:
>
>
> On 23/07/19 4:14 PM, Marc Zyngier wrote:
>> GICv3.1 introduces support for new interrupt ranges, one of them being
>> the Extended SPI range (ESPI). The DT binding is extended to deal with
>> it as a new interrupt class
On 23/07/2019 13:50, Lokesh Vutla wrote:
>
>
> On 23/07/19 4:14 PM, Marc Zyngier wrote:
>> Add the required support for the ESPI range, which behave exactly like
>> the SPIs of old, only with new funky INTIDs.
>>
>> Signed-off-by: Marc Zyngier
>> ---
>
Expand the pre-existing PPI support to be able to deal with the
Extended PPI range (EPPI). This includes obtaining the number of PPIs
from each individual redistributor, and compute the minimum set
(just in case someone builds something really clever...).
Signed-off-by: Marc Zyngier
---
drivers
configuration register for the considered interrupt.
At the same time, move part of the error handling back to the
individual drivers, as things are about to change on that front.
Signed-off-by: Marc Zyngier
---
drivers/irqchip/irq-gic-common.c | 14 +-
drivers/irqchip/irq-gic-v3.c
Update the GICv3 binding to allow interrupts in the EPPI range.
Signed-off-by: Marc Zyngier
---
.../devicetree/bindings/interrupt-controller/arm,gic-v3.yaml | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git
a/Documentation/devicetree/bindings/interrupt-controller/arm,gic
Again, PPIs are becoming a variable set. Let's hack the PPI partition
code to make the top-level array dynamically allocated.
Signed-off-by: Marc Zyngier
---
drivers/irqchip/irq-gic-v3.c | 14 +++---
1 file changed, 11 insertions(+), 3 deletions(-)
diff --git a/drivers/irqchip/ir
As we're about to have a variable number of PPIs, let's make the
allocation of the NMI refcounts dynamic. Also apply some minor
cleanups (moving things around).
Signed-off-by: Marc Zyngier
---
drivers/irqchip/irq-gic-v3.c | 47 ++--
1 file changed, 34
.
No functional change.
Signed-off-by: Marc Zyngier
---
drivers/irqchip/irq-gic-common.c | 19 ---
drivers/irqchip/irq-gic-common.h | 2 +-
drivers/irqchip/irq-gic-v3.c | 22 +++---
drivers/irqchip/irq-gic.c| 2 +-
drivers/irqchip/irq-hip04.c | 2
GICv3.1 introduces support for new interrupt ranges, one of them being
the Extended SPI range (ESPI). The DT binding is extended to deal with
it as a new interrupt class.
Signed-off-by: Marc Zyngier
---
.../devicetree/bindings/interrupt-controller/arm,gic-v3.yaml | 5 +++--
1 file changed, 3
Add the required support for the ESPI range, which behave exactly like
the SPIs of old, only with new funky INTIDs.
Signed-off-by: Marc Zyngier
---
drivers/irqchip/irq-gic-v3.c | 85 --
include/linux/irqchip/arm-gic-v3.h | 17 +-
2 files changed, 85
range. Boo.
In order to make our life less hellish, let's introduce a set of primitives
that will allow ranges to be identified easily and offsets to be remapped.
So far, there is no functionnal change.
Signed-off-by: Marc Zyngier
---
drivers/irqchip/irq-gic-v3.c | 112 +++
requires a bit of
infrastructure rework in order to make the thing less horrible...
This has been tested on a FastModel.
[1] https://developer.arm.com/docs/ihi0069/latest (version E)
Marc Zyngier (9):
irqchip/gic: Rework gic_configure_irq to take the full ICFGR base
irqchip/gic-v3: Add INTID
On Mon, 22 Jul 2019 21:52:42 +0100,
Pavel Tatashin wrote:
>
> On Mon, Jul 22, 2019 at 3:33 AM Marc Zyngier wrote:
> >
> > So far, we've let the arm64 kernel start its meaningful time stamping
> > of the kernel log pretty late, which is caused by sched_clock() bein
On Mon, 22 Jul 2019 09:21:21 -0700
Sowjanya Komatineni wrote:
> On 7/22/19 3:57 AM, Dmitry Osipenko wrote:
> > 22.07.2019 13:13, Marc Zyngier пишет:
> >> On 22/07/2019 10:54, Dmitry Osipenko wrote:
> >>> 21.07.2019 22:40, Sowjanya Komatineni пишет:
> >
Hi John,
On 22/07/2019 15:14, John Garry wrote:
> Hi Thomas,
>
> I have a question on commit cbf866a6 ("genirq: Let irq thread follow
> the effective hard irq affinity"), if you could kindly check:
>
> Here we set the thread affinity to be the same as the hard interrupt
> affinity. For an
On 22/07/2019 14:03, Russell King - ARM Linux admin wrote:
> On Mon, Jul 22, 2019 at 01:47:57PM +0100, Marc Zyngier wrote:
>> On 22/07/2019 12:25, Petr Mladek wrote:
>>> On Mon 2019-07-22 11:33:28, Marc Zyngier wrote:
>>>> printk currently relies on local_
On 22/07/2019 12:25, Petr Mladek wrote:
> On Mon 2019-07-22 11:33:28, Marc Zyngier wrote:
>> printk currently relies on local_clock to time-stamp the kernel
>> messages. In order to allow the timestamping (and only that)
>> to be overridden by architecture-specific code, l
series adds the necessary logic to arm64,
allowing the (potentially unreliable) time stamping of early kernel
messages.
Tested on a bunch of arm64 systems, both bare-metal and in VMs. Boot
tested on a x86 guest.
[1] https://lore.kernel.org/patchwork/patch/1015110/
Marc Zyngier (3):
printk: All
this facility will
have to define CONFIG_ARCH_HAS_TIMESTAMP_CLOCK.
The default is of course to return local_clock(), so that the
existing behaviour stays unchanged.
Signed-off-by: Marc Zyngier
---
include/linux/sched/clock.h | 13 +
kernel/printk/printk.c | 4 ++--
2 files ch
time stamps are continuous and that there
is no jitter other than that introduced by the lack of quality
of the timestamping clock.
Signed-off-by: Marc Zyngier
---
kernel/time/sched_clock.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/kernel/time/sched_clock.c b/kernel/time
1601 - 1700 of 4221 matches
Mail list logo
