From: Xu Yilun <yilun.xu@intel.com>
To: Greg KH <gregkh@linuxfoundation.org>
Cc: Tom Rix <trix@redhat.com>,
mdf@kernel.org, linux-fpga@vger.kernel.org,
linux-kernel@vger.kernel.org, lgoncalv@redhat.com,
hao.wu@intel.com, yilun.xu@intel.com
Subject: Re: [PATCH 1/2] fpga: dfl: add driver_override support
Date: Tue, 20 Oct 2020 16:57:23 +0800 [thread overview]
Message-ID: <20201020085723.GE16172@yilunxu-OptiPlex-7050> (raw)
In-Reply-To: <20201020073259.GA3803984@kroah.com>
On Tue, Oct 20, 2020 at 09:32:59AM +0200, Greg KH wrote:
> On Tue, Oct 20, 2020 at 03:11:58PM +0800, Xu Yilun wrote:
> > I think it is normal case that a driver is successfully registered but
> > doesn't match any device because it provides no id_table.
>
> How is that "normal"? What would ever cause that driver to be bound to
> a device then?
This patchset adds the driver_override sysfs node, to let userspace
specify which driver (by name matching) to be bound to a device. The
driver "dfl-uio-pdev" doesn't provide an id_table, it could only be
bound to a device whose driver_override is set to "dfl-uio-pdev".
Sorry, this is actually not "normal". Usually dfl drivers with valid id_table
should be used to drive the dfl devices. But we also want to give an option
for userspace to take full control of the device, some IP blocks in FPGA are
written for specific purposes by FPGA user so a userspace driver may
serve them better.
>
> And you better not say userspace is responsible for it...
Actually it is the userspace's decision which device they want to
access directly ...
I'm not sure if this idea is OK. I see similar implementation for
pci/platform devices.
Thanks,
Yilun
>
> thanks,
>
> greg k-h
next prev parent reply other threads:[~2020-10-20 9:02 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-10-16 6:02 [PATCH 0/2] UIO support for dfl devices Xu Yilun
2020-10-16 6:02 ` [PATCH 1/2] fpga: dfl: add driver_override support Xu Yilun
2020-10-16 16:21 ` Tom Rix
2020-10-19 4:06 ` Xu Yilun
2020-10-19 7:46 ` Wu, Hao
2020-10-19 7:50 ` Xu Yilun
2020-10-19 8:53 ` gregkh
2020-10-19 8:52 ` Xu Yilun
2020-10-19 9:03 ` Greg KH
2020-10-20 0:42 ` Xu Yilun
2020-10-19 13:55 ` Tom Rix
2020-10-20 7:11 ` Xu Yilun
2020-10-20 7:32 ` Greg KH
2020-10-20 8:57 ` Xu Yilun [this message]
2020-10-20 9:21 ` Greg KH
2020-10-21 7:25 ` Xu Yilun
2020-11-09 2:30 ` Xu Yilun
2020-10-20 14:13 ` Tom Rix
2020-10-16 6:02 ` [PATCH 2/2] fpga: dfl: add the userspace I/O device support for DFL devices Xu Yilun
2020-10-16 16:36 ` Tom Rix
2020-10-19 4:16 ` Xu Yilun
2020-10-19 14:01 ` Tom Rix
2020-10-16 16:40 ` [PATCH 0/2] UIO support for dfl devices Tom Rix
2020-10-19 4:17 ` Xu Yilun
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20201020085723.GE16172@yilunxu-OptiPlex-7050 \
--to=yilun.xu@intel.com \
--cc=gregkh@linuxfoundation.org \
--cc=hao.wu@intel.com \
--cc=lgoncalv@redhat.com \
--cc=linux-fpga@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mdf@kernel.org \
--cc=trix@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).