linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Boris Brezillon <boris.brezillon@bootlin.com>
To: vitor <vitor.soares@synopsys.com>
Cc: <wsa@the-dreams.de>, <linux-i2c@vger.kernel.org>,
	<corbet@lwn.net>, <linux-doc@vger.kernel.org>,
	<gregkh@linuxfoundation.org>, <arnd@arndb.de>,
	<psroka@cadence.com>, <agolec@cadence.com>,
	<adouglas@cadence.com>, <bfolta@cadence.com>, <dkos@cadence.com>,
	<alicja@cadence.com>, <cwronka@cadence.com>,
	<sureshp@cadence.com>, <rafalc@cadence.com>,
	<thomas.petazzoni@bootlin.com>, <nm@ti.com>, <robh+dt@kernel.org>,
	<pawel.moll@arm.com>, <mark.rutland@arm.com>,
	<ijc+devicetree@hellion.org.uk>, <galak@codeaurora.org>,
	<devicetree@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
	<geert@linux-m68k.org>, <linus.walleij@linaro.org>,
	<Xiang.Lin@synaptics.com>, <linux-gpio@vger.kernel.org>,
	<nsekhar@ti.com>, <pgaj@cadence.com>, <peda@axentia.se>,
	<mshettel@codeaurora.org>, <swboyd@chromium.org>,
	<joao.pinto@synopsys.com>
Subject: Re: [PATCH] i3c: master: dw: split dw-i3c-master.c into master and bus specific parts
Date: Mon, 26 Nov 2018 13:35:50 +0100	[thread overview]
Message-ID: <20181126133550.51469816@bbrezillon> (raw)
In-Reply-To: <83115f47-1326-cb33-a7dc-4bc8ff95befa@synopsys.com>

On Mon, 26 Nov 2018 12:06:24 +0000
vitor <vitor.soares@synopsys.com> wrote:

> Hi Boris,
> 
> 
> On 23/11/18 12:50, Boris Brezillon wrote:
> > On Fri, 23 Nov 2018 12:39:31 +0000
> > vitor <vitor.soares@synopsys.com> wrote:
> >  
> >> Hi Boris,
> >>
> >>
> >> On 22/11/18 20:02, Boris Brezillon wrote:  
> >>> On Thu, 22 Nov 2018 17:54:54 +0000
> >>> Vitor Soares <vitor.soares@synopsys.com> wrote:
> >>>     
> >>>> From: Vitor Soares <soares@synopsys.com>
> >>>>
> >>>> 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 <soares@synopsys.com>
> >>>> ---
> >>>>    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-<ipname>.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.

  reply	other threads:[~2018-11-26 12:36 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-11-22 17:54 [PATCH] i3c: master: dw: split dw-i3c-master.c into master and bus specific parts Vitor Soares
2018-11-22 20:02 ` Boris Brezillon
2018-11-23 12:39   ` vitor
2018-11-23 12:50     ` Boris Brezillon
2018-11-26 12:06       ` vitor
2018-11-26 12:35         ` Boris Brezillon [this message]
2018-11-26 18:33           ` vitor
2018-11-26 18:56             ` Boris Brezillon
2018-11-26 19:08               ` Boris Brezillon
2018-11-26 19:28                 ` vitor
2018-11-26 20:06                   ` Boris Brezillon
2018-11-26 20:11               ` vitor
2018-11-26 21:33                 ` Boris Brezillon
2018-11-27 11:50                   ` vitor
2018-11-27 12:33                     ` Boris Brezillon
2018-12-04  0:34                       ` vitor
2018-12-04  9:19                         ` Boris Brezillon

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20181126133550.51469816@bbrezillon \
    --to=boris.brezillon@bootlin.com \
    --cc=Xiang.Lin@synaptics.com \
    --cc=adouglas@cadence.com \
    --cc=agolec@cadence.com \
    --cc=alicja@cadence.com \
    --cc=arnd@arndb.de \
    --cc=bfolta@cadence.com \
    --cc=corbet@lwn.net \
    --cc=cwronka@cadence.com \
    --cc=devicetree@vger.kernel.org \
    --cc=dkos@cadence.com \
    --cc=galak@codeaurora.org \
    --cc=geert@linux-m68k.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=ijc+devicetree@hellion.org.uk \
    --cc=joao.pinto@synopsys.com \
    --cc=linus.walleij@linaro.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-gpio@vger.kernel.org \
    --cc=linux-i2c@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=mshettel@codeaurora.org \
    --cc=nm@ti.com \
    --cc=nsekhar@ti.com \
    --cc=pawel.moll@arm.com \
    --cc=peda@axentia.se \
    --cc=pgaj@cadence.com \
    --cc=psroka@cadence.com \
    --cc=rafalc@cadence.com \
    --cc=robh+dt@kernel.org \
    --cc=sureshp@cadence.com \
    --cc=swboyd@chromium.org \
    --cc=thomas.petazzoni@bootlin.com \
    --cc=vitor.soares@synopsys.com \
    --cc=wsa@the-dreams.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).