Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1236829 > unrolled thread

[PATCH 0/2] uio_msi: device driver

Back to article view | Back to linux.kernel

Contents

  [PATCH 0/2] uio_msi: device driver Stephen Hemminger <stephen@networkplumber.org> - 2015-10-01 00:30 +0200
    [PATCH 2/2] uio: new driver to support PCI MSI-X Stephen Hemminger <stephen@networkplumber.org> - 2015-10-01 00:30 +0200
      Re: [PATCH 2/2] uio: new driver to support PCI MSI-X "Michael S. Tsirkin" <mst@redhat.com> - 2015-10-01 10:40 +0200
        Re: [PATCH 2/2] uio: new driver to support PCI MSI-X "Michael S. Tsirkin" <mst@redhat.com> - 2015-10-01 12:40 +0200
          Re: [PATCH 2/2] uio: new driver to support PCI MSI-X "Michael S. Tsirkin" <mst@redhat.com> - 2015-10-01 18:10 +0200
        Re: [PATCH 2/2] uio: new driver to support PCI MSI-X Stephen Hemminger <stephen@networkplumber.org> - 2015-10-01 17:00 +0200
          Re: [PATCH 2/2] uio: new driver to support PCI MSI-X "Michael S. Tsirkin" <mst@redhat.com> - 2015-10-01 17:30 +0200
        Re: [PATCH 2/2] uio: new driver to support PCI MSI-X "Michael S. Tsirkin" <mst@redhat.com> - 2015-10-01 18:40 +0200
          Re: [PATCH 2/2] uio: new driver to support PCI MSI-X Stephen Hemminger <stephen@networkplumber.org> - 2015-10-01 19:30 +0200
            Re: [PATCH 2/2] uio: new driver to support PCI MSI-X "Michael S. Tsirkin" <mst@redhat.com> - 2015-10-01 20:30 +0200
        Re: [PATCH 2/2] uio: new driver to support PCI MSI-X "Michael S. Tsirkin" <mst@redhat.com> - 2015-10-06 00:00 +0200
      Re: [dpdk-dev] [PATCH 2/2] uio: new driver to support PCI MSI-X Alexander Duyck <alexander.duyck@gmail.com> - 2015-10-02 01:50 +0200
        Re: [dpdk-dev] [PATCH 2/2] uio: new driver to support PCI MSI-X Stephen Hemminger <stephen@networkplumber.org> - 2015-10-02 02:10 +0200
          Re: [dpdk-dev] [PATCH 2/2] uio: new driver to support PCI MSI-X Alexander Duyck <alexander.duyck@gmail.com> - 2015-10-02 04:40 +0200
        Re: [dpdk-dev] [PATCH 2/2] uio: new driver to support PCI MSI-X Stephen Hemminger <stephen@networkplumber.org> - 2015-10-02 02:10 +0200
          Re: [dpdk-dev] [PATCH 2/2] uio: new driver to support PCI MSI-X Alexander Duyck <alexander.duyck@gmail.com> - 2015-10-02 03:30 +0200
    [PATCH 1/2] uio: add support for ioctls Stephen Hemminger <stephen@networkplumber.org> - 2015-10-01 00:30 +0200
    Re: [PATCH 0/2] uio_msi: device driver "Michael S. Tsirkin" <mst@redhat.com> - 2015-10-01 10:40 +0200
    Re: [dpdk-dev] [PATCH 0/2] uio_msi: device driver Avi Kivity <avi@scylladb.com> - 2015-10-01 13:00 +0200
      Re: [dpdk-dev] [PATCH 0/2] uio_msi: device driver Stephen Hemminger <stephen@networkplumber.org> - 2015-10-01 17:00 +0200
        Re: [dpdk-dev] [PATCH 0/2] uio_msi: device driver Alexander Duyck <alexander.duyck@gmail.com> - 2015-10-01 21:50 +0200
          Re: [dpdk-dev] [PATCH 0/2] uio_msi: device driver Stephen Hemminger <stephen@networkplumber.org> - 2015-10-02 00:10 +0200
            Re: [dpdk-dev] [PATCH 0/2] uio_msi: device driver Alexander Duyck <alexander.duyck@gmail.com> - 2015-10-02 01:10 +0200
              Re: [dpdk-dev] [PATCH 0/2] uio_msi: device driver Stephen Hemminger <stephen@networkplumber.org> - 2015-10-02 01:40 +0200
                Re: [dpdk-dev] [PATCH 0/2] uio_msi: device driver Alexander Duyck <alexander.duyck@gmail.com> - 2015-10-02 01:50 +0200
                  Re: [dpdk-dev] [PATCH 0/2] uio_msi: device driver Stephen Hemminger <stephen@networkplumber.org> - 2015-10-02 02:10 +0200
                    Re: [dpdk-dev] [PATCH 0/2] uio_msi: device driver Alexander Duyck <alexander.duyck@gmail.com> - 2015-10-02 03:40 +0200
                      Re: [dpdk-dev] [PATCH 0/2] uio_msi: device driver Vlad Zolotarov <vladz@cloudius-systems.com> - 2015-10-04 19:00 +0200
                        Re: [dpdk-dev] [PATCH 0/2] uio_msi: device driver Greg KH <gregkh@linux-foundation.org> - 2015-10-04 21:10 +0200
                          Re: [dpdk-dev] [PATCH 0/2] uio_msi: device driver Vlad Zolotarov <vladz@cloudius-systems.com> - 2015-10-04 22:50 +0200

Page 2 of 2 — ← Prev page 1 [2]

#1237688 — Re: [dpdk-dev] [PATCH 0/2] uio_msi: device driver

On 10/01/2015 07:57 AM, Stephen Hemminger wrote:
> On Thu, 1 Oct 2015 13:59:02 +0300
> Avi Kivity <avi@scylladb.com> wrote:
>
>> On 10/01/2015 01:28 AM, Stephen Hemminger wrote:
>>> This is a new UIO device driver to allow supporting MSI-X and MSI devices
>>> in userspace.  It has been used in environments like VMware and older versions
>>> of QEMU/KVM where no IOMMU support is available.
>> Why not add msi/msix support to uio_pci_generic?
> That is possible but that would meet ABI and other resistance from the author.
> Also, uio_pci_generic makes it harder to find resources since it doesn't fully
> utilize UIO infrastructure.

I'd say you are better off actually taking this in the other direction.  
From what I have seen it seems like this driver is meant to deal with 
mapping VFs contained inside of guests.  If you are going to fork off 
and create a UIO driver for mapping VFs why not just make it specialize 
in that.  You could probably simplify the code by dropping support for 
legacy interrupts and IO regions since all that is already covered by 
uio_pci_generic anyway if I am not mistaken.

You could then look at naming it something like uio_vf since the uio_msi 
is a bit of a misnomer since it is MSI-X it supports, not MSI interrupts.

- Alex
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1237774 — Re: [dpdk-dev] [PATCH 0/2] uio_msi: device driver

On Thu, 1 Oct 2015 12:48:36 -0700
Alexander Duyck <alexander.duyck@gmail.com> wrote:

> On 10/01/2015 07:57 AM, Stephen Hemminger wrote:
> > On Thu, 1 Oct 2015 13:59:02 +0300
> > Avi Kivity <avi@scylladb.com> wrote:
> >
> >> On 10/01/2015 01:28 AM, Stephen Hemminger wrote:
> >>> This is a new UIO device driver to allow supporting MSI-X and MSI devices
> >>> in userspace.  It has been used in environments like VMware and older versions
> >>> of QEMU/KVM where no IOMMU support is available.
> >> Why not add msi/msix support to uio_pci_generic?
> > That is possible but that would meet ABI and other resistance from the author.
> > Also, uio_pci_generic makes it harder to find resources since it doesn't fully
> > utilize UIO infrastructure.
> 
> I'd say you are better off actually taking this in the other direction.  
> From what I have seen it seems like this driver is meant to deal with 
> mapping VFs contained inside of guests.  If you are going to fork off 
> and create a UIO driver for mapping VFs why not just make it specialize 
> in that.  You could probably simplify the code by dropping support for 
> legacy interrupts and IO regions since all that is already covered by 
> uio_pci_generic anyway if I am not mistaken.
> 
> You could then look at naming it something like uio_vf since the uio_msi 
> is a bit of a misnomer since it is MSI-X it supports, not MSI interrupts.

The support needs to cover:
  - VF in guest
  - VNIC in guest (vmxnet3)
it isn't just about VF's
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1237823 — Re: [dpdk-dev] [PATCH 0/2] uio_msi: device driver

On 10/01/2015 03:00 PM, Stephen Hemminger wrote:
> On Thu, 1 Oct 2015 12:48:36 -0700
> Alexander Duyck <alexander.duyck@gmail.com> wrote:
>
>> On 10/01/2015 07:57 AM, Stephen Hemminger wrote:
>>> On Thu, 1 Oct 2015 13:59:02 +0300
>>> Avi Kivity <avi@scylladb.com> wrote:
>>>
>>>> On 10/01/2015 01:28 AM, Stephen Hemminger wrote:
>>>>> This is a new UIO device driver to allow supporting MSI-X and MSI devices
>>>>> in userspace.  It has been used in environments like VMware and older versions
>>>>> of QEMU/KVM where no IOMMU support is available.
>>>> Why not add msi/msix support to uio_pci_generic?
>>> That is possible but that would meet ABI and other resistance from the author.
>>> Also, uio_pci_generic makes it harder to find resources since it doesn't fully
>>> utilize UIO infrastructure.
>> I'd say you are better off actually taking this in the other direction.
>>  From what I have seen it seems like this driver is meant to deal with
>> mapping VFs contained inside of guests.  If you are going to fork off
>> and create a UIO driver for mapping VFs why not just make it specialize
>> in that.  You could probably simplify the code by dropping support for
>> legacy interrupts and IO regions since all that is already covered by
>> uio_pci_generic anyway if I am not mistaken.
>>
>> You could then look at naming it something like uio_vf since the uio_msi
>> is a bit of a misnomer since it is MSI-X it supports, not MSI interrupts.
> The support needs to cover:
>    - VF in guest
>    - VNIC in guest (vmxnet3)
> it isn't just about VF's

I get that, but the driver you are talking about adding is duplicating 
much of what is already there in uio_pci_generic.  If nothing else it 
might be worth while to look at replacing the legacy interrupt with 
MSI.  Maybe look at naming it something like uio_pcie to indicate that 
we are focusing on assigning PCIe and virtual devices that support MSI 
and MSI-X and use memory BARs rather than legacy PCI devices that are 
doing things like mapping I/O BARs and using INTx signaling.

My main argument is that we should probably look at dropping support for 
anything that isn't going to be needed.  If it is really important we 
can always add it later.  I just don't see the value in having code 
around for things we aren't likely to ever use with real devices as we 
are stuck supporting it for the life of the driver. I'll go ahead and 
provide a inline review of your patch 2/2 as I think my feedback might 
make a bit more sense that way.

- Alex



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1237831 — Re: [dpdk-dev] [PATCH 0/2] uio_msi: device driver

On Thu, 1 Oct 2015 16:03:06 -0700
Alexander Duyck <alexander.duyck@gmail.com> wrote:

> On 10/01/2015 03:00 PM, Stephen Hemminger wrote:
> > On Thu, 1 Oct 2015 12:48:36 -0700
> > Alexander Duyck <alexander.duyck@gmail.com> wrote:
> >
> >> On 10/01/2015 07:57 AM, Stephen Hemminger wrote:
> >>> On Thu, 1 Oct 2015 13:59:02 +0300
> >>> Avi Kivity <avi@scylladb.com> wrote:
> >>>
> >>>> On 10/01/2015 01:28 AM, Stephen Hemminger wrote:
> >>>>> This is a new UIO device driver to allow supporting MSI-X and MSI devices
> >>>>> in userspace.  It has been used in environments like VMware and older versions
> >>>>> of QEMU/KVM where no IOMMU support is available.
> >>>> Why not add msi/msix support to uio_pci_generic?
> >>> That is possible but that would meet ABI and other resistance from the author.
> >>> Also, uio_pci_generic makes it harder to find resources since it doesn't fully
> >>> utilize UIO infrastructure.
> >> I'd say you are better off actually taking this in the other direction.
> >>  From what I have seen it seems like this driver is meant to deal with
> >> mapping VFs contained inside of guests.  If you are going to fork off
> >> and create a UIO driver for mapping VFs why not just make it specialize
> >> in that.  You could probably simplify the code by dropping support for
> >> legacy interrupts and IO regions since all that is already covered by
> >> uio_pci_generic anyway if I am not mistaken.
> >>
> >> You could then look at naming it something like uio_vf since the uio_msi
> >> is a bit of a misnomer since it is MSI-X it supports, not MSI interrupts.
> > The support needs to cover:
> >    - VF in guest
> >    - VNIC in guest (vmxnet3)
> > it isn't just about VF's
> 
> I get that, but the driver you are talking about adding is duplicating 
> much of what is already there in uio_pci_generic.  If nothing else it 
> might be worth while to look at replacing the legacy interrupt with 
> MSI.  Maybe look at naming it something like uio_pcie to indicate that 
> we are focusing on assigning PCIe and virtual devices that support MSI 
> and MSI-X and use memory BARs rather than legacy PCI devices that are 
> doing things like mapping I/O BARs and using INTx signaling.
> 
> My main argument is that we should probably look at dropping support for 
> anything that isn't going to be needed.  If it is really important we 
> can always add it later.  I just don't see the value in having code 
> around for things we aren't likely to ever use with real devices as we 
> are stuck supporting it for the life of the driver. I'll go ahead and 
> provide a inline review of your patch 2/2 as I think my feedback might 
> make a bit more sense that way.

Ok, but having one driver that can deal with failures with msi-x vector
setup and fallback seemed like a better strategy.


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1237834 — Re: [dpdk-dev] [PATCH 0/2] uio_msi: device driver

On 10/01/2015 04:39 PM, Stephen Hemminger wrote:
> On Thu, 1 Oct 2015 16:03:06 -0700
> Alexander Duyck <alexander.duyck@gmail.com> wrote:
>
>> On 10/01/2015 03:00 PM, Stephen Hemminger wrote:
>>> On Thu, 1 Oct 2015 12:48:36 -0700
>>> Alexander Duyck <alexander.duyck@gmail.com> wrote:
>>>
>>>> On 10/01/2015 07:57 AM, Stephen Hemminger wrote:
>>>>> On Thu, 1 Oct 2015 13:59:02 +0300
>>>>> Avi Kivity <avi@scylladb.com> wrote:
>>>>>
>>>>>> On 10/01/2015 01:28 AM, Stephen Hemminger wrote:
>>>>>>> This is a new UIO device driver to allow supporting MSI-X and MSI devices
>>>>>>> in userspace.  It has been used in environments like VMware and older versions
>>>>>>> of QEMU/KVM where no IOMMU support is available.
>>>>>> Why not add msi/msix support to uio_pci_generic?
>>>>> That is possible but that would meet ABI and other resistance from the author.
>>>>> Also, uio_pci_generic makes it harder to find resources since it doesn't fully
>>>>> utilize UIO infrastructure.
>>>> I'd say you are better off actually taking this in the other direction.
>>>>   From what I have seen it seems like this driver is meant to deal with
>>>> mapping VFs contained inside of guests.  If you are going to fork off
>>>> and create a UIO driver for mapping VFs why not just make it specialize
>>>> in that.  You could probably simplify the code by dropping support for
>>>> legacy interrupts and IO regions since all that is already covered by
>>>> uio_pci_generic anyway if I am not mistaken.
>>>>
>>>> You could then look at naming it something like uio_vf since the uio_msi
>>>> is a bit of a misnomer since it is MSI-X it supports, not MSI interrupts.
>>> The support needs to cover:
>>>     - VF in guest
>>>     - VNIC in guest (vmxnet3)
>>> it isn't just about VF's
>> I get that, but the driver you are talking about adding is duplicating
>> much of what is already there in uio_pci_generic.  If nothing else it
>> might be worth while to look at replacing the legacy interrupt with
>> MSI.  Maybe look at naming it something like uio_pcie to indicate that
>> we are focusing on assigning PCIe and virtual devices that support MSI
>> and MSI-X and use memory BARs rather than legacy PCI devices that are
>> doing things like mapping I/O BARs and using INTx signaling.
>>
>> My main argument is that we should probably look at dropping support for
>> anything that isn't going to be needed.  If it is really important we
>> can always add it later.  I just don't see the value in having code
>> around for things we aren't likely to ever use with real devices as we
>> are stuck supporting it for the life of the driver. I'll go ahead and
>> provide a inline review of your patch 2/2 as I think my feedback might
>> make a bit more sense that way.
> Ok, but having one driver that can deal with failures with msi-x vector
> setup and fallback seemed like a better strategy.

Yes, but in the case of something like a VF it is going to just make a 
bigger mess of things since INTx doesn't work.  So what would you expect 
your driver to do in that case?  Also we have to keep in mind that the 
MSI-X failure case is very unlikely.

One other thing that just occurred to me is that you may want to try 
using the range allocation call instead of a hard set number of 
interrupts.  Then if you start running short on vectors you don't hard 
fail and instead just allocate what you can.

- Alex
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1237840 — Re: [dpdk-dev] [PATCH 0/2] uio_msi: device driver

On Thu, 1 Oct 2015 16:43:23 -0700
Alexander Duyck <alexander.duyck@gmail.com> wrote:

> Yes, but in the case of something like a VF it is going to just make a 
> bigger mess of things since INTx doesn't work.  So what would you expect 
> your driver to do in that case?  Also we have to keep in mind that the 
> MSI-X failure case is very unlikely.
> 
> One other thing that just occurred to me is that you may want to try 
> using the range allocation call instead of a hard set number of 
> interrupts.  Then if you start running short on vectors you don't hard 
> fail and instead just allocate what you can.

I tried that but the bookkeeping gets messy since there is no good
way to communicate that back to userspace and have it adapt.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1237876 — Re: [dpdk-dev] [PATCH 0/2] uio_msi: device driver

On 10/01/2015 05:04 PM, Stephen Hemminger wrote:
> On Thu, 1 Oct 2015 16:43:23 -0700
> Alexander Duyck <alexander.duyck@gmail.com> wrote:
>
>> Yes, but in the case of something like a VF it is going to just make a
>> bigger mess of things since INTx doesn't work.  So what would you expect
>> your driver to do in that case?  Also we have to keep in mind that the
>> MSI-X failure case is very unlikely.
>>
>> One other thing that just occurred to me is that you may want to try
>> using the range allocation call instead of a hard set number of
>> interrupts.  Then if you start running short on vectors you don't hard
>> fail and instead just allocate what you can.
> I tried that but the bookkeeping gets messy since there is no good
> way to communicate that back to userspace and have it adapt.

Actually I kind of just realized that uio_msi_open is kind of messed 
up.  So if the MSI-X allocation fails due to no resources it will return 
a positive value indicating the number of vectors that could be 
allocated, a negative value if one of the input values is invalid, or 
0.  I'm not sure if returning a positive value on failure is an issue or 
not.  I know the open call is supposed to return a negative value or the 
file descriptor if not negative.  I don't know if the return value might 
be interpreted as a file descriptor or not.

Also if MSI-X is supported by the hardware, but disabled for some reason 
by the kernel ("pci=nomsi")  then this driver is rendered inoperable 
since it will never give you anything but -EINVAL from the open call.

I really think you should probably look at taking care of enabling MSI-X 
and maybe MSI as a fall-back in probe.  At least then you can post a 
message about how many vectors are enabled and what type. Then if you 
cannot enable any interrupts due to MSI being disabled you can simply 
fail at probe time and let then load a different driver.

- Alex
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1239158 — Re: [dpdk-dev] [PATCH 0/2] uio_msi: device driver

FYI: I've just posted to linux-kernel list patches that add support for 
both MSI and MSI-X interrupt modes to uio_pci_generic driver.
It addresses most (all) remarks on this thread and also fixes some 
issues this code has, e.g. not disabling msi-x in remove(), etc.

U are all welcome to comment... ;)

thanks,
vlad

On 10/02/15 04:39, Alexander Duyck wrote:
> On 10/01/2015 05:04 PM, Stephen Hemminger wrote:
>> On Thu, 1 Oct 2015 16:43:23 -0700
>> Alexander Duyck <alexander.duyck@gmail.com> wrote:
>>
>>> Yes, but in the case of something like a VF it is going to just make a
>>> bigger mess of things since INTx doesn't work.  So what would you 
>>> expect
>>> your driver to do in that case?  Also we have to keep in mind that the
>>> MSI-X failure case is very unlikely.
>>>
>>> One other thing that just occurred to me is that you may want to try
>>> using the range allocation call instead of a hard set number of
>>> interrupts.  Then if you start running short on vectors you don't hard
>>> fail and instead just allocate what you can.
>> I tried that but the bookkeeping gets messy since there is no good
>> way to communicate that back to userspace and have it adapt.
>
> Actually I kind of just realized that uio_msi_open is kind of messed 
> up.  So if the MSI-X allocation fails due to no resources it will 
> return a positive value indicating the number of vectors that could be 
> allocated, a negative value if one of the input values is invalid, or 
> 0.  I'm not sure if returning a positive value on failure is an issue 
> or not.  I know the open call is supposed to return a negative value 
> or the file descriptor if not negative.  I don't know if the return 
> value might be interpreted as a file descriptor or not.
>
> Also if MSI-X is supported by the hardware, but disabled for some 
> reason by the kernel ("pci=nomsi")  then this driver is rendered 
> inoperable since it will never give you anything but -EINVAL from the 
> open call.
>
> I really think you should probably look at taking care of enabling 
> MSI-X and maybe MSI as a fall-back in probe.  At least then you can 
> post a message about how many vectors are enabled and what type. Then 
> if you cannot enable any interrupts due to MSI being disabled you can 
> simply fail at probe time and let then load a different driver.
>
> - Alex

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1239185 — Re: [dpdk-dev] [PATCH 0/2] uio_msi: device driver

On Sun, Oct 04, 2015 at 07:49:35PM +0300, Vlad Zolotarov wrote:
> FYI: I've just posted to linux-kernel list patches that add support for both
> MSI and MSI-X interrupt modes to uio_pci_generic driver.
> It addresses most (all) remarks on this thread and also fixes some issues
> this code has, e.g. not disabling msi-x in remove(), etc.
> 
> U are all welcome to comment... ;)

Not if you don't at least cc: all of the uio maintainers :(

I'm just going to ignore the things, as obviously you don't want them
merged, quite strange...

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1239212 — Re: [dpdk-dev] [PATCH 0/2] uio_msi: device driver

On 10/04/15 22:03, Greg KH wrote:
> On Sun, Oct 04, 2015 at 07:49:35PM +0300, Vlad Zolotarov wrote:
>> FYI: I've just posted to linux-kernel list patches that add support for both
>> MSI and MSI-X interrupt modes to uio_pci_generic driver.
>> It addresses most (all) remarks on this thread and also fixes some issues
>> this code has, e.g. not disabling msi-x in remove(), etc.
>>
>> U are all welcome to comment... ;)
> Not if you don't at least cc: all of the uio maintainers :(
>
> I'm just going to ignore the things, as obviously you don't want them
> merged, quite strange...

I actually do mean them to be merged and I do (tried to) cc all the 
maintainers. Unfortunately I missed the first letter when I copied your 
email from the get_maintainers.pl output. I resent v3 with the correct 
email of yours. Hope u don't have (too) hard feelings about the first 
iterations of the series. Pls., believe me there was nothing personal, 
just a typo... ;)

>
> greg k-h

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | linux.kernel

csiph-web