[{"id":3687000,"web_url":"http://patchwork.ozlabs.org/comment/3687000/","msgid":"<20260506113215.GK6785@black.igk.intel.com>","list_archive_url":null,"date":"2026-05-06T11:32:15","subject":"Re: [PATCH] gpio: acpi: modernize resource management using cleanup.h","submitter":{"id":14534,"url":"http://patchwork.ozlabs.org/api/people/14534/","name":"Mika Westerberg","email":"mika.westerberg@linux.intel.com"},"content":"Hi.\n\n+Andy\n\nOn Wed, May 06, 2026 at 11:29:36AM +0200, Marco Scardovi wrote:\n> Hi everyone,\n> \n> I was looking for ways to switch to modern cleanup guards and auto-freeing\n> pointers to simplify error paths and synchronization in gpiolib-acpi-core.c\n> so I came up with the patch you can find below.\n> \n> Here you can see the main points I've worked on:\n> - Use DEFINE_FREE() for gpio_desc and ACPI resources.\n> - Use guard(mutex)() within the OpRegion handler loop for automatic locking.\n> - Use __free() for automatic descriptor and memory cleanup.\n> - Fix off-by-one error in GPIO pin bounds check.\n> - Return AE_OK on out-of-range pins to allow processing other resources\n>   even if one is misconfigured in firmware.\n> - Use break instead of goto in OpRegion handler for cleaner control flow\n>   leveraging auto-cleanup.\n\nThat should be several patches not one doing all these.\n\n> I've tested it (both build and functionality) against linux-next-20260430.\n> \n> Signed-off-by: Marco Scardovi \n> ---\n>  drivers/gpio/gpiolib-acpi-core.c | 94\n> +++++++++++++++++++---------------------\n>  1 file changed, 43 insertions(+), 51 deletions(-)\n> \n> diff --git a/drivers/gpio/gpiolib-acpi-core.c\n> b/drivers/gpio/gpiolib-acpi-core.c\n> index eb8a40cfb7a9..19a18222b7b2 100644\n> --- a/drivers/gpio/gpiolib-acpi-core.c\n> +++ b/drivers/gpio/gpiolib-acpi-core.c\n> @@ -7,6 +7,9 @@\n>   *          Mika Westerberg \n>   */\n> \n> +#include \n> +#include \n> +\n\nDrop the empty line.\n\n>  #include \n>  #include \n>  #include \n> @@ -23,6 +26,16 @@\n>  #include \"gpiolib.h\"\n>  #include \"gpiolib-acpi.h\"\n> \n> +DEFINE_FREE(free_gpio_desc, struct gpio_desc *, {\n> +    if (_T)\n> +        gpiochip_free_own_desc(_T);\n> +})\n> +\n> +DEFINE_FREE(acpi_free, void *, {\n> +    if (_T)\n> +        ACPI_FREE(_T);\n> +})\n\nThese are white space damaged. Also I'm not big fan of these but if Andy is\nfine then works for me too. However, please test with KASAN and kmemleak\nenabled that you don't break anything.\n\n> +\n>  /**\n>   * struct acpi_gpio_event - ACPI GPIO event handler data\n>   *\n> @@ -361,6 +374,7 @@ static acpi_status acpi_gpiochip_alloc_event(struct\n> acpi_resource *ares,\n>      struct acpi_gpio_event *event;\n>      irq_handler_t handler = NULL;\n>      struct gpio_desc *desc;\n> +    struct gpio_desc *desc_guard __free(free_gpio_desc) = NULL;\n>      unsigned int pin;\n>      int ret, irq;\n> \n> @@ -370,6 +384,11 @@ static acpi_status acpi_gpiochip_alloc_event(struct\n> acpi_resource *ares,\n>      handle = ACPI_HANDLE(chip->parent);\n>      pin = agpio->pin_table[0];\n> \n> +    if (pin >= chip->ngpio) {\n> +        dev_err(chip->parent, \"Failed to request GPIO for pin 0x%04X, out\n> of range\\n\", pin);\n\nThis is damaged too.\n\nActually let's start with a proper patch and then look the details :)\n\n> +        return AE_OK;\n> +    }\n> +\n>      if (pin <= 255) {\n>          char ev_name[8];\n>          sprintf(ev_name, \"_%c%02X\",\n> @@ -392,31 +411,26 @@ static acpi_status acpi_gpiochip_alloc_event(struct\n> acpi_resource *ares,\n> \n>      desc = acpi_request_own_gpiod(chip, agpio, 0, \"ACPI:Event\");\n>      if (IS_ERR(desc)) {\n> -        dev_err(chip->parent,\n> -            \"Failed to request GPIO for pin 0x%04X, err %pe\\n\",\n> -            pin, desc);\n> +        dev_err(chip->parent, \"Failed to request GPIO for pin 0x%04X, err\n> %pe\\n\", pin, desc);\n>          return AE_OK;\n>      }\n> +    desc_guard = desc;\n> \n>      ret = gpiochip_lock_as_irq(chip, pin);\n>      if (ret) {\n> -        dev_err(chip->parent,\n> -            \"Failed to lock GPIO pin 0x%04X as interrupt, err %d\\n\",\n> -            pin, ret);\n> -        goto fail_free_desc;\n> +        dev_err(chip->parent, \"Failed to lock GPIO pin 0x%04X as interrupt,\n> err %d\\n\", pin, ret);\n> +        return AE_OK;\n>      }\n> \n>      irq = gpiod_to_irq(desc);\n>      if (irq < 0) {\n> -        dev_err(chip->parent,\n> -            \"Failed to translate GPIO pin 0x%04X to IRQ, err %d\\n\",\n> -            pin, irq);\n> -        goto fail_unlock_irq;\n> +        dev_err(chip->parent, \"Failed to translate GPIO pin 0x%04X to IRQ,\n> err %d\\n\", pin, irq);\n> +        goto err_unlock;\n>      }\n> \n>      event = kzalloc_obj(*event);\n>      if (!event)\n> -        goto fail_unlock_irq;\n> +        goto err_unlock;\n> \n>      event->irqflags = IRQF_ONESHOT;\n>      if (agpio->triggering == ACPI_LEVEL_SENSITIVE) {\n> @@ -444,17 +458,15 @@ static acpi_status acpi_gpiochip_alloc_event(struct\n> acpi_resource *ares,\n>      event->irq = irq;\n>      event->irq_is_wake = acpi_gpio_irq_is_wake(chip->parent, agpio);\n>      event->pin = pin;\n> -    event->desc = desc;\n> +    /* Transfer ownership to event, prevent auto-free */\n> +    event->desc = no_free_ptr(desc_guard);\n> \n>      list_add_tail(&event->node, &acpi_gpio->events);\n> \n>      return AE_OK;\n> \n> -fail_unlock_irq:\n> +err_unlock:\n>      gpiochip_unlock_as_irq(chip, pin);\n> -fail_free_desc:\n> -    gpiochip_free_own_desc(desc);\n> -\n>      return AE_OK;\n>  }\n> \n> @@ -1086,7 +1098,7 @@ acpi_gpio_adr_space_handler(u32 function,\n> acpi_physical_address address,\n>      struct acpi_gpio_chip *achip = region_context;\n>      struct gpio_chip *chip = achip->chip;\n>      struct acpi_resource_gpio *agpio;\n> -    struct acpi_resource *ares;\n> +    struct acpi_resource *ares __free(acpi_free) = NULL;\n>      u16 pin_index = address;\n>      acpi_status status;\n>      int length;\n> @@ -1097,20 +1109,17 @@ acpi_gpio_adr_space_handler(u32 function,\n> acpi_physical_address address,\n>      if (ACPI_FAILURE(status))\n>          return status;\n> \n> -    if (WARN_ON(ares->type != ACPI_RESOURCE_TYPE_GPIO)) {\n> -        ACPI_FREE(ares);\n> +    if (WARN_ON(ares->type != ACPI_RESOURCE_TYPE_GPIO))\n>          return AE_BAD_PARAMETER;\n> -    }\n> \n>      agpio = &ares->data.gpio;\n> \n>      if (WARN_ON(agpio->io_restriction == ACPI_IO_RESTRICT_INPUT &&\n> -        function == ACPI_WRITE)) {\n> -        ACPI_FREE(ares);\n> +        function == ACPI_WRITE))\n>          return AE_BAD_PARAMETER;\n> -    }\n> \n>      length = min(agpio->pin_table_length, pin_index + bits);\n> +    status = AE_OK;\n>      for (i = pin_index; i < length; ++i) {\n>          unsigned int pin = agpio->pin_table[i];\n>          struct acpi_gpio_connection *conn;\n> @@ -1118,7 +1127,7 @@ acpi_gpio_adr_space_handler(u32 function,\n> acpi_physical_address address,\n>          u16 word, shift;\n>          bool found;\n> \n> -        mutex_lock(&achip->conn_lock);\n> +        guard(mutex)(&achip->conn_lock);\n> \n>          found = false;\n>          list_for_each_entry(conn, &achip->conns, node) {\n> @@ -1150,17 +1159,15 @@ acpi_gpio_adr_space_handler(u32 function,\n> acpi_physical_address address,\n>          if (!found) {\n>              desc = acpi_request_own_gpiod(chip, agpio, i, \"ACPI:OpRegion\");\n>              if (IS_ERR(desc)) {\n> -                mutex_unlock(&achip->conn_lock);\n>                  status = AE_ERROR;\n> -                goto out;\n> +                break;\n>              }\n> \n>              conn = kzalloc_obj(*conn);\n>              if (!conn) {\n>                  gpiochip_free_own_desc(desc);\n> -                mutex_unlock(&achip->conn_lock);\n>                  status = AE_NO_MEMORY;\n> -                goto out;\n> +                break;\n>              }\n> \n>              conn->pin = pin;\n> @@ -1168,8 +1175,6 @@ acpi_gpio_adr_space_handler(u32 function,\n> acpi_physical_address address,\n>              list_add_tail(&conn->node, &achip->conns);\n>          }\n> \n> -        mutex_unlock(&achip->conn_lock);\n> -\n>          /*\n>           * For the cases when OperationRegion() consists of more than\n>           * 64 bits calculate the word and bit shift to use that one to\n> @@ -1188,8 +1193,6 @@ acpi_gpio_adr_space_handler(u32 function,\n> acpi_physical_address address,\n>          }\n>      }\n> \n> -out:\n> -    ACPI_FREE(ares);\n>      return status;\n>  }\n>","headers":{"Return-Path":"\n ","X-Original-To":["incoming@patchwork.ozlabs.org","linux-gpio@vger.kernel.org"],"Delivered-To":"patchwork-incoming@legolas.ozlabs.org","Authentication-Results":["legolas.ozlabs.org;\n\tdkim=pass (2048-bit key;\n unprotected) header.d=intel.com header.i=@intel.com header.a=rsa-sha256\n header.s=Intel header.b=N/yd5YKL;\n\tdkim-atps=neutral","legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=vger.kernel.org\n (client-ip=172.234.253.10; helo=sea.lore.kernel.org;\n envelope-from=linux-gpio+bounces-36280-incoming=patchwork.ozlabs.org@vger.kernel.org;\n receiver=patchwork.ozlabs.org)","smtp.subspace.kernel.org;\n\tdkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com\n header.b=\"N/yd5YKL\"","smtp.subspace.kernel.org;\n arc=none smtp.client-ip=198.175.65.12","smtp.subspace.kernel.org;\n dmarc=pass (p=none dis=none) header.from=linux.intel.com","smtp.subspace.kernel.org;\n spf=pass smtp.mailfrom=linux.intel.com"],"Received":["from sea.lore.kernel.org (sea.lore.kernel.org [172.234.253.10])\n\t(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n\t key-exchange x25519)\n\t(No client certificate requested)\n\tby legolas.ozlabs.org (Postfix) with ESMTPS id 4g9YCc6kGnz1y04\n\tfor ; Wed, 06 May 2026 21:33:00 +1000 (AEST)","from smtp.subspace.kernel.org (conduit.subspace.kernel.org\n [100.90.174.1])\n\tby sea.lore.kernel.org (Postfix) with ESMTP id B4738302571F\n\tfor ; Wed, 6 May 2026 11:32:22 +0000 (UTC)","from localhost.localdomain (localhost.localdomain [127.0.0.1])\n\tby smtp.subspace.kernel.org (Postfix) with ESMTP id 22C69429819;\n\tWed, 6 May 2026 11:32:21 +0000 (UTC)","from mgamail.intel.com (mgamail.intel.com [198.175.65.12])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))\n\t(No client certificate requested)\n\tby smtp.subspace.kernel.org (Postfix) with ESMTPS id 76644313543;\n\tWed, 6 May 2026 11:32:18 +0000 (UTC)","from fmviesa006.fm.intel.com ([10.60.135.146])\n by orvoesa104.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384;\n 06 May 2026 04:32:18 -0700","from black.igk.intel.com ([10.91.253.5])\n by fmviesa006.fm.intel.com with ESMTP; 06 May 2026 04:32:16 -0700","by black.igk.intel.com (Postfix, from userid 1001)\n\tid 1EC3595; Wed, 06 May 2026 13:32:15 +0200 (CEST)"],"ARC-Seal":"i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;\n\tt=1778067140; cv=none;\n b=lHvVFvma2o6R3T44WOGoomeUZzIU8/Ccr6F7x0GbEu/iABp0L9cqPhV32/WLX3ssi0GjVXwVg+a0tisG1GM8AV2GVw1eNrYRAgjgh34jz8wuEMkJZAOG4XZ0lzG6z8B2tWRFSdcxYyTuLcU/eLLNUbF86b9hzhSNdjK6nz2CLvI=","ARC-Message-Signature":"i=1; a=rsa-sha256; d=subspace.kernel.org;\n\ts=arc-20240116; t=1778067140; c=relaxed/simple;\n\tbh=O6TF3HsWcTy6sdh8ERgaGEDnfbxo5JycHdzco+fV99Q=;\n\th=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version:\n\t Content-Type:Content-Disposition:In-Reply-To;\n b=r+IlvOw5TavIGw1ISXEKXfdkQFd2Zu8292MM1VYXde/dEKkE1Ajoxj0D9yfiVT2qgqdMQFbTmD8mRLr6An9k8cZoP53XjL/7/Q9CKVwTzQNGeHIbqz9U+DP8UR+eGz9m07/zSFM85Zevvxx385R7Qe57iI1M71/KCtS8IsT8oew=","ARC-Authentication-Results":"i=1; smtp.subspace.kernel.org;\n dmarc=pass (p=none dis=none) header.from=linux.intel.com;\n spf=pass smtp.mailfrom=linux.intel.com;\n dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com\n header.b=N/yd5YKL; arc=none smtp.client-ip=198.175.65.12","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/simple;\n d=intel.com; i=@intel.com; q=dns/txt; s=Intel;\n t=1778067139; x=1809603139;\n h=date:from:to:cc:subject:message-id:references:\n mime-version:content-transfer-encoding:in-reply-to;\n bh=O6TF3HsWcTy6sdh8ERgaGEDnfbxo5JycHdzco+fV99Q=;\n b=N/yd5YKL4rmRwtBSWP2g4EKXH9VmLjzvKMXjJZrpjYhA4m+JfGQLqjQ3\n RkLgX6DpYvYEkeqlS8ZNmBeK31V0ifaVCuntGFf/OgTYpGDvflIDc1pga\n pICdHmcQF8QrKdkpvLHsPde+Tzhr67AZCjc7aZLaemoWmuHNDXFTlkx2x\n fUyxzjefOIRCWSi6YP9NEst4/8xuqA4coChShZcFET9v29IYP0b+HrmcK\n TtQWZJVFlN1zrXG6YJGcNe3yIi15GB92iMEeAKbeZHjsG9c4lkrZSzjDH\n a94egeXC2uoZw8O/vzeYhaJSwCZEndYz1UCZme2QxyurVHdPDYFF9JfXj\n w==;","X-CSE-ConnectionGUID":["I80yiqw3TKKTD0zIPruOjQ==","I0uO+rMCQnWeXhjzshuPZg=="],"X-CSE-MsgGUID":["sBaMIdCgTqmtcKnQ6ZyuhA==","2eQO0X2DT4Ke8O30NSNBWQ=="],"X-IronPort-AV":["E=McAfee;i=\"6800,10657,11777\"; a=\"90451370\"","E=Sophos;i=\"6.23,219,1770624000\";\n d=\"scan'208\";a=\"90451370\"","E=Sophos;i=\"6.23,219,1770624000\";\n d=\"scan'208\";a=\"231568222\""],"X-ExtLoop1":"1","Date":"Wed, 6 May 2026 13:32:15 +0200","From":"Mika Westerberg ","To":"Marco Scardovi ","Cc":"mathias.nyman@linux.intel.com, linux-gpio@vger.kernel.org,\n\tlinux-acpi@vger.kernel.org, linux-kernel@vger.kernel.org,\n\tAndy Shevchenko ","Subject":"Re: [PATCH] gpio: acpi: modernize resource management using cleanup.h","Message-ID":"<20260506113215.GK6785@black.igk.intel.com>","References":"<59174ed2-dc3a-4891-929f-bf513deecdc2@gmail.com>","Precedence":"bulk","X-Mailing-List":"linux-gpio@vger.kernel.org","List-Id":"","List-Subscribe":"","List-Unsubscribe":"","MIME-Version":"1.0","Content-Type":"text/plain; charset=utf-8","Content-Disposition":"inline","Content-Transfer-Encoding":"8bit","In-Reply-To":"<59174ed2-dc3a-4891-929f-bf513deecdc2@gmail.com>"}},{"id":3687054,"web_url":"http://patchwork.ozlabs.org/comment/3687054/","msgid":"","list_archive_url":null,"date":"2026-05-06T12:46:13","subject":"Re: [PATCH] gpio: acpi: modernize resource management using cleanup.h","submitter":{"id":8583,"url":"http://patchwork.ozlabs.org/api/people/8583/","name":"Andy Shevchenko","email":"andriy.shevchenko@linux.intel.com"},"content":"On Wed, May 06, 2026 at 01:32:15PM +0200, Mika Westerberg wrote:\n\n> +Andy\n\nThanks for Cc'ing me. Marco, you have to follow the MAINTAINERS database when\nsubmitting this. For simplicity you may use my \"smart\" script [1] that does\nalmost right (it still uses heuristics but nobody complained so far) the Cc\nlists.\n\n\n> On Wed, May 06, 2026 at 11:29:36AM +0200, Marco Scardovi wrote:\n> > \n> > I was looking for ways to switch to modern cleanup guards and auto-freeing\n> > pointers to simplify error paths and synchronization in gpiolib-acpi-core.c\n> > so I came up with the patch you can find below.\n> > \n> > Here you can see the main points I've worked on:\n> > - Use DEFINE_FREE() for gpio_desc and ACPI resources.\n> > - Use guard(mutex)() within the OpRegion handler loop for automatic locking.\n> > - Use __free() for automatic descriptor and memory cleanup.\n> > - Fix off-by-one error in GPIO pin bounds check.\n> > - Return AE_OK on out-of-range pins to allow processing other resources\n> >   even if one is misconfigured in firmware.\n> > - Use break instead of goto in OpRegion handler for cleaner control flow\n> >   leveraging auto-cleanup.\n> \n> That should be several patches not one doing all these.\n\nAs Mika said, please, split this to the per-logical change series.\n\n> > I've tested it (both build and functionality) against linux-next-20260430.\n\nThis is assumed, but you can put that into the cover letter.\n\n> > Signed-off-by: Marco Scardovi \n\n...\n\n> > +#include \n> > +#include \n> > +\n> \n> Drop the empty line.\n\nAnd follow the existing order.\n\n...\n\n> > +DEFINE_FREE(free_gpio_desc, struct gpio_desc *, {\n> > +    if (_T)\n> > +        gpiochip_free_own_desc(_T);\n> > +})\n> > +\n> > +DEFINE_FREE(acpi_free, void *, {\n> > +    if (_T)\n> > +        ACPI_FREE(_T);\n> > +})\n\n> These are white space damaged. Also I'm not big fan of these but if Andy is\n> fine then works for me too. However, please test with KASAN and kmemleak\n> enabled that you don't break anything.\n\nThey are fine, but:\n\n- they need to be just one liner as it's done elsewhere\n- the {} are redundant (see existing examples)\n- they need to be added per subsystem to their headers\n\n(so, two more patches on top of whatever this one has to be split to for\n different subsystems).\n\n...\n\n> >      struct acpi_gpio_event *event;\n> >      irq_handler_t handler = NULL;\n> >      struct gpio_desc *desc;\n> > +    struct gpio_desc *desc_guard __free(free_gpio_desc) = NULL;\n\nThis way of defining is highly discouraged. See below.\n\n> >      desc = acpi_request_own_gpiod(chip, agpio, 0, \"ACPI:Event\");\n\nThis one should be used otherwise as\n\n\tstruct gpio_desc *desc __free(free_gpio_desc) =\n\t\tacpi_request_own_gpiod(chip, agpio, 0, \"ACPI:Event\");\n\n...\n\n> > -    struct acpi_resource *ares;\n> > +    struct acpi_resource *ares __free(acpi_free) = NULL;\n\nAs per above.\n\n...\n\n[1]: https://github.com/andy-shev/home-bin-tools/blob/master/ge2maintainer.sh","headers":{"Return-Path":"\n ","X-Original-To":["incoming@patchwork.ozlabs.org","linux-gpio@vger.kernel.org"],"Delivered-To":"patchwork-incoming@legolas.ozlabs.org","Authentication-Results":["legolas.ozlabs.org;\n\tdkim=pass (2048-bit key;\n unprotected) header.d=intel.com header.i=@intel.com header.a=rsa-sha256\n header.s=Intel header.b=RQ98ZRrD;\n\tdkim-atps=neutral","legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=vger.kernel.org\n (client-ip=2600:3c04:e001:36c::12fc:5321; helo=tor.lore.kernel.org;\n envelope-from=linux-gpio+bounces-36287-incoming=patchwork.ozlabs.org@vger.kernel.org;\n receiver=patchwork.ozlabs.org)","smtp.subspace.kernel.org;\n\tdkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com\n header.b=\"RQ98ZRrD\"","smtp.subspace.kernel.org;\n arc=none smtp.client-ip=192.198.163.16","smtp.subspace.kernel.org;\n dmarc=pass (p=none dis=none) header.from=linux.intel.com","smtp.subspace.kernel.org;\n spf=pass smtp.mailfrom=linux.intel.com"],"Received":["from tor.lore.kernel.org (tor.lore.kernel.org\n [IPv6:2600:3c04:e001:36c::12fc:5321])\n\t(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n\t key-exchange x25519 server-signature ECDSA (secp384r1) server-digest SHA384)\n\t(No client certificate requested)\n\tby legolas.ozlabs.org (Postfix) with ESMTPS id 4g9b073zSjz1yJq\n\tfor ; Wed, 06 May 2026 22:53:11 +1000 (AEST)","from smtp.subspace.kernel.org (conduit.subspace.kernel.org\n [100.90.174.1])\n\tby tor.lore.kernel.org (Postfix) with ESMTP id D0FBA30B1736\n\tfor ; Wed, 6 May 2026 12:46:55 +0000 (UTC)","from localhost.localdomain (localhost.localdomain [127.0.0.1])\n\tby smtp.subspace.kernel.org (Postfix) with ESMTP id 021D34418D7;\n\tWed, 6 May 2026 12:46:42 +0000 (UTC)","from mgamail.intel.com (mgamail.intel.com [192.198.163.16])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))\n\t(No client certificate requested)\n\tby smtp.subspace.kernel.org (Postfix) with ESMTPS id 202E844E04A;\n\tWed, 6 May 2026 12:46:30 +0000 (UTC)","from fmviesa006.fm.intel.com ([10.60.135.146])\n by fmvoesa110.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384;\n 06 May 2026 05:46:27 -0700","from abityuts-desk.ger.corp.intel.com (HELO localhost)\n ([10.245.244.183])\n by fmviesa006-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384;\n 06 May 2026 05:46:16 -0700"],"ARC-Seal":"i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;\n\tt=1778071597; cv=none;\n b=drDLNL+9LZ7EW8lLQaFANccKWBpI0BNOuR3yOF5ic9SoJlcN9lsh9WfXvRQgoDiHbQ/skBv0RLYKpKmvy1dDBf5lxeGuI0hky+VgDdMshQsx72E3GUL8o5r6ix6+8tNW+q8nBoXNTx8DRFUmdGMOGXhHuRhLh5vGdkFc/PP1MIo=","ARC-Message-Signature":"i=1; a=rsa-sha256; d=subspace.kernel.org;\n\ts=arc-20240116; t=1778071597; c=relaxed/simple;\n\tbh=8M1mhUauXKWE6wfQQYzDfLESAaqJoCkxK+U36T05No8=;\n\th=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version:\n\t Content-Type:Content-Disposition:In-Reply-To;\n b=RhDASf/xBYpbCCK+KpbVCkIW3KQhU/ILTA60jV/9BE9bfjWjf6g8GiFTJxnXGXnz9MzmfRQOQe9WnRMTzw2XOoXlNOlXOS88MgP8GBXZE5n3YnCigVvEYGo5gxByKg1CbNg0YldbVTuFinLEZLVJfICiCL6Hoi4BzOurfl60uJ0=","ARC-Authentication-Results":"i=1; smtp.subspace.kernel.org;\n dmarc=pass (p=none dis=none) header.from=linux.intel.com;\n spf=pass smtp.mailfrom=linux.intel.com;\n dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com\n header.b=RQ98ZRrD; arc=none smtp.client-ip=192.198.163.16","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/simple;\n d=intel.com; i=@intel.com; q=dns/txt; s=Intel;\n t=1778071592; x=1809607592;\n h=date:from:to:cc:subject:message-id:references:\n mime-version:content-transfer-encoding:in-reply-to;\n bh=8M1mhUauXKWE6wfQQYzDfLESAaqJoCkxK+U36T05No8=;\n b=RQ98ZRrDCtvVHZcZ3I8YP2+iNPrL0yo+6eTjHlcMZzOV8fCh6qVJ6384\n BGOOrhmj/A6FkrWvydt39q5BOLaiqP+gU5s8uXTAaQ4yJOFog/BEEYGb5\n P4eWwm+K1hzXaC6GSpYAoXpfr/z6leaUuiWZqS0EYEm8YYC7FKDN//FG7\n HkuBIuFoU1jB8GBif4LraOkDhE0Xr3hSBz74doYBL6Azxyp0cVMaNBwV9\n VrqxM9HS+z01+x86UGMwfgnIrJDKk4o34lnmCfR5rxkdqfZazfmaQp9Qt\n 4JkCWukVZLubUAVrQx9dxP+oFP8wqCCYq9bBOkR/cVptXguJ2FQTPBtcv\n w==;","X-CSE-ConnectionGUID":["+toVeAVTQ4i47OfE8uiu9Q==","VSQw5iB8RoWfoSoovQdJEQ=="],"X-CSE-MsgGUID":["FABiWPStSKKfNyMn6lq3pQ==","52SOpqCpREOR1NJP0mtEEA=="],"X-IronPort-AV":["E=McAfee;i=\"6800,10657,11777\"; a=\"66530082\"","E=Sophos;i=\"6.23,219,1770624000\";\n d=\"scan'208\";a=\"66530082\"","E=Sophos;i=\"6.23,219,1770624000\";\n d=\"scan'208\";a=\"231587821\""],"X-ExtLoop1":"1","Date":"Wed, 6 May 2026 15:46:13 +0300","From":"Andy Shevchenko ","To":"Mika Westerberg ","Cc":"Marco Scardovi , mathias.nyman@linux.intel.com,\n\tlinux-gpio@vger.kernel.org, linux-acpi@vger.kernel.org,\n\tlinux-kernel@vger.kernel.org","Subject":"Re: [PATCH] gpio: acpi: modernize resource management using cleanup.h","Message-ID":"","References":"<59174ed2-dc3a-4891-929f-bf513deecdc2@gmail.com>\n <20260506113215.GK6785@black.igk.intel.com>","Precedence":"bulk","X-Mailing-List":"linux-gpio@vger.kernel.org","List-Id":"","List-Subscribe":"","List-Unsubscribe":"","MIME-Version":"1.0","Content-Type":"text/plain; charset=iso-8859-1","Content-Disposition":"inline","Content-Transfer-Encoding":"8bit","In-Reply-To":"<20260506113215.GK6785@black.igk.intel.com>","Organization":"Intel Finland Oy - BIC 0357606-4 - c/o Alberga Business Park, 6\n krs, Bertel Jungin Aukio 5, 02600 Espoo"}}]