linux-kernel - Re: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 for Android: free password hash cracker in your pocket

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

Message-ID: <AO6ABADMCK4udBOCpij0-KpN.3.1587107069183.Hmail.wenhu.wang@vivo.com>
Date:   Fri, 17 Apr 2020 15:04:29 +0800 (GMT+08:00)
From:   王文虎 <wenhu.wang@...o.com>
To:     Scott Wood <oss@...error.net>
Cc:     Rob Herring <robh@...nel.org>, gregkh@...uxfoundation.org,
        linux-kernel@...r.kernel.org, christophe.leroy@....fr,
        linuxppc-dev@...ts.ozlabs.org, kernel@...o.com
Subject: Re: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.
As I mentioned before, this is not currently meaningful for us, and maybe the better
way is to set it optionally for uio, but it belongs to uio core, which is a framework for
different kind of drivers or devices, but not only for us. So I guess this is not a thing
troubles and arguing about this is really helpless.

>> > > 
>> > > > +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].compa
>> tible), 0);
>> +MODULE_PARM_DESC(of_id, "platform device id to be handled by cache-sram-
>> uio");
>> +#endif
>
>No.  The point is that you wouldn't be configuring this with the device tree
>at all.
>
It was to fit for the unbinding requriement. And I mentioned what if I want to create
more than one device and each owns multiple uiomaps?
Devicetree is definitely better choice to solve the problem and make the driver more
convenient for users to use. Pseudo device is a device and a device. Or else device
tree should be hardware-only-devicetree.

The point is why we left the better choice and write a plenty of redundant codes
to parse the module parameters?

Further more, I don't think there is enough reason for the lower driver mpc85xx cache-sram
to restrict other from using it in a way of module param or dynamic allocation with ioctl or so.

UIO is there and all these parts cooperate well to make the cache-sram more useful and better
resolve user requirement.

I will update the patch with the diff applied in v5.

Thanks,
Wenhu