From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-dl1-f43.google.com (mail-dl1-f43.google.com [74.125.82.43]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 94C2417A2FC for ; Sun, 7 Jun 2026 19:01:37 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=74.125.82.43 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780858898; cv=none; b=Oag6Rlr3isqjWSViN5T1Gf77W5sStJgz4D0m9fVIt7/T+AeykeszT4HxbKsVj2FTqZTHfQY68nMxuJFlXqY6R4wnS1BxNN6bIKJ8BA0xO+2GeY11hJ7dUtsBpAkZgVk1kBzeFpdVpfyAgISKMAW2cG+k6Wvszx2dDn7giPfU32k= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780858898; c=relaxed/simple; bh=8TXfEMMV2uWnmskY16B5og0NVW5Rz797jmeczmEHw4s=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=Dkzz6Egc/3qxIwF5OBvGmcLL5haqjFBNXxJirT25aXL+0jaAZPtY1xla3d3a8a/7ntXAcAJrzE+IEWtLxTZK91u7jD5TGDShuwlpU690PBa6yIzvG+sa8M0t9Kccbld5AqxluwA8jM5asLIIJrmBVsjxOPYR+wP5HlyqOv9LoFM= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com; spf=pass smtp.mailfrom=google.com; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b=pgRydl7/; arc=none smtp.client-ip=74.125.82.43 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=google.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="pgRydl7/" Received: by mail-dl1-f43.google.com with SMTP id a92af1059eb24-1380104f31eso19921c88.0 for ; Sun, 07 Jun 2026 12:01:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20251104; t=1780858897; x=1781463697; darn=vger.kernel.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=7bxnEjA/C3zuxdR051u14W5wOLjOO10IAKaN4C2htfQ=; b=pgRydl7/v6qxi4kfAI8pxM8jtQMkltAiCed1YgfNGv5z3zqCKVVezTcwFJasClqhFZ 8SgYwMwaszwJ/Ef+zfADWDwRw7HsKqjHXwbN53uisDybAJFZ4YE/glzBOqj0yZ61DbFd ypIXfiFAogGl6i8PiLet9Ij5NGwK7q6D0rxupldOrqbYtNsFChFydkCq2XARxM+kiZnT 8vvGdx5XlRh/Npilx+iVocF4cf97R9kUoSyYAvOXJrIopREX0JCq/SWk/qZFa5hbbCoe FkX8ThHU+FaIOqALNzYvHAaeOp030QdN8H+D5GuxEHsq0mtyOQxvYpoi6pNFTGnSWxbv mERQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1780858897; x=1781463697; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=7bxnEjA/C3zuxdR051u14W5wOLjOO10IAKaN4C2htfQ=; b=SA2shwxRxgHoEXMdft4E1pY3RjyqRn0R8ZOvxZ3TRId+YHx1wSGzRXYvn/F2d8kqc+ 6A45XtBMdTfbKhyl/m45vu88WyKo4jV88VXgcifzFbZrGLqMmmy0nnDjJVvn4Qt+ofON AiRPMsKRde6zR64sTHC5VwGavsrp16qlLFtsJv0Y2JHpX/RKLhO7+iwzJTAv4lrY6HJE NZggLwvFTZBdbICDhSiAFfpBoyjETCsjGRPIoX/Cb5P2bSfryKgt8fdUDXhcBRBfGyQi kaY4rVjvYBGxXqXmZF+veMxJqWLeLqVXXi3jyZ2ibuhhRoiTt+1GDGrHaePQ/vqRB6my iq4w== X-Forwarded-Encrypted: i=1; AFNElJ9PUJeKQ4dR0NCxonf7NGwJPwhAYa2OZlYPGLm5yMPSKZhr3O7yRbBAtFP8P4AnfhsQKwj/sFCOf0gIs3g=@vger.kernel.org X-Gm-Message-State: AOJu0Yw53ONL/sKBqzCAwRG6ecQ6KD0ILTRMDcJB2dGT4QfK8aYprEmz YraREFj7FXPmSzpo+TPKcxBzOUSXHGyVSW52UebhMfDJTW/bSq/Pu2tU9SiIvcJwtw== X-Gm-Gg: Acq92OEG751ZnU6yVXAkAlwJxplAU6Yg2v+54tRiwbeI2QpXJU+WHxaox/00lQVXpGP efNwUPvERMPx67GAnMleaT2ZNmkB17ashIF8T2JSzE65Jjh7guq7oFljIZlQlCsOCkH//feE4s5 7deOSO/g9ZHdLn6pq/IV1QmZkff3fRcwn+sIAswEB6Dwinp2lDAEzWbBfdjuO9DW5kGBKvQTgx5 7dTLst9GqjuGw2A1J1BYhT//sWoPSY+VL6qAw8asmMiz3qC/AenT5GIQrURG0X1Yrp1mHcIpSRN kZ8oFF+60mvYnQU02l7kmXdVN/A39l4wQ7f8dMxuAgEZ2FjFv1EGew7jaHVyT4QSsrTB+C3rs0+ geWad1dljD3cPT8Z0rXFqfE1dNurc0SK1Xy4KUmd+5+NqzoemxDRwkhwuBDbB+7MPqEXHg/Us2s jHNFfJnj81Ggp42UEjmmlR2Jy3LHc6fGNgBHV2AYYRU3ocJlgmBAtk9dYrKNXIWVbV5Y3/W9M= X-Received: by 2002:a05:7022:23a2:b0:138:888:32de with SMTP id a92af1059eb24-13808883386mr174298c88.30.1780858894965; Sun, 07 Jun 2026 12:01:34 -0700 (PDT) Received: from google.com (199.255.142.34.bc.googleusercontent.com. [34.142.255.199]) by smtp.gmail.com with ESMTPSA id 5a478bee46e88-3074dea8e76sm13773740eec.18.2026.06.07.12.01.29 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 07 Jun 2026 12:01:34 -0700 (PDT) Date: Sun, 7 Jun 2026 19:01:25 +0000 From: Pranjal Shrivastava To: David Matlack Cc: kexec@lists.infradead.org, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, linux-pci@vger.kernel.org, Adithya Jayachandran , Alexander Graf , Alex Williamson , Bjorn Helgaas , Chris Li , David Rientjes , Jacob Pan , Jason Gunthorpe , Jonathan Corbet , Josh Hilke , Leon Romanovsky , Lukas Wunner , Mike Rapoport , Parav Pandit , Pasha Tatashin , Pratyush Yadav , Saeed Mahameed , Samiullah Khawaja , Shuah Khan , Vipin Sharma , William Tu , Yi Liu Subject: Re: [PATCH v6 07/12] PCI: Refactor matching logic for pci_dev_acs_ops Message-ID: References: <20260522202410.3104264-1-dmatlack@google.com> <20260522202410.3104264-8-dmatlack@google.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20260522202410.3104264-8-dmatlack@google.com> On Fri, May 22, 2026 at 08:24:05PM +0000, David Matlack wrote: > Refactor the logic to match devices to pci_dev_acs_ops by factoring out > the loop and device matching into its own routine. This eliminates some > duplicate code between pci_dev_specific_enable_acs() and > pci_dev_specific_disable_acs_redir(), and will also be used in a > subsequent commit to check if a device requires device-specific > enable_acs() during a Live Update. > > No functional change intended. > > Signed-off-by: David Matlack > --- > drivers/pci/quirks.c | 50 ++++++++++++++++++-------------------------- > 1 file changed, 20 insertions(+), 30 deletions(-) > [...] > } pci_dev_acs_ops[] = { > { PCI_VENDOR_ID_INTEL, PCI_ANY_ID, > + .match = pci_quirk_intel_pch_acs_match, > .enable_acs = pci_quirk_enable_intel_pch_acs, > }, > { PCI_VENDOR_ID_INTEL, PCI_ANY_ID, > + .match = pci_quirk_intel_spt_pch_acs_match, > .enable_acs = pci_quirk_enable_intel_spt_pch_acs, > .disable_acs_redir = pci_quirk_disable_intel_spt_pch_acs_redir, > }, > }; > > -int pci_dev_specific_enable_acs(struct pci_dev *dev) > +static const struct pci_dev_acs_ops *pci_dev_acs_ops_get(struct pci_dev *dev) > { > const struct pci_dev_acs_ops *p; > - int i, ret; > + int i; > > for (i = 0; i < ARRAY_SIZE(pci_dev_acs_ops); i++) { > p = &pci_dev_acs_ops[i]; > @@ -5481,33 +5475,29 @@ int pci_dev_specific_enable_acs(struct pci_dev *dev) > p->vendor == (u16)PCI_ANY_ID) && > (p->device == dev->device || > p->device == (u16)PCI_ANY_ID) && > - p->enable_acs) { > - ret = p->enable_acs(dev); > - if (ret >= 0) > - return ret; > - } > + p->match(dev)) > + return p; Nit: Should we check if (p->match != NULL) like we check for p->enable_acs & p->disable_acs_redir(). Otherwise, it seems like we're mandating the existence of a match op in the pci_dev_acs_ops here? Today, we just have two Intel entries in that array, both of which need the match op. However, AFAICT, it shouldn't be mandatory for future SoCs that might only need a simple vid + devid match [...] with that nit: Reviewed-by: Pranjal Shrivastava Thanks, Praan