From: Wang Wenhu <wenhu.wang@vivo.com>
To: christophe.leroy@c-s.fr
Cc: gregkh@linuxfoundation.org, kernel@vivo.com,
linux-kernel@vger.kernel.org, linuxppc-dev@lists.ozlabs.org,
mpe@ellerman.id.au, oss@buserror.net, wenhu.wang@vivo.com
Subject: Re: [PATCH v2,5/5] drivers: uio: new driver for fsl_85xx_cache_sram
Date: Wed, 15 Apr 2020 22:22:47 -0700 [thread overview]
Message-ID: <20200416052247.112887-1-wenhu.wang@vivo.com> (raw)
In-Reply-To: <37b6b890-e537-7424-6b26-04565681f40a@c-s.fr>
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.
>> +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", },
{},
};
Thanks,
Wenhu
next prev parent reply other threads:[~2020-04-16 5:24 UTC|newest]
Thread overview: 46+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-04-15 12:33 [PATCH 0/5] drivers: uio: new driver uio_fsl_85xx_cache_sram Wang Wenhu
2020-04-15 12:33 ` [PATCH 1/5] powerpc: 85xx: make FSL_85XX_CACHE_SRAM configurable Wang Wenhu
2020-04-16 0:58 ` kbuild test robot
2020-04-15 12:33 ` [PATCH 2/5] powerpc: sysdev: fix compile error for fsl_85xx_cache_sram Wang Wenhu
2020-04-15 12:33 ` [PATCH 3/5] powerpc: sysdev: fix compile warning " Wang Wenhu
2020-04-15 12:33 ` [PATCH 4/5] powerpc: sysdev: fix compile error for fsl_85xx_l2ctlr Wang Wenhu
2020-04-15 12:33 ` [PATCH 5/5] drivers: uio: new driver for fsl_85xx_cache_sram Wang Wenhu
2020-04-15 12:49 ` Greg KH
2020-04-15 14:07 ` [PATCH 5/5] drivers: uio: new driver for fsl_85xx_cache_sram>On Wed, Apr 15, 2020 at 05:33:46AM -0700, Wang Wenhu wrote: Wang Wenhu
2020-04-15 15:24 ` [PATCH v2,0/5] drivers: uio: new driver uio_fsl_85xx_cache_sram Wang Wenhu
2020-04-15 15:24 ` [PATCH v2,1/5] powerpc: 85xx: make FSL_85XX_CACHE_SRAM configurable Wang Wenhu
2020-04-15 16:26 ` Christophe Leroy
2020-04-15 16:29 ` Christophe Leroy
2020-04-15 18:53 ` Scott Wood
2020-04-16 4:11 ` Wang Wenhu
2020-04-15 15:24 ` [PATCH v2,2/5] powerpc: sysdev: fix compile error for fsl_85xx_cache_sram Wang Wenhu
2020-04-15 15:24 ` [PATCH v2,3/5] powerpc: sysdev: fix compile warning " Wang Wenhu
2020-04-15 15:24 ` [PATCH v2,4/5] powerpc: sysdev: fix compile error for fsl_85xx_l2ctlr Wang Wenhu
2020-04-15 15:24 ` [PATCH v2,5/5] drivers: uio: new driver for fsl_85xx_cache_sram Wang Wenhu
2020-04-15 16:52 ` Christophe Leroy
2020-04-15 19:27 ` Scott Wood
2020-04-16 6:30 ` Greg KH
2020-04-16 19:36 ` Scott Wood
2020-04-16 5:22 ` Wang Wenhu [this message]
2020-04-16 6:02 ` Christophe Leroy
2020-04-15 19:26 ` Scott Wood
2020-04-16 6:30 ` Greg KH
2020-04-16 19:40 ` Scott Wood
2020-04-16 7:29 ` [PATCH v3,0/4] drivers: uio: new driver uio_fsl_85xx_cache_sram Wang Wenhu
2020-04-16 7:29 ` [PATCH v3,1/4] powerpc: sysdev: fix compile error for fsl_85xx_l2ctlr Wang Wenhu
2020-04-16 7:29 ` [PATCH v3,2/4] powerpc: sysdev: fix compile error for fsl_85xx_cache_sram Wang Wenhu
2020-04-16 7:29 ` [PATCH v3,3/4] powerpc: sysdev: fix compile warning " Wang Wenhu
2020-04-16 7:29 ` [PATCH v3,4/4] drivers: uio: new driver " Wang Wenhu
2020-04-16 7:41 ` [PATCH v3,0/4] drivers: uio: new driver uio_fsl_85xx_cache_sram Wang Wenhu
2020-04-16 7:41 ` [PATCH v3,1/4] powerpc: sysdev: fix compile error for fsl_85xx_l2ctlr Wang Wenhu
2020-04-16 7:41 ` [PATCH v3,2/4] powerpc: sysdev: fix compile error for fsl_85xx_cache_sram Wang Wenhu
2020-04-16 7:41 ` [PATCH v3,3/4] powerpc: sysdev: fix compile warning " Wang Wenhu
2020-04-16 7:41 ` [PATCH v3,4/4] drivers: uio: new driver " Wang Wenhu
2020-04-16 7:49 ` [PATCH v3,0/4] drivers: uio: new driver uio_fsl_85xx_cache_sram Wang Wenhu
2020-04-16 7:49 ` [PATCH v3,1/4] powerpc: sysdev: fix compile error for fsl_85xx_l2ctlr Wang Wenhu
2020-04-16 7:49 ` [PATCH v3,2/4] powerpc: sysdev: fix compile error for fsl_85xx_cache_sram Wang Wenhu
2020-04-16 7:49 ` [PATCH v3,3/4] powerpc: sysdev: fix compile warning " Wang Wenhu
2020-04-16 7:49 ` [PATCH v3,4/4] drivers: uio: new driver " Wang Wenhu
2020-04-16 9:29 ` Re:[PATCH v3,0/4] drivers: uio: new driver uio_fsl_85xx_cache_sram 王文虎
2020-04-16 10:36 ` [PATCH " Christophe Leroy
2020-04-16 11:14 ` 王文虎
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=20200416052247.112887-1-wenhu.wang@vivo.com \
--to=wenhu.wang@vivo.com \
--cc=christophe.leroy@c-s.fr \
--cc=gregkh@linuxfoundation.org \
--cc=kernel@vivo.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=mpe@ellerman.id.au \
--cc=oss@buserror.net \
/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).