mbox series

[v11,0/2] UIO support for dfl devices

Message ID 1612403971-13291-1-git-send-email-yilun.xu@intel.com (mailing list archive)
Headers show
Series UIO support for dfl devices | expand

Message

Xu Yilun Feb. 4, 2021, 1:59 a.m. UTC
This patchset supports some dfl device drivers written in userspace.

In the patchset v1, the "driver_override" interface should be used to bind
the DFL UIO driver to DFL devices. But there is concern that the 
"driver_override" interface is not OK itself.

In v2, we use a new matching algorithem. The "driver_override" interface
is abandoned, the DFL UIO driver matches any DFL device which could not be
handled by other DFL drivers. So the DFL UIO driver could be used for new 
DFL devices which are not supported by kernel. The concern is the UIO may 
not be suitable as a default/generic driver for all dfl features, such as
features with multiple interrupts.

In v4, we specify each matching device in the id_table of the UIO driver,
just the same as other dfl drivers do. Now the UIO driver supports Ether
Group feature. To support more DFL features, their feature ids should be
added to the driver's id_table.

Before v9, we create a "uio_pdrv_genirq" platform device using DFL devices'
resources. Then we leverage the uio_pdrv_genirq driver for UIO support. It
is suggested that we implement a driver in drivers/uio that directly calls
UIO framework APIs. So we implement the uio_dfl driver in v9. The driver
now only binds the ether group feature, which has no irq. So the irq 
support is not implemented yet.


Main changes from v1:
- switch to the new matching algorithem. It matches DFL devices which could
  not be handled by other DFL drivers.
- refacor the code about device resources filling.
- add the documentation.

Main changes from v2:
- split the match ops changes in dfl.c to an independent patch.
- move the declarations needed for dfl-uio-pdev from include/linux/dfl.h
  to driver/fpga/dfl.h
- some minor fixes.

Main changes from v3:
- switch to specifying each matching device in the driver's id_table.
- refactor the irq handling code.

Main changes from v4:
- refactor the irq handling code.

Main changes from v5:
- fix the res[] zero initialization issue.
- improve the return code for probe().
- some doc improvement.

Main changes from v6:
- use platform_device_register_resndata() for pdev creation.

Main changes from v7:
- some doc fixes.

Main changes from v8:
- switch to add a uio driver in drivers/uio

Main changes from v9:
- add this source file in MAINTAINERS
- improve the Kconfig, add more descriptive Kconfig header, add detailed
  path for opae uio example in Kconfig.

Main changes from v10:
- add description in doc that interrupt support is not implemented yet.


Xu Yilun (2):
  uio: uio_dfl: add userspace i/o driver for DFL bus
  Documentation: fpga: dfl: Add description for DFL UIO support

 Documentation/fpga/dfl.rst | 26 ++++++++++++++++++
 MAINTAINERS                |  1 +
 drivers/uio/Kconfig        | 17 ++++++++++++
 drivers/uio/Makefile       |  1 +
 drivers/uio/uio_dfl.c      | 66 ++++++++++++++++++++++++++++++++++++++++++++++
 5 files changed, 111 insertions(+)
 create mode 100644 drivers/uio/uio_dfl.c

Comments

Tom Rix Feb. 22, 2021, 6:56 p.m. UTC | #1
Yilun,

Is there anything outstanding or remaining to be done ?

Tom

On 2/3/21 5:59 PM, Xu Yilun wrote:
> This patchset supports some dfl device drivers written in userspace.
>
> In the patchset v1, the "driver_override" interface should be used to bind
> the DFL UIO driver to DFL devices. But there is concern that the 
> "driver_override" interface is not OK itself.
>
> In v2, we use a new matching algorithem. The "driver_override" interface
> is abandoned, the DFL UIO driver matches any DFL device which could not be
> handled by other DFL drivers. So the DFL UIO driver could be used for new 
> DFL devices which are not supported by kernel. The concern is the UIO may 
> not be suitable as a default/generic driver for all dfl features, such as
> features with multiple interrupts.
>
> In v4, we specify each matching device in the id_table of the UIO driver,
> just the same as other dfl drivers do. Now the UIO driver supports Ether
> Group feature. To support more DFL features, their feature ids should be
> added to the driver's id_table.
>
> Before v9, we create a "uio_pdrv_genirq" platform device using DFL devices'
> resources. Then we leverage the uio_pdrv_genirq driver for UIO support. It
> is suggested that we implement a driver in drivers/uio that directly calls
> UIO framework APIs. So we implement the uio_dfl driver in v9. The driver
> now only binds the ether group feature, which has no irq. So the irq 
> support is not implemented yet.
>
>
> Main changes from v1:
> - switch to the new matching algorithem. It matches DFL devices which could
>   not be handled by other DFL drivers.
> - refacor the code about device resources filling.
> - add the documentation.
>
> Main changes from v2:
> - split the match ops changes in dfl.c to an independent patch.
> - move the declarations needed for dfl-uio-pdev from include/linux/dfl.h
>   to driver/fpga/dfl.h
> - some minor fixes.
>
> Main changes from v3:
> - switch to specifying each matching device in the driver's id_table.
> - refactor the irq handling code.
>
> Main changes from v4:
> - refactor the irq handling code.
>
> Main changes from v5:
> - fix the res[] zero initialization issue.
> - improve the return code for probe().
> - some doc improvement.
>
> Main changes from v6:
> - use platform_device_register_resndata() for pdev creation.
>
> Main changes from v7:
> - some doc fixes.
>
> Main changes from v8:
> - switch to add a uio driver in drivers/uio
>
> Main changes from v9:
> - add this source file in MAINTAINERS
> - improve the Kconfig, add more descriptive Kconfig header, add detailed
>   path for opae uio example in Kconfig.
>
> Main changes from v10:
> - add description in doc that interrupt support is not implemented yet.
>
>
> Xu Yilun (2):
>   uio: uio_dfl: add userspace i/o driver for DFL bus
>   Documentation: fpga: dfl: Add description for DFL UIO support
>
>  Documentation/fpga/dfl.rst | 26 ++++++++++++++++++
>  MAINTAINERS                |  1 +
>  drivers/uio/Kconfig        | 17 ++++++++++++
>  drivers/uio/Makefile       |  1 +
>  drivers/uio/uio_dfl.c      | 66 ++++++++++++++++++++++++++++++++++++++++++++++
>  5 files changed, 111 insertions(+)
>  create mode 100644 drivers/uio/uio_dfl.c
>
Xu Yilun Feb. 26, 2021, 1:22 a.m. UTC | #2
On Mon, Feb 22, 2021 at 10:56:45AM -0800, Tom Rix wrote:
> Yilun,
> 
> Is there anything outstanding or remaining to be done ?

Sorry for late reply. No, this is my lastest version now.


Hi Greg:

Do you have some comments on this patchset?

Thanks,
Yilun

> 
> Tom
> 
> On 2/3/21 5:59 PM, Xu Yilun wrote:
> > This patchset supports some dfl device drivers written in userspace.
> >
> > In the patchset v1, the "driver_override" interface should be used to bind
> > the DFL UIO driver to DFL devices. But there is concern that the 
> > "driver_override" interface is not OK itself.
> >
> > In v2, we use a new matching algorithem. The "driver_override" interface
> > is abandoned, the DFL UIO driver matches any DFL device which could not be
> > handled by other DFL drivers. So the DFL UIO driver could be used for new 
> > DFL devices which are not supported by kernel. The concern is the UIO may 
> > not be suitable as a default/generic driver for all dfl features, such as
> > features with multiple interrupts.
> >
> > In v4, we specify each matching device in the id_table of the UIO driver,
> > just the same as other dfl drivers do. Now the UIO driver supports Ether
> > Group feature. To support more DFL features, their feature ids should be
> > added to the driver's id_table.
> >
> > Before v9, we create a "uio_pdrv_genirq" platform device using DFL devices'
> > resources. Then we leverage the uio_pdrv_genirq driver for UIO support. It
> > is suggested that we implement a driver in drivers/uio that directly calls
> > UIO framework APIs. So we implement the uio_dfl driver in v9. The driver
> > now only binds the ether group feature, which has no irq. So the irq 
> > support is not implemented yet.
> >
> >
> > Main changes from v1:
> > - switch to the new matching algorithem. It matches DFL devices which could
> >   not be handled by other DFL drivers.
> > - refacor the code about device resources filling.
> > - add the documentation.
> >
> > Main changes from v2:
> > - split the match ops changes in dfl.c to an independent patch.
> > - move the declarations needed for dfl-uio-pdev from include/linux/dfl.h
> >   to driver/fpga/dfl.h
> > - some minor fixes.
> >
> > Main changes from v3:
> > - switch to specifying each matching device in the driver's id_table.
> > - refactor the irq handling code.
> >
> > Main changes from v4:
> > - refactor the irq handling code.
> >
> > Main changes from v5:
> > - fix the res[] zero initialization issue.
> > - improve the return code for probe().
> > - some doc improvement.
> >
> > Main changes from v6:
> > - use platform_device_register_resndata() for pdev creation.
> >
> > Main changes from v7:
> > - some doc fixes.
> >
> > Main changes from v8:
> > - switch to add a uio driver in drivers/uio
> >
> > Main changes from v9:
> > - add this source file in MAINTAINERS
> > - improve the Kconfig, add more descriptive Kconfig header, add detailed
> >   path for opae uio example in Kconfig.
> >
> > Main changes from v10:
> > - add description in doc that interrupt support is not implemented yet.
> >
> >
> > Xu Yilun (2):
> >   uio: uio_dfl: add userspace i/o driver for DFL bus
> >   Documentation: fpga: dfl: Add description for DFL UIO support
> >
> >  Documentation/fpga/dfl.rst | 26 ++++++++++++++++++
> >  MAINTAINERS                |  1 +
> >  drivers/uio/Kconfig        | 17 ++++++++++++
> >  drivers/uio/Makefile       |  1 +
> >  drivers/uio/uio_dfl.c      | 66 ++++++++++++++++++++++++++++++++++++++++++++++
> >  5 files changed, 111 insertions(+)
> >  create mode 100644 drivers/uio/uio_dfl.c
> >
Greg Kroah-Hartman Feb. 26, 2021, 6:40 a.m. UTC | #3
On Fri, Feb 26, 2021 at 09:22:37AM +0800, Xu Yilun wrote:
> On Mon, Feb 22, 2021 at 10:56:45AM -0800, Tom Rix wrote:
> > Yilun,
> > 
> > Is there anything outstanding or remaining to be done ?
> 
> Sorry for late reply. No, this is my lastest version now.
> 
> 
> Hi Greg:
> 
> Do you have some comments on this patchset?

It's the middle of the merge window, I can't accept anything right
now...

But this doesn't even look like it is in my "to review" queue anymore,
which means that there must have been a lot of discussion on it and
others asking for changes, so why not work on that right now while you
can and resubmit it when you have done that?

No need to ever wait on me for fixing things up.

greg k-h
Xu Yilun Feb. 27, 2021, 2:57 p.m. UTC | #4
Hi Greg:

On Fri, Feb 26, 2021 at 07:40:56AM +0100, Greg KH wrote:
> On Fri, Feb 26, 2021 at 09:22:37AM +0800, Xu Yilun wrote:
> > On Mon, Feb 22, 2021 at 10:56:45AM -0800, Tom Rix wrote:
> > > Yilun,
> > > 
> > > Is there anything outstanding or remaining to be done ?
> > 
> > Sorry for late reply. No, this is my lastest version now.
> > 
> > 
> > Hi Greg:
> > 
> > Do you have some comments on this patchset?
> 
> It's the middle of the merge window, I can't accept anything right
> now...
> 
> But this doesn't even look like it is in my "to review" queue anymore,
> which means that there must have been a lot of discussion on it and
> others asking for changes, so why not work on that right now while you
> can and resubmit it when you have done that?
> 
> No need to ever wait on me for fixing things up.

I checked the mails again and confirmed all the comments from Moritz,
Tom and Hao are fixed. So could you help review it so it could be
accepted in next cycle?

Thanks,
Yilun

> 
> greg k-h
Greg Kroah-Hartman Feb. 27, 2021, 3:07 p.m. UTC | #5
On Sat, Feb 27, 2021 at 10:57:33PM +0800, Xu Yilun wrote:
> Hi Greg:
> 
> On Fri, Feb 26, 2021 at 07:40:56AM +0100, Greg KH wrote:
> > On Fri, Feb 26, 2021 at 09:22:37AM +0800, Xu Yilun wrote:
> > > On Mon, Feb 22, 2021 at 10:56:45AM -0800, Tom Rix wrote:
> > > > Yilun,
> > > > 
> > > > Is there anything outstanding or remaining to be done ?
> > > 
> > > Sorry for late reply. No, this is my lastest version now.
> > > 
> > > 
> > > Hi Greg:
> > > 
> > > Do you have some comments on this patchset?
> > 
> > It's the middle of the merge window, I can't accept anything right
> > now...
> > 
> > But this doesn't even look like it is in my "to review" queue anymore,
> > which means that there must have been a lot of discussion on it and
> > others asking for changes, so why not work on that right now while you
> > can and resubmit it when you have done that?
> > 
> > No need to ever wait on me for fixing things up.
> 
> I checked the mails again and confirmed all the comments from Moritz,
> Tom and Hao are fixed. So could you help review it so it could be
> accepted in next cycle?

Please resend it, as I said above, it is no longer in my queue.

greg k-h