linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Mark Brown <broonie@kernel.org>
To: Adrian Fiergolski <Adrian.Fiergolski@cern.ch>
Cc: linux-spi@vger.kernel.org, robh+dt@kernel.org,
	mark.rutland@arm.com, devicetree@vger.kernel.org,
	linux-kernel@vger.kernel.org, miguel.ojeda.sandonis@gmail.com
Subject: Re: [PATCH] spi: Add spi-bits-per-word binding.
Date: Mon, 13 Mar 2017 17:55:04 +0000	[thread overview]
Message-ID: <20170313175504.mpwjxqbhc4yxk434@sirena.org.uk> (raw)
In-Reply-To: <983e943b-30f2-7d80-294a-df29bca11738@cern.ch>

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

On Mon, Mar 13, 2017 at 06:25:53PM +0100, Adrian Fiergolski wrote:
> Hi Mark,

Please don't top post, reply in line with needed context.  This allows
readers to readily follow the flow of conversation and understand what
you are talking about and also helps ensure that everything in the
discussion is being addressed.

> In my case, xilinx_spi_probe function (of spi-xilinx controller) sets
> bits_per_word_mask of spi_master struct only to 16 bits support. Later,
> xilinx_spi_probe calls of_register_spi_devices, which calls
> of_register_spi_devices. The last one allocates an empty spi_device
> struct and configures different options of the spi_device according to a
> device tree. bits_per_word are not covered here (why?), thus it is left
> 0 (value after allocation), which, by convention, means 8 bits support.
> At the end, the same function (of_register_spi_device) calls
> spi_add_device which finally calls spi_setup. The last call, according
> to convention, changes bits_per_word to 8 and calls
> __spi_validate_bits_per_word which fails, as master doesn't support 8
> bit transmission. This fails registration sequence of a device driver.
> As you see, the device driver doesn't have possibility to modify
> bits_per_word during the registration process, thus it can't provide
> support for such limited controllers.

I can't see any way in which it follows from the above that it's a good
idea to try to override bits per word settings in the device tree, that
just wastes user time and is an abstraction failure.  We need better
handling of defaults done purely in the kernel.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

  reply	other threads:[~2017-03-13 17:55 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20170217101151.hyzmz5a4lgdy7p5m>
2017-02-20 15:35 ` [PATCH] spi: Add spi-bits-per-word binding Adrian Fiergolski
2017-02-21 19:08   ` Mark Brown
2017-03-13 17:25     ` Adrian Fiergolski
2017-03-13 17:55       ` Mark Brown [this message]
2017-03-13 18:12         ` Adrian Fiergolski
2017-03-13 19:57           ` Geert Uytterhoeven
2017-03-13 20:26             ` Adrian Fiergolski
2017-03-17 21:21               ` 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=20170313175504.mpwjxqbhc4yxk434@sirena.org.uk \
    --to=broonie@kernel.org \
    --cc=Adrian.Fiergolski@cern.ch \
    --cc=devicetree@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-spi@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=miguel.ojeda.sandonis@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 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).