From: Mark Brown <broonie@kernel.org>
To: Alvaro Gamez Machado <alvaro.gamez@hazent.com>
Cc: Michal Simek <michal.simek@xilinx.com>,
Shubhrajyoti Datta <shubhraj@xilinx.com>,
linux-spi@vger.kernel.org, Rob Herring <robh+dt@kernel.org>,
devicetree@vger.kernel.org
Subject: Re: [PATCH] spi: set bits_per_word based on controller's bits_per_word_mask
Date: Thu, 24 Oct 2019 14:41:16 +0100 [thread overview]
Message-ID: <20191024134116.GF46373@sirena.co.uk> (raw)
In-Reply-To: <20191024131856.GA32609@salem.gmr.ssr.upm.es>
[-- Attachment #1: Type: text/plain, Size: 1634 bytes --]
On Thu, Oct 24, 2019 at 03:18:57PM +0200, Alvaro Gamez Machado wrote:
> On Thu, Oct 24, 2019 at 02:11:29PM +0100, Mark Brown wrote:
> > No, that still leaves the slave driver thinking it's sending 8 bits when
> > really it's sending something else - the default is just 8 bits, if the
> > controller can't do it then the transfer can't happen and there's an
> > error. It's not a good idea to carry on if we're likely to introduce
> > data corruption.
> Well, yes. But I don't think that's a software issue but a hardware one.
> If you have a board that has a SPI master that cannot talk to an 8 bits
> device and you expect to communicate with anything that accepts 8 bits
> you're not going to be able to. Either the kernel raises an error or it
> shuts up and tries its best. I understand the first option is better, but I
> also think that's not a software issue, that hardware simply cannot work as
> is regardless of what we do in software. The hardware devices simply can't
> talk to each other.
Sure, but then it's going to be easier to diagnose problems if the
software says that it's identified a data format problem than it is to
try to figure out the results of data corruption. There is also the
possibility that if the formats the hardware needs to use can be made to
align through rewriting software can persuade things to interoperate
(eg, if all the transfers are multiples of 32 bits then a device can
probably work with a controller that only supports 32 bit words even if
the device expects a byte stream) but that requires explicit code rather
than just silently accepting the data and hoping for the best.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
next prev parent reply other threads:[~2019-10-24 13:41 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-10-24 11:07 [PATCH] Allowing Xilinx's AXI Quad widths different than 8 bits on userspace Alvaro Gamez Machado
2019-10-24 11:07 ` [PATCH] spi: xilinx: add description of new property xlnx,num-transfer-bits Alvaro Gamez Machado
2019-10-24 11:57 ` Mark Brown
2019-10-24 11:57 ` Applied "spi: xilinx: add description of new property xlnx,num-transfer-bits" to the spi tree Mark Brown
2019-10-24 11:07 ` [PATCH] spi: xilinx: Add DT support for selecting transfer word width Alvaro Gamez Machado
2019-10-24 11:57 ` Applied "spi: xilinx: Add DT support for selecting transfer word width" to the spi tree Mark Brown
2019-10-24 11:07 ` [PATCH] spi: set bits_per_word based on controller's bits_per_word_mask Alvaro Gamez Machado
2019-10-24 11:13 ` Mark Brown
2019-10-24 12:54 ` Alvaro Gamez Machado
2019-10-24 13:11 ` Mark Brown
2019-10-24 13:18 ` Alvaro Gamez Machado
2019-10-24 13:41 ` Mark Brown [this message]
2019-10-24 14:07 ` Alvaro Gamez Machado
2019-10-24 17:40 ` Mark Brown
2019-10-25 6:39 ` Alvaro Gamez Machado
2019-10-25 11:56 ` Mark Brown
2019-10-28 9:43 ` Alvaro Gamez Machado
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=20191024134116.GF46373@sirena.co.uk \
--to=broonie@kernel.org \
--cc=alvaro.gamez@hazent.com \
--cc=devicetree@vger.kernel.org \
--cc=linux-spi@vger.kernel.org \
--cc=michal.simek@xilinx.com \
--cc=robh+dt@kernel.org \
--cc=shubhraj@xilinx.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 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).