lkml.org 
[lkml]   [2020]   [Apr]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH v2,5/5] drivers: uio: new driver for fsl_85xx_cache_sram
From
Date


Le 16/04/2020 à 07:22, Wang Wenhu a écrit :
> Yes, kzalloc() would clean the allocated areas and the init of remaining array
> elements are redundant. I will remove the block in v3.
>
>>>> + dev_err(&pdev->dev, "error no valid uio-map configured\n");
>>>> + ret = -EINVAL;
>>>> + goto err_info_free_internel;
>>>> + }
>>>> +
>>>> + info->version = "0.1.0";
>>>
>>> Could you define some DRIVER_VERSION in the top of the file next to
>>> DRIVER_NAME instead of hard coding in the middle on a function ?
>>
>> That's what v1 had, and Greg KH said to remove it. I'm guessing that he
>> thought it was the common-but-pointless practice of having the driver print a
>> version number that never gets updated, rather than something the UIO API
>> (unfortunately, compared to a feature query interface) expects. That said,
>> I'm not sure what the value is of making it a macro since it should only be
>> used once, that use is self documenting, it isn't tunable, etc. Though if
>> this isn't a macro, UIO_NAME also shouldn't be (and if it is made a macro
>> again, it should be UIO_VERSION, not DRIVER_VERSION).
>>
>> Does this really need a three-part version scheme? What's wrong with a
>> version of "1", to be changed to "2" in the hopefully-unlikely event that the
>> userspace API changes? Assuming UIO is used for this at all, which doesn't
>> seem like a great fit to me.
>>
>> -Scott
>>
>
> As Scott mentioned, the version define as necessity by uio core but actually
> useless for us here(and for many other type of devices I guess). So maybe the better
> way is to set it optionally, but this belong first to uio core.
>
> For the cache-sram uio driver, I will define an UIO_VERSION micro as a compromise
> fit all wonders, no confusing as Greg first mentioned.

Yes I like it.

>
>>> +static const struct of_device_id uio_mpc85xx_l2ctlr_of_match[] = {
>>> + { .compatible = "uio,fsl,p2020-l2-cache-controller", },
>>> + { .compatible = "uio,fsl,p2010-l2-cache-controller", },
>>> + { .compatible = "uio,fsl,p1020-l2-cache-controller", },
>>> + { .compatible = "uio,fsl,p1011-l2-cache-controller", },
>>> + { .compatible = "uio,fsl,p1013-l2-cache-controller", },
>>> + { .compatible = "uio,fsl,p1022-l2-cache-controller", },
>>> + { .compatible = "uio,fsl,mpc8548-l2-cache-controller", },
>>> + { .compatible = "uio,fsl,mpc8544-l2-cache-controller", },
>>> + { .compatible = "uio,fsl,mpc8572-l2-cache-controller", },
>>> + { .compatible = "uio,fsl,mpc8536-l2-cache-controller", },
>>> + { .compatible = "uio,fsl,p1021-l2-cache-controller", },
>>> + { .compatible = "uio,fsl,p1012-l2-cache-controller", },
>>> + { .compatible = "uio,fsl,p1025-l2-cache-controller", },
>>> + { .compatible = "uio,fsl,p1016-l2-cache-controller", },
>>> + { .compatible = "uio,fsl,p1024-l2-cache-controller", },
>>> + { .compatible = "uio,fsl,p1015-l2-cache-controller", },
>>> + { .compatible = "uio,fsl,p1010-l2-cache-controller", },
>>> + { .compatible = "uio,fsl,bsc9131-l2-cache-controller", },
>>> + {},
>>> +};
>>
>> NACK
>>
>> The device tree describes the hardware, not what driver you want to bind the
>> hardware to, or how you want to allocate the resources. And even if defining
>> nodes for sram allocation were the right way to go, why do you have a separate
>> compatible for each chip when you're just describing software configuration?
>>
>> Instead, have module parameters that take the sizes and alignments you'd like
>> to allocate and expose to userspace. Better still would be some sort of
>> dynamic allocation (e.g. open a fd, ioctl to set the requested size/alignment,
>> if it succeeds you can mmap it, and when the fd is closed the region is
>> freed).
>>
>> -Scott
>>
>
> Can not agree more. But what if I want to define more than one cache-sram uio devices?
> How about use the device tree for pseudo uio cache-sram driver?
>
> static const struct of_device_id uio_mpc85xx_l2ctlr_of_match[] = {
> { .compatible = "uio,cache-sram", },
> {},
> };
>

You can still give it a name in line with your driver, ie:
"uio,mpc85xx-cache-sram"

After, it you have different behaviours depending on the compatible,
then you have to add a .data field which will tell the driver which
behaviour to implement.

Christophe

\
 
 \ /
  Last update: 2020-04-16 08:03    [W:1.207 / U:0.088 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site