MaxSpeed is documented as setting the max speed only; it seems like it's defensible, if a bit silly, for the kernel to choose 312kHz when you request 10MHz. It looks like Go is just passing the requested speed on to the kernel.

@quentinmit Please reread my comment. When using my own code, the kernel correctly choose the closest clock speed, which is 6.25mhz.

Can you show the output of "strace" on both programs?

I think the devfs_READ and devfs_WRITE constants are reversed.

With existing values (https://github.com/golang/exp/blob/master/io/spi/devfs.go#L19):

>>> devfs_MAGIC = 107
>>>
>>> devfs_NRBITS   = 8
>>> devfs_TYPEBITS = 8
>>> devfs_SIZEBITS = 13
>>> devfs_DIRBITS  = 3
>>>
>>> devfs_NRSHIFT   = 0
>>> devfs_TYPESHIFT = devfs_NRSHIFT + devfs_NRBITS
>>> devfs_SIZESHIFT = devfs_TYPESHIFT + devfs_TYPEBITS
>>> devfs_DIRSHIFT  = devfs_SIZESHIFT + devfs_SIZEBITS
>>>
>>> devfs_READ  = 2
>>> devfs_WRITE = 4
>>> hex((devfs_WRITE << devfs_DIRSHIFT) | (devfs_MAGIC << devfs_TYPESHIFT) | (4 << devfs_NRSHIFT) | (4 << devfs_SIZESHIFT))
'0x80046b04'
>>> hex((devfs_READ << devfs_DIRSHIFT) | (devfs_MAGIC << devfs_TYPESHIFT) | (4 << devfs_NRSHIFT) | (4 << devfs_SIZESHIFT))
'0x40046b04'

From the C header files:

$ cat values.c
#include <stdlib.h>
#include <stdio.h>
#include <fcntl.h>
#include <linux/spi/spidev.h>
#include <linux/types.h>
#include <sys/ioctl.h>
#include <linux/ioctl.h>

int main(int argc, char *argv[]) {
    printf("SPI_IOC_WR_MAX_SPEED_HZ %08x\n", SPI_IOC_WR_MAX_SPEED_HZ);
    printf("SPI_IOC_RD_MAX_SPEED_HZ %08x\n", SPI_IOC_RD_MAX_SPEED_HZ);
    return 0;
}
$ cc values.c && ./a.out
SPI_IOC_WR_MAX_SPEED_HZ 40046b04
SPI_IOC_RD_MAX_SPEED_HZ 80046b04

I think the devfs_READ and devfs_WRITE constants are reversed.

These constants looks suspicious but all other writes (in the scope of my use cases) are succeeding.

strace output would be useful between the two.

I just want to confirm that we have had to swap devfs_READ and devfs_WRITE to get the code to work. This should really just be fixed.

I would like to confirm the same findings. The platform that I am developing on is an RPi Zero v1.3. The Linux kernel is 4.9.59+, and the SPI kernel module is spi_bcm2835.

I suspected also that READ and WRITE were reversed and came across this thread after a few days of debugging. I inserted some fmt.Println statements in devfs.go and found that the referenced value was being "rejected."

Both setting the speed and setting the SPI mode bits were broken, and investigation with a high speed logic analyzer was showing a clock around 100 MHz and no change in phase when I set up the peripheral with different parameters.

The following is a snippet of what I used to debug in devfs.go. "m before:" for instance would be 2, and "m after:" would be 0.

        case driver.Mode:
        //      m := uint8(v)
                m := v
                // I discovered later in the evening with a logic analyzer that the mode bit is "ignored" in this implementation
                // just as the speed is.
                fmt.Println("m before:", m)
                if err := c.ioctl(requestCode(devfs_WRITE, devfs_MAGIC, 1, 1), uintptr(unsafe.Pointer(&m))); err != nil {
                        return fmt.Errorf("error setting mode to %v: %v", m, err)
                }
                fmt.Println("m after:", m)
                c.mode = uint8(m)

I recommend https://periph.io/x/periph/conn/spi/spireg, which will be supported going forward.

I'll keep this bug open for documentation purposes but I'm unsubscribing for notifications so @ me directly if you want me to see the message.

I don't plan to make any change here.