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 X-Spam-Level: X-Spam-Status: No, score=-3.8 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id AE44DC3A5A0 for ; Mon, 20 Apr 2020 14:35:14 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 8DEDB20735 for ; Mon, 20 Apr 2020 14:35:14 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729922AbgDTOfN (ORCPT ); Mon, 20 Apr 2020 10:35:13 -0400 Received: from mout.kundenserver.de ([212.227.126.131]:59495 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726895AbgDTOfN (ORCPT ); Mon, 20 Apr 2020 10:35:13 -0400 Received: from mail-qt1-f169.google.com ([209.85.160.169]) by mrelayeu.kundenserver.de (mreue012 [212.227.15.129]) with ESMTPSA (Nemesis) id 1N45th-1jHMUx43rV-0105HW for ; Mon, 20 Apr 2020 16:35:11 +0200 Received: by mail-qt1-f169.google.com with SMTP id z90so8546168qtd.10 for ; Mon, 20 Apr 2020 07:35:10 -0700 (PDT) X-Gm-Message-State: AGi0PuahG27kNBpjdzcO8xGat2cRhoSuipOu9DeBfwE9kl1pmWQdFXNQ haSFqGcfe8HUzkjtGcwnl8uhXEH871fVyKBULNc= X-Google-Smtp-Source: APiQypJ8+eSyM92GKz+tgktc3MN8Tu0mYjJI8QaeKzhQGr6nLHXQdvHnLZbXBCSy5i2jRKmsTpsr3bDsRZBUFnm0wII= X-Received: by 2002:ac8:6757:: with SMTP id n23mr16212594qtp.304.1587393309871; Mon, 20 Apr 2020 07:35:09 -0700 (PDT) MIME-Version: 1.0 References: <20200420030538.101696-1-wenhu.wang@vivo.com> In-Reply-To: <20200420030538.101696-1-wenhu.wang@vivo.com> From: Arnd Bergmann Date: Mon, 20 Apr 2020 16:34:53 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v2,RESEND] misc: new driver sram_uapi for user level SRAM access To: Wang Wenhu Cc: gregkh , "linux-kernel@vger.kernel.org" , linuxppc-dev , kernel@vivo.com, Rob Herring , Christophe Leroy , Scott Wood , Michael Ellerman , Randy Dunlap Content-Type: text/plain; charset="UTF-8" X-Provags-ID: V03:K1:f2KcBoQYKMkDgGCqtwpUxjQ4BrGLgCXosMUHdU42ZMlCwfboEx8 o/UC7mLD3M1uD0ncxhJGmDjhNLwiSu78TGgPbleNfkhx21n1gOXYeZUzRyTvugdC2q1gGQM FkTekJondpUYpvFiQxXMKGCX6cXF1jF3EN/LSXIxh1c8fkj7SUKL8KR33wQLlgDgTTK5s3t UaG8sQunweBBFU5PG13FA== X-UI-Out-Filterresults: notjunk:1;V03:K0:t2mjBYshxc4=:Zm43rhuYlnsdUeOB8eHDHk hIgV2c+XbsOAyna+DhZFIKrk/2ujUMs7rAfT0VHZCPnFdhWxyR5A2LXUXFJY0dMeDWzmJokAK qPyOwgT5kA9nUBqB793UeZf4R2cSx1dbQ74pA8LERnVbqjCFNXPPSKwU7ZmmcTIQUXgBCXJA/ +FdOZlalnLoByUi+KAQ4JC3tFQD64cjRnRVJT2uDJEZwOf2Tm8PbVhgnZ9fVv3AO/wRN+MunM 3hBQ5tb9jHutdTd9PULZ6ieJGvSrPzT1/IHivuUI5jx3f9IwjWMoMD1GPqPJgM23KI4OjIiIh BZjv4gsQGgWZFwE3iuCX3aTlZGa16suvAKEtq3z8LX8+861FMPsqV1UroclTtRPY8PYnfCcQ+ DolqCOb1hykFRkHpnBPn2vb9GQMjSYnQILVMI350IYy4gmtb2uby2wLJTL+8mLg3gdN8lJvk0 j8ayH7ZwFuS33B0VSNFxD4L7aBSeSe2OAI/9DDAYdE3rsmhTvLFO0A2MWMnR/QTp6a7D1M4pJ +ArrZ+p7toPRAB0aMLVPv8/j+6Z+9FsGaTY/CK4SmwA4mpzP0qGqrFOyBCMATEDNYO0s4pTUx UVPUPNmHAbz0xYJwVrIQsqzG3z7NshtVq5jO4N+4z5Y0ynkstGTr9GpQ4tNbhzJ61xulnwbsG NeXtuABeqz0oGTTy/K5fATECbZo/6t2ge5NOdZAwNw0zc1WHWzPl+i27aGEE/GK37CB9ES4jo 1tTZvQabQCDzYKD0dVFc4ZUrDbnBEA0SGi9oKEtPGbyHtQFTfUYm8FHJWZ7bE2vVZQaTLggR9 sMtbGuj9ON8Vcoy6/XQ20Um4nU48wXEnbbIKNMaEw+Ms/bo/4s= Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Apr 20, 2020 at 5:06 AM Wang Wenhu wrote: > > A generic User-Kernel interface that allows a misc device created > by it to support file-operations of ioctl and mmap to access SRAM > memory from user level. Different kinds of SRAM alloction and free > APIs could be registered by specific SRAM hardware level driver to > the available list and then be chosen by users to allocate and map > SRAM memory from user level. > > It is extremely helpful for the user space applications that require > high performance memory accesses, such as embedded networking devices > that would process data in user space, and PowerPC e500 is a case. > > Signed-off-by: Wang Wenhu > Cc: Greg Kroah-Hartman > Cc: Arnd Bergmann > Cc: Christophe Leroy > Cc: Scott Wood > Cc: Michael Ellerman > Cc: Randy Dunlap > Cc: linuxppc-dev@lists.ozlabs.org > --- > Changes since v1: addressed comments from Arnd > * Changed the ioctl cmd definitions using _IO micros > * Export interfaces for HW-SRAM drivers to register apis to available list > * Modified allocation alignment to PAGE_SIZE > * Use phys_addr_t as type of SRAM resource size and offset > * Support compat_ioctl > * Misc device name:sram Looks much better already. > Note: From this on, the SRAM_UAPI driver is independent to any hardware > drivers, so I would only commit the patch itself as v2, while the v1 of > it was wrapped together with patches for Freescale L2-Cache-SRAM device. > Then after, I'd create patches for Freescale L2-Cache-SRAM device as > another series. What I meant to suggest was actually to tie it more closely to the code we already have in drivers/misc/sram.c, which already has some form of abstraction. > +static int __init sram_uapi_init(void) > +{ > + int ret; > + > + INIT_LIST_HEAD(&sram_api_list); > + mutex_init(&sram_api_list_lock); > + > + ret = misc_register(&sram_uapi_miscdev); > + if (ret) > + pr_err("failed to register sram uapi misc device\n"); The mutex and listhead are already initialized, so this can be a one-line function return misc_register(&sram_uapi_miscdev); > --- /dev/null > +++ b/include/linux/sram_uapi.h The ioctl definitions need to be in include/uapi/linux/ > @@ -0,0 +1,28 @@ > +/* SPDX-License-Identifier: GPL-2.0 */ > +#ifndef __SRAM_UAPI_H > +#define __SRAM_UAPI_H > + > +/* Set SRAM type to be accessed */ > +#define SRAM_UAPI_IOC_SET_SRAM_TYPE _IOW('S', 0, __u32) > + > +/* Allocate resource from SRAM */ > +#define SRAM_UAPI_IOC_ALLOC _IOWR('S', 1, struct res_info) > + > +/* Free allocated resource of SRAM */ > +#define SRAM_UAPI_IOC_FREE _IOW('S', 2, struct res_info) struct res_info needs to also be defined here, so user applications can see the definition, and it has to use __u64, not phys_addr_t, to ensure the API does not depend on kernel configuraiton. Arnd 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 X-Spam-Level: X-Spam-Status: No, score=-3.8 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 31F9AC3815B for ; Mon, 20 Apr 2020 14:39:41 +0000 (UTC) Received: from lists.ozlabs.org (lists.ozlabs.org [203.11.71.2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id DFF83206B9 for ; Mon, 20 Apr 2020 14:39:40 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org DFF83206B9 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=arndb.de Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Received: from lists.ozlabs.org (lists.ozlabs.org [IPv6:2401:3900:2:1::3]) by lists.ozlabs.org (Postfix) with ESMTP id 495TqY3lBXzDqsw for ; Tue, 21 Apr 2020 00:39:37 +1000 (AEST) Authentication-Results: lists.ozlabs.org; spf=none (no SPF record) smtp.mailfrom=arndb.de (client-ip=217.72.192.73; helo=mout.kundenserver.de; envelope-from=arnd@arndb.de; receiver=) Authentication-Results: lists.ozlabs.org; dmarc=none (p=none dis=none) header.from=arndb.de Received: from mout.kundenserver.de (mout.kundenserver.de [217.72.192.73]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 495TkZ288FzDqlm for ; Tue, 21 Apr 2020 00:35:16 +1000 (AEST) Received: from mail-qt1-f169.google.com ([209.85.160.169]) by mrelayeu.kundenserver.de (mreue108 [212.227.15.145]) with ESMTPSA (Nemesis) id 1N8GEY-1jDDlH1rTU-014FOt for ; Mon, 20 Apr 2020 16:35:11 +0200 Received: by mail-qt1-f169.google.com with SMTP id w24so8550628qts.11 for ; Mon, 20 Apr 2020 07:35:10 -0700 (PDT) X-Gm-Message-State: AGi0PuaysmT0acvOW6ysswbHEaNu9sHro+4APBZozI2rd5rIkTNHDNAX ptz5zwbiDBYCxw2nfpvm0vbLhwyG50j0QPIQGYg= X-Google-Smtp-Source: APiQypJ8+eSyM92GKz+tgktc3MN8Tu0mYjJI8QaeKzhQGr6nLHXQdvHnLZbXBCSy5i2jRKmsTpsr3bDsRZBUFnm0wII= X-Received: by 2002:ac8:6757:: with SMTP id n23mr16212594qtp.304.1587393309871; Mon, 20 Apr 2020 07:35:09 -0700 (PDT) MIME-Version: 1.0 References: <20200420030538.101696-1-wenhu.wang@vivo.com> In-Reply-To: <20200420030538.101696-1-wenhu.wang@vivo.com> From: Arnd Bergmann Date: Mon, 20 Apr 2020 16:34:53 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v2, RESEND] misc: new driver sram_uapi for user level SRAM access To: Wang Wenhu Content-Type: text/plain; charset="UTF-8" X-Provags-ID: V03:K1:W43FMOZC8GNxc8XRjIqPK/y7reIccZgcirU90SxBIBTKvVFY6ko r7Qgc8GCi9tcloIKqmgG1Ga3+h39q92gUQIwwclBEFs9UsHXeJMbU/v6RDp2qMotjtyGC4i HLWvXvmJKD7PgBs0QDC/GAQAoHYItAy0SUQrH3FThb1YlqAmLr5VulRwxsmHRwFff8LsScn WWwOyXQuawoOPy0fCnWdg== X-UI-Out-Filterresults: notjunk:1;V03:K0:lMlmaC4iy6c=:rzN2AeJB5fUFaE6l9rI9B6 mxX8pFHPtrzSDc+S06YMqyjlsd4xz+aIcTlxTg1O4hqP6wWJhTWfeJ3ANcentleyZIOxYIgTS aBPmw7IxHRDG3bQ2QKqx+14vJRhFDnQ0fFMKTGvOdhYiWSCzNTo4JzuTh9v3hVnYL9qgIt0pr 3dtAlpegf2mKNGPwuJNUIC/ra7iEcNXxfiAj/yX8ncUXWVUmb30XVumGgRuJ1qfqMkBhtEc2K /OSgQOhACzMaLaYW4CW/OBii2ITOL/+qwPrYQOBWM8LWhaB9DXY25cQyUGD/bZzP3ItwtbUFS nKoB+gN7ciQRQGMTRuVomVX+KZt+1uc9E1g7x0KVjkmV46G2TEMfB4Dv7ww2FmKY70/j3Lj28 E40einPLkc7IZAyDB9AYQE5issQXG3ddsyoPZCKzYPlvOzBPofNT6BQZqDY+zPJcvM28hQpCQ 3qORS5oSG5se+io5vTfWFdC7EJo81fWVqE+Kib5gzRTiTrJajs+bCu3nbDCc3+zFID4oNo+lz RPOFOkFw8S01OjwD6A8+LhJZAjAePyk1trh41xjnUFBx5WivjGJbnhad0LAKaXdqzNQW0r0lK 2dICkCRnqrkcYghpG8byWaY+bgDuMt39EABGV6Yrv54SmpBdLEupDDelq1cQaYyoi0pVTP77y qo5evJ/jCEZFlQBgC/8NgV3ix/ZmgTmfg4HvrSiJ6bSEOM/1pN4pXoWDmp4UqOXbRbpog84Sa 5XL74LpX8h5SXmeRgJ13yX47/c4VIMmdv1nAoS8cb9+ZIC5HJ8ViuE/V+zWgsrLo6MWg68sBM TyUse0L0Ky5OnJJhL0Tl8HvboPxXf8wx8VQ4JsCXz/uyScv5Is= X-BeenThere: linuxppc-dev@lists.ozlabs.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Rob Herring , gregkh , Randy Dunlap , "linux-kernel@vger.kernel.org" , Scott Wood , kernel@vivo.com, linuxppc-dev Errors-To: linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Sender: "Linuxppc-dev" On Mon, Apr 20, 2020 at 5:06 AM Wang Wenhu wrote: > > A generic User-Kernel interface that allows a misc device created > by it to support file-operations of ioctl and mmap to access SRAM > memory from user level. Different kinds of SRAM alloction and free > APIs could be registered by specific SRAM hardware level driver to > the available list and then be chosen by users to allocate and map > SRAM memory from user level. > > It is extremely helpful for the user space applications that require > high performance memory accesses, such as embedded networking devices > that would process data in user space, and PowerPC e500 is a case. > > Signed-off-by: Wang Wenhu > Cc: Greg Kroah-Hartman > Cc: Arnd Bergmann > Cc: Christophe Leroy > Cc: Scott Wood > Cc: Michael Ellerman > Cc: Randy Dunlap > Cc: linuxppc-dev@lists.ozlabs.org > --- > Changes since v1: addressed comments from Arnd > * Changed the ioctl cmd definitions using _IO micros > * Export interfaces for HW-SRAM drivers to register apis to available list > * Modified allocation alignment to PAGE_SIZE > * Use phys_addr_t as type of SRAM resource size and offset > * Support compat_ioctl > * Misc device name:sram Looks much better already. > Note: From this on, the SRAM_UAPI driver is independent to any hardware > drivers, so I would only commit the patch itself as v2, while the v1 of > it was wrapped together with patches for Freescale L2-Cache-SRAM device. > Then after, I'd create patches for Freescale L2-Cache-SRAM device as > another series. What I meant to suggest was actually to tie it more closely to the code we already have in drivers/misc/sram.c, which already has some form of abstraction. > +static int __init sram_uapi_init(void) > +{ > + int ret; > + > + INIT_LIST_HEAD(&sram_api_list); > + mutex_init(&sram_api_list_lock); > + > + ret = misc_register(&sram_uapi_miscdev); > + if (ret) > + pr_err("failed to register sram uapi misc device\n"); The mutex and listhead are already initialized, so this can be a one-line function return misc_register(&sram_uapi_miscdev); > --- /dev/null > +++ b/include/linux/sram_uapi.h The ioctl definitions need to be in include/uapi/linux/ > @@ -0,0 +1,28 @@ > +/* SPDX-License-Identifier: GPL-2.0 */ > +#ifndef __SRAM_UAPI_H > +#define __SRAM_UAPI_H > + > +/* Set SRAM type to be accessed */ > +#define SRAM_UAPI_IOC_SET_SRAM_TYPE _IOW('S', 0, __u32) > + > +/* Allocate resource from SRAM */ > +#define SRAM_UAPI_IOC_ALLOC _IOWR('S', 1, struct res_info) > + > +/* Free allocated resource of SRAM */ > +#define SRAM_UAPI_IOC_FREE _IOW('S', 2, struct res_info) struct res_info needs to also be defined here, so user applications can see the definition, and it has to use __u64, not phys_addr_t, to ensure the API does not depend on kernel configuraiton. Arnd