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

["Dey, Megha" <megha.dey@linux.intel.com>]

Hi Thomas,

On 4/25/2020 2:23 PM, Thomas Gleixner wrote:
> Dave Jiang <dave.jiang@intel.com> writes:
>> From: Megha Dey <megha.dey@linux.intel.com>
>> --- 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
>