Messages in this thread | | | Date | Fri, 24 Feb 2023 18:36:30 +0200 | From | Andy Shevchenko <> | 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
| |