From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-qk1-f179.google.com (mail-qk1-f179.google.com [209.85.222.179]) (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 590C42DB782 for ; Wed, 11 Feb 2026 15:59:26 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.222.179 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770825567; cv=none; b=G5+JIvXJmM7TEi5Qlvk9bQqO1cqB7rNTrY+ZWV9NAaxMg0lybIZQswpyCWIQiFc1svQP6MumkwzhFAE1MUbHGZLZAH8UINE3QipEWVDW82bGXeQwJJxMh5eJgG5nJzlhZPzCtrvLR5Jza4DErGcWCvwbpTtoIlWM2Qk4L9oGzP0= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770825567; c=relaxed/simple; bh=IKUNIkEymglVf4BArYHDRxPhT6lG79lU/pszt7Itru4=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=iI8stdJ3yr9Q57tYke1RjVXm1Ma8GLI7+i1siWqDxf/00VJ0aetKEYIOAm0MmiTk6ZbR7EUTjrSyvqUWmKveGoen20ZqorFFFAo7yfX/mGiCeUFzzk2AdJw3tb5Q4rlDm2otV1JM3LGmF4gr3yVG+msGJlPg/B2ORidHQk0rUEE= 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=Gz9k/tQ5; arc=none smtp.client-ip=209.85.222.179 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="Gz9k/tQ5" Received: by mail-qk1-f179.google.com with SMTP id af79cd13be357-8c52f15c5b3so679185385a.3 for ; Wed, 11 Feb 2026 07:59:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gourry.net; s=google; t=1770825565; x=1771430365; 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=d6RAzUSXpBXql+F9ay58cLMbqKb0I7SnNahqduMaG0U=; b=Gz9k/tQ5DXjaqatbqgzegv2A7jxsoqQbbhQV1PWY4ZxSLD2kCu51X9GIvl3NgIPqdb AQzXPlSHzq78UlEXtPm5EmvJc3jFM8cGxYExpvcKpAzPTxTv7HGekTFIbGV8ml7PKdaY nZ8bSpgFiKkAztAc1F0Lrj/zl0MCfMyuj7Spa4Tgl4i974sSkJPkq8hYCSfjvlpRce5S xwiMuoIsq4nqkllXaaPU4EfglXVcl1Bj69eO52YCUms9S5Cbm7cUi9+SB71o4KyjnJIk yj439usJWaW0m6AInf5KkKPQ8/ucBjygsEiL6HT91srd373LvCzk+NZJzcvCqK0Xxg5D 7yAw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1770825565; x=1771430365; 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=d6RAzUSXpBXql+F9ay58cLMbqKb0I7SnNahqduMaG0U=; b=kYWGJr2rRbkdzFeHBunivklwZ7NkS8rlv4vVttX8klytS2Kr3PZDXMyUemaU7g5pCb Oc1yKS6dIrhdEa+H1bmxgIUe5sZwsB3eE3Bh16D+DCxTdlAMG8ZODKVcqAu5T8OPaUrt KvKnzeyGjymV2DMK+Gi+hONfOXZ7RDoHIKui8jKY8PCqanyZ7LblVUiNPP+NMQeRgBtn 3gKHCqDCFtE57TJmxOBIkaVgaHmeeQWbOOZoOVFezup/sLfYlru19M56C3v0FfTY5Zya KDTs+wvMZ2fmVizNKoJEmcrP4qRvh7KG5mIEHI+ge3cRdaPugRx+J62i8kyMTcQfbCSp yZYA== X-Forwarded-Encrypted: i=1; AJvYcCXMU9JwIGM+g1NwAB5NOIo/uTOllkjoBZJZa1T+E4iK1nvbGDct6UoP6tzgNLsoLBcoZNInvSWhc/WI+uA=@vger.kernel.org X-Gm-Message-State: AOJu0YwD32mLStQMwF9K1rc7QVWV5zc0orLTtZLRA1YSCT73QlXGYyOb tU5rcmvIQ8lvorLVjDK6JKvqXQg27ZLqdzR+GAjI1wCcfd6YV81Q8/736KAwwapxO4g= X-Gm-Gg: AZuq6aL33LogzOZwki8462djsNP0wqCFOiBXNcFoUBZccN3clBa3OgQI1Qwnl2vwMMh 8M0qTYqyO0WzsIACtveMhuQtsQqkOAWiS9Wr9qjVAYJs5oOOH6IERIIaJOxQemC6g5da5+w7xTr fX1xUvhgIPLe2u2iT/62DIFBrQuXIC4pa9deP5WCUA+cqeNWzjk7b/7kZwZ2Gw8KVDYfpJG5D+E 7b1gEvmocMrplXN4WDUXGI+0cO/QOZFqs2i4ZnH7iOenrIZW6tPce+ws0zIR3L6q6ULGVJN8orp tYgNGC/Lq1SziztqDTR6CBKrGs61ndU2lWcnzQ/pfDZNHRdZ9bsakndycTZmlEs4wUAZ2YHnR3z ADa6LDgl2djAh4G1PuVyh1dPtA3gLIYFy1o4tIZwedK42Je5UhCIMG+duCE3rGql5yPLkgxhodu +qhG7ZuZiheXlipJXlxPp2LpXbVnAJaQNSWnOZr6GT9oCCKwz7wOrDW/FnifRJ8SOVMRY6NM5mC +k7FaEK0w== X-Received: by 2002:a05:620a:3184:b0:8a2:3be9:1d79 with SMTP id af79cd13be357-8cb2a2bf77emr255258885a.18.1770825565157; Wed, 11 Feb 2026 07:59:25 -0800 (PST) Received: from gourry-fedora-PF4VCD3F (pool-96-255-20-138.washdc.ftas.verizon.net. [96.255.20.138]) by smtp.gmail.com with ESMTPSA id af79cd13be357-8cb2b20f240sm139552185a.40.2026.02.11.07.59.24 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 11 Feb 2026 07:59:24 -0800 (PST) Date: Wed, 11 Feb 2026 10:59:22 -0500 From: Gregory Price To: Alison Schofield Cc: Vishal Aslot , Davidlohr Bueso , Jonathan Cameron , Dave Jiang , Vishal Verma , Ira Weiny , Dan Williams , Li Ming , Peter Zijlstra , "open list:COMPUTE EXPRESS LINK (CXL)" , open list Subject: Re: [PATCH v1 1/2] cxl_test: enable zero sized decoders under hb0 Message-ID: References: <20251015024019.1189713-1-vaslot@nvidia.com> <20251015024019.1189713-2-vaslot@nvidia.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: On Wed, Feb 11, 2026 at 10:04:41AM -0500, Gregory Price wrote: > Revisiting this - it might be reasonable to allow post-lock ordering if > *all* decoders in beyond the programmable one are zero-locked. > > Seems ok? Thoughts? > Sorry, got myself a bit mixed up, lets me a bit more precise, there are annoying corner conditions here that make reasoning about this difficult, and the mild ambiguity in the spec doesn't imbue confidence. [open] = programmable [programmed] = usually auto-decoder, but some cases may allow runtime programming, i haven't logic'd that out. Post-lock Legal decoder 0 1 2 ... N ------------------------------------------------------------------ [open] [zero-lock] [zero-lock] [zero-lock] [open] [open] [zero-lock] [zero-lock] [programmed] [open] [zero-lock] [zero-lock] [programmed] [programmed] [zero-lock] [zero-lock] In these cases you basically act as-if the zero-locked decoders essentially don't exist. Pre-lock Legal decoder 0 1 2 ... N ------------------------------------------------------------------ [zero-lock] [zero-lock] [zero-lock] [open] [zero-lock] [zero-lock] [zero-lock] [programmed] [zero-lock] [zero-lock] [programmed] [open] [zero-lock] [zero-lock] [programmed] [programmed] Again, in these causes you just act like the decoders don't exist. Illegal decoder 0 1 2 ... N ------------------------------------------------------------------ [open] [zero-lock] [open] [zero-lock] [programmed] [zero-lock] [open] [zero-lock] [open] [zero-lock] [programmed] [zero-lock] [zero-lock] [open] [zero-lock] [zero-lock] [zero-lock] [open] [zero-lock] [open] [zero-lock] [open] [zero-lock] [open] [zero-lock] [open] [zero-lock] [programmed] These cases are all illegal because there is always some form of decoder committed out-of-order in the presence of at least one locked decoder (the zero-locks). Questionable decoder 0 1 2 ... N ------------------------------------------------------------------ [zero-lock] [programmed] [zero-lock] [zero-lock] [programmed] [zero-lock] [programmed] [zero-lock] [zero-lock] [programmed] [zero-lock] [programmed] ****** [zero-lock] [programmed] [zero-lock] [open]...[open] In these cases, it's only really legal IFF the programmed decoder(s) are auto-decoders, because it means an out-of-order condition is impossible. I think you can validate this on probe, but it's annoying if zero-lock decoder is present a) all decoders prior to the zero-lock are locked (zero | auto) b) all decoders after the zero-lock are locked* * if an open decoder appears after a zero-lock, all decoders after the open decoder must also be open. (supports corner case above) I... think that works? It's annoying though lol. ~Gregory