Philip Blundell (pb@nexus.co.uk)
Fri, 07 May 1999 12:46:37 +0100
>And that leads to the first problem: while it is
>easy to emulate eg. parport_write_control, it has
>to be called from a process context, it may not
>be called from an interrupt routine nor a BH.
Why is this? I think it's going to be awkward to ensure that no code assumes
the low-level functions are safe to call from interrupt context. For stuff
like PLIP and PPA it's pretty much obligatory.
>Roughly the same goes for interrupts. It supports interrupts,
>but doesn't have an associated "hardware" IRQ (it goes indirectly
>via the USB host controller interrupt), so how do I signal
>higher level drivers that this port has interrupts, but the
>procfs code should not even think of trying to change interrupt
>numbers?
The new procfs code (in the tmw tree) has all the interrupt-changing cruft
taken out anyway, so this is probably no big deal. Nothing outside the
low-level driver should actually care about the irq number except to compare
it with PARPORT_IRQ_NONE, so you can probably set it to whatever you like.
p.
-- To unsubscribe, send mail to: linux-parport-request@torque.net --
-- with the single word "unsubscribe" in the body of the message. --
This archive was generated by hypermail 2.0b3 on Fri 07 May 1999 - 07:53:12 EDT