[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <YshHZXK/dq3apNDu@casper.infradead.org>
Date: Fri, 8 Jul 2022 16:04:05 +0100
From: Matthew Wilcox <willy@...radead.org>
To: Ira Weiny <ira.weiny@...el.com>
Cc: Bjorn Helgaas <helgaas@...nel.org>,
Dan Williams <dan.j.williams@...el.com>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
"Rafael J. Wysocki" <rafael@...nel.org>,
Alison Schofield <alison.schofield@...el.com>,
Vishal Verma <vishal.l.verma@...el.com>,
linux-kernel@...r.kernel.org, linux-cxl@...r.kernel.org,
linux-pci@...r.kernel.org, linux-fsdevel@...r.kernel.org
Subject: Re: [RFC PATCH 2/3] pci/doe: Use devm_xa_init()
On Fri, Jul 08, 2022 at 07:57:10AM -0700, Ira Weiny wrote:
> > > 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.
It does, *but* ...
static inline void *xa_mk_value(unsigned long v)
{
WARN_ON((long)v < 0);
return (void *)((v << 1) | 1);
}
... you can't pass an integer that has the top bit set to it.
> Can't I use xa_mk_value() to store data directly in the entry "pointer"?
Yes, that's the purpose of xa_mk_value(). From what you said, it sounded
like you were just storing the integer directly, which won't work.
> +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?
You haven't tested that on 32-bit, have you? Shift vid by 8 instead of
16, and it'll be fine.
(Oh, and you don't need to cast vid; the standard C integer promotions
will promote vid to int before shifting, and you won't lose any bits)
Powered by blists - more mailing lists