Messages in this thread | | | Date | Fri, 8 Jul 2022 07:57:10 -0700 | From | Ira Weiny <> | Subject | Re: [RFC PATCH 2/3] pci/doe: Use devm_xa_init() |
| |
On Fri, Jul 08, 2022 at 03:49:51PM +0100, Matthew Wilcox wrote: > On Fri, Jul 08, 2022 at 07:45:12AM -0700, Ira Weiny wrote: > > On Thu, Jul 07, 2022 at 11:06:46AM -0500, Bjorn Helgaas wrote: > > > On Tue, Jul 05, 2022 at 04:21:58PM -0700, ira.weiny@intel.com wrote: > > > > From: Ira Weiny <ira.weiny@intel.com> > > > > > > > > The XArray being used to store the protocols does not even store > > > > allocated objects. > > > > > > I guess the point is that the doe_mb->prots XArray doesn't reference > > > any other objects that would need to be freed when destroying > > > doe_mb->prots? > > > > Yes. > > > > > A few more words here would make the commit log more > > > useful to non-XArray experts. > > > > I'll update this to be more clear in a V1 if it goes that far. But to clarify > > here; the protocol information is a u16 vendor id and u8 protocol number. So > > we are able to store that in the unsigned long value that would normally be a > > pointer to something in the XArray. > > Er. Signed long.
Sorry I misspoke, xa_mk_value() takes an unsigned long.
> I can't find drivers/pci/doe.c in linux-next, so > I have no idea if you're doing something wrong.
Sorry doe.c does not exist yet. I came up with this idea while developing a CXL series which is still in review.[0]
> But what you said here > sounds wrong.
:-/
Can't I use xa_mk_value() to store data directly in the entry "pointer"?
From patch 3/9 in that series.[1]
+static void *pci_doe_xa_prot_entry(u16 vid, u8 prot) +{ + return xa_mk_value(((unsigned long)vid << 16) | prot); +}
Both Dan and I thought this was acceptable in XArray?
Ira
[0] https://lore.kernel.org/linux-cxl/20220705154932.2141021-1-ira.weiny@intel.com/ [1] https://lore.kernel.org/linux-cxl/20220705154932.2141021-4-ira.weiny@intel.com/
| |