linux-kernel - RE: [PATCH 5.4 064/134] ACPI: GED: add support for _Exx /

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <OSBPR01MB2983F4C32B052F1438964A93929A0@OSBPR01MB2983.jpnprd01.prod.outlook.com>
Date:   Wed, 17 Jun 2020 09:26:41 +0000
From:   <nobuhiro1.iwamatsu@...hiba.co.jp>
To:     <gregkh@...uxfoundation.org>, <linux-kernel@...r.kernel.org>
CC:     <stable@...r.kernel.org>, <ardb@...nel.org>,
        <rafael.j.wysocki@...el.com>
Subject: RE: [PATCH 5.4 064/134] ACPI: GED: add support for _Exx / _Lxx
 handler methods

Hi again,

> -----Original Message-----
> From: iwamatsu nobuhiro(岩松 信洋 □ＳＷＣ◯ＡＣＴ)
> Sent: Wednesday, June 17, 2020 6:23 PM
> To: Greg Kroah-Hartman <gregkh@...uxfoundation.org>; linux-kernel@...r.kernel.org
> Cc: stable@...r.kernel.org; Ard Biesheuvel <ardb@...nel.org>; Rafael J. Wysocki <rafael.j.wysocki@...el.com>
> Subject: RE: [PATCH 5.4 064/134] ACPI: GED: add support for _Exx / _Lxx handler methods
> 
> Hi,
> 
> > -----Original Message-----
> > From: stable-owner@...r.kernel.org [mailto:stable-owner@...r.kernel.org] On Behalf Of Greg Kroah-Hartman
> > Sent: Wednesday, June 17, 2020 12:34 AM
> > To: linux-kernel@...r.kernel.org
> > Cc: Greg Kroah-Hartman <gregkh@...uxfoundation.org>; stable@...r.kernel.org; Ard Biesheuvel <ardb@...nel.org>;
> Rafael
> > J. Wysocki <rafael.j.wysocki@...el.com>
> > Subject: [PATCH 5.4 064/134] ACPI: GED: add support for _Exx / _Lxx handler methods
> >
> > From: Ard Biesheuvel <ardb@...nel.org>
> >
> > commit ea6f3af4c5e63f6981c0b0ab8ebec438e2d5ef40 upstream.
> >
> > Per the ACPI spec, interrupts in the range [0, 255] may be handled
> > in AML using individual methods whose naming is based on the format
> > _Exx or _Lxx, where xx is the hex representation of the interrupt
> > index.
> >
> > Add support for this missing feature to our ACPI GED driver.
> >
> > Cc: v4.9+ <stable@...r.kernel.org> # v4.9+
> > Signed-off-by: Ard Biesheuvel <ardb@...nel.org>
> > Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@...el.com>
> > Signed-off-by: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
> >
> 
> This patch also requires the following patch.
> Please apply to this kernel version, 4.9, 4.14, 4.19, 5.6 and 5.7.
> 
> From e5c399b0bd6490c12c0af2a9eaa9d7cd805d52c9 Mon Sep 17 00:00:00 2001
> From: Ard Biesheuvel <ardb@...nel.org>
> Date: Wed, 27 May 2020 13:37:00 +0200

I update with the correct information.

commit e5c399b0bd6490c12c0af2a9eaa9d7cd805d52c9
Author: Ard Biesheuvel <ardb@...nel.org>
Date:   Wed May 27 13:37:00 2020 +0200

....

Best regards,
  Nobuhiro

> 
>     ACPI: GED: use correct trigger type field in _Exx / _Lxx handling
> 
>     Commit ea6f3af4c5e63f69 ("ACPI: GED: add support for _Exx / _Lxx handler
>     methods") added a reference to the 'triggering' field of either the
>     normal or the extended ACPI IRQ resource struct, but inadvertently used
>     the wrong pointer in the latter case. Note that both pointers refer to the
>     same union, and the 'triggering' field appears at the same offset in both
>     struct types, so it currently happens to work by accident. But let's fix
>     it nonetheless
> 
>     Fixes: ea6f3af4c5e63f69 ("ACPI: GED: add support for _Exx / _Lxx handler methods")
>     Signed-off-by: Ard Biesheuvel <ardb@...nel.org>
>     Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@...el.com>
> 
> Best regards,
>   Nobuhiro
> 
> > ---
> >  drivers/acpi/evged.c |   22 +++++++++++++++++++---
> >  1 file changed, 19 insertions(+), 3 deletions(-)
> >
> > --- a/drivers/acpi/evged.c
> > +++ b/drivers/acpi/evged.c
> > @@ -79,6 +79,8 @@ static acpi_status acpi_ged_request_inte
> >  	struct resource r;
> >  	struct acpi_resource_irq *p = &ares->data.irq;
> >  	struct acpi_resource_extended_irq *pext = &ares->data.extended_irq;
> > +	char ev_name[5];
> > +	u8 trigger;
> >
> >  	if (ares->type == ACPI_RESOURCE_TYPE_END_TAG)
> >  		return AE_OK;
> > @@ -87,14 +89,28 @@ static acpi_status acpi_ged_request_inte
> >  		dev_err(dev, "unable to parse IRQ resource\n");
> >  		return AE_ERROR;
> >  	}
> > -	if (ares->type == ACPI_RESOURCE_TYPE_IRQ)
> > +	if (ares->type == ACPI_RESOURCE_TYPE_IRQ) {
> >  		gsi = p->interrupts[0];
> > -	else
> > +		trigger = p->triggering;
> > +	} else {
> >  		gsi = pext->interrupts[0];
> > +		trigger = p->triggering;
> > +	}
> >
> >  	irq = r.start;
> >
> > -	if (ACPI_FAILURE(acpi_get_handle(handle, "_EVT", &evt_handle))) {
> > +	switch (gsi) {
> > +	case 0 ... 255:
> > +		sprintf(ev_name, "_%c%02hhX",
> > +			trigger == ACPI_EDGE_SENSITIVE ? 'E' : 'L', gsi);
> > +
> > +		if (ACPI_SUCCESS(acpi_get_handle(handle, ev_name, &evt_handle)))
> > +			break;
> > +		/* fall through */
> > +	default:
> > +		if (ACPI_SUCCESS(acpi_get_handle(handle, "_EVT", &evt_handle)))
> > +			break;
> > +
> >  		dev_err(dev, "cannot locate _EVT method\n");
> >  		return AE_ERROR;
> >  	}
> >