linux.git/drivers/net/ethernet/emulex, branch v3.13 Linux kernel source tree be2net: add dma_mapping_error() check for dma_map_page() 2014-01-16T00:50:32+00:00 Ivan Vecera ivecera@redhat.com 2014-01-15T10:11:34+00:00 ba42fad0964a41f0830e80c1b6be49c1e6bfcc01 The driver does not check value returned by dma_map_page. The patch fixes this. v2: Removed the bugfix for non-bug ;-) (thanks Sathya) Signed-off-by: Ivan Vecera <ivecera@redhat.com> Acked-by: Sathya Perla <Sathya.perla@emulex.com> Signed-off-by: David S. Miller <davem@davemloft.net> 
The driver does not check value returned by dma_map_page. The patch
fixes this.

v2: Removed the bugfix for non-bug ;-) (thanks Sathya)

Signed-off-by: Ivan Vecera <ivecera@redhat.com>
Acked-by: Sathya Perla <Sathya.perla@emulex.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
be2net: fix max_evt_qs calculation for BE3 in SR-IOV config 2014-01-06T18:09:21+00:00 Suresh Reddy suresh.reddy@emulex.com 2014-01-06T07:32:25+00:00 e3dc867c1758fc4ae6fc6b63ea6bbcd454479f08 The driver wrongly assumes 16 EQs/vectors are available for each BE3 PF. When SR-IOV is enabled, a BE3 PF can support only a max of 8 EQs. Signed-off-by: Suresh Reddy <suresh.reddy@emulex.com> Signed-off-by: Sathya Perla <sathya.perla@emulex.com> Signed-off-by: David S. Miller <davem@davemloft.net> 
The driver wrongly assumes 16 EQs/vectors are available for each BE3 PF.
When SR-IOV is enabled, a BE3 PF can support only a max of 8 EQs.

Signed-off-by: Suresh Reddy <suresh.reddy@emulex.com>
Signed-off-by: Sathya Perla <sathya.perla@emulex.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
be2net: increase the timeout value for loopback-test FW cmd 2014-01-06T18:09:21+00:00 Suresh Reddy suresh.reddy@emulex.com 2014-01-06T07:32:24+00:00 5eeff6354faffb3f140d690eec1cede78de53b06 The loopback test FW cmd may need upto 15 seconds to complete on certain PHYs. This patch also fixes the name of the completion variable used to synchronize FW cmd completions as it not used by the flashing cmd alone anymore. Signed-off-by: Suresh Reddy <suresh.reddy@emulex.com> Signed-off-by: Sathya Perla <sathya.perla@emulex.com> Signed-off-by: David S. Miller <davem@davemloft.net> 
The loopback test FW cmd may need upto 15 seconds to complete on
certain PHYs. This patch also fixes the name of the completion variable
used to synchronize FW cmd completions as it not used by the flashing
cmd alone anymore.

Signed-off-by: Suresh Reddy <suresh.reddy@emulex.com>
Signed-off-by: Sathya Perla <sathya.perla@emulex.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
be2net: disable RSS when number of RXQs is reduced to 1 via set-channels 2014-01-06T18:09:21+00:00 Vasundhara Volam vasundhara.volam@emulex.com 2014-01-06T07:32:23+00:00 da1388d655292a11b5e9c011532e9ca83f77e1d3 When *only* the default RXQ is used, the RSS policy must be disabled so that all IP and no-IP traffic is placed into the default RXQ. If not, IP traffic is dropped. Also, issue the RSS_CONFIG cmd only if FW advertises RSS capability for the interface. Signed-off-by: Vasundhara Volam <vasundhara.volam@emulex.com> Signed-off-by: Sathya Perla <sathya.perla@emulex.com> Signed-off-by: David S. Miller <davem@davemloft.net> 
When *only* the default RXQ is used, the RSS policy must be disabled so
that all IP and no-IP traffic is placed into the default RXQ. If not,
IP traffic is dropped.

Also, issue the RSS_CONFIG cmd only if FW advertises RSS capability for
the interface.
Signed-off-by: Vasundhara Volam <vasundhara.volam@emulex.com>
Signed-off-by: Sathya Perla <sathya.perla@emulex.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
be2net: Free/delete pmacs (in be_clear()) only if they exist 2013-12-06T20:03:40+00:00 Somnath Kotur somnath.kotur@emulex.com 2013-12-05T06:38:16+00:00 b05004adf9d34e7fb8e96fe6a7cdeb0843f5ab35 During suspend-resume and lancer error recovery we will cleanup and re-initialize the resources through be_clear() and be_setup() respectively. During re-initialisation in be_setup(), if be_get_config() fails, we'll again call be_clear() which will cause a NULL pointer dereference as adapter->pmac_id is already freed. Signed-off-by: Kalesh AP <kalesh.purayil@emulex.com> Signed-off-by: Somnath Kotur <somnath.kotur@emulex.com> Signed-off-by: David S. Miller <davem@davemloft.net> 
During suspend-resume and lancer error recovery we will cleanup and
re-initialize the resources through be_clear() and be_setup() respectively.
During re-initialisation in be_setup(), if be_get_config() fails, we'll again
call be_clear() which will cause a NULL pointer dereference as adapter->pmac_id is
already freed.

Signed-off-by: Kalesh AP <kalesh.purayil@emulex.com>
Signed-off-by: Somnath Kotur <somnath.kotur@emulex.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
be2net: Fix Lancer error recovery to distinguish FW download 2013-12-06T20:03:40+00:00 Somnath Kotur somnath.kotur@emulex.com 2013-12-05T06:37:55+00:00 4bebb56a6d50ca50a34048194877dca34f572f8f The Firmware update would be detected by looking at the sliport_error1/ sliport_error2 register values(0x02/0x00). If its not a FW reset the current messaging would take place. If the error is due to FW reset, log a message to user that "Firmware update in progress" and also do not log sliport_status and sliport_error register values. Signed-off-by: Kalesh AP <kalesh.purayil@emulex.com> Signed-off-by: Somnath Kotur <somnath.kotur@emulex.com> Signed-off-by: David S. Miller <davem@davemloft.net> 
The Firmware update would be detected by looking at the sliport_error1/
sliport_error2 register values(0x02/0x00). If its not a FW reset the current
messaging would take place. If the error is due to FW reset, log a message to
user that "Firmware update in progress" and also do not log sliport_status and
sliport_error register values.

Signed-off-by: Kalesh AP <kalesh.purayil@emulex.com>
Signed-off-by: Somnath Kotur <somnath.kotur@emulex.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
be2net: call napi_disable() for all event queues 2013-11-28T23:54:02+00:00 Ivan Vecera ivecera@redhat.com 2013-11-27T07:59:32+00:00 dff345c5c85df3c5853491b007f6b1b578dc28a4 The recent be2net commit 6384a4d (adds a support for busy polling) introduces a regression that results in kernel crash. It incorrectly modified be_close() so napi_disable() is called only for the first queue. This breaks a correct pairing of napi_enable/_disable for the rest of event queues and causes a crash in subsequent be_open() call. v2: Applied suggestions from Sathya Fixes: 6384a4d ("be2net: add support for ndo_busy_poll") Cc: Sathya Perla <sathya.perla@emulex.com> Cc: Subbu Seetharaman <subbu.seetharaman@emulex.com> Cc: Ajit Khaparde <ajit.khaparde@emulex.com> Signed-off-by: Ivan Vecera <ivecera@redhat.com> Acked-by: Sathya Perla <sathya.perla@emulex.com> Signed-off-by: David S. Miller <davem@davemloft.net> 
The recent be2net commit 6384a4d (adds a support for busy polling)
introduces a regression that results in kernel crash. It incorrectly
modified be_close() so napi_disable() is called only for the first queue.
This breaks a correct pairing of napi_enable/_disable for the rest
of event queues and causes a crash in subsequent be_open() call.

v2: Applied suggestions from Sathya

Fixes: 6384a4d ("be2net: add support for ndo_busy_poll")
Cc: Sathya Perla <sathya.perla@emulex.com>
Cc: Subbu Seetharaman <subbu.seetharaman@emulex.com>
Cc: Ajit Khaparde <ajit.khaparde@emulex.com>
Signed-off-by: Ivan Vecera <ivecera@redhat.com>
Acked-by: Sathya Perla <sathya.perla@emulex.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Revert "be2net: call napi_disable() for all event queues" 2013-11-28T23:53:36+00:00 David S. Miller davem@davemloft.net 2013-11-28T23:53:36+00:00 71237b6feb8361a00a1cb481a0c901fbee8f82a5 This reverts commit 55485e7b417b640870b14eceec4cfbcb2b3e7a92. I applied the wrong version of this patch, the right one is coming up next. Signed-off-by: David S. Miller <davem@davemloft.net> 
This reverts commit 55485e7b417b640870b14eceec4cfbcb2b3e7a92.

I applied the wrong version of this patch, the right one is coming up
next.

Signed-off-by: David S. Miller <davem@davemloft.net>
be2net: call napi_disable() for all event queues 2013-11-28T23:50:52+00:00 Ivan Vecera ivecera@redhat.com 2013-11-26T16:54:41+00:00 55485e7b417b640870b14eceec4cfbcb2b3e7a92 The recent be2net commit 6384a4d (adds a support for busy polling) introduces a regression that results in kernel crash. It incorrectly modified be_close() so napi_disable() is called only for the first queue. This breaks a correct pairing of napi_enable/_disable for the rest of event queues and causes a crash in subsequent be_open() call. Cc: Sathya Perla <sathya.perla@emulex.com> Cc: Subbu Seetharaman <subbu.seetharaman@emulex.com> Cc: Ajit Khaparde <ajit.khaparde@emulex.com> Signed-off-by: Ivan Vecera <ivecera@redhat.com> Acked-by: Ajit Khaparde <ajit.khaparde@emulex.com> Signed-off-by: David S. Miller <davem@davemloft.net> 
The recent be2net commit 6384a4d (adds a support for busy polling)
introduces a regression that results in kernel crash. It incorrectly
modified be_close() so napi_disable() is called only for the first queue.
This breaks a correct pairing of napi_enable/_disable for the rest
of event queues and causes a crash in subsequent be_open() call.

Cc: Sathya Perla <sathya.perla@emulex.com>
Cc: Subbu Seetharaman <subbu.seetharaman@emulex.com>
Cc: Ajit Khaparde <ajit.khaparde@emulex.com>
Signed-off-by: Ivan Vecera <ivecera@redhat.com>
Acked-by: Ajit Khaparde <ajit.khaparde@emulex.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
be2net: Avoid programming permenant MAC by BE3-R VFs 2013-11-23T23:11:07+00:00 Ajit Khaparde ajit.khaparde@emulex.com 2013-11-22T18:51:28+00:00 2c7a9dc1641664173211c4ebc5db510a08684c46 On BE3-R, the PF programs the initial MAC address for its VFs. Doing it again in VF probe, causes a FW error which although harmless generates an unnecessary error log message. Signed-off-by: Vasundhara Volam <vasundhara.volam@emulex.com> Signed-off-by: Sathya Perla <sathya.perla@emulex.com> Signed-off-by: Ajit Khaparde <ajit.khaparde@emulex.com> Signed-off-by: David S. Miller <davem@davemloft.net> 
On BE3-R, the PF programs the initial MAC address for its VFs. Doing it again
in VF probe, causes a FW error which although harmless generates
an unnecessary error log message.

Signed-off-by: Vasundhara Volam <vasundhara.volam@emulex.com>
Signed-off-by: Sathya Perla <sathya.perla@emulex.com>
Signed-off-by: Ajit Khaparde <ajit.khaparde@emulex.com>
Signed-off-by: David S. Miller <davem@davemloft.net>