All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mark Brown <broonie@kernel.org>
To: Jane Wan <Jane.Wan@gainspeed.com>
Cc: "grant.likely@linaro.org" <grant.likely@linaro.org>,
	"robh+dt@kernel.org" <robh+dt@kernel.org>,
	"Emilian.Medve@Freescale.com" <Emilian.Medve@Freescale.com>,
	"kenth.eriksson@transmode.com" <kenth.eriksson@transmode.com>,
	"thomas.de.schampheleire@gmail.com" 
	<thomas.de.schampheleire@gmail.com>,
	"b48286@freescale.com" <b48286@Freescale.com>,
	"jg1.han@samsung.com" <jg1.han@samsung.com>,
	"sr@denx.de" <sr@denx.de>, Insop Song <Insop.Song@gainspeed.com>,
	"linux-spi@vger.kernel.org" <linux-spi@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>
Subject: Re: [PATCH] Configure FSL eSPI CSBEF, CSAFT, and whether to send all received data to user
Date: Wed, 16 Apr 2014 18:28:30 +0100	[thread overview]
Message-ID: <20140416172830.GV12304@sirena.org.uk> (raw)
In-Reply-To: <6f2c800fbba74470a6a49903b34e7796@SN2PR07MB064.namprd07.prod.outlook.com>

[-- Attachment #1: Type: text/plain, Size: 1318 bytes --]

On Wed, Apr 16, 2014 at 04:39:47PM +0000, Jane Wan wrote:
> On Mon, Apr 14, 2014 at 09:51:56PM +0100, Mark Brown wrote:

> > > +		if (spi_raw_rxdata_to_user[m->spi->chip_select])
> > > +			espi_trans->len = n_tx;
> > > +		else
> > > +			espi_trans->len = trans_len + n_tx;

> > Why is there even an option for the buggy behaviour?

> We have three devices attached to the FSL eSPI interface, with chip select (CS) 
> 0-2. The device driver for the device at CS #2 requires to know all the data that 
> the slave device put on MISO.  But the device drivers for the other two devices 
> (at CS #0 and #1) work with the existing FSL eSPI driver.  The device at CS #0 is 
> Micron n25q512a compatible.

> We make the FSL eSPI driver configurable through device tree.  If we make a fix 
> without the DT option, the fix will break other device drivers working with the 
> existing FSL eSPI driver.

> Could this still be considered as a solution?  If this is ok, I can send it as a separate 
> patch.  Otherwise, we will look if this driver can be modified without DT option.

No, this is completely unaceptable.  The drivers relying on the buggy
behaviour are broken and must be fixed.  The whole point of DT is to
describe the hardware, not to allow the OS to implement workarounds for
itself.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

WARNING: multiple messages have this Message-ID (diff)
From: Mark Brown <broonie-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
To: Jane Wan <Jane.Wan-X7+3OicCfH32eFz/2MeuCQ@public.gmane.org>
Cc: "grant.likely-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org"
	<grant.likely-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>,
	"robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org"
	<robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
	"Emilian.Medve-eDlz3WWmN0ll57MIdRCFDg@public.gmane.org"
	<Emilian.Medve-eDlz3WWmN0ll57MIdRCFDg@public.gmane.org>,
	"kenth.eriksson-SNLAxHN9vbdl57MIdRCFDg@public.gmane.org"
	<kenth.eriksson-SNLAxHN9vbdl57MIdRCFDg@public.gmane.org>,
	"thomas.de.schampheleire-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org"
	<thomas.de.schampheleire-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
	"b48286-KZfg59tc24xl57MIdRCFDg@public.gmane.org"
	<b48286-KZfg59tc24xl57MIdRCFDg@public.gmane.org>,
	"jg1.han-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org"
	<jg1.han-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>,
	"sr-ynQEQJNshbs@public.gmane.org"
	<sr-ynQEQJNshbs@public.gmane.org>,
	Insop Song <Insop.Song-X7+3OicCfH32eFz/2MeuCQ@public.gmane.org>,
	"linux-spi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
	<linux-spi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	"linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
	<linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	"devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
	<devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
Subject: Re: [PATCH] Configure FSL eSPI CSBEF, CSAFT, and whether to send all received data to user
Date: Wed, 16 Apr 2014 18:28:30 +0100	[thread overview]
Message-ID: <20140416172830.GV12304@sirena.org.uk> (raw)
In-Reply-To: <6f2c800fbba74470a6a49903b34e7796-w1qlG7ycJuujtJEAekZsixQPvRvOrrxkXA4E9RH9d+qIuWR1G4zioA@public.gmane.org>

[-- Attachment #1: Type: text/plain, Size: 1318 bytes --]

On Wed, Apr 16, 2014 at 04:39:47PM +0000, Jane Wan wrote:
> On Mon, Apr 14, 2014 at 09:51:56PM +0100, Mark Brown wrote:

> > > +		if (spi_raw_rxdata_to_user[m->spi->chip_select])
> > > +			espi_trans->len = n_tx;
> > > +		else
> > > +			espi_trans->len = trans_len + n_tx;

> > Why is there even an option for the buggy behaviour?

> We have three devices attached to the FSL eSPI interface, with chip select (CS) 
> 0-2. The device driver for the device at CS #2 requires to know all the data that 
> the slave device put on MISO.  But the device drivers for the other two devices 
> (at CS #0 and #1) work with the existing FSL eSPI driver.  The device at CS #0 is 
> Micron n25q512a compatible.

> We make the FSL eSPI driver configurable through device tree.  If we make a fix 
> without the DT option, the fix will break other device drivers working with the 
> existing FSL eSPI driver.

> Could this still be considered as a solution?  If this is ok, I can send it as a separate 
> patch.  Otherwise, we will look if this driver can be modified without DT option.

No, this is completely unaceptable.  The drivers relying on the buggy
behaviour are broken and must be fixed.  The whole point of DT is to
describe the hardware, not to allow the OS to implement workarounds for
itself.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

  reply	other threads:[~2014-04-16 17:29 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-04-12 18:48 [PATCH] Configure FSL eSPI CSBEF, CSAFT, and whether to send all received data to user Jane Wan
2014-04-12 18:48 ` Jane Wan
2014-04-14 20:55   ` Mark Brown
2014-04-16 16:39     ` Jane Wan
2014-04-16 16:39       ` Jane Wan
2014-04-16 17:28       ` Mark Brown [this message]
2014-04-16 17:28         ` Mark Brown
2014-04-14 20:51 ` Mark Brown
2014-04-14 21:38   ` Insop Song
2014-04-14 21:38     ` Insop Song
2014-04-14 23:49     ` Mark Brown
2014-04-14 23:49       ` Mark Brown
2014-04-14 23:59       ` Insop Song
2014-04-14 23:59         ` Insop Song
2014-04-15  0:00       ` Insop Song
2014-04-15  0:00         ` Insop Song
2014-04-15 12:11         ` Mark Brown
2014-04-15 12:11           ` Mark Brown

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=20140416172830.GV12304@sirena.org.uk \
    --to=broonie@kernel.org \
    --cc=Emilian.Medve@Freescale.com \
    --cc=Insop.Song@gainspeed.com \
    --cc=Jane.Wan@gainspeed.com \
    --cc=b48286@Freescale.com \
    --cc=devicetree@vger.kernel.org \
    --cc=grant.likely@linaro.org \
    --cc=jg1.han@samsung.com \
    --cc=kenth.eriksson@transmode.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-spi@vger.kernel.org \
    --cc=robh+dt@kernel.org \
    --cc=sr@denx.de \
    --cc=thomas.de.schampheleire@gmail.com \
    /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.