Skip to content

K
Kernel

openeuler / Kernel
1 年多 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 26 10月, 2019 9 次提交
    • H
      r8169: improve rtl8169_rx_fill · e4b5c7a5
      由 Heiner Kallweit 提交于 
      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: NHeiner Kallweit <hkallweit1@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      e4b5c7a5
    • H
      r8169: align fix_features callback with vendor driver · 7cb83b21
      由 Heiner Kallweit 提交于 
      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: NHeiner Kallweit <hkallweit1@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      7cb83b21
    • D
      Merge branch 'for-upstream' of... · 8ca12bc3
      由 David S. Miller 提交于 
      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: NDavid S. Miller <davem@davemloft.net>
      8ca12bc3
    • J
      tcp: add TCP_INFO status for failed client TFO · 48027478
      由 Jason Baron 提交于 
      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: NJason 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: NYuchung Cheng <ycheng@google.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      48027478
    • D
      Merge branch 'phy-dp83867-enable-robust-auto-mdix' · 79f2056b
      由 David S. Miller 提交于 
      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: NDavid S. Miller <davem@davemloft.net>
      79f2056b
    • G
      net: phy: dp83867: move dt parsing to probe · ef87f7da
      由 Grygorii Strashko 提交于 
      Move DT parsing code to probe dp83867_probe() as it's one time operation.
Signed-off-by: NGrygorii Strashko <grygorii.strashko@ti.com>
Reviewed-by: NAndrew Lunn <andrew@lunn.ch>
Reviewed-by: NFlorian Fainelli <f.fainelli@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      ef87f7da
    • G
      net: phy: dp83867: enable robust auto-mdix · 5a7f08c2
      由 Grygorii Strashko 提交于 
      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: NGrygorii Strashko <grygorii.strashko@ti.com>
Reviewed-by: NAndrew Lunn <andrew@lunn.ch>
Reviewed-by: NFlorian Fainelli <f.fainelli@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      5a7f08c2
    • V
      net: sch_generic: Use pfifo_fast as fallback scheduler for CAN hardware · 546b85bb
      由 Vincent Prince 提交于 
      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: NMarc Kleine-Budde <mkl@pengutronix.de>
Signed-off-by: NMarc Kleine-Budde <mkl@pengutronix.de>
Signed-off-by: NVincent Prince <vincent.prince.fr@gmail.com>
Acked-by: NDave Taht <dave.taht@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      546b85bb
    • H
      r8152: check the pointer rtl_fw->fw before using it · 8e484ebb
      由 Hayes Wang 提交于 
      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: NMarek Szyprowski <m.szyprowski@samsung.com>
Tested-by: NMarek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: NHayes Wang <hayeswang@realtek.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      8e484ebb
  3. 25 10月, 2019 21 次提交
  5. 24 10月, 2019 9 次提交
  7. 23 10月, 2019 1 次提交