public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Mark Brown <broonie@kernel.org>
To: Michal Suchanek <hramrach@gmail.com>
Cc: "Brian Norris" <computersforpeace@gmail.com>,
	linux-sunxi <linux-sunxi@googlegroups.com>,
	"Rob Herring" <robh+dt@kernel.org>,
	"Pawel Moll" <pawel.moll@arm.com>,
	"Mark Rutland" <mark.rutland@arm.com>,
	"Ian Campbell" <ijc+devicetree@hellion.org.uk>,
	"Kumar Gala" <galak@codeaurora.org>,
	"David Woodhouse" <dwmw2@infradead.org>,
	"Marek Vasut" <marex@denx.de>,
	"Huang Shijie" <b32955@freescale.com>,
	"Rafał Miłecki" <zajec5@gmail.com>,
	"Ben Hutchings" <ben@decadent.org.uk>,
	"Alison Chaiken" <alison_chaiken@mentor.com>,
	"Mika Westerberg" <mika.westerberg@linux.intel.com>,
	"Bean Huo 霍斌斌 (beanhuo)" <beanhuo@micron.com>,
	"grmoore@altera.com" <grmoore@altera.com>,
	devicetree <devicetree@vger.kernel.org>,
	"Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>,
	linux-mtd@lists.infradead.org,
	linux-spi <linux-spi@vger.kernel.org>
Subject: Re: [PATCH 2/3] MTD: spi-nor: check for short writes in spi_nor_write.
Date: Thu, 21 May 2015 11:28:02 +0100	[thread overview]
Message-ID: <20150521102802.GS21577@sirena.org.uk> (raw)
In-Reply-To: <CAOMqctTYqDWL51twOuGi+oXONXQ4B2-2BkdJNSpzZAXshZUN6g@mail.gmail.com>

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

On Thu, May 21, 2015 at 10:39:13AM +0200, Michal Suchanek wrote:
> On 21 May 2015 at 01:38, Brian Norris <computersforpeace@gmail.com> wrote:

Why is this thread about SPI error handling CCed to quite so many
people?

> >> Check the amount of data actually written by the driver.

> > I'm not sure if we should just reactively use the retlen, or if we
> > should be communicating such a limitation via the SPI API. Thoughts?

> Is there any driver that would break if the SPI master truncated
> writes when the message is too long rather than returning an error an
> refusing the transfer?

Any such driver is buggy, the actual length transferred has always been
a part of the SPI API.  We should probably expose limitations so clients
can query in advance (we don't at the minute) but it'd be a while before
clients could rely on that information being useful and it's still
possible things can be truncated by error.

With modern drivers using transfer_one() where we have control of the
chip select we do also have the ability to add support to the core for
chopping large transfers up into smaller ones that the hardware can
handle transparently.  That won't for everything though since it depends
on us being able to manually control the chip select which not all
hardware can do.

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

  reply	other threads:[~2015-05-21 10:28 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <cover.1430403750.git.hramrach@gmail.com>
     [not found] ` <3b0c112672f364452e80c333048161eaffb655db.1430403750.git.hramrach@gmail.com>
2015-04-30 14:58   ` [linux-sunxi] [PATCH 3/3] MTD: m25p80: Add option to limit SPI transfer size Julian Calaby
2015-05-20 23:27     ` Brian Norris
2015-04-30 16:30 ` [PATCH 0/3] Using SPI NOR flah on sunxi Thomas.Betker
2015-04-30 16:56   ` Michal Suchanek
2015-04-30 18:34     ` Marek Vasut
2015-05-20 23:54       ` Brian Norris
     [not found] ` <55132b4496e7fe73f949186c0f140f3e4fd4e2c7.1430403750.git.hramrach@gmail.com>
2015-04-30 18:43   ` [PATCH 1/3] MTD: m25p80: fix write return value Marek Vasut
2015-04-30 21:37     ` Michal Suchanek
     [not found] ` <jwv4mnwfppf.fsf-monnier+gmane.comp.hardware.netbook.arm.sunxi@gnu.org>
2015-05-04 10:32   ` [linux-sunxi] Re: [PATCH 0/3] Using SPI NOR flah on sunxi Michal Suchanek
     [not found] ` <50c40ef17ab6566f35ef5a4426bf23567f896db7.1430403750.git.hramrach@gmail.com>
2015-05-20 23:38   ` [PATCH 2/3] MTD: spi-nor: check for short writes in spi_nor_write Brian Norris
2015-05-21  8:39     ` Michal Suchanek
2015-05-21 10:28       ` Mark Brown [this message]
2015-05-22  7:17         ` Brian Norris
2015-05-22  7:25           ` Brian Norris
2015-05-22  9:37             ` 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=20150521102802.GS21577@sirena.org.uk \
    --to=broonie@kernel.org \
    --cc=alison_chaiken@mentor.com \
    --cc=b32955@freescale.com \
    --cc=beanhuo@micron.com \
    --cc=ben@decadent.org.uk \
    --cc=computersforpeace@gmail.com \
    --cc=devicetree@vger.kernel.org \
    --cc=dwmw2@infradead.org \
    --cc=galak@codeaurora.org \
    --cc=grmoore@altera.com \
    --cc=hramrach@gmail.com \
    --cc=ijc+devicetree@hellion.org.uk \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mtd@lists.infradead.org \
    --cc=linux-spi@vger.kernel.org \
    --cc=linux-sunxi@googlegroups.com \
    --cc=marex@denx.de \
    --cc=mark.rutland@arm.com \
    --cc=mika.westerberg@linux.intel.com \
    --cc=pawel.moll@arm.com \
    --cc=robh+dt@kernel.org \
    --cc=zajec5@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox