On Thu, Mar 2, 2023 at 4:17 AM Palmer Dabbelt wrote:
>
> On Tue, 14 Feb 2023 01:19:02 PST (-0800), h...@linux.ibm.com wrote:
> > On Tue, Feb 14, 2023 at 09:58:17AM +0100, Geert Uytterhoeven wrote:
> >> Hi Heiko,
> >>
> >> On Tue, Feb 14, 2023 at 9:39 AM Heiko Carstens wrote:
> >> > On Tue, Feb
Hi Jean-Jacques,
Thanks for your patch!
On Wed, Mar 1, 2023 at 7:53 PM Jean-Jacques Hiblot
wrote:
> of_irq_parse_one() does a get() on the device node returned in out_irq->np.
> Callers of of_irq_parse_one() must do a put() when they are done with it.
What does "be done with it" really mean
This series attempts to fix refcounting issues related to of_irq_parse_one()
and of_irq_parse_raw().
The first issue is simply that most callers of of_irq_parse_one() and
of_irq_parse_raw() don't call of_node_put() on the returned device node when
they no longer need it.
The second issue is a
When of_parse_phandle_with_args() succeeds, a get() is performed on
out_irq->np. And another get() is performed in of_irq_parse_raw(),
resulting in the refcount being incremented twice.
Fixing this by calling put() after of_irq_parse_raw().
Signed-off-by: Jean-Jacques Hiblot
---
of_irq_parse_raw() does a get() on the device node returned in out_irq->np.
Callers of of_irq_parse_raw() must do a put() when they are done with it.
Signed-off-by: Jean-Jacques Hiblot
---
arch/powerpc/platforms/fsl_uli1575.c | 1 +
drivers/bcma/main.c | 5 -
2 files
of_irq_parse_one() does a get() on the device node returned in out_irq->np.
Callers of of_irq_parse_one() must do a put() when they are done with it.
Signed-off-by: Jean-Jacques Hiblot
---
.../mach-shmobile/regulator-quirk-rcar-gen2.c | 1 +
arch/powerpc/sysdev/mpic_msi.c| 1 +
On 3/2/23 3:35 AM, Benjamin Gray wrote:
On Wed, 2023-03-01 at 22:39 +0530, Kajol Jain wrote:
From: Madhavan Srinivasan
event.h header already includes utlis.h. Avoid including
the same explicitly in the code when event.h included.
Signed-off-by: Madhavan Srinivasan
As I understand,
On Tue, 14 Feb 2023 01:19:02 PST (-0800), h...@linux.ibm.com wrote:
On Tue, Feb 14, 2023 at 09:58:17AM +0100, Geert Uytterhoeven wrote:
Hi Heiko,
On Tue, Feb 14, 2023 at 9:39 AM Heiko Carstens wrote:
> On Tue, Feb 14, 2023 at 08:49:01AM +0100, Alexandre Ghiti wrote:
> > This all came up in
On Thu, 23 Feb 2023 05:09:17 PST (-0800), Arnd Bergmann wrote:
On Thu, Feb 23, 2023, at 10:54, Alexandre Ghiti wrote:
On Wed, Feb 15, 2023 at 2:05 PM Arnd Bergmann wrote:
On Wed, Feb 15, 2023, at 13:59, Russell King (Oracle) wrote:
> On Tue, Feb 14, 2023 at 08:49:04AM +0100, Alexandre Ghiti
On Wed, Mar 1, 2023 at 4:54 PM Hyeonggon Yoo <42.hye...@gmail.com> wrote:
>
> On Wed, Mar 01, 2023 at 10:42:48AM -0800, Suren Baghdasaryan wrote:
> > On Wed, Mar 1, 2023 at 10:34 AM Suren Baghdasaryan
> > wrote:
> > >
> > > On Tue, Feb 28, 2023 at 11:57 PM Hyeonggon Yoo <42.hye...@gmail.com>
>
gcc
arc allyesconfig gcc
arc buildonly-randconfig-r001-20230301 gcc
arc defconfig gcc
arc randconfig-r011-20230226 gcc
arc randconfig-r011-20230227 gcc
arc
On Wed, Mar 01, 2023 at 10:42:48AM -0800, Suren Baghdasaryan wrote:
> On Wed, Mar 1, 2023 at 10:34 AM Suren Baghdasaryan wrote:
> >
> > On Tue, Feb 28, 2023 at 11:57 PM Hyeonggon Yoo <42.hye...@gmail.com> wrote:
> > >
> > > On Wed, Mar 01, 2023 at 07:43:33AM +, Hyeonggon Yoo wrote:
> > > > On
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git
merge
branch HEAD: 90dbf76e470bc4b973052a8f26ea43bae30f9aec Automatic merge of
'master' into merge (2023-02-26 20:52)
elapsed time: 5173m
configs tested: 178
configs skipped: 14
The following configs have been
The HPET-based hardlockup detector relies on the TSC to determine if an
observed NMI interrupt was originated by HPET timer. Hence, this detector
can no longer be used with an unstable TSC. Once marked as unstable,
the TSC cannot be stable again. In such case, permanently stop the HPET-
based
Add a shim hardlockup detector that allows to select between the perf- and
HPET-driven implementations available for x86.
Override the interfaces of the default hardlockup detector.
Cc: Andi Kleen
Cc: Stephane Eranian
Cc: "Ravi V. Shankar"
Cc: io...@lists.linux-foundation.org
Cc:
It is not possible to determine the source of a non-maskable interrupt
(NMI) in x86. When dealing with an HPET channel, the only direct method to
determine whether it caused an NMI would be to read the Interrupt Status
register.
Reading HPET registers is slow and, therefore, not to be done while
The NMI watchdog may become unreliable during runtime. This is the case
in x86 if, for instance, the HPET-based hardlockup detector is in use and
the TSC counter becomes unstable.
Introduce a new interface to mark the hardlockup detector as unavailable
in such cases. When doing this, update the
Keep the HPET-based hardlockup detector disabled unless explicitly enabled
via a command-line argument. If such parameter is not given, the
initialization of the HPET-based hardlockup detector fails and the NMI
watchdog will fall back to use the perf-based implementation.
Cc: Andi Kleen
Cc:
Certain implementations of the hardlockup detector require support for
Inter-Processor Interrupt shorthands. On x86, support for these can only
be determined after all the possible CPUs have booted once (in smp_init()).
Other architectures may not need such check.
lockup_detector_init() only
Implement a hardlockup detector that uses an HPET channel as the source
of the non-maskable interrupt. Implement the basic functionality to
start, stop, and configure the timer.
Designate as the handling CPU one of the CPUs that the detector monitors.
Use it to service the NMI from the HPET
The current default implementation of the hardlockup detector assumes that
it is implemented using perf events. However, the hardlockup detector can
be driven by other sources of non-maskable interrupts (e.g., a properly
configured timer).
Group and wrap in #ifdef CONFIG_HARDLOCKUP_DETECTOR_PERF
The procedure to detect hardlockups is independent of the source of the
the non-maskable interrupt that drives it. Place it in a separate, generic
function to be invoked by various implementations of the NMI watchdog.
Move the bulk of watchdog_overflow_callback() to the new function
Create a new HPET_MODE_NMI_WATCHDOG mode category to reserve an HPET
channel for the hard lockup detector.
Only reserve the channel if the HPET frequency is sufficiently low to allow
32-bit register accesses and if Front Side BUS interrupt delivery (i.e.,
MSI interrupts) is supported.
Cc: Andi
The flag X86_ALLOC_AS_NMI indicates that the interrupts to be allocated in
an interrupt domain need to be configured as NMIs. Add an as_nmi argument
to hpet_assign_irq(). The HPET clock events do not need NMIs, but the HPET
hardlockup detector does.
Cc: Andi Kleen
Cc: "Ravi V. Shankar"
Cc:
In order to allow hpet_writel() to be used by other components (e.g.,
the HPET-based hardlockup detector), expose it in the HPET header file.
Cc: Andi Kleen
Cc: Stephane Eranian
Cc: "Ravi V. Shankar"
Cc: io...@lists.linux-foundation.org
Cc: linuxppc-dev@lists.ozlabs.org
Reviewed-by: Tony Luck
As per the AMD I/O Virtualization Technology (IOMMU) Specification, the
AMD IOMMU only remaps fixed and arbitrated MSIs. NMIs are controlled
by the NMIPass bit of a Device Table Entry. When set, the IOMMU passes
through NMI interrupt messages unmapped. Otherwise, they are aborted.
Also, Section
Programming an HPET channel in periodic mode involves several steps.
Besides the HPET clocksource, the HPET-based hardlockup detector may
need to program its HPET channel in periodic mode.
To avoid code duplication, wrap the programming of the HPET timer in
a helper function.
Cc: Andi Kleen
Cc:
If NMIPass is enabled in a Device Table Entry, the IOMMU lets NMI interrupt
messages pass through unmapped. The contents of the MSI message, not an
IRTE, determine how and where the NMI is delivered.
The IOMMU driver owns the MSI message of the NMI. Compose it using the non-
interrupt-remapping
If an interrupt is allocated with NMI as delivery mode, the Device Table
Entry needs to be modified accordingly in irq_remapping_alloc().
No functional changes.
Cc: Andi Kleen
Cc: "Ravi V. Shankar"
Cc: Joerg Roedel
Cc: Suravee Suthikulpanit
Cc: Stephane Eranian
Cc:
struct irq_cfg::delivery_mode specifies the delivery mode of each interrupt
separately. Configuring the delivery mode of an IRTE would require adding
a third argument to prepare_irte(). Instead, take a pointer to the irq_cfg
for which an IRTE is being configured. No functional changes.
Cc: Andi
Use the mode specified in the provided interrupt hardware configuration
data to set the delivery mode.
Since most interrupts are configured to use the delivery mode of the APIC
driver, there are no functional changes. The only exception are interrupts
that do specify a different delivery mode.
When the destination mode of an interrupt is physical APICID, the interrupt
is delivered only to the single CPU of which the physical APICID is
specified in the destination ID field. The redirection hint is meaningless.
Furthermore, on certain processors, the IOMMU does not deliver the
interrupt
Add a separate local APIC NMI controller to handle NMIs apart from the
regular APIC management.
This controller will be used to handle the NMI vector of the HPET NMI
watchdog.
Cc: Andi Kleen
Cc: "Ravi V. Shankar"
Cc: Stephane Eranian
Cc: io...@lists.linux-foundation.org
Cc:
The NMI vector is fixed. No cleanup is needed after updating affinity.
Cc: Andi Kleen
Cc: "Ravi V. Shankar"
Cc: Stephane Eranian
Cc: io...@lists.linux-foundation.org
Cc: linuxppc-dev@lists.ozlabs.org
Signed-off-by: Ricardo Neri
---
Changes since v6:
* Introduced this patch.
Changes since
Hi x86 trusted reviewers,
This is the seventh version of this patchset. I acknowledge that it took me
a long time to post a new version. Sorry! I will commit time to continue
working on this series with high priority and I will post a new series soon
after receiving your new feedback.
Although
There are cases in which it is necessary to set the delivery mode of an
interrupt as NMI. Add a new flag that callers can specify when allocating
an interrupt.
Cc: Andi Kleen
Cc: "Ravi V. Shankar"
Cc: Stephane Eranian
Cc: io...@lists.linux-foundation.org
Cc: linuxppc-dev@lists.ozlabs.org
There are no restrictions in hardware to configure the delivery mode of
each interrupt individually. Also, certain interrupts need to be
configured with a specific delivery mode (e.g., non-maskable interrupts).
Add a new member, delivery_mode, to struct irq_cfg to this effect.
To keep the current
irq_cfg provides a delivery mode for each interrupt. Use it instead
of the hardcoded APIC_DELIVERY_MODE_FIXED. This allows to compose
messages for NMI delivery mode which is required to implement a HPET-
based NMI watchdog.
No functional change as the default delivery mode is set to
On Tue, Feb 28, 2023 at 10:21:36PM +1100, Michael Ellerman wrote:
> Jarkko Sakkinen writes:
> > On Mon, Feb 27, 2023 at 06:08:31PM -0500, Stefan Berger wrote:
> >> On 2/23/23 22:25, Michael Ellerman wrote:
> >> > There's code in prom_instantiate_sml() to do a "SML handover" (Stored
> >> >
On Sat, Feb 18, 2023 at 01:14:05PM -0800, Rick Edgecombe wrote:
The x86 Control-flow Enforcement Technology (CET) feature includes a new
type of memory called shadow stack. This shadow stack memory has some
unusual properties, which requires some core mm changes to function
properly.
One of
-- Forwarded message --
From: 王昊然
Date: Tue, 28 Feb 2023 18:16:14 +0800
Subject: Re: Symbol cpu_feature_keys should be exported to all modules
on powerpc
To: Greg KH
Cc: sta...@vger.kernel.org
2023-02-28 16:28 GMT+08:00, Greg KH :
> On Tue, Feb 28, 2023 at 04:18:12PM +0800, 王昊然
On Wed, 2023-03-01 at 22:39 +0530, Kajol Jain wrote:
> From: Madhavan Srinivasan
>
> event.h header already includes utlis.h. Avoid including
> the same explicitly in the code when event.h included.
>
> Signed-off-by: Madhavan Srinivasan
As I understand, transitive includes should not be
Miquel!
On Wed, Mar 01 2023 at 11:55, Miquel Raynal wrote:
> t...@linutronix.de wrote on Fri, 11 Nov 2022 14:54:22 +0100 (CET):
>
>> When a range of descriptors is freed then all of them are not associated to
>> a linux interrupt. Remove the filter and add a warning to the free function.
>> +
On Wed, Mar 1, 2023 at 12:53 PM Jean-Jacques Hiblot
wrote:
>
> When of_parse_phandle_with_args() succeeds, a get() is performed on
> out_irq->np. And another get() is performed in of_irq_parse_raw(),
> resulting in the refcount being incremented twice.
> Fixing this by calling put() after
On Wed, Mar 1, 2023 at 10:34 AM Suren Baghdasaryan wrote:
>
> On Tue, Feb 28, 2023 at 11:57 PM Hyeonggon Yoo <42.hye...@gmail.com> wrote:
> >
> > On Wed, Mar 01, 2023 at 07:43:33AM +, Hyeonggon Yoo wrote:
> > > On Mon, Feb 27, 2023 at 09:36:17AM -0800, Suren Baghdasaryan wrote:
> > > >
Since CONFIG_PER_VMA_LOCK depends on CONFIG_MMU, the changes in nommu
are not needed. Remove them.
Fixes: bad94decd6a4 ("mm: write-lock VMAs before removing them from VMA tree")
Reported-by: Hyeonggon Yoo <42.hye...@gmail.com>
Link: https://lore.kernel.org/all/Y%2F8CJQGNuMUTdLwP@localhost/
On Wed, Mar 1, 2023 at 10:34 AM Suren Baghdasaryan wrote:
>
> On Tue, Feb 28, 2023 at 11:57 PM Hyeonggon Yoo <42.hye...@gmail.com> wrote:
> >
> > On Wed, Mar 01, 2023 at 07:43:33AM +, Hyeonggon Yoo wrote:
> > > On Mon, Feb 27, 2023 at 09:36:17AM -0800, Suren Baghdasaryan wrote:
> > > >
On Tue, Feb 28, 2023 at 11:57 PM Hyeonggon Yoo <42.hye...@gmail.com> wrote:
>
> On Wed, Mar 01, 2023 at 07:43:33AM +, Hyeonggon Yoo wrote:
> > On Mon, Feb 27, 2023 at 09:36:17AM -0800, Suren Baghdasaryan wrote:
> > > Write-locking VMAs before isolating them ensures that page fault
> > >
On Thu, Feb 16, 2023 at 10:42:52AM -0800, Josh Poimboeuf wrote:
> Include to make sure play_dead() matches its prototype going
> forward.
>
> Acked-by: Florian Fainelli
> Reviewed-by: Philippe Mathieu-Daudé
> Signed-off-by: Josh Poimboeuf
The latest version of this patch triggered a new
From: Madhavan Srinivasan
event.h header already includes utlis.h. Avoid including
the same explicitly in the code when event.h included.
Signed-off-by: Madhavan Srinivasan
---
tools/testing/selftests/powerpc/pmu/count_instructions.c | 1 -
The testcase verifies the setting of different fields in Monitor Mode
Control Register A (MMCRA). In the current code, EV_CODE_EXTRACT macro
is used to extract the "sample" field, which then needs to be further
processed to fetch rand_samp_elig and rand_samp_mode bits. But the
current code is not
On Wed, Mar 1, 2023, at 15:23, Christophe Leroy wrote:
> So, to come back about the RDB boards, we have a couple of MPC 885 ADS
> and a couple of MPC 8321 RDB. They are reference boards and we always
> check that a given kernel version properly runs on them before starting
> to port it to our
Le 28/02/2023 à 18:51, Arnd Bergmann a écrit :
> On Tue, Feb 28, 2023, at 11:03, Joakim Tjernlund wrote:
>> On Mon, 2023-02-27 at 14:48 -0600, Li Yang wrote:
>>
>> Here, we remove the MPC8548E-MDS[1], the MPC8360E-MDS[2], the
>> MPC837xE-MDS[3], and the MPC832x-MDS[4] board support
> 2023年3月1日 13:06，Christoph Hellwig 写道：
>
>> - select OF_DMA_DEFAULT_COHERENT if !NOT_COHERENT_CACHE
>
> Doesn't powerpc need to select CONFIG_ARCH_DMA_DEFAULT_COHERENT now,
> or even better should be doing that in the patch adding that
> symbol?
If I read the code correctly for powerpc
The audio on my iBook G4 (powerbook65) has not been working.
This is because the ids of the device were missing in the aoa audio driver.
With this patch, the IDs of Powerbook6,4 and Powerbook6,5 are added to the
driver.
Signed-off-by: Thaison Nguyen
---
sound/aoa/fabrics/layout.c | 15
On 01.03.23 08:03, Christophe Leroy wrote:
Le 27/02/2023 à 23:29, Rick Edgecombe a écrit :
The x86 Control-flow Enforcement Technology (CET) feature includes a new
type of memory called shadow stack. This shadow stack memory has some
unusual properties, which requires some core mm changes to
Le 27/02/2023 à 23:29, Rick Edgecombe a écrit :
> The x86 Control-flow Enforcement Technology (CET) feature includes a new
> type of memory called shadow stack. This shadow stack memory has some
> unusual properties, which requires some core mm changes to function
> properly.
>
> One of these
Since correctable errors have been corrected (and counted), the dmesg output
should not be reported as a warning, but rather as "informational".
Otherwise, using a certain well known vendor's PCIe parts in a USB4 docking
station, the dmesg buffer can be spammed with correctable errors, 717 bytes
> - select OF_DMA_DEFAULT_COHERENT if !NOT_COHERENT_CACHE
Doesn't powerpc need to select CONFIG_ARCH_DMA_DEFAULT_COHERENT now,
or even better should be doing that in the patch adding that
symbol?
In fact I wonder if adding CONFIG_ARCH_DMA_DEFAULT_COHERENT and removing
> +config ARCH_DMA_DEFAULT_COHERENT
> + bool
Please add a comment here explaining when an architecture should
ѕelect this symbol.
On Thu, Feb 23, 2023 at 11:36:41AM +, Jiaxun Yang wrote:
> dma_default_coherent was decleared unconditionally at kernel/dma/mapping.c
> but only decleared when any of non-coherent options is enabled in
> dma-map-ops.h.
Overly lone line here.
> }
> #else
> +#define dma_default_coherent
Hi Thomas,
t...@linutronix.de wrote on Fri, 11 Nov 2022 14:54:22 +0100 (CET):
> When a range of descriptors is freed then all of them are not associated to
> a linux interrupt. Remove the filter and add a warning to the free function.
>
> Signed-off-by: Thomas Gleixner
> ---
[...]
> ---
On Mon, Feb 27, 2023 at 09:36:23AM -0800, Suren Baghdasaryan wrote:
> When vma->anon_vma is not set, page fault handler will set it by either
> reusing anon_vma of an adjacent VMA if VMAs are compatible or by
> allocating a new one. find_mergeable_anon_vma() walks VMA tree to find
> a compatible
On 03/01/23 at 05:11am, Matthew Wilcox wrote:
> On Wed, Mar 01, 2023 at 04:38:10AM +, Edward Cree wrote:
> > On 01/03/2023 03:42, Baoquan He wrote:
> > > diff --git a/drivers/net/ethernet/sfc/io.h b/drivers/net/ethernet/sfc/io.h
> > > index 30439cc83a89..07f99ad14bf3 100644
> > > ---
On 3/1/23 12:26, Christophe Leroy wrote:
> Hi,
>
> Le 03/02/2022 à 04:57, Anshuman Khandual a écrit :
>> Each call into pte_mkhuge() is invariably followed by arch_make_huge_pte().
>> Instead arch_make_huge_pte() can accommodate pte_mkhuge() at the beginning.
>> This updates generic fallback
65 matches
Mail list logo
