Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp5732888imu; Mon, 26 Nov 2018 04:37:35 -0800 (PST) X-Google-Smtp-Source: AFSGD/UUHpSHNxRlHhzVfJx2bVrI+DkTYdbCdjHX92ZXEMSA1VZ8fL7iUDMMemgWz1KAfWlSF1yG X-Received: by 2002:a63:b105:: with SMTP id r5mr24949444pgf.442.1543235855799; Mon, 26 Nov 2018 04:37:35 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1543235855; cv=none; d=google.com; s=arc-20160816; b=Kft89Wqn+FcKShtXo21H1i13aM7xWCuSZvi9K5+1r01KkK/P/dEGx6k1DRdrm3YHnR Bj56w7XswBZAnXTLhSfAXVl8Df3eap7gARapD2RGY4r2IJiGtYDU6Gch9LzCBIb6XOM6 KHCm9bSWv13MiZdqr/JYD6owaDQcDTYfOCYnbRqIVH6DTqwH4UbYjgMPOM6OFI+ZB2R/ lCvVJTxnK32vl0PXoWsq2ZgNL6oTZVuWhdUcHl0Hf7z5wWeP+Go/k651+jeOXXDTt8MH +QcRUk+00L0SYg4OPAakaDnQ/sbQosmiS3ozFgYuW+LisW3N4rL4eEzGoFhQnR5KbF3V W5eQ== 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 :references:in-reply-to:message-id:subject:cc:to:from:date; bh=30UOta4eyXHvAQYU0E95WoeFXTfp+MEGkCqOaAfBV10=; b=h+p5yr4cg6nxp4RsyWmPiYEZH7VECBSucuoa+MIw9QUn9tI/R1LfTHSkNpnVG7t22o 4TR8TZCcET4itNN/tr44AkyYKU/QYkv7/3p5LK7TCFcfLnqRxM6YF+RntmdZXL28Asxf OKPhlecTuws1xYjpd6D2iscHHg/pX+L15tupN+M2vBsFwUJLZtjTyMkFbMUw4S0AHPfH t/AmI1e/crjVvArT2sheA7scNwmkI5zbsN2vq9ssw8SA3aHHSWZFGjdwQ+zXHpEYLr91 2wQLIJO6pliDHYNVuTKrBh06Qm02IGE9YF6d7UUNMy3ZJoo6NvbfPZEFxDRUmd1jGb0x 8MIg== ARC-Authentication-Results: i=1; mx.google.com; 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id z5si196752pgj.177.2018.11.26.04.36.49; Mon, 26 Nov 2018 04:37:35 -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; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726381AbeKZXaD (ORCPT + 99 others); Mon, 26 Nov 2018 18:30:03 -0500 Received: from mail.bootlin.com ([62.4.15.54]:53141 "EHLO mail.bootlin.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726177AbeKZXaD (ORCPT ); Mon, 26 Nov 2018 18:30:03 -0500 Received: by mail.bootlin.com (Postfix, from userid 110) id 5111D20D31; Mon, 26 Nov 2018 13:36:01 +0100 (CET) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on mail.bootlin.com X-Spam-Level: X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,SHORTCIRCUIT shortcircuit=ham autolearn=disabled version=3.4.2 Received: from bbrezillon (aaubervilliers-681-1-94-205.w90-88.abo.wanadoo.fr [90.88.35.205]) by mail.bootlin.com (Postfix) with ESMTPSA id 8EAD3207BD; Mon, 26 Nov 2018 13:35:50 +0100 (CET) Date: Mon, 26 Nov 2018 13:35:50 +0100 From: Boris Brezillon To: vitor Cc: , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , Subject: Re: [PATCH] i3c: master: dw: split dw-i3c-master.c into master and bus specific parts Message-ID: <20181126133550.51469816@bbrezillon> In-Reply-To: <83115f47-1326-cb33-a7dc-4bc8ff95befa@synopsys.com> References: <20181122210202.6af50fcc@bbrezillon> <6d513e04-3a57-1989-429c-64631101c5a2@synopsys.com> <20181123135004.7fd1cd58@bbrezillon> <83115f47-1326-cb33-a7dc-4bc8ff95befa@synopsys.com> X-Mailer: Claws Mail 3.16.0 (GTK+ 2.24.32; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 26 Nov 2018 12:06:24 +0000 vitor wrote: > Hi Boris, > > > On 23/11/18 12:50, Boris Brezillon wrote: > > On Fri, 23 Nov 2018 12:39:31 +0000 > > vitor wrote: > > > >> Hi Boris, > >> > >> > >> On 22/11/18 20:02, Boris Brezillon wrote: > >>> On Thu, 22 Nov 2018 17:54:54 +0000 > >>> Vitor Soares wrote: > >>> > >>>> From: Vitor Soares > >>>> > >>>> This patch slipts dw-i3c-master.c into three pieces: > >>>> dw-i3c-master.c - contains the code that interacts directly with the > >>>> core in master mode. > >>>> > >>>> dw-i3c-platdrv.c - contains the code specific to the platform driver. > >>>> > >>>> dw-i3c-core.h - contains the definitions and declarations shared by > >>>> dw-i3c-master and dw-i3c-platdrv > >>>> > >>>> This patch will allow SOC integrators to add their code specific to > >>>> DesignWare I3C IP. > >>> Isn't it too early to do this change? Can't we wait until we have a SoC > >>> that actually embeds this IP? > >> > >> I'm trying to turn it more flexible so the other can reuse the code. > > Looking at the separation you've done here, I don't see why you need > > it. All the resources you request are generic, so why not just adding a > > new compat in the of_match_table? > > I understand your point. > > > I'm just following what it's done in others Synopsys drivers and what I > expect is that in the future we will have the same for the I3C. > > Some of the current generic functions might be override according with > SoC requirements (e.g i2c-designware, pcie-designware). > > > for now what do you prefer? > I prefer that we keep the driver as is until we actually need to split things up. > >> > >>> > >>>> Signed-off-by: Vitor Soares > >>>> --- > >>>> drivers/i3c/master/Kconfig | 9 +- > >>>> drivers/i3c/master/Makefile | 5 +- > >>>> drivers/i3c/master/dw-i3c-core.h | 214 ++++++++++++++++++++++++++ > >>>> drivers/i3c/master/dw-i3c-master.c | 299 ++---------------------------------- > >>>> drivers/i3c/master/dw-i3c-platdrv.c | 112 ++++++++++++++ > > Just realized the driver is named dw-i3c-master, while the cadence > > driver is named i3c-master-cdns.c. I'll send a patch to make that > > consistent and follow the initial naming scheme: i3c-master-.c. > > As I shared with you in previous email, the structure that I have in > mind is this one: > > - core.h (or common.h, any though?) > > - common.c > > - master.c > > - slave.c > > > so for me doesn't make sense to have for instance: i3c-master-dw-slave.c If you have several files and they're all placed in a dw/ subdir, then I agree, prefixing everything with i3c-master- is useless, as you'll have to define a custom rule to create the i3c-master-dw.ko object. When there's a single source file, and this source file is directly used to create a .ko, we need this prefix, otherwise we would have dw.ko, and this would basically conflict with any other designware driver that does not have a proper prefix. > > But seeing what is already in the kernel I wasn't coherent and it should > be named to i3c-designware-master.c Actually it's i3c-master-designware.c (or i3c-master-dw.c) if we follow what's been done for the cadence driver. > > > or > > > follow this https://lkml.org/lkml/2017/7/12/430 And I agree with Linus on this, except that does not apply to single source file drivers. > > > This topic rise another one related with the master folder. I understand > that now the subsystem doesn't have slave support but the name is > limited. Isn't better to have something like controller or busses? What > do you have in mind for the slave? drivers/i3c/slave/... for slave drivers and drivers/i3c/slave.c for the framework, just like we have drivers/i3c/master/ for master controller drivers and drivers/i3c/master.c.