From: Federico Vaga <federico.vaga-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
To: Grant Likely <grant.likely-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.org>
Cc: spi-devel-general-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: [PATCH RFC] spidev.c: add sysfs attributes for SPI configuration
Date: Sat, 22 Dec 2012 12:21:15 +0100 [thread overview]
Message-ID: <4348691.tj7B63aR8x@number-5> (raw)
In-Reply-To: <20121222094725.797F03E03CE@localhost>
> 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.
spidev_test and spidev_fdx does not allow me to customize tx buffer and
I think (very personal opinion) that for debugging purpose is better
sysfs with well known programs (echo, cat, hexdump, od) and
oscilloscope.
I know that I'm not so persuasive :) I can develop a simple program
that can write custom tx buf with ioctl
--
Federico Vaga
------------------------------------------------------------------------------
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d
WARNING: multiple messages have this Message-ID (diff)
From: Federico Vaga <federico.vaga@gmail.com>
To: Grant Likely <grant.likely@secretlab.ca>
Cc: 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 12:21:15 +0100 [thread overview]
Message-ID: <4348691.tj7B63aR8x@number-5> (raw)
In-Reply-To: <20121222094725.797F03E03CE@localhost>
> 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.
spidev_test and spidev_fdx does not allow me to customize tx buffer and
I think (very personal opinion) that for debugging purpose is better
sysfs with well known programs (echo, cat, hexdump, od) and
oscilloscope.
I know that I'm not so persuasive :) I can develop a simple program
that can write custom tx buf with ioctl
--
Federico Vaga
next prev parent reply other threads:[~2012-12-22 11:21 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 [this message]
2012-12-22 11:21 ` Federico Vaga
2012-12-22 18:29 ` Greg KH
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=4348691.tj7B63aR8x@number-5 \
--to=federico.vaga-re5jqeeqqe8avxtiumwx3w@public.gmane.org \
--cc=grant.likely-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.org \
--cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@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 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.