Searched hist:af027a34 (Results 1 – 6 of 6) sorted by relevance
| /openbmc/linux/drivers/net/ethernet/brocade/bna/ |
| H A D | bfa_msgq.h | af027a34 Mon Aug 08 11:21:35 CDT 2011 Rasesh Mody <rmody@brocade.com> bna: MSGQ Implementation
Change details:
- Currently modules communicate with the FW using 32 byte command and
response register. This limits the size of the command and response
messages exchanged with the FW to 32 bytes. We need a mechanism to
exchange the comamnds and responses exchange with FW that exceeds 32 bytes.
- MSGQ implementation provides that facility. It removes the assumption that
command/response queue size is precisely calculated to accommodate all
concurrent FW commands/responses. The queue depth is made variable now, defined
by a macro. A waiting command list is implemented to hold all the commands
when there is no place in the command queue. Callback is implemented for
each command entry to invoke the module posting the command, when there is
space in the command queue and the command was finally posted to the queue.
Module/Object information is embedded in the response for tracking purpose.
Signed-off-by: Rasesh Mody <rmody@brocade.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
af027a34 Mon Aug 08 11:21:35 CDT 2011 Rasesh Mody <rmody@brocade.com> bna: MSGQ Implementation
Change details:
- Currently modules communicate with the FW using 32 byte command and
response register. This limits the size of the command and response
messages exchanged with the FW to 32 bytes. We need a mechanism to
exchange the comamnds and responses exchange with FW that exceeds 32 bytes.
- MSGQ implementation provides that facility. It removes the assumption that
command/response queue size is precisely calculated to accommodate all
concurrent FW commands/responses. The queue depth is made variable now, defined
by a macro. A waiting command list is implemented to hold all the commands
when there is no place in the command queue. Callback is implemented for
each command entry to invoke the module posting the command, when there is
space in the command queue and the command was finally posted to the queue.
Module/Object information is embedded in the response for tracking purpose.
Signed-off-by: Rasesh Mody <rmody@brocade.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
| H A D | bfa_msgq.c | af027a34 Mon Aug 08 11:21:35 CDT 2011 Rasesh Mody <rmody@brocade.com> bna: MSGQ Implementation
Change details:
- Currently modules communicate with the FW using 32 byte command and
response register. This limits the size of the command and response
messages exchanged with the FW to 32 bytes. We need a mechanism to
exchange the comamnds and responses exchange with FW that exceeds 32 bytes.
- MSGQ implementation provides that facility. It removes the assumption that
command/response queue size is precisely calculated to accommodate all
concurrent FW commands/responses. The queue depth is made variable now, defined
by a macro. A waiting command list is implemented to hold all the commands
when there is no place in the command queue. Callback is implemented for
each command entry to invoke the module posting the command, when there is
space in the command queue and the command was finally posted to the queue.
Module/Object information is embedded in the response for tracking purpose.
Signed-off-by: Rasesh Mody <rmody@brocade.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
af027a34 Mon Aug 08 11:21:35 CDT 2011 Rasesh Mody <rmody@brocade.com> bna: MSGQ Implementation
Change details:
- Currently modules communicate with the FW using 32 byte command and
response register. This limits the size of the command and response
messages exchanged with the FW to 32 bytes. We need a mechanism to
exchange the comamnds and responses exchange with FW that exceeds 32 bytes.
- MSGQ implementation provides that facility. It removes the assumption that
command/response queue size is precisely calculated to accommodate all
concurrent FW commands/responses. The queue depth is made variable now, defined
by a macro. A waiting command list is implemented to hold all the commands
when there is no place in the command queue. Callback is implemented for
each command entry to invoke the module posting the command, when there is
space in the command queue and the command was finally posted to the queue.
Module/Object information is embedded in the response for tracking purpose.
Signed-off-by: Rasesh Mody <rmody@brocade.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
| H A D | Makefile | af027a34 Mon Aug 08 11:21:35 CDT 2011 Rasesh Mody <rmody@brocade.com> bna: MSGQ Implementation
Change details:
- Currently modules communicate with the FW using 32 byte command and
response register. This limits the size of the command and response
messages exchanged with the FW to 32 bytes. We need a mechanism to
exchange the comamnds and responses exchange with FW that exceeds 32 bytes.
- MSGQ implementation provides that facility. It removes the assumption that
command/response queue size is precisely calculated to accommodate all
concurrent FW commands/responses. The queue depth is made variable now, defined
by a macro. A waiting command list is implemented to hold all the commands
when there is no place in the command queue. Callback is implemented for
each command entry to invoke the module posting the command, when there is
space in the command queue and the command was finally posted to the queue.
Module/Object information is embedded in the response for tracking purpose.
Signed-off-by: Rasesh Mody <rmody@brocade.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
af027a34 Mon Aug 08 11:21:35 CDT 2011 Rasesh Mody <rmody@brocade.com> bna: MSGQ Implementation
Change details:
- Currently modules communicate with the FW using 32 byte command and
response register. This limits the size of the command and response
messages exchanged with the FW to 32 bytes. We need a mechanism to
exchange the comamnds and responses exchange with FW that exceeds 32 bytes.
- MSGQ implementation provides that facility. It removes the assumption that
command/response queue size is precisely calculated to accommodate all
concurrent FW commands/responses. The queue depth is made variable now, defined
by a macro. A waiting command list is implemented to hold all the commands
when there is no place in the command queue. Callback is implemented for
each command entry to invoke the module posting the command, when there is
space in the command queue and the command was finally posted to the queue.
Module/Object information is embedded in the response for tracking purpose.
Signed-off-by: Rasesh Mody <rmody@brocade.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
| H A D | bfa_ioc.h | af027a34 Mon Aug 08 11:21:35 CDT 2011 Rasesh Mody <rmody@brocade.com> bna: MSGQ Implementation
Change details:
- Currently modules communicate with the FW using 32 byte command and
response register. This limits the size of the command and response
messages exchanged with the FW to 32 bytes. We need a mechanism to
exchange the comamnds and responses exchange with FW that exceeds 32 bytes.
- MSGQ implementation provides that facility. It removes the assumption that
command/response queue size is precisely calculated to accommodate all
concurrent FW commands/responses. The queue depth is made variable now, defined
by a macro. A waiting command list is implemented to hold all the commands
when there is no place in the command queue. Callback is implemented for
each command entry to invoke the module posting the command, when there is
space in the command queue and the command was finally posted to the queue.
Module/Object information is embedded in the response for tracking purpose.
Signed-off-by: Rasesh Mody <rmody@brocade.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
af027a34 Mon Aug 08 11:21:35 CDT 2011 Rasesh Mody <rmody@brocade.com> bna: MSGQ Implementation
Change details:
- Currently modules communicate with the FW using 32 byte command and
response register. This limits the size of the command and response
messages exchanged with the FW to 32 bytes. We need a mechanism to
exchange the comamnds and responses exchange with FW that exceeds 32 bytes.
- MSGQ implementation provides that facility. It removes the assumption that
command/response queue size is precisely calculated to accommodate all
concurrent FW commands/responses. The queue depth is made variable now, defined
by a macro. A waiting command list is implemented to hold all the commands
when there is no place in the command queue. Callback is implemented for
each command entry to invoke the module posting the command, when there is
space in the command queue and the command was finally posted to the queue.
Module/Object information is embedded in the response for tracking purpose.
Signed-off-by: Rasesh Mody <rmody@brocade.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
| H A D | bfi.h | af027a34 Mon Aug 08 11:21:35 CDT 2011 Rasesh Mody <rmody@brocade.com> bna: MSGQ Implementation
Change details:
- Currently modules communicate with the FW using 32 byte command and
response register. This limits the size of the command and response
messages exchanged with the FW to 32 bytes. We need a mechanism to
exchange the comamnds and responses exchange with FW that exceeds 32 bytes.
- MSGQ implementation provides that facility. It removes the assumption that
command/response queue size is precisely calculated to accommodate all
concurrent FW commands/responses. The queue depth is made variable now, defined
by a macro. A waiting command list is implemented to hold all the commands
when there is no place in the command queue. Callback is implemented for
each command entry to invoke the module posting the command, when there is
space in the command queue and the command was finally posted to the queue.
Module/Object information is embedded in the response for tracking purpose.
Signed-off-by: Rasesh Mody <rmody@brocade.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
af027a34 Mon Aug 08 11:21:35 CDT 2011 Rasesh Mody <rmody@brocade.com> bna: MSGQ Implementation
Change details:
- Currently modules communicate with the FW using 32 byte command and
response register. This limits the size of the command and response
messages exchanged with the FW to 32 bytes. We need a mechanism to
exchange the comamnds and responses exchange with FW that exceeds 32 bytes.
- MSGQ implementation provides that facility. It removes the assumption that
command/response queue size is precisely calculated to accommodate all
concurrent FW commands/responses. The queue depth is made variable now, defined
by a macro. A waiting command list is implemented to hold all the commands
when there is no place in the command queue. Callback is implemented for
each command entry to invoke the module posting the command, when there is
space in the command queue and the command was finally posted to the queue.
Module/Object information is embedded in the response for tracking purpose.
Signed-off-by: Rasesh Mody <rmody@brocade.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
| H A D | bfa_ioc.c | af027a34 Mon Aug 08 11:21:35 CDT 2011 Rasesh Mody <rmody@brocade.com> bna: MSGQ Implementation
Change details:
- Currently modules communicate with the FW using 32 byte command and
response register. This limits the size of the command and response
messages exchanged with the FW to 32 bytes. We need a mechanism to
exchange the comamnds and responses exchange with FW that exceeds 32 bytes.
- MSGQ implementation provides that facility. It removes the assumption that
command/response queue size is precisely calculated to accommodate all
concurrent FW commands/responses. The queue depth is made variable now, defined
by a macro. A waiting command list is implemented to hold all the commands
when there is no place in the command queue. Callback is implemented for
each command entry to invoke the module posting the command, when there is
space in the command queue and the command was finally posted to the queue.
Module/Object information is embedded in the response for tracking purpose.
Signed-off-by: Rasesh Mody <rmody@brocade.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
af027a34 Mon Aug 08 11:21:35 CDT 2011 Rasesh Mody <rmody@brocade.com> bna: MSGQ Implementation
Change details:
- Currently modules communicate with the FW using 32 byte command and
response register. This limits the size of the command and response
messages exchanged with the FW to 32 bytes. We need a mechanism to
exchange the comamnds and responses exchange with FW that exceeds 32 bytes.
- MSGQ implementation provides that facility. It removes the assumption that
command/response queue size is precisely calculated to accommodate all
concurrent FW commands/responses. The queue depth is made variable now, defined
by a macro. A waiting command list is implemented to hold all the commands
when there is no place in the command queue. Callback is implemented for
each command entry to invoke the module posting the command, when there is
space in the command queue and the command was finally posted to the queue.
Module/Object information is embedded in the response for tracking purpose.
Signed-off-by: Rasesh Mody <rmody@brocade.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|