12 Oct, 2019

1 commit


06 Sep, 2019

1 commit

  • commit 5f3e2bf008c2221478101ee72f5cb4654b9fc363 upstream.

    Some TCP peers announce a very small MSS option in their SYN and/or
    SYN/ACK messages.

    This forces the stack to send packets with a very high network/cpu
    overhead.

    Linux has enforced a minimal value of 48. Since this value includes
    the size of TCP options, and that the options can consume up to 40
    bytes, this means that each segment can include only 8 bytes of payload.

    In some cases, it can be useful to increase the minimal value
    to a saner value.

    We still let the default to 48 (TCP_MIN_SND_MSS), for compatibility
    reasons.

    Note that TCP_MAXSEG socket option enforces a minimal value
    of (TCP_MIN_MSS). David Miller increased this minimal value
    in commit c39508d6f118 ("tcp: Make TCP_MAXSEG minimum more correct.")
    from 64 to 88.

    We might in the future merge TCP_MIN_SND_MSS and TCP_MIN_MSS.

    CVE-2019-11479 -- tcp mss hardcoded to 48

    Signed-off-by: Eric Dumazet
    Suggested-by: Jonathan Looney
    Acked-by: Neal Cardwell
    Cc: Yuchung Cheng
    Cc: Tyler Hicks
    Cc: Bruce Curtis
    Cc: Jonathan Lemon
    Signed-off-by: David S. Miller
    Signed-off-by: Greg Kroah-Hartman
    (cherry picked from commit 7f9f8a37e563c67b24ccd57da1d541a95538e8d9)

    Eric Dumazet
     

30 Aug, 2019

1 commit


16 Aug, 2019

1 commit


06 Aug, 2019

1 commit


24 Jul, 2019

1 commit


19 Jul, 2019

1 commit


09 Jul, 2019

1 commit


02 Jul, 2019

1 commit


27 Jun, 2019

1 commit

  • This is an reset driver to implement a reset controller
    device DISPMIX on IMX8MM and IMX8MN platforms. Dispmix
    reset is used to reset or enable related buses and clks
    for the submodules in DISPMIX.

    All the dispmix resets are divided into three subgroups:
    sft_rstn, clk_en and mipi_rst, and each of them contains
    several reset lines to control several different modules
    on and off in DISPMIX which doesn't require the standard
    reset flow, but only line assert and deassert operations.

    Signed-off-by: Fancy Fang

    Fancy Fang
     

21 Jun, 2019

3 commits


07 Jun, 2019

1 commit

  • Since L4.15, community involve the commit 105819c8a545 ("mmc: core: use mrq->sbc
    when sending CMD23 for RPMB"), let the usdhc to decide whether to use ACMD23 for
    RPMB. This CMD23 for RPMB need to set the bit 31 to its argument, if not, the
    RPMB write operation will return general fail.

    According to the sdhci logic, SDMA mode will disable the ACMD23, and only in
    ADMA mode, it will chose to use ACMD23 if the host support. But according to
    debug, and confirm with IC, the imx6qpdl/imx6sx/imx6sl/imx7d do not support
    the ACMD23 feature completely. These SoCs only use the 16 bit block count of
    the register 0x4 (BLOCK_ATT) as the CMD23's argument in ACMD23 mode, which
    means it will ignore the upper 16 bit of the CMD23's argument. This will block
    the reliable write operation in RPMB, because RPMB reliable write need to set
    the bit31 of the CMD23's argument. This is the hardware limitation. Due to
    imx6sl use SDMA, so for imx6qpdl/imx6sx/imx7d, it need to broke the ACMD23 for
    eMMC, SD card do not has this limitation, because SD card do not support reliable
    write.

    For imx6ul/imx6ull/imx6sll/imx7ulp/imx8, it support the ACMD23 completely, it
    change to use the 0x0 register (DS_ADDR) to put the CMD23's argument in ADMA mode.

    This patch handle 'auto-cmd23-broken' from devicetree.

    Signed-off-by: Haibo Chen

    Haibo Chen
     

24 May, 2019

1 commit


20 May, 2019

1 commit


18 Apr, 2019

24 commits