[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Y/jnjivxoIefKzlx@smile.fi.intel.com>
Date: Fri, 24 Feb 2023 18:36:30 +0200
From: Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
To: William Breathitt Gray <william.gray@...aro.org>
Cc: Mark Brown <broonie@...nel.org>,
Aidan MacDonald <aidanmacdonald.0x0@...il.com>,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 1/1] regmap-irq: Place kernel doc of struct
regmap_irq_chip in order
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
Powered by blists - more mailing lists