The power settings need to be updated after a binding flow is done
and before quota calculations. This was missing in the start_ap_ibss()
flow. Fix it.
Signed-off-by: Ilan Peer <ilan.peer@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
The state variable was not set to false in case of a failure to
complete the start_ap_ibss() flow.
Signed-off-by: Ilan Peer <ilan.peer@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
It's a huge mess currently, that is really hard to read. This cleanup
doesn't touch the logic at all, it only breaks easy-to-fix long lines and
updates comment styles.
CC: Jay Vosburgh <fubar@us.ibm.com>
CC: Andy Gospodarek <andy@greyhouse.net>
Signed-off-by: Veaceslav Falico <vfalico@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
transition to the common clock framework has completed and the PPC_CLOCK
is no longer available for the MPC512x platform, remove the now obsolete
code path of the mpc5xxx mscan driver which accessed clock control module
registers directly
Cc: Wolfgang Grandegger <wg@grandegger.com>
Cc: Marc Kleine-Budde <mkl@pengutronix.de>
Cc: linux-can@vger.kernel.org
Signed-off-by: Gerhard Sittig <gsi@denx.de>
Signed-off-by: Anatolij Gustschin <agust@denx.de>
implement a .get_clock() callback for the MPC512x platform which uses
the common clock infrastructure (eliminating direct access to the clock
control registers from within the CAN network driver), and provide the
corresponding .put_clock() callback to release resources after use
acquire both the clock items for register access ("ipg") as well as for
wire communication ("can")
keep the previous implementation of MPC512x support in place during
migration, this results in a readable diff of the change
this change is neutral to the MPC5200 platform
Cc: Wolfgang Grandegger <wg@grandegger.com>
Cc: Marc Kleine-Budde <mkl@pengutronix.de>
Cc: linux-can@vger.kernel.org
Signed-off-by: Gerhard Sittig <gsi@denx.de>
Signed-off-by: Anatolij Gustschin <agust@denx.de>
Jeff Kirsher says:
====================
Intel Wired LAN Driver Updates
This series contains updates to i40e and now i40evf.
Most notable is Jacob's patch to add PTP support to i40e.
Mitch cleans up additional memcpy's and use struct assignment instead.
Then fixes long lines to appease checkpatch.pl. Mitch then provides
a fix to keep us from spamming the log with confusing errors. If you
use ip to change the MAC address of a VF while the VF driver is loaded,
closing the VF interface or unloading the VF driver will cause the VF
driver to remove the MAC filter for its original (now invalid) MAC
address.
Jesse cleans up macros which are no longer needed or used.
I (Jeff) cleanup function header comments to ensure Doxygen/kdoc works
correctly to generate documentation without warnings.
Anjali fixes a bug where ethtool set-channels would return failure when
configuring only one Rx queue. Then fixes a bug where the driver was
erroneously exiting the driver unload path if one part of the unload
failed.
Shannon fixes if the IPV6EXADD but is set in the Rx descriptor status,
there was an optional extension header with an alternate IP address
detected and the hardware checksum was not handling the alternate IP
address correctly. Then adjusts the ITR max and min values to match
the hardware max value and recommended min value. Shannon makes sure
to clear the PXE mode after the adminq is initialized.
v2:
- fix patch 14 "i40e: enable PTP" to address Richard Cochran's spelling
catch and Ben Hutchings Kconfig, SIOCGHWTSTAMP and sizeof() suggestions
- added Paul Gortmaker's i40evf fix patch
v3:
- fix patch 14 "i40e: enable PTP" to address Ben Hutchings concerns about
a race with PTP init and cleanup and i40e_get_ts_info().
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
This patch fixes the following sparse warning, which occurs in casts when
accessing the data in the CAN frames (struct can_frame) in the RX and TX
routines:
drivers/net/can/ti_hecc.c:521:17: warning: cast to restricted __be32
drivers/net/can/ti_hecc.c:521:17: warning: cast to restricted __be32
drivers/net/can/ti_hecc.c:521:17: warning: cast to restricted __be32
drivers/net/can/ti_hecc.c:521:17: warning: cast to restricted __be32
drivers/net/can/ti_hecc.c:521:17: warning: cast to restricted __be32
drivers/net/can/ti_hecc.c:521:17: warning: cast to restricted __be32
drivers/net/can/ti_hecc.c:524:25: warning: cast to restricted __be32
drivers/net/can/ti_hecc.c:524:25: warning: cast to restricted __be32
drivers/net/can/ti_hecc.c:524:25: warning: cast to restricted __be32
drivers/net/can/ti_hecc.c:524:25: warning: cast to restricted __be32
drivers/net/can/ti_hecc.c:524:25: warning: cast to restricted __be32
drivers/net/can/ti_hecc.c:524:25: warning: cast to restricted __be32
drivers/net/can/ti_hecc.c:572:28: warning: incorrect type in assignment (different base types)
drivers/net/can/ti_hecc.c:572:28: expected unsigned int [unsigned] [usertype] <noident>
drivers/net/can/ti_hecc.c:572:28: got restricted __be32 [usertype] <noident>
drivers/net/can/ti_hecc.c:575:40: warning: incorrect type in assignment (different base types)
drivers/net/can/ti_hecc.c:575:40: expected unsigned int [unsigned] [usertype] <noident>
drivers/net/can/ti_hecc.c:575:40: got restricted __be32 [usertype] <noident>
As the data is indeed big endian, use "__be32" instead of "u32", when casting
it.
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Building arm:allmodconfig fails with
flexcan.c: In function 'flexcan_read':
flexcan.c:243:2: error: implicit declaration of function 'in_be32'
flexcan.c: In function 'flexcan_write':
flexcan.c:248:2: error: implicit declaration of function 'out_be32'
in_be32 and out_be32 do not (or no longer) exist for ARM targets.
Disable the build for ARM on big endian CPUs.
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
As of commit 7f12ad741a ("i40evf: transmit
and receive functionality") the s390 builds (allyesconfig) fail with:
drivers/net/ethernet/intel/i40evf/i40e_txrx.c: In function 'i40e_clean_rx_irq':
drivers/net/ethernet/intel/i40evf/i40e_txrx.c:818:3: error: implicit declaration of function 'prefetch'
make[5]: *** [drivers/net/ethernet/intel/i40evf/i40e_txrx.o] Error 1
due to an implicit assumption that the prototype from linux/prefetch.h
will be present.
Cc: Mitch Williams <mitch.a.williams@intel.com>
Cc: Greg Rose <gregory.v.rose@intel.com>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Acked-by: Shannon Nelson <shannon.nelson@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
In the latest firmware the clear_pxe_mode function will use the
AdminQ request, so call this after AdminQ is set up rather than
relying on i40e_pf_reset() to clear the PXE mode.
Change-ID: Ice8cba2e9cbc3c7bde0a0bcf8eaf5009abef040b
Signed-off-by: Shannon Nelson <shannon.nelson@intel.com>
Signed-off-by: Jesse Brandeburg <jesse.brandeburg@intel.com>
Tested-by: Kavindya Deegala <kavindya.s.deegala@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Set the ITR max and min values to match the hardware max value
and the recommended min value. These values are shifted right
one bit because the register counts in 2 usec units, so leave
a comment to explain.
Change-ID: I289c27955cf6c566a6d21b95c3110b88cbb15dad
Signed-off-by: Shannon Nelson <shannon.nelson@intel.com>
Signed-off-by: Jesse Brandeburg <jesse.brandeburg@intel.com>
Tested-by: Kavindya Deegala <kavindya.s.deegala@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
If the IPV6EXADD bit is set in the Rx descriptor status, there
was an optional extension header with an alternate IP address
detected. The HW checksum offload doesn't handle the alternate
IP address correctly so likely comes up with the wrong answer.
Thus, if the bit is set we ignore the checksum offload value.
Change-ID: I70ff8d38cdcddccf44107691cae13d0c07c284c8
Signed-off-by: Shannon Nelson <shannon.nelson@intel.com>
Signed-off-by: Jesse Brandeburg <jesse.brandeburg@intel.com>
Tested-by: Kavindya Deegala <kavindya.s.deegala@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
If you use ip to change the MAC address of a VF while the VF
driver is loaded, closing the VF interface or unloading the VF
driver will cause the VF driver to remove the MAC filter for its
original (now invalid) MAC address. This would cause the PF
driver to kick an error message to the log, and back to the VF
driver.
Since the VF driver has not really done anything naughty, let's
not punish it. Don't check for MAC address overrides on the
delete operation, just make sure it's a valid address. This keeps
us from spamming the log with confusing errors.
Change-ID: I1f051bd4014e50855457d928c9ee8b0766981b2f
Signed-off-by: Mitch Williams <mitch.a.williams@intel.com>
Signed-off-by: Jesse Brandeburg <jesse.brandeburg@intel.com>
Tested-by: Kavindya Deegala <kavindya.s.deegala@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Fix a bug where the driver was erroneously exiting the driver unload
path if one part of the unload failed. Instead of the original way
the driver should always continue when disabling and be sure to disable
all queues.
Change-ID: Ib8c81c596bc87c31d8e9ca97ebf871168475279d
Signed-off-by: Anjali Singhai Jain <anjali.singhai@intel.com>
Signed-off-by: Jesse Brandeburg <jesse.brandeburg@intel.com>
Tested-by: Kavindya Deegala <kavindya.s.deegala@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
The current driver will warn the user if the NVM version
is out of date, this raises the bar to a newer version.
Change-ID: I5ec21d8efa4e7c3fdacb56f85d310bb2229b1483
Signed-off-by: Anjali Singhai Jain <anjali.singhai@intel.com>
Signed-off-by: Jesse Brandeburg <jesse.brandeburg@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Restore the original regulatory testing functionality and also
make it more flexible by allowing the parameters to be specified
when creating a dynamic radio.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Add new commands to the hwsim generic netlink family to allow
creating and destroying radios on the fly. The number of channels
a radio supports can be specified when it's created, if it isn't
the module parameter will be used as default.
This should be extended in the future to allow other parameters
to be specified, e.g.
* list of channels
* interface combinations, particularly P2P_DEVICE support
* regtest
* and pretty much all other hardware capabilities
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Reject wmediumd registrations when any devices have multi-channel
capability, but register the generic netlink family unconditionally
to make it possible to add new commands that shouldn't depend on
the number of (default) channels.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
There can't be two wmediumd instances controlling hwsim,
so reject registration from a second one and verify in
the commands that it's the correct instance calling.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
This will make the next patch, adding support for netlink,
smaller and more readable. The code is not modified here.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
To later allow dynamic registration, assign the index for the
struct device and MAC address from a new free-running counter.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Check the flag that the module parameter sets instead, so
later radios can use different parameters.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Refactor the radio cleanup into a new function to later
allow deleting a single radio from the list.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
In order to support dynamic radio registration in the future,
refactor the actual registration into a new function with only
minor cleanups. Since it had to change anyway, also clean up
the init error paths.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
The regtest thing worked based on the radio loop, but with
more dynamic radio registration that loop won't really exist
as is. We can add it back later with proper dynamic code.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Prepare the code to support, in theory, different devices
with a different number of channels supported. Right now
this doesn't really change anything, but will allow for
dynamic device registration in the future.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
There's no need to print a message, and genl_unregister_family()
can't really fail so remove the error message there as well.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
o Consider number of Tx queues while calculating the length of
Tx statistics as part of ethtool stats.
o Calculate statistics lenght properly for 82xx and 83xx adapter
Signed-off-by: Shahed Shaikh <shahed.shaikh@qlogic.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
o Driver was not updating TX stats so it was not populating
statistics in `ifconfig` command output.
Signed-off-by: Manish Chopra <manish.chopra@qlogic.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Currently, the tx queue were selected implicitly in ndo_dfwd_start_xmit(). The
will cause several issues:
- NETIF_F_LLTX were removed for macvlan, so txq lock were done for macvlan
instead of lower device which misses the necessary txq synchronization for
lower device such as txq stopping or frozen required by dev watchdog or
control path.
- dev_hard_start_xmit() was called with NULL txq which bypasses the net device
watchdog.
- dev_hard_start_xmit() does not check txq everywhere which will lead a crash
when tso is disabled for lower device.
Fix this by explicitly introducing a new param for .ndo_select_queue() for just
selecting queues in the case of l2 forwarding offload. netdev_pick_tx() was also
extended to accept this parameter and dev_queue_xmit_accel() was used to do l2
forwarding transmission.
With this fixes, NETIF_F_LLTX could be preserved for macvlan and there's no need
to check txq against NULL in dev_hard_start_xmit(). Also there's no need to keep
a dedicated ndo_dfwd_start_xmit() and we can just reuse the code of
dev_queue_xmit() to do the transmission.
In the future, it was also required for macvtap l2 forwarding support since it
provides a necessary synchronization method.
Cc: John Fastabend <john.r.fastabend@intel.com>
Cc: Neil Horman <nhorman@tuxdriver.com>
Cc: e1000-devel@lists.sourceforge.net
Signed-off-by: Jason Wang <jasowang@redhat.com>
Acked-by: Neil Horman <nhorman@tuxdriver.com>
Acked-by: John Fastabend <john.r.fastabend@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
L2 fowarding offload will bypass the rx handler of real device. This will make
the packet could not be forwarded to macvtap device. Another problem is the
dev_hard_start_xmit() called for macvtap does not have any synchronization.
Fix this by forbidding L2 forwarding for macvtap.
Cc: John Fastabend <john.r.fastabend@intel.com>
Cc: Neil Horman <nhorman@tuxdriver.com>
Acked-by: Neil Horman <nhorman@tuxdriver.com>
Signed-off-by: Jason Wang <jasowang@redhat.com>
Acked-by: John Fastabend <john.r.fastabend@intel.com.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
