From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-qk1-f171.google.com (mail-qk1-f171.google.com [209.85.222.171]) (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 E666F46EC91 for ; Tue, 4 Aug 2026 15:45:23 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.222.171 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785858327; cv=none; b=lNyUmfFIYH3s3OMyObzRpP8ufUgEKz8suxgFqwmnuisywKA+YnbAYTSqmRymd4aneCvjMWiAQHG0NfJB71XNqqYLwvLxzdOsRcZbnebtnwdfYzBTrdimzNns4adxipgP51r6nbQo1faZAsuWgtZvXp4wvy1Uk7WQSR1NFn2NdBE= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785858327; c=relaxed/simple; bh=udcDnCZOafJFJBg/CawTNl6gae2dFtyKioVGErWlQrs=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=rWXoV8qQmf21s3EtYoT1WVIDtntq11MVcok1nU7daCgbGJbkptjAGxZNgZda1m8mP69UZqqFgklrLumV08elrHtAKJHJVGY3bfcntyroB2h/CaxktEwI2sd91QjH9/T2UDchBr5Bd3xJI974J+aoHuD/aPb/Ezd9zr7CKuQF6DI= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=gourry.net; spf=pass smtp.mailfrom=gourry.net; dkim=pass (2048-bit key) header.d=gourry.net header.i=@gourry.net header.b=FxmdHqCQ; arc=none smtp.client-ip=209.85.222.171 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=gourry.net Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gourry.net Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gourry.net header.i=@gourry.net header.b="FxmdHqCQ" Received: by mail-qk1-f171.google.com with SMTP id af79cd13be357-92e5d6f35c1so628685a.0 for ; Tue, 04 Aug 2026 08:45:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gourry.net; s=google; t=1785858322; x=1786463122; darn=vger.kernel.org; h=in-reply-to:content-disposition:content-type:mime-version :references:message-id:subject:cc:to:from:date:from:to:cc:subject :date:message-id:reply-to:content-type; bh=EwAZOjeHlqWn9v6/BYYDkI9dqxumArr6QgC+CpKgPx8=; b=FxmdHqCQsJIzOzLRaXOvvoGvXgSN/NR9EToj/FKsuQ1JaV2770IfumQH1YF0CR8Rjq p9r4ph3qXVTorJnXJuTn2a60Ep1pDQicGhOxntvAaMcXZ3uV6eIRCKYqeTNjlSwFdo+y L5/KO6cw9mvQKonXOnqforSK7UnmLOTq2qeg959jtcOMedypZ39+YSeEb51u8ZjYV6EF 2qH1nUB5Gd73c7W6GQ8m9POB73eJnfROA0SsuwrueX0F8yTJYlH/7VH83W554jNX/w5v R+4UAFvYYHTXGRjItPhlflDWBCkPub3UID7VhsC9yt7mfKqX69UF3C2b//DRqdTw0Sz8 OqJg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1785858322; x=1786463122; h=in-reply-to:content-disposition:content-type: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 :content-type; bh=EwAZOjeHlqWn9v6/BYYDkI9dqxumArr6QgC+CpKgPx8=; b=NCCybPWl+AA8ZUtOhDOyjmGYsSSpre1+d1W11F62PCjglvNJkEHDWDob7RFGic4eub fZu1ExmJ3KqrrSa3KRl7iWItwSKAEWFenRMzoDQbfHhsbuYorGRcVGrYcFT59FWDcKSB J/Up8B630gvLy1Sh7lRiL6SimPRCHfXjkdrR/cdRw568U9VWQEY7ZRKfSxJi0n4OMHrx QPSwN3JBDSyfbV8i19sAEkgsCng5woEQiC3iCK+yVLW9S7kcM+7rSbnfhmibnfWaA0JL Jg1fuq/h2JU8HDYE4cAKS0ZyT5RL+2y9xCaZv/DS7ZjdzWAs31/MRnlqdRDXkO9VQ+F6 If+w== X-Forwarded-Encrypted: i=1; AHgh+RpzRaLAzyBOAUtyGvKVmRyUMfxyX5dC5u3V+2n7GmHrHw2tgpTBRz7Vi5i+I9pN0TkHx97XTZOcXc8DlOw=@vger.kernel.org X-Gm-Message-State: AOJu0YwljvCHRBYvs3jhD3TxWER8+NIA/h6wT/XDYjA4xfxno+yeviK+ 9okzSdIMm4oi1HkWmKf7V70aDAXrjeZe7gcu2Ceh3D86pyd6fvfJavBHIg2wvp7KQc4= X-Gm-Gg: AR+sD11szKkhkSHaI31X8iuCCucILMIymj6oeYcHzHzP8hhsSWL3uAms4FOAblZ64ro 0LvM6kq5u/j0LbaPPMDXfGO51AbFI80x/44jWYd+h5rIZV9EeYd8AobgCN81GSQLPYbJ99kvtNy b56vkMsoWMg9/0OmDKzfLXn2rU+9KR3k/2vywEG9oJxKGe9qaITzyrKZ12dVehbyi/hYQ+GTfDs nlylCVxb5PdhksLe9DSequlj1auciz++2HkqA7QMJopdVpUhiQPLQha2OwKlxz7MV0OrVYknn2A Cbc3Rkgur5NmsFTXuw/MeW+BeXhy4ppGB+67kr50Rv/w5tP9owE3fyV32koTHwABce7mVrjTgVW FqGybD0OXsIMWqjnY4cWbLXtVR9l2c7GBTH6Tnepadv7bxxTUsh70xeZMOKtQxXuP7iG07X9wqj emg8MmK0ciIRMKcwGtb5HH1EC0zEcdyFv9jUuQVvWh+WBOIGiqRYQkks3Ar6wwt5r0ilZXahOcv ewbZClgx7aMSwvEio46eqrqVduJoVyk+DYa1PRM5ao0PUPz8/dpL3I= X-Received: by 2002:a05:620a:3c11:b0:931:369:ff0a with SMTP id af79cd13be357-934a0a705b9mr2027822185a.35.1785858321563; Tue, 04 Aug 2026 08:45:21 -0700 (PDT) Received: from gourry-fedora-PF4VCD3F (pool-173-79-60-52.washdc.fios.verizon.net. [173.79.60.52]) by smtp.gmail.com with ESMTPSA id af79cd13be357-936418e2f7dsm103209485a.35.2026.08.04.08.45.20 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 04 Aug 2026 08:45:21 -0700 (PDT) Date: Tue, 4 Aug 2026 11:45:19 -0400 From: Gregory Price To: Jonathan Cameron Cc: Alison Schofield , Anisa Su , linux-cxl@vger.kernel.org, nvdimm@lists.linux.dev, linux-kernel@vger.kernel.org, Dave Jiang , Fan Ni , Li Ming , Vishal Verma , Davidlohr Bueso , Ira Weiny , Benjamin Cheatham , Wonjae Lee , Junhee Park , Heesoo Kim , Anisa Su Subject: Re: [PATCH v12 1/8] cxl/mbox: Flag support for Dynamic Capacity Devices (DCD) Message-ID: References: <20260731084901.1512819-1-anisa.su@samsung.com> <20260731084901.1512819-2-anisa.su@samsung.com> <20260804001245.079b16ae@jic23-huawei> 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: <20260804001245.079b16ae@jic23-huawei> On Tue, Aug 04, 2026 at 12:12:45AM +0100, Jonathan Cameron wrote: > > > > When I view how this lands in the entirety of cxl_walk_cel() it seems > > to needlessly be different from the pattern set by poison and security > > handling in the same function and structures. Could this follow that > > more closely? Doing so would remove this 'tail' work here of checking > > and setting the boolean. > > > > This appended diff touches patch 2 where it has the first caller, but > > pasting all here for simplicity - you'll apply per patch if you take it. > > > > The bitmap lives in mds structure and it is already where the bool is now. > > The only piece of the poison and security pattern not worth copying > > yet is the wrapper struct cxl_poison_state and struct cxl_security_state > > exist because each grew a mutex and other per-class state, and DCD has > > none of that in this series (yet). > Hi Alison, > > This rang a bell as I remembered Ira did it this way originally - > so I did some archaeology. > > [PATCH v8 01/21] cxl/mbox: Flag support for Dynamic Capacity Devices (DCD) > https://lore.kernel.org/all/67786b76a0c5_f58f294b1@dwillia2-xfh.jf.intel.com.notmuch/ > > Dan's point was that we need that infrastructure for poison and security > because a subset is a realistic possibility. For DCD today it's all or > nothing so why keep a bitmap around? > > I agree there is merit in having all the command types handled the same > but perhaps it is clearer to just have a bool. Of course when someone > adds another DCD command on the device side (which by definition will have > to be optional) then we will need to revisit. > Yeah, and it's not really binding ABI so no need for complexity until we get there. Honestly the feature bit check is essentially the same as the bitmap check at this point, so seems find to push that generalization off until we actually need it. ~Gregory