Re: [PATCH v6 06/13] ACPI: resources: Add wake_capable parameter to acpi_dev_irq_flags

From: Rafael J. Wysocki
Date: Thu Sep 29 2022 - 15:38:29 EST

Next message: kernel test robot: "[driver-core:kobject-const 11/18] drivers/vdpa/vdpa_user/vduse_dev.c:1792:23: error: incompatible function pointer types assigning to 'char *(*)(const struct device *, umode_t *)' (aka 'char *(*)(const struct device *, unsigned short *)') from 'char *(struct device *, umode_t *)' (aka 'ch..."
Previous message: kernel test robot: "[mark:arm64/insn/rework-redo 14/24] ERROR: modpost: "aarch64_insn_gen_cond_branch_imm" [arch/arm64/lib/test_insn.ko] undefined!"
In reply to: Raul Rangel: "Re: [PATCH v6 06/13] ACPI: resources: Add wake_capable parameter to acpi_dev_irq_flags"
Next in thread: Raul Rangel: "Re: [PATCH v6 06/13] ACPI: resources: Add wake_capable parameter to acpi_dev_irq_flags"
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

On Thu, Sep 29, 2022 at 9:27 PM Raul Rangel <rrangel@xxxxxxxxxxxx> wrote:
>
> On Thu, Sep 29, 2022 at 1:18 PM Rafael J. Wysocki <rafael@xxxxxxxxxx> wrote:
> >
> > On Thu, Sep 29, 2022 at 6:19 PM Raul E Rangel <rrangel@xxxxxxxxxxxx> wrote:
> > >
> > > ACPI IRQ/Interrupt resources contain a bit that describes if the
> > > interrupt should wake the system. This change exposes that bit via
> > > a new IORESOURCE_IRQ_WAKECAPABLE flag. Drivers should check this flag
> >
> > I would call this IORESOURCE_IRQ_WAKE which is (a) simpler and easier
> > to read and (b) it sort of matches the "wakeirq" naming convention.
>
> It was Dmitry who originally suggested the name. I personally like the
> CAPABLE in the name. It makes it clear that it's capable of acting as
> a wake source, not to be confused with being enabled as a wake source.

Well, so be it then.

As I said elsewhere, I can apply this patch too if that's useful at this point.

> >
> > This is not a big deal if you insist on this name and for a good
> > reason, but just something I would do differently.
> >
> > The patch LGTM otherwise.
> >