Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
IronPort-SDR: naTDMBqrJlkJRt1lhQQ3GVFJebEm8IYfm9W0y6pP6g2LtUzeb+VVeSVcEy5lDi6pmCQel27igG
 kuyk21FpUcbQ==
IronPort-SDR: ay6wyb/IrQE+kw/UrUR7SYpQK/CiKKNmI26I3oqf5dB6TYTV7gvARvn3p73AHH+fZENwpTKNTT
 jN4ZFbmDfJcQ==
Date:   Tue, 20 Oct 2020 16:57:23 +0800
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
Message-ID: <20201020085723.GE16172@yilunxu-OptiPlex-7050>
References: <1602828151-24784-1-git-send-email-yilun.xu@intel.com>
 <1602828151-24784-2-git-send-email-yilun.xu@intel.com>
 <63d7730b-d9b8-c75d-16f6-3ebb507aabaa@redhat.com>
 <20201019040612.GA16172@yilunxu-OptiPlex-7050>
 <f767b9a0-1db8-7ced-6bd9-5ee1f58d40da@redhat.com>
 <20201020071158.GC28746@yilunxu-OptiPlex-7050>
 <20201020073259.GA3803984@kroah.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20201020073259.GA3803984@kroah.com>
User-Agent: Mutt/1.5.24 (2015-08-30)
Precedence: bulk

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