Spinlock vs mutexes for spi network driver

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



I have modified 'drivers/net/ethoc.c' for spi communication and it is
able to transmit/receive packets. However, I am confused about using
spinlocks vs mutexes for locking access to the spi device.

e.g. For the transmit function I use a work_queue to schedule the
transmits. In the handler function, I use a mutex to lock the device.
Could I be using a spinlock here instead? Should I use a spinlock to
disable the irq while I'm in the middle of transmitting data?

The ethoc device sends out an interrupt everytime a packet is
successfully transmitted and received. So it has to be acked otherwise
the interrupt line stays high and no transmit or receive can happen
(which why I'm not use if I should use the spin_lock_irq variant in this
case).

Some other spi net drivers such as ks8851.c have mutexes around all spi
device accesses, which I guess is to prevent simultaneous uses of the
device. Is this a good idea? Doesn't the spi_transfer calls schedule
device accesses already?

Thanks for any comment on this.

Amit

_______________________________________________
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxx
http://driverdev.linuxdriverproject.org/mailman/listinfo/devel

[Index of Archives]     [Linux Driver Backports]     [DMA Engine]     [Linux GPIO]     [Linux SPI]     [Video for Linux]     [Linux USB Devel]     [Linux Coverity]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Yosemite Backpacking]
  Powered by Linux