On Thu, Jun 26 2025 at 16:47, Nam Cao wrote:
> The solution is implementing per device MSI domains, this means the
> entities which provide global PCI/MSI domain so far have to implement MSI
> parent domain functionality instead.
>
> This series:
>
>- Untangle XIVE driver from Powernv and Pseri
On Wed, Mar 19 2025 at 10:28, Jiri Slaby wrote:
> Hi,
>
> tl;dr if patches are agreed upon, I ask subsys maintainers to take the
> respective ones via their trees (as they are split per subsys), so that
> the IRQ tree can take only the rest. That would minimize churn/conflicts
> during merges.
So
On Sat, Feb 22 2025 at 16:17, Xi Ruoyao wrote:
> On Tue, 2025-02-04 at 13:05 +0100, Thomas Weißschuh wrote:
>> The generic storage implementation provides the same features as the
>> custom one. However it can be shared between architectures, making
>> maintenance easier.
>>
>> Co-developed-by: Na
David!
On Thu, Feb 06 2025 at 09:31, David Woodhouse wrote:
> Thanks for working on this. Is there a plan to expose the time data
> directly to userspace in a form which is usable *other* than by
> function calls which get the value of the clock at a given moment?
>
> For populating the vmclock de
teven Rostedt (Google) # for kernel/trace/
> Reviewed-by: Martin K. Petersen # SCSI
> Reviewed-by: Darrick J. Wong # xfs
> Acked-by: Jani Nikula
> Acked-by: Corey Minyard
> Signed-off-by: Joel Granados
Acked-by: Thomas Gleixner
On Wed, Dec 04 2024 at 11:40, Eliav Farber wrote:
> I'm just waiting for a reply if the new configuration option should be
> placed inside or after the following section:
I think you got one yesterday :)
On Tue, Dec 03 2024 at 12:55, Eliav Farber wrote:
> On 12/3/2024 1:04 PM, Thomas Gleixner wrote:
>>> +
>>> +config GENERIC_IRQ_KEXEC_CLEAR_VM_FORWARD
>>> + bool "Clear forwarded VM interrupts during kexec"
>>
>> This should n
On Sat, Nov 30 2024 at 20:11, Eliav Farber wrote:
> +
> +config GENERIC_IRQ_KEXEC_CLEAR_VM_FORWARD
> + bool "Clear forwarded VM interrupts during kexec"
This should not be user selectable. Just keep it as:
config GENERIC_IRQ_KEXEC_CLEAR_VM_FORWARD
bool
which defaults to 'n'. Just add
On Sat, Nov 30 2024 at 20:08, Eliav Farber wrote:
> On 11/29/2024 3:30 PM, Thomas Gleixner wrote:
>> Looking deeper. This function actually cannot be called from this
>> context. It does:
>>
>> irq_get_desc_buslock(irq, &flags, 0);
>>
>> which
On Fri, Nov 29 2024 at 11:31, Eliav Farber wrote:
>
> This patch addresses the issue by:
Again: git grep 'This patch' Documentation/process/
On Fri, Nov 29 2024 at 11:31, Eliav Farber wrote:
> Move the machine_kexec_mask_interrupts function to a common location in
> kernel/kexec_core.c, removing duplicate implementations from architecture
> specific files (arch/arm, arch/arm64, arch/powerpc, and arch/riscv).
Can you please move this in
On Wed, Nov 27 2024 at 15:22, Eliav Farber wrote:
As a related note. The subject line is not really matching what the
patch does. It want's to be split into a core change and one patch per
architecture.
> This patch replaces the direct invocation of the irq_mask() and
git grep 'This patch' Docum
On Wed, Nov 27 2024 at 15:22, Eliav Farber wrote:
> diff --git a/arch/arm/kernel/machine_kexec.c b/arch/arm/kernel/machine_kexec.c
> index 80ceb5bd2680..54d0bd1bd449 100644
> --- a/arch/arm/kernel/machine_kexec.c
> +++ b/arch/arm/kernel/machine_kexec.c
> @@ -142,11 +142,8 @@ static void machine_kex
On Thu, Nov 14 2024 at 23:51, Michael Ellerman wrote:
> The powerpc Cell blade support, now removed, was the only user of
> IRQ_EDGE_EOI_HANDLER, so remove it.
>
> Signed-off-by: Michael Ellerman
Acked-by: Thomas Gleixner
On Fri, Nov 15 2024 at 14:15, Easwar Hariharan wrote:
> On 11/15/2024 1:41 PM, Jeff Johnson wrote:
>>
>> How do you expect this series to land since it overlaps a large number of
>> maintainer trees? Do you have a maintainer who has volunteered to take the
>> series and the maintainers should just
On Mon, Nov 11 2024 at 11:19, Luming Yu wrote:
> Due to the common layer and internal calls details are hidden from
> the top level at the call side in ppc arch code, there are some
> difficulties in preserving
> all semantics implications of the original code in the patch. e.g when
> we got -1 re
On Mon, Nov 11 2024 at 11:19, Luming Yu wrote:
> cleanup do_syscall_trace_enter/leave and do_seccomp.
What's the cleanup here? All what this patch does is removing code, but
what replaces that functionality?
The subject line should probably be: "Break syscall entry"
Thanks,
tglx
On Mon, Nov 11 2024 at 11:19, Luming Yu wrote:
> generic irq entry support via generic irqentry is added for powerpc.
> There may be duplciate calls and missing callbacks requires further
> work.
No. This needs to be a transition which is consistent and correct at any
stage of the series.
You can
On Mon, Nov 11 2024 at 11:19, Luming Yu wrote:
> enable the common entry of user return notifier for powerpc as
> a debug feature.
What's the debug feature?
There are ZERO user return notifiers registered in PowerPC, so your
"debug feature" is just a waste of CPU cycles.
Thanks,
tglx
On Mon, Nov 11 2024 at 11:19, Luming Yu wrote:
factout?
> To have lowlevel paca.h include high level entry-common.h cause
> include file dependency mess.
That's not a technical explanation which explains which problem this
patch is trying to solve.
> Split irqentry-state.h to have the irqentry_
David!
On Sun, Nov 03 2024 at 16:05, David Wang wrote:
$Subject: [PATCH] kernel/irq/proc: performance: ...
That's not a valid subsystem prefix.
> seq_printf is costy, when stress reading /proc/interrupts, profiling indicates
> seq_printf takes about ~47% of show_interrupts samples:
Also please
On Fri, Nov 01 2024 at 11:18, Yicong Yang wrote:
> On 2024/10/31 21:33, Thomas Gleixner wrote:
>> cpu_smt_control is not guaranteed to have CPU_SMT_ENABLED state, so this
>> argument is bogus.
>>
> sorry for didn't explain all the cases here.
>
> For
On Thu, Oct 31 2024 at 20:17, Yicong Yang wrote:
> On 2024/10/30 22:55, Thomas Gleixner wrote:
>>> +static inline bool topology_is_primary_thread(unsigned int cpu)
>>> +{
>>> + /*
>>> +* On SMT hotplug the primary thread of the SMT won't be
On Wed, Oct 30 2024 at 20:54, Yicong Yang wrote:
>
> +#ifndef topology_is_primary_thread
> +#define topology_is_primary_thread topology_is_primary_thread
Please do not glue defines and functions together w/o a newline in between.
> +static inline bool topology_is_primary_thread(unsigned int cpu
On Sat, Oct 12 2024 at 11:56, Luming Yu wrote:
> To have lowlevel paca.h include high level entry-common.h cause
> include file dependency mess. Split irqentry-state.h to have
> the irqentry_state.h can be included in low level paca.h
What's the rationale for this?
> Signed-off-by: Luming Yu
>
On Mon, Sep 16 2024 at 22:20, Christophe JAILLET wrote:
> Le 11/09/2024 à 07:13, Anna-Maria Behnsen a écrit :
>
> not directly related to your serie, but some time ago I sent a patch to
> micro-optimize Optimize usleep_range(). (See [1])
>
> The idea is that the 2 parameters of usleep_range() are
On Mon, Sep 16 2024 at 15:20, Costa Shulyupin wrote:
> Interrupts disturb real-time tasks on affined cpus.
> To ensure CPU isolation for real-time tasks, interrupt handling must
> be adjusted accordingly.
> Non-managed interrupts can be configured from userspace,
> while managed interrupts require
On Mon, Sep 16 2024 at 15:20, Costa Shulyupin wrote:
> +/*
> + * housekeeping_update - change housekeeping.cpumasks[type] and propagate the
> + * change.
> + */
> +static int housekeeping_update(enum hk_type type, const struct cpumask
> *update)
> +{
> + struct {
> + struct cpumask
On Fri, Aug 30 2024 at 22:21, Ma Ke wrote:
> Zero and negative number is not a valid IRQ for in-kernel code and the
> irq_of_parse_and_map() function returns zero on error. So this check for
> valid IRQs should only accept values > 0.
The subsystem prefix is wrong. This changes drivers/i2c/busses
On Mon, Aug 26 2024 at 12:45, Christophe Leroy wrote:
> Le 26/08/2024 à 10:58, Jason A. Donenfeld a écrit :
>> On Mon, Aug 26, 2024 at 10:37:49AM +0200, Christophe Leroy wrote:
>>>
>>>
>>> Le 26/08/2024 à 10:07, Jason A. Donenfeld a écrit :
On Thu, Aug 22, 2024 at 09:13:10AM +0200, Christophe
On Mon, Aug 26 2024 at 10:01, Christophe Leroy wrote:
> Le 26/08/2024 à 09:50, Jason A. Donenfeld a écrit :
>> But tglx pointed out in that thread that this actually isn't necessary:
>>
>> | All of this is pointless because if a 32-bit application runs on a
>> | 64-bit kernel it has to use the 64-
hree drivers overriding it depend on that. They should
> probably also be marked broken, but we can give them a bit of a grace
> period for that.
One week :)
> Signed-off-by: Christoph Hellwig
Reviewed-by: Thomas Gleixner
On Thu, Aug 08 2024 at 10:54, Peter Xu wrote:
> On Thu, Aug 08, 2024 at 12:22:38AM +0200, Thomas Gleixner wrote:
>> On Wed, Aug 07 2024 at 15:48, Peter Xu wrote:
>> > An entry should be reported as PUD leaf even if it's PROT_NONE, in which
>> > case PRESENT bit is
On Wed, Aug 07 2024 at 15:48, Peter Xu wrote:
> These new helpers will be needed for pud entry updates soon. Introduce
> these helpers by referencing the pmd ones. Namely:
>
> - pudp_invalidate()
> - pud_modify()
Zero content about what these helpers do and why they are needed. That's
not how it
On Wed, Aug 07 2024 at 15:48, Peter Xu wrote:
> Subject: mm/x86: arch_check_zapped_pud()
Is not a proper subject line. It clearly lacks a verb.
Subject: mm/x86: Implement arch_check_zapped_pud()
> Introduce arch_check_zapped_pud() to sanity check shadow stack on PUD zaps.
> It has the same l
On Wed, Aug 07 2024 at 15:48, Peter Xu wrote:
> An entry should be reported as PUD leaf even if it's PROT_NONE, in which
> case PRESENT bit isn't there. I hit bad pud without this when testing dax
> 1G on zapping a PROT_NONE PUD.
That does not qualify as a change log. What you hit is irrelevant un
> Signed-off-by: Michael Ellerman
Reviewed-by: Thomas Gleixner
Assuming this goes through the PPC tree:
Reviewed-by: Thomas Gleixner
Michael: If I should route it through my tree, let me know.
Thanks,
tglx
On Fri, Jul 12 2024 at 15:16, Vignesh Balasubramanian wrote:
> diff --git a/arch/x86/include/asm/elf.h b/arch/x86/include/asm/elf.h
> index 1fb83d477..cad37090b 100644
> --- a/arch/x86/include/asm/elf.h
> +++ b/arch/x86/include/asm/elf.h
> @@ -13,6 +13,15 @@
> #include
> #include
>
> +struct
On Tue, Jun 25 2024 at 00:41, Shrikanth Hegde wrote:
> On 6/24/24 1:44 AM, Thomas Gleixner wrote:
>> Right. So changing it not to online a thread when the full core is
>> offline should not really break stuff.
>>
>> OTH, the mechanism to figure that out on x86 is defin
Michael!
On Thu, Jun 13 2024 at 21:34, Michael Ellerman wrote:
> IIUIC the regression was in the ppc64_cpu userspace tool, which switched
> to using the new kernel interface without taking into account the way it
> behaves.
>
> Or are you saying the kernel behaviour changed on x86 after the powerp
On Tue, May 07 2024 at 15:23, Vignesh Balasubramanian wrote:
> +struct xfeat_component {
> + u32 xfeat_type;
> + u32 xfeat_sz;
> + u32 xfeat_off;
> + u32 xfeat_flags;
> +} __packed;
Why repeating xfeat_ for all member names?
u32 type;
u32 size;
u32 of
On Wed, Apr 10 2024 at 14:45, Bitao Hu wrote:
> On 2024/4/9 17:58, Thomas Gleixner wrote:
> By the way, what do you think of my reason for using printk() instead of
> pr_crit()? Should I change this part of the code in v13?
Either way is fine. Just put a proper explanation into the chan
elta
> of a specific interrupt later on.
>
> Originally-by: Thomas Gleixner
> Signed-off-by: Bitao Hu
> Reviewed-by: Liu Song
> Reviewed-by: Douglas Anderson
This does not apply anymore.
Also can you please split this apart to convert kstat_irqs to a struct
with just t
On Wed, Mar 06 2024 at 20:52, Bitao Hu wrote:
> + if (__this_cpu_read(snapshot_taken)) {
> + for_each_active_irq(i) {
> + count = kstat_get_irq_since_snapshot(i);
> + tabulate_irq_count(irq_counts_sorted, i, count,
> NUM_HARDIRQ_REPORT);
> +
On Thu, Mar 14 2024 at 17:29, Borislav Petkov wrote:
> On Thu, Mar 14, 2024 at 09:19:15AM -0700, Dave Hansen wrote:
>> Are you envisioning an *XSAVE* state component that's not described by
>> CPUID?
>
> I want to be prepared. You can imagine some of the short cuts and
> corners cutting hw guys wou
On Wed, Mar 06 2024 at 15:14, Arnd Bergmann wrote:
> From: Arnd Bergmann
>
> Naresh noticed that the newly added usage of the PAGE_SIZE macro in
> include/vdso/datapage.h introduced a build regression. I had an older
> patch that I revived to have this defined through Kconfig rather than
> through
n one and allow
> only the hardware page size to be selected.
>
> Acked-by: Guo Ren
> Acked-by: Heiko Carstens
> Acked-by: Stafford Horne
> Acked-by: Johannes Berg
> Signed-off-by: Arnd Bergmann
Reviewed-by: Thomas Gleixner
e
> leaving the arhcitecture specific ones as the user visible
> place for configuring it, to avoid breaking user configs.
>
> Reviewed-by: Christophe Leroy (powerpc32)
> Acked-by: Catalin Marinas
> Acked-by: Helge Deller # parisc
> Signed-off-by: Arnd Bergmann
Reviewed-by: Thomas Gleixner
off-by: Arnd Bergmann
Reviewed-by: Thomas Gleixner
On Tue, Mar 05 2024 at 18:57, Bitao Hu wrote:
> On 2024/3/4 22:24, Thomas Gleixner wrote:
> "GENERIC_IRQ_STAT_SNAPSHOT" visible to the user. However, after
> analyzing the previous emails, it seems that what you were actually
> proposing was to directly disable "GENE
On Mon, Mar 04 2024 at 20:00, Bitao Hu wrote:
>> +# Snapshot for interrupt statistics
>> +config GENERIC_IRQ_STAT_SNAPSHOT
>> +bool
>> +
>> # Support forced irq threading
>> config IRQ_FORCED_THREADING
>> bool
>
> I think we should follow Douglas's suggestion by making
> "config GE
On Thu, Feb 29 2024 at 16:42, pet...@redhat.com wrote:
> From: Peter Xu
>
> pud_leaf() has a fallback macro defined in include/linux/pgtable.h already.
> Drop the extra two for x86.
>
> Cc: Thomas Gleixner
> Cc: Ingo Molnar
> Cc: Borislav Petkov
> Cc: Dave Ha
Doug!
On Wed, Feb 28 2024 at 14:44, Doug Anderson wrote:
> I won't insist on it, but I continue to worry about memory
> implications with large numbers of CPUs. With a 4-byte int, 8192 max
> CPUs, and 100 IRQs the extra "ref" value takes up over 3MB of memory
> (8192 * 4 bytes * 100).
>
> Technica
On Tue, Feb 27 2024 at 19:20, Bitao Hu wrote:
> On 2024/2/27 17:26, Thomas Gleixner wrote:
>>
>> and then let kstat_irqs() and show_interrupts() use it. See?
>
> I have a concern. kstat_irqs() uses for_each_possible_cpu() for
> summation. However, show_interrupts()
On Mon, Feb 26 2024 at 10:09, Bitao Hu wrote:
> We could use the irq_desc::tot_count member to avoid the summation
> loop for interrupts which are not marked as 'PER_CPU' interrupts in
> 'show_interrupts'. This could reduce the time overhead of reading
> /proc/interrupts.
"Could" is not really a t
On Fri, Feb 23 2024 at 15:18, Bitao Hu wrote:
> On 2024/2/22 21:22, Thomas Gleixner wrote:
>>> - if (desc->kstat_irqs) {
>>> - for_each_online_cpu(j)
>>> - any_count |= data_race(*per_cpu_ptr(desc->kstat_irqs,
>>>
On Thu, Feb 22 2024 at 17:34, Bitao Hu wrote:
First of all the subsystem prefix is 'genirq:'. 'git log kernel/irq/'
gives you a pretty good hint. It's documented
Secondly the subject line does not match what this patch is about. It's
not about using a struct, it's about providing a snapshot m
On Tue, Feb 20 2024 at 00:19, Bitao Hu wrote:
> arch/mips/dec/setup.c| 2 +-
> arch/parisc/kernel/smp.c | 2 +-
> arch/powerpc/kvm/book3s_hv_rm_xics.c | 2 +-
> include/linux/irqdesc.h | 9 ++-
> include/linux/kernel_stat.h | 4 +
> kerne
On Thu, Sep 14 2023 at 20:01, Maciej W. Rozycki wrote:
> On Thu, 14 Sep 2023, John Ogness wrote:
>
>> Patches 2-74 switch all uart port locking call sites to use the new
>> wrappers. These patches were automatically generated using coccinelle.
>
> Hmm, no need to do this for drivers/tty/serial/zs
On Fri, Jul 28 2023 at 14:23, Rui Zhang wrote:
> On Fri, 2023-07-28 at 09:40 +0200, Thomas Gleixner wrote:
>> On Sun, Jul 09 2023 at 15:25, Rui Zhang wrote:
>> > I ran into a boot hang regression with latest upstream code, and it
>> > took me a while to bisect the offe
Laurent, Michael!
On Wed, Jul 05 2023 at 16:51, Laurent Dufour wrote:
> I'm taking over the series Michael sent previously [1] which is smartly
> reviewing the initial series I sent [2]. This series is addressing the
> comments sent by Thomas and me on the Michael's one.
Thanks for getting this
Rui!
On Sun, Jul 09 2023 at 15:25, Rui Zhang wrote:
> I ran into a boot hang regression with latest upstream code, and it
> took me a while to bisect the offending commit and workaround it.
Where is the bug report and the analysis? And what's the workaround?
Thanks,
tglx
On Thu, Jun 15 2023 at 17:46, Laurent Dufour wrote:
>
> - if (ctrlval != cpu_smt_control) {
> + orig_threads = cpu_smt_num_threads;
> + cpu_smt_num_threads = num_threads;
> +
> + if (num_threads > orig_threads) {
> + ret = cpuhp_smt_enable();
> + } else if (num_thr
On Thu, Jun 15 2023 at 17:46, Laurent Dufour wrote:
> From: Michael Ellerman
>
> A subsequent patch would like to use the cpuhp_smt_control enum as part
> of the interface between generic and arch code.
This still has the 'patch' and 'arch' style which I pointed out
before. It seems you fixed it
Kent!
On Sun, Jun 18 2023 at 19:14, Kent Overstreet wrote:
> On Mon, Jun 19, 2023 at 12:32:55AM +0200, Thomas Gleixner wrote:
>
> Thomas, you're confusing an internal interface with external
No. I am not.
Whether that's an internal function or not does not make any differenc
ead.
I don't know what caused you to decide that ad hoc hackery is better
than proper data structure based design patterns. I actually don't want
to know.
As much as my voice counts:
NAK-ed-by: Thomas Gleixner
Thanks,
tglx
On Tue, Jun 13 2023 at 19:16, Laurent Dufour wrote:
> On 10/06/2023 23:26:18, Thomas Gleixner wrote:
>> On Thu, May 25 2023 at 01:56, Michael Ellerman wrote:
>>> #ifdef CONFIG_HOTPLUG_SMT
>>> enum cpuhp_smt_control cpu_smt_control __read_mostly = CPU_SMT_ENABLE
On Mon, Jun 12 2023 at 17:20, Laurent Dufour wrote:
> On 10/06/2023 23:10:02, Thomas Gleixner wrote:
>> This needs more thoughts to avoid a completely inconsistent duct tape
>> mess.
>
> Despite the test against smt_enabled_at_boot, mentioned above, I can't see
>
On Thu, May 25 2023 at 01:56, Michael Ellerman wrote:
> A subsequent patch will enable partial SMT states, ie. when not all SMT
> threads are brought online.
Nitpick. I stumbled over this 'subsequent patch' theme a couple of times
now because it's very similar to the 'This patch does' phrase.
Jus
On Thu, May 25 2023 at 01:56, Michael Ellerman wrote:
> +/**
> + * topology_smt_threads_supported - Check if the given number of SMT threads
> + * is supported.
> + *
> + * @threads: The number of SMT threads.
> + */
> +bool topology_smt_threads_supported(unsigned int
On Sat, Jun 10 2023 at 23:26, Thomas Gleixner wrote:
> On Thu, May 25 2023 at 01:56, Michael Ellerman wrote:
> /*
> * The decision whether SMT is supported can only be done after the full
> * CPU identification. Called from architecture code.
> */
> -void __init cpu_smt_c
On Thu, May 25 2023 at 01:56, Michael Ellerman wrote:
> #ifdef CONFIG_HOTPLUG_SMT
> enum cpuhp_smt_control cpu_smt_control __read_mostly = CPU_SMT_ENABLED;
> +static unsigned int cpu_smt_max_threads __ro_after_init;
> +unsigned int cpu_smt_num_threads;
Why needs this to be global? cpu_smt_contro
On Thu, Jun 01 2023 at 18:19, Laurent Dufour wrote:
> @@ -435,12 +435,17 @@ void __init cpu_smt_disable(bool force)
> * The decision whether SMT is supported can only be done after the full
> * CPU identification. Called from architecture code.
> */
> -void __init cpu_smt_check_topology(unsig
On Thu, May 25 2023 at 01:56, Michael Ellerman wrote:
> There is a hook which allows arch code to control how many threads per
Can you please write out architecture in changelogs and comments?
I know 'arch' is commonly used but while my brain parser tolerates
'arch_' prefixes it raises an excepti
On Sat, Jun 10 2023 at 22:09, Thomas Gleixner wrote:
> On Thu, May 25 2023 at 01:56, Michael Ellerman wrote:
>> There is a hook which allows arch code to control how many threads per
>
> Can you please write out architecture in changelogs and comments?
>
> I know 'arch&#
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 Sun, Nov 27 2022 at 09:53, Paul E. McKenney wrote:
> On Sun, Nov 27, 2022 at 01:40:28PM +0100, Thomas Gleixner wrote:
>> There are quite some reasons why a CPU-hotplug or a hot-unplug operation
>> can fail, which is not a fatal problem, really.
>>
>> So if a CPU ho
Zhouyi,
On Sun, Nov 27 2022 at 10:45, Zhouyi Zhou wrote:
> On Sun, Nov 27, 2022 at 1:05 AM Thomas Gleixner wrote:
>
> So, I should construct my patch as:
> We avoid ... by ...
Not "We avoid".
Avoid this behaviour by
>> No. We are not exporting this just to
On Mon, Nov 21 2022 at 11:51, Zhouyi Zhou wrote:
> During CPU-hotplug torture (CONFIG_NO_HZ_FULL=y), if we try to
> offline tick_do_timer_cpu, the operation will fail because in
> function tick_nohz_cpu_down:
> ```
> if (tick_nohz_full_running && tick_do_timer_cpu == cpu)
> return -EBUSY;
> `
Jason, Bjorn, Ashok!
On Wed, Nov 16 2022 at 14:05, Jason Gunthorpe wrote:
> On Fri, Nov 11, 2022 at 02:55:17PM +0100, Thomas Gleixner wrote:
>> Now that the PCI/MSI core code does early checking for multi-MSI support
>> X86_IRQ_ALLOC_CONTIGUOUS_VECTORS is not required anymore.
On Wed, Nov 16 2022 at 07:39, Ashok Raj wrote:
> On Fri, Nov 11, 2022 at 02:54:15PM +0100, Thomas Gleixner wrote:
>
> Can the pre-enabled checks for msi and msix be moved up before any vector
> range check?
>
> not that it matters for how it fails, does EBUSY sound better?
Do
On Wed, Nov 16 2022 at 10:31, Bjorn Helgaas wrote:
> On Fri, Nov 11, 2022 at 02:55:09PM +0100, Thomas Gleixner wrote:
>>
>> +/**
>> + * pci_msi_domain_supports - Check for support of a particular feature flag
>> + * @pdev: The PCI device to operate on
On Wed, Nov 16 2022 at 13:51, Jason Gunthorpe wrote:
> On Fri, Nov 11, 2022 at 02:54:35PM +0100, Thomas Gleixner wrote:
>> /* PCI-MSI is oneshot-safe */
>> info->chip->flags |= IRQCHIP_ONESHOT_SAFE;
>> +/* Let the core update the bus token
On Wed, Nov 16 2022 at 13:49, Jason Gunthorpe wrote:
> On Fri, Nov 11, 2022 at 02:54:33PM +0100, Thomas Gleixner wrote:
>> From: Ahmed S. Darwish
>>
>> Add a bus token member to struct msi_domain_info and let
>> msi_create_irq_domain() set the bus token.
>>
On Wed, Nov 16 2022 at 13:44, Jason Gunthorpe wrote:
> On Fri, Nov 11, 2022 at 02:54:27PM +0100, Thomas Gleixner wrote:
>> To prepare for removing the exposure of __msi_domain_free_irqs() provide a
>> post_free() callback in the MSI domain ops which can be used to solve
>> th
On Wed, Nov 16 2022 at 10:28, Bjorn Helgaas wrote:
> On Fri, Nov 11, 2022 at 02:55:06PM +0100, Thomas Gleixner wrote:
>> From: Ahmed S. Darwish
>>
>> There is no way to navigate msi.c without banging the head against the wall
>> every now and then because MSI and M
On Wed, Nov 16 2022 at 10:26, Bjorn Helgaas wrote:
>> /**
>> + * pci_disable_msix() - Disable MSI-X interrupt mode on device
>> + * @dev: the PCI device to operate on
>> + *
>> + * Legacy device driver API to disable MSI-X interrupt mode on device,
>> + * free earlier-allocated interrupt vectors,
On Wed, Nov 16 2022 at 10:23, Bjorn Helgaas wrote:
> On Fri, Nov 11, 2022 at 02:54:51PM +0100, Thomas Gleixner wrote:
>> + * Same as pci_alloc_irq_vectors(), but with the extra @affd parameter.
>> + * Check that function docs, and &struct irq_affinity, for more detai
On Wed, Nov 16 2022 at 10:22, Bjorn Helgaas wrote:
>> + * Allocate up to @max_vecs interrupt vectors on device. MSI-X irq
>
> s/irq/IRQ/
>
>> + * vector allocation has a higher precedence over plain MSI, which has a
>> + * higher precedence over legacy INTx emulation.
>> + *
>> + * Upon a successfu
On Wed, Nov 16 2022 at 10:18, Bjorn Helgaas wrote:
> On Fri, Nov 11, 2022 at 02:54:46PM +0100, Thomas Gleixner wrote:
>> From: Ahmed S. Darwish
>>
>> To distangle the maze in msi.c all exported device-driver MSI APIs are now
>> to be grouped in one file, api.c.
>&
On Wed, Nov 16 2022 at 10:12, Bjorn Helgaas wrote:
> On Fri, Nov 11, 2022 at 02:54:38PM +0100, Thomas Gleixner wrote:
>> What a zoo:
>>
>> PCI_MSI
>> select GENERIC_MSI_IRQ
>>
>> PCI_MSI_IRQ_DOMAIN
>> def_boo
On Wed, Nov 16 2022 at 08:02, Ashok Raj wrote:
> On Fri, Nov 11, 2022 at 02:54:19PM +0100, Thomas Gleixner wrote:
>> PCI/Multi-MSI is MSI specific and not supported for MSI-X
>>
>> Signed-off-by: Thomas Gleixner
>> ---
>> drivers/iommu/amd/iommu.c |3 +-
On Wed, Nov 16 2022 at 07:52, Ashok Raj wrote:
> On Fri, Nov 11, 2022 at 02:54:17PM +0100, Thomas Gleixner wrote:
>> PCI/Multi-MSI is MSI specific and not supported for MSI-X.
>>
>> Signed-off-by: Thomas Gleixner
>> ---
>> drivers/iommu/intel/irq_remapping.c
grouped together.
Suggested-by: Thomas Gleixner
Signed-off-by: Ahmed S. Darwish
Signed-off-by: Thomas Gleixner
---
drivers/pci/msi/msi.c | 577 +-
1 file changed, 295 insertions(+), 282 deletions(-)
--- a/drivers/pci/msi/msi.c
+++ b/drivers/pci
rray.
Signed-off-by: Thomas Gleixner
---
drivers/pci/msi/msi.c | 11 +--
1 file changed, 9 insertions(+), 2 deletions(-)
--- a/drivers/pci/msi/msi.c
+++ b/drivers/pci/msi/msi.c
@@ -725,13 +725,17 @@ static int msix_capability_init(struct p
return ret;
}
-static bool pci_msix_val
. Darwish
Signed-off-by: Thomas Gleixner
---
drivers/pci/msi/api.c | 59 +++-
drivers/pci/msi/msi.c | 65
+
2 files changed, 59 insertions(+), 65 deletions(-)
---
diff --git a/drivers/pci/msi/api.c b
From: Ahmed S. Darwish
All exported device-driver MSI APIs are now grouped in one place at
drivers/pci/msi/api.c with comprehensive kernel-docs added.
Reference these kernel-docs in the official PCI/MSI howto.
Signed-off-by: Ahmed S. Darwish
Signed-off-by: Thomas Gleixner
---
Documentation
From: Ahmed S. Darwish
To distangle the maze in msi.c, all exported device-driver MSI APIs are
now to be grouped in one file, api.c.
Move pci_disable_msix() and make its kernel-doc comprehensive.
Signed-off-by: Ahmed S. Darwish
Signed-off-by: Thomas Gleixner
---
drivers/pci/msi/api.c | 24
There is no point in doing the same sanity checks over and over in a loop
during MSI-X enablement. Put them in front of the loop and return early
when they fail.
Signed-off-by: Thomas Gleixner
---
drivers/pci/msi/msi.c | 67 +-
1 file changed
1 - 100 of 814 matches
Mail list logo
