Re: [PATCH v4 2/4] arm64: Work around Falkor erratum 1003
On 31/01/17 17:48, Christopher Covington wrote: > On 01/31/2017 07:37 AM, Mark Rutland wrote: >> On Wed, Jan 25, 2017 at 10:52:30AM -0500, Christopher Covington wrote: >>> The Qualcomm Datacenter Technologies Falkor v1 CPU may allocate TLB entries >>> using an incorrect ASID when TTBRx_EL1 is being updated. When the erratum >>> is triggered, page table entries using the new translation table base >>> address (BADDR) will be allocated into the TLB using the old ASID. All >>> circumstances leading to the incorrect ASID being cached in the TLB arise >>> when software writes TTBRx_EL1[ASID] and TTBRx_EL1[BADDR], a memory >>> operation is in the process of performing a translation using the specific >>> TTBRx_EL1 being written, and the memory operation uses a translation table >>> descriptor designated as non-global. EL2 and EL3 code changing the EL1&0 >>> ASID is not subject to this erratum because hardware is prohibited from >>> performing translations from an out-of-context translation regime. >>> >>> Consider the following pseudo code. >>> >>> write new BADDR and ASID values to TTBRx_EL1 >>> >>> Replacing the above sequence with the one below will ensure that no TLB >>> entries with an incorrect ASID are used by software. >>> >>> write reserved value to TTBRx_EL1[ASID] >>> ISB >>> write new value to TTBRx_EL1[BADDR] >>> ISB >>> write new value to TTBRx_EL1[ASID] >>> ISB >>> >>> When the above sequence is used, page table entries using the new BADDR >>> value may still be incorrectly allocated into the TLB using the reserved >>> ASID. Yet this will not reduce functionality, since TLB entries incorrectly >>> tagged with the reserved ASID will never be hit by a later instruction. >> >> Based on my understanding that entries allocated to the reserved ASID >> will not be used for subsequent page table walks (and so we don't have >> asynchronous behaviour to contend with), this sounds fine to me. >> >> Thanks for taking the time to clarify the details on that. >> >>> Based on work by Shanker Donthineni >>> >>> Signed-off-by: Christopher Covington >>> --- >>> Documentation/arm64/silicon-errata.txt | 1 + >>> arch/arm64/Kconfig | 11 +++ >>> arch/arm64/include/asm/assembler.h | 23 +++ >>> arch/arm64/include/asm/cpucaps.h | 3 ++- >>> arch/arm64/include/asm/mmu_context.h | 8 +++- >>> arch/arm64/kernel/cpu_errata.c | 7 +++ >>> arch/arm64/mm/context.c| 11 +++ >>> arch/arm64/mm/proc.S | 1 + >>> 8 files changed, 63 insertions(+), 2 deletions(-) >> >> Don't we need to use pre_ttbr0_update_workaround in >> for CONFIG_ARM64_SW_TTBR0_PAN? We implicitly switch to the reserved ASID >> for the empty table in __uaccess_ttbr0_disable. >> >> That also means we have to invalidate the reserved ASID so as to not >> accidentally hit while uaccess is disabled. > > The CPU in question (Falkor v1) has hardware PAN support. Do we need > to worry about including the workaround in the SW PAN code in that case? Given that all ARMv8 CPUs can support SW_PAN, it is more likely to be enabled than the ARMv8.1 PAN. I'd vote for supporting the workaround in that case too, and hope that people do enable the HW version. Thanks, M. -- Jazz is not dead. It just smells funny... -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] tty: pl011: Work around QDF2400 E44 stuck BUSY bit
On Wed, Feb 08 2017 at 2:09:12 pm GMT, Timur Tabi wrote: > Mark Rutland wrote: > >>> No, only Kryo and Falkor V1 based SOCs have this problem. Falkor V2 >>> will have this fixed. We intend to revert these fixes after Falkor >>> V1 SOCs are no longer supported. >> >> Supported by whom? > > Qualcomm. > >> Generally, once something's upstreamed we expect it to remain supported. > > The V1 SOCs are technically pre-production, but still in wide use and > it will be a while before they are all replaced by V2 SOCs. It's only > because of the "ugliness" of the erratum and its work-around that we > want to git rid of it when we can. Interesting. How will you guarantee that nobody will ever want to run a mainline kernel on this box after a certain date? Self-destruct timer? ;-) As someone who runs mainline on HW that exceeded its "sell-by" date by a few decades, I'm genuinely interested. Thanks, M. -- Jazz is not dead, it just smell funny. -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] irqchip/gicv3-its: Add workaround for QDF2400 ITS erratum 0065
On Sun, Mar 05 2017 at 3:23:56 pm GMT, Shanker Donthineni
wrote:
> On Qualcomm Datacenter Technologies QDF2400 SoCs, the ITS hardware
> implementation uses 16Bytes for Interrupt Translation Entry (ITTE),
nit: Interrupt Translation Entry is abbreviated as ITE. I know the vITS
has the ITTE thing all over the place, which I plan to address. No need
to respin for that.
> but reports an incorrect value of 8Bytes in GITS_TYPER.ITTE_size.
>
> It might cause kernel memory corruption depending on the number
> of MSI(x) that are configured and the amount of memory that has
> been allocated for ITTEs in its_create_device().
>
> This patch fixes the potential memory corruption by setting the
> correct ITTE size to 16Bytes.
>
> Signed-off-by: Shanker Donthineni
> ---
> Documentation/arm64/silicon-errata.txt | 1 +
> arch/arm64/Kconfig | 10 ++
> drivers/irqchip/irq-gic-v3-its.c | 16
> 3 files changed, 27 insertions(+)
>
> diff --git a/Documentation/arm64/silicon-errata.txt
> b/Documentation/arm64/silicon-errata.txt
> index a71b809..2f66683 100644
> --- a/Documentation/arm64/silicon-errata.txt
> +++ b/Documentation/arm64/silicon-errata.txt
> @@ -68,3 +68,4 @@ stable kernels.
> || | |
> |
> | Qualcomm Tech. | Falkor v1 | E1003 |
> QCOM_FALKOR_ERRATUM_1003|
> | Qualcomm Tech. | Falkor v1 | E1009 |
> QCOM_FALKOR_ERRATUM_1009|
> +| Qualcomm Tech. | QDF2400 ITS | E0065 |
> QCOM_QDF2400_ERRATUM_0065 |
> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> index 896eba6..6bd51fb 100644
> --- a/arch/arm64/Kconfig
> +++ b/arch/arm64/Kconfig
> @@ -509,6 +509,16 @@ config QCOM_FALKOR_ERRATUM_1009
>
> If unsure, say Y.
>
> +config QCOM_QDF2400_ERRATUM_0065
> + bool "QDF2400 E0065: Incorrect GITS_TYPER.ITT_Entry_size"
> + default y
> + help
> + On Qualcomm Datacenter Technologies QDF2400 SoC, ITS hardware reports
> + ITTE size incorrectly. The GITS_TYPER.ITT_Entry_size field should have
> + been indicated as 16Bytes (0xf), not 8Bytes (0x7).
> +
> + If unsure, say Y.
> +
> endmenu
>
>
> diff --git a/drivers/irqchip/irq-gic-v3-its.c
> b/drivers/irqchip/irq-gic-v3-its.c
> index 2320100..86bd428 100644
> --- a/drivers/irqchip/irq-gic-v3-its.c
> +++ b/drivers/irqchip/irq-gic-v3-its.c
> @@ -1601,6 +1601,14 @@ static void __maybe_unused
> its_enable_quirk_cavium_23144(void *data)
> its->flags |= ITS_FLAGS_WORKAROUND_CAVIUM_23144;
> }
>
> +static void __maybe_unused its_enable_quirk_qdf2400_e0065(void *data)
> +{
> + struct its_node *its = data;
> +
> + /* On QDF2400, the size of the ITTE is 16Bytes */
> + its->ite_size = 16;
> +}
> +
> static const struct gic_quirk its_quirks[] = {
> #ifdef CONFIG_CAVIUM_ERRATUM_22375
> {
> @@ -1618,6 +1626,14 @@ static void __maybe_unused
> its_enable_quirk_cavium_23144(void *data)
> .init = its_enable_quirk_cavium_23144,
> },
> #endif
> +#ifdef CONFIG_QCOM_QDF2400_ERRATUM_0065
> + {
> + .desc = "ITS: QDF2400 erratum 0065",
> + .iidr = 0x1070, /* QDF2400 ITS rev 1.x */
> + .mask = 0x,
> + .init = its_enable_quirk_qdf2400_e0065,
> + },
> +#endif
> {
> }
> };
OK, that's pretty bad. Should this be CC stable?
Thanks,
M.
--
Jazz is not dead, it just smell funny.
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Add initial SX3000b platform code to MIPS arch
Hi Amit, On 22/03/17 05:38, Amit Kama IL wrote: > Add initial support for boards based on Satixfy's SX3000b (Catniss) SoC. > The SoC includes a MIPS interAptiv dual core 4 VPE processor and boots > using device-tree. > > Signed-off-by: Amit Kama > > The irqchip file (irq-sx3000b.c) is pertinent to the platform. > IRQCHIP maintainers - is it possible to merge this through MIPS tree? Can you please send something that is the result of "git format-patch"? You should have a diff-stat before the patch itself... Also, this file (irq-sx3000b.c) doesn't seem to be in this huge patch, which doesn't seem to concern the irqchip subsystem (it all looks platform code to me). Wrong patch? Thanks, M. -- Jazz is not dead. It just smells funny... -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] arm64: fix documentation on kernel pages mappings to HYP VA
On Tue, Sep 26 2017 at 9:45:42 pm BST, Yury Norov wrote: > Ping? > > On Wed, Sep 13, 2017 at 09:08:30PM +0300, Yury Norov wrote: >> The Documentation/arm64/memory.txt says: >> When using KVM, the hypervisor maps kernel pages in EL2, at a fixed >> offset from the kernel VA (top 24bits of the kernel VA set to zero): >> >> In fact, kernel addresses are transleted to HYP with kern_hyp_va macro, >> which has more options, and none of them assumes clearing of top 24bits >> of the kernel VA. >> >> Signed-off-by: Yury Norov >> --- >> Documentation/arm64/memory.txt | 15 +-- >> 1 file changed, 9 insertions(+), 6 deletions(-) >> >> diff --git a/Documentation/arm64/memory.txt b/Documentation/arm64/memory.txt >> index d7273a5f6456..c39895d7e3a2 100644 >> --- a/Documentation/arm64/memory.txt >> +++ b/Documentation/arm64/memory.txt >> @@ -86,9 +86,12 @@ Translation table lookup with 64KB pages: >> +-> [63] TTBR0/1 >> >> >> -When using KVM, the hypervisor maps kernel pages in EL2, at a fixed >> -offset from the kernel VA (top 24bits of the kernel VA set to zero): >> - >> -Start End SizeUse >> >> -0040007f 256GB kernel objects >> mapped in HYP >> +When using KVM without Virtualization Host Extensions, the hypervisor maps >> +kernel pages in EL2, at a fixed offset from the kernel VA. Namely, top 16 >> +or 25 bits of the kernel VA set to zero depending on ARM64_VA_BITS_48 or >> +ARM64_VA_BITS_39 config option selected; or top 17 or 26 bits of the kernel >> +VA set to zero if CPU has Reduced HYP mapping offset capability. See >> +kern_hyp_va macro. What is this "Reduced HYP mapping offset capability"? You're missing the point that the location of the EL2 mapping is conditioned by the location of the identity mapping that is used to bring up / tear down KVM. You have to express the VA transformation in terms of both VA_BITS (and there is more cases than just 39 or 48 bits) *and* the idmap address, not to mention the case where KVM's VA_BITS is larger than the rest of the kernel. See the extensive blurb in kvm_mmu.h. >> + >> +When using KVM with Virtualization Host Extensions, no additional mappings >> +created as host kernel already operates in EL2. This bit is fine. Thanks, M. -- Jazz is not dead. It just smells funny. -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] arm64: fix documentation on kernel pages mappings to HYP VA
On Wed, Sep 27 2017 at 10:13:33 am BST, Will Deacon wrote: > On Wed, Sep 27, 2017 at 09:31:41AM +0100, Marc Zyngier wrote: >> On Tue, Sep 26 2017 at 9:45:42 pm BST, Yury Norov >> wrote: >> > On Wed, Sep 13, 2017 at 09:08:30PM +0300, Yury Norov wrote: >> >> The Documentation/arm64/memory.txt says: >> >> When using KVM, the hypervisor maps kernel pages in EL2, at a fixed >> >> offset from the kernel VA (top 24bits of the kernel VA set to zero): >> >> >> >> In fact, kernel addresses are transleted to HYP with kern_hyp_va macro, >> >> which has more options, and none of them assumes clearing of top 24bits >> >> of the kernel VA. >> >> >> >> Signed-off-by: Yury Norov >> >> --- >> >> Documentation/arm64/memory.txt | 15 +-- >> >> 1 file changed, 9 insertions(+), 6 deletions(-) >> >> >> >> diff --git a/Documentation/arm64/memory.txt >> >> b/Documentation/arm64/memory.txt >> >> index d7273a5f6456..c39895d7e3a2 100644 >> >> --- a/Documentation/arm64/memory.txt >> >> +++ b/Documentation/arm64/memory.txt >> >> @@ -86,9 +86,12 @@ Translation table lookup with 64KB pages: >> >> +-> [63] TTBR0/1 >> >> >> >> >> >> -When using KVM, the hypervisor maps kernel pages in EL2, at a fixed >> >> -offset from the kernel VA (top 24bits of the kernel VA set to zero): >> >> - >> >> -StartEnd SizeUse >> >> >> >> -0040 007f 256GB kernel objects >> >> mapped in HYP >> >> +When using KVM without Virtualization Host Extensions, the hypervisor >> >> maps >> >> +kernel pages in EL2, at a fixed offset from the kernel VA. Namely, top 16 >> >> +or 25 bits of the kernel VA set to zero depending on ARM64_VA_BITS_48 or >> >> +ARM64_VA_BITS_39 config option selected; or top 17 or 26 bits of the >> >> kernel >> >> +VA set to zero if CPU has Reduced HYP mapping offset capability. See >> >> +kern_hyp_va macro. >> >> What is this "Reduced HYP mapping offset capability"? >> >> You're missing the point that the location of the EL2 mapping is >> conditioned by the location of the identity mapping that is used to >> bring up / tear down KVM. You have to express the VA transformation in >> terms of both VA_BITS (and there is more cases than just 39 or 48 bits) >> *and* the idmap address, not to mention the case where KVM's VA_BITS is >> larger than the rest of the kernel. See the extensive blurb in >> kvm_mmu.h. >> >> >> + >> >> +When using KVM with Virtualization Host Extensions, no additional >> >> mappings >> >> +created as host kernel already operates in EL2. >> >> This bit is fine. > > FWIW, I was going to queue a simplified version along the lines of the patch > below. > > Will > > --->8 > > commit dbf7393b7738a0ba0284551e7b6e014cfb100661 > Author: Yury Norov > Date: Wed Sep 13 21:08:30 2017 +0300 > > arm64: fix documentation on kernel pages mappings to HYP VA > > The Documentation/arm64/memory.txt says: > When using KVM, the hypervisor maps kernel pages in EL2, at a fixed > offset from the kernel VA (top 24bits of the kernel VA set to zero): > > In fact, kernel addresses are transleted to HYP with kern_hyp_va macro, > which has more options, and none of them assumes clearing of top 24bits > of the kernel VA. > > Signed-off-by: Yury Norov > [will: removed gory details] > Signed-off-by: Will Deacon > > diff --git a/Documentation/arm64/memory.txt b/Documentation/arm64/memory.txt > index d7273a5f6456..ea9ee39784a2 100644 > --- a/Documentation/arm64/memory.txt > +++ b/Documentation/arm64/memory.txt > @@ -86,9 +86,9 @@ Translation table lookup with 64KB pages: > +-> [63] TTBR0/1 > > > -When using KVM, the hypervisor maps kernel pages in EL2, at a fixed > -offset from the kernel VA (top 24bits of the kernel VA set to zero): > +When using KVM without the Virtualization Host Extensions, the hypervisor > +maps kernel pages in EL2 at a fixed offset from the kernel VA. See the > +kern_hyp_va macro for more details. > > -StartEnd SizeUse > > -0040 007f 256GB kernel objects > mapped in HYP > +When using KVM with the Virtualization Host Extensions, no additional > +mappings are created, since the host kernel runs directly in EL2. Acked-by: Marc Zyngier M. -- Jazz is not dead. It just smells funny. -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] irqchip/gic-v3-its: Add workaround for ThunderX2 erratum #174
On 03/01/18 06:32, Ganapatrao Kulkarni wrote:
> When an interrupt is moved across node collections on ThunderX2
node collections?
> multi Socket platform, an interrupt stops routed to new collection
> and results in loss of interrupts.
>
> Adding workaround to issue INV after MOVI for cross-node collection
> move to flush out the cached entry.
>
> Signed-off-by: Ganapatrao Kulkarni
> ---
> Documentation/arm64/silicon-errata.txt | 1 +
> arch/arm64/Kconfig | 11 +++
> drivers/irqchip/irq-gic-v3-its.c | 24
> 3 files changed, 36 insertions(+)
>
> diff --git a/Documentation/arm64/silicon-errata.txt
> b/Documentation/arm64/silicon-errata.txt
> index fc1c884..fb27cb5 100644
> --- a/Documentation/arm64/silicon-errata.txt
> +++ b/Documentation/arm64/silicon-errata.txt
> @@ -63,6 +63,7 @@ stable kernels.
> | Cavium | ThunderX Core | #27456 | CAVIUM_ERRATUM_27456
> |
> | Cavium | ThunderX Core | #30115 | CAVIUM_ERRATUM_30115
> |
> | Cavium | ThunderX SMMUv2 | #27704 | N/A
> |
> +| Cavium | ThunderX2 ITS | #174| CAVIUM_ERRATUM_174
> |
> | Cavium | ThunderX2 SMMUv3| #74 | N/A
> |
> | Cavium | ThunderX2 SMMUv3| #126| N/A
> |
> || | |
> |
> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> index c9a7e9e..71a7e30 100644
> --- a/arch/arm64/Kconfig
> +++ b/arch/arm64/Kconfig
> @@ -461,6 +461,17 @@ config ARM64_ERRATUM_843419
>
> If unsure, say Y.
>
> +config CAVIUM_ERRATUM_174
> + bool "Cavium ThunderX2 erratum 174"
> + depends on NUMA
Why? This system will be affected no matter whether NUMA is selected or not.
> + default y
> + help
> + LPI stops routed to redistributors after inter node collection
> + move in ITS. Enable workaround to invalidate ITS entry after
> + inter-node collection move.
That's a very terse description. Nobody knows what an LPI, a
redistributor or a collection is. Please explain what the erratum is in
layman's terms (Cavium ThunderX2 systems may loose interrupts on
affinity change) so that people understand whether or not they are affected.
> +
> + If unsure, say Y.
> +
> config CAVIUM_ERRATUM_22375
> bool "Cavium erratum 22375, 24313"
> default y
> diff --git a/drivers/irqchip/irq-gic-v3-its.c
> b/drivers/irqchip/irq-gic-v3-its.c
> index 06f025f..d8b9c96 100644
> --- a/drivers/irqchip/irq-gic-v3-its.c
> +++ b/drivers/irqchip/irq-gic-v3-its.c
> @@ -46,6 +46,7 @@
> #define ITS_FLAGS_CMDQ_NEEDS_FLUSHING(1ULL << 0)
> #define ITS_FLAGS_WORKAROUND_CAVIUM_22375(1ULL << 1)
> #define ITS_FLAGS_WORKAROUND_CAVIUM_23144(1ULL << 2)
> +#define ITS_FLAGS_WORKAROUND_CAVIUM_174 (1ULL << 3)
>
> #define RDIST_FLAGS_PROPBASE_NEEDS_FLUSHING (1 << 0)
>
> @@ -1119,6 +1120,12 @@ static int its_set_affinity(struct irq_data *d, const
> struct cpumask *mask_val,
> if (cpu != its_dev->event_map.col_map[id]) {
> target_col = &its_dev->its->collections[cpu];
> its_send_movi(its_dev, target_col, id);
> + if (its_dev->its->flags & ITS_FLAGS_WORKAROUND_CAVIUM_174) {
> + /* Issue INV for cross node collection move. */
> + if (cpu_to_node(cpu) !=
> + cpu_to_node(its_dev->event_map.col_map[id]))
> + its_send_inv(its_dev, id);
> + }
What happens if an interrupt happens after the MOV, but before the INV?
> its_dev->event_map.col_map[id] = cpu;
> irq_data_update_effective_affinity(d, cpumask_of(cpu));
> }
> @@ -2904,6 +2911,15 @@ static int its_force_quiescent(void __iomem *base)
> }
> }
>
> +static bool __maybe_unused its_enable_quirk_cavium_174(void *data)
> +{
> + struct its_node *its = data;
> +
> + its->flags |= ITS_FLAGS_WORKAROUND_CAVIUM_174;
> +
> + return true;
> +}
> +
> static bool __maybe_unused its_enable_quirk_cavium_22375(void *data)
> {
> struct its_node *its = data;
> @@ -3031,6 +3047,14 @@ static const struct gic_quirk its_quirks[] = {
> .init = its_enable_quirk_hip07_161600802,
> },
> #endif
> +#ifdef CONFIG_CAVIUM_ERRATUM_174
> + {
> + .desc = "ITS: Cavium ThunderX2 erratum 174",
> + .iidr = 0x13f,/* ThunderX2 pass A1/A2/B0 */
Do all 3 revisions have the same IIDR?
> + .mask = 0x,
> + .init = its_enable_quirk_cavium_174,
> + },
> +#endif
> {
> }
> };
>
Thanks,
M.
--
Jazz is not dead. It just smells funny...
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of
Re: [PATCH] irqchip/gic-v3-its: Add workaround for ThunderX2 erratum #174
On 03/01/18 09:35, Ganapatrao Kulkarni wrote: > Hi Marc, > > On Wed, Jan 3, 2018 at 2:17 PM, Marc Zyngier wrote: >> On 03/01/18 06:32, Ganapatrao Kulkarni wrote: >>> When an interrupt is moved across node collections on ThunderX2 >> >> node collections? > > ok, i will rephrase it. > i was intended to say cross NUMA node collection/cpu affinity change. > >> >>> multi Socket platform, an interrupt stops routed to new collection >>> and results in loss of interrupts. >>> >>> Adding workaround to issue INV after MOVI for cross-node collection >>> move to flush out the cached entry. >>> >>> Signed-off-by: Ganapatrao Kulkarni >>> --- >>> Documentation/arm64/silicon-errata.txt | 1 + >>> arch/arm64/Kconfig | 11 +++ >>> drivers/irqchip/irq-gic-v3-its.c | 24 >>> 3 files changed, 36 insertions(+) >>> >>> diff --git a/Documentation/arm64/silicon-errata.txt >>> b/Documentation/arm64/silicon-errata.txt >>> index fc1c884..fb27cb5 100644 >>> --- a/Documentation/arm64/silicon-errata.txt >>> +++ b/Documentation/arm64/silicon-errata.txt >>> @@ -63,6 +63,7 @@ stable kernels. >>> | Cavium | ThunderX Core | #27456 | >>> CAVIUM_ERRATUM_27456| >>> | Cavium | ThunderX Core | #30115 | >>> CAVIUM_ERRATUM_30115| >>> | Cavium | ThunderX SMMUv2 | #27704 | N/A >>> | >>> +| Cavium | ThunderX2 ITS | #174| CAVIUM_ERRATUM_174 >>> | >>> | Cavium | ThunderX2 SMMUv3| #74 | N/A >>> | >>> | Cavium | ThunderX2 SMMUv3| #126| N/A >>> | >>> || | | >>> | >>> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig >>> index c9a7e9e..71a7e30 100644 >>> --- a/arch/arm64/Kconfig >>> +++ b/arch/arm64/Kconfig >>> @@ -461,6 +461,17 @@ config ARM64_ERRATUM_843419 >>> >>> If unsure, say Y. >>> >>> +config CAVIUM_ERRATUM_174 >>> + bool "Cavium ThunderX2 erratum 174" >>> + depends on NUMA >> >> Why? This system will be affected no matter whether NUMA is selected or not. > > it does not makes sense to enable on non-NUMA/single socket platforms. > By default NUMA is enabled on ThunderX2 dual socket platforms. config ARCH_THUNDER2 bool "Cavium ThunderX2 Server Processors" select GPIOLIB help This enables support for Cavium's ThunderX2 CN99XX family of server processors. Do you see any NUMA here? I can perfectly compile a kernel with both sockets, and not using NUMA. NUMA has to do with memory, and not interrupts. > >> >>> + default y >>> + help >>> + LPI stops routed to redistributors after inter node collection >>> + move in ITS. Enable workaround to invalidate ITS entry after >>> + inter-node collection move. >> >> That's a very terse description. Nobody knows what an LPI, a >> redistributor or a collection is. Please explain what the erratum is in >> layman's terms (Cavium ThunderX2 systems may loose interrupts on >> affinity change) so that people understand whether or not they are affected. > > ok, i will rephrase it in next version. >> >>> + >>> + If unsure, say Y. >>> + >>> config CAVIUM_ERRATUM_22375 >>> bool "Cavium erratum 22375, 24313" >>> default y >>> diff --git a/drivers/irqchip/irq-gic-v3-its.c >>> b/drivers/irqchip/irq-gic-v3-its.c >>> index 06f025f..d8b9c96 100644 >>> --- a/drivers/irqchip/irq-gic-v3-its.c >>> +++ b/drivers/irqchip/irq-gic-v3-its.c >>> @@ -46,6 +46,7 @@ >>> #define ITS_FLAGS_CMDQ_NEEDS_FLUSHING(1ULL << 0) >>> #define ITS_FLAGS_WORKAROUND_CAVIUM_22375(1ULL << 1) >>> #define ITS_FLAGS_WORKAROUND_CAVIUM_23144(1ULL << 2) >>> +#define ITS_FLAGS_WORKAROUND_CAVIUM_174 (1ULL << 3) >>> >>> #define RDIST_FLAGS_PROPBASE_NEEDS_FLUSHING (1 << 0) >>> >>> @@ -1119,6 +1120,12 @@ static int its_set_affinity(struct irq_data *d, >>> const struct cpumask *mask_val, >>> if (cpu != its_dev->event_map.
Re: [PATCH] irqchip/gic-v3-its: Add workaround for ThunderX2 erratum #174
On 03/01/18 11:20, Ganapatrao Kulkarni wrote: > On Wed, Jan 3, 2018 at 3:43 PM, Marc Zyngier wrote: >> On 03/01/18 09:35, Ganapatrao Kulkarni wrote: >>> Hi Marc, >>> >>> On Wed, Jan 3, 2018 at 2:17 PM, Marc Zyngier wrote: >>>> On 03/01/18 06:32, Ganapatrao Kulkarni wrote: >>>>> When an interrupt is moved across node collections on ThunderX2 >>>> >>>> node collections? >>> >>> ok, i will rephrase it. >>> i was intended to say cross NUMA node collection/cpu affinity change. >>> >>>> >>>>> multi Socket platform, an interrupt stops routed to new collection >>>>> and results in loss of interrupts. >>>>> >>>>> Adding workaround to issue INV after MOVI for cross-node collection >>>>> move to flush out the cached entry. >>>>> >>>>> Signed-off-by: Ganapatrao Kulkarni >>>>> --- >>>>> Documentation/arm64/silicon-errata.txt | 1 + >>>>> arch/arm64/Kconfig | 11 +++ >>>>> drivers/irqchip/irq-gic-v3-its.c | 24 >>>>> 3 files changed, 36 insertions(+) >>>>> >>>>> diff --git a/Documentation/arm64/silicon-errata.txt >>>>> b/Documentation/arm64/silicon-errata.txt >>>>> index fc1c884..fb27cb5 100644 >>>>> --- a/Documentation/arm64/silicon-errata.txt >>>>> +++ b/Documentation/arm64/silicon-errata.txt >>>>> @@ -63,6 +63,7 @@ stable kernels. >>>>> | Cavium | ThunderX Core | #27456 | >>>>> CAVIUM_ERRATUM_27456| >>>>> | Cavium | ThunderX Core | #30115 | >>>>> CAVIUM_ERRATUM_30115| >>>>> | Cavium | ThunderX SMMUv2 | #27704 | N/A >>>>> | >>>>> +| Cavium | ThunderX2 ITS | #174| >>>>> CAVIUM_ERRATUM_174 | >>>>> | Cavium | ThunderX2 SMMUv3| #74 | N/A >>>>> | >>>>> | Cavium | ThunderX2 SMMUv3| #126| N/A >>>>> | >>>>> || | | >>>>> | >>>>> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig >>>>> index c9a7e9e..71a7e30 100644 >>>>> --- a/arch/arm64/Kconfig >>>>> +++ b/arch/arm64/Kconfig >>>>> @@ -461,6 +461,17 @@ config ARM64_ERRATUM_843419 >>>>> >>>>> If unsure, say Y. >>>>> >>>>> +config CAVIUM_ERRATUM_174 >>>>> + bool "Cavium ThunderX2 erratum 174" >>>>> + depends on NUMA >>>> >>>> Why? This system will be affected no matter whether NUMA is selected or >>>> not. >>> >>> it does not makes sense to enable on non-NUMA/single socket platforms. >>> By default NUMA is enabled on ThunderX2 dual socket platforms. >> >> >> config ARCH_THUNDER2 >> bool "Cavium ThunderX2 Server Processors" >> select GPIOLIB >> help >> This enables support for Cavium's ThunderX2 CN99XX family of >> server processors. >> >> >> Do you see any NUMA here? I can perfectly compile a kernel with both >> sockets, and not using NUMA. NUMA has to do with memory, and not interrupts. > > ok, i will remote it. >> >>> >>>> >>>>> + default y >>>>> + help >>>>> + LPI stops routed to redistributors after inter node collection >>>>> + move in ITS. Enable workaround to invalidate ITS entry after >>>>> + inter-node collection move. >>>> >>>> That's a very terse description. Nobody knows what an LPI, a >>>> redistributor or a collection is. Please explain what the erratum is in >>>> layman's terms (Cavium ThunderX2 systems may loose interrupts on >>>> affinity change) so that people understand whether or not they are >>>> affected. >>> >>> ok, i will rephrase it in next version. >>>> >>>>> + >>>>> + If unsure, say Y. >>>>> + >>>>> config CAVIUM_ERRATUM_22375 >>
Re: [PATCH] irqchip/gic-v3-its: Add workaround for ThunderX2 erratum #174
On 03/01/18 18:13, Ganapatrao Kulkarni wrote: > On Wed, Jan 3, 2018 at 5:06 PM, Marc Zyngier wrote: >> On 03/01/18 11:20, Ganapatrao Kulkarni wrote: >>> On Wed, Jan 3, 2018 at 3:43 PM, Marc Zyngier wrote: >>>> On 03/01/18 09:35, Ganapatrao Kulkarni wrote: >>>>> Hi Marc, >>>>> >>>>> On Wed, Jan 3, 2018 at 2:17 PM, Marc Zyngier wrote: >>>>>> On 03/01/18 06:32, Ganapatrao Kulkarni wrote: >>>>>>> When an interrupt is moved across node collections on ThunderX2 >>>>>> >>>>>> node collections? >>>>> >>>>> ok, i will rephrase it. >>>>> i was intended to say cross NUMA node collection/cpu affinity change. >>>>> >>>>>> >>>>>>> multi Socket platform, an interrupt stops routed to new collection >>>>>>> and results in loss of interrupts. >>>>>>> >>>>>>> Adding workaround to issue INV after MOVI for cross-node collection >>>>>>> move to flush out the cached entry. >>>>>>> >>>>>>> Signed-off-by: Ganapatrao Kulkarni >>>>>>> --- >>>>>>> Documentation/arm64/silicon-errata.txt | 1 + >>>>>>> arch/arm64/Kconfig | 11 +++ >>>>>>> drivers/irqchip/irq-gic-v3-its.c | 24 >>>>>>> 3 files changed, 36 insertions(+) >>>>>>> >>>>>>> diff --git a/Documentation/arm64/silicon-errata.txt >>>>>>> b/Documentation/arm64/silicon-errata.txt >>>>>>> index fc1c884..fb27cb5 100644 >>>>>>> --- a/Documentation/arm64/silicon-errata.txt >>>>>>> +++ b/Documentation/arm64/silicon-errata.txt >>>>>>> @@ -63,6 +63,7 @@ stable kernels. >>>>>>> | Cavium | ThunderX Core | #27456 | >>>>>>> CAVIUM_ERRATUM_27456| >>>>>>> | Cavium | ThunderX Core | #30115 | >>>>>>> CAVIUM_ERRATUM_30115| >>>>>>> | Cavium | ThunderX SMMUv2 | #27704 | N/A >>>>>>> | >>>>>>> +| Cavium | ThunderX2 ITS | #174| >>>>>>> CAVIUM_ERRATUM_174 | >>>>>>> | Cavium | ThunderX2 SMMUv3| #74 | N/A >>>>>>> | >>>>>>> | Cavium | ThunderX2 SMMUv3| #126| N/A >>>>>>> | >>>>>>> || | | >>>>>>> | >>>>>>> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig >>>>>>> index c9a7e9e..71a7e30 100644 >>>>>>> --- a/arch/arm64/Kconfig >>>>>>> +++ b/arch/arm64/Kconfig >>>>>>> @@ -461,6 +461,17 @@ config ARM64_ERRATUM_843419 >>>>>>> >>>>>>> If unsure, say Y. >>>>>>> >>>>>>> +config CAVIUM_ERRATUM_174 >>>>>>> + bool "Cavium ThunderX2 erratum 174" >>>>>>> + depends on NUMA >>>>>> >>>>>> Why? This system will be affected no matter whether NUMA is selected or >>>>>> not. >>>>> >>>>> it does not makes sense to enable on non-NUMA/single socket platforms. >>>>> By default NUMA is enabled on ThunderX2 dual socket platforms. >>>> >>>> >>>> config ARCH_THUNDER2 >>>> bool "Cavium ThunderX2 Server Processors" >>>> select GPIOLIB >>>> help >>>> This enables support for Cavium's ThunderX2 CN99XX family of >>>> server processors. >>>> >>>> >>>> Do you see any NUMA here? I can perfectly compile a kernel with both >>>> sockets, and not using NUMA. NUMA has to do with memory, and not >>>> interrupts. >>> >>> ok, i will remote it. >>>> >>>>> >>>>>> >>>>>>> + default y >>>>>>> + help >>>>>>> + LPI stops routed to redistributors after inter node collection >>&
Re: [PATCH] Documentation/IRQ-domain.txt: Document irq_domain_create_{linear, tree}
On 27/03/16 04:51, Jianyu Zhan wrote:
> They have the same functionalities as irq_domain_add_{linear, tree},
> except fro accepting different first argument.
>
> Signed-off-by: Jianyu Zhan
> ---
> v1->v2:
>Fix spelling error.
>
> Documentation/IRQ-domain.txt | 12
> 1 file changed, 12 insertions(+)
Acked-by: Marc Zyngier
M.
--
Jazz is not dead. It just smells funny...
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] arm64: erratum: Workaround for Kryo reserved system register read
HI Naveen, On 07/04/16 16:54, Naveen Kaje wrote: > The ARMv8.0 architecture reserves several system register > encodings for future use. These encodings should behave > as read-only and always return zero on a read. The Kryo core > errantly causes an instruction abort upon an AArch64 > read attempt to the following system register encodings using > the MRS instruction: >3, 0, C0, [C4-C7], [2-3, 6-7] >3, 0, C0, C3, [3-7] >3, 0, C0, [C4,C6,C7], [4-5] >3, 0, C0, C2, [6-7] > All system register encodings above use the following form > Op0, Op1, CRn, CRm, Op2. > Note that some of the encodings listed above include the system > register space reserved for the following identification registers > which may appear in future revisions of the ARM architecture beyond > ARMv8.0. > > This space includes: > ID_AA64PFR[2-7]_EL1 > ID_AA64DFR[2-3]_EL1 > ID_AA64AFR[2-3]_EL1 > ID_AA64ISAR[2-7]_EL1 > ID_AA64MMFR[2-7]_EL1 > > Workaround: > Software must not rely on a zero value returned from any of the system > register encodings listed above when attempting to determine support for > certain architectural options. Software should instead infer architectural > support when unaffected variant is in use by reading the MIDR_EL1. > > System Impact > None. The required software workaround does not result in any reduction in > functionality nor does it have any relevant impact on performance or power. > > This change uses the ARMv8 implementer introduced in > https://www.mail-archive.com/kvm@vger.kernel.org/msg116473.html > > Change-Id: Id53e335b6c4524c730b95e5dd7279cf870bb82f6 > Signed-off-by: Naveen Kaje > --- > Documentation/arm64/silicon-errata.txt | 29 +++-- > arch/arm64/Kconfig | 29 + > arch/arm64/include/asm/cpufeature.h| 3 ++- > arch/arm64/kernel/cpu_errata.c | 8 > arch/arm64/kernel/cpuinfo.c| 10 +++--- > 5 files changed, 61 insertions(+), 18 deletions(-) > > diff --git a/Documentation/arm64/silicon-errata.txt > b/Documentation/arm64/silicon-errata.txt > index 58b71dd..4e16be5 100644 > --- a/Documentation/arm64/silicon-errata.txt > +++ b/Documentation/arm64/silicon-errata.txt > @@ -42,17 +42,18 @@ file acts as a registry of software workarounds in the > Linux Kernel and > will be updated when new workarounds are committed and backported to > stable kernels. > > -| Implementor| Component | Erratum ID | Kconfig > | > -++-+-+-+ > -| ARM| Cortex-A53 | #826319 | ARM64_ERRATUM_826319 > | > -| ARM| Cortex-A53 | #827319 | ARM64_ERRATUM_827319 > | > -| ARM| Cortex-A53 | #824069 | ARM64_ERRATUM_824069 > | > -| ARM| Cortex-A53 | #819472 | ARM64_ERRATUM_819472 > | > -| ARM| Cortex-A53 | #845719 | ARM64_ERRATUM_845719 > | > -| ARM| Cortex-A53 | #843419 | ARM64_ERRATUM_843419 > | > -| ARM| Cortex-A57 | #832075 | ARM64_ERRATUM_832075 > | > -| ARM| Cortex-A57 | #852523 | N/A > | > -| ARM| Cortex-A57 | #834220 | ARM64_ERRATUM_834220 > | > -|| | | > | > -| Cavium | ThunderX ITS| #22375, #24313 | CAVIUM_ERRATUM_22375 > | > -| Cavium | ThunderX GICv3 | #23154 | CAVIUM_ERRATUM_23154 > | > +| Implementor | Component | Erratum ID | Kconfig >| > +++-+-+-+ > +| ARM | Cortex-A53 | #826319 | > ARM64_ERRATUM_826319| > +| ARM | Cortex-A53 | #827319 | > ARM64_ERRATUM_827319| > +| ARM | Cortex-A53 | #824069 | > ARM64_ERRATUM_824069| > +| ARM | Cortex-A53 | #819472 | > ARM64_ERRATUM_819472| > +| ARM | Cortex-A53 | #845719 | > ARM64_ERRATUM_845719| > +| ARM | Cortex-A53 | #843419 | > ARM64_ERRATUM_843419| > +| ARM | Cortex-A57 | #832075 | > ARM64_ERRATUM_832075| > +| ARM | Cortex-A57 | #852523 | N/A >| > +| ARM | Cortex-A57 | #834220 | > ARM64_ERRATUM_834220| > +| | | | >| > +| Cavium | ThunderX ITS| #22375, #24313 | > CAVIUM_ERRATUM_22375| > +| Cavium | Thunde
Re: [PATCH] arm64: erratum: Workaround for Kryo reserved system register read
On 08/04/16 10:58, Suzuki K Poulose wrote: > On 07/04/16 18:31, Marc Zyngier wrote: > >>> + All system register encodings above use the form >>> + >>> + Op0, Op1, CRn, CRm, Op2. >>> + >>> + Note that some of the encodings listed above include >>> + the system register space reserved for the following >>> + identification registers which may appear in future revisions >>> + of the ARM architecture beyond ARMv8.0. >>> + This space includes: >>> + ID_AA64PFR[2-7]_EL1 >>> + ID_AA64DFR[2-3]_EL1 >>> + ID_AA64AFR[2-3]_EL1 >>> + ID_AA64ISAR[2-7]_EL1 >>> + ID_AA64MMFR[2-7]_EL1 > > > AFAIK, the id space is unassigned. So the naming above could cause confusion > if the register is named something else. It is reserved *at the moment*, but already has a defined behaviour. My worry is that when some new architecture revision comes around, we start using these registers without thinking much about it (because we should be able to). At this point, your SoC will catch fire and nobody will have a clue about the problem because it is not apparent in the code. I'd really like to see something a bit more forward looking that covers that space for good. Thanks, M. -- Jazz is not dead. It just smells funny... -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] arm64: erratum: Workaround for Kryo reserved system register read
On 08/04/16 11:31, Suzuki K Poulose wrote: > On 08/04/16 11:24, Marc Zyngier wrote: >> On 08/04/16 10:58, Suzuki K Poulose wrote: >>> On 07/04/16 18:31, Marc Zyngier wrote: >>> >>>>> + All system register encodings above use the form >>>>> + >>>>> + Op0, Op1, CRn, CRm, Op2. >>>>> + >>>>> + Note that some of the encodings listed above include >>>>> + the system register space reserved for the following >>>>> + identification registers which may appear in future revisions >>>>> + of the ARM architecture beyond ARMv8.0. >>>>> + This space includes: >>>>> + ID_AA64PFR[2-7]_EL1 >>>>> + ID_AA64DFR[2-3]_EL1 >>>>> + ID_AA64AFR[2-3]_EL1 >>>>> + ID_AA64ISAR[2-7]_EL1 >>>>> + ID_AA64MMFR[2-7]_EL1 >>> >>> >>> AFAIK, the id space is unassigned. So the naming above could cause confusion >>> if the register is named something else. >> >> It is reserved *at the moment*, but already has a defined behaviour. My > > Absolutely, they do need to be RAZ. My point was assigning names to the > reserved > space where the names are unassigned. Sorry - I misread your statement. It makes a lot more sense now that the coffee has trickled in. We're in violent agreement! ;-) Thanks, M. -- Jazz is not dead. It just smells funny... -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5] irqchip, gicv3-its, numa: Enable workaround for Cavium thunderx erratum 23144
On 21/04/16 18:40, Robert Richter wrote: > On 15.04.16 21:30:05, Robert Richter wrote: >> From: Ganapatrao Kulkarni >> >> The erratum fixes the hang of ITS SYNC command by avoiding inter node >> io and collections/cpu mapping on thunderx dual-socket platform. >> >> This fix is only applicable for Cavium's ThunderX dual-socket platform. >> >> This is based on NUMA v16 series. >> Message-Id: <1460155828-8690-1-git-send-email-ddaney.c...@gmail.com> > > Will, Catalin, > > after NUMA base patches went into linux-next (many thanks), please > consider this pass 1.x errata workaround for inclusion too. I'll queue it as a fix once the NUMA patches are merged into mainline. Thanks, M. -- Jazz is not dead. It just smells funny... -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/5] irq: generic-chip: resource management improvements
On 20/06/17 11:31, Bartosz Golaszewski wrote: > 2017-05-31 18:06 GMT+02:00 Bartosz Golaszewski : >> This series is a follow-up to [1]. >> >> Some users of irq_alloc_generic_chip() are modules which can be >> removed (e.g. gpio-ml-ioh) but have no means of freeing the allocated >> generic chip. >> >> Last time it was suggested to provide irq_destroy_generic_chip() which >> would undo both irq_remove_generic_chip() and irq_alloc_generic_chip(). >> >> This functionality is provided by patch 2/5 with 1/5 adding the option >> to only free the allocated memory. >> >> Patch 3/5 exports a function that will be used in the devres variant >> of irq_alloc_generic_chip(). >> >> Patches 4/5 and 5/5 add resource managed versions of >> irq_alloc_generic_chip() & irq_setup_generic_chip(). They will be used >> in drivers where applicable. Device resources are released in reverse >> order so it's ok to call devm_irq_alloc_generic_chip() and then >> devm_irq_setup_generic_chip(). >> >> [1] https://lkml.org/lkml/2017/3/8/550 >> >> Bartosz Golaszewski (5): >> irq: generic-chip: provide irq_free_generic_chip() >> irq: generic-chip: provide irq_destroy_generic_chip() >> irq: generic-chip: export irq_init_generic_chip() locally >> irq: generic-chip: provide devm_irq_alloc_generic_chip() >> irq: generic-chip: provide devm_irq_setup_generic_chip() >> >> Documentation/driver-model/devres.txt | 2 + >> include/linux/irq.h | 22 + >> kernel/irq/devres.c | 86 >> +++ >> kernel/irq/generic-chip.c | 7 ++- >> kernel/irq/internals.h| 11 + >> 5 files changed, 124 insertions(+), 4 deletions(-) >> >> -- >> 2.9.3 >> > > Ping for v4.13. > > Is there any reason not to merge it? There was a kbuild report from June 1st with worrying warnings on x86_64 (though I couldn't see how that was related to these patches). What's the status of that? Thanks, M. -- Jazz is not dead. It just smells funny... -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/5] irq: generic-chip: resource management improvements
On 31/05/17 17:06, Bartosz Golaszewski wrote: > This series is a follow-up to [1]. > > Some users of irq_alloc_generic_chip() are modules which can be > removed (e.g. gpio-ml-ioh) but have no means of freeing the allocated > generic chip. > > Last time it was suggested to provide irq_destroy_generic_chip() which > would undo both irq_remove_generic_chip() and irq_alloc_generic_chip(). > > This functionality is provided by patch 2/5 with 1/5 adding the option > to only free the allocated memory. > > Patch 3/5 exports a function that will be used in the devres variant > of irq_alloc_generic_chip(). > > Patches 4/5 and 5/5 add resource managed versions of > irq_alloc_generic_chip() & irq_setup_generic_chip(). They will be used > in drivers where applicable. Device resources are released in reverse > order so it's ok to call devm_irq_alloc_generic_chip() and then > devm_irq_setup_generic_chip(). > > [1] https://lkml.org/lkml/2017/3/8/550 > > Bartosz Golaszewski (5): > irq: generic-chip: provide irq_free_generic_chip() > irq: generic-chip: provide irq_destroy_generic_chip() > irq: generic-chip: export irq_init_generic_chip() locally > irq: generic-chip: provide devm_irq_alloc_generic_chip() > irq: generic-chip: provide devm_irq_setup_generic_chip() > > Documentation/driver-model/devres.txt | 2 + > include/linux/irq.h | 22 + > kernel/irq/devres.c | 86 > +++ > kernel/irq/generic-chip.c | 7 ++- > kernel/irq/internals.h | 11 +++++ > 5 files changed, 124 insertions(+), 4 deletions(-) > Looks OK to me. For the series: Acked-by: Marc Zyngier M. -- Jazz is not dead. It just smells funny... -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/3] simulated interrupts
On 19/07/17 14:58, Thomas Gleixner wrote: > On Wed, 19 Jul 2017, Bartosz Golaszewski wrote: > >> 2017-07-19 14:25 GMT+02:00 Thomas Gleixner : >>> On Wed, 19 Jul 2017, Bartosz Golaszewski wrote: >>> Some frameworks (e.g. iio, gpiolib) use irq_work to implement simulated interrupts that can be 'fired' from process context when needed and requested just like normal interrupts. This is useful for testing and development purposes. Currently this code is reimplemented by every user. This series proposes to add a new set of functions that can be used by drivers that want to simulate interrupts without having to duplicate any boilerplate code. The first patch adds a simple irq simulator framework. The second extends it with resource management. The third uses the new functionality in the gpio-mockup testing driver. NOTE: The next candidate for using this API would be iio-dummy-evgen. >>> >>> I like the general idea - have not looked at the code yet. Just a quick >>> question: How many copies/variants of this scheme do we have in tree? >>> >>> Thanks, >>> >>> tglx >> >> Currently there are two: iio and gpiolib basically duplicate the same >> code in their respective testing drivers. I only used irq_sim in >> gpio-mockup in this series as an example and to see if there's any >> interest in merging it before spending time on iio-dummy-evgen. > > Yes, I think so. Consolidation is always a good thing and simulation is > useful for developing or validating code. Indeed, that's pretty interesting. On a slightly tangential subject, there is another aspect that I thought of implementing for a while, but always ended up just relying on a quick hack: forcing the injection of an actual interrupt. A number of interrupt controllers have the ability to make an interrupt pending, for it to be handled as if a device had actually triggered it. In my case, it has proved to be incredibly useful when debugging the interrupt controller itself, and also things that mess with interrupts in a creative way (like KVM) while relying on a particular interrupt controller. What I had in mind was something like: echo 1 >/proc/irq/9/trigger (or the corresponding /sys/kernel/debug/irq/irqs/ interface if we want to make sure that this is really not for production use...). If there is any interest, I'll try to whip something up. Thanks, M. -- Jazz is not dead. It just smells funny... -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] irqchip/gic-v3-its: Add workaround for ThunderX2 erratum #174
On 18/01/18 05:28, Ganapatrao Kulkarni wrote:
> This erratum is observed on the ThunderX2 GICv3 ITS. When a
> MOVI command is used to change affinity of a LPI to a collection/cpu
> on another node, the LPI is not delivered to the cpu.
> An additional INV command is required after the MOVI to deliver
> the LPI to the new destination.
>
> If we add INV after MOVI, there is a chance that we lose LPIs which
> are raised when the affinity is changed. So for now, adding workaround fix
> to disable inter node affinity change.
>
> Signed-off-by: Ganapatrao Kulkarni
> ---
>
> v2: Added workaround to avoid inter node affinity change.
>
> v1: Initial patch
>
> Documentation/arm64/silicon-errata.txt | 1 +
> arch/arm64/Kconfig | 10 ++
> drivers/irqchip/irq-gic-v3-its.c | 21 -
> 3 files changed, 31 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/arm64/silicon-errata.txt
> b/Documentation/arm64/silicon-errata.txt
> index fc1c884..fb27cb5 100644
> --- a/Documentation/arm64/silicon-errata.txt
> +++ b/Documentation/arm64/silicon-errata.txt
> @@ -63,6 +63,7 @@ stable kernels.
> | Cavium | ThunderX Core | #27456 | CAVIUM_ERRATUM_27456
> |
> | Cavium | ThunderX Core | #30115 | CAVIUM_ERRATUM_30115
> |
> | Cavium | ThunderX SMMUv2 | #27704 | N/A
> |
> +| Cavium | ThunderX2 ITS | #174| CAVIUM_ERRATUM_174
> |
> | Cavium | ThunderX2 SMMUv3| #74 | N/A
> |
> | Cavium | ThunderX2 SMMUv3| #126| N/A
> |
> || | |
> |
> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> index c9a7e9e..0dbf3bd 100644
> --- a/arch/arm64/Kconfig
> +++ b/arch/arm64/Kconfig
> @@ -461,6 +461,16 @@ config ARM64_ERRATUM_843419
>
> If unsure, say Y.
>
> +config CAVIUM_ERRATUM_174
> + bool "Cavium ThunderX2 erratum 174"
> + default y
> + help
> + Cavium ThunderX2 dual socket systems may loose interrupts
> + on affinity change to a cpu on other node.
> + This workaround fix avoids inter node affinity change.
> +
> + If unsure, say Y.
> +
> config CAVIUM_ERRATUM_22375
> bool "Cavium erratum 22375, 24313"
> default y
> diff --git a/drivers/irqchip/irq-gic-v3-its.c
> b/drivers/irqchip/irq-gic-v3-its.c
> index 06f025f..b0cb528 100644
> --- a/drivers/irqchip/irq-gic-v3-its.c
> +++ b/drivers/irqchip/irq-gic-v3-its.c
> @@ -46,6 +46,7 @@
> #define ITS_FLAGS_CMDQ_NEEDS_FLUSHING(1ULL << 0)
> #define ITS_FLAGS_WORKAROUND_CAVIUM_22375(1ULL << 1)
> #define ITS_FLAGS_WORKAROUND_CAVIUM_23144(1ULL << 2)
> +#define ITS_FLAGS_WORKAROUND_CAVIUM_174 (1ULL << 3)
Instead of inventing a new flag, please rename the existing one to
ITS_FLAG_WORKAROUND_RESTRICT_NODE_AFFINITY (or something similar). There
is really no need to have two flags that do the exact same thing,
>
> #define RDIST_FLAGS_PROPBASE_NEEDS_FLUSHING (1 << 0)
>
> @@ -1102,7 +1103,8 @@ static int its_set_affinity(struct irq_data *d, const
> struct cpumask *mask_val,
> return -EINVAL;
>
> /* lpi cannot be routed to a redistributor that is on a foreign node
> */
> - if (its_dev->its->flags & ITS_FLAGS_WORKAROUND_CAVIUM_23144) {
> + if (its_dev->its->flags & ITS_FLAGS_WORKAROUND_CAVIUM_23144 ||
> + its_dev->its->flags & ITS_FLAGS_WORKAROUND_CAVIUM_174) {
> if (its_dev->its->numa_node >= 0) {
> cpu_mask = cpumask_of_node(its_dev->its->numa_node);
> if (!cpumask_intersects(mask_val, cpu_mask))
> @@ -2904,6 +2906,15 @@ static int its_force_quiescent(void __iomem *base)
> }
> }
>
> +static bool __maybe_unused its_enable_quirk_cavium_174(void *data)
> +{
> + struct its_node *its = data;
> +
> + its->flags |= ITS_FLAGS_WORKAROUND_CAVIUM_174;
> +
> + return true;
> +}
> +
> static bool __maybe_unused its_enable_quirk_cavium_22375(void *data)
> {
> struct its_node *its = data;
> @@ -3031,6 +3042,14 @@ static const struct gic_quirk its_quirks[] = {
> .init = its_enable_quirk_hip07_161600802,
> },
> #endif
> +#ifdef CONFIG_CAVIUM_ERRATUM_174
> + {
> + .desc = "ITS: Cavium ThunderX2 erratum 174",
> + .iidr = 0x13f,/* ThunderX2 pass A1/A2/B0 */
> + .mask = 0x,
> + .init = its_enable_quirk_cavium_174,
> + },
> +#endif
> {
> }
> };
>
Thanks,
M.
--
Jazz is not dead. It just smells funny...
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] irqchip/gic-v3-its: Add workaround for ThunderX2 erratum #174
On Sun, 21 Jan 2018 07:00:48 +, Jayachandran C wrote: > > On Thu, Jan 18, 2018 at 10:58:20AM +0530, Ganapatrao Kulkarni wrote: > > This erratum is observed on the ThunderX2 GICv3 ITS. When a > > MOVI command is used to change affinity of a LPI to a collection/cpu > > on another node, the LPI is not delivered to the cpu. > > An additional INV command is required after the MOVI to deliver > > the LPI to the new destination. > > > > If we add INV after MOVI, there is a chance that we lose LPIs which > > are raised when the affinity is changed. So for now, adding workaround fix > > to disable inter node affinity change. > > > > Signed-off-by: Ganapatrao Kulkarni > > --- > > > > v2: Added workaround to avoid inter node affinity change. > > > > v1: Initial patch > > > > Documentation/arm64/silicon-errata.txt | 1 + > > arch/arm64/Kconfig | 10 ++ > > drivers/irqchip/irq-gic-v3-its.c | 21 - > > 3 files changed, 31 insertions(+), 1 deletion(-) > > > > diff --git a/Documentation/arm64/silicon-errata.txt > > b/Documentation/arm64/silicon-errata.txt > > index fc1c884..fb27cb5 100644 > > --- a/Documentation/arm64/silicon-errata.txt > > +++ b/Documentation/arm64/silicon-errata.txt > > @@ -63,6 +63,7 @@ stable kernels. > > | Cavium | ThunderX Core | #27456 | > > CAVIUM_ERRATUM_27456| > > | Cavium | ThunderX Core | #30115 | > > CAVIUM_ERRATUM_30115| > > | Cavium | ThunderX SMMUv2 | #27704 | N/A > > | > > +| Cavium | ThunderX2 ITS | #174| CAVIUM_ERRATUM_174 > > | > > | Cavium | ThunderX2 SMMUv3| #74 | N/A > > | > > | Cavium | ThunderX2 SMMUv3| #126| N/A > > | > > || | | > > | > > diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig > > index c9a7e9e..0dbf3bd 100644 > > --- a/arch/arm64/Kconfig > > +++ b/arch/arm64/Kconfig > > @@ -461,6 +461,16 @@ config ARM64_ERRATUM_843419 > > > > If unsure, say Y. > > > > +config CAVIUM_ERRATUM_174 > > + bool "Cavium ThunderX2 erratum 174" > > + default y > > + help > > + Cavium ThunderX2 dual socket systems may loose interrupts > > + on affinity change to a cpu on other node. > > + This workaround fix avoids inter node affinity change. > > This has to be fixed up to match the commit message (and for spelling). > I have seen some questions offlist about how important this fix is, > and how it can affect users - so that would be useful to have in the > description as well. > > To clarify, this errata comes into play only when the irq affinity is > forced from the node given by the device (and ITS) affinity to another > node. This should not happen in normal, useful configurations. Define normal. That's all under control of userspace, and the kernel doesn't really have a say. irqbalance will happily move interrupts around. Disable all CPUs from node at runtime (again, from userspace), and you'll get the exact same thing. I can't see what's so "abnormal" about any of that. > Also, we will hold further posting of this errata until we do another > round of investigation with the hardware team for a better solution. > If we can handle the pending interrupts for the small window of MOVI/INV > in first workaround, we will not need this restriction at all. What do you mean by "If we can handle the pending interrupts for the small window of MOVI/INV"? Taking the interrupt on the source CPU? Sure, that would be fine. But that's assuming that the souce CPU is in a position to actually handle this, and is not simply going down. If there is only a slight possibility that you may loose an interrupt in the MOVI/INV window (which is not that small, since that's a 4 command sequence), your only other solution is to inject a spurious interrupt to replace the one you may have lost in that window. In the meantime, and until I see a patch fixing this (or a decent explanation of why this isn't a problem), I'll consider it broken. Thanks, M. -- Jazz is not dead, it just smell funny. -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] irqchip/gic-v3-its: Add workaround for ThunderX2 erratum #174
On Mon, 19 Feb 2018 21:12:10 +, Jayachandran C wrote: > > On Sun, Jan 21, 2018 at 11:35:34AM +, Marc Zyngier wrote: > > On Sun, 21 Jan 2018 07:00:48 +, > > Jayachandran C wrote: > > > > > > On Thu, Jan 18, 2018 at 10:58:20AM +0530, Ganapatrao Kulkarni wrote: > > > > This erratum is observed on the ThunderX2 GICv3 ITS. When a > > > > MOVI command is used to change affinity of a LPI to a collection/cpu > > > > on another node, the LPI is not delivered to the cpu. > > > > An additional INV command is required after the MOVI to deliver > > > > the LPI to the new destination. > > > > > > > > If we add INV after MOVI, there is a chance that we lose LPIs which > > > > are raised when the affinity is changed. So for now, adding workaround > > > > fix > > > > to disable inter node affinity change. > > > > > > > > Signed-off-by: Ganapatrao Kulkarni > > > > --- > > > > > > > > v2: Added workaround to avoid inter node affinity change. > > > > > > > > v1: Initial patch > > > > > > > > Documentation/arm64/silicon-errata.txt | 1 + > > > > arch/arm64/Kconfig | 10 ++ > > > > drivers/irqchip/irq-gic-v3-its.c | 21 - > > > > 3 files changed, 31 insertions(+), 1 deletion(-) > > > > > > > > diff --git a/Documentation/arm64/silicon-errata.txt > > > > b/Documentation/arm64/silicon-errata.txt > > > > index fc1c884..fb27cb5 100644 > > > > --- a/Documentation/arm64/silicon-errata.txt > > > > +++ b/Documentation/arm64/silicon-errata.txt > > > > @@ -63,6 +63,7 @@ stable kernels. > > > > | Cavium | ThunderX Core | #27456 | > > > > CAVIUM_ERRATUM_27456| > > > > | Cavium | ThunderX Core | #30115 | > > > > CAVIUM_ERRATUM_30115| > > > > | Cavium | ThunderX SMMUv2 | #27704 | N/A > > > > | > > > > +| Cavium | ThunderX2 ITS | #174| > > > > CAVIUM_ERRATUM_174 | > > > > | Cavium | ThunderX2 SMMUv3| #74 | N/A > > > > | > > > > | Cavium | ThunderX2 SMMUv3| #126| N/A > > > > | > > > > || | | > > > > | > > > > diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig > > > > index c9a7e9e..0dbf3bd 100644 > > > > --- a/arch/arm64/Kconfig > > > > +++ b/arch/arm64/Kconfig > > > > @@ -461,6 +461,16 @@ config ARM64_ERRATUM_843419 > > > > > > > > If unsure, say Y. > > > > > > > > +config CAVIUM_ERRATUM_174 > > > > + bool "Cavium ThunderX2 erratum 174" > > > > + default y > > > > + help > > > > + Cavium ThunderX2 dual socket systems may loose interrupts > > > > + on affinity change to a cpu on other node. > > > > + This workaround fix avoids inter node affinity change. > > > > > > This has to be fixed up to match the commit message (and for spelling). > > > I have seen some questions offlist about how important this fix is, > > > and how it can affect users - so that would be useful to have in the > > > description as well. > > > > > > To clarify, this errata comes into play only when the irq affinity is > > > forced from the node given by the device (and ITS) affinity to another > > > node. This should not happen in normal, useful configurations. > > > > Define normal. That's all under control of userspace, and the kernel > > doesn't really have a say. irqbalance will happily move interrupts > > around. Disable all CPUs from node at runtime (again, from userspace), > > and you'll get the exact same thing. I can't see what's so "abnormal" > > about any of that. > > > > > Also, we will hold further posting of this errata until we do another > > > round of investigation with the hardware team for a better solution. > > > If we can handle the pending interrupts for the small window of MOVI/INV > > > in first workaround, we will not need this restriction at all. > > > > What do you mean by &quo
Re: [PATCH v4 4/8] dt-bindings: Add doc for the Ingenic TCU drivers
On 17/03/18 23:28, Paul Cercueil wrote:
> Add documentation about how to properly use the Ingenic TCU
> (Timer/Counter Unit) drivers from devicetree.
>
> Signed-off-by: Paul Cercueil
> ---
> .../bindings/clock/ingenic,tcu-clocks.txt | 42
> .../bindings/interrupt-controller/ingenic,tcu.txt | 39 +++
> .../devicetree/bindings/mfd/ingenic,tcu.txt| 56
> ++
> .../devicetree/bindings/timer/ingenic,tcu.txt | 41
> 4 files changed, 178 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/clock/ingenic,tcu-clocks.txt
> create mode 100644
> Documentation/devicetree/bindings/interrupt-controller/ingenic,tcu.txt
> create mode 100644 Documentation/devicetree/bindings/mfd/ingenic,tcu.txt
> create mode 100644 Documentation/devicetree/bindings/timer/ingenic,tcu.txt
>
> v4: New patch in this series. Corresponds to V2 patches 3-4-5 with
> added content.
>
> diff --git a/Documentation/devicetree/bindings/clock/ingenic,tcu-clocks.txt
> b/Documentation/devicetree/bindings/clock/ingenic,tcu-clocks.txt
> new file mode 100644
> index ..471d27078599
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/clock/ingenic,tcu-clocks.txt
> @@ -0,0 +1,42 @@
> +Ingenic SoC TCU binding
> +
> +The TCU is the Timer/Counter Unit present in all Ingenic SoCs. It features 8
> +channels, each one having its own clock, that can be started and stopped,
> +reparented, and reclocked.
> +
> +Required properties:
> +- compatible : One of:
> + * ingenic,jz4740-tcu-clocks,
> + * ingenic,jz4770-tcu-clocks,
> + * ingenic,jz4780-tcu-clocks.
> +- clocks : List of phandle & clock specifiers for clocks external to the TCU.
> + The "pclk", "rtc" and "ext" clocks should be provided.
> +- clock-names : List of name strings for the external clocks.
> +- #clock-cells: Should be 1.
> + Clock consumers specify this argument to identify a clock. The valid values
> + may be found in .
> +
> +Example:
> +
> +/ {
> + tcu: mfd@10002000 {
> + compatible = "ingenic,tcu", "simple-mfd", "syscon";
> + reg = <0x10002000 0x1000>;
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges = <0x0 0x10002000 0x1000>;
> +
> + tcu_clk: clocks@10 {
> + compatible = "ingenic,jz4740-tcu-clocks";
> + reg = <0x10 0xff0>;
> +
> + clocks = <&ext>, <&rtc>, <&pclk>;
> + clock-names = "ext", "rtc", "pclk";
> +
> + #clock-cells = <1>;
> + };
> + };
> +};
> +
> +For information about the top-level "ingenic,tcu" compatible node and other
> +children nodes, see Documentation/devicetree/bindings/mfd/ingenic,tcu.txt.
> diff --git
> a/Documentation/devicetree/bindings/interrupt-controller/ingenic,tcu.txt
> b/Documentation/devicetree/bindings/interrupt-controller/ingenic,tcu.txt
> new file mode 100644
> index ..7f3af2da77cd
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/interrupt-controller/ingenic,tcu.txt
> @@ -0,0 +1,39 @@
> +Ingenic SoCs Timer/Counter Unit Interrupt Controller
> +
> +Required properties:
> +
> +- compatible : should be "ingenic,-tcu-intc". Valid strings are:
> + * ingenic,jz4740-tcu-intc
> + * ingenic,jz4770-tcu-intc
> + * ingenic,jz4780-tcu-intc
> +- interrupt-controller : Identifies the node as an interrupt controller
> +- #interrupt-cells : Specifies the number of cells needed to encode an
> + interrupt source. The value shall be 1.
> +- interrupt-parent : phandle of the interrupt controller.
> +- interrupts : Specifies the interrupt the controller is connected to.
> +
> +Example:
> +
> +/ {
> + tcu: mfd@10002000 {
> + compatible = "ingenic,tcu", "simple-mfd", "syscon";
> + reg = <0x10002000 0x1000>;
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges = <0x0 0x10002000 0x1000>;
> +
> + tcu_irq: interrupt-controller@20 {
> + compatible = "ingenic,jz4740-tcu-intc";
> + reg = <0x20 0x20>;
> +
> + interrupt-controller;
> + #interrupt-cells = <1>;
> +
> + interrupt-parent = <&intc>;
> + interrupts = <15>;
> + };
> + };
> +};
> +
> +For information about the top-level "ingenic,tcu" compatible node and other
> +children nodes, see Documentation/devicetree/bindings/mfd/ingenic,tcu.txt.
> diff --git a/Documentation/devicetree/bindings/mfd/ingenic,tcu.txt
> b/Documentation/devicetree/bindings/mfd/ingenic,tcu.txt
> new file mode 100644
> index ..5742c3f21550
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mfd/ingenic,tcu.txt
> @@ -0,0 +1,56 @@
> +Ingenic JZ47xx SoCs Timer/Counter Unit devicetree bindings
> +--
> +
> +For a description o
Re: [PATCH v3 2/6] Disable instrumentation for some code
On 02/04/18 13:04, Abbott Liu wrote: > From: Andrey Ryabinin > > Disable instrumentation for arch/arm/boot/compressed/* > ,arch/arm/kvm/hyp/* and arch/arm/vdso/* because those > code won't linkd with kernel image. > > Disable kasan check in the function unwind_pop_register > because it doesn't matter that kasan checks failed when > unwind_pop_register read stack memory of task. > > Reviewed-by: Russell King - ARM Linux > Reviewed-by: Florian Fainelli > Reviewed-by: Marc Zyngier Just because I replied to this patch doesn't mean you can stick my Reviewed-by tag on it. Please drop this tag until I explicitly say that you can add it (see Documentation/process/submitting-patches.rst, section 11). Same goes for patch 1. Thanks, M. -- Jazz is not dead. It just smells funny... -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 2/5] arm64: Work around Falkor erratum 1003
On 11/01/17 18:06, Catalin Marinas wrote: > Some minor comments below, nothing fundamental (as long as you say the > new sequence doesn't have the speculative TLB load problem I mentioned > on a previous version). > > On Wed, Jan 11, 2017 at 09:41:15AM -0500, Christopher Covington wrote: >> diff --git a/Documentation/arm64/silicon-errata.txt >> b/Documentation/arm64/silicon-errata.txt >> index 405da11..7151aed 100644 >> --- a/Documentation/arm64/silicon-errata.txt >> +++ b/Documentation/arm64/silicon-errata.txt >> @@ -42,24 +42,25 @@ file acts as a registry of software workarounds in the >> Linux Kernel and >> will be updated when new workarounds are committed and backported to >> stable kernels. >> >> -| Implementor| Component | Erratum ID | Kconfig >>| >> -++-+-+-+ >> -| ARM| Cortex-A53 | #826319 | ARM64_ERRATUM_826319 >>| >> -| ARM| Cortex-A53 | #827319 | ARM64_ERRATUM_827319 >>| >> -| ARM| Cortex-A53 | #824069 | ARM64_ERRATUM_824069 >>| >> -| ARM| Cortex-A53 | #819472 | ARM64_ERRATUM_819472 >>| >> -| ARM| Cortex-A53 | #845719 | ARM64_ERRATUM_845719 >>| >> -| ARM| Cortex-A53 | #843419 | ARM64_ERRATUM_843419 >>| >> -| ARM| Cortex-A57 | #832075 | ARM64_ERRATUM_832075 >>| >> -| ARM| Cortex-A57 | #852523 | N/A >>| >> -| ARM| Cortex-A57 | #834220 | ARM64_ERRATUM_834220 >>| >> -| ARM| Cortex-A72 | #853709 | N/A >>| >> -| ARM| MMU-500 | #841119,#826419 | N/A >>| >> -|| | | >>| >> -| Cavium | ThunderX ITS| #22375, #24313 | CAVIUM_ERRATUM_22375 >>| >> -| Cavium | ThunderX ITS| #23144 | CAVIUM_ERRATUM_23144 >>| >> -| Cavium | ThunderX GICv3 | #23154 | CAVIUM_ERRATUM_23154 >>| >> -| Cavium | ThunderX Core | #27456 | CAVIUM_ERRATUM_27456 >>| >> -| Cavium | ThunderX SMMUv2 | #27704 | N/A | >> -|| | | >>| >> -| Freescale/NXP | LS2080A/LS1043A | A-008585| FSL_ERRATUM_A008585 >>| >> +| Implementor | Component | Erratum ID | Kconfig >>| >> ++---+-+-+--+ >> +| ARM | Cortex-A53 | #826319 | ARM64_ERRATUM_826319 >>| >> +| ARM | Cortex-A53 | #827319 | ARM64_ERRATUM_827319 >>| >> +| ARM | Cortex-A53 | #824069 | ARM64_ERRATUM_824069 >>| >> +| ARM | Cortex-A53 | #819472 | ARM64_ERRATUM_819472 >>| >> +| ARM | Cortex-A53 | #845719 | ARM64_ERRATUM_845719 >>| >> +| ARM | Cortex-A53 | #843419 | ARM64_ERRATUM_843419 >>| >> +| ARM | Cortex-A57 | #832075 | ARM64_ERRATUM_832075 >>| >> +| ARM | Cortex-A57 | #852523 | N/A >>| >> +| ARM | Cortex-A57 | #834220 | ARM64_ERRATUM_834220 >>| >> +| ARM | Cortex-A72 | #853709 | N/A >>| >> +| ARM | MMU-500 | #841119,#826419 | N/A >>| >> +| | | | >>| >> +| Cavium| ThunderX ITS| #22375, #24313 | CAVIUM_ERRATUM_22375 >>| >> +| Cavium| ThunderX ITS| #23144 | CAVIUM_ERRATUM_23144 >>| >> +| Cavium| ThunderX GICv3 | #23154 | CAVIUM_ERRATUM_23154 >>| >> +| Cavium| ThunderX Core | #27456 | CAVIUM_ERRATUM_27456 >>| >> +| Cavium| ThunderX SMMUv2 | #27704 | N/A >>| >> +| | | | >>| >> +| Freescale/NXP | LS2080A/LS1043A | A-008585| FSL_ERRATUM_A008585 >>| >> +| Qualcomm | Falkor v1 | E1003 | >> QCOM_FALKOR_ERRATUM_1003 | > > Please don't change the "Implementor" column width, there is no point > and it makes the patch harder to read (i.e. this hunk should only have > one line). > >> diff --git a/arch/arm64/mm/context.c b/arch/arm64/mm/context.c >> index 4c63cb1..5a0a82a 100644 >> --- a/arch/arm64/mm/context.c >> +++ b/arch/arm64/mm/context.c >> @@ -87,6 +87,11 @@ static void flush_context(unsigned int cpu) >> /* Update the list of reserved ASIDs and the ASID bitmap. */ >>
Re: [PATCH v3 2/5] arm64: Work around Falkor erratum 1003
[finally, some proper bikeshedding] On 11/01/17 18:40, Timur Tabi wrote: > On 01/11/2017 12:37 PM, Mark Rutland wrote: >> The name, as it is, is perfectly descriptive. >> >> Let's not sacrifice legibility over a non-issue. > > I don't want to kick a dead horse or anything, but changing it to > QCOM_FLKR_ERRATUM_1003 would eliminate all the spacing problems without > sacrificing anything. Other than not being able to grep for the core name in the source tree, how do you suggest we pronounce FLKR? Because so far, it rolls off the tongue in an interesting way... Thanks, M. -- Jazz is not dead. It just smells funny... -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v15 06/13] irqchip: Add irq-ingenic-tcu driver
On 24/07/2019 18:16, Paul Cercueil wrote: > This driver handles the interrupt controller built in the Timer/Counter > Unit (TCU) of the JZ47xx SoCs from Ingenic. > > Signed-off-by: Paul Cercueil > Tested-by: Mathieu Malaterre > Tested-by: Artur Rojek > Reviewed-by: Thomas Gleixner Acked-by: Marc Zyngier Given the various dependencies, I assume the series will get routed via the MIPS tree. Thanks, M. -- Jazz is not dead, it just smells funny...
Re: [PATCH v12 15/39] KVM: arm64: Manage GCS access and registers for guests
On Thu, 29 Aug 2024 00:27:31 +0100, Mark Brown wrote: > > GCS introduces a number of system registers for EL1 and EL0, on systems > with GCS we need to context switch them and expose them to VMMs to allow > guests to use GCS. > > In order to allow guests to use GCS we also need to configure > HCRX_EL2.GCSEn, if this is not set GCS instructions will be noops and > CHKFEAT will report GCS as disabled. Also enable fine grained traps for > access to the GCS registers by guests which do not have the feature > enabled. > > In order to allow userspace to control availability of the feature to > guests we enable writability for only ID_AA64PFR1_EL1.GCS, this is a > deliberately conservative choice to avoid errors due to oversights. > Further fields should be made writable in future. > > Reviewed-by: Thiago Jung Bauermann > Signed-off-by: Mark Brown > --- > arch/arm64/include/asm/kvm_host.h | 12 > arch/arm64/include/asm/vncr_mapping.h | 2 ++ > arch/arm64/kvm/hyp/include/hyp/sysreg-sr.h | 49 > -- > arch/arm64/kvm/sys_regs.c | 27 +++- > 4 files changed, 79 insertions(+), 11 deletions(-) FWIW, this patch is going to conflict badly with -next, because of the "conservative" approach to dealing with ID_AA64PFR1_EL1 (thankfully, the *progressive* approach has been merged). If it gets stuck on a branch together with patch #11 (which seems to be the minimum for things to compile), I can take it independently and fix it myself. Just let me know. Thanks, M. -- Without deviation from the norm, progress is not possible.
