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
From: Ahmed S. Darwish
The upcoming support for per device MSI interrupt domains needs to share
some of the inline helpers with the MSI implementation.
Move them to the header file.
Signed-off-by: Ahmed S. Darwish
Signed-off-by: Thomas Gleixner
---
drivers/pci/msi/msi.c | 61
1 - 100 of 813 matches
Mail list logo
