Re: [PATCH RFC 03/15] drivers/base: Allocate/free platform-msi interrupts by group

[Dey, Megha]

Hi Thomas,

On 4/25/2020 2:23 PM, Thomas Gleixner wrote:
> Dave Jiang <dave.jiang@xxxxxxxxx> writes:
> > From: Megha Dey <megha.dey@xxxxxxxxxxxxxxx>
> > --- a/include/linux/msi.h
> > +++ b/include/linux/msi.h
> > @@ -135,6 +135,12 @@ enum platform_msi_type {
> >   	GEN_PLAT_MSI = 1,
> >   };
> >   
> > +struct platform_msi_group_entry {
> > +	unsigned int group_id;
> > +	struct list_head group_list;
> > +	struct list_head entry_list;
>
> I surely told you before that struct members want to be written tabular.

yep, you surely did :) I will use tabs henceforth!
> > +};
> > +
> >   /* Helpers to hide struct msi_desc implementation details */
> >   #define msi_desc_to_dev(desc)		((desc)->dev)
> >   #define dev_to_msi_list(dev)		(&(dev)->msi_list)
> > @@ -145,21 +151,31 @@ enum platform_msi_type {
> >   #define for_each_msi_entry_safe(desc, tmp, dev)	\
> >   	list_for_each_entry_safe((desc), (tmp), dev_to_msi_list((dev)), list)
> >   
> > -#define dev_to_platform_msi_list(dev)	(&(dev)->platform_msi_list)
> > -#define first_platform_msi_entry(dev)		\
> > -	list_first_entry(dev_to_platform_msi_list((dev)), struct msi_desc, list)
> > -#define for_each_platform_msi_entry(desc, dev)	\
> > -	list_for_each_entry((desc), dev_to_platform_msi_list((dev)), list)
> > -#define for_each_platform_msi_entry_safe(desc, tmp, dev)	\
> > -	list_for_each_entry_safe((desc), (tmp), dev_to_platform_msi_list((dev)), list)
> > +#define dev_to_platform_msi_group_list(dev)    (&(dev)->platform_msi_list)
> > +
> > +#define first_platform_msi_group_entry(dev)				\
> > +	list_first_entry(dev_to_platform_msi_group_list((dev)),		\
> > +			 struct platform_msi_group_entry, group_list)
> >   
> > -#define first_msi_entry_common(dev)	\
> > -	list_first_entry_select((dev)->platform_msi_type, dev_to_platform_msi_list((dev)),	\
> > +#define platform_msi_current_group_entry_list(dev)			\
> > +	(&((list_last_entry(dev_to_platform_msi_group_list((dev)),	\
> > +			    struct platform_msi_group_entry,		\
> > +			    group_list))->entry_list))
> > +
> > +#define first_msi_entry_current_group(dev)				\
> > +	list_first_entry_select((dev)->platform_msi_type,		\
> > +				platform_msi_current_group_entry_list((dev)),	\
> >   				dev_to_msi_list((dev)), struct msi_desc, list)
> >   
> > -#define for_each_msi_entry_common(desc, dev)	\
> > -	list_for_each_entry_select((dev)->platform_msi_type, desc, dev_to_platform_msi_list((dev)), \
> > -				   dev_to_msi_list((dev)), list)	\
> > +#define for_each_msi_entry_current_group(desc, dev)			\
> > +	list_for_each_entry_select((dev)->platform_msi_type, desc,	\
> > +				   platform_msi_current_group_entry_list((dev)),\
> > +				   dev_to_msi_list((dev)), list)
> > +
> > +#define for_each_platform_msi_entry_in_group(desc, platform_msi_group, group, dev)	\
> > +	list_for_each_entry((platform_msi_group), dev_to_platform_msi_group_list((dev)), group_list)	\
> > +		if (((platform_msi_group)->group_id) == (group))			\
> > +			list_for_each_entry((desc), (&(platform_msi_group)->entry_list), list)
>
> Yet more unreadable macro maze to obfuscate what the code is actually
> doing.

hmm I will i guess add some more documentation either in the commit 
message or somewhere in documentation to make it clearer about the 
purpose of these macros.

> >   /* When an MSI domain is used as an intermediate domain */
> >   int msi_domain_prepare_irqs(struct irq_domain *domain, struct device *dev,
> > diff --git a/kernel/irq/msi.c b/kernel/irq/msi.c
> > index bc5f9e32387f..899ade394ec8 100644
> > --- a/kernel/irq/msi.c
> > +++ b/kernel/irq/msi.c
> > @@ -320,7 +320,7 @@ int msi_domain_populate_irqs(struct irq_domain *domain, struct device *dev,
> >   	struct msi_desc *desc;
> >   	int ret = 0;
> >   
> > -	for_each_msi_entry_common(desc, dev) {
> > +	for_each_msi_entry_current_group(desc, dev) {
>
> How is anyone supposed to figure out what the heck this means without
> going through several layers of macro maze and some magic type/group
> storage in struct device?

Point noted. I think I am better off committing smaller logical changes 
in each patch.

> Again, function arguments exist for a reason.

ok makes sense, I will do this in the next version.

> Thanks,
>
>          tglx