lkml.org 
[lkml]   [2021]   [Jan]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH v5 0/2] UIO support for dfl devices
On Sun, Jan 10, 2021 at 11:58:44AM -0800, Moritz Fischer wrote:
> Hi Xu,
>
> On Sat, Jan 02, 2021 at 11:13:00AM +0800, 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.
>
> I think this is what you want, yes. Instead of doing a driver override
> or such, add devices that should always be bound to UIO to a device id
> table. For those you temporarily want to bind, make sure you can unbind
> them and use 'new_id' or 'bind' in sysfs, similar to what sysfs does.

"new_id" is not generic to all bus drivers, we need to add the attr in
dfl bus driver like pci do, actually I think quite similar to
"driver_override", How do you think?

I'm glad we restarted the discussion for the temporary binding of UIO
driver.

Thanks,
Yilun

\
 
 \ /
  Last update: 2021-01-11 07:34    [W:0.133 / U:31.248 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site