- 18 Feb, 2014 14 commits
-
-
Alexander Gordeev authored
As result of deprecation of MSI-X/MSI enablement functions pci_enable_msix() and pci_enable_msi_block() all drivers using these two interfaces need to be updated to use the new pci_enable_msi_range() and pci_enable_msix_range() interfaces. Signed-off-by: Alexander Gordeev <agordeev@redhat.com> Cc: Dimitris Michailidis <dm@chelsio.com> Cc: netdev@vger.kernel.org Cc: linux-pci@vger.kernel.org Signed-off-by: David S. Miller <davem@davemloft.net>
-
Alexander Gordeev authored
As result of deprecation of MSI-X/MSI enablement functions pci_enable_msix() and pci_enable_msi_block() all drivers using these two interfaces need to be updated to use the new pci_enable_msi_range() and pci_enable_msix_range() interfaces. Signed-off-by: Alexander Gordeev <agordeev@redhat.com> Cc: Santosh Raspatur <santosh@chelsio.com> Cc: netdev@vger.kernel.org Cc: linux-pci@vger.kernel.org Signed-off-by: David S. Miller <davem@davemloft.net>
-
Alexander Gordeev authored
There is no need to call pci_disable_msix() in case the previous call to pci_enable_msix() failed Signed-off-by: Alexander Gordeev <agordeev@redhat.com> Cc: Santosh Raspatur <santosh@chelsio.com> Cc: netdev@vger.kernel.org Cc: linux-pci@vger.kernel.org Signed-off-by: David S. Miller <davem@davemloft.net>
-
Alexander Gordeev authored
As result of deprecation of MSI-X/MSI enablement functions pci_enable_msix() and pci_enable_msi_block() all drivers using these two interfaces need to be updated to use the new pci_enable_msi_range() and pci_enable_msix_range() interfaces. Signed-off-by: Alexander Gordeev <agordeev@redhat.com> Cc: Rasesh Mody <rmody@brocade.com> Cc: netdev@vger.kernel.org Cc: linux-pci@vger.kernel.org Signed-off-by: David S. Miller <davem@davemloft.net>
-
Alexander Gordeev authored
As result of deprecation of MSI-X/MSI enablement functions pci_enable_msix() and pci_enable_msi_block() all drivers using these two interfaces need to be updated to use the new pci_enable_msi_range() and pci_enable_msix_range() interfaces. Signed-off-by: Alexander Gordeev <agordeev@redhat.com> Cc: Nithin Nayak Sujir <nsujir@broadcom.com> Cc: Michael Chan <mchan@broadcom.com> Cc: netdev@vger.kernel.org Cc: linux-pci@vger.kernel.org Signed-off-by: David S. Miller <davem@davemloft.net>
-
Alexander Gordeev authored
As result of deprecation of MSI-X/MSI enablement functions pci_enable_msix() and pci_enable_msi_block() all drivers using these two interfaces need to be updated to use the new pci_enable_msi_range() and pci_enable_msix_range() interfaces. Signed-off-by: Alexander Gordeev <agordeev@redhat.com> Cc: Ariel Elior <ariele@broadcom.com> Cc: netdev@vger.kernel.org Cc: linux-pci@vger.kernel.org Signed-off-by: David S. Miller <davem@davemloft.net>
-
Alexander Gordeev authored
As result of deprecation of MSI-X/MSI enablement functions pci_enable_msix() and pci_enable_msi_block() all drivers using these two interfaces need to be updated to use the new pci_enable_msi_range() and pci_enable_msix_range() interfaces. Signed-off-by: Alexander Gordeev <agordeev@redhat.com> Cc: Michael Chan <mchan@broadcom.com> Cc: netdev@vger.kernel.org Cc: linux-pci@vger.kernel.org Signed-off-by: David S. Miller <davem@davemloft.net>
-
David S. Miller authored
Claudiu Manoil says: ==================== gianfar: Device configuration fixes This patchset represents the first part of an effort to solve some old device configuration issues in gianfar, especially run-time reset and re-configuration problems. I'm referring to "on-the-fly" configuration of registers against HW specification, concurrency issues during device reset / re-configuration operations, and implementing HW advisories for these operations. There's also a good deal of code cleanup and refactoring, and some other (minor) fixes as well. v2: Remove sysfs stubs w/o replacing them with module params (patch 2). ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
-
Claudiu Manoil authored
gfar_clean_rx_ring() was designed to be called from napi (rx softirq) context to do the Rx processing. Calling it from a process context like this is a bug as it will clearly race with the napi Rx processing. There's also no point in initializing num_txbdfree since startup_gfar() already does that, when bringing the device up again (after reset). Changing num_txbdfree "on-the-fly" like this is also subject to race conditions. num_txbdfree is handled by the Tx processing path and the device reset procedure. Also, don't assume that num_rx_queues is always equal to num_tx_queues. Signed-off-by: Claudiu Manoil <claudiu.manoil@freescale.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Claudiu Manoil authored
gfar_halt() and gfar_start() are responsible for stopping and starting the DMA and the Rx/Tx hw rings. They implement the support for the "graceful Rx/Tx stop/start" hw procedure, and also disable/enable eTSEC's hw interrupts in the process. The GRS/GTS procedure requires however to have the RQUEUE/TQUEUE registers cleared first and to wait for a period of time for the current frame to pass through the interface (around ~10ms for a jumbo frame). Only then may the GTS and GRS bits from DMACTRL be set to shut down the DMA, and finally the Tx_EN and Rx_EN bits in MACCFG1 may be cleared to disable the Tx/Rx blocks. The same register programming order applies to start the Rx/Tx: enabling the RQUEUE/TQUEUE *before* clearing the GRS/GTS bits. This is a HW recommendation in order to avoid a possible controller "lock up" during graceful reset. Cleanup the gfar_halt()/start() prototypes, to take priv instead of ndev as their purpose is to operate on HW. Enabling the RQUEUE/TQUEUE in the hw_init() is not needed anymore since that's the job of gfar_start(). Signed-off-by: Claudiu Manoil <claudiu.manoil@freescale.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Claudiu Manoil authored
Throughout the code there are places where the controller's hw interrupt sources need to get disabled/enabled (masked/ un-masked) all at once. The recommendation for disabling the interrupts is to clear the ievent first then the imask register (not the other way around). Use the gfar_ints_enable/disable() helpers to make these operations consistent. Signed-off-by: Claudiu Manoil <claudiu.manoil@freescale.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Claudiu Manoil authored
The RCTRL updates of the FSL_GIANFAR_DEV_HAS_PADDING device flag get overriden by the FSL_GIANFAR_DEV_HAS_TIMER flag settings, which impose a Rx padding alignment of 8 bytes. As all the eTSEC devices that set HAS_PADDING also set the HAS_TIMER flag, the HAS_PADDING flag is now obsolete. Signed-off-by: Claudiu Manoil <claudiu.manoil@freescale.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Claudiu Manoil authored
Removing the sysfs stubs for the Tx FIFOCFG and ATTRELI (stashing) config registers, as these registers may only be configured after a MAC reset, with the controller stopped (i.e. during hw init, at probe() time). The current sysfs stubs allow on-the-fly updates of these registers (the locking measures are useless and only add unecessary code). Changing these registers is discouraged. Only the default values will be used instead. Moreover, the stashing (ATTRELI) configuration options were effectively disabled (didn't get to the hw anyway if changed) because the stashing device_flags (HAS_BD_STASHING|HAS_BUF_STASHING) were "accidentally" cleared during probe(). Signed-off-by: Claudiu Manoil <claudiu.manoil@freescale.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Claudiu Manoil authored
Factor out gfar_hw_init() to contain all the controller hw initialization steps for a better control of register writes, and to significantly simplify the tangled code from gfar_probe(). This results in code size and stack usage reduction (besides code readability). Fix memory leak on device removal, by freeing the rx_/tx_queue structures. Replace custom bit swapping function with a library one (bitrev8). Move allocation of rx_/tx_queue struct arrays before the group structure init, because in order to assign Rx/Tx queues to groups we need to have the queues first. This also allows earlier bail out of gfar_probe(), in case the memory allocation fails. The flow control checks for maccfg1 were removed from gfar_probe(), since flow control is disabled at probe time (priv->rx_/tx_pause_en are 0). Redundant initializations (by 0) also removed. Signed-off-by: Claudiu Manoil <claudiu.manoil@freescale.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
- 17 Feb, 2014 26 commits
-
-
Sachin Kamat authored
linux/sctp.h was included twice. Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Wang Yufen authored
Signed-off-by: Wang Yufen <wangyufen@huawei.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Wang Yufen authored
Signed-off-by: Wang Yufen <wangyufen@huawei.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Wang Yufen authored
Signed-off-by: Wang Yufen <wangyufen@huawei.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Wang Yufen authored
ERROR: spaces required and "(foo*)" should be "(foo *)" Signed-off-by: Wang Yufen <wangyufen@huawei.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Yang Yingliang authored
Replace two magic numbers which intialize clgstate::state. Signed-off-by: Yang Yingliang <yangyingliang@huawei.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
David S. Miller authored
Phoebe Buckheister says: ==================== ieee802154: support rf212 and extended mac features this patch set adds support for the RF212 radio chip to the existing at86rf230 driver and adds support for numerous features of the RF212 chips to the ieee802154 stack. These features include CSMA parameter configuration, transmit power control, CCA parameter configuration, and automatic retransmission of frames. Netlink APIs are provided for all new options introduced in this set. Many features might also work for RF230, but since I have no such chips at my disposal, most new features are implemented only for RF212. Changes since v2: * Indentation Changes since v1: * CodingStyle compliance. Thanks Sergei Shtylyov * Add CSMA parameters to netlink phy list that were forgotten in v1 ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
-
Phoebe Buckheister authored
This patch does multiple things: * add .set_csma_params and .set_frame_retries for the RF212 radio. This should work fine with RF230, but since I have no RF230 radios to test with, RF230 does not implement these right now * enable TX_ARET for frame retransmission limits greater than -1 Since RF230 has no operations to change CSMA parameters or frame retry limits, RF230 will not be able to enter TX_ARET with this patch. Signed-off-by: Phoebe Buckheister <phoebe.buckheister@itwm.fraunhofer.de> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Phoebe Buckheister authored
Introduce new netlink attributes for SET_PHY_ATTRS: * CSMA minimal backoff exponent * CSMA maximal backoff exponent * CSMA retry limit * frame retransmission limit The CSMA attributes shall correspond to minBE, maxBE and maxCSMABackoffs of 802.15.4, respectively. The frame retransmission shall correspond to maxFrameRetries of 802.15.4, unless given as -1: then the old behaviour of the stack shall apply. For RF2xy, the old behaviour is to not do channel sensing at all and simply send *right now*, which is not intended behaviour for most applications and actually prohibited for some channel/page combinations. For all values except frame retransmission limit, the defaults of 802.15.4 apply. Frame retransmission limits are set to -1 to indicate backward-compatible behaviour. Signed-off-by: Phoebe Buckheister <phoebe.buckheister@itwm.fraunhofer.de> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Phoebe Buckheister authored
A documented erratum of the RF212 chip describes that some versions of RF212 may not be properly reset by the standard reset procedure. The described workaround seems to not fully work either; my RF212 chips will not correctly receive any frames unless they are taken from RX mode to TRX_OFF and back to RX mode, effectively forcing a up-down-up-cycle. Going to TRX_OFF and to RX without intermediate state changes at least once fixes this. The same transition is allowed for RF230, so simply do it all the time. Signed-off-by: Phoebe Buckheister <phoebe.buckheister@itwm.fraunhofer.de> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Phoebe Buckheister authored
Since three of the four clear channel assesment modes make use of energy detection, provide an API to set the energy detection threshold. Driver support for this is available in at86rf230 for the RF212 chips. Since for these chips the minimal energy detection threshold depends on page and channel used, add a field to struct at86rf230_local that stores the minimal threshold. Actual ED thresholds are configured as offsets from this value. For RF212, setting the ED threshold will not work before a channel/page has been set due to the dependency of energy detection in the chip and the actual channel/page selected. Signed-off-by: Phoebe Buckheister <phoebe.buckheister@itwm.fraunhofer.de> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Phoebe Buckheister authored
The standard describes four modes of clear channel assesment: "energy above threshold", "carrier found", and the logical and/or of these two. Support for CCA mode setting is included in the at86rf230 driver, predicated for RF212 chips. Signed-off-by: Phoebe Buckheister <phoebe.buckheister@itwm.fraunhofer.de> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Phoebe Buckheister authored
Listen-before-talk is an alternative to CSMA in uncoordinated networks and prescribed by european regulations if one wants to have a device with radio duty cycles above 10% (or less in some bands). Add a phy property to enable/disable LBT in the phy, including support in the at86rf230 driver for RF212 chips. Signed-off-by: Phoebe Buckheister <phoebe.buckheister@itwm.fraunhofer.de> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Phoebe Buckheister authored
The standard assigns channel 0 on page 2 to be 100kbps QPSK in the 868.3MHz band. Add support to the at86rf230 driver for this channel and page, at the moment predicated only for the RF212 chip. Per the datasheet, configurations for page 0, channels 0 to 10 and page 2, channels 0 to 10 differ only in the BPSK_QPSK bit. Support for channels 1 to 10 is untested. Signed-off-by: Phoebe Buckheister <phoebe.buckheister@itwm.fraunhofer.de> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Phoebe Buckheister authored
Replace the current u8 transmit_power in wpan_phy with s8 transmit_power. The u8 field contained the actual tx power and a tolerance field, which no physical radio every used. Adjust sysfs entries to keep compatibility with userspace, give tolerances of +-1dB statically there. This patch only adds support for this in the at86rf230 driver and the RF212 chip. Configuration calculation for RF212 is also somewhat basic, but does the job - the RF212 datasheet gives a large table with suggested values for combinations of TX power and page/channel, if this does not work well, we might have to copy the whole table. Signed-off-by: Phoebe Buckheister <phoebe.buckheister@itwm.fraunhofer.de> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Phoebe Buckheister authored
The current IEEE802.15.4 stack assumes that a radio will never deliver packets with a bad CRC into the stack, as required by the standard. at86rf230 driven radios violates this assumption because of another incompatibility: devices are required to send ACKs if requested by a sender, but RF2xx will only send ACKs from a special receive mode that is currently not used by the driver. Enable this receive mode to fix both bugs. Frames with bad CRCs will not be received at all, and ACKs will be sent if so requested. Signed-off-by: Phoebe Buckheister <phoebe.buckheister@itwm.fraunhofer.de> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Phoebe Buckheister authored
Since the AT86RF2xy chips are mostly compatible, this is only a small change to the actual driver code. The at86rf230 driver already supports the RF212 in most places, only three small adjustments are required: * force the initial state after P_ON to FORCE_TRX_OFF to work around a documented erratum * channels_supported depends on the frequency of the transceiver, and thus is_rf212 * do early detection of chip version select an appropriate _ops struct based on the chip version. Signed-off-by: Phoebe Buckheister <phoebe.buckheister@itwm.fraunhofer.de> Signed-off-by: David S. Miller <davem@davemloft.net>
-
David S. Miller authored
Florian Fainelli says: ==================== net: phy: soft reset rework for 10G PHYs As reported by Shaohui, 10G PHYs may have a slightly more complex reset sequence for which a BMCR_RESET software reset might not suffice. This patchset offers a solution for those by allowing them to implement their own soft_reset() callback. Finally there is an update to the PHY library Documentation to cover for the newly added callbacks of the PHY driver structure. Changes in v2: - fixed callback testing - fixed typo in Documentation ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
-
Florian Fainelli authored
The PHY library was missing a bunch of newly added PHY driver callbacks along with a smallish description of what they do, fix that. Signed-off-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Florian Fainelli authored
As pointed out by Shaohui, most 10G PHYs out there have a non-standard compliant software reset sequence, eventually something much more complex than just toggling the BMCR_RESET bit. Allow PHY driver to implement their own soft_reset() callback to deal with that. If no callback is provided, call into genphy_soft_reset() which makes sure the existing behavior is kept intact. Reported-by: Shaohui Xie <Shaohui.Xie@freescale.com> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Florian Fainelli authored
As pointed out by Shaohui, this function is generic for 10/100/1000 PHYs, but 10G PHYs might have a slightly different reset sequence which prevents most of them from using this function. Move the BMCR_RESET based software resent sequence to genphy_soft_reset() in preparation for allowing PHY drivers to implement a soft_reset() callback. Reported-by: Shaohui Xie <Shaohui.Xie@freescale.com> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
KY Srinivasan authored
Get rid of the buffer allocation in the receive path for normal packets. Signed-off-by: K. Y. Srinivasan <kys@microsoft.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
KY Srinivasan authored
Make the receive path a little more efficient by parameterizing the required state rather than re-establishing that state. Signed-off-by: K. Y. Srinivasan <kys@microsoft.com> Reviewed-by: Haiyang Zhang <haiyangz@microsoft.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
KY Srinivasan authored
This structure is redundant; get rid of it make the code little more efficient - get rid of the unnecessary indirection. Signed-off-by: K. Y. Srinivasan <kys@microsoft.com> Reviewed-by: Haiyang Zhang <haiyangz@microsoft.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Stefan Sørensen authored
This patch allows the use of a generic timestamping phy connected to the cpsw if CPTS support is not enabled. This also adds support of the SIOCGMIIREG and SIOCSMIIREG, and moves handling of SIOCGMIIPHY to the generic driver. Signed-off-by: Stefan Sørensen <stefan.sorensen@spectralink.com> Reviewed-by: Ben Hutchings <ben@decadent.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Joe Perches authored
ether_addr_copy is smaller and faster for some architectures. This relies on a stack frame being at least __aligned(2) for one use of an Ethernet address on the stack. Signed-off-by: Joe Perches <joe@perches.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-