Received: by 2002:a05:7412:a9a2:b0:e2:908c:2ebd with SMTP id o34csp1044939rdh; Fri, 27 Oct 2023 03:12:24 -0700 (PDT) X-Google-Smtp-Source: AGHT+IFMoiEgJsFHHAtS0Fu5hvS4ezZHJpfJ+xIisVqUuf8JFiFrV1ztwkP6dcmRuVouzNyx7Jyf X-Received: by 2002:a05:6102:101b:b0:457:c445:69f3 with SMTP id q27-20020a056102101b00b00457c44569f3mr2042175vsp.34.1698401544278; Fri, 27 Oct 2023 03:12:24 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1698401544; cv=none; d=google.com; s=arc-20160816; b=Q+9SHeXWXgefvS91gy8u4HUmTf0r+y7YGp0KaiIqvHqm9IcsAfMWCKZ4L2+IzOWHYT 1DlITX1bY6D3HkBj6ikSHe8ORUz5UghN0yGXQXm+SaKbUCNeC2B3rbnnrKYmPXKy60mw 3coh/FbUM3ihMRuR36sc34nLrys7F0rPEb3HttAHVQKIvHG93Vac3oRTf7vvFQQe3pUc nVcvszKE9RBzL9Az5JA1ImZMIZPRnc2yLdcIt/3oQNkPSrX31IhJoCY5N0FblBFFNxa+ mUL+ucXT51aDwaHV3bHKjlJy0bLzPsWWFEK+tqgiUb9FYidmgLuphQ+zIIdLSXvi85hw whJw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=TZA7HCnfUFOyhzx5FSl0bKzBsfA5XYuI5R7NOlgotBs=; fh=tBy8eVSD4moMZnPuIRuzNXje623dsKDm39LwkhrNNsE=; b=yb7YHpgaVGvD2ooHp9sANj9t7T8z17RSf5TSS6CSYqB2JZnKD6sTE9dzageVGnE2aH /1t3CCuk+/l1KEs+jh9b1o9QkFqYPxD35UtNc9UWNoyCs4jpZOYsJFQLgGHGrCgcA2or OaEcFzFF45hMa3C/z4qLEXc879yuQC2Tt88uBgNGY75+O1UpsaEC+QCS+1+BNwDDC7cM zceCLXm+6DYzThOdT3VtPL5WuBwMltIUabZTqxmdFEYI4Vm2F9/v55tDiFWODH/tJS5c zHh2NUAtZj+QP73cc3dUki6RTjfunQTvSOM/kMTr1ObR9+qBaQFzXjOiOxu5vRTIvrPg QRFQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=MNdJXDUs; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:3 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from lipwig.vger.email (lipwig.vger.email. [2620:137:e000::3:3]) by mx.google.com with ESMTPS id n193-20020a25d6ca000000b00d9a55429bcdsi2281019ybg.698.2023.10.27.03.12.23 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 27 Oct 2023 03:12:24 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:3 as permitted sender) client-ip=2620:137:e000::3:3; Authentication-Results: mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=MNdJXDUs; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:3 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by lipwig.vger.email (Postfix) with ESMTP id C9E9F83650A0; Fri, 27 Oct 2023 03:12:21 -0700 (PDT) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.10 at lipwig.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1345658AbjJ0KMG (ORCPT + 99 others); Fri, 27 Oct 2023 06:12:06 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:38066 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230502AbjJ0KME (ORCPT ); Fri, 27 Oct 2023 06:12:04 -0400 Received: from mgamail.intel.com (mgamail.intel.com [192.55.52.115]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id F2003BD; Fri, 27 Oct 2023 03:12:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1698401523; x=1729937523; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=fC4NawWJxctEmEJLsZMy6ys4v8xn8O7rZqwzS7NeHnk=; b=MNdJXDUspd8LsbbaVo0dVUGTwGRigo3RHGf4Eug/R1fdA6FyzKbbniN8 KXJPjoaS6WM5qahdk8gwAaVtuhtFGccH7nODYhhbnqjLUjRiiXRkjlzn6 JO1DL2Vu24J7GpNTn7cRrh01QWRimhcuJZbru8i3Ivnn/UMJ36VUUQ8Kr vxpEyjRhyHqEvflcsZXCuIxDqAKTmB4ZjmeQunmP2daBwue4cOm7sq+Zd uRWMTWar+7D0EnDyPkWn3yJcXkXu8kQsggDvIZhzuTgWfs7DO7QsP7isx 6rnXcazj33EPIbboSkP6KtOvCrNHXjdi8oH3BGDq1Bkl6RhKpWekxzsvk Q==; X-IronPort-AV: E=McAfee;i="6600,9927,10875"; a="387562322" X-IronPort-AV: E=Sophos;i="6.03,255,1694761200"; d="scan'208";a="387562322" Received: from orsmga008.jf.intel.com ([10.7.209.65]) by fmsmga103.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 27 Oct 2023 03:12:02 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10875"; a="788789658" X-IronPort-AV: E=Sophos;i="6.03,255,1694761200"; d="scan'208";a="788789658" Received: from black.fi.intel.com ([10.237.72.28]) by orsmga008.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 27 Oct 2023 03:11:59 -0700 Date: Fri, 27 Oct 2023 13:11:56 +0300 From: Raag Jadav To: Mika Westerberg 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 Message-ID: References: <20231026083335.12551-1-raag.jadav@intel.com> <20231027081855.GK3208943@black.fi.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20231027081855.GK3208943@black.fi.intel.com> X-Spam-Status: No, score=-0.9 required=5.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lipwig.vger.email Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (lipwig.vger.email [0.0.0.0]); Fri, 27 Oct 2023 03:12:21 -0700 (PDT) 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 > > Acked-by: Mika Westerberg > > 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. However, I do agree that we can improve acpi_dev_uid_match() by treating uids as integers underneath, instead of doing a raw string comparison. This would make it more aligned with the spec as suggested by Andy. Raag