Re: [PATCH v2 1/1] regmap-irq: Place kernel doc of struct regmap_irq_chip in order

[Andy Shevchenko]

On Wed, Feb 22, 2023 at 02:24:55PM -0500, William Breathitt Gray wrote:
> On Fri, Feb 24, 2023 at 05:01:09PM +0200, Andy Shevchenko wrote:
> > On Wed, Feb 22, 2023 at 12:46:05PM -0500, William Breathitt Gray wrote:
> > > On Thu, Feb 23, 2023 at 08:52:36PM +0200, Andy Shevchenko wrote:
> > > > On Wed, Feb 22, 2023 at 11:43:28AM -0500, William Breathitt Gray wrote:
> > > > > On Mon, Feb 20, 2023 at 05:33:34PM +0200, Andy Shevchenko wrote:
> > > > > >  	unsigned int use_ack:1;
> > > > > >  	unsigned int ack_invert:1;
> > > > > >  	unsigned int clear_ack:1;
> > > > > > +	unsigned int status_invert:1;
> > > > > >  	unsigned int wake_invert:1;
> > > > > > -	unsigned int runtime_pm:1;
> > > > > >  	unsigned int type_in_mask:1;
> > > > > >  	unsigned int clear_on_unmask:1;
> > > > > > +	unsigned int runtime_pm:1;
> > > > > >  	unsigned int not_fixed_stride:1;
> > > > > > -	unsigned int status_invert:1;
> > > > > 
> > > > > These don't look alphabetical, so what is the order for these?
> > > > 
> > > > Nope, the order is to follow:
> > > > a) kernel doc
> > > > b) semantics of each of the groups
> > > > 
> > > > Do you think the order can be improved? Can you point out how?
> > > 
> > > No, I don't have any particular improvement suggestions, I'm just want
> > > to understand the current order for when I introduce something new here
> > > (e.g. no_status). If I understand correctly, status_invert was moved up
> > > to be with the other "*_invert" flags,
> > 
> > As far as I read these there are IRQ related flags, and some others.
> 
> Okay, that makes sense to me too.
> 
> > > but why was runtime_pm moved
> > > to above not_fixed_stride rather than below it?
> > 
> > Do you think that not_fixed_stride belongs to "*mask" group?
> 
> However, I don't think runtime_pm belongs to a "*mask" group either
> because it's a lock for power management if I'm not mistaken. So if we
> can move runtime_pm below not_fixed_stride then we can avoid the
> respective runtime_pm kernel doc line move which makes the diff for this
> patch slightly simpler.

Good point! I will address this in v3.


-- 
With Best Regards,
Andy Shevchenko