All of lore.kernel.org
 help / color / mirror / Atom feed
From: Lee Jones <lee.jones@linaro.org>
To: Alexandre Belloni <alexandre.belloni@bootlin.com>
Cc: Geert Uytterhoeven <geert@linux-m68k.org>,
	radu_nicolae.pirea@upb.ro, Rob Herring <robh+dt@kernel.org>,
	Mark Rutland <mark.rutland@arm.com>,
	Nicolas Ferre <nicolas.ferre@microchip.com>,
	Greg KH <gregkh@linuxfoundation.org>,
	Mark Brown <broonie@kernel.org>, Jiri Slaby <jslaby@suse.com>,
	Richard Genoud <richard.genoud@gmail.com>,
	"David S. Miller" <davem@davemloft.net>,
	Mauro Carvalho Chehab <mchehab+samsung@kernel.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Arnd Bergmann <arnd@arndb.de>,
	"open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" 
	<devicetree@vger.kernel.org>,
	Linux ARM <linux-arm-kernel@lists.infradead.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	"open list:SERIAL DRIVERS" <linux-serial@vger.kernel.org>,
	linux-spi <linux-spi@vger.kernel.org>
Subject: Re: [PATCH v12 0/6] Driver for at91 usart in spi mode
Date: Wed, 12 Sep 2018 14:12:48 +0100	[thread overview]
Message-ID: <20180912131248.GA21544@dell> (raw)
In-Reply-To: <20180912121420.GE2760@piout.net>

On Wed, 12 Sep 2018, Alexandre Belloni wrote:

> On 12/09/2018 12:43:52+0100, Lee Jones wrote:
> > > > But ... we can't have it both ways.  *Either* it's a true MFD, in
> > > > which case it can/should have 2 separate compatible strings which can
> > > > be specified directly from the DT.  *Or* it's not an MFD.  In the
> > > > latter case, which I think we're all agreeing on (else we'd have 2
> > > > compatible strings), MFD is not the place to handle this (my original
> > > > point).
> > > > 
> > > 
> > > If that is what bothers you, then let's move it out of mfd.
> > 
> > As I've already mentioned.  I don't just want it moved out of MFD and
> > shoved somewhere else.  My aim is to fix this properly.
> > 
> 
> If it is out of MFD, then I'm not sure why you would care too much about
> it as you won't be maintaining that code. And I still this what was done
> was correct but I'm open to test what you suggest.

I care for the kernel in general, not just the areas I'm responsible
for.  I guess I'm just that kinda guy! ;)

> > > > So ... this is a USART device which can do SPI, right?
> > > > 
> > > > My current thinking is that; as this is a USART device first &
> > > > foremost, the USART should be probed in the first instance regardless,
> > > > then if SPI mode is specified it (the USART driver) registers the SPI
> > > > platform driver (as MFD does currently) and exits gracefully, allowing
> > > > the SPI driver to take over.
> > > > 
> > > > Spanner in the works: is it physically possible to change the mode at
> > > > run-time?  :s
> > > 
> > > Yes it is possible but on Linux that will not happen without probing
> > > the drivers again.
> > 
> > Not sure I understand what you mean.
> 
> I was just commenting on changing the mode at runtime.

Oh I see.  My question was relating to whether the H/W is physically
capable of changing modes on-the-fly, rather than how Linux would
handle that.  If this is something we'd wish to support, then it would
have to be a single driver, which is why I was asking.  By separating
the drivers this way, we are blocking that as a possibility.  Although
I guess the OP has already thought about that and made the decision
not to support it.

> > I'm suggesting that you use the same platform_* interfaces MFD uses to
> > register the SPI driver if SPI mode has been selected.  Only do so
> > from the appropriate driver i.e. USART.
> 
> Yeah, I understood that but I didn't comment because I'm not sure this
> will work yet.

Other drivers already do this.

-- 
Lee Jones [李琼斯]
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

WARNING: multiple messages have this Message-ID (diff)
From: Lee Jones <lee.jones@linaro.org>
To: Alexandre Belloni <alexandre.belloni@bootlin.com>
Cc: Geert Uytterhoeven <geert@linux-m68k.org>,
	radu_nicolae.pirea@upb.ro, Rob Herring <robh+dt@kernel.org>,
	Mark Rutland <mark.rutland@arm.com>,
	Nicolas Ferre <nicolas.ferre@microchip.com>,
	Greg KH <gregkh@linuxfoundation.org>,
	Mark Brown <broonie@kernel.org>, Jiri Slaby <jslaby@suse.com>,
	Richard Genoud <richard.genoud@gmail.com>,
	"David S. Miller" <davem@davemloft.net>,
	Mauro Carvalho Chehab <mchehab+samsung@kernel.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Arnd Bergmann <arnd@arndb.de>,
	"open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS"
	<devicetree@vger.kernel.org>,
	Linux ARM <linux-arm-kernel@lists.infradead.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	"open list:SERIAL DRIVERS"
	<linux-serial@vger.kernel.org>linux-spi <l>
Subject: Re: [PATCH v12 0/6] Driver for at91 usart in spi mode
Date: Wed, 12 Sep 2018 14:12:48 +0100	[thread overview]
Message-ID: <20180912131248.GA21544@dell> (raw)
In-Reply-To: <20180912121420.GE2760@piout.net>

On Wed, 12 Sep 2018, Alexandre Belloni wrote:

> On 12/09/2018 12:43:52+0100, Lee Jones wrote:
> > > > But ... we can't have it both ways.  *Either* it's a true MFD, in
> > > > which case it can/should have 2 separate compatible strings which can
> > > > be specified directly from the DT.  *Or* it's not an MFD.  In the
> > > > latter case, which I think we're all agreeing on (else we'd have 2
> > > > compatible strings), MFD is not the place to handle this (my original
> > > > point).
> > > > 
> > > 
> > > If that is what bothers you, then let's move it out of mfd.
> > 
> > As I've already mentioned.  I don't just want it moved out of MFD and
> > shoved somewhere else.  My aim is to fix this properly.
> > 
> 
> If it is out of MFD, then I'm not sure why you would care too much about
> it as you won't be maintaining that code. And I still this what was done
> was correct but I'm open to test what you suggest.

I care for the kernel in general, not just the areas I'm responsible
for.  I guess I'm just that kinda guy! ;)

> > > > So ... this is a USART device which can do SPI, right?
> > > > 
> > > > My current thinking is that; as this is a USART device first &
> > > > foremost, the USART should be probed in the first instance regardless,
> > > > then if SPI mode is specified it (the USART driver) registers the SPI
> > > > platform driver (as MFD does currently) and exits gracefully, allowing
> > > > the SPI driver to take over.
> > > > 
> > > > Spanner in the works: is it physically possible to change the mode at
> > > > run-time?  :s
> > > 
> > > Yes it is possible but on Linux that will not happen without probing
> > > the drivers again.
> > 
> > Not sure I understand what you mean.
> 
> I was just commenting on changing the mode at runtime.

Oh I see.  My question was relating to whether the H/W is physically
capable of changing modes on-the-fly, rather than how Linux would
handle that.  If this is something we'd wish to support, then it would
have to be a single driver, which is why I was asking.  By separating
the drivers this way, we are blocking that as a possibility.  Although
I guess the OP has already thought about that and made the decision
not to support it.

> > I'm suggesting that you use the same platform_* interfaces MFD uses to
> > register the SPI driver if SPI mode has been selected.  Only do so
> > from the appropriate driver i.e. USART.
> 
> Yeah, I understood that but I didn't comment because I'm not sure this
> will work yet.

Other drivers already do this.

-- 
Lee Jones [李琼斯]
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

WARNING: multiple messages have this Message-ID (diff)
From: Lee Jones <lee.jones@linaro.org>
To: Alexandre Belloni <alexandre.belloni@bootlin.com>
Cc: Geert Uytterhoeven <geert@linux-m68k.org>,
	radu_nicolae.pirea@upb.ro, Rob Herring <robh+dt@kernel.org>,
	Mark Rutland <mark.rutland@arm.com>,
	Nicolas Ferre <nicolas.ferre@microchip.com>,
	Greg KH <gregkh@linuxfoundation.org>,
	Mark Brown <broonie@kernel.org>, Jiri Slaby <jslaby@suse.com>,
	Richard Genoud <richard.genoud@gmail.com>,
	"David S. Miller" <davem@davemloft.net>,
	Mauro Carvalho Chehab <mchehab+samsung@kernel.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Arnd Bergmann <arnd@arndb.de>,
	"open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS"
	<devicetree@vger.kernel.org>,
	Linux ARM <linux-arm-kernel@lists.infradead.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	"open list:SERIAL DRIVERS" <linux-serial@vger.kernel.org>,
	linux-spi <l
Subject: Re: [PATCH v12 0/6] Driver for at91 usart in spi mode
Date: Wed, 12 Sep 2018 14:12:48 +0100	[thread overview]
Message-ID: <20180912131248.GA21544@dell> (raw)
In-Reply-To: <20180912121420.GE2760@piout.net>

On Wed, 12 Sep 2018, Alexandre Belloni wrote:

> On 12/09/2018 12:43:52+0100, Lee Jones wrote:
> > > > But ... we can't have it both ways.  *Either* it's a true MFD, in
> > > > which case it can/should have 2 separate compatible strings which can
> > > > be specified directly from the DT.  *Or* it's not an MFD.  In the
> > > > latter case, which I think we're all agreeing on (else we'd have 2
> > > > compatible strings), MFD is not the place to handle this (my original
> > > > point).
> > > > 
> > > 
> > > If that is what bothers you, then let's move it out of mfd.
> > 
> > As I've already mentioned.  I don't just want it moved out of MFD and
> > shoved somewhere else.  My aim is to fix this properly.
> > 
> 
> If it is out of MFD, then I'm not sure why you would care too much about
> it as you won't be maintaining that code. And I still this what was done
> was correct but I'm open to test what you suggest.

I care for the kernel in general, not just the areas I'm responsible
for.  I guess I'm just that kinda guy! ;)

> > > > So ... this is a USART device which can do SPI, right?
> > > > 
> > > > My current thinking is that; as this is a USART device first &
> > > > foremost, the USART should be probed in the first instance regardless,
> > > > then if SPI mode is specified it (the USART driver) registers the SPI
> > > > platform driver (as MFD does currently) and exits gracefully, allowing
> > > > the SPI driver to take over.
> > > > 
> > > > Spanner in the works: is it physically possible to change the mode at
> > > > run-time?  :s
> > > 
> > > Yes it is possible but on Linux that will not happen without probing
> > > the drivers again.
> > 
> > Not sure I understand what you mean.
> 
> I was just commenting on changing the mode at runtime.

Oh I see.  My question was relating to whether the H/W is physically
capable of changing modes on-the-fly, rather than how Linux would
handle that.  If this is something we'd wish to support, then it would
have to be a single driver, which is why I was asking.  By separating
the drivers this way, we are blocking that as a possibility.  Although
I guess the OP has already thought about that and made the decision
not to support it.

> > I'm suggesting that you use the same platform_* interfaces MFD uses to
> > register the SPI driver if SPI mode has been selected.  Only do so
> > from the appropriate driver i.e. USART.
> 
> Yeah, I understood that but I didn't comment because I'm not sure this
> will work yet.

Other drivers already do this.

-- 
Lee Jones [李琼斯]
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

WARNING: multiple messages have this Message-ID (diff)
From: lee.jones@linaro.org (Lee Jones)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v12 0/6] Driver for at91 usart in spi mode
Date: Wed, 12 Sep 2018 14:12:48 +0100	[thread overview]
Message-ID: <20180912131248.GA21544@dell> (raw)
In-Reply-To: <20180912121420.GE2760@piout.net>

On Wed, 12 Sep 2018, Alexandre Belloni wrote:

> On 12/09/2018 12:43:52+0100, Lee Jones wrote:
> > > > But ... we can't have it both ways.  *Either* it's a true MFD, in
> > > > which case it can/should have 2 separate compatible strings which can
> > > > be specified directly from the DT.  *Or* it's not an MFD.  In the
> > > > latter case, which I think we're all agreeing on (else we'd have 2
> > > > compatible strings), MFD is not the place to handle this (my original
> > > > point).
> > > > 
> > > 
> > > If that is what bothers you, then let's move it out of mfd.
> > 
> > As I've already mentioned.  I don't just want it moved out of MFD and
> > shoved somewhere else.  My aim is to fix this properly.
> > 
> 
> If it is out of MFD, then I'm not sure why you would care too much about
> it as you won't be maintaining that code. And I still this what was done
> was correct but I'm open to test what you suggest.

I care for the kernel in general, not just the areas I'm responsible
for.  I guess I'm just that kinda guy! ;)

> > > > So ... this is a USART device which can do SPI, right?
> > > > 
> > > > My current thinking is that; as this is a USART device first &
> > > > foremost, the USART should be probed in the first instance regardless,
> > > > then if SPI mode is specified it (the USART driver) registers the SPI
> > > > platform driver (as MFD does currently) and exits gracefully, allowing
> > > > the SPI driver to take over.
> > > > 
> > > > Spanner in the works: is it physically possible to change the mode at
> > > > run-time?  :s
> > > 
> > > Yes it is possible but on Linux that will not happen without probing
> > > the drivers again.
> > 
> > Not sure I understand what you mean.
> 
> I was just commenting on changing the mode at runtime.

Oh I see.  My question was relating to whether the H/W is physically
capable of changing modes on-the-fly, rather than how Linux would
handle that.  If this is something we'd wish to support, then it would
have to be a single driver, which is why I was asking.  By separating
the drivers this way, we are blocking that as a possibility.  Although
I guess the OP has already thought about that and made the decision
not to support it.

> > I'm suggesting that you use the same platform_* interfaces MFD uses to
> > register the SPI driver if SPI mode has been selected.  Only do so
> > from the appropriate driver i.e. USART.
> 
> Yeah, I understood that but I didn't comment because I'm not sure this
> will work yet.

Other drivers already do this.

-- 
Lee Jones [???]
Linaro Services Technical Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

  reply	other threads:[~2018-09-12 13:13 UTC|newest]

Thread overview: 127+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-09-04 11:13 [PATCH v12 0/6] Driver for at91 usart in spi mode Radu Pirea
2018-09-04 11:13 ` Radu Pirea
2018-09-04 11:13 ` Radu Pirea
2018-09-04 11:13 ` [PATCH v12 1/6] MAINTAINERS: add at91 usart mfd driver Radu Pirea
2018-09-04 11:13   ` Radu Pirea
2018-09-04 11:13   ` Radu Pirea
2018-09-04 11:13 ` [PATCH v12 2/6] dt-bindings: add binding for atmel-usart in SPI mode Radu Pirea
2018-09-04 11:13   ` Radu Pirea
2018-09-04 11:13   ` Radu Pirea
2018-09-04 11:13 ` [PATCH v12 3/6] mfd: at91-usart: added mfd driver for usart Radu Pirea
2018-09-04 11:13   ` Radu Pirea
2018-09-04 11:13   ` Radu Pirea
2018-09-04 11:13 ` [PATCH v12 4/6] MAINTAINERS: add at91 usart spi driver Radu Pirea
2018-09-04 11:13   ` Radu Pirea
2018-09-04 11:13   ` Radu Pirea
2018-09-04 11:13 ` [PATCH v12 5/6] spi: at91-usart: add driver for at91-usart as spi Radu Pirea
2018-09-04 11:13   ` Radu Pirea
2018-09-04 11:13   ` Radu Pirea
2018-09-04 11:13 ` [PATCH v12 6/6] tty/serial: atmel: change the driver to work under at91-usart mfd Radu Pirea
2018-09-04 11:13   ` Radu Pirea
2018-09-04 11:13   ` Radu Pirea
2018-09-10  9:48 ` [PATCH v12 0/6] Driver for at91 usart in spi mode Lee Jones
2018-09-10  9:48   ` Lee Jones
2018-09-10  9:51   ` Nicolas Ferre
2018-09-10  9:51     ` Nicolas Ferre
2018-09-10  9:51     ` Nicolas Ferre
2018-09-10 13:43     ` Lee Jones
2018-09-10 13:43       ` Lee Jones
2018-09-11  9:33 ` Lee Jones
2018-09-11  9:33   ` Lee Jones
2018-09-11  9:39   ` Alexandre Belloni
2018-09-11  9:39     ` Alexandre Belloni
2018-09-11 14:59     ` Geert Uytterhoeven
2018-09-11 14:59       ` Geert Uytterhoeven
2018-09-11 14:59       ` Geert Uytterhoeven
2018-09-11 14:59       ` Geert Uytterhoeven
2018-09-11 15:36       ` Alexandre Belloni
2018-09-11 15:36         ` Alexandre Belloni
2018-09-11 15:36         ` Alexandre Belloni
2018-09-11 15:36         ` Alexandre Belloni
2018-09-11 16:23         ` Geert Uytterhoeven
2018-09-11 16:23           ` Geert Uytterhoeven
2018-09-11 16:23           ` Geert Uytterhoeven
2018-09-11 16:23           ` Geert Uytterhoeven
2018-09-11 18:39           ` Lee Jones
2018-09-11 18:39             ` Lee Jones
2018-09-11 18:39             ` Lee Jones
2018-09-11 18:39             ` Lee Jones
2018-09-11 18:58             ` Alexandre Belloni
2018-09-11 18:58               ` Alexandre Belloni
2018-09-11 18:58               ` Alexandre Belloni
2018-09-11 18:58               ` Alexandre Belloni
2018-09-11 19:04               ` Geert Uytterhoeven
2018-09-11 19:04                 ` Geert Uytterhoeven
2018-09-11 19:04                 ` Geert Uytterhoeven
2018-09-11 19:04                 ` Geert Uytterhoeven
2018-09-11 22:44               ` Lee Jones
2018-09-11 22:44                 ` Lee Jones
2018-09-11 22:44                 ` Lee Jones
2018-09-11 22:44                 ` Lee Jones
2018-09-11 22:54                 ` Lee Jones
2018-09-11 22:54                   ` Lee Jones
2018-09-11 22:54                   ` Lee Jones
2018-09-11 22:54                   ` Lee Jones
2018-09-12  7:33                   ` Alexandre Belloni
2018-09-12  7:33                     ` Alexandre Belloni
2018-09-12  7:33                     ` Alexandre Belloni
2018-09-12  7:33                     ` Alexandre Belloni
2018-09-12  8:41                     ` Lee Jones
2018-09-12  8:41                       ` Lee Jones
2018-09-12  8:41                       ` Lee Jones
2018-09-12  8:41                       ` Lee Jones
2018-09-12  9:43                       ` Geert Uytterhoeven
2018-09-12  9:43                         ` Geert Uytterhoeven
2018-09-12  9:43                         ` Geert Uytterhoeven
2018-09-12  9:43                         ` Geert Uytterhoeven
2018-09-12 10:54                         ` Lee Jones
2018-09-12 10:54                           ` Lee Jones
2018-09-12 10:54                           ` Lee Jones
2018-09-12 10:54                           ` Lee Jones
2018-09-12 11:17                           ` Alexandre Belloni
2018-09-12 11:17                             ` Alexandre Belloni
2018-09-12 11:17                             ` Alexandre Belloni
2018-09-12 11:17                             ` Alexandre Belloni
2018-09-12 11:43                             ` Lee Jones
2018-09-12 11:43                               ` Lee Jones
2018-09-12 11:43                               ` Lee Jones
2018-09-12 11:43                               ` Lee Jones
2018-09-12 12:14                               ` Alexandre Belloni
2018-09-12 12:14                                 ` Alexandre Belloni
2018-09-12 12:14                                 ` Alexandre Belloni
2018-09-12 12:14                                 ` Alexandre Belloni
2018-09-12 13:12                                 ` Lee Jones [this message]
2018-09-12 13:12                                   ` Lee Jones
2018-09-12 13:12                                   ` Lee Jones
2018-09-12 13:12                                   ` Lee Jones
2018-09-12 19:36                                   ` Radu Pirea
2018-09-12 19:36                                     ` Radu Pirea
2018-09-12 19:36                                     ` Radu Pirea
2018-10-09  9:04                                     ` Lee Jones
2018-10-09  9:04                                       ` Lee Jones
2018-10-09  9:04                                       ` Lee Jones
2018-10-09  9:04                                       ` Lee Jones
2018-09-11 18:59             ` Geert Uytterhoeven
2018-09-11 18:59               ` Geert Uytterhoeven
2018-09-11 18:59               ` Geert Uytterhoeven
2018-09-11 18:59               ` Geert Uytterhoeven
2018-09-11 22:43               ` Lee Jones
2018-09-11 22:43                 ` Lee Jones
2018-09-11 22:43                 ` Lee Jones
2018-09-11 22:43                 ` Lee Jones
2018-09-12  7:30                 ` Alexandre Belloni
2018-09-12  7:30                   ` Alexandre Belloni
2018-09-12  7:30                   ` Alexandre Belloni
2018-09-12  7:30                   ` Alexandre Belloni
2018-09-12  8:36                   ` Lee Jones
2018-09-12  8:36                     ` Lee Jones
2018-09-12  8:36                     ` Lee Jones
2018-09-12  8:36                     ` Lee Jones
2018-09-11 11:18 ` [GIT PULL v2] Immutable branch between MFD, SPI and TTY due for the v4.20 merge window Lee Jones
2018-09-11 11:18   ` Lee Jones
2018-09-11 14:04   ` Greg KH
2018-09-11 14:04     ` Greg KH
2018-09-11 14:07     ` Lee Jones
2018-09-11 14:07       ` Lee Jones
2018-09-11 14:12       ` Greg KH
2018-09-11 14:12         ` Greg KH

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=20180912131248.GA21544@dell \
    --to=lee.jones@linaro.org \
    --cc=akpm@linux-foundation.org \
    --cc=alexandre.belloni@bootlin.com \
    --cc=arnd@arndb.de \
    --cc=broonie@kernel.org \
    --cc=davem@davemloft.net \
    --cc=devicetree@vger.kernel.org \
    --cc=geert@linux-m68k.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=jslaby@suse.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-serial@vger.kernel.org \
    --cc=linux-spi@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=mchehab+samsung@kernel.org \
    --cc=nicolas.ferre@microchip.com \
    --cc=radu_nicolae.pirea@upb.ro \
    --cc=richard.genoud@gmail.com \
    --cc=robh+dt@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.