linux-spi.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Martin Sperl <martin-d5rIkyn9cnPYtjvyW6yDsg@public.gmane.org>
To: spi-devel-general-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
Cc: broonie-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E@public.gmane.org
Subject: Adding/changing SPI device registrations on the fly via the load of a module
Date: Mon, 07 Oct 2013 13:47:30 +0200	[thread overview]
Message-ID: <52529F52.8030703@sperl.org> (raw)

Hi!

A lot of people have been trying to get their preferred SPI devices 
working on a Raspberry Pi (and probably some other development boards as 
well).
Most (newbies) of them have failed because it requires a recompile of 
the kernel to change the default config from SPIDEV to any other device 
of your choice - at least for non-device tree devices.

This is quite "burdensome" for people new to Linux, who just want to 
access their device - most of the time just changing modinfo, 
max_speed_hz and maybe assigning an irq-line for the driver.

As far as my experience goes, the ability to change the SPI device 
registration on the fly on development board (beagle-board, openwrt 
routers,...) would be of great advantage to the users.

Device tree would provide the "config" part, but would not allow to 
change settings on the fly. Also Device-tree requires a lot of 
"knowledge" (especially to newbies, that just want to add an ADC, or 
access a CAN bus board they just bought) to get it right and then a 
reboot hoping for the device-tree to work...

So here a proposal for a "simple" module that does only register SPI 
devices based on arguments passed to it when loading the module (and 
releasing the devices when removing the module).

You can find it in the form of an out of tree module at: 
https://github.com/msperl/spi-config

I agree, that this module provides some means to shoot yourself into the 
foot resulting in a crashed kernel.
But at least after a reboot we are back to "normal" again without any 
additional recovery procedures to boot the kernel.
So it is not an optimal solution, but at least it fills the niche for 
quick modifications to a system when the parts in question are not 
needed to get the system up and running in the first place.

The other benefit is that it also reduces support overhead for people 
who create and sell extension modules/capes/..., who then have to 
provide a separately patched kernel to make the extension work. With the 
above approach they just need to provide the command "modprobe 
spi-config device=..." and then load the relevant SPI driver module to 
get the people started with the default kernel that comes with the 
OS/board (assuming the OS has the module compiled).

Please review this out-of-tree-module and give some feedback.
Maybe you find it valuable enough to get it included with the kernel itself?

Thanks,
             Martin

P.s: the module has an option to replace an existing SPI 
board-registration that comes with the default kernel. But - for now -  
such an action will taint the kernel, as this action might produce 
unexpected results... (besides memory that does not get freed)


------------------------------------------------------------------------------
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from 
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60134791&iu=/4140/ostg.clktrk

                 reply	other threads:[~2013-10-07 11:47 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

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=52529F52.8030703@sperl.org \
    --to=martin-d5rikyn9cnpytjvyw6ydsg@public.gmane.org \
    --cc=broonie-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E@public.gmane.org \
    --cc=spi-devel-general-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.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).