From: Greg KH <gregkh@linuxfoundation.org>
To: Federico Vaga <federico.vaga@gmail.com>
Cc: Grant Likely <grant.likely@secretlab.ca>,
spi-devel-general@lists.sourceforge.net,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH RFC] spidev.c: add sysfs attributes for SPI configuration
Date: Sat, 22 Dec 2012 10:29:09 -0800 [thread overview]
Message-ID: <20121222182909.GA18767@kroah.com> (raw)
In-Reply-To: <4348691.tj7B63aR8x@number-5>
On Sat, Dec 22, 2012 at 12:21:15PM +0100, Federico Vaga wrote:
> > I'm cautious about adding operational interfaces to sysfs because it
> > can be quite difficult to get the locking right. To begin with it
> > splits up a single interface into multiple files, any of which can
> > be held open by a process. Then there is the question of ordering
> > of operations when there are multiple users. For instance, if there
> > were two users, each of which using different transfer parameters,
> > a sysfs interface doesn't provide any mechanism to group setting up
> > the device with the transfer.
> >
> > These are lessons learned the hard way with the gpio sysfs abi. I
> > don't want to get caught in the same trap for spi.
> >
> > g.
>
> I understand the problem, but I think that for very simple test on
> devices, sysfs is easier. For example, it happens that a SPI device
> does not work correctly with a driver, so I want to verify the SPI
> traffic by writing directly the device commands and check with an
> oscilloscope. I think that an easy way is to use sysfs like this:
>
> echo 123456 > speed_hz
> [other options if needed]
> echo -n -e "\x12\x34" > /dev/spidev1.1
> [oscilloscope]
> hexdump -n 2 /dev/spidev1.1
>
> This sysfs interface should be used only for testing/debugging, not to
> develop an user space driver on it; moreover, the ioctl interface is
> still there.
Then move it to debugfs, don't put debugging code in sysfs, as once you
do, you are stuck with it for life (hint, you forgot to add
Documentation/ABI entries for your new sysfs files, which are required).
If you move this to debugfs, you can do whatever you want, as it's
obvious no one would ever put "real" interfaces in debugfs :)
thanks,
greg k-h
prev parent reply other threads:[~2012-12-22 18:29 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-11-24 17:20 [PATCH RFC] spidev.c: add sysfs attributes for SPI configuration Federico Vaga
2012-11-24 17:20 ` Federico Vaga
2012-12-19 15:09 ` Grant Likely
2012-12-20 15:30 ` Federico Vaga
2012-12-20 15:30 ` Federico Vaga
2012-12-22 9:47 ` Grant Likely
2012-12-22 11:21 ` Federico Vaga
2012-12-22 11:21 ` Federico Vaga
2012-12-22 18:29 ` Greg KH [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=20121222182909.GA18767@kroah.com \
--to=gregkh@linuxfoundation.org \
--cc=federico.vaga@gmail.com \
--cc=grant.likely@secretlab.ca \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.