- 28 Apr, 2014 7 commits
-
-
Bjørn Mork authored
Dan writes: "The Dell drivers use the same configuration for PIDs: 81A2: Dell Wireless 5806 Gobi(TM) 4G LTE Mobile Broadband Card 81A3: Dell Wireless 5570 HSPA+ (42Mbps) Mobile Broadband Card 81A4: Dell Wireless 5570e HSPA+ (42Mbps) Mobile Broadband Card 81A8: Dell Wireless 5808 Gobi(TM) 4G LTE Mobile Broadband Card 81A9: Dell Wireless 5808e Gobi(TM) 4G LTE Mobile Broadband Card These devices are all clearly Sierra devices, but are also definitely Gobi-based. The A8 might be the MC7700/7710 and A9 is likely a MC7750. >From DellGobi5kSetup.exe from the Dell drivers: usbif0: serial/firmware loader? usbif2: nmea usbif3: modem/ppp usbif8: net/QMI" Reported-by:
AceLan Kao <acelan.kao@canonical.com> Reported-by:
Dan Williams <dcbw@redhat.com> Signed-off-by:
Bjørn Mork <bjorn@mork.no> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Bjørn Mork authored
A number of older CMOTech modems are based on Qualcomm chips and exporting a QMI/wwan function. Reported-by:
Lars Melin <larsm17@gmail.com> Signed-off-by:
-
Bjørn Mork authored
Device interface layout: 0: ff/ff/ff - serial 1: ff/00/00 - serial AT+PPP 2: ff/ff/ff - QMI/wwan 3: 08/06/50 - storage Signed-off-by:
-
Bjørn Mork authored
Device interface layout: 0: ff/ff/ff - serial 1: ff/ff/ff - serial AT+PPP 2: 08/06/50 - storage 3: ff/ff/ff - serial 4: ff/ff/ff - QMI/wwan Reported-by:
Julio Araujo <julio.araujo@wllctel.com.br> Signed-off-by:
-
Bjørn Mork authored
Signed-off-by:
-
Bjørn Mork authored
Signed-off-by:
-
Bjørn Mork authored
Signed-off-by:
-
- 27 Apr, 2014 5 commits
-
-
Xufeng Zhang authored
commit 813b3b5d (ipv4: Use caller's on-stack flowi as-is in output route lookups.) introduces another regression which is very similar to the problem of commit e6b45241 (ipv4: reset flowi parameters on route connect) wants to fix: Before we call ip_route_output_key() in sctp_v4_get_dst() to get a dst that matches a bind address as the source address, we have already called this function previously and the flowi parameters have been initialized including flowi4_oif, so when we call this function again, the process in __ip_route_output_key() will be different because of the setting of flowi4_oif, and we'll get a networking device which corresponds to the inputted flowi4_oif as the output device, this is wrong because we'll never hit this place if the previously returned source address of dst match one of the bound addresses. To reproduce this problem, a vlan setting is enough: # ifconfig eth0 up # route del default # vconfig add eth0 2 # vconfig add eth0 3 # ifconfig eth0.2 10.0.1.14 netmask 255.255.255.0 # route add default gw 10.0.1.254 dev eth0.2 # ifconfig eth0.3 10.0.0.14 netmask 255.255.255.0 # ip rule add from 10.0.0.14 table 4 # ip route add table 4 default via 10.0.0.254 src 10.0.0.14 dev eth0.3 # sctp_darn -H 10.0.0.14 -P 36422 -h 10.1.4.134 -p 36422 -s -I You'll detect that all the flow are routed to eth0.2(10.0.1.254). Signed-off-by:
Xufeng Zhang <xufeng.zhang@windriver.com> Signed-off-by:
Julian Anastasov <ja@ssi.bg> Acked-by:
Vlad Yasevich <vyasevich@gmail.com> Signed-off-by:
-
Heiko Stübner authored
This adds ability for the arc_emac to really handle its supplying clock. To get the needed clock-frequency either a real clock or the previous clock-frequency property must be provided. Signed-off-by:
Heiko Stuebner <heiko@sntech.de> Tested-by:
Max Schwarz <max.schwarz@online.de> Signed-off-by:
-
Heiko Stübner authored
The probe function at the moment only frees the netdev but does not disconnect the phy or removes the mdio bus it registered. Signed-off-by:
-
Toshiaki Makita authored
When bridge device is created with IFLA_ADDRESS, we are not calling br_stp_change_bridge_id(), which leads to incorrect local fdb management and bridge id calculation, and prevents us from receiving frames on the bridge device. Reported-by:
Tom Gundersen <teg@jklm.no> Signed-off-by:
Toshiaki Makita <makita.toshiaki@lab.ntt.co.jp> Signed-off-by:
-
Hariprasad Shenai authored
Signed-off-by:
Hariprasad Shenai <hariprasad@chelsio.com> Signed-off-by:
-
- 26 Apr, 2014 11 commits
-
-
Jacob Keller authored
This patch fixes the PTP Tx timestamp interrupt handler. The original code misinterpreted the interrupt handler design. We were clearing the ena_mask bit for the Timesync interrupts. This is done to indicate that the interrupt will be handled in a scheduled work item (instead of immediately) and that work item is responsible for re-enabling the interrupts. However, the Tx timestamp was being handled immediately and nothing was ever re-enabling it. This resulted in a single interrupt working for the life of the driver. This patch fixes the issue by instead clearing the bit from icr0 which is used to indicate that the interrupt was immediately handled and can be re-enabled right away. This patch also clears up a related issue due to writing the PRTTSYN_STAT_0 register, which was unintentionally clearing the cause bits for Timesync interrupts. Change-ID: I057bd70d53c302f60fab78246989cbdfa469d83b Signed-off-by:
Jacob Keller <jacob.e.keller@intel.com> Acked-by:
Anjali Singhai Jain <anjali.singhai@intel.com> Acked-by:
Shannon Nelson <shannon.nelson@intel.com> Tested-by:
Kavindya Deegala <kavindya.s.deegala@intel.com> Signed-off-by:
Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by:
-
git://gitorious.org/linux-can/linux-canDavid S. Miller authored
Marc Kleine-Budde says: ==================== this is a pull request for net/master, for the v3.15 release cycle, consisting of 26 patches. Thomas Gleixner contributes 21 patches for the c_can driver, which address several shortcomings in the driver like hardware initialisation, concurrency, message ordering and poor performance. Two patches Oliver Hartkopp, one adds a missing lock to the sja1000_isa driver, the other one fixes the return value in the generic bit time configuration function. And finally a patch by Alexander Stein, that fixes the slcan driver to use the correct spinlock variant. To make it 26 patches, Wolfgang Grandegger patch for the c_can_pci driver, which enables the bus master only for MSI and a patch by Wolfram Sang, which converts the 'instance' in the c_can driver to the proper type. ==================== Signed-off-by: -
David S. Miller authored
Vince Bridgers says: ==================== This series of patches addresses a handful of issues found in testing and reported by users of the Altera Triple Speed Ethernet soft IP. The patches address the following issues (in summary) 1) The SGDMA soft IP was found to incorrectly process receive packets when the target physical address of the receive buffer was on a boundary that's not 32-bit aligned. One of the patches addresses this issue. 2) The pause quanta was not being set by the driver, one patch of this series sets the pause quanta to the IEEE defined default value since the hardware reset value is 0. 3) An issue in a error recovery path of the probe routine caused a kernel panic in the event a phy was probed and could not be found. A patch addresses this issue. 4) A change was made to the driver name for Ethtool support, and comments added to support an addition to Ethtool to support the Altera Triple Speed Ethernet controller. ==================== Signed-off-by: -
Vince Bridgers authored
This patch changes the name used by Ethtool to something more conventional in preparation for TSE Ethtool register dump support to be added in the near future. Signed-off-by:
Vince Bridgers <vbridgers2013@gmail.com> Signed-off-by:
-
Vince Bridgers authored
This patch addresses a fault in the error recovery path of the probe routine where the netdev structure was not being unregistered properly leading to a panic only when the phy probe failed. Abbreviated panic stack seen is as follows: (free_netdev+0xXX) from (altera_tse_probe+0xXX) (altera_tse_probe+0xXX) from (platform_drv_probe+0xXX) (platform_drv_probe+0xXX) from (driver_probe_device+0xXX) (driver_probe_device+0xXX) from (__driver_attach+0xXX) (__driver_attach+0xXX) from (bus_for_each_dev+0xXX) (bus_for_each_dev+0xXX) from (driver_attach+0xXX) (driver_attach+0xXX) from (bus_add_driver+0xXX) (bus_add_driver+0xXX) from (driver_register+0xXX) (driver_register+0xXX) from (__platform_driver_register+0xXX) (__platform_driver_register+0xXX) from (altera_tse_driver_init+0xXX) (altera_tse_driver_init+0xXX) from (do_one_initcall+0xXX) (do_one_initcall+0xXX) from (kernel_init_freeable+0xXX) (kernel_init_freeable+0xXX) from (kernel_init+0xXX) (kernel_init+0xXX) from (ret_from_fork+0xXX) Signed-off-by:
-
Vince Bridgers authored
This patch initializes the pause quanta set for transmitted pause frames to the IEEE specified default of 0xffff. Signed-off-by:
-
Vince Bridgers authored
This patch works around a recently discovered unaligned receive dma problem with the Altera SGMDA. The Altera SGDMA component cannot be configured to DMA data to unaligned addresses for receive packet operations from the Triple Speed Ethernet component because of a potential data transfer corruption that can occur. This patch addresses this issue by utilizing the shift 16 bits feature of the Altera Triple Speed Ethernet component and modifying the receive buffer physical addresses accordingly such that the target receive DMA address is always aligned on a 32-bit boundary. Signed-off-by:
Matthew Gerlach <mgerlach@altera.com> Signed-off-by:
-
David S. Miller authored
Yuval Mintz says: ==================== bnx2x: SRIOV bug fixes This series contains 3 SRIOV bug fixes, 2 of which are regressions starting with commit 2dc33bbc "bnx2x: Remove the sriov VFOP mechanism". ==================== Signed-off-by:
-
Narender Kumar authored
Commit 2dc33bbc "bnx2x: Remove the sriov VFOP mechanism" caused a regression, preventing VFs from configuring multicast filters. Signed-off-by:
Naredner Kumar <narender.kumar@qlogic.com> Signed-off-by:
Yuval Mintz <Yuval.Mintz@qlogic.com> Signed-off-by:
Ariel Elior <Ariel.Elior@qlogic.com> Signed-off-by:
-
Yuval Mintz authored
Starting with commit 2dc33bbc "bnx2x: Remove the sriov VFOP mechanism", the bnx2x started enforcing vlan credits for all vlan configurations. This exposed 2 issues: - Vlan credits are not returned once a VF is removed; this causes a leak of credits, and eventually will lead to VFs with no vlan credits. - A vlan credit must be set aside for the Hypervisor to use, and should not be visible to the VF. Although linux VFs at the moment do not support vlan configuration [from the VF side] which causes them to be resilient to this sort of issue, Windows VF over linux hypervisors might fail to load as the vlan credits become depleted. Signed-off-by:
-
Yuval Mintz authored
When removing a VF interface, the driver fails to release that VF's mailbox and bulletin board allocated memory. Signed-off-by:
-
- 24 Apr, 2014 17 commits
-
-
Kumar Sundararajan authored
When the ipv6 fib changes during a table dump, the walk is restarted and the number of nodes dumped are skipped. But the existing code doesn't advance to the next node after a node is skipped. This can cause the dump to loop or produce lots of duplicates when the fib is modified during the dump. This change advances the walk to the next node if the current node is skipped after a restart. Signed-off-by:
Kumar Sundararajan <kumar@fb.com> Signed-off-by:
Chris Mason <clm@fb.com> Signed-off-by:
-
Alexander Stein authored
slc_xmit is called within softirq context and locks sl->lock, but slcan_write_wakeup is not softirq context, so we need to use spin_[un]lock_bh! Detected using kernel lock debugging mechanism. Signed-off-by:
Alexander Stein <alexander.stein@systec-electronic.com> Acked-by:
Oliver Hartkopp <socketcan@hartkopp.net> Signed-off-by:
Marc Kleine-Budde <mkl@pengutronix.de>
-
Oliver Hartkopp authored
When trying to set a data bitrate on non CAN FD devices the 'ip' tool answers with: RTNETLINK answers: Unknown error 524 Rename '-ENOTSUPP' to '-EOPNOTSUPP' so that 'ip' answers correctly: RTNETLINK answers: Operation not supported Signed-off-by: -
Oliver Hartkopp authored
When accessing the SJA1000 controller registers in the indirect access mode, writing the register number and reading/writing the data has to be an atomic attempt. As the sja1000_isa driver is an old style driver with a fixed number of instances the locking variable depends on the same index like all the other configuration elements given on the module command line. As a positive side effect dev->dev_id is populated by the instance index, which was missing in 3e66d013 ("can: populate netdev::dev_id for udev discrimination"). Reported-by:
-
Wolfgang Grandegger authored
Coverity complains that c_can_pci_probe() calls pci_enable_msi() without checking the result: CID 712278 (#1 of 1): Unchecked return value (CHECKED_RETURN) 3. check_return: Calling pci_enable_msi_block without checking return value (as is done elsewhere 88 out of 105 times). 88 pci_enable_msi(pdev); This is CID 712278. Signed-off-by:
Wolfgang Grandegger <wg@grandegger.com> Reported-by:
Bjorn Helgaas <bhelgaas@google.com> Signed-off-by:
-
Wolfram Sang authored
Commit 6439fbce (can: c_can: fix error checking of priv->instance in probe()) found the warning but applied a suboptimal solution. Since, both pdev->id and of_alias_get_id() return integers, it makes sense to convert the variable to an integer and avoid the cast. Signed-off-by:
Wolfram Sang <wsa@sang-engineering.com> Signed-off-by:
-
Thomas Gleixner authored
It's suffcient to kill the TXIE bit in the message control register even if the documentation of C and D CAN says that it's not allowed to do that while MSGVAL is set. Reality tells a different story and this change gives us another 2% of CPU back for not waiting on I/O. Signed-off-by:
Thomas Gleixner <tglx@linutronix.de> Tested-by:
-
Thomas Gleixner authored
Mark suggested to use one IF for the softirq and the other for the xmit function to avoid the xmit lock. That requires to write the frame into the interface first, then handle the echo skb and store the dlc before committing the TX request to the message ram. We use an atomic to handle the active buffers instead of reading the MSGVAL register as thats way faster especially on PCH/x86. Suggested-by:
Mark <mark5@del-llc.com> Signed-off-by:
-
Thomas Gleixner authored
Instead of obfuscating the code by artificial 16 bit splits use the proper 32 bit assignments and split the result when writing to the interface. Signed-off-by:
-
Thomas Gleixner authored
Remove the MASK from the TX transfer side. Make the code readable and get rid of the annoying IFX_WRITE_XXX_16BIT macros which are just obfuscating the code. Signed-off-by:
-
Thomas Gleixner authored
Sigh! Signed-off-by:
-
Thomas Gleixner authored
Signed-off-by:
-
Thomas Gleixner authored
Signed-off-by:
-
Thomas Gleixner authored
Signed-off-by:
-
Thomas Gleixner authored
Signed-off-by:
-
Thomas Gleixner authored
Alexander reported that the new optimized handling of the RX fifo causes random packet loss on Intel PCH C_CAN hardware. After a few fruitless debugging sessions I got hold of a PCH (eg20t) afflicted system. That machine does not have the CAN interface wired up, but it was possible to reproduce the issue with the HW loopback mode. As Alexander observed correctly, clearing the NewDat flag along with reading out the message buffer causes that issue on C_CAN, while D_CAN handles that correctly. Instead of restoring the original message buffer handling horror the following workaround solves the issue: transfer buffer to IF without clearing the NewDat handle the message clear NewDat bit That's similar to the original code but conditional for C_CAN. I really wonder why all user manuals (C_CAN, Intel PCH and some more) recommend to clear the NewDat bit right away. The knows it all Oracle operated by Gurgle does not unearth any useful information either. I simply cannot believe that we are the first to uncover that HW issue. Reported-and-tested-by: -
Thomas Gleixner authored
The RX buffer split causes packet loss in the hardware: What happens is: RX Packet 1 --> message buffer 1 (newdat bit is not cleared) RX Packet 2 --> message buffer 2 (newdat bit is not cleared) RX Packet 3 --> message buffer 3 (newdat bit is not cleared) RX Packet 4 --> message buffer 4 (newdat bit is not cleared) RX Packet 5 --> message buffer 5 (newdat bit is not cleared) RX Packet 6 --> message buffer 6 (newdat bit is not cleared) RX Packet 7 --> message buffer 7 (newdat bit is not cleared) RX Packet 8 --> message buffer 8 (newdat bit is not cleared) Clear newdat bit in message buffer 1 Clear newdat bit in message buffer 2 Clear newdat bit in message buffer 3 Clear newdat bit in message buffer 4 Clear newdat bit in message buffer 5 Clear newdat bit in message buffer 6 Clear newdat bit in message buffer 7 Clear newdat bit in message buffer 8 Now if during that clearing of newdat bits, a new message comes in, the HW gets confused and drops it. It does not matter how many of them you clear. I put a delay between clear of buffer 1 and buffer 2 which was long enough that the message should have been queued either in buffer 1 or buffer 9. But it did not show up anywhere. The next message ended up in buffer 1. So the hardware lost a packet of course without telling it via one of the error handlers. That does not happen on all clear newdat bit events. I see one of 10k packets dropped in the scenario which allows us to reproduce. But the trace looks always the same. Not splitting the RX Buffer avoids the packet loss but can cause reordering. It's hard to trigger, but it CAN happen. With that mode we use the HW as it was probably designed for. We read from the buffer 1 upwards and clear the buffer as we get the message. That's how all microcontrollers use it. So I assume that the way we handle the buffers was never really tested. According to the public documentation it should just work :) Let the user decide which evil is the lesser one. [ Oliver Hartkopp: Provided a sane config option and help text and made me switch to favour potential and unlikely reordering over packet loss ] Signed-off-by:
-
