12 Oct, 2019

1 commit

  • Driver to communicate with SECO over messaging unit.
    Expose a char device to user-space so user can write messages that
    will be sent to SECO and read messages received from it.
    Data that should be exchanged with SECO through shared memory are
    indicated to this driver through ioctl calls.

    Signed-off-by: Stephane Dion
    (cherry picked from commit eb721810fdc309b6a32a7a64c7686eaa6052cdc7)

    Stephane Dion
     

21 Sep, 2019

1 commit

  • As DPU fetchunits support ITU601(limited range)/ITU601_FR(full range)
    and ITU709(limited range) YUV to RGB color space conversions, we may
    add color encoding and color range properties support for planes.
    Considering software backward compatibility, the default color encoding
    is set to ITU601 with full color range.

    Signed-off-by: Liu Ying
    (cherry picked from commit f491e24e65cb360fb0b3ce56f74d04fd80da77ab)

    Liu Ying
     

20 Sep, 2019

4 commits

  • This patch adds mulitple pixel blend modes for DPU plane.
    The modes are "None", "Pre-multiplied" and "Coverage".

    Signed-off-by: Liu Ying
    (cherry picked from commit 1259fedbcf2a54f58b47e8531a09b35cc60a43f7)

    Liu Ying
     
  • Without the new blend modes("None", "Pre-multiplied" and "Coverage")
    introduced in the below commit, the old userspace assumes alpha in
    pixel is per-premultiplied by default. So, let's support the default
    blend mode properly.

    commit 468dba6432ca ("drm: Add per-plane pixel blend mode property")

    Signed-off-by: Liu Ying
    (cherry picked from commit ebb7b4874493a8fb42de636e9421877a54399177)

    Liu Ying
     
  • Pixel blend modes represent the alpha blending equation
    selection, describing how the pixels from the current
    plane are composited with the background.

    Adds a pixel_blend_mode to drm_plane_state and a
    blend_mode_property to drm_plane, and related support
    functions.

    Defines three blend modes in drm_blend.h.

    Changes since v1:
    - Moves the blending equation into the DOC comment
    - Refines the comments of drm_plane_create_blend_mode_property to not
    enumerate the #defines, but instead the string values
    - Uses fg.* instead of pixel.* and plane_alpha instead of plane.alpha
    Changes since v2:
    - Refines the comments of drm_plane_create_blend_mode_property:
    1) Puts the descriptions (after the ":") on a new line
    2) Adds explaining why @supported_modes need PREMUL as default
    Changes since v3:
    - Refines drm_plane_create_blend_mode_property(). drm_property_add_enum()
    can calculate the index itself just fine, so no point in having the
    caller pass it in.
    - Since the current DRM assumption is that alpha is premultiplied
    as default, define DRM_MODE_BLEND_PREMULTI as 0 will be better.
    - Refines some comments.
    Changes since v4:
    - Adds comments in drm_blend.h.
    - Removes setting default value in drm_plane_create_blend_mode_property()
    as it is already in __drm_atomic_helper_plane_reset().
    - Fixes to use state->pixel_blend_mode instead of using
    plane->state->pixel_blend_mode in reset function.
    - Rebases on drm-misc-next.

    Reviewed-by: Liviu Dudau
    Signed-off-by: Lowry Li
    Signed-off-by: Ayan Kumar Halder
    Reviewed-by: Sean Paul
    Link: https://patchwork.freedesktop.org/patch/245734/
    (cherry picked from commit a5ec8332d4280500544e316f76c04a7adc02ce03)
    (cherry picked from commit 468dba6432ca97eedc2b8d6e6cc8905cd1e1f34e)

    Lowry Li
     
  • There are a lot of drivers that subclass drm_plane_state, all of them
    duplicate the code that links together the plane with plane_state.

    On top of that, drivers that enable core properties also have to
    duplicate the code for initializing the properties to their default
    values, which in all cases are the same as the defaults from core.

    Change since v1:
    - Make it consistent with the other helpers and require that both
    plane and state not be NULL, suggested by Boris Brezillon and
    Philipp Zabel.

    Reviewed-by: Laurent Pinchart
    Signed-off-by: Alexandru Gheorghe
    Reviewed-by: Philipp Zabel
    Link: https://patchwork.freedesktop.org/patch/msgid/20180804161530.12275-2-alexandru-cosmin.gheorghe@arm.com
    (cherry picked from commit 7f4de521001f4ea705d505c9f91f58d0f56a0e6d)
    (cherry picked from commit f09b192bf1316f0e65fa2dbb5ba4c82a558867ae)

    Alexandru Gheorghe
     

16 Sep, 2019

1 commit

  • The CRTC background should be full screen instead of partial
    screen, because the DRM core is likely to add configurable
    background color support in the future. We may cover the full
    screen with ConstFrame0/1, upon which builds planes. With this,
    it is easier to compute each plane's layer offset vs CRTC start
    point and all ConstFrame units can be controlled by CRTC.

    Signed-off-by: Liu Ying
    (cherry picked from commit ba18a9874cf010032413ca70f9b358399a143037)

    Liu Ying
     

12 Sep, 2019

3 commits


06 Sep, 2019

5 commits

  • [ Upstream commit 8d650cdedaabb33e85e9b7c517c0c71fcecc1de9 ]

    Neal reported incorrect use of ns_capable() from bpf hook.

    bpf_setsockopt(...TCP_CONGESTION...)
    -> tcp_set_congestion_control()
    -> ns_capable(sock_net(sk)->user_ns, CAP_NET_ADMIN)
    -> ns_capable_common()
    -> current_cred()
    -> rcu_dereference_protected(current->cred, 1)

    Accessing 'current' in bpf context makes no sense, since packets
    are processed from softirq context.

    As Neal stated : The capability check in tcp_set_congestion_control()
    was written assuming a system call context, and then was reused from
    a BPF call site.

    The fix is to add a new parameter to tcp_set_congestion_control(),
    so that the ns_capable() call is only performed under the right
    context.

    Fixes: 91b5b21c7c16 ("bpf: Add support for changing congestion control")
    Signed-off-by: Eric Dumazet
    Cc: Lawrence Brakmo
    Reported-by: Neal Cardwell
    Acked-by: Neal Cardwell
    Acked-by: Lawrence Brakmo
    Signed-off-by: David S. Miller
    Signed-off-by: Greg Kroah-Hartman
    (cherry picked from commit c60f57dfe995172c2f01e59266e3ffa3419c6cd9)

    Eric Dumazet
     
  • [ Upstream commit b617158dc096709d8600c53b6052144d12b89fab ]

    Some applications set tiny SO_SNDBUF values and expect
    TCP to just work. Recent patches to address CVE-2019-11478
    broke them in case of losses, since retransmits might
    be prevented.

    We should allow these flows to make progress.

    This patch allows the first and last skb in retransmit queue
    to be split even if memory limits are hit.

    It also adds the some room due to the fact that tcp_sendmsg()
    and tcp_sendpage() might overshoot sk_wmem_queued by about one full
    TSO skb (64KB size). Note this allowance was already present
    in stable backports for kernels < 4.15

    Note for < 4.15 backports :
    tcp_rtx_queue_tail() will probably look like :

    static inline struct sk_buff *tcp_rtx_queue_tail(const struct sock *sk)
    {
    struct sk_buff *skb = tcp_send_head(sk);

    return skb ? tcp_write_queue_prev(sk, skb) : tcp_write_queue_tail(sk);
    }

    Fixes: f070ef2ac667 ("tcp: tcp_fragment() should apply sane memory limits")
    Signed-off-by: Eric Dumazet
    Reported-by: Andrew Prout
    Tested-by: Andrew Prout
    Tested-by: Jonathan Lemon
    Tested-by: Michal Kubecek
    Acked-by: Neal Cardwell
    Acked-by: Yuchung Cheng
    Acked-by: Christoph Paasch
    Cc: Jonathan Looney
    Signed-off-by: David S. Miller
    Signed-off-by: Greg Kroah-Hartman
    (cherry picked from commit 6323c238bb4374d1477348cfbd5854f2bebe9a21)

    Eric Dumazet
     
  • 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
     
  • commit f070ef2ac66716357066b683fb0baf55f8191a2e upstream.

    Jonathan Looney reported that a malicious peer can force a sender
    to fragment its retransmit queue into tiny skbs, inflating memory
    usage and/or overflow 32bit counters.

    TCP allows an application to queue up to sk_sndbuf bytes,
    so we need to give some allowance for non malicious splitting
    of retransmit queue.

    A new SNMP counter is added to monitor how many times TCP
    did not allow to split an skb if the allowance was exceeded.

    Note that this counter might increase in the case applications
    use SO_SNDBUF socket option to lower sk_sndbuf.

    CVE-2019-11478 : tcp_fragment, prevent fragmenting a packet when the
    socket is already using more than half the allowed space

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

    Eric Dumazet
     
  • commit 3b4929f65b0d8249f19a50245cd88ed1a2f78cff upstream.

    Jonathan Looney reported that TCP can trigger the following crash
    in tcp_shifted_skb() :

    BUG_ON(tcp_skb_pcount(skb) < pcount);

    This can happen if the remote peer has advertized the smallest
    MSS that linux TCP accepts : 48

    An skb can hold 17 fragments, and each fragment can hold 32KB
    on x86, or 64KB on PowerPC.

    This means that the 16bit witdh of TCP_SKB_CB(skb)->tcp_gso_segs
    can overflow.

    Note that tcp_sendmsg() builds skbs with less than 64KB
    of payload, so this problem needs SACK to be enabled.
    SACK blocks allow TCP to coalesce multiple skbs in the retransmit
    queue, thus filling the 17 fragments to maximal capacity.

    CVE-2019-11477 -- u16 overflow of TCP_SKB_CB(skb)->tcp_gso_segs

    Fixes: 832d11c5cd07 ("tcp: Try to restore large SKBs while SACK processing")
    Signed-off-by: Eric Dumazet
    Reported-by: Jonathan Looney
    Acked-by: Neal Cardwell
    Reviewed-by: Tyler Hicks
    Cc: Yuchung Cheng
    Cc: Bruce Curtis
    Cc: Jonathan Lemon
    Signed-off-by: David S. Miller
    Signed-off-by: Greg Kroah-Hartman
    (cherry picked from commit c09be31461ed140976c60a87364415454a2c3d42)

    Eric Dumazet
     

05 Sep, 2019

1 commit

  • Patch moves some decoding functions from driver/usb/dwc3/debug.h driver
    to driver/usb/common/debug.c file. These moved functions include:
    dwc3_decode_get_status
    dwc3_decode_set_clear_feature
    dwc3_decode_set_address
    dwc3_decode_get_set_descriptor
    dwc3_decode_get_configuration
    dwc3_decode_set_configuration
    dwc3_decode_get_intf
    dwc3_decode_set_intf
    dwc3_decode_synch_frame
    dwc3_decode_set_sel
    dwc3_decode_set_isoch_delay
    dwc3_decode_ctrl

    These functions are used also in inroduced cdns3 driver.

    All functions prefixes were changed from dwc3 to usb.
    Also, function's parameters has been extended according to the name
    of fields in standard SETUP packet.
    Additionally, patch adds usb_decode_ctrl function to
    include/linux/usb/ch9.h file.

    Signed-off-by: Pawel Laszczak
    (cherry picked from commit 046b47df488c6956b9a4420e684274cc0ca0fb70)
    Signed-off-by: Leonard Crestez
    Reviewed-by: Peter Chen

    Pawel Laszczak
     

06 Aug, 2019

1 commit


29 Jul, 2019

1 commit


25 Jul, 2019

3 commits

  • Macros 'inline' and '__gnu_inline' used to be defined in compiler-gcc.h,
    which was (and is) included entirely in (__KERNEL__ && !__ASSEMBLY__).
    Commit 815f0ddb346c ("include/linux/compiler*.h: make compiler-*.h mutually
    exclusive") had those macros exposed to userspace, unintentionally.

    Then commit a3f8a30f3f00 ("Compiler Attributes: use feature checks
    instead of version checks") moved '__gnu_inline' back into
    (__KERNEL__ && !__ASSEMBLY__) and 'inline' was left behind. Since 'inline'
    depends on '__gnu_inline', compiling error showing "unknown type name
    ‘__gnu_inline’" will pop up, if userspace somehow includes
    .

    Other macros like __must_check, notrace, etc. are in a similar situation.
    So just move all these macros back into (__KERNEL__ && !__ASSEMBLY__).

    Note:
    1. This patch only affects what userspace sees.
    2. __must_check (when !CONFIG_ENABLE_MUST_CHECK) and noinline_for_stack
    were once defined in __KERNEL__ only, but we believe that they can
    be put into !__ASSEMBLY__ too.

    Acked-by: Nick Desaulniers
    Signed-off-by: Xiaozhou Liu
    Signed-off-by: Miguel Ojeda

    Xiaozhou Liu
     
  • Remove clocks that dont exist in imx8qxp.
    Change clock names to match HW.

    Signed-off-by: Ranjani Vaidyanathan

    Ranjani Vaidyanathan
     
  • Remove clocks that dont exist in imx8qxp.
    Change clock names to match HW.

    Signed-off-by: Ranjani Vaidyanathan

    Ranjani Vaidyanathan
     

19 Jul, 2019

1 commit


17 Jul, 2019

1 commit


11 Jul, 2019

1 commit


27 Jun, 2019

2 commits

  • 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
     
  • Add i.MX8MN clock and pin definition.

    Signed-off-by: Bai Ping
    Signed-off-by: Anson Huang
    Reviewed-by: Abel Vesa
    Reviewed-by: Bai Ping

    Bai Ping
     

21 Jun, 2019

1 commit


10 Jun, 2019

1 commit

  • In order to support the new ASRC in i.MX815, we update the
    user api file mxc_asrc.h.

    The reason is that the new ASRC support more sample width, and
    support endianness, sign, float format, iec958 format setting,
    All these type can be expressed by snd_pcm_format_t type.

    So we use the in(out)put_format to instead the in(out)put_word_width.

    Signed-off-by: Shengjiu Wang
    Reviewed-by: Daniel Baluta
    Reviewed-by: Viorel Suman
    (cherry picked from commit b95c32c4d4b51e3e55e1e28269a0e8bce0a04f98)

    Shengjiu Wang
     

04 Jun, 2019

1 commit


31 May, 2019

1 commit

  • Instead of just raising irq0 for all the cores, we mask the irq0 for all the
    non-target cores, this way waking up only the core we want. All of this
    is done now in TF-A.

    Also, since this new workaround doesn't need the IOMUX_GPR1 register here
    in kernel, the IOMUX_GPR reg entry inside the gic dts node can be removed.

    In order for this to work, the following commit is needed in TF-A:
    0e91ff59720d0756 ("MLK-21399 plat: imx8mq: gpc: Workaround for ERR11171")

    Signed-off-by: Abel Vesa
    Reviewed-by: Leonard Crestez

    Abel Vesa
     

20 May, 2019

1 commit


15 May, 2019

1 commit


10 May, 2019

1 commit

  • As suggested by the design team, there is rigorous timing requirement
    to address TKT320590, that is, we need to turn Tcon(s) from bypass mode
    into operation mode as soon as the first dumb frame is generated by DPU.
    When dual stream is used, we should look at the first dumb frame generated
    by the master FrameGen. If we cannot ensure the timing requirement, say
    the Tcon mode switching takes place after the second frame is generated
    by DPU, the hardware could run into malfunction sometimes. Based on
    stress tests, the content shadow load done event for the first time we call
    ->atomic_flush() may not come after the CRTC enablement in the single
    stream case and it looks like display data is not generated to the
    down-stream encoder(hence, black screen). This patch tunes enablement
    sequence to correctly switch Tcon mode, according to the design team's
    suggestions. During the switching, we don't relinquish CPU to ensure the
    sequence is straightforward to meet the timing requirement. As we cannot
    sleep during the switching, we take the pixel link enablement/disablement
    operations(wrapped by a mutex in RPC call) out of framegen_enable/disable()
    functions and put them at appropriate place. This introduces additional
    sequence modifications but should be safe.

    Signed-off-by: Liu Ying

    Liu Ying
     

30 Apr, 2019

1 commit


29 Apr, 2019

3 commits


26 Apr, 2019

2 commits


25 Apr, 2019

1 commit