Received: by 2002:a25:1985:0:0:0:0:0 with SMTP id 127csp226062ybz; Thu, 23 Apr 2020 22:31:01 -0700 (PDT) X-Google-Smtp-Source: APiQypK1bJucvKuryOnodjjNnmanrrTQYKCjGQgEnwTbdy7RPUx3yKHjkt6y60Ecv839oTkM3xyL X-Received: by 2002:a05:6402:2d5:: with SMTP id b21mr5474375edx.291.1587706261524; Thu, 23 Apr 2020 22:31:01 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1587706261; cv=none; d=google.com; s=arc-20160816; b=axcrX0LBP1/af6OnPzAOngXLQt2+dVI+nrFQLoJ35Oor3rut1vhHXTe00mOGSPQQLM RuE8+8HbUfbm57kXUFvb6UBo2aZIPzeCGJ9EZsFYhnfzHdJAS9/boPBE4Q9iPkvNfi37 3HOlbIh6pIJUaZoVAHMbJYyKPCPUWDk+C60p5viCSJ9Y7CNMlG4CdAjzeoj0XugsI3rR bZ0GEC79PTlIXUIqMzrAzCpY7S16I4MxMz0BUpkWZn+RolEbNJOG/fszqzUDvRL5DEXy s09nCr1CempoX/CQQMtYFvPiohFAWdPu3hxK4Gf0aZa3VfSmWouWhuIckH90N6PjxZpl r9lw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject:dkim-signature; bh=iMRb+wlAbT9tTesvDqOU7UfChF4hn+WeV+Drvq5rbHI=; b=pNuk5xJu70wjLTuhgBqBQ5H6al6EKY+UcS/yy9l7/iliNOyjbml+e70B/qYKkEuvBb 2SfQMRn2kWeiY5gVwSvEiybsO5suEzVWyh4lOEu5YH2xMWRhMeHVuAyfyoMXghPIJaIo Zo/NTzjtCcgfz7lYVCiZFIfBOmAMyP6F3qfO7lji2iqMxIsI2vdNnatUJhUYKMNA3i3q 4Qtf9+M9cg4RVbJS5Wrb0NBO9dw+84hyQFbP69dn25veaERzkrXtp6qdODpCDiFNQM97 5JNYucPmNbEegzg0eneIINku382aUUQw4z3WHH3lDANZ2mTnB8b/4OgpV46OMI/8NDLV 7buA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@c-s.fr header.s=mail header.b="p/CeMaob"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id fx19si2550629ejb.39.2020.04.23.22.30.36; Thu, 23 Apr 2020 22:31:01 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@c-s.fr header.s=mail header.b="p/CeMaob"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726072AbgDXF3R (ORCPT + 99 others); Fri, 24 Apr 2020 01:29:17 -0400 Received: from pegase1.c-s.fr ([93.17.236.30]:3026 "EHLO pegase1.c-s.fr" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725554AbgDXF3Q (ORCPT ); Fri, 24 Apr 2020 01:29:16 -0400 Received: from localhost (mailhub1-int [192.168.12.234]) by localhost (Postfix) with ESMTP id 497jQd5HmzzB09ZR; Fri, 24 Apr 2020 07:29:13 +0200 (CEST) Authentication-Results: localhost; dkim=pass reason="1024-bit key; insecure key" header.d=c-s.fr header.i=@c-s.fr header.b=p/CeMaob; dkim-adsp=pass; dkim-atps=neutral X-Virus-Scanned: Debian amavisd-new at c-s.fr Received: from pegase1.c-s.fr ([192.168.12.234]) by localhost (pegase1.c-s.fr [192.168.12.234]) (amavisd-new, port 10024) with ESMTP id aRmv_O6GNT6o; Fri, 24 Apr 2020 07:29:13 +0200 (CEST) Received: from messagerie.si.c-s.fr (messagerie.si.c-s.fr [192.168.25.192]) by pegase1.c-s.fr (Postfix) with ESMTP id 497jQd40M3zB09ZQ; Fri, 24 Apr 2020 07:29:13 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=c-s.fr; s=mail; t=1587706153; bh=iMRb+wlAbT9tTesvDqOU7UfChF4hn+WeV+Drvq5rbHI=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=p/CeMaobek2OPGDCrpFoY1qqHPJYzHxkZEOHYkJ+YYFj1jcZwD6PgYSWCsJygdgQr w9FX+vWDJDV5wT41AkVR8Ptl6bv3il+kIxTtBGgGkH0gmlJCtwrTMHb0fvc9UxTo4U kfeM1rAA019PaNmTzOtYPXXBFPiDsIG6azYcqNFQ= Received: from localhost (localhost [127.0.0.1]) by messagerie.si.c-s.fr (Postfix) with ESMTP id 73FD38B775; Fri, 24 Apr 2020 07:29:14 +0200 (CEST) X-Virus-Scanned: amavisd-new at c-s.fr Received: from messagerie.si.c-s.fr ([127.0.0.1]) by localhost (messagerie.si.c-s.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id aYWzi7ORRw48; Fri, 24 Apr 2020 07:29:14 +0200 (CEST) Received: from [192.168.4.90] (unknown [192.168.4.90]) by messagerie.si.c-s.fr (Postfix) with ESMTP id E3C948B75E; Fri, 24 Apr 2020 07:29:11 +0200 (CEST) Subject: Re: [PATCH v3,5/5] powerpc: sysdev: support userspace access of fsl_85xx_sram To: Wang Wenhu , gregkh@linuxfoundation.org, arnd@arndb.de, linux-kernel@vger.kernel.org, linuxppc-dev@lists.ozlabs.org Cc: oss@buserror.net, kernel@vivo.com, robh@kernel.org, benh@kernel.crashing.org, paulus@samba.org, Michael Ellerman References: <20200424024554.30709-1-wenhu.wang@vivo.com> <20200424024554.30709-6-wenhu.wang@vivo.com> From: Christophe Leroy Message-ID: <0dfd17ca-d11e-9cf3-177e-bce0b8eace5c@c-s.fr> Date: Fri, 24 Apr 2020 07:29:09 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: <20200424024554.30709-6-wenhu.wang@vivo.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Le 24/04/2020 à 04:45, Wang Wenhu a écrit : > New module which registers its memory allocation and free APIs to the > sram_dynamic module, which would create a device of struct sram_device > type to act as an interface for user level applications to access the > backend hardware device, fsl_85xx_cache_sram, which is drived by the > FSL_85XX_CACHE_SRAM module. > > Signed-off-by: Wang Wenhu > Cc: Christophe Leroy > Cc: Scott Wood > Cc: Michael Ellerman > Cc: Greg Kroah-Hartman > Cc: Arnd Bergmann > Cc: linuxppc-dev@lists.ozlabs.org > --- > .../powerpc/include/asm/fsl_85xx_cache_sram.h | 4 ++ > arch/powerpc/platforms/85xx/Kconfig | 10 +++++ > arch/powerpc/sysdev/Makefile | 1 + > arch/powerpc/sysdev/fsl_85xx_cache_ctlr.h | 6 +++ > arch/powerpc/sysdev/fsl_85xx_cache_sram.c | 12 ++++++ > arch/powerpc/sysdev/fsl_85xx_sram_uapi.c | 39 +++++++++++++++++++ > 6 files changed, 72 insertions(+) > create mode 100644 arch/powerpc/sysdev/fsl_85xx_sram_uapi.c We shouldn't add more stuff in arch/powerpc/sysdev/ Either it is dedicated to 85xx, and it should go into arch/powerpc/platform/85xx/ , or it is common to several platforms/architectures and should be moved to drivers/soc/fsl/ > > diff --git a/arch/powerpc/include/asm/fsl_85xx_cache_sram.h b/arch/powerpc/include/asm/fsl_85xx_cache_sram.h > index 0235a0447baa..99cb7e202c38 100644 > --- a/arch/powerpc/include/asm/fsl_85xx_cache_sram.h > +++ b/arch/powerpc/include/asm/fsl_85xx_cache_sram.h > @@ -26,6 +26,10 @@ struct mpc85xx_cache_sram { > unsigned int size; > rh_info_t *rh; > spinlock_t lock; > + > +#ifdef CONFIG_FSL_85XX_SRAM_UAPI > + struct device *dev; > +#endif > }; > > extern void mpc85xx_cache_sram_free(void *ptr); > diff --git a/arch/powerpc/platforms/85xx/Kconfig b/arch/powerpc/platforms/85xx/Kconfig > index fa3d29dcb57e..3a6f6af973eb 100644 > --- a/arch/powerpc/platforms/85xx/Kconfig > +++ b/arch/powerpc/platforms/85xx/Kconfig > @@ -16,6 +16,16 @@ if FSL_SOC_BOOKE > > if PPC32 > > +config FSL_85XX_SRAM_UAPI > + tristate "Freescale MPC85xx SRAM UAPI Support" > + depends on FSL_SOC_BOOKE && SRAM_DYNAMIC Is SRAM_DYNAMIC usefull on its own, without a driver like this one ? Is that worth allowing tiny selection of both drivers ? Shouldn't one of them imply the other one ? > + select FSL_85XX_CACHE_SRAM > + help > + This registers a device of struct sram_device type which would act as > + an interface for user level applications to access the Freescale 85xx > + Cache-SRAM memory dynamically, meaning allocate on demand dynamically > + while they are running. > + > config FSL_85XX_CACHE_SRAM > bool > select PPC_LIB_RHEAP > diff --git a/arch/powerpc/sysdev/Makefile b/arch/powerpc/sysdev/Makefile > index cb5a5bd2cef5..e71f82f0d2c3 100644 > --- a/arch/powerpc/sysdev/Makefile > +++ b/arch/powerpc/sysdev/Makefile > @@ -24,6 +24,7 @@ obj-$(CONFIG_FSL_CORENET_RCPM) += fsl_rcpm.o > obj-$(CONFIG_FSL_LBC) += fsl_lbc.o > obj-$(CONFIG_FSL_GTM) += fsl_gtm.o > obj-$(CONFIG_FSL_85XX_CACHE_SRAM) += fsl_85xx_l2ctlr.o fsl_85xx_cache_sram.o > +obj-$(CONFIG_FSL_85XX_SRAM_UAPI) += fsl_85xx_sram_uapi.o > obj-$(CONFIG_FSL_RIO) += fsl_rio.o fsl_rmu.o > obj-$(CONFIG_TSI108_BRIDGE) += tsi108_pci.o tsi108_dev.o > obj-$(CONFIG_RTC_DRV_CMOS) += rtc_cmos_setup.o > diff --git a/arch/powerpc/sysdev/fsl_85xx_cache_ctlr.h b/arch/powerpc/sysdev/fsl_85xx_cache_ctlr.h > index ce370749add9..4930784d9852 100644 > --- a/arch/powerpc/sysdev/fsl_85xx_cache_ctlr.h > +++ b/arch/powerpc/sysdev/fsl_85xx_cache_ctlr.h > @@ -10,6 +10,8 @@ > #ifndef __FSL_85XX_CACHE_CTLR_H__ > #define __FSL_85XX_CACHE_CTLR_H__ > > +#include > + > #define L2CR_L2FI 0x40000000 /* L2 flash invalidate */ > #define L2CR_L2IO 0x00200000 /* L2 instruction only */ > #define L2CR_SRAM_ZERO 0x00000000 /* L2SRAM zero size */ > @@ -81,6 +83,10 @@ struct sram_parameters { > phys_addr_t sram_offset; > }; > > +#ifdef CONFIG_FSL_85XX_SRAM_UAPI > +extern struct mpc85xx_cache_sram *mpc85xx_get_cache_sram(void); 'extern' keywork is meaningless here, remove it. > +#endif > + > extern int instantiate_cache_sram(struct platform_device *dev, > struct sram_parameters sram_params); > extern void remove_cache_sram(struct platform_device *dev); > diff --git a/arch/powerpc/sysdev/fsl_85xx_cache_sram.c b/arch/powerpc/sysdev/fsl_85xx_cache_sram.c > index 3de5ac8382c0..0156ea63a3a2 100644 > --- a/arch/powerpc/sysdev/fsl_85xx_cache_sram.c > +++ b/arch/powerpc/sysdev/fsl_85xx_cache_sram.c > @@ -23,6 +23,14 @@ > > struct mpc85xx_cache_sram *cache_sram; > > + > +#ifdef CONFIG_FSL_85XX_SRAM_UAPI > +struct mpc85xx_cache_sram *mpc85xx_get_cache_sram(void) > +{ > + return cache_sram; > +} > +#endif This function is not worth the mess of an #ifdef in a .c file. cache_sram is already globaly visible, so this function should go in fsl_85xx_cache_ctlr.h as a 'static inline' > + > void *mpc85xx_cache_sram_alloc(unsigned int size, > phys_addr_t *phys, unsigned int align) > { > @@ -115,6 +123,10 @@ int instantiate_cache_sram(struct platform_device *dev, > rh_attach_region(cache_sram->rh, 0, cache_sram->size); > spin_lock_init(&cache_sram->lock); > > +#ifdef CONFIG_FSL_85XX_SRAM_UAPI > + cache_sram->dev = &dev->dev; > +#endif Can we avoid the #ifdef in .c file ? (see https://www.kernel.org/doc/html/latest/process/coding-style.html#conditional-compilation) > + > dev_info(&dev->dev, "[base:0x%llx, size:0x%x] configured and loaded\n", > (unsigned long long)cache_sram->base_phys, cache_sram->size); > > diff --git a/arch/powerpc/sysdev/fsl_85xx_sram_uapi.c b/arch/powerpc/sysdev/fsl_85xx_sram_uapi.c > new file mode 100644 > index 000000000000..60190bf3c8e9 > --- /dev/null > +++ b/arch/powerpc/sysdev/fsl_85xx_sram_uapi.c > @@ -0,0 +1,39 @@ > +// SPDX-License-Identifier: GPL-2.0 > +/* > + * Copyright (C) 2020 Vivo Communication Technology Co. Ltd. > + * Copyright (C) 2020 Wang Wenhu > + * All rights reserved. > + */ > + > +#include > +#include > +#include > +#include > +#include "fsl_85xx_cache_ctlr.h" > + > +static struct sram_api mpc85xx_sram_api = { > + .name = "mpc85xx_sram", > + .alloc = mpc85xx_cache_sram_alloc, > + .free = mpc85xx_cache_sram_free, > +}; > + > +static int __init mpc85xx_sram_uapi_init(void) > +{ > + struct mpc85xx_cache_sram *sram = mpc85xx_get_cache_sram(); > + > + if (!sram) > + return -ENODEV; > + > + return sram_register_device(sram->dev, &mpc85xx_sram_api); > +} > +subsys_initcall(mpc85xx_sram_uapi_init); > + > +static void __exit mpc85xx_sram_uapi_exit(void) > +{ > + sram_unregister_device(&mpc85xx_sram_api); > +} > +module_exit(mpc85xx_sram_uapi_exit); > + > +MODULE_AUTHOR("Wang Wenhu "); > +MODULE_DESCRIPTION("MPC85xx SRAM User-Space API Support"); > +MODULE_LICENSE("GPL v2"); > Christophe