[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <871rhfml0c.fsf@nanos.tec.linutronix.de>
Date: Fri, 30 Oct 2020 23:01:07 +0100
From: Thomas Gleixner <tglx@...utronix.de>
To: Dave Jiang <dave.jiang@...el.com>, vkoul@...nel.org,
megha.dey@...el.com, maz@...nel.org, bhelgaas@...gle.com,
alex.williamson@...hat.com, jacob.jun.pan@...el.com,
ashok.raj@...el.com, jgg@...lanox.com, yi.l.liu@...el.com,
baolu.lu@...el.com, kevin.tian@...el.com, sanjay.k.kumar@...el.com,
tony.luck@...el.com, jing.lin@...el.com, dan.j.williams@...el.com,
kwankhede@...dia.com, eric.auger@...hat.com, parav@...lanox.com,
jgg@...lanox.com, rafael@...nel.org, netanelg@...lanox.com,
shahafs@...lanox.com, yan.y.zhao@...ux.intel.com,
pbonzini@...hat.com, samuel.ortiz@...el.com, mona.hossain@...el.com
Cc: dmaengine@...r.kernel.org, linux-kernel@...r.kernel.org,
linux-pci@...r.kernel.org, kvm@...r.kernel.org
Subject: Re: [PATCH v4 01/17] irqchip: Add IMS (Interrupt Message Store) driver
On Fri, Oct 30 2020 at 11:50, Dave Jiang wrote:
> --- a/include/linux/interrupt.h
> +++ b/include/linux/interrupt.h
> @@ -487,6 +487,8 @@ extern int irq_get_irqchip_state(unsigned int irq, enum irqchip_irq_state which,
> extern int irq_set_irqchip_state(unsigned int irq, enum irqchip_irq_state which,
> bool state);
>
> +int irq_set_auxdata(unsigned int irq, unsigned int which, u64 val);
....
> +EXPORT_SYMBOL_GPL(irq_set_auxdata);
Again: Read and follow documentation. This does not belong into this
driver patch and wants to be a standalone preperatory patch.
Also the core change, the irq chip, the iommu support and the device msi
dependency has to be completely seperate from this idxd series.
You cannot just dump a pile of patches touching several subsystems at
once plus having dependencies on stuff which is not even agreed on and
merged and then expect that everything just falls into place.
The various subsystems involved are not holding their breath and putting
a lock on development just because you have a series against some random
snapshot.
The dependencies, e.g. the device msi infrastructure, are not going to
make their way magically into the proper maintainer tree either.
If this ever goes into a mergeable state, then the merge logistics for
this whole thing need to be carefully sorted out and it's on you to make
that as simple as possible for every maintainer involved.
Thanks,
tglx
Powered by blists - more mailing lists