Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Thu, 9 Jun 2022 15:03:27 -0700
From:   Ira Weiny <ira.weiny@intel.com>
To:     Jonathan Cameron <Jonathan.Cameron@huawei.com>
CC:     Ben Widawsky <bwidawsk@kernel.org>,
        Dan Williams <dan.j.williams@intel.com>,
        Bjorn Helgaas <bhelgaas@google.com>,
        "Alison Schofield" <alison.schofield@intel.com>,
        Vishal Verma <vishal.l.verma@intel.com>,
        Dave Jiang <dave.jiang@intel.com>,
        <linux-kernel@vger.kernel.org>, <linux-cxl@vger.kernel.org>,
        <linux-pci@vger.kernel.org>
Subject: Re: [PATCH V10 6/9] cxl/port: Read CDAT table
Message-ID: <YqJuLwlmn0oLwHxj@iweiny-desk3>
References: <20220605005049.2155874-1-ira.weiny@intel.com>
 <20220605005049.2155874-7-ira.weiny@intel.com>
 <20220606181541.ysb3zqdpe5cuk4e6@bwidawsk-mobl5>
 <YqESPug9duS6BMfQ@iweiny-desk3>
 <20220609092738.00007553@Huawei.com>
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <20220609092738.00007553@Huawei.com>
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?HHmHG+pNR+3zlkWaRmHd9LP/h3mG1hsZ1aS8fGEZcDSqKZG56nDmEsWr4g1g?=
 =?us-ascii?Q?DisNEeA7716uQWr+866do/+CIjSAf/Y5YmBYm8mPjZtGxm+hlwqwrYONrsgs?=
 =?us-ascii?Q?T3/9mBtipBpy9lDho/KJBaeUsNraE6fKATcT1Qmq6PiR9P+24qP5BrxXHICK?=
 =?us-ascii?Q?r3i99nzacEBFzv2xX32brZrbc/YE26+K3/29Wgt4CMx1HH8070tW3XQyXUoD?=
 =?us-ascii?Q?mYI9zPeHisRPdMMPxddPhsz1uFLWJSC0XQJsiqs3K5Y9bl96pZoo2wqaDPQw?=
 =?us-ascii?Q?OwB5u5nGfV4RZgmSKPiW/+9sZkmFctU6cGKIN0/ib1ex1vafO9k8SK7SJNEr?=
 =?us-ascii?Q?uTKloLNaNVVe0Tkv2R9rQcjJhfRIA+2uP+Z404RBK7xcSmA1rOCqgCnj8XFX?=
 =?us-ascii?Q?y4rJmeygQ3qsKt/7jxhD0hh76OnjWw+844Ph+yZUpMBsp+aoaAmUcsEuVwxV?=
 =?us-ascii?Q?XJQfFtooZvTPa18O4Pw0cucI49zolybCocyY1br254hXIbmuCO1FHnlC2e/C?=
 =?us-ascii?Q?HyPfiaMvadAM7o9oF9/SK9U9Xb5VTZEErXmA6tDXM3cg8ux5J3pkgdHXP3SV?=
 =?us-ascii?Q?pllZkshAveCCGs+W0oVqOpKUixlTnStdHACsf3kUg+pVQV8ya1xO1AA5sVFX?=
 =?us-ascii?Q?2JLtLsfO0FyjqW4vOBV2HMOau/zCrZVf8L37ep62+0ZKu5kQUEWe/Jz5ABgF?=
 =?us-ascii?Q?tU9Hq3VaEeMzvLUrAwSESUmSdbPfr+/zmRhdiTa+2FlBTBnS2YUCO6E2xVxF?=
 =?us-ascii?Q?rdKBcoc8aEwzPZcDkogfdBNdQonJT0eGOduQ264hDA7Dr0aObLG8PVo6v717?=
 =?us-ascii?Q?1lNB72nV/5nbNAIuYNLeVSOa5/GPkOMUsLCw8U/PTrCzr+ziCu4mxgqmAWuN?=
 =?us-ascii?Q?ceXTBmOP1K5ogxrrZn7fVIQQPGCEHE0ll8XGoUsjtYNg+rzk290JPxRUnNum?=
 =?us-ascii?Q?pwW+jcldzPOuhpv+oCPFDIK9OSExR61hk7rS2fFqD0VQSUxmC4tOjJfz95tm?=
 =?us-ascii?Q?E43IwhF0/Mqe76sEuKccIJOLG3rlNfrfmuO8Mu1DQVpKRnVOAlLZJZ8GSHM1?=
 =?us-ascii?Q?FytoYG4P2CNQsTDuOGZH6q2ENoe0y4ZzJCpgAFQ4mKdDy3eUW3D6Xym98X+M?=
 =?us-ascii?Q?G2pPKlsZLxhL230JkitWC0u23jLFKhY8fvzcti5u/wu6/RCPCQeO30OzmyA8?=
 =?us-ascii?Q?iQubIBFW4VZYDJckWghA/3vv7RYtnLeE6lv1VabbCujJ0KWktNoNpZHmNazI?=
 =?us-ascii?Q?zoABR5by0s8mSgLGK8dJrKK9Sy8cC646gWHhwXtfNcHR9UDr4aEoBKo7J31e?=
 =?us-ascii?Q?GXHrgby9+ZDBjnIE7n6fYe6v2cTYfIYl7GKiN711n2Nl9U6uCDRU+REVm4fN?=
 =?us-ascii?Q?vUadX7OlItgEXxkLqtFV/YYIWvcrZbuEiL3zt9FkXcja066GAYkbkeYaZE2F?=
 =?us-ascii?Q?CMURV8uf2Ht61pXJf/PdsDgikLJuoJC/0J6Yb1kbhaH3iWZVpfGZT1+T38Bs?=
 =?us-ascii?Q?R9qcfU1M7O/64nTmF268I69WURZldWjWzuNfgaYWg2u9joS3V4b8mbT/EZ1B?=
 =?us-ascii?Q?9GbEG+4TDFCRSuXP5D4cR9nQc2iuDJ5Jm5kK1rsWALvI21AtxqY/+HvwCDC6?=
 =?us-ascii?Q?NoAbwEJS7CnJCPloPHRd0+ogtSA6bYEb6SOZBjs7pGgvkK1eNQ66i0NHr5vu?=
 =?us-ascii?Q?Kc20i3+8FUj/Pic5+y+AU+IaOtsSd2oYyU3t9FL2BvsSamGUxBxFsjAjki6Z?=
 =?us-ascii?Q?ORG+bjaghj36VKv2c/mriJyauTyiRo0=3D?=
X-MS-Exchange-CrossTenant-Network-Message-Id: 1e391715-7f9d-45c1-f8b1-08da4a63e3d9
X-MS-Exchange-CrossTenant-AuthSource: DM4PR11MB6311.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 09 Jun 2022 22:03:31.2526
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 46c98d88-e344-4ed4-8496-4ed7712e255d
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: PMhyoMBKJWVhBJ3L/FfuT2NlgKpSkcws/mjVjrWllPu+VhegX5TXrxQEPJPsrJJ6od29sySmeSoqxuhuUlR1hg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA2PR11MB4970
X-OriginatorOrg: intel.com
X-Spam-Status: No, score=-5.6 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,
        DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_MED,
        SPF_HELO_NONE,SPF_NONE,T_SCC_BODY_TEXT_LINE,URIBL_BLOCKED
        autolearn=ham autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on
        lindbergh.monkeyblade.net
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Thu, Jun 09, 2022 at 09:27:38AM +0100, Jonathan Cameron wrote:
> On Wed, 8 Jun 2022 14:27:14 -0700
> Ira Weiny <ira.weiny@intel.com> wrote:
> 
> > On Mon, Jun 06, 2022 at 11:15:41AM -0700, Ben Widawsky wrote:
> > > On 22-06-04 17:50:46, ira.weiny@intel.com wrote:  
> > > > From: Jonathan Cameron <Jonathan.Cameron@huawei.com>
> > > >   
> > 
> 
> [snip]
> 
> > >   
> > > > +
> > > > +		entry = cdat_response_pl + 1;
> > > > +		entry_dw = task.rv / sizeof(u32);
> > > > +		/* Skip Header */
> > > > +		entry_dw -= 1;
> > > > +		entry_dw = min(length / 4, entry_dw);
> > > > +		memcpy(data, entry, entry_dw * sizeof(u32));
> > > > +		length -= entry_dw * sizeof(u32);
> > > > +		data += entry_dw;
> > > > +		entry_handle = FIELD_GET(CXL_DOE_TABLE_ACCESS_ENTRY_HANDLE, cdat_response_pl[0]);  
> > > 
> > > [0] looks suspicious...  
> > 
> > Actually I have to claim ignorance on this one.  I've carried this from
> > Jonathan's original patches.  I'm not as worried about the [0] as that is just
> > the first dword.  But I'm confused as to this entry handle now.
> > 
> > Jonathan?  Help?
> 
> Looks right to me.  The entryhandle is a field in the upper 16 bits of the
> first dword defined in Read Entry Response table in the CXL spec and also
> used in the request of the next entry (which is more or less a CDAT structure)
> Two magic values.
> 0 -  CDAT header (request only - can't be returned)
> 0xFFFF - No more entries.

Thanks!

> 
> As we are reading the whole table, we write 0 to first request and from there
> on use the value returned in the response for the next request until we see
> 0xFFFF and stop.
> 
> Note IIRC the meaning of entry handle was clarified in a CXL 2.0 errata as
> was a bit ambiguous in the original spec (we had two QEMU implementations
> briefly and they did different things :)

I see it now!  I'm going to add a define for 0xFFFF as well.

Ira

> 
> Jonathan
> 
> 
> > 
> > >   
> > > > +
> > > > +	} while (entry_handle != 0xFFFF);
> > > > +
> > > > +	return rc;
> > > > +}
> > > > +
> 
>