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]
Date: Mon, 20 Nov 2023 10:20:13 +0100
From: Krzysztof Kozlowski <krzk@...nel.org>
To: Luiz Angelo Daros de Luca <luizluca@...il.com>, netdev@...r.kernel.org
Cc: linus.walleij@...aro.org, alsi@...g-olufsen.dk, andrew@...n.ch,
 f.fainelli@...il.com, olteanv@...il.com, davem@...emloft.net,
 edumazet@...gle.com, kuba@...nel.org, pabeni@...hat.com,
 arinc.unal@...nc9.com
Subject: Re: [net-next 2/2] net: dsa: realtek: load switch variants on demand

On 18/11/2023 00:50, Luiz Angelo Daros de Luca wrote:
> realtek-common had a hard dependency on both switch variants. As a
> result, it was not possible to selectively load only one model at
> runtime. Now, variants are registered in the realtek-common module, and
> interface modules look for a variant using the compatible string.

...

> diff --git a/drivers/net/dsa/realtek/realtek-common.h b/drivers/net/dsa/realtek/realtek-common.h
> index 90a949386518..6de4991d8b5c 100644
> --- a/drivers/net/dsa/realtek/realtek-common.h
> +++ b/drivers/net/dsa/realtek/realtek-common.h
> @@ -5,6 +5,37 @@
>  
>  #include <linux/regmap.h>
>  
> +struct realtek_variant_entry {
> +	const struct realtek_variant *variant;
> +	const char *compatible;
> +	struct module *owner;
> +	struct list_head list;
> +};
> +
> +#define module_realtek_variant(__variant, __compatible)			\
> +static struct realtek_variant_entry __variant ## _entry = {		\
> +	.compatible = __compatible,					\
> +	.variant = &(__variant),					\
> +	.owner = THIS_MODULE,						\
> +};									\
> +static int __init realtek_variant_module_init(void)			\
> +{									\
> +	realtek_variant_register(&__variant ## _entry);			\
> +	return 0;							\
> +}									\
> +module_init(realtek_variant_module_init)				\
> +									\
> +static void __exit realtek_variant_module_exit(void)			\
> +{									\
> +	realtek_variant_unregister(&__variant ## _entry);		\
> +}									\
> +module_exit(realtek_variant_module_exit);				\
> +									\
> +MODULE_ALIAS(__compatible)

No, why do you need it? You should not need MODULE_ALIAS() in normal
cases. If you need it, usually it means your device ID table is wrong
(e.g. misses either entries or MODULE_DEVICE_TABLE()). MODULE_ALIAS() is
not a substitute for incomplete ID table.

Entire abstraction/macro is pointless and make the code less readable.


Best regards,
Krzysztof


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ