From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 8FDB434AB00 for ; Thu, 18 Dec 2025 14:04:06 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=185.176.79.56 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1766066650; cv=none; b=chUTF+cGKvCtlSf3utgKl+wgPE36FFhKEpCLEpA0u1xwP17oVAlBvzJHIxTK6TkJfMRgUWmx8WkfktYA+q0X/+4iCAyDXNbQUnK22NwMhhzW3Bxgcmo28L/JuEHk2WUZEFzB3PQjK51le2B89xRzs2XC9UiREWkVDVlU/NdAYeY= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1766066650; c=relaxed/simple; bh=4sUJJoedwJv/6ogF+hkEAC8PAkRrfZZXthxV1UUTzNE=; h=Date:From:To:CC:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=lpAh8H2vXO5e0aWXknHjnJmnzVpgZwMFXTyjeeJkz5weNMtWVScL2f6sTpihOPcmj1/oADwD35gYo+X4hYSUAfqcldtrEPJIT29227qB58fYX4jqmn4El8/ZBA0JGspyqD39y90HI3XrC0KXiVD9IWNI/Y0rkjqLfbVOFUV2538= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=huawei.com; spf=pass smtp.mailfrom=huawei.com; arc=none smtp.client-ip=185.176.79.56 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=huawei.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=huawei.com Received: from mail.maildlp.com (unknown [172.18.224.83]) by frasgout.his.huawei.com (SkyGuard) with ESMTPS id 4dXC7X5stWzHnH4q; Thu, 18 Dec 2025 22:03:36 +0800 (CST) Received: from dubpeml100005.china.huawei.com (unknown [7.214.146.113]) by mail.maildlp.com (Postfix) with ESMTPS id 17A4B40569; Thu, 18 Dec 2025 22:04:04 +0800 (CST) Received: from localhost (10.203.177.15) by dubpeml100005.china.huawei.com (7.214.146.113) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1544.36; Thu, 18 Dec 2025 14:04:02 +0000 Date: Thu, 18 Dec 2025 14:04:01 +0000 From: Jonathan Cameron To: James Morse CC: , , D Scott Phillips OS , , , , , , Jamie Iles , "Xin Hao" , , , , David Hildenbrand , Dave Martin , Koba Ko , Shanker Donthineni , , , Gavin Shan , Ben Horgan , , , Punit Agrawal Subject: Re: [RFC PATCH 34/38] arm_mpam: Add quirk framework Message-ID: <20251218140401.000062ce@huawei.com> In-Reply-To: <20251205215901.17772-35-james.morse@arm.com> References: <20251205215901.17772-1-james.morse@arm.com> <20251205215901.17772-35-james.morse@arm.com> X-Mailer: Claws Mail 4.3.0 (GTK 3.24.42; x86_64-w64-mingw32) 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-Transfer-Encoding: 7bit X-ClientProxiedBy: lhrpeml500011.china.huawei.com (7.191.174.215) To dubpeml100005.china.huawei.com (7.214.146.113) On Fri, 5 Dec 2025 21:58:57 +0000 James Morse wrote: > From: Shanker Donthineni > > The MPAM specification includes the MPAMF_IIDR, which serves to > uniquely identify the MSC implementation through a combination of > implementer details, product ID, variant, and revision. Certain > hardware issues/errata can be resolved using software workarounds. > > Introduce a quirk framework to allow workarounds to be enabled based > on the MPAMF_IIDR value. > > Signed-off-by: Shanker Donthineni > [ morse: Stash the IIDR so this doesn't need an IPI, enable quirks only > once, move the description to the callback so it can be pr_once()d, add > an enum of workarounds for popular errata. Add macros for making lists > of product/revision/vendor half readable ] > Signed-off-by: James Morse > --- > drivers/resctrl/mpam_devices.c | 27 +++++++++++++++++++++++++++ > drivers/resctrl/mpam_internal.h | 26 ++++++++++++++++++++++++++ > 2 files changed, 53 insertions(+) > > diff --git a/drivers/resctrl/mpam_devices.c b/drivers/resctrl/mpam_devices.c > index 741e14e1e6cf..f0f6f9b55ad4 100644 > --- a/drivers/resctrl/mpam_devices.c > +++ b/drivers/resctrl/mpam_devices.c > @@ -630,6 +630,25 @@ static struct mpam_msc_ris *mpam_get_or_create_ris(struct mpam_msc *msc, > return ERR_PTR(-ENOENT); > } > > +static const struct mpam_quirk mpam_quirks[] = { > + { NULL }, /* Sentinel */ Drop the trailing , given I assume whole point is nothing after this? > +}; > + > +static void mpam_enable_quirks(struct mpam_msc *msc) > +{ > + const struct mpam_quirk *quirk; > + > + for (quirk = &mpam_quirks[0]; quirk->iidr_mask; quirk++) { > + if (quirk->iidr != (msc->iidr & quirk->iidr_mask)) > + continue; > + > + if (quirk->init) > + quirk->init(msc, quirk); I'm curious why you don't return a bool from this and call mpam_set_quirk() if that's not indicating it should not be set. Seems a bit odd to push the tracking that is relevant to the generic framework (mpam_set_quirk) down into the particular quirk inits. > + else > + mpam_set_quirk(quirk->workaround, msc); > + } > +} > diff --git a/drivers/resctrl/mpam_internal.h b/drivers/resctrl/mpam_internal.h > index d381906545ed..de3e5faa12b2 100644 > --- a/drivers/resctrl/mpam_internal.h > +++ b/drivers/resctrl/mpam_internal.h > @@ -88,6 +88,8 @@ struct mpam_msc { > u8 pmg_max; > unsigned long ris_idxs; > u32 ris_max; > + u32 iidr; > + u16 quirks; > > /* > * error_irq_lock is taken when registering/unregistering the error > @@ -215,6 +217,29 @@ struct mpam_props { > #define mpam_set_feature(_feat, x) set_bit(_feat, (x)->features) > #define mpam_clear_feature(_feat, x) clear_bit(_feat, (x)->features) > > +/* Workaround bits for msc->quirks */ > +enum mpam_device_quirks { > + MPAM_QUIRK_LAST, Dropping this comma should make it harder for anyone to stick an entry after this.