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@xxxxxxxxx> wrote: > > > On Mon, Jun 06, 2022 at 11:15:41AM -0700, Ben Widawsky wrote: > > > On 22-06-04 17:50:46, ira.weiny@xxxxxxxxx wrote: > > > > From: Jonathan Cameron <Jonathan.Cameron@xxxxxxxxxx> > > > > > > > > [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; > > > > +} > > > > + > >
