linux-kernel - Kernel driver with multiple SPI sources

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-next>] [day] [month] [year] [list]

Date:	Fri, 16 Oct 2009 21:50:43 +1300
From:	Bertrand Roussel <bertrand.roussel@...-net.org>
To:	linux-kernel@...r.kernel.org
Subject: Kernel driver with multiple SPI sources

Hello,

I am currently writing a kernel driver for an IMU, this is a basic
driver that is taking infos from
two SPI devices (an adc and a magnetic sensor), that are running on
the same bus, but different with different CS.

I'm having troubles to determine if the architecture I am currently
thinking about is a good way to do things.
In order to write portable code I was thinking in using general kernel
APIs, and came out with something like this:
 _____      ______
|     | <> |  ADC |
|     |    |______|
| IMU |     ______  <> Bus SPI
|     | <> |  MAG |
|_____|    |______|

Each block correspond to a driver:
* IMU is a basic char driver, depending on both ADC and MAG driver,
and that register new spi_device to the spi_master
* ADC and MAG are instances of an spi_driver, with a char driver as an interface

The IMU must take samples from the devices at a fixed rate.
A problem is that to retrieve infos from the MAG for example, a
command must be send first, then there is a delay from
1 to 4ms before the result are available, which is known when a PIN gets high.

Since I'm a beginner in kernel writing, I really don't know if the
approach I took is a good way to do things or not.
If that's not the case, can anyone give me some hints about how I
should consider doing things ?

However, in the case as my approach is right, I am really worried
about the delay part, since I don't want the kernel
to block for 5ms doing nothing a hundred times per second just because
it is reading from the SPI, I was considering
asynchronous IO implementation on the ADC/MAG side.
A timer would generate the sample rate in the IMU driver, tell the
ADC, which would send the command, then return.
On the gpio interrupt, the driver would read the ADC, and return the
result to the IMU. Which would then tell the MAG,
which would send the command, then return. Then gpio interrupt, the
driver read from the MAG, and return the result to
the IMU again, which would then store both results in a buffer, until
an application in user space decide to read it.

I am having trouble writing the Imu <=> Adc and Imu <=> Mag
communication part, did I got it wrong ?

Best regards,
Bertrand
--
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/