LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Linus Walleij <linus.walleij@linaro.org>
To: Rob Herring <robh@kernel.org>
Cc: Robert Marko <robert.marko@sartura.hr>,
	Bartosz Golaszewski <bgolaszewski@baylibre.com>,
	Lee Jones <lee.jones@linaro.org>,
	Philipp Zabel <p.zabel@pengutronix.de>,
	"open list:GPIO SUBSYSTEM" <linux-gpio@vger.kernel.org>,
	devicetree <devicetree@vger.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Luka Perkov <luka.perkov@sartura.hr>,
	jmp@epiphyte.org, Paul Menzel <pmenzel@molgen.mpg.de>,
	Donald Buczek <buczek@molgen.mpg.de>
Subject: Re: [PATCH v6 5/6] dt-bindings: mfd: Add Delta TN48M CPLD drivers bindings
Date: Wed, 21 Jul 2021 16:16:48 +0200	[thread overview]
Message-ID: <CACRpkdbq6Jow6AT9OpsR7Q0JVCWVMcmamh9KHPXMtUnkoe7ZFw@mail.gmail.com> (raw)
In-Reply-To: <20210719225906.GA2769608@robh.at.kernel.org>

On Tue, Jul 20, 2021 at 12:59 AM Rob Herring <robh@kernel.org> wrote:

> > > > Are there any issues with the bindings?
> > >
> > > Yes. Primarily the GPIO function being part of the compatible. I'm
> > > surprised Linus W is okay with that.
> >
> > I think I already explained this before, having a single compatible
> > won't work here.
> > Then there would not be anything to know whether its input or output
> > only as the pins
> > have specific purpose.
>
> The client side should tell the direction. Are you using the SFP
> binding?: Documentation/devicetree/bindings/net/sff,sfp.txt
>
> Specific purpose IOs are not general purpose IOs. Repeating Linus W
> here. Maybe his opinion has evolved...

Nah. I think at one time or two I was convinced to let something
special purpose slip through as "GPIO".

Typical case: LED control lines that were in practice used for other
things, such as controlling motors.

Here there is a pin named "SFP TX disable" which is suspicious.
Why isn't whatever is now managing SFP just read/write this bit
without going through the GPIO abstraction to disable TX?

If it is a regmap in Linux then that is fine, just pass the regmap
around inside the kernel, OK finished. But really that is an OS
detail.

If the pin is in practice used for other things, say connected
to a LED, I would soften up and accept it as a GPIO compatible.

> If the programming model of each instance is different, then different
> compatibles are justified. But describe what the difference is, not the
> connection.

IIRC that is the case as the instances are different.

So those differences should be described for each compatible in the
bindings.

So there is this:

> +  GPIO controller module provides GPIO-s for the SFP slots.
> +  It is split into 3 controllers, one output only for the SFP TX disable
> +  pins, one input only for the SFP present pins and one input only for
> +  the SFP LOS pins.

This should read "the hardware instances are different in such way
that the first can only (by hardware restrictions) be used as output..."
etc, so that it is crystal clear what this means.

But if the lines are special purpose not general purpose, they
should not be GPIOs to begin with.

Yours,
Linus Walleij

  reply	other threads:[~2021-07-21 14:17 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-07 12:33 [PATCH v6 1/6] mfd: simple-mfd-i2c: Add Delta TN48M CPLD support Robert Marko
2021-06-07 12:33 ` [PATCH v6 2/6] gpio: Add Delta TN48M CPLD GPIO driver Robert Marko
2021-06-07 12:33 ` [PATCH v6 3/6] dt-bindings: reset: Add Delta TN48M Robert Marko
2021-06-07 12:33 ` [PATCH v6 4/6] reset: Add Delta TN48M CPLD reset controller Robert Marko
2021-06-07 12:33 ` [PATCH v6 5/6] dt-bindings: mfd: Add Delta TN48M CPLD drivers bindings Robert Marko
2021-06-25 11:46   ` Robert Marko
2021-07-13 22:25     ` Rob Herring
2021-07-18  9:15       ` Robert Marko
2021-07-19 10:46         ` Lee Jones
2021-07-19 22:59         ` Rob Herring
2021-07-21 14:16           ` Linus Walleij [this message]
2021-08-03 19:22             ` Robert Marko
2021-08-11 12:17               ` Linus Walleij
2021-08-24  8:03                 ` Robert Marko
2021-09-07 21:02                   ` Robert Marko
2021-09-25 14:47                     ` Robert Marko
2021-10-03 22:48                   ` Linus Walleij
2021-10-12 16:31                     ` Robert Marko
2021-10-19  1:40                       ` Andrew Lunn
2021-10-19 10:49                         ` Robert Marko
2021-10-19  2:05         ` Andrew Lunn
2021-10-19 10:54           ` Robert Marko
2021-06-07 12:33 ` [PATCH v6 6/6] MAINTAINERS: Add Delta Networks TN48M CPLD drivers Robert Marko

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=CACRpkdbq6Jow6AT9OpsR7Q0JVCWVMcmamh9KHPXMtUnkoe7ZFw@mail.gmail.com \
    --to=linus.walleij@linaro.org \
    --cc=bgolaszewski@baylibre.com \
    --cc=buczek@molgen.mpg.de \
    --cc=devicetree@vger.kernel.org \
    --cc=jmp@epiphyte.org \
    --cc=lee.jones@linaro.org \
    --cc=linux-gpio@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luka.perkov@sartura.hr \
    --cc=p.zabel@pengutronix.de \
    --cc=pmenzel@molgen.mpg.de \
    --cc=robert.marko@sartura.hr \
    --cc=robh@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 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).