[mcnet4l-devel] responder step 4

[Daniel S. <st...@in...>]

mark, 

i'm close to finishing 2.14 device drivers for both 
system host boards as well as 21554 based peripherals. 

regarding the host device, i think i've stumbled over 
a general problem with the connection setup scheme,
related to out-of-band control alert managements on the receiver side. 

i just did not notice this before, since all the in-band
alerts, e.g. 21554 doorbell interrupts, on peripherals usually do fine
without management descriptors provided by the remote side. 

consider a peripheral (21554) initiating a connection to a
node residing on the system host:

the initiator would deliver alert descriptors based on 21554 doorbell
interrupts. the responder on the system host would request bus
interrupts. here, the responder needs to rely completely on management
descriptors delivered by the initiator.

the weirdness starts in initiator step4/responder step4:
here, the responder gets an interrupt from a device it effectively has
not yet seen managements for -- the managements are provded within the
same step in which the interrupt occurs.
so a driver would have to 
- parse the managements
- apply the identification mechanism. see if it succeeds.
- apply the clear means.

all this - basically the whole "responder step4" procedure - will need
to take place directly within the interrupt handling routine. not
impossible, but pretty much work for an irq service, i think.

interrupts need to be assumed as shared with other devices (both
mcdevices as well as non-mc). so, this has to happen based on an
_assumption_ the interrupt stems from a respective connection.

if the remote side failed to deliver proper management mechanisms, the
whole responding system gets more or less trashed. no way to clear the
interrupt execept disabling the entire irq line.

i don't really feel comfortable with this scheme.
has the 2.14 committee been aware of this? maybe the spec should note
some of the implications regarding dependencies on alert managements?
  
confused again :),
dns


-- 
__________________________________________________________________
mailto: st...@in...