[Prism54-devel] suggestion to shorten interrupt code path

[Rainer Weikusat]

Jean-Baptiste Note <jean-baptiste.note at wanadoo.fr> writes:
>> [*] for instance, I happen to know one cause of 'mgmt timeouts'
>>     (device bug, sometimes asserts update but doesn't send data
>>      => little endian frame length converted to little endian
>>      a 2nd time => kmalloc failure in mgt_receive)
>
> The XH8196 driver ( a buggy linux softmac driver from intersil that
> someone got from a vendor of PCI cards ) has the following snippet of
> code before accessing the control block (which is allocated as
> _consistent_ ) :
>
>             /* flush the Control Block in the d-cache */
>             pci_map_single( ((struct pci_hif_local_data*)lp->hif_local_data)->pci_device,
>                             ((struct pci_hif_local_data*)lp->hif_local_data)->driver_mem_address,
>                             sizeof(struct control_block), PCI_DMA_FROMDEVICE );
>
>                     /* visit the queues */
>
> 	    /* unmap the Control Block memory */
> 	    pci_unmap_single( hif_lp->pci_device, hif_lp->device_host_address, 
> 	    	sizeof(struct control_block), PCI_DMA_FROMDEVICE );
>
>>From what i understood, this should not be necessary for consistent
> mappings.

According to the actual kernel code (2.4, I've looked this up for
i386, ppc and arm), it is not necessary. Additionally, the usage is
wrong: pci_map_single has a return value and this return value should
be passed to the corresponding unmap-call (NB: It is entirely possible
that this seemingly pointless operation is a workaround for something
else that happens to be broken/ unimplemented in some specific
Linux-variant).  

> But i think they knew what they were doing,

This an assumption I would not generally want to make when dealing
with Conexant-code[*] :->.

	[*] home of the 'telnet'-server that sends \n\r as line
	terminator. 

> and they do it all the same. Do you know / can you see if it would
> be a workaround for the problem? 

Certainly not for the problem I have described above. That happens to
be just a bad interaction between buggy firmware and not very sensible
code (it is an 'interesting' idea to drop already received managment
data silently because it cannot be copied into a buffer whose sole
purpose is to copy the data for no purpose).

Workaround: Initialize the frame header to some pattern that will
(hopefully ;-) not be used by the device and survives the endian
conversion intact (like 'all 0xff' for instance), so the situation can
be detected by the driver code. Depending on the oid in question,
the request can either simply be retransmitted if it is omnipotent and
otherwise, something more complicated procedure to restore a known
state needs to be implemented. And there is the additional special
case that (of course) the device not only kills managment responses,
but also trap frames.