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 17:28:56 +0300 [thread overview]
Message-ID: <20231027142856.GL3208943@black.fi.intel.com> (raw)
In-Reply-To: <ZTvGaNZmGWpsM-yw@black.fi.intel.com>
On Fri, Oct 27, 2023 at 05:17:12PM +0300, Raag Jadav wrote:
> On Fri, Oct 27, 2023 at 01:12:02PM +0300, Raag Jadav wrote:
> > On Fri, Oct 27, 2023 at 11:18:55AM +0300, Mika Westerberg wrote:
> > > 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().
> >
> > The way I see it, acpi_dev_uid_to_integer() is useful when drivers want to
> > parse _UID and store it in their private data, so that it is available for
> > making various decisions throughout the lifetime of the driver, as opposed
> > to acpi_dev_uid_match() which is more useful for oneshot comparisons in my
> > opinion.
> >
> > So I'm a bit conflicted about merging them into a single helper, unless
> > ofcourse there is a way to serve both purposes.
>
> Or perhaps something like,
>
> bool acpi_dev_uid_match(struct acpi_device *adev, const void *uid2, enum uid_type type)
> {
> u64 uid1_d, uid2_d;
>
> if (type == UID_TYPE_STR) {
> char *uid2_s = (char *)uid2;
> if (!(uid2_s && !kstrtou64(uid2_s, 0, &uid2_d)))
> return false;
> } else if (type == UID_TYPE_INT) {
> u64 *uid2_p;
> uid2_p = (u64 *)uid2;
> uid2_d = *uid2_p;
> } else {
> return false;
> }
>
> if (!acpi_dev_uid_to_integer(adev, &uid1_d) && uid1_d == uid2_d)
> return true;
> else
> return false;
> }
>
> Although this looks unnecessarily hideous.
Indeed, but using the _Generic() you should be able to have
a single acpi_dev_uid_match() to work for either type so:
acpi_dev_uid_match(adev, "1")
and
acpi_dev_uid_match(adev, 1)
would both work with type checkings etc.
Not sure if this is worth the trouble though.
next prev parent reply other threads:[~2023-10-27 14:35 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
2023-10-27 10:11 ` Raag Jadav
2023-10-27 14:17 ` Raag Jadav
2023-10-27 14:28 ` Mika Westerberg [this message]
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=20231027142856.GL3208943@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.