Received: by 10.223.185.116 with SMTP id b49csp351910wrg; Tue, 20 Feb 2018 22:45:18 -0800 (PST) X-Google-Smtp-Source: AH8x227zAKtOQjvvcmrqWLrOuFLIgwii0DE/Ko/J860O5y8HH9ySflXJ8NoO7tWV+wsfjSeBd0mH X-Received: by 2002:a17:902:bc41:: with SMTP id t1-v6mr2208484plz.436.1519195518107; Tue, 20 Feb 2018 22:45:18 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1519195518; cv=none; d=google.com; s=arc-20160816; b=RnuyVneBWboCbBVMgxTZiQZ0Fx44lkaiy2wWIqrBBJCwhL9vMXEUlcKYUmVNBFRKYM kwZyf9LxuAtt/R7ZUcDTIjDS7YQmtAXzuy/vwP7eYiwowD9ehezxoIOdqxSUbRnhzgxN 4TqCzCnTfYW/a0kPgX76d28+TSmztGc4fa6yxhPLwhBxySb7hmGPArovnfv6N4Fbx/rs BvqiNuF4zLFpF18IaJx9Ouz1aHVB7T6xPpCGKElMl0cbY0ME57AYHfx2RyCv0THbHDTX gZg6ZuBLiHwvLTp4Bm5sZCeL/9uRfzs2/g8ghzIfQMbfYZggJrOQgEnJUGnxHiTrxhP7 I4oA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :references:in-reply-to:mime-version:dkim-signature :arc-authentication-results; bh=64ry4OZkVn+2Yh1MKbAwhjodZJLnoMiKFiLy5Jp00bo=; b=lGQTOrzA7DKlW6NWuZGKx35EvvY1kQu6s4JkwJw2vjUPm8gGm20ZYPcUXldJ8AO41F 8LkbMhQpDu/HiQI2ojkkTJLi27A3DPR4PPCRrq+GE2krzyennWnugwshCL2BiKwsUTCe d0CeHyeSB2Hx2dtegf7CHhMEOJZKCpwWTfzagEpPmSSfCMMUszVXXbSHCDDZXFZ6PRPY BfUTQnYXBxmizlfNAiKBSslwmeQdzPLdavHULp/6qZ65ay+atRD/2no0o0jCx5qqyS6e elEwrTIhmjTpxSe1iqnW8BHhaY3ctmmMu0gCG/vpZk4smIuA+M2DOtQVuBPXYP0MGXrD 6ceQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=N6cX49/W; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id b29si642123pfh.294.2018.02.20.22.44.53; Tue, 20 Feb 2018 22:45:18 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=N6cX49/W; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751362AbeBUGoC (ORCPT + 99 others); Wed, 21 Feb 2018 01:44:02 -0500 Received: from mail-ua0-f196.google.com ([209.85.217.196]:33780 "EHLO mail-ua0-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750740AbeBUGoB (ORCPT ); Wed, 21 Feb 2018 01:44:01 -0500 Received: by mail-ua0-f196.google.com with SMTP id p12so387578uad.0 for ; Tue, 20 Feb 2018 22:44:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=64ry4OZkVn+2Yh1MKbAwhjodZJLnoMiKFiLy5Jp00bo=; b=N6cX49/WUh8tWQom6mZIIWREg6P3J6O1yzQ6Lut0JQLmgqku/Ox/Oq3kS8p2QRnJPV f8NiWSQtx5IqbcIYhM8Unqp9QNZ1tkVr2Rh0csVDrmfw4Jw4jwZ/YpqI/HfMDEzS92kW 1hX4Ka3GRTJW0puU+P0SIZoVfZvFDoPHhduTau4C2ElAREvOnlJO4dsZB6Zx6EbO1RK7 MNGgMMI+iGA4khse5bXVDKIrmXmxjpX8wnBb0BkhIECngLtyqxLdFp4b6AohFQZt1rZ8 Hc8vp2nTj5TeeH2BMgZwsKtACl8HJes444DpiuvdKB3H2Cv2Jv6YnkLg4V+rUCd51o+7 dkVA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=64ry4OZkVn+2Yh1MKbAwhjodZJLnoMiKFiLy5Jp00bo=; b=EH6FKIstxhDG3aaAfwDG9biygKA+Ug9QU3b1uoLk7fXM+Ia9aGs0EEZENr0PqDyayg Ep2ejyIZxE3vEaAJk3vydrevTh+GzCQDmJ82zd+6PnNEjUh8GXg0dfqkJmXv332ocXFj 2bFryAos7qncdDSHVadj5Iql3MLtbJxR21LIFr9yOzhIhoSPFp1TxLd7hqlmvrAdcU0J hxg7Z3KyK4iacvEHa7nsM00U6Z2P0ekJnGRrZUiLLFXtrBqNeyfEk/INoF1DZMgvbrYr 0aKbOPOQ3PqAG544pL45zSiGZS9SAe5R59hlQ1ApLiqCHNwkrmyrp8ZdLwqoRNwxAOU9 IJ9g== X-Gm-Message-State: APf1xPDkuhNPXF+5RHS9bcAKeK6Ac2soqs0a1s6Wyvaol8Yof5KWzR4M vu+NEnq+PQXdba/R8UeQUk7WL5fckHQRqVpAzeQ= X-Received: by 10.159.52.101 with SMTP id s37mr1746782uab.24.1519195440576; Tue, 20 Feb 2018 22:44:00 -0800 (PST) MIME-Version: 1.0 Received: by 10.176.97.142 with HTTP; Tue, 20 Feb 2018 22:43:59 -0800 (PST) In-Reply-To: <20180221045736.7614-1-alastair@au1.ibm.com> References: <20180221045736.7614-1-alastair@au1.ibm.com> From: Balbir Singh Date: Wed, 21 Feb 2018 17:43:59 +1100 Message-ID: Subject: Re: [PATCH] ocxl: Add get_metadata IOCTL to share OCXL information to userspace To: "Alastair D'Silva" Cc: linuxppc-dev , "linux-kernel@vger.kernel.org" , Arnd Bergmann , frederic.barrat@fr.ibm.com, Greg KH , Andrew Donnellan , "Alastair D'Silva" Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Feb 21, 2018 at 3:57 PM, Alastair D'Silva wrote: > From: Alastair D'Silva > > Some required information is not exposed to userspace currently (eg. the > PASID), pass this information back, along with other information which > is currently communicated via sysfs, which saves some parsing effort in > userspace. > > Signed-off-by: Alastair D'Silva > --- > drivers/misc/ocxl/file.c | 27 +++++++++++++++++++++++++++ > include/uapi/misc/ocxl.h | 22 ++++++++++++++++++++++ > 2 files changed, 49 insertions(+) > > diff --git a/drivers/misc/ocxl/file.c b/drivers/misc/ocxl/file.c > index d9aa407db06a..11514a8444e5 100644 > --- a/drivers/misc/ocxl/file.c > +++ b/drivers/misc/ocxl/file.c > @@ -102,10 +102,32 @@ static long afu_ioctl_attach(struct ocxl_context *ctx, > return rc; > } > > +static long afu_ioctl_get_metadata(struct ocxl_context *ctx, > + struct ocxl_ioctl_get_metadata __user *uarg) Why do we call this metadata? Isn't this an afu_descriptor? > +{ > + struct ocxl_ioctl_get_metadata arg; > + > + memset(&arg, 0, sizeof(arg)); > + > + arg.version = 0; Does it make sense to have version 0? Even if does, you can afford to skip initialization due to the memset above. I prefer that versions start with 1 > + > + arg.afu_version_major = ctx->afu->config.version_major; > + arg.afu_version_minor = ctx->afu->config.version_minor; > + arg.pasid = ctx->pasid; > + arg.pp_mmio_size = ctx->afu->config.pp_mmio_stride; > + arg.global_mmio_size = ctx->afu->config.global_mmio_size; > + > + if (copy_to_user(uarg, &arg, sizeof(arg))) > + return -EFAULT; > + > + return 0; > +} > + > #define CMD_STR(x) (x == OCXL_IOCTL_ATTACH ? "ATTACH" : \ > x == OCXL_IOCTL_IRQ_ALLOC ? "IRQ_ALLOC" : \ > x == OCXL_IOCTL_IRQ_FREE ? "IRQ_FREE" : \ > x == OCXL_IOCTL_IRQ_SET_FD ? "IRQ_SET_FD" : \ > + x == OCXL_IOCTL_GET_METADATA ? "GET_METADATA" : \ > "UNKNOWN") > > static long afu_ioctl(struct file *file, unsigned int cmd, > @@ -157,6 +179,11 @@ static long afu_ioctl(struct file *file, unsigned int cmd, > irq_fd.eventfd); > break; > > + case OCXL_IOCTL_GET_METADATA: > + rc = afu_ioctl_get_metadata(ctx, > + (struct ocxl_ioctl_get_metadata __user *) args); > + break; > + > default: > rc = -EINVAL; > } > diff --git a/include/uapi/misc/ocxl.h b/include/uapi/misc/ocxl.h > index 4b0b0b756f3e..16e1f48ce280 100644 > --- a/include/uapi/misc/ocxl.h > +++ b/include/uapi/misc/ocxl.h > @@ -32,6 +32,27 @@ struct ocxl_ioctl_attach { > __u64 reserved3; > }; > > +/* > + * Version contains the version of the struct. > + * Versions will always be backwards compatible, that is, new versions will not > + * alter existing fields > + */ > +struct ocxl_ioctl_get_metadata { This sounds more like a function name, do we need it to be _get_metdata? > + __u16 version; > + > + // Version 0 fields > + __u8 afu_version_major; > + __u8 afu_version_minor; > + __u32 pasid; > + > + __u64 pp_mmio_size; > + __u64 global_mmio_size; > + Should we document the fields? pp_ stands for per process, but is not very clear at first look. Why do we care to return only the size, what about lpc size? > + // End version 0 fields > + > + __u64 reserved[13]; // Total of 16*u64 > +}; Balbir Singh.