From: Mika Westerberg <mika.westerberg@linux.intel.com>
To: Raag Jadav <raag.jadav@intel.com>
Cc: rafael@kernel.org, len.brown@intel.com,
andriy.shevchenko@linux.intel.com, linux-acpi@vger.kernel.org,
linux-kernel@vger.kernel.org,
mallikarjunappa.sangannavar@intel.com, bala.senthil@intel.com
Subject: Re: [PATCH v2] ACPI: LPSS: use acpi_dev_uid_match() for matching _UID
Date: Fri, 27 Oct 2023 11:18:55 +0300 [thread overview]
Message-ID: <20231027081855.GK3208943@black.fi.intel.com> (raw)
In-Reply-To: <20231026083335.12551-1-raag.jadav@intel.com>
On Thu, Oct 26, 2023 at 02:03:35PM +0530, Raag Jadav wrote:
> Now that we have a standard ACPI helper, we can use acpi_dev_uid_match()
> for matching _UID as per the original logic before commit 2a036e489eb1
> ("ACPI: LPSS: Refactor _UID handling to use acpi_dev_uid_to_integer()"),
> instead of treating it as an integer.
>
> Signed-off-by: Raag Jadav <raag.jadav@intel.com>
> Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com>
The change still looks good to me, however I wonder if we could maybe
improve acpi_dev_uid_match() to support both data types possible for
_UID? This of course is separate patch (unless there are objections).
There is the _Generic() thing and I think that can be used to make
acpi_dev_uid_match()
which takes either u64 (or maybe even unsigned int) or const char * and
based on that picks the correct implementation. Not sure if that's
possible, did not check but it would allow us to use one function
everywhere instead of acpi_dev_uid_to_integer() and
acpi_dev_uid_match().
next prev parent reply other threads:[~2023-10-27 8:19 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-10-26 8:33 [PATCH v2] ACPI: LPSS: use acpi_dev_uid_match() for matching _UID Raag Jadav
2023-10-27 8:18 ` Mika Westerberg [this message]
2023-10-27 10:11 ` Raag Jadav
2023-10-27 14:17 ` Raag Jadav
2023-10-27 14:28 ` Mika Westerberg
2023-10-27 16:51 ` Raag Jadav
2023-10-27 17:19 ` Rafael J. Wysocki
2023-10-27 17:40 ` Rafael J. Wysocki
2023-10-28 8:58 ` Raag Jadav
2023-10-30 10:12 ` Andy Shevchenko
2023-10-30 16:00 ` Raag Jadav
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20231027081855.GK3208943@black.fi.intel.com \
--to=mika.westerberg@linux.intel.com \
--cc=andriy.shevchenko@linux.intel.com \
--cc=bala.senthil@intel.com \
--cc=len.brown@intel.com \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mallikarjunappa.sangannavar@intel.com \
--cc=raag.jadav@intel.com \
--cc=rafael@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.