On Fri, 2006-06-02 at 23:23 +0100, Esben Nielsen wrote:Just for the sake of generality. Nothing else. It would be very unlikely, as you say, that it wouldn't return 0.Makes it possible for the e100 ethernet driver to have it's interrupt handler
in both hard-irq and threaded context under PREEMPT_RT.
Index: linux-2.6.16-rt23.spin_mutex/drivers/net/e100.c
===================================================================
--- linux-2.6.16-rt23.spin_mutex.orig/drivers/net/e100.c
+++ linux-2.6.16-rt23.spin_mutex/drivers/net/e100.c
@@ -530,7 +530,7 @@ struct nic {
enum ru_state ru_running;
spinlock_t cb_lock ____cacheline_aligned;
- spinlock_t cmd_lock;
+ spin_mutex_t cmd_lock;
struct csr __iomem *csr;
enum scb_cmd_lo cuc_cmd;
unsigned int cbs_avail;
@@ -1950,6 +1950,30 @@ static int e100_rx_alloc_list(struct nic
return 0;
}
+static int e100_change_context(int irq, void *dev_id,
+ enum change_context_cmd cmd)
+{
+ struct net_device *netdev = dev_id;
+ struct nic *nic = netdev_priv(netdev);
+
+ switch(cmd)
+ {
+ case IRQ_TO_HARDIRQ:
+ if(!spin_mutexes_can_spin())
+ return -ENOSYS;
+
+ spin_mutex_to_spin(&nic->cmd_lock);
+ break;
+ case IRQ_CAN_THREAD:
+ /* Ok - return 0 */
+ break;
Why even bother with the IRQ_CAN_THREAD. If this would be anything
other than OK, then we shouldn't be using that request_irq2 (yuck!) call
in the first place.
-- Steve