linux-kernel - Re: [PATCH RFC] spidev.c: add sysfs attributes for SPI configuration

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <4348691.tj7B63aR8x@number-5>
Date:	Sat, 22 Dec 2012 12:21:15 +0100
From:	Federico Vaga <federico.vaga@...il.com>
To:	Grant Likely <grant.likely@...retlab.ca>
Cc:	spi-devel-general@...ts.sourceforge.net,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH RFC] spidev.c: add sysfs attributes for SPI configuration

> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/