From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 97534C433EF for ; Fri, 8 Jul 2022 15:04:24 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S238482AbiGHPEX (ORCPT ); Fri, 8 Jul 2022 11:04:23 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:56990 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S238189AbiGHPEV (ORCPT ); Fri, 8 Jul 2022 11:04:21 -0400 Received: from casper.infradead.org (casper.infradead.org [IPv6:2001:8b0:10b:1236::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 5E7F52F67E; Fri, 8 Jul 2022 08:04:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=3jpvp1J2V3RiYjdNlHd4/ahZAB1KUqyXlwmwoUipWJ0=; b=e+7GDgz79BPotjw0lqXGRpcd/B OJkyo7ZfBI5HADrhmC15E51UM2IZDoZ+5zsP6A8p7dfQMyPpXNoN/k6FIKqZg8nTJsDigOEg25ZU/ hUHIeSNm96S6FVnqqKSG0ALs3dNA0lBWk4l0haqvkZMmTS9l6YDquQQZDw92MsZWd2+xit4RC4n+7 VKvG3pFYh8rMWwcqt4ebIIVNRhA/a59eOhYVcsQQzF3hWuxvdOlOrI8gZtwrXMhLmMFsEIERyTgHm KY4eQuyAyk79Tph0/kfYFPo9pRr8dCFiv4mn6o9AKah48N71tdHo+tvD+4fk6GdfLljZA0ApPMHj0 vMU6//og==; Received: from willy by casper.infradead.org with local (Exim 4.94.2 #2 (Red Hat Linux)) id 1o9pWX-003aRS-WF; Fri, 08 Jul 2022 15:04:06 +0000 Date: Fri, 8 Jul 2022 16:04:05 +0100 From: Matthew Wilcox To: Ira Weiny Cc: Bjorn Helgaas , Dan Williams , Greg Kroah-Hartman , "Rafael J. Wysocki" , Alison Schofield , Vishal Verma , linux-kernel@vger.kernel.org, linux-cxl@vger.kernel.org, linux-pci@vger.kernel.org, linux-fsdevel@vger.kernel.org Subject: Re: [RFC PATCH 2/3] pci/doe: Use devm_xa_init() Message-ID: References: <20220705232159.2218958-3-ira.weiny@intel.com> <20220707160646.GA306751@bhelgaas> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-fsdevel@vger.kernel.org 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)