public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Mark Brown <broonie@opensource.wolfsonmicro.com>
To: Jassi Brar <jassisinghbrar@gmail.com>
Cc: David Brownell <dbrownell@users.sourceforge.net>,
	Grant Likely <grant.likely@secretlab.ca>,
	spi-devel-general@lists.sourceforge.net,
	linux-kernel@vger.kernel.org
Subject: Re: [spi-devel-general] [PATCH 1/2] spi/spi_s3c64xx: Make probe more robust against missing board config
Date: Mon, 23 Aug 2010 10:57:22 +0100	[thread overview]
Message-ID: <20100823095722.GA6061@rakim.wolfsonmicro.main> (raw)
In-Reply-To: <AANLkTikDj7YsOQXnFGjZCNRYuQQbLRtKiWw5Sm=vkCuq@mail.gmail.com>

On Sun, Aug 22, 2010 at 12:37:25PM +0900, Jassi Brar wrote:

> An immediate kernel crash ? :)
> I mean if the developer didn't even run-check the board init code, he ought
> to face a kernel crash.
> On a more lenient note, probably a check like yours or !sci->num_cs
> could be added.

I'd personally not actually be that upset with a BUG_ON(), my main
reason for changing the code was that it was non-obvious what the source
of the error was rather than the fact that things fell over.

> > It did occur to me that a nice way of dealing with this would be to have
> > the driver default to using the built in chip select (even if driven as
> > a GPIO for the sake of code simplicity) but leave the current method
> > there as an override.  That way if people are using the IP block in the
> > "natural" manner they'd have less to set up.

> I thought about it but decided against it, for that would complicate the
> driver by having to switch between two mechanism in runtime and there
> are some peculiarities in the controller about clocking and CS'ing.

Yeah, that's why I suggested driving it as a GPIO for simplicity - from
the user point of view it doesn't matter if that's what the controller
does so long as the driver figures out the chip select without external
help.

      reply	other threads:[~2010-08-23  9:57 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-08-20 16:17 [PATCH 1/2] spi/spi_s3c64xx: Make probe more robust against missing board config Mark Brown
2010-08-20 16:17 ` [PATCH 2/2] spi/spi_s3c64xx: Staticise non-exported functions Mark Brown
2010-08-21  1:52   ` [spi-devel-general] " Jassi Brar
2010-08-20 20:46 ` [PATCH 1/2] spi/spi_s3c64xx: Make probe more robust against missing board config Grant Likely
2010-08-21  1:45 ` [spi-devel-general] " Jassi Brar
2010-08-21 10:08   ` Mark Brown
2010-08-21 13:58     ` Jassi Brar
2010-08-21 19:30       ` Mark Brown
2010-08-22  3:37         ` Jassi Brar
2010-08-23  9:57           ` Mark Brown [this message]

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=20100823095722.GA6061@rakim.wolfsonmicro.main \
    --to=broonie@opensource.wolfsonmicro.com \
    --cc=dbrownell@users.sourceforge.net \
    --cc=grant.likely@secretlab.ca \
    --cc=jassisinghbrar@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=spi-devel-general@lists.sourceforge.net \
    /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