1. 26 Oct, 2019 18 commits
    • Abhishek Pandit-Subedi's avatar
      Bluetooth: hci_bcm: Add compatible string for BCM43540 · d462af20
      Abhishek Pandit-Subedi authored
      The BCM43540 chip is a 802.11 a/b/g/n/ac + Bluetooth 4.1 combo module.
      This patch adds a compatible string match to the serdev driver for the
      Bluetooth part of the chip.
      Signed-off-by: default avatarAbhishek Pandit-Subedi <abhishekpandit@chromium.org>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      d462af20
    • YueHaibing's avatar
      Bluetooth: btrtl: remove unneeded semicolon · 515d6798
      YueHaibing authored
      Remove unneeded semicolon.
      This is detected by coccinelle.
      Signed-off-by: default avatarYueHaibing <yuehaibing@huawei.com>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      515d6798
    • David S. Miller's avatar
      Merge branch 'ionic-updates' · 0629d245
      David S. Miller authored
      Shannon Nelson says:
      
      ====================
      ionic updates
      
      These are a few of the driver updates we've been working on internally.
      These clean up a few mismatched struct comments, add checking for dead
      firmware, fix an initialization bug, and change the Rx buffer management.
      
      These are based on net-next v5.4-rc3-709-g985fd98a.
      
      v2: clear napi->skb in the error case in ionic_rx_frags()
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      0629d245
    • Shannon Nelson's avatar
      ionic: update driver version · 63ad1cd6
      Shannon Nelson authored
      Signed-off-by: default avatarShannon Nelson <snelson@pensando.io>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      63ad1cd6
    • Shannon Nelson's avatar
      ionic: implement support for rx sgl · 08f2e4b2
      Shannon Nelson authored
      Even out Rx performance across MTU sizes by changing from full
      skb allocations to page-based frag allocations.  The device
      supports a form of scatter-gather in the Rx path, so we can
      set up a number of pages for each descriptor, all of which are
      easier to alloc and pass around than the standard kzalloc'd
      buffer.  An skb is wrapped around the pages while processing
      the received packets, and pages are recycled as needed, or
      left alone if they weren't used in the Rx.
      Signed-off-by: default avatarShannon Nelson <snelson@pensando.io>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      08f2e4b2
    • Shannon Nelson's avatar
      ionic: add a watchdog timer to monitor heartbeat · 089406bc
      Shannon Nelson authored
      Add a watchdog to periodically monitor the NIC heartbeat.
      Signed-off-by: default avatarShannon Nelson <snelson@pensando.io>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      089406bc
    • Shannon Nelson's avatar
      ionic: add heartbeat check · 97ca4865
      Shannon Nelson authored
      Most of our firmware has a heartbeat feature that the driver
      can watch for to see if the FW is still alive and likely to
      answer a dev_cmd or AdminQ request.
      Signed-off-by: default avatarShannon Nelson <snelson@pensando.io>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      97ca4865
    • Shannon Nelson's avatar
      ionic: reverse an interrupt coalesce calculation · ff7ebed9
      Shannon Nelson authored
      Fix the initial interrupt coalesce usec-to-hw setting
      to actually be usec-to-hw.
      
      Fixes: 780eded3 ("ionic: report users coalesce request")
      Signed-off-by: default avatarShannon Nelson <snelson@pensando.io>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      ff7ebed9
    • Shannon Nelson's avatar
      ionic: fix up struct name comments · 5c28f213
      Shannon Nelson authored
      Fix up struct names in the ionic_if.h comments
      Signed-off-by: default avatarShannon Nelson <snelson@pensando.io>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      5c28f213
    • Heiner Kallweit's avatar
      r8169: improve rtl8169_rx_fill · e4b5c7a5
      Heiner Kallweit authored
      We have only one user of the error path, so we can inline it.
      In addition the call to rtl8169_make_unusable_by_asic() can be removed
      because rtl8169_alloc_rx_data() didn't call rtl8169_mark_to_asic() yet
      for the respective index if returning NULL.
      Signed-off-by: default avatarHeiner Kallweit <hkallweit1@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      e4b5c7a5
    • Heiner Kallweit's avatar
      r8169: align fix_features callback with vendor driver · 7cb83b21
      Heiner Kallweit authored
      This patch aligns the fix_features callback with the vendor driver and
      also disables IPv6 HW checksumming and TSO if jumbo packets are used
      on RTL8101/RTL8168/RTL8125.
      Signed-off-by: default avatarHeiner Kallweit <hkallweit1@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      7cb83b21
    • David S. Miller's avatar
      Merge branch 'for-upstream' of... · 8ca12bc3
      David S. Miller authored
      Merge branch 'for-upstream' of git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next
      
      Johan Hedberg says:
      
      ====================
      pull request: bluetooth-next 2019-10-23
      
      Here's the main bluetooth-next pull request for the 5.5 kernel:
      
       - Multiple fixes to hci_qca driver
       - Fix for HCI_USER_CHANNEL initialization
       - btwlink: drop superseded driver
       - Add support for Intel FW download error recovery
       - Various other smaller fixes & improvements
      
      Please let me know if there are any issues pulling. Thanks.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      8ca12bc3
    • Jason Baron's avatar
      tcp: add TCP_INFO status for failed client TFO · 48027478
      Jason Baron authored
      The TCPI_OPT_SYN_DATA bit as part of tcpi_options currently reports whether
      or not data-in-SYN was ack'd on both the client and server side. We'd like
      to gather more information on the client-side in the failure case in order
      to indicate the reason for the failure. This can be useful for not only
      debugging TFO, but also for creating TFO socket policies. For example, if
      a middle box removes the TFO option or drops a data-in-SYN, we can
      can detect this case, and turn off TFO for these connections saving the
      extra retransmits.
      
      The newly added tcpi_fastopen_client_fail status is 2 bits and has the
      following 4 states:
      
      1) TFO_STATUS_UNSPEC
      
      Catch-all state which includes when TFO is disabled via black hole
      detection, which is indicated via LINUX_MIB_TCPFASTOPENBLACKHOLE.
      
      2) TFO_COOKIE_UNAVAILABLE
      
      If TFO_CLIENT_NO_COOKIE mode is off, this state indicates that no cookie
      is available in the cache.
      
      3) TFO_DATA_NOT_ACKED
      
      Data was sent with SYN, we received a SYN/ACK but it did not cover the data
      portion. Cookie is not accepted by server because the cookie may be invalid
      or the server may be overloaded.
      
      4) TFO_SYN_RETRANSMITTED
      
      Data was sent with SYN, we received a SYN/ACK which did not cover the data
      after at least 1 additional SYN was sent (without data). It may be the case
      that a middle-box is dropping data-in-SYN packets. Thus, it would be more
      efficient to not use TFO on this connection to avoid extra retransmits
      during connection establishment.
      
      These new fields do not cover all the cases where TFO may fail, but other
      failures, such as SYN/ACK + data being dropped, will result in the
      connection not becoming established. And a connection blackhole after
      session establishment shows up as a stalled connection.
      Signed-off-by: default avatarJason Baron <jbaron@akamai.com>
      Cc: Eric Dumazet <edumazet@google.com>
      Cc: Neal Cardwell <ncardwell@google.com>
      Cc: Christoph Paasch <cpaasch@apple.com>
      Cc: Yuchung Cheng <ycheng@google.com>
      Acked-by: default avatarYuchung Cheng <ycheng@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      48027478
    • David S. Miller's avatar
      Merge branch 'phy-dp83867-enable-robust-auto-mdix' · 79f2056b
      David S. Miller authored
      Grygorii Strashko says:
      
      ====================
      net: phy: dp83867: enable robust auto-mdix
      
      Patch 1 - improves link detection when dp83867 PHY is configured in manual mode
      by enabling CFG3[9] Robust Auto-MDIX option.
      
      Patch 2 - is minor optimization.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      79f2056b
    • Grygorii Strashko's avatar
      net: phy: dp83867: move dt parsing to probe · ef87f7da
      Grygorii Strashko authored
      Move DT parsing code to probe dp83867_probe() as it's one time operation.
      Signed-off-by: default avatarGrygorii Strashko <grygorii.strashko@ti.com>
      Reviewed-by: default avatarAndrew Lunn <andrew@lunn.ch>
      Reviewed-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      ef87f7da
    • Grygorii Strashko's avatar
      net: phy: dp83867: enable robust auto-mdix · 5a7f08c2
      Grygorii Strashko authored
      The link detection timeouts can be observed (or link might not be detected
      at all) when dp83867 PHY is configured in manual mode (speed/duplex).
      
      CFG3[9] Robust Auto-MDIX option allows to significantly improve link detection
      in case dp83867 is configured in manual mode and reduce link detection
      time.
      As per DM: "If link partners are configured to operational modes that are
      not supported by normal Auto MDI/MDIX mode (like Auto-Neg versus Force
      100Base-TX or Force 100Base-TX versus Force 100Base-TX), this Robust Auto
      MDI/MDIX mode allows MDI/MDIX resolution and prevents deadlock."
      
      Hence, enable this option by default as there are no known reasons
      not to do so.
      Signed-off-by: default avatarGrygorii Strashko <grygorii.strashko@ti.com>
      Reviewed-by: default avatarAndrew Lunn <andrew@lunn.ch>
      Reviewed-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      5a7f08c2
    • Vincent Prince's avatar
      net: sch_generic: Use pfifo_fast as fallback scheduler for CAN hardware · 546b85bb
      Vincent Prince authored
      There is networking hardware that isn't based on Ethernet for layers 1 and 2.
      
      For example CAN.
      
      CAN is a multi-master serial bus standard for connecting Electronic Control
      Units [ECUs] also known as nodes. A frame on the CAN bus carries up to 8 bytes
      of payload. Frame corruption is detected by a CRC. However frame loss due to
      corruption is possible, but a quite unusual phenomenon.
      
      While fq_codel works great for TCP/IP, it doesn't for CAN. There are a lot of
      legacy protocols on top of CAN, which are not build with flow control or high
      CAN frame drop rates in mind.
      
      When using fq_codel, as soon as the queue reaches a certain delay based length,
      skbs from the head of the queue are silently dropped. Silently meaning that the
      user space using a send() or similar syscall doesn't get an error. However
      TCP's flow control algorithm will detect dropped packages and adjust the
      bandwidth accordingly.
      
      When using fq_codel and sending raw frames over CAN, which is the common use
      case, the user space thinks the package has been sent without problems, because
      send() returned without an error. pfifo_fast will drop skbs, if the queue
      length exceeds the maximum. But with this scheduler the skbs at the tail are
      dropped, an error (-ENOBUFS) is propagated to user space. So that the user
      space can slow down the package generation.
      
      On distributions, where fq_codel is made default via CONFIG_DEFAULT_NET_SCH
      during compile time, or set default during runtime with sysctl
      net.core.default_qdisc (see [1]), we get a bad user experience. In my test case
      with pfifo_fast, I can transfer thousands of million CAN frames without a frame
      drop. On the other hand with fq_codel there is more then one lost CAN frame per
      thousand frames.
      
      As pointed out fq_codel is not suited for CAN hardware, so this patch changes
      attach_one_default_qdisc() to use pfifo_fast for "ARPHRD_CAN" network devices.
      
      During transition of a netdev from down to up state the default queuing
      discipline is attached by attach_default_qdiscs() with the help of
      attach_one_default_qdisc(). This patch modifies attach_one_default_qdisc() to
      attach the pfifo_fast (pfifo_fast_ops) if the network device type is
      "ARPHRD_CAN".
      
      [1] https://github.com/systemd/systemd/issues/9194Suggested-by: default avatarMarc Kleine-Budde <mkl@pengutronix.de>
      Signed-off-by: default avatarMarc Kleine-Budde <mkl@pengutronix.de>
      Signed-off-by: default avatarVincent Prince <vincent.prince.fr@gmail.com>
      Acked-by: default avatarDave Taht <dave.taht@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      546b85bb
    • Hayes Wang's avatar
      r8152: check the pointer rtl_fw->fw before using it · 8e484ebb
      Hayes Wang authored
      Fix the pointer rtl_fw->fw would be used before checking in
      rtl8152_apply_firmware() that causes the following kernel oops.
      
      Unable to handle kernel NULL pointer dereference at virtual address 00000002
      pgd = (ptrval)
      [00000002] *pgd=00000000
      Internal error: Oops: 5 [#1] PREEMPT SMP ARM
      Modules linked in:
      CPU: 0 PID: 131 Comm: kworker/0:2 Not tainted
      5.4.0-rc1-00539-g9370f2d0 #6788
      Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
      Workqueue: events_long rtl_hw_phy_work_func_t
      PC is at rtl8152_apply_firmware+0x14/0x464
      LR is at r8153_hw_phy_cfg+0x24/0x17c
      pc : [<c064f4e4>]    lr : [<c064fa18>]    psr: a0000013
      sp : e75c9e60  ip : 60000013  fp : c11b7614
      r10: e883b91c  r9 : 00000000  r8 : fffffffe
      r7 : e883b640  r6 : fffffffe  r5 : fffffffe  r4 : e883b640
      r3 : 736cfe7c  r2 : 736cfe7c  r1 : 000052f8  r0 : e883b640
      Flags: NzCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment none
      Control: 10c5387d  Table: 6640006a  DAC: 00000051
      Process kworker/0:2 (pid: 131, stack limit = 0x(ptrval))
      Stack: (0xe75c9e60 to 0xe75ca000)
      ...
      [<c064f4e4>] (rtl8152_apply_firmware) from [<c064fa18>]
      (r8153_hw_phy_cfg+0x24/0x17c)
      [<c064fa18>] (r8153_hw_phy_cfg) from [<c064e784>]
      (rtl_hw_phy_work_func_t+0x220/0x3e4)
      [<c064e784>] (rtl_hw_phy_work_func_t) from [<c0148a74>]
      (process_one_work+0x22c/0x7c8)
      [<c0148a74>] (process_one_work) from [<c0149054>] (worker_thread+0x44/0x520)
      [<c0149054>] (worker_thread) from [<c0150548>] (kthread+0x130/0x164)
      [<c0150548>] (kthread) from [<c01010b4>] (ret_from_fork+0x14/0x20)
      Exception stack(0xe75c9fb0 to 0xe75c9ff8)
      ...
      
      Fixes: 9370f2d0 ("r8152: support request_firmware for RTL8153")
      Reported-by: default avatarMarek Szyprowski <m.szyprowski@samsung.com>
      Tested-by: default avatarMarek Szyprowski <m.szyprowski@samsung.com>
      Signed-off-by: default avatarHayes Wang <hayeswang@realtek.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      8e484ebb
  2. 24 Oct, 2019 22 commits