linux-kernel - Re: [PATCH v4,4/4] drivers: uio: new driver for fsl_85xx_cache

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <ANcAoADRCKKtO5p9r33Ll4og.3.1587090694317.Hmail.wenhu.wang@vivo.com>
Date:   Fri, 17 Apr 2020 10:31:34 +0800 (GMT+08:00)
From:   王文虎 <wenhu.wang@...o.com>
To:     Rob Herring <robh@...nel.org>
Cc:     Scott Wood <oss@...error.net>, gregkh@...uxfoundation.org,
        linux-kernel@...r.kernel.org, christophe.leroy@....fr,
        linuxppc-dev@...ts.ozlabs.org, kernel@...o.com
Subject: Re: [PATCH v4,4/4] drivers: uio: new driver for fsl_85xx_cache_sram

>> On Thu, 2020-04-16 at 08:35 -0700, Wang Wenhu wrote:
>> > +#define UIO_INFO_VER	"devicetree,pseudo"
>> 
>> What does this mean?  Changing a number into a non-obvious string (Why
>> "pseudo"?  Why does the UIO user care that the config came from the device
>> tree?) just to avoid setting off Greg's version number autoresponse isn't
>> really helping anything.
>> 
>> > +static const struct of_device_id uio_mpc85xx_l2ctlr_of_match[] = {
>> > +	{	.compatible = "uio,mpc85xx-cache-sram",	},
>
>Form is <vendor>,<device> and "uio" is not a vendor (and never will be).
>
Should have been something like "fsl,mpc85xx-cache-sram-uio", and if it is
to be defined with module parameters, this would be user defined.
Anyway, <vendor>,<device> should always be used.

>> > +	{},
>> > +};
>> > +
>> > +static struct platform_driver uio_fsl_85xx_cache_sram = {
>> > +	.probe = uio_fsl_85xx_cache_sram_probe,
>> > +	.remove = uio_fsl_85xx_cache_sram_remove,
>> > +	.driver = {
>> > +		.name = DRIVER_NAME,
>> > +		.owner = THIS_MODULE,
>> > +		.of_match_table	= uio_mpc85xx_l2ctlr_of_match,
>> > +	},
>> > +};
>> 
>> Greg's comment notwithstanding, I really don't think this belongs in the
>> device tree (and if I do get overruled on that point, it at least needs a
>> binding document).  Let me try to come up with a patch for dynamic allocation.
>
>Agreed. "UIO" bindings have long been rejected.
>
Sounds it is. And does the modification below fit well?
---
-static const struct of_device_id uio_mpc85xx_l2ctlr_of_match[] = {
-       {       .compatible = "uio,mpc85xx-cache-sram", },
-       {},
+#ifdef CONFIG_OF
+static struct of_device_id uio_fsl_85xx_cache_sram_of_match[] = {
+       { /* This is filled with module_parm */ },
+       { /* Sentinel */ },
 };
+MODULE_DEVICE_TABLE(of, uio_fsl_85xx_cache_sram_of_match);
+module_param_string(of_id, uio_fsl_85xx_cache_sram_of_match[0].compatible,
+                           sizeof(uio_fsl_85xx_cache_sram_of_match[0].compatible), 0);
+MODULE_PARM_DESC(of_id, "platform device id to be handled by cache-sram-uio");
+#endif
 
 static struct platform_driver uio_fsl_85xx_cache_sram = {
        .probe = uio_fsl_85xx_cache_sram_probe,
        .remove = uio_fsl_85xx_cache_sram_remove,
        .driver = {
                .name = DRIVER_NAME,
-               .owner = THIS_MODULE,
-               .of_match_table = uio_mpc85xx_l2ctlr_of_match,
+               .of_match_table = of_match_ptr(uio_fsl_85xx_cache_sram_of_match),
        },
 };

Regards,
Wenhu