[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4223511b-8dc0-33d1-6af1-831d8bf40b3d@intel.com>
Date: Mon, 27 Apr 2020 14:38:12 -0700
From: Dave Jiang <dave.jiang@...el.com>
To: Greg KH <gregkh@...uxfoundation.org>
Cc: vkoul@...nel.org, megha.dey@...ux.intel.com, maz@...nel.org,
bhelgaas@...gle.com, rafael@...nel.org, tglx@...utronix.de,
hpa@...or.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,
dmaengine@...r.kernel.org, linux-kernel@...r.kernel.org,
x86@...nel.org, linux-pci@...r.kernel.org, kvm@...r.kernel.org
Subject: Re: [PATCH RFC 01/15] drivers/base: Introduce platform_msi_ops
On 4/26/2020 12:01 AM, Greg KH wrote:
> On Tue, Apr 21, 2020 at 04:33:53PM -0700, Dave Jiang wrote:
>> From: Megha Dey <megha.dey@...ux.intel.com>
>>
>> This is a preparatory patch to introduce Interrupt Message Store (IMS).
>>
>> Until now, platform-msi.c provided a generic way to handle non-PCI MSI
>> interrupts. Platform-msi uses its parent chip's mask/unmask routines
>> and only provides a way to write the message in the generating device.
>>
>> Newly creeping non-PCI complaint MSI-like interrupts (Intel's IMS for
>> instance) might need to provide a device specific mask and unmask callback
>> as well, apart from the write function.
>>
>> Hence, introduce a new structure platform_msi_ops, which would provide
>> device specific write function as well as other device specific callbacks
>> (mask/unmask).
>>
>> Signed-off-by: Megha Dey <megha.dey@...ux.intel.com>
>
> As this is not following the Intel-specific rules for sending me new
> code, I am just deleting it all from my inbox.
That is my fault. As the aggregator of the patches, I should've signed
off Megha's patches.
>
> Please follow the rules you all have been given, they are specific and
> there for a reason. And in looking at this code, those rules are not
> going away any time soon.
>
> greg k-h
>
Powered by blists - more mailing lists