Re: [RFC] fpga: dfl: a prototype uio driver
On 12/9/20 12:56 AM, Xu Yilun wrote:
> Hi Tom:
>
> On Mon, Dec 07, 2020 at 05:07:05AM -0800, Tom Rix wrote:
>> On 12/7/20 12:02 AM, Greg KH wrote:
>>> On Sun, Dec 06, 2020 at 01:55:54PM -0800, t...@redhat.com wrote:
From: Tom Rix
>From [PATCH 0/2] UIO support for dfl devices
https://lore.kernel.org/linux-fpga/1602828151-24784-1-git-send-email-yilun...@intel.com/
>>> Why is this here?
>> As reference, Yilun's work has precedence for a uio driver and this rfc is
>> trying to address what i believe is a sticking point of the driver
>> override. This rfc is some code i hacked out to show the idea and move
>> uio support along. I would like to see uio support for at least the
>> unclaimed feature id's because this would make it easier for them to be
>> developed.
> I see there is concern about sharing DFL devices for both UIO and kernel
> drivers. Even if a lock could be created to serialize the accesses of
> both interfaces, they could potentially impact each other without notice
> on hardware level.
>
> Maybe it is better we split the uio driver for unclaimed features. But
> how we could know it is an unclaimed feature, may be for simplicity we
> list the feature ids in device id table for dfl uio driver? We should
> change the code of dfl uio when we want to use uio for a new dfl device,
> is that acceptable?
No entry in the device id table would mean there would never be a conflict, so
this is good.
This set could be expanded if the platform device driver was checked, and then
uio could also used whose platform drivers were disabled in the configury.
There would be this problem: on the module case, disabling uio per feature so
the platform driver kmod could be used.
I think we could do your the device id table suggestion now since it is simple
and will help almost all developers.
Tom
>
> Thanks,
> Yilun
>
Here is an idea to have uio support with no driver override.
This makes UIO the primary driver interface because every feature
will have one and makes the existing platform driver interface
secondary. There will be a new burden for locking write access when
they compete.
Example shows finding the fpga's temperture.
Signed-off-by: Tom Rix
---
drivers/fpga/dfl-fme-main.c | 9 +++-
drivers/fpga/dfl-uio.c | 96 +
drivers/fpga/dfl.c | 44 -
drivers/fpga/dfl.h | 9
uio.c | 56 ++
5 files changed, 212 insertions(+), 2 deletions(-)
create mode 100644 drivers/fpga/dfl-uio.c
create mode 100644 uio.c
diff --git a/drivers/fpga/dfl-fme-main.c b/drivers/fpga/dfl-fme-main.c
index 037dc4f946f0..3323e90a18c4 100644
--- a/drivers/fpga/dfl-fme-main.c
+++ b/drivers/fpga/dfl-fme-main.c
@@ -709,12 +709,18 @@ static int fme_probe(struct platform_device *pdev)
if (ret)
goto dev_destroy;
- ret = dfl_fpga_dev_ops_register(pdev, _fops, THIS_MODULE);
+ ret = dfl_fpga_dev_feature_init_uio(pdev, DFH_TYPE_FIU);
if (ret)
goto feature_uinit;
+ ret = dfl_fpga_dev_ops_register(pdev, _fops, THIS_MODULE);
+ if (ret)
+ goto feature_uinit_uio;
+
return 0;
+feature_uinit_uio:
+ dfl_fpga_dev_feature_uinit_uio(pdev, DFH_TYPE_FIU);
feature_uinit:
dfl_fpga_dev_feature_uinit(pdev);
dev_destroy:
@@ -726,6 +732,7 @@ exit:
static int fme_remove(struct platform_device *pdev)
{
dfl_fpga_dev_ops_unregister(pdev);
+ dfl_fpga_dev_feature_uinit_uio(pdev, DFH_TYPE_FIU);
dfl_fpga_dev_feature_uinit(pdev);
fme_dev_destroy(pdev);
diff --git a/drivers/fpga/dfl-uio.c b/drivers/fpga/dfl-uio.c
new file mode 100644
index ..7610ee0b19dc
--- /dev/null
+++ b/drivers/fpga/dfl-uio.c
@@ -0,0 +1,96 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * prototype dfl uio driver
+ *
+ * Copyright Tom Rix 2020
+ */
+#include
+#include "dfl.h"
+
+static irqreturn_t dfl_uio_handler(int irq, struct uio_info *info)
+{
+ return IRQ_HANDLED;
+}
+
+static int dfl_uio_mmap(struct uio_info *info, struct vm_area_struct *vma)
+{
+ int ret = -ENODEV;
+ return ret;
>>> Did you run this through checkpatch?
>>>
>>> Does the code make sense?
>>>
+}
+
+static int dfl_uio_open(struct uio_info *info, struct inode *inode)
+{
+ int ret = -ENODEV;
+ struct dfl_feature *feature = container_of(info, struct dfl_feature,
uio);
+ if (feature->dev)
+ mutex_lock(>lock);
+
+ ret = 0;
+ return ret;
>>> Same here, does this make sense?
>>>
>>> And wait, you are having userspace grab a kernel lock? What could
Re: [RFC] fpga: dfl: a prototype uio driver
Hi Tom:
On Mon, Dec 07, 2020 at 05:07:05AM -0800, Tom Rix wrote:
>
> On 12/7/20 12:02 AM, Greg KH wrote:
> > On Sun, Dec 06, 2020 at 01:55:54PM -0800, t...@redhat.com wrote:
> >> From: Tom Rix
> >>
> >> >From [PATCH 0/2] UIO support for dfl devices
> >> https://lore.kernel.org/linux-fpga/1602828151-24784-1-git-send-email-yilun...@intel.com/
> > Why is this here?
>
> As reference, Yilun's work has precedence for a uio driver and this rfc is
> trying to address what i believe is a sticking point of the driver override.
> This rfc is some code i hacked out to show the idea and move uio support
> along. I would like to see uio support for at least the unclaimed feature
> id's because this would make it easier for them to be developed.
I see there is concern about sharing DFL devices for both UIO and kernel
drivers. Even if a lock could be created to serialize the accesses of
both interfaces, they could potentially impact each other without notice
on hardware level.
Maybe it is better we split the uio driver for unclaimed features. But
how we could know it is an unclaimed feature, may be for simplicity we
list the feature ids in device id table for dfl uio driver? We should
change the code of dfl uio when we want to use uio for a new dfl device,
is that acceptable?
Thanks,
Yilun
>
> >> Here is an idea to have uio support with no driver override.
> >>
> >> This makes UIO the primary driver interface because every feature
> >> will have one and makes the existing platform driver interface
> >> secondary. There will be a new burden for locking write access when
> >> they compete.
> >>
> >> Example shows finding the fpga's temperture.
> >>
> >> Signed-off-by: Tom Rix
> >> ---
> >> drivers/fpga/dfl-fme-main.c | 9 +++-
> >> drivers/fpga/dfl-uio.c | 96 +
> >> drivers/fpga/dfl.c | 44 -
> >> drivers/fpga/dfl.h | 9
> >> uio.c | 56 ++
> >> 5 files changed, 212 insertions(+), 2 deletions(-)
> >> create mode 100644 drivers/fpga/dfl-uio.c
> >> create mode 100644 uio.c
> >>
> >> diff --git a/drivers/fpga/dfl-fme-main.c b/drivers/fpga/dfl-fme-main.c
> >> index 037dc4f946f0..3323e90a18c4 100644
> >> --- a/drivers/fpga/dfl-fme-main.c
> >> +++ b/drivers/fpga/dfl-fme-main.c
> >> @@ -709,12 +709,18 @@ static int fme_probe(struct platform_device *pdev)
> >>if (ret)
> >>goto dev_destroy;
> >>
> >> - ret = dfl_fpga_dev_ops_register(pdev, _fops, THIS_MODULE);
> >> + ret = dfl_fpga_dev_feature_init_uio(pdev, DFH_TYPE_FIU);
> >>if (ret)
> >>goto feature_uinit;
> >>
> >> + ret = dfl_fpga_dev_ops_register(pdev, _fops, THIS_MODULE);
> >> + if (ret)
> >> + goto feature_uinit_uio;
> >> +
> >>return 0;
> >>
> >> +feature_uinit_uio:
> >> + dfl_fpga_dev_feature_uinit_uio(pdev, DFH_TYPE_FIU);
> >> feature_uinit:
> >>dfl_fpga_dev_feature_uinit(pdev);
> >> dev_destroy:
> >> @@ -726,6 +732,7 @@ exit:
> >> static int fme_remove(struct platform_device *pdev)
> >> {
> >>dfl_fpga_dev_ops_unregister(pdev);
> >> + dfl_fpga_dev_feature_uinit_uio(pdev, DFH_TYPE_FIU);
> >>dfl_fpga_dev_feature_uinit(pdev);
> >>fme_dev_destroy(pdev);
> >>
> >> diff --git a/drivers/fpga/dfl-uio.c b/drivers/fpga/dfl-uio.c
> >> new file mode 100644
> >> index ..7610ee0b19dc
> >> --- /dev/null
> >> +++ b/drivers/fpga/dfl-uio.c
> >> @@ -0,0 +1,96 @@
> >> +/* SPDX-License-Identifier: GPL-2.0 */
> >> +/*
> >> + * prototype dfl uio driver
> >> + *
> >> + * Copyright Tom Rix 2020
> >> + */
> >> +#include
> >> +#include "dfl.h"
> >> +
> >> +static irqreturn_t dfl_uio_handler(int irq, struct uio_info *info)
> >> +{
> >> + return IRQ_HANDLED;
> >> +}
> >> +
> >> +static int dfl_uio_mmap(struct uio_info *info, struct vm_area_struct *vma)
> >> +{
> >> + int ret = -ENODEV;
> >> + return ret;
> > Did you run this through checkpatch?
> >
> > Does the code make sense?
> >
> >> +}
> >> +
> >> +static int dfl_uio_open(struct uio_info *info, struct inode *inode)
> >> +{
> >> + int ret = -ENODEV;
> >> + struct dfl_feature *feature = container_of(info, struct dfl_feature,
> >> uio);
> >> + if (feature->dev)
> >> + mutex_lock(>lock);
> >> +
> >> + ret = 0;
> >> + return ret;
> > Same here, does this make sense?
> >
> > And wait, you are having userspace grab a kernel lock? What could go
> > wrong? :(
> >
> Yes, this is the bad part of this idea.
>
> Tom
>
>
> >> +}
> >> +
> >> +static int dfl_uio_release(struct uio_info *info, struct inode *inode)
> >> +{
> >> + int ret = -ENODEV;
> >> + struct dfl_feature *feature = container_of(info, struct dfl_feature,
> >> uio);
> >> + if (feature->dev)
> >> + mutex_unlock(>lock);
> >> +
> >> + ret = 0;
> >> + return ret;
> >> +}
> >> +
> >> +static int dfl_uio_irqcontrol(struct uio_info *info, s32 irq_on)
> >> +{
> >> + int ret = -ENODEV;
> >> + return ret;
> >> +}
> >> +
> >> +int
Re: [RFC] fpga: dfl: a prototype uio driver
On 12/7/20 12:02 AM, Greg KH wrote:
> On Sun, Dec 06, 2020 at 01:55:54PM -0800, t...@redhat.com wrote:
>> From: Tom Rix
>>
>> >From [PATCH 0/2] UIO support for dfl devices
>> https://lore.kernel.org/linux-fpga/1602828151-24784-1-git-send-email-yilun...@intel.com/
> Why is this here?
As reference, Yilun's work has precedence for a uio driver and this rfc is
trying to address what i believe is a sticking point of the driver override.
This rfc is some code i hacked out to show the idea and move uio support along.
I would like to see uio support for at least the unclaimed feature id's
because this would make it easier for them to be developed.
>> Here is an idea to have uio support with no driver override.
>>
>> This makes UIO the primary driver interface because every feature
>> will have one and makes the existing platform driver interface
>> secondary. There will be a new burden for locking write access when
>> they compete.
>>
>> Example shows finding the fpga's temperture.
>>
>> Signed-off-by: Tom Rix
>> ---
>> drivers/fpga/dfl-fme-main.c | 9 +++-
>> drivers/fpga/dfl-uio.c | 96 +
>> drivers/fpga/dfl.c | 44 -
>> drivers/fpga/dfl.h | 9
>> uio.c | 56 ++
>> 5 files changed, 212 insertions(+), 2 deletions(-)
>> create mode 100644 drivers/fpga/dfl-uio.c
>> create mode 100644 uio.c
>>
>> diff --git a/drivers/fpga/dfl-fme-main.c b/drivers/fpga/dfl-fme-main.c
>> index 037dc4f946f0..3323e90a18c4 100644
>> --- a/drivers/fpga/dfl-fme-main.c
>> +++ b/drivers/fpga/dfl-fme-main.c
>> @@ -709,12 +709,18 @@ static int fme_probe(struct platform_device *pdev)
>> if (ret)
>> goto dev_destroy;
>>
>> -ret = dfl_fpga_dev_ops_register(pdev, _fops, THIS_MODULE);
>> +ret = dfl_fpga_dev_feature_init_uio(pdev, DFH_TYPE_FIU);
>> if (ret)
>> goto feature_uinit;
>>
>> +ret = dfl_fpga_dev_ops_register(pdev, _fops, THIS_MODULE);
>> +if (ret)
>> +goto feature_uinit_uio;
>> +
>> return 0;
>>
>> +feature_uinit_uio:
>> +dfl_fpga_dev_feature_uinit_uio(pdev, DFH_TYPE_FIU);
>> feature_uinit:
>> dfl_fpga_dev_feature_uinit(pdev);
>> dev_destroy:
>> @@ -726,6 +732,7 @@ exit:
>> static int fme_remove(struct platform_device *pdev)
>> {
>> dfl_fpga_dev_ops_unregister(pdev);
>> +dfl_fpga_dev_feature_uinit_uio(pdev, DFH_TYPE_FIU);
>> dfl_fpga_dev_feature_uinit(pdev);
>> fme_dev_destroy(pdev);
>>
>> diff --git a/drivers/fpga/dfl-uio.c b/drivers/fpga/dfl-uio.c
>> new file mode 100644
>> index ..7610ee0b19dc
>> --- /dev/null
>> +++ b/drivers/fpga/dfl-uio.c
>> @@ -0,0 +1,96 @@
>> +/* SPDX-License-Identifier: GPL-2.0 */
>> +/*
>> + * prototype dfl uio driver
>> + *
>> + * Copyright Tom Rix 2020
>> + */
>> +#include
>> +#include "dfl.h"
>> +
>> +static irqreturn_t dfl_uio_handler(int irq, struct uio_info *info)
>> +{
>> +return IRQ_HANDLED;
>> +}
>> +
>> +static int dfl_uio_mmap(struct uio_info *info, struct vm_area_struct *vma)
>> +{
>> +int ret = -ENODEV;
>> +return ret;
> Did you run this through checkpatch?
>
> Does the code make sense?
>
>> +}
>> +
>> +static int dfl_uio_open(struct uio_info *info, struct inode *inode)
>> +{
>> +int ret = -ENODEV;
>> +struct dfl_feature *feature = container_of(info, struct dfl_feature,
>> uio);
>> +if (feature->dev)
>> +mutex_lock(>lock);
>> +
>> +ret = 0;
>> +return ret;
> Same here, does this make sense?
>
> And wait, you are having userspace grab a kernel lock? What could go
> wrong? :(
>
Yes, this is the bad part of this idea.
Tom
>> +}
>> +
>> +static int dfl_uio_release(struct uio_info *info, struct inode *inode)
>> +{
>> +int ret = -ENODEV;
>> +struct dfl_feature *feature = container_of(info, struct dfl_feature,
>> uio);
>> +if (feature->dev)
>> +mutex_unlock(>lock);
>> +
>> +ret = 0;
>> +return ret;
>> +}
>> +
>> +static int dfl_uio_irqcontrol(struct uio_info *info, s32 irq_on)
>> +{
>> +int ret = -ENODEV;
>> +return ret;
>> +}
>> +
>> +int dfl_uio_add(struct dfl_feature *feature)
>> +{
>> +struct uio_info *uio = >uio;
>> +struct resource *res =
>> +>dev->resource[feature->resource_index];
>> +int ret = 0;
>> +
>> +uio->name = kasprintf(GFP_KERNEL, "dfl-uio-%llx", feature->id);
>> +if (!uio->name) {
>> +ret = -ENOMEM;
>> +goto exit;
>> +}
>> +
>> +uio->version = "0.1";
>> +uio->mem[0].memtype = UIO_MEM_PHYS;
>> +uio->mem[0].addr = res->start & PAGE_MASK;
>> +uio->mem[0].offs = res->start & ~PAGE_MASK;
>> +uio->mem[0].size = (uio->mem[0].offs + resource_size(res)
>> ++ PAGE_SIZE - 1) & PAGE_MASK;
>> +/* How are nr_irqs > 1 handled ??? */
>> +if (feature->nr_irqs == 1)
>> +uio->irq = feature->irq_ctx[0].irq;
>> +uio->handler =
Re: [RFC] fpga: dfl: a prototype uio driver
On 12/6/20 10:24 PM, Wu, Hao wrote:
>> Subject: Re: [RFC] fpga: dfl: a prototype uio driver
>>
>> On Sun, Dec 06, 2020 at 01:55:54PM -0800, t...@redhat.com wrote:
>>> From: Tom Rix
>>>
>>> >From [PATCH 0/2] UIO support for dfl devices
>>> https://lore.kernel.org/linux-fpga/1602828151-24784-1-git-send-email-
>> yilun...@intel.com/
>>> Here is an idea to have uio support with no driver override.
>>>
>>> This makes UIO the primary driver interface because every feature
>>> will have one and makes the existing platform driver interface
>>> secondary. There will be a new burden for locking write access when
>>> they compete.
>>>
>>> Example shows finding the fpga's temperture.
>> Hi Tom:
>>
>> Thanks for the idea and detailed illustrate with the patch. I see it
>> abandons the driver_override and expose all the DFL devices to userspace
>> by UIO. I'd like to see if we could get some more comments on it.
> This allows concurrent access from both userspace and kernel space driver
> to the same feature device? conflicts?
Yes conflicts, that is why a lock is needed and the unpleasant part of this
idea.
Another way is split them and have uio for the unclaimed feature id's
Tom
>
> Hao
>
>> Thanks,
>> Yilun
>>
>>> Signed-off-by: Tom Rix
>>> ---
>>> drivers/fpga/dfl-fme-main.c | 9 +++-
>>> drivers/fpga/dfl-uio.c | 96 +
>>> drivers/fpga/dfl.c | 44 -
>>> drivers/fpga/dfl.h | 9
>>> uio.c | 56 ++
>>> 5 files changed, 212 insertions(+), 2 deletions(-)
>>> create mode 100644 drivers/fpga/dfl-uio.c
>>> create mode 100644 uio.c
>>>
>>> diff --git a/drivers/fpga/dfl-fme-main.c b/drivers/fpga/dfl-fme-main.c
>>> index 037dc4f946f0..3323e90a18c4 100644
>>> --- a/drivers/fpga/dfl-fme-main.c
>>> +++ b/drivers/fpga/dfl-fme-main.c
>>> @@ -709,12 +709,18 @@ static int fme_probe(struct platform_device
>> *pdev)
>>> if (ret)
>>> goto dev_destroy;
>>>
>>> - ret = dfl_fpga_dev_ops_register(pdev, _fops, THIS_MODULE);
>>> + ret = dfl_fpga_dev_feature_init_uio(pdev, DFH_TYPE_FIU);
>>> if (ret)
>>> goto feature_uinit;
>>>
>>> + ret = dfl_fpga_dev_ops_register(pdev, _fops, THIS_MODULE);
>>> + if (ret)
>>> + goto feature_uinit_uio;
>>> +
>>> return 0;
>>>
>>> +feature_uinit_uio:
>>> + dfl_fpga_dev_feature_uinit_uio(pdev, DFH_TYPE_FIU);
>>> feature_uinit:
>>> dfl_fpga_dev_feature_uinit(pdev);
>>> dev_destroy:
>>> @@ -726,6 +732,7 @@ exit:
>>> static int fme_remove(struct platform_device *pdev)
>>> {
>>> dfl_fpga_dev_ops_unregister(pdev);
>>> + dfl_fpga_dev_feature_uinit_uio(pdev, DFH_TYPE_FIU);
>>> dfl_fpga_dev_feature_uinit(pdev);
>>> fme_dev_destroy(pdev);
>>>
>>> diff --git a/drivers/fpga/dfl-uio.c b/drivers/fpga/dfl-uio.c
>>> new file mode 100644
>>> index ..7610ee0b19dc
>>> --- /dev/null
>>> +++ b/drivers/fpga/dfl-uio.c
>>> @@ -0,0 +1,96 @@
>>> +/* SPDX-License-Identifier: GPL-2.0 */
>>> +/*
>>> + * prototype dfl uio driver
>>> + *
>>> + * Copyright Tom Rix 2020
>>> + */
>>> +#include
>>> +#include "dfl.h"
>>> +
>>> +static irqreturn_t dfl_uio_handler(int irq, struct uio_info *info)
>>> +{
>>> + return IRQ_HANDLED;
>>> +}
>>> +
>>> +static int dfl_uio_mmap(struct uio_info *info, struct vm_area_struct *vma)
>>> +{
>>> + int ret = -ENODEV;
>>> + return ret;
>>> +}
>>> +
>>> +static int dfl_uio_open(struct uio_info *info, struct inode *inode)
>>> +{
>>> + int ret = -ENODEV;
>>> + struct dfl_feature *feature = container_of(info, struct dfl_feature,
>> uio);
>>> + if (feature->dev)
>>> + mutex_lock(>lock);
>>> +
>>> + ret = 0;
>>> + return ret;
>>> +}
>>> +
>>> +static int dfl_uio_release(struct uio_info *info, struct inode *inode)
>>> +{
>>> + int ret = -ENODEV;
>>> + struct dfl_feature *feature = container_of(info, struct dfl_feature,
>> uio);
>>> + if (feature->dev)
>>> + mutex_unloc
Re: [RFC] fpga: dfl: a prototype uio driver
On Sun, Dec 06, 2020 at 01:55:54PM -0800, t...@redhat.com wrote:
> From: Tom Rix
>
> >From [PATCH 0/2] UIO support for dfl devices
> https://lore.kernel.org/linux-fpga/1602828151-24784-1-git-send-email-yilun...@intel.com/
Why is this here?
>
> Here is an idea to have uio support with no driver override.
>
> This makes UIO the primary driver interface because every feature
> will have one and makes the existing platform driver interface
> secondary. There will be a new burden for locking write access when
> they compete.
>
> Example shows finding the fpga's temperture.
>
> Signed-off-by: Tom Rix
> ---
> drivers/fpga/dfl-fme-main.c | 9 +++-
> drivers/fpga/dfl-uio.c | 96 +
> drivers/fpga/dfl.c | 44 -
> drivers/fpga/dfl.h | 9
> uio.c | 56 ++
> 5 files changed, 212 insertions(+), 2 deletions(-)
> create mode 100644 drivers/fpga/dfl-uio.c
> create mode 100644 uio.c
>
> diff --git a/drivers/fpga/dfl-fme-main.c b/drivers/fpga/dfl-fme-main.c
> index 037dc4f946f0..3323e90a18c4 100644
> --- a/drivers/fpga/dfl-fme-main.c
> +++ b/drivers/fpga/dfl-fme-main.c
> @@ -709,12 +709,18 @@ static int fme_probe(struct platform_device *pdev)
> if (ret)
> goto dev_destroy;
>
> - ret = dfl_fpga_dev_ops_register(pdev, _fops, THIS_MODULE);
> + ret = dfl_fpga_dev_feature_init_uio(pdev, DFH_TYPE_FIU);
> if (ret)
> goto feature_uinit;
>
> + ret = dfl_fpga_dev_ops_register(pdev, _fops, THIS_MODULE);
> + if (ret)
> + goto feature_uinit_uio;
> +
> return 0;
>
> +feature_uinit_uio:
> + dfl_fpga_dev_feature_uinit_uio(pdev, DFH_TYPE_FIU);
> feature_uinit:
> dfl_fpga_dev_feature_uinit(pdev);
> dev_destroy:
> @@ -726,6 +732,7 @@ exit:
> static int fme_remove(struct platform_device *pdev)
> {
> dfl_fpga_dev_ops_unregister(pdev);
> + dfl_fpga_dev_feature_uinit_uio(pdev, DFH_TYPE_FIU);
> dfl_fpga_dev_feature_uinit(pdev);
> fme_dev_destroy(pdev);
>
> diff --git a/drivers/fpga/dfl-uio.c b/drivers/fpga/dfl-uio.c
> new file mode 100644
> index ..7610ee0b19dc
> --- /dev/null
> +++ b/drivers/fpga/dfl-uio.c
> @@ -0,0 +1,96 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +/*
> + * prototype dfl uio driver
> + *
> + * Copyright Tom Rix 2020
> + */
> +#include
> +#include "dfl.h"
> +
> +static irqreturn_t dfl_uio_handler(int irq, struct uio_info *info)
> +{
> + return IRQ_HANDLED;
> +}
> +
> +static int dfl_uio_mmap(struct uio_info *info, struct vm_area_struct *vma)
> +{
> + int ret = -ENODEV;
> + return ret;
Did you run this through checkpatch?
Does the code make sense?
> +}
> +
> +static int dfl_uio_open(struct uio_info *info, struct inode *inode)
> +{
> + int ret = -ENODEV;
> + struct dfl_feature *feature = container_of(info, struct dfl_feature,
> uio);
> + if (feature->dev)
> + mutex_lock(>lock);
> +
> + ret = 0;
> + return ret;
Same here, does this make sense?
And wait, you are having userspace grab a kernel lock? What could go
wrong? :(
> +}
> +
> +static int dfl_uio_release(struct uio_info *info, struct inode *inode)
> +{
> + int ret = -ENODEV;
> + struct dfl_feature *feature = container_of(info, struct dfl_feature,
> uio);
> + if (feature->dev)
> + mutex_unlock(>lock);
> +
> + ret = 0;
> + return ret;
> +}
> +
> +static int dfl_uio_irqcontrol(struct uio_info *info, s32 irq_on)
> +{
> + int ret = -ENODEV;
> + return ret;
> +}
> +
> +int dfl_uio_add(struct dfl_feature *feature)
> +{
> + struct uio_info *uio = >uio;
> + struct resource *res =
> + >dev->resource[feature->resource_index];
> + int ret = 0;
> +
> + uio->name = kasprintf(GFP_KERNEL, "dfl-uio-%llx", feature->id);
> + if (!uio->name) {
> + ret = -ENOMEM;
> + goto exit;
> + }
> +
> + uio->version = "0.1";
> + uio->mem[0].memtype = UIO_MEM_PHYS;
> + uio->mem[0].addr = res->start & PAGE_MASK;
> + uio->mem[0].offs = res->start & ~PAGE_MASK;
> + uio->mem[0].size = (uio->mem[0].offs + resource_size(res)
> + + PAGE_SIZE - 1) & PAGE_MASK;
> + /* How are nr_irqs > 1 handled ??? */
> + if (feature->nr_irqs == 1)
> + uio->irq = feature->irq_ctx[0].irq;
> + uio->handler = dfl_uio_handler;
> + //uio->mmap = dfl_uio_mmap;
???
I don't understand what this patch is trying to show...
thanks,
greg k-h
RE: [RFC] fpga: dfl: a prototype uio driver
> Subject: Re: [RFC] fpga: dfl: a prototype uio driver
>
> On Sun, Dec 06, 2020 at 01:55:54PM -0800, t...@redhat.com wrote:
> > From: Tom Rix
> >
> > >From [PATCH 0/2] UIO support for dfl devices
> > https://lore.kernel.org/linux-fpga/1602828151-24784-1-git-send-email-
> yilun...@intel.com/
> >
> > Here is an idea to have uio support with no driver override.
> >
> > This makes UIO the primary driver interface because every feature
> > will have one and makes the existing platform driver interface
> > secondary. There will be a new burden for locking write access when
> > they compete.
> >
> > Example shows finding the fpga's temperture.
>
> Hi Tom:
>
> Thanks for the idea and detailed illustrate with the patch. I see it
> abandons the driver_override and expose all the DFL devices to userspace
> by UIO. I'd like to see if we could get some more comments on it.
This allows concurrent access from both userspace and kernel space driver
to the same feature device? conflicts?
Hao
>
> Thanks,
> Yilun
>
> >
> > Signed-off-by: Tom Rix
> > ---
> > drivers/fpga/dfl-fme-main.c | 9 +++-
> > drivers/fpga/dfl-uio.c | 96 +
> > drivers/fpga/dfl.c | 44 -
> > drivers/fpga/dfl.h | 9
> > uio.c | 56 ++
> > 5 files changed, 212 insertions(+), 2 deletions(-)
> > create mode 100644 drivers/fpga/dfl-uio.c
> > create mode 100644 uio.c
> >
> > diff --git a/drivers/fpga/dfl-fme-main.c b/drivers/fpga/dfl-fme-main.c
> > index 037dc4f946f0..3323e90a18c4 100644
> > --- a/drivers/fpga/dfl-fme-main.c
> > +++ b/drivers/fpga/dfl-fme-main.c
> > @@ -709,12 +709,18 @@ static int fme_probe(struct platform_device
> *pdev)
> > if (ret)
> > goto dev_destroy;
> >
> > - ret = dfl_fpga_dev_ops_register(pdev, _fops, THIS_MODULE);
> > + ret = dfl_fpga_dev_feature_init_uio(pdev, DFH_TYPE_FIU);
> > if (ret)
> > goto feature_uinit;
> >
> > + ret = dfl_fpga_dev_ops_register(pdev, _fops, THIS_MODULE);
> > + if (ret)
> > + goto feature_uinit_uio;
> > +
> > return 0;
> >
> > +feature_uinit_uio:
> > + dfl_fpga_dev_feature_uinit_uio(pdev, DFH_TYPE_FIU);
> > feature_uinit:
> > dfl_fpga_dev_feature_uinit(pdev);
> > dev_destroy:
> > @@ -726,6 +732,7 @@ exit:
> > static int fme_remove(struct platform_device *pdev)
> > {
> > dfl_fpga_dev_ops_unregister(pdev);
> > + dfl_fpga_dev_feature_uinit_uio(pdev, DFH_TYPE_FIU);
> > dfl_fpga_dev_feature_uinit(pdev);
> > fme_dev_destroy(pdev);
> >
> > diff --git a/drivers/fpga/dfl-uio.c b/drivers/fpga/dfl-uio.c
> > new file mode 100644
> > index ..7610ee0b19dc
> > --- /dev/null
> > +++ b/drivers/fpga/dfl-uio.c
> > @@ -0,0 +1,96 @@
> > +/* SPDX-License-Identifier: GPL-2.0 */
> > +/*
> > + * prototype dfl uio driver
> > + *
> > + * Copyright Tom Rix 2020
> > + */
> > +#include
> > +#include "dfl.h"
> > +
> > +static irqreturn_t dfl_uio_handler(int irq, struct uio_info *info)
> > +{
> > + return IRQ_HANDLED;
> > +}
> > +
> > +static int dfl_uio_mmap(struct uio_info *info, struct vm_area_struct *vma)
> > +{
> > + int ret = -ENODEV;
> > + return ret;
> > +}
> > +
> > +static int dfl_uio_open(struct uio_info *info, struct inode *inode)
> > +{
> > + int ret = -ENODEV;
> > + struct dfl_feature *feature = container_of(info, struct dfl_feature,
> uio);
> > + if (feature->dev)
> > + mutex_lock(>lock);
> > +
> > + ret = 0;
> > + return ret;
> > +}
> > +
> > +static int dfl_uio_release(struct uio_info *info, struct inode *inode)
> > +{
> > + int ret = -ENODEV;
> > + struct dfl_feature *feature = container_of(info, struct dfl_feature,
> uio);
> > + if (feature->dev)
> > + mutex_unlock(>lock);
> > +
> > + ret = 0;
> > + return ret;
> > +}
> > +
> > +static int dfl_uio_irqcontrol(struct uio_info *info, s32 irq_on)
> > +{
> > + int ret = -ENODEV;
> > + return ret;
> > +}
> > +
> > +int dfl_uio_add(struct dfl_feature *feature)
> > +{
> > + struct uio_info *uio = >uio;
> > + struct resource *res =
> > + >dev->resource[feature->resource_index];
> > + int ret = 0;
> > +
>
Re: [RFC] fpga: dfl: a prototype uio driver
On Sun, Dec 06, 2020 at 01:55:54PM -0800, t...@redhat.com wrote:
> From: Tom Rix
>
> >From [PATCH 0/2] UIO support for dfl devices
> https://lore.kernel.org/linux-fpga/1602828151-24784-1-git-send-email-yilun...@intel.com/
>
> Here is an idea to have uio support with no driver override.
>
> This makes UIO the primary driver interface because every feature
> will have one and makes the existing platform driver interface
> secondary. There will be a new burden for locking write access when
> they compete.
>
> Example shows finding the fpga's temperture.
Hi Tom:
Thanks for the idea and detailed illustrate with the patch. I see it
abandons the driver_override and expose all the DFL devices to userspace
by UIO. I'd like to see if we could get some more comments on it.
Thanks,
Yilun
>
> Signed-off-by: Tom Rix
> ---
> drivers/fpga/dfl-fme-main.c | 9 +++-
> drivers/fpga/dfl-uio.c | 96 +
> drivers/fpga/dfl.c | 44 -
> drivers/fpga/dfl.h | 9
> uio.c | 56 ++
> 5 files changed, 212 insertions(+), 2 deletions(-)
> create mode 100644 drivers/fpga/dfl-uio.c
> create mode 100644 uio.c
>
> diff --git a/drivers/fpga/dfl-fme-main.c b/drivers/fpga/dfl-fme-main.c
> index 037dc4f946f0..3323e90a18c4 100644
> --- a/drivers/fpga/dfl-fme-main.c
> +++ b/drivers/fpga/dfl-fme-main.c
> @@ -709,12 +709,18 @@ static int fme_probe(struct platform_device *pdev)
> if (ret)
> goto dev_destroy;
>
> - ret = dfl_fpga_dev_ops_register(pdev, _fops, THIS_MODULE);
> + ret = dfl_fpga_dev_feature_init_uio(pdev, DFH_TYPE_FIU);
> if (ret)
> goto feature_uinit;
>
> + ret = dfl_fpga_dev_ops_register(pdev, _fops, THIS_MODULE);
> + if (ret)
> + goto feature_uinit_uio;
> +
> return 0;
>
> +feature_uinit_uio:
> + dfl_fpga_dev_feature_uinit_uio(pdev, DFH_TYPE_FIU);
> feature_uinit:
> dfl_fpga_dev_feature_uinit(pdev);
> dev_destroy:
> @@ -726,6 +732,7 @@ exit:
> static int fme_remove(struct platform_device *pdev)
> {
> dfl_fpga_dev_ops_unregister(pdev);
> + dfl_fpga_dev_feature_uinit_uio(pdev, DFH_TYPE_FIU);
> dfl_fpga_dev_feature_uinit(pdev);
> fme_dev_destroy(pdev);
>
> diff --git a/drivers/fpga/dfl-uio.c b/drivers/fpga/dfl-uio.c
> new file mode 100644
> index ..7610ee0b19dc
> --- /dev/null
> +++ b/drivers/fpga/dfl-uio.c
> @@ -0,0 +1,96 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +/*
> + * prototype dfl uio driver
> + *
> + * Copyright Tom Rix 2020
> + */
> +#include
> +#include "dfl.h"
> +
> +static irqreturn_t dfl_uio_handler(int irq, struct uio_info *info)
> +{
> + return IRQ_HANDLED;
> +}
> +
> +static int dfl_uio_mmap(struct uio_info *info, struct vm_area_struct *vma)
> +{
> + int ret = -ENODEV;
> + return ret;
> +}
> +
> +static int dfl_uio_open(struct uio_info *info, struct inode *inode)
> +{
> + int ret = -ENODEV;
> + struct dfl_feature *feature = container_of(info, struct dfl_feature,
> uio);
> + if (feature->dev)
> + mutex_lock(>lock);
> +
> + ret = 0;
> + return ret;
> +}
> +
> +static int dfl_uio_release(struct uio_info *info, struct inode *inode)
> +{
> + int ret = -ENODEV;
> + struct dfl_feature *feature = container_of(info, struct dfl_feature,
> uio);
> + if (feature->dev)
> + mutex_unlock(>lock);
> +
> + ret = 0;
> + return ret;
> +}
> +
> +static int dfl_uio_irqcontrol(struct uio_info *info, s32 irq_on)
> +{
> + int ret = -ENODEV;
> + return ret;
> +}
> +
> +int dfl_uio_add(struct dfl_feature *feature)
> +{
> + struct uio_info *uio = >uio;
> + struct resource *res =
> + >dev->resource[feature->resource_index];
> + int ret = 0;
> +
> + uio->name = kasprintf(GFP_KERNEL, "dfl-uio-%llx", feature->id);
> + if (!uio->name) {
> + ret = -ENOMEM;
> + goto exit;
> + }
> +
> + uio->version = "0.1";
> + uio->mem[0].memtype = UIO_MEM_PHYS;
> + uio->mem[0].addr = res->start & PAGE_MASK;
> + uio->mem[0].offs = res->start & ~PAGE_MASK;
> + uio->mem[0].size = (uio->mem[0].offs + resource_size(res)
> + + PAGE_SIZE - 1) & PAGE_MASK;
> + /* How are nr_irqs > 1 handled ??? */
> + if (feature->nr_irqs == 1)
> + uio->irq = feature->irq_ctx[0].irq;
> + uio->handler = dfl_uio_handler;
> + //uio->mmap = dfl_uio_mmap;
> + uio->open = dfl_uio_open;
> + uio->release = dfl_uio_release;
> + uio->irqcontrol = dfl_uio_irqcontrol;
> +
> + ret = uio_register_device(>dev->dev, uio);
> + if (ret)
> + goto err_register;
> +
> +exit:
> + return ret;
> +err_register:
> + kfree(uio->name);
> + goto exit;
> +}
> +EXPORT_SYMBOL_GPL(dfl_uio_add);
> +
> +int dfl_uio_remove(struct dfl_feature *feature)
> +{
> + uio_unregister_device(>uio);
> +
[RFC] fpga: dfl: a prototype uio driver
From: Tom Rix
>From [PATCH 0/2] UIO support for dfl devices
https://lore.kernel.org/linux-fpga/1602828151-24784-1-git-send-email-yilun...@intel.com/
Here is an idea to have uio support with no driver override.
This makes UIO the primary driver interface because every feature
will have one and makes the existing platform driver interface
secondary. There will be a new burden for locking write access when
they compete.
Example shows finding the fpga's temperture.
Signed-off-by: Tom Rix
---
drivers/fpga/dfl-fme-main.c | 9 +++-
drivers/fpga/dfl-uio.c | 96 +
drivers/fpga/dfl.c | 44 -
drivers/fpga/dfl.h | 9
uio.c | 56 ++
5 files changed, 212 insertions(+), 2 deletions(-)
create mode 100644 drivers/fpga/dfl-uio.c
create mode 100644 uio.c
diff --git a/drivers/fpga/dfl-fme-main.c b/drivers/fpga/dfl-fme-main.c
index 037dc4f946f0..3323e90a18c4 100644
--- a/drivers/fpga/dfl-fme-main.c
+++ b/drivers/fpga/dfl-fme-main.c
@@ -709,12 +709,18 @@ static int fme_probe(struct platform_device *pdev)
if (ret)
goto dev_destroy;
- ret = dfl_fpga_dev_ops_register(pdev, _fops, THIS_MODULE);
+ ret = dfl_fpga_dev_feature_init_uio(pdev, DFH_TYPE_FIU);
if (ret)
goto feature_uinit;
+ ret = dfl_fpga_dev_ops_register(pdev, _fops, THIS_MODULE);
+ if (ret)
+ goto feature_uinit_uio;
+
return 0;
+feature_uinit_uio:
+ dfl_fpga_dev_feature_uinit_uio(pdev, DFH_TYPE_FIU);
feature_uinit:
dfl_fpga_dev_feature_uinit(pdev);
dev_destroy:
@@ -726,6 +732,7 @@ exit:
static int fme_remove(struct platform_device *pdev)
{
dfl_fpga_dev_ops_unregister(pdev);
+ dfl_fpga_dev_feature_uinit_uio(pdev, DFH_TYPE_FIU);
dfl_fpga_dev_feature_uinit(pdev);
fme_dev_destroy(pdev);
diff --git a/drivers/fpga/dfl-uio.c b/drivers/fpga/dfl-uio.c
new file mode 100644
index ..7610ee0b19dc
--- /dev/null
+++ b/drivers/fpga/dfl-uio.c
@@ -0,0 +1,96 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * prototype dfl uio driver
+ *
+ * Copyright Tom Rix 2020
+ */
+#include
+#include "dfl.h"
+
+static irqreturn_t dfl_uio_handler(int irq, struct uio_info *info)
+{
+ return IRQ_HANDLED;
+}
+
+static int dfl_uio_mmap(struct uio_info *info, struct vm_area_struct *vma)
+{
+ int ret = -ENODEV;
+ return ret;
+}
+
+static int dfl_uio_open(struct uio_info *info, struct inode *inode)
+{
+ int ret = -ENODEV;
+ struct dfl_feature *feature = container_of(info, struct dfl_feature,
uio);
+ if (feature->dev)
+ mutex_lock(>lock);
+
+ ret = 0;
+ return ret;
+}
+
+static int dfl_uio_release(struct uio_info *info, struct inode *inode)
+{
+ int ret = -ENODEV;
+ struct dfl_feature *feature = container_of(info, struct dfl_feature,
uio);
+ if (feature->dev)
+ mutex_unlock(>lock);
+
+ ret = 0;
+ return ret;
+}
+
+static int dfl_uio_irqcontrol(struct uio_info *info, s32 irq_on)
+{
+ int ret = -ENODEV;
+ return ret;
+}
+
+int dfl_uio_add(struct dfl_feature *feature)
+{
+ struct uio_info *uio = >uio;
+ struct resource *res =
+ >dev->resource[feature->resource_index];
+ int ret = 0;
+
+ uio->name = kasprintf(GFP_KERNEL, "dfl-uio-%llx", feature->id);
+ if (!uio->name) {
+ ret = -ENOMEM;
+ goto exit;
+ }
+
+ uio->version = "0.1";
+ uio->mem[0].memtype = UIO_MEM_PHYS;
+ uio->mem[0].addr = res->start & PAGE_MASK;
+ uio->mem[0].offs = res->start & ~PAGE_MASK;
+ uio->mem[0].size = (uio->mem[0].offs + resource_size(res)
+ + PAGE_SIZE - 1) & PAGE_MASK;
+ /* How are nr_irqs > 1 handled ??? */
+ if (feature->nr_irqs == 1)
+ uio->irq = feature->irq_ctx[0].irq;
+ uio->handler = dfl_uio_handler;
+ //uio->mmap = dfl_uio_mmap;
+ uio->open = dfl_uio_open;
+ uio->release = dfl_uio_release;
+ uio->irqcontrol = dfl_uio_irqcontrol;
+
+ ret = uio_register_device(>dev->dev, uio);
+ if (ret)
+ goto err_register;
+
+exit:
+ return ret;
+err_register:
+ kfree(uio->name);
+ goto exit;
+}
+EXPORT_SYMBOL_GPL(dfl_uio_add);
+
+int dfl_uio_remove(struct dfl_feature *feature)
+{
+ uio_unregister_device(>uio);
+ kfree(feature->uio.name);
+ return 0;
+}
+EXPORT_SYMBOL_GPL(dfl_uio_remove);
+
diff --git a/drivers/fpga/dfl.c b/drivers/fpga/dfl.c
index 1305be48037d..af2cd3d1b5f6 100644
--- a/drivers/fpga/dfl.c
+++ b/drivers/fpga/dfl.c
@@ -603,6 +603,7 @@ static int dfl_feature_instance_init(struct platform_device
*pdev,
}
feature->ops = drv->ops;
+ mutex_init(>lock);
return ret;
}
@@ -663,10 +664,51 @@ exit:
}
EXPORT_SYMBOL_GPL(dfl_fpga_dev_feature_init);
Re: [RFC] fpga: dfl: a prototype uio driver
On 9/21/20 8:18 PM, Xu Yilun wrote: > On Mon, Sep 21, 2020 at 12:32:16PM -0700, Tom Rix wrote: >> On 9/21/20 1:55 AM, Xu Yilun wrote: >>> On Sat, Sep 19, 2020 at 09:51:13AM -0700, t...@redhat.com wrote: From: Tom Rix I following up on Moritz asking for early RFC's by showing how this could be done with the concrete example of around [PATCH 0/3] add VFIO mdev support for DFL devices I hacked this together, it barely works. Do not expect that this patch to apply anywhere. It has enough to show where I want to go and people can comment without me having invested a lot of effort. I am not expecting to carry this forward, it only addresses the issues I had with the origin patch. This change adds a uio driver for any unclaimed dfl feature During the normal matching of feature id's to drivers, some of the features are not claimed because there neither a builtin driver nor a module driver that matches the feature id. For these unclaimed features, provide a uio driver to a possible user space driver. >>> I think we don't have to setup UIO interfaces for all unclaimed >>> features. It could be the decision of the user whether the UIO >>> device is needed for a feature. My opinion is that, the >>> driver_override sysfs is still generic enough for user's to switch >>> between kernel device drivers and dfl uio driver. >> Instead of a string, could there just be a 'use_uio' flag ? >> >> How does the 'driver_override' work when there is no starting driver ? > Now we have a dfl bus_type, we could add the 'driver_override' to each > dfl device on dfl bus. It is the same as 'feature_id' & 'type'. > > Actually the 'driver_override' also exists in various bus type (platform, > pci ...). > >>> There may be cases the dfl device driver modules are not inserted >>> during dfl-fme/port initialization, but they are to be inserted >>> manually. If the features are all registered to uio, then there will >>> be problems when dfl device drivers module are inserted. >> How does this manual loading work ? The driver list for the features >> >> seems to only be used during the card probe time. >> >> To change the order the dfl-pci needs to be unloaded and that will >> >> destroy all the uio devices as well as usual feature drivers attached to >> >> the pci driver. > After we have introduced the dfl bus patches. The initialization flow > is: > > 1. dfl-fme/port initializes its core private features (listed in >fme/port_feature_drvs array), these private features are part of >the dfl-fme/port module. They cannot be exposed as uio devices cause >they are managed by the dfl-fme/afu kernel driver. > > > 2. The rest of the private features are added as dfl devices. They can >be matched by independent dfl driver modules. dfl-n3000-nios is the >first use case. The dfl-n3000-nios.ko may not be loaded when dfl-fme >probe, but later user loads the module manually by >"insmod drivers/fpga/dfl-n3000-nios.ko". > >If we create uio interfaces for all unclaimed features on >dfl-fme/port probe, then I can see problem when user insmod >dfl-n3000-nios.ko > > > For these dfl devices, we could give users an option to manage them > by userspace I/O access. The flow I suggest is like: > a) load the uio-dfl.ko, it will not match any dfl device now. ># modprobe uio-dfl > > b) unbind the kernel driver for the specific dfl device ># echo dfl_dev.0 > /sys/bus/dfl/drivers/n3000-nios/unbind > > c) assign the uio driver for the dfl device. Please note this will >not trigger any driver matching. ># echo uio-dfl > /sys/bus/dfl/devices/dfl_dev.0/driver_override > > d) actually trigger the driver matching, then the uio-dfl module takes >function. ># echo dfl_dev.0 > /sys/bus/dfl/drivers_probe > >> >>> I have doubts that a uio for an afu feature is approptiate as these can be any device. >>> I think generally afu could also be as uio device if we don't concern >>> about dma isolation. >> I am thinking about afu with its own pci id. >> >> So there could be a conflict with some other driver that responds to the pci >> id. > I think 'driver_override' mechanism solves the problem, it ensures no > other driver could be matched to the device except your assigned one. > >>> But now seems not possible to match afu to uio driver, cause now in DFL >>> framework AFU is managed by dfl-afu.ko >>> Another possible problem is if the number of interrupts for the feature is greater than 1. Uio seems to only support 1. My guess is this would need some hackery in the open() to add to the interrupt handler. >>> I think it may not possible for UIO to support multiple interrupts if >>> user cannot access the interrupt enable/pending registers. The uio >>> device have just one /dev/uioX node for interrupt. So I tend to >>> accept the limitation. And for now we don't have board specific >>>
Re: [RFC] fpga: dfl: a prototype uio driver
On Mon, Sep 21, 2020 at 12:32:16PM -0700, Tom Rix wrote: > > On 9/21/20 1:55 AM, Xu Yilun wrote: > > On Sat, Sep 19, 2020 at 09:51:13AM -0700, t...@redhat.com wrote: > >> From: Tom Rix > >> > >> I following up on Moritz asking for early RFC's by showing how this > >> could be done with the concrete example of around > >> > >> [PATCH 0/3] add VFIO mdev support for DFL devices > >> > >> I hacked this together, it barely works. Do not expect that this > >> patch to apply anywhere. It has enough to show where I want > >> to go and people can comment without me having invested a lot of > >> effort. I am not expecting to carry this forward, it only > >> addresses the issues I had with the origin patch. > >> > >> This change adds a uio driver for any unclaimed dfl feature > >> > >> During the normal matching of feature id's to drivers, some > >> of the features are not claimed because there neither a > >> builtin driver nor a module driver that matches the feature > >> id. For these unclaimed features, provide a uio driver to a > >> possible user space driver. > > I think we don't have to setup UIO interfaces for all unclaimed > > features. It could be the decision of the user whether the UIO > > device is needed for a feature. My opinion is that, the > > driver_override sysfs is still generic enough for user's to switch > > between kernel device drivers and dfl uio driver. > > Instead of a string, could there just be a 'use_uio' flag ? > > How does the 'driver_override' work when there is no starting driver ? Now we have a dfl bus_type, we could add the 'driver_override' to each dfl device on dfl bus. It is the same as 'feature_id' & 'type'. Actually the 'driver_override' also exists in various bus type (platform, pci ...). > > > > > There may be cases the dfl device driver modules are not inserted > > during dfl-fme/port initialization, but they are to be inserted > > manually. If the features are all registered to uio, then there will > > be problems when dfl device drivers module are inserted. > > How does this manual loading work ? The driver list for the features > > seems to only be used during the card probe time. > > To change the order the dfl-pci needs to be unloaded and that will > > destroy all the uio devices as well as usual feature drivers attached to > > the pci driver. After we have introduced the dfl bus patches. The initialization flow is: 1. dfl-fme/port initializes its core private features (listed in fme/port_feature_drvs array), these private features are part of the dfl-fme/port module. They cannot be exposed as uio devices cause they are managed by the dfl-fme/afu kernel driver. 2. The rest of the private features are added as dfl devices. They can be matched by independent dfl driver modules. dfl-n3000-nios is the first use case. The dfl-n3000-nios.ko may not be loaded when dfl-fme probe, but later user loads the module manually by "insmod drivers/fpga/dfl-n3000-nios.ko". If we create uio interfaces for all unclaimed features on dfl-fme/port probe, then I can see problem when user insmod dfl-n3000-nios.ko For these dfl devices, we could give users an option to manage them by userspace I/O access. The flow I suggest is like: a) load the uio-dfl.ko, it will not match any dfl device now. # modprobe uio-dfl b) unbind the kernel driver for the specific dfl device # echo dfl_dev.0 > /sys/bus/dfl/drivers/n3000-nios/unbind c) assign the uio driver for the dfl device. Please note this will not trigger any driver matching. # echo uio-dfl > /sys/bus/dfl/devices/dfl_dev.0/driver_override d) actually trigger the driver matching, then the uio-dfl module takes function. # echo dfl_dev.0 > /sys/bus/dfl/drivers_probe > > > > > > > >> I have doubts that a uio for an afu feature is approptiate as these > >> can be any device. > > I think generally afu could also be as uio device if we don't concern > > about dma isolation. > > I am thinking about afu with its own pci id. > > So there could be a conflict with some other driver that responds to the pci > id. I think 'driver_override' mechanism solves the problem, it ensures no other driver could be matched to the device except your assigned one. > > > > > But now seems not possible to match afu to uio driver, cause now in DFL > > framework AFU is managed by dfl-afu.ko > > > >> Another possible problem is if the number of interrupts for the > >> feature is greater than 1. Uio seems to only support 1. My guess > >> is this would need some hackery in the open() to add to the > >> interrupt handler. > > I think it may not possible for UIO to support multiple interrupts if > > user cannot access the interrupt enable/pending registers. The uio > > device have just one /dev/uioX node for interrupt. So I tend to > > accept the limitation. And for now we don't have board specific > > features that needs multiple interrupts. For PAC N3000, no interrupt is > > needed. > Maybe uio
Re: [RFC] fpga: dfl: a prototype uio driver
On 9/21/20 1:55 AM, Xu Yilun wrote:
> On Sat, Sep 19, 2020 at 09:51:13AM -0700, t...@redhat.com wrote:
>> From: Tom Rix
>>
>> I following up on Moritz asking for early RFC's by showing how this
>> could be done with the concrete example of around
>>
>> [PATCH 0/3] add VFIO mdev support for DFL devices
>>
>> I hacked this together, it barely works. Do not expect that this
>> patch to apply anywhere. It has enough to show where I want
>> to go and people can comment without me having invested a lot of
>> effort. I am not expecting to carry this forward, it only
>> addresses the issues I had with the origin patch.
>>
>> This change adds a uio driver for any unclaimed dfl feature
>>
>> During the normal matching of feature id's to drivers, some
>> of the features are not claimed because there neither a
>> builtin driver nor a module driver that matches the feature
>> id. For these unclaimed features, provide a uio driver to a
>> possible user space driver.
> I think we don't have to setup UIO interfaces for all unclaimed
> features. It could be the decision of the user whether the UIO
> device is needed for a feature. My opinion is that, the
> driver_override sysfs is still generic enough for user's to switch
> between kernel device drivers and dfl uio driver.
Instead of a string, could there just be a 'use_uio' flag ?
How does the 'driver_override' work when there is no starting driver ?
>
> There may be cases the dfl device driver modules are not inserted
> during dfl-fme/port initialization, but they are to be inserted
> manually. If the features are all registered to uio, then there will
> be problems when dfl device drivers module are inserted.
How does this manual loading work ? The driver list for the features
seems to only be used during the card probe time.
To change the order the dfl-pci needs to be unloaded and that will
destroy all the uio devices as well as usual feature drivers attached to
the pci driver.
>
>
>> I have doubts that a uio for an afu feature is approptiate as these
>> can be any device.
> I think generally afu could also be as uio device if we don't concern
> about dma isolation.
I am thinking about afu with its own pci id.
So there could be a conflict with some other driver that responds to the pci id.
>
> But now seems not possible to match afu to uio driver, cause now in DFL
> framework AFU is managed by dfl-afu.ko
>
>> Another possible problem is if the number of interrupts for the
>> feature is greater than 1. Uio seems to only support 1. My guess
>> is this would need some hackery in the open() to add to the
>> interrupt handler.
> I think it may not possible for UIO to support multiple interrupts if
> user cannot access the interrupt enable/pending registers. The uio
> device have just one /dev/uioX node for interrupt. So I tend to
> accept the limitation. And for now we don't have board specific
> features that needs multiple interrupts. For PAC N3000, no interrupt is
> needed.
Maybe uio needs to change to support multiple interrupts ?
>
>> It is for this type of reason I think a dfl-uio driver is needed
>> rather than reusing an existing generic uio driver.
> So if we don't try to change interrupt, the implementation of dfl-uio is
> just a subset of generic uio platform driver, so why not we just use it?
Its a toss up.
Maybe there some dfl only constraints like write/read is a multiple 4 bytes
Or just why have another layer in the setup.
Tom
>
> Thanks,
> Yilun
>
>> Signed-off-by: Tom Rix
>> ---
>> drivers/fpga/dfl-fme-main.c | 9 ++-
>> drivers/fpga/dfl-uio.c | 107
>> drivers/fpga/dfl.c | 47 +++-
>> drivers/fpga/dfl.h | 8 +++
>> 4 files changed, 169 insertions(+), 2 deletions(-)
>> create mode 100644 drivers/fpga/dfl-uio.c
>>
>> diff --git a/drivers/fpga/dfl-fme-main.c b/drivers/fpga/dfl-fme-main.c
>> index 037dc4f..3323e90 100644
>> --- a/drivers/fpga/dfl-fme-main.c
>> +++ b/drivers/fpga/dfl-fme-main.c
>> @@ -709,12 +709,18 @@ static int fme_probe(struct platform_device *pdev)
>> if (ret)
>> goto dev_destroy;
>>
>> -ret = dfl_fpga_dev_ops_register(pdev, _fops, THIS_MODULE);
>> +ret = dfl_fpga_dev_feature_init_uio(pdev, DFH_TYPE_FIU);
>> if (ret)
>> goto feature_uinit;
>>
>> +ret = dfl_fpga_dev_ops_register(pdev, _fops, THIS_MODULE);
>> +if (ret)
>> +goto feature_uinit_uio;
>> +
>> return 0;
>>
>> +feature_uinit_uio:
>> +dfl_fpga_dev_feature_uinit_uio(pdev, DFH_TYPE_FIU);
>> feature_uinit:
>> dfl_fpga_dev_feature_uinit(pdev);
>> dev_destroy:
>> @@ -726,6 +732,7 @@ exit:
>> static int fme_remove(struct platform_device *pdev)
>> {
>> dfl_fpga_dev_ops_unregister(pdev);
>> +dfl_fpga_dev_feature_uinit_uio(pdev, DFH_TYPE_FIU);
>> dfl_fpga_dev_feature_uinit(pdev);
>> fme_dev_destroy(pdev);
>>
>> diff --git a/drivers/fpga/dfl-uio.c b/drivers/fpga/dfl-uio.c
>> new
[RFC] fpga: dfl: a prototype uio driver
From: Tom Rix
I following up on Moritz asking for early RFC's by showing how this
could be done with the concrete example of around
[PATCH 0/3] add VFIO mdev support for DFL devices
I hacked this together, it barely works. Do not expect that this
patch to apply anywhere. It has enough to show where I want
to go and people can comment without me having invested a lot of
effort. I am not expecting to carry this forward, it only
addresses the issues I had with the origin patch.
This change adds a uio driver for any unclaimed dfl feature
During the normal matching of feature id's to drivers, some
of the features are not claimed because there neither a
builtin driver nor a module driver that matches the feature
id. For these unclaimed features, provide a uio driver to a
possible user space driver.
I have doubts that a uio for an afu feature is approptiate as these
can be any device.
Another possible problem is if the number of interrupts for the
feature is greater than 1. Uio seems to only support 1. My guess
is this would need some hackery in the open() to add to the
interrupt handler.
It is for this type of reason I think a dfl-uio driver is needed
rather than reusing an existing generic uio driver.
Signed-off-by: Tom Rix
---
drivers/fpga/dfl-fme-main.c | 9 ++-
drivers/fpga/dfl-uio.c | 107
drivers/fpga/dfl.c | 47 +++-
drivers/fpga/dfl.h | 8 +++
4 files changed, 169 insertions(+), 2 deletions(-)
create mode 100644 drivers/fpga/dfl-uio.c
diff --git a/drivers/fpga/dfl-fme-main.c b/drivers/fpga/dfl-fme-main.c
index 037dc4f..3323e90 100644
--- a/drivers/fpga/dfl-fme-main.c
+++ b/drivers/fpga/dfl-fme-main.c
@@ -709,12 +709,18 @@ static int fme_probe(struct platform_device *pdev)
if (ret)
goto dev_destroy;
- ret = dfl_fpga_dev_ops_register(pdev, _fops, THIS_MODULE);
+ ret = dfl_fpga_dev_feature_init_uio(pdev, DFH_TYPE_FIU);
if (ret)
goto feature_uinit;
+ ret = dfl_fpga_dev_ops_register(pdev, _fops, THIS_MODULE);
+ if (ret)
+ goto feature_uinit_uio;
+
return 0;
+feature_uinit_uio:
+ dfl_fpga_dev_feature_uinit_uio(pdev, DFH_TYPE_FIU);
feature_uinit:
dfl_fpga_dev_feature_uinit(pdev);
dev_destroy:
@@ -726,6 +732,7 @@ exit:
static int fme_remove(struct platform_device *pdev)
{
dfl_fpga_dev_ops_unregister(pdev);
+ dfl_fpga_dev_feature_uinit_uio(pdev, DFH_TYPE_FIU);
dfl_fpga_dev_feature_uinit(pdev);
fme_dev_destroy(pdev);
diff --git a/drivers/fpga/dfl-uio.c b/drivers/fpga/dfl-uio.c
new file mode 100644
index 000..185fbab
--- /dev/null
+++ b/drivers/fpga/dfl-uio.c
@@ -0,0 +1,107 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * prototype dfl uio driver
+ *
+ * Copyright Tom Rix 2020
+ */
+#include
+#include "dfl.h"
+
+static irqreturn_t dfl_uio_handler(int irq, struct uio_info *dev_info)
+{
+ return IRQ_HANDLED;
+}
+
+static int dfl_uio_mmap(struct uio_info *info, struct vm_area_struct *vma)
+{
+ return 0;
+}
+
+static int dfl_uio_open(struct uio_info *info, struct inode *inode)
+{
+ return 0;
+}
+
+static int dfl_uio_release(struct uio_info *info, struct inode *inode)
+{
+ return 0;
+}
+
+static int dfl_uio_irqcontrol(struct uio_info *info, s32 irq_on)
+{
+ return 0;
+}
+
+int dfl_uio_add(struct dfl_feature *feature)
+{
+ struct uio_info *uio;
+ struct resource *res =
+ >dev->resource[feature->resource_index];
+ int ret = 0;
+
+ uio = kzalloc(sizeof(struct uio_info), GFP_KERNEL);
+ if (!uio) {
+ ret = -ENOMEM;
+ goto exit;
+ }
+
+ uio->name = kasprintf(GFP_KERNEL, "dfl-uio-%llx", feature->id);
+ if (!uio->name) {
+ ret = -ENOMEM;
+ goto err_name;
+ }
+
+ uio->version = "0.1";
+ uio->mem[0].memtype = UIO_MEM_PHYS;
+ uio->mem[0].addr = res->start & PAGE_MASK;
+ uio->mem[0].offs = res->start & ~PAGE_MASK;
+ uio->mem[0].size = (uio->mem[0].offs + resource_size(res)
+ + PAGE_SIZE - 1) & PAGE_MASK;
+ /* How are nr_irqs > 1 handled ??? */
+ if (feature->nr_irqs == 1)
+ uio->irq = feature->irq_ctx[0].irq;
+ uio->handler = dfl_uio_handler;
+ uio->mmap = dfl_uio_mmap;
+ uio->open = dfl_uio_open;
+ uio->release = dfl_uio_release;
+ uio->irqcontrol = dfl_uio_irqcontrol;
+
+ ret = uio_register_device(>dev->dev, uio);
+ if (ret)
+ goto err_register;
+
+ feature->uio = uio;
+exit:
+ return ret;
+err_register:
+ kfree(uio->name);
+err_name:
+ kfree(uio);
+ goto exit;
+}
+EXPORT_SYMBOL_GPL(dfl_uio_add);
+
+int dfl_uio_remove(struct dfl_feature *feature)
+{
+ uio_unregister_device(feature->uio);
+ kfree(feature->uio->name);
+ kfree(feature->uio);
+
