All of lore.kernel.org
 help / color / mirror / Atom feed
From: Geert Uytterhoeven <geert@linux-m68k.org>
To: Michel Pollet <michel.pollet@bp.renesas.com>
Cc: Rob Herring <robh@kernel.org>,
	"linux-renesas-soc@vger.kernel.org"
	<linux-renesas-soc@vger.kernel.org>,
	Simon Horman <horms@verge.net.au>,
	Phil Edworthy <phil.edworthy@renesas.com>,
	"buserror+upstream@gmail.com" <buserror+upstream@gmail.com>,
	Magnus Damm <magnus.damm@gmail.com>,
	Mark Rutland <mark.rutland@arm.com>,
	Lee Jones <lee.jones@linaro.org>,
	Russell King <linux@armlinux.org.uk>,
	Sebastian Reichel <sre@kernel.org>,
	"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>,
	"linux-pm@vger.kernel.org" <linux-pm@vger.kernel.org>
Subject: Re: [PATCH v4 3/8] dt-bindings: mfd: renesas,rzn1-sysctrl: document RZ/N1 sysctrl node
Date: Tue, 17 Apr 2018 10:31:38 +0200	[thread overview]
Message-ID: <CAMuHMdWoW6QXofvS0Ju5VL1WivmWWMx8c=ppVbKe1+2eO6LsFg@mail.gmail.com> (raw)
In-Reply-To: <OSBPR01MB20548CE7A728549EFA2B9ADBD2B70@OSBPR01MB2054.jpnprd01.prod.outlook.com>

Hi Michel,

On Tue, Apr 17, 2018 at 9:56 AM, Michel Pollet
<michel.pollet@bp.renesas.com> wrote:
> On 13 April 2018 19:06, Rob Herring:
>> On Tue, Apr 10, 2018 at 09:30:03AM +0100, Michel Pollet wrote:
>> > The Renesas RZ/N1 Family (Part #R9A06G0xx) has a multi-function system
>> > controller. This documents the node used to encapsulate it's sub
>> > drivers.
>> >
>> > Signed-off-by: Michel Pollet <michel.pollet@bp.renesas.com>
>> > ---
>> >  .../bindings/mfd/renesas,rzn1-sysctrl.txt          | 23
>> ++++++++++++++++++++++
>> >  1 file changed, 23 insertions(+)
>> >  create mode 100644
>> > Documentation/devicetree/bindings/mfd/renesas,rzn1-sysctrl.txt
>> >
>> > diff --git
>> > a/Documentation/devicetree/bindings/mfd/renesas,rzn1-sysctrl.txt
>> > b/Documentation/devicetree/bindings/mfd/renesas,rzn1-sysctrl.txt
>> > new file mode 100644
>> > index 0000000..9897f8f
>> > --- /dev/null
>> > +++ b/Documentation/devicetree/bindings/mfd/renesas,rzn1-sysctrl.txt
>> > @@ -0,0 +1,23 @@
>> > +DT bindings for the Renesas RZ/N1 System Controller
>> > +
>> > +== System Controller Node ==
>> > +
>> > +The system controller node currently only hosts a single sub-node to
>> > +handle the rebooting of the CPU. Eventually it will host the clock
>> > +driver, SMP start handler, watchdog etc.
>>
>> Please submit a complete binding for the h/w block.
>>
>> Again, if the only reason you have sub nodes is to define compatible strings
>> and in turn enumerate drivers, then you don't need the nodes in DT. DT is
>> not the only way to instantiate drivers.
>
> I can't document it before I have the code. There is 0.000% chance of my clock
> driver for example to be upstreamed the way I would imagine making it -- in
> fact pretty much any other driver will have to be reworked to fit, so documenting
> bindings first is impossible.
>
> So, if I understand correctly, you are telling me to make a 'sysctrl' driver and use
> platform_device to instantiate my sub-drivers? Isn't that what machine files used
> to do? And they are now banned?
>
> Geert, any guidance here?

It depends on how many and which subnodes you want to add to  the sysctrl
node. Without a complete binding for the block, we cannot know.
If the major part will be the clock driver, I would make that the main
driver for the sysctrl node. The clock driver can easily register
e.g. a simple reset handler.

Cfr. the renesas-cpg-mssr driver, which also handles (module) resets.
There are plenty of other examples of drivers providing multiple
functionalities (e.g. pinctrl drivers also registering GPIO controllers).

If a monolithic driver becomes too large, it can still be split using the
MFD framework.
E.g. the BD9571 PMIC driver is split in an MFD core driver, and 2 drivers
for different functionalities:

   drivers/gpio/gpio-bd9571mwv.c
   drivers/mfd/bd9571mwv.c
   drivers/regulator/bd9571mwv-regulator.c
   include/linux/mfd/bd9571mwv.h

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

WARNING: multiple messages have this Message-ID (diff)
From: geert@linux-m68k.org (Geert Uytterhoeven)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v4 3/8] dt-bindings: mfd: renesas,rzn1-sysctrl: document RZ/N1 sysctrl node
Date: Tue, 17 Apr 2018 10:31:38 +0200	[thread overview]
Message-ID: <CAMuHMdWoW6QXofvS0Ju5VL1WivmWWMx8c=ppVbKe1+2eO6LsFg@mail.gmail.com> (raw)
In-Reply-To: <OSBPR01MB20548CE7A728549EFA2B9ADBD2B70@OSBPR01MB2054.jpnprd01.prod.outlook.com>

Hi Michel,

On Tue, Apr 17, 2018 at 9:56 AM, Michel Pollet
<michel.pollet@bp.renesas.com> wrote:
> On 13 April 2018 19:06, Rob Herring:
>> On Tue, Apr 10, 2018 at 09:30:03AM +0100, Michel Pollet wrote:
>> > The Renesas RZ/N1 Family (Part #R9A06G0xx) has a multi-function system
>> > controller. This documents the node used to encapsulate it's sub
>> > drivers.
>> >
>> > Signed-off-by: Michel Pollet <michel.pollet@bp.renesas.com>
>> > ---
>> >  .../bindings/mfd/renesas,rzn1-sysctrl.txt          | 23
>> ++++++++++++++++++++++
>> >  1 file changed, 23 insertions(+)
>> >  create mode 100644
>> > Documentation/devicetree/bindings/mfd/renesas,rzn1-sysctrl.txt
>> >
>> > diff --git
>> > a/Documentation/devicetree/bindings/mfd/renesas,rzn1-sysctrl.txt
>> > b/Documentation/devicetree/bindings/mfd/renesas,rzn1-sysctrl.txt
>> > new file mode 100644
>> > index 0000000..9897f8f
>> > --- /dev/null
>> > +++ b/Documentation/devicetree/bindings/mfd/renesas,rzn1-sysctrl.txt
>> > @@ -0,0 +1,23 @@
>> > +DT bindings for the Renesas RZ/N1 System Controller
>> > +
>> > +== System Controller Node ==
>> > +
>> > +The system controller node currently only hosts a single sub-node to
>> > +handle the rebooting of the CPU. Eventually it will host the clock
>> > +driver, SMP start handler, watchdog etc.
>>
>> Please submit a complete binding for the h/w block.
>>
>> Again, if the only reason you have sub nodes is to define compatible strings
>> and in turn enumerate drivers, then you don't need the nodes in DT. DT is
>> not the only way to instantiate drivers.
>
> I can't document it before I have the code. There is 0.000% chance of my clock
> driver for example to be upstreamed the way I would imagine making it -- in
> fact pretty much any other driver will have to be reworked to fit, so documenting
> bindings first is impossible.
>
> So, if I understand correctly, you are telling me to make a 'sysctrl' driver and use
> platform_device to instantiate my sub-drivers? Isn't that what machine files used
> to do? And they are now banned?
>
> Geert, any guidance here?

It depends on how many and which subnodes you want to add to  the sysctrl
node. Without a complete binding for the block, we cannot know.
If the major part will be the clock driver, I would make that the main
driver for the sysctrl node. The clock driver can easily register
e.g. a simple reset handler.

Cfr. the renesas-cpg-mssr driver, which also handles (module) resets.
There are plenty of other examples of drivers providing multiple
functionalities (e.g. pinctrl drivers also registering GPIO controllers).

If a monolithic driver becomes too large, it can still be split using the
MFD framework.
E.g. the BD9571 PMIC driver is split in an MFD core driver, and 2 drivers
for different functionalities:

   drivers/gpio/gpio-bd9571mwv.c
   drivers/mfd/bd9571mwv.c
   drivers/regulator/bd9571mwv-regulator.c
   include/linux/mfd/bd9571mwv.h

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

  reply	other threads:[~2018-04-17  8:31 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-04-10  8:30 [PATCH v4 0/8] arm: Base support for Renesas RZN1D-DB Board Michel Pollet
2018-04-10  8:30 ` Michel Pollet
2018-04-10  8:30 ` [PATCH v4 1/8] arm: shmobile: Add the RZ/N1 arch to the shmobile Kconfig Michel Pollet
2018-04-10  8:30   ` Michel Pollet
2018-04-12  8:00   ` Simon Horman
2018-04-12  8:00     ` Simon Horman
2018-04-10  8:30 ` [PATCH v4 2/8] arm: shmobile: Add the RZ/N1D (R9A06G032) " Michel Pollet
2018-04-10  8:30   ` Michel Pollet
2018-04-10  8:30 ` [PATCH v4 3/8] dt-bindings: mfd: renesas,rzn1-sysctrl: document RZ/N1 sysctrl node Michel Pollet
2018-04-10  8:30   ` [PATCH v4 3/8] dt-bindings: mfd: renesas, rzn1-sysctrl: " Michel Pollet
2018-04-13 18:05   ` [PATCH v4 3/8] dt-bindings: mfd: renesas,rzn1-sysctrl: " Rob Herring
2018-04-13 18:05     ` Rob Herring
2018-04-17  7:56     ` Michel Pollet
2018-04-17  7:56       ` Michel Pollet
2018-04-17  8:31       ` Geert Uytterhoeven [this message]
2018-04-17  8:31         ` Geert Uytterhoeven
2018-04-10  8:30 ` [PATCH v4 4/8] dt-bindings: reset: renesas,rzn1-reboot: document RZ/N1 reboot driver Michel Pollet
2018-04-10  8:30   ` [PATCH v4 4/8] dt-bindings: reset: renesas, rzn1-reboot: " Michel Pollet
2018-04-10  8:30 ` [PATCH v4 5/8] dt-bindings: arm: Document the RZN1D-DB board Michel Pollet
2018-04-10  8:30   ` Michel Pollet
2018-04-13 18:32   ` Rob Herring
2018-04-13 18:32     ` Rob Herring
2018-04-10  8:30 ` [PATCH v4 6/8] ARM: dts: Renesas RZ/N1 SoC base device tree file Michel Pollet
2018-04-10  8:30   ` Michel Pollet
2018-04-10  8:30 ` [PATCH v4 7/8] ARM: dts: Renesas RZN1D-DB Board base file Michel Pollet
2018-04-10  8:30   ` Michel Pollet
2018-04-10  8:30 ` [PATCH v4 8/8] reset: Renesas RZ/N1 reboot driver Michel Pollet
2018-04-10  8:30   ` Michel Pollet

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='CAMuHMdWoW6QXofvS0Ju5VL1WivmWWMx8c=ppVbKe1+2eO6LsFg@mail.gmail.com' \
    --to=geert@linux-m68k.org \
    --cc=buserror+upstream@gmail.com \
    --cc=devicetree@vger.kernel.org \
    --cc=horms@verge.net.au \
    --cc=lee.jones@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=linux-renesas-soc@vger.kernel.org \
    --cc=linux@armlinux.org.uk \
    --cc=magnus.damm@gmail.com \
    --cc=mark.rutland@arm.com \
    --cc=michel.pollet@bp.renesas.com \
    --cc=phil.edworthy@renesas.com \
    --cc=robh@kernel.org \
    --cc=sre@kernel.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.