Received: by 2002:a25:1985:0:0:0:0:0 with SMTP id 127csp714543ybz; Fri, 17 Apr 2020 08:45:04 -0700 (PDT) X-Google-Smtp-Source: APiQypL7iZkGwFVydo42oOah6cYj6voqAQG1X5PIXxsguMSjie2mc1fovMale7Pq6e4s//PvVE3a X-Received: by 2002:a17:906:1f47:: with SMTP id d7mr3712018ejk.37.1587138304130; Fri, 17 Apr 2020 08:45:04 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1587138304; cv=none; d=google.com; s=arc-20160816; b=qCAgx6vtR5RwbaQX/Xll4OrZrvtFCtw2ICIzFc6OcnV2BWHC44rBtUqJFN5+swjUko 53Chu8nxKKyuHdiFX6M2zTLnucHZPNXAwgPTEW4IYXAOHPAzqMvbgaeV6/GOAQyEyuP1 +CP1S/6yvBm0jm2AF8J4dhl9kmP+41nGgN7CniJwTcywNTjLRP5q+ap5Rv1HkXsSft8s eKMoV+2Tf+o16cMaUBATjPOVKx8KZH8OA4Ab3Uv0gWwM8H8p9XiBzx5X0x2nEHS2m8KS mtnZtLjIt47nBWrr2RdCxmpdEx1hvUVLrEZ8biLKmMc98gUbVyCi2MEuJxEjR+2zteWh I30w== 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:mime-version :organization:references:in-reply-to:message-id:subject:cc:to:from :date; bh=Tg4/f261YvvYgCBwXrQygh2lgIjo1bGAvfRbdfchsD8=; b=NBZJJe+yT4HFSarzY1Lc80NiZLt6q5ea049Wc25KTj4rLh24sjUWMyUpBhX6N1u/7n +gjdZfGwriAAdQFOVdzn03/8oLEcfSmJxT4V/2V4ZXJbe9kUsBoHEqpozfMIp0Pz/MZf zHPJsnxPkCSz6Gtt94x4gXKHDnGkdbB8yq9xPoZ6N6IxIxVw5zaTjLp1EeTWE3Jn7mcd Hc3MeJIuBjZvpXTZ4UO8bYxtwPjrd1W0wOAH90XCzKS3mx19/Ob/CRahgLlHo9o8MMPm 2cMVXTTGztjveCrGZPUbzr+KcgpPs70+JuWwQfnldL/AaghdO1KTEPYE35OzfeG2bcoa ICFA== ARC-Authentication-Results: i=1; mx.google.com; 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=collabora.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id y24si8511386edw.420.2020.04.17.08.44.40; Fri, 17 Apr 2020 08:45:04 -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; 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=collabora.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729207AbgDQPlp convert rfc822-to-8bit (ORCPT + 99 others); Fri, 17 Apr 2020 11:41:45 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:46588 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-FAIL-OK-FAIL) by vger.kernel.org with ESMTP id S1729110AbgDQPlp (ORCPT ); Fri, 17 Apr 2020 11:41:45 -0400 Received: from bhuna.collabora.co.uk (bhuna.collabora.co.uk [IPv6:2a00:1098:0:82:1000:25:2eeb:e3e3]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 25B52C061A0C; Fri, 17 Apr 2020 08:41:45 -0700 (PDT) Received: from localhost (unknown [IPv6:2a01:e0a:2c:6930:5cf4:84a1:2763:fe0d]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: bbrezillon) by bhuna.collabora.co.uk (Postfix) with ESMTPSA id 0920E2A0613; Fri, 17 Apr 2020 16:41:43 +0100 (BST) Date: Fri, 17 Apr 2020 17:41:40 +0200 From: Boris Brezillon To: Marek Vasut Cc: Christophe Kerello , miquel.raynal@bootlin.com, richard@nod.at, vigneshr@ti.com, lee.jones@linaro.org, robh+dt@kernel.org, mark.rutland@arm.com, tony@atomide.com, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mtd@lists.infradead.org, linux-stm32@st-md-mailman.stormreply.com Subject: Re: [PATCH v2 03/12] bus: stm32-fmc2-ebi: add STM32 FMC2 EBI controller driver Message-ID: <20200417174140.00456f36@collabora.com> In-Reply-To: References: <1586966256-29548-1-git-send-email-christophe.kerello@st.com> <1586966256-29548-4-git-send-email-christophe.kerello@st.com> <20200416215328.53982fef@collabora.com> Organization: Collabora X-Mailer: Claws Mail 3.17.5 (GTK+ 2.24.32; x86_64-redhat-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 17 Apr 2020 17:31:49 +0200 Marek Vasut wrote: > On 4/17/20 5:29 PM, Christophe Kerello wrote: > > > > > > On 4/16/20 9:53 PM, Boris Brezillon wrote: > >> On Wed, 15 Apr 2020 17:57:27 +0200 > >> Christophe Kerello wrote: > >> > >>> The driver adds the support for the STMicroelectronics FMC2 EBI > >>> controller > >>> found on STM32MP SOCs. > >>> > >>> Signed-off-by: Christophe Kerello > >>> Tested-by: Marek Vasut > >>> --- > >>> Changes in v2: > >>>   - call 2 APIs to manage FMC2 enable/disable instead of ops > >>>   - call 2 APIs to manage FMC2 NWAIT shared signal instead of ops > >>> > >>>   drivers/bus/Kconfig          |   11 + > >>>   drivers/bus/Makefile         |    1 + > >>>   drivers/bus/stm32-fmc2-ebi.c | 1091 > >>> ++++++++++++++++++++++++++++++++++++++++++ > >> > >> Hm, I see that other memory bus controller drivers are placed under > >> drivers/memory/, any reason for choosing drivers/bus/? If that's where > >> we want to have all generic memory bus controllers to live it might be > >> worth moving existing drivers to the drivers/bus/ directory at some > >> point. > >> > > > > Hi Boris, > > > > I see this controller as an external bus interface as we are able to > > attach different devices on it, like a PSRAM, an ethernet controller, a > > FPGA, a LCD display, ... > > > > When I had a look at bus/Kconfig file, I have found similar drivers > > (like IMX_WEIM or QCOM_EBI2 drivers). These drivers are able to connect > > devices like NAND Flash, SRAM, ethernet adapters, FPGAs and LCD displays > > as it is written in the Kconfig file. > > > > But, after checking memory/Kconfig file, it is also possible to find > > similar drivers (like ATMEL_EBI driver that is inspired by the WEIM bus > > driver). > > > > So, I will follow the recommendation and I will move it to > > drivers/memory folder if it is the place where this driver should be. > > The EBI isn't a memory bus, you can very well have a non-memory device, > like an external parallel bus memory controller on it. So why should it > be in drivers/memory ? Just like most of those so-called memory bus controllers we have under drivers/memory/ => they are most of the time used to interact with memories but can also be used for other things (Christophe listed a few uses cases). And I'm not pushing one way or the other, all I said was that we should makes things consistent instead of having half of those controller drivers in drivers/memory/ and the other half in drivers/bus/.