summaryrefslogtreecommitdiff
path: root/include
AgeCommit message (Collapse)Author
2020-01-23MLK-23258-3 dts: Fix PCIE suspend/resume issueRanjani Vaidyanathan
Fix the parent-child power domain dependency to handle different PCIE usecases. Signed-off-by: Ranjani Vaidyanathan <ranjani.vaidyanathan@nxp.com>
2019-12-23LF-580 dt-bindings: imx: correct i2c4/uart1 clocks IDFugang Duan
Current i2c4/uart1 clocks ID have conflict with pwm2/pwm3, correct them. Reviewed-by: Anson Huang <Anson.Huang@nxp.com> Signed-off-by: Fugang Duan <fugang.duan@nxp.com>
2019-12-17MLK-23116-11 gpu: imx: imx8_dprc: Support hard argument for dprc_disable()Liu Ying
As we would support some non-native prefetch engine pixel formats soon later with some coming patches, hot-switch from native pixel formats to non-native ones(on-the-fly PRG bypass) is inevitable. Basically, dprc_disable() is called to do the switch. If a follow-up modeset is done to enable the prefetch engine again, we see prefetch engine fail-over issue. So, a reset is needed in dprc_disable() in the need_modeset case. It appears that PRG reset is enough. Reviewed-by: Sandor Yu <Sandor.yu@nxp.com> Signed-off-by: Liu Ying <victor.liu@nxp.com> (cherry picked from commit 52450396e492b555cd965b046e8982c77cdcafee) (cherry picked from commit 8045c5046812a81e530d123d2ee78ef2c9376b8b)
2019-12-17MLK-23116-10 gpu: imx: imx8_dprc: Add helper dprc_is_repeat_en()Liu Ying
This patch adds helper dprc_is_repeat_en() support so that callers may know whether DPRC REPEAT_EN bit is enabled or not. Reviewed-by: Sandor Yu <Sandor.yu@nxp.com> Signed-off-by: Liu Ying <victor.liu@nxp.com> (cherry picked from commit 029d6ec7d4e73f4c2876d4b0d3c2d1504bb9293a) (cherry picked from commit cbcac4fa968da56d2cedae4e2186659d0706b6cd)
2019-12-17MLK-23116-2 gpu: imx: imx8_dprc: Add helper ↵Liu Ying
dprc_gasket_shadow_enable/disable() support The start/aux_start arguments of dprc_configure() are not clearly defined. Currently, they would impact both DPRC SYSTEM_CTRL0 register and PRG SHADOW_EN bit in PRG_CTRL register. However, we need to control the PRG SHADOW_EN bit separately from the DPRC register. So, this patch adds helper dprc_gasket_shadow_enable/disable() support so that caller may enable or disable DPRC's gasket(PRG) SHADOW_EN bit only. Reviewed-by: Sandor Yu <Sandor.yu@nxp.com> Signed-off-by: Liu Ying <victor.liu@nxp.com> (cherry picked from commit 830c4d99445aa9620e28929aa2323c07f859c81d) (cherry picked from commit 34505c98243c85bf2b1d0a6ef70092f008887004)
2019-12-17MLK-23116-1 gpu: imx: imx8_prg: Add helper prg_shadow_disable() supportLiu Ying
This patch adds helper prg_shadow_disable() support so that callers may disable PRG SHADOW_EN bit. Reviewed-by: Sandor Yu <Sandor.yu@nxp.com> Signed-off-by: Liu Ying <victor.liu@nxp.com> (cherry picked from commit d0c6de11268ced25dd7e33111914bdd76c70ab84) (cherry picked from commit c346809d39662dbe43d8a23635a60a439949774b)
2019-12-17MLK-23107-1 gpu: imx: imx8_dprc: Add helper dprc_disable_repeat_en()Liu Ying
This patch adds helper dprc_disable_repeat_en() so that callers may disable DPRC repeat_en. Reviewed-by: Sandor Yu <Sandor.yu@nxp.com> Signed-off-by: Liu Ying <victor.liu@nxp.com> (cherry picked from commit 618a40a421987c31335485ba02fbc5476c224e4b) (cherry picked from commit ca93dcd5bb678716d4e9f30c228b796ad7136062)
2019-12-17MLK-23102-2 gpu: imx: dpu: fetchunit: Remove pin-off operationsLiu Ying
No one is using pin-off operations, so let's remove them. Reviewed-by: Sandor Yu <Sandor.yu@nxp.com> Signed-off-by: Liu Ying <victor.liu@nxp.com> (cherry picked from commit 24d75f3118895fbbec9e5b5e6e42d54d20db27f1) (cherry picked from commit 7a827f219fe5c9e8dc33c0cedf8e77e2c4060a19)
2019-12-05SHE-17 soc: imx8: SECO MU driverStephane Dion
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 <stephane.dion_1@nxp.com> (cherry picked from commit eb721810fdc309b6a32a7a64c7686eaa6052cdc7) (cherry picked from commit db41bf52c2edf7c0936686d806eb4b2373b385a0)
2019-12-05SSI-87: soc: imx: secvio: Add support for SNVS secvio and tamper via SCFWFranck LENORMAND
The driver register an IRQ handle to SCU for security violation interrupt. When an interruption is fired, the driver inform the user. Signed-off-by: Franck LENORMAND <franck.lenormand@nxp.com>
2019-12-05SSI-87: soc:imx: Add sc_seco_secvio_dgo_config to headerFranck LENORMAND
The function sc_seco_secvio_dgo_config is not declared in the header. Signed-off-by: Franck LENORMAND <franck.lenormand@nxp.com>
2019-11-21MLK-22998-3 soc:imx: Update SCFW APIRanjani Vaidyanathan
Sync SCFW API to commit 6dcd0242ae Signed-off-by: Ranjani Vaidyanathan <ranjani.vaidyanathan@nxp.com>
2019-11-21MLK-22998-1 dt-bindings: Update SCFW APIRanjani Vaidyanathan
Sync SCFW API to commit 6dcd0242ae Signed-off-by: Ranjani Vaidyanathan <ranjani.vaidyanathan@nxp.com>
2019-11-08MLK-22934-2: clk: imx8qxp: Remove unused audio clockShengjiu Wang
Remove below audio clocks from clk tree. IMX8QXP_ACM_AUD_CLK0_CLK IMX8QXP_ACM_AUD_CLK1_CLK, IMX8QXP_ACM_ASRC0_MUX_CLK_SEL IMX8QXP_ACM_ASRC0_MUX_CLK_CLK IMX8QXP_ACM_ASRC1_MUX_CLK_CLK IMX8QXP_ACM_ASRC1_MUX_CLK_SEL There are no these clocks physically. which are added wrongly before, so remove them. Signed-off-by: Shengjiu Wang <shengjiu.wang@nxp.com> Reviewed-by: Viorel Suman <viorel.suman@nxp.com>
2019-11-08MLK-22934-1: clk: imx8qm: Remove unused audio clockShengjiu Wang
Remove below audio clocks from clk tree. IMX8QM_ACM_AUD_CLK0_CLK IMX8QM_ACM_AUD_CLK1_CLK, IMX8QM_ACM_ASRC1_MUX_CLK_CLK IMX8QM_ACM_ASRC1_MUX_CLK_SEL There are no these clocks physically. which are added wrongly before, so remove them. Signed-off-by: Shengjiu Wang <shengjiu.wang@nxp.com> Reviewed-by: Viorel Suman <viorel.suman@nxp.com>
2019-10-24MLK-22824-1: mfd: pca9450: add pca9450 mfd driverRobin Gong
Add new pmic pca9450 driver for i.mx8mn-evk board. Signed-off-by: John Lee <john.lee@nxp.com> Signed-off-by: Robin Gong <yibin.gong@nxp.com> Reviewed-by: Anson Huang <anson.huang@nxp.com>
2019-09-21MLK-22649 drm/imx: dpu: plane: Add color properties supportLiu Ying
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 <victor.liu@nxp.com> (cherry picked from commit f491e24e65cb360fb0b3ce56f74d04fd80da77ab)
2019-09-20MLK-22600-5 drm/imx: dpu: plane: Support multiple pixel blend modesLiu Ying
This patch adds mulitple pixel blend modes for DPU plane. The modes are "None", "Pre-multiplied" and "Coverage". Signed-off-by: Liu Ying <victor.liu@nxp.com> (cherry picked from commit 1259fedbcf2a54f58b47e8531a09b35cc60a43f7)
2019-09-20MLK-22600-1 drm/imx: dpu: kms: Support proper default blend modeLiu 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 <victor.liu@nxp.com> (cherry picked from commit ebb7b4874493a8fb42de636e9421877a54399177)
2019-09-17drm: Add per-plane pixel blend mode propertyLowry Li
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 <liviu.dudau@arm.com> Signed-off-by: Lowry Li <lowry.li@arm.com> Signed-off-by: Ayan Kumar Halder <ayan.halder@arm.com> Reviewed-by: Sean Paul <seanpaul@chromium.org> Link: https://patchwork.freedesktop.org/patch/245734/ (cherry picked from commit a5ec8332d4280500544e316f76c04a7adc02ce03)
2019-09-17drm: Don't pass the index to drm_property_add_enum()Ville Syrjälä
drm_property_add_enum() can calculate the index itself just fine, so no point in having the caller pass it in. Cc: Patrik Jakobsson <patrik.r.jakobsson@gmail.com> Cc: Ben Skeggs <bskeggs@redhat.com> Cc: nouveau@lists.freedesktop.org Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180316190420.26734-1-ville.syrjala@linux.intel.com Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> (cherry picked from commit 30e9db6d046ba667070e5a011a13951830d60a6e)
2019-09-17Revert "drm: Use a flexible array member for blob property data"Ville Syrjälä
Using a flexible array for the blob data was a mistake by me. It forces all users of the blob data to cast blob->data to something else. void* is clearly superior so let's go back to the original scheme. Not a clean revert as the code has moved. This reverts commit d63f5e6bf6f2a1573ea39c9937cdf5ab0b3a4b77. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180223192506.29992-1-ville.syrjala@linux.intel.com Reviewed-by: Shashank Sharma <shashank.sharma@intel.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> (cherry picked from commit 9c60583c0b0fd6f3a5b61fda3eb604ce218b9d25)
2019-09-17drm: Make property flags u32Ville Syrjälä
The property flags are part of the uabi and we have 32 bits for them. Pass them around as u32 internally as well, instead of a signed int. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180306164849.2862-5-ville.syrjala@linux.intel.com Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> (cherry picked from commit 51abc97658b954d357f6107885a3b069f497c7ff)
2019-09-17drm/atomic: Add __drm_atomic_helper_plane_resetAlexandru Gheorghe
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 <laurent.pinchart@ideasonboard.com> Signed-off-by: Alexandru Gheorghe <alexandru-cosmin.gheorghe@arm.com> Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de> Link: https://patchwork.freedesktop.org/patch/msgid/20180804161530.12275-2-alexandru-cosmin.gheorghe@arm.com (cherry picked from commit 7f4de521001f4ea705d505c9f91f58d0f56a0e6d)
2019-09-17drm: Add optional COLOR_ENCODING and COLOR_RANGE properties to drm_planeJyri Sarha
Add a standard optional properties to support different non RGB color encodings in DRM planes. COLOR_ENCODING select the supported non RGB color encoding, for instance ITU-R BT.709 YCbCr. COLOR_RANGE selects the value ranges within the selected color encoding. The properties are stored to drm_plane object to allow different set of supported encoding for different planes on the device. v2: Add/fix kerneldocs, verify bitmasks (danvet) Cc: Harry Wentland <harry.wentland@amd.com> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: Daniel Stone <daniel@fooishbar.org> Cc: Russell King - ARM Linux <linux@armlinux.org.uk> Cc: Ilia Mirkin <imirkin@alum.mit.edu> Cc: Hans Verkuil <hverkuil@xs4all.nl> Cc: Uma Shankar <uma.shankar@intel.com> Cc: Shashank Sharma <shashank.sharma@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Jyri Sarha <jsarha@ti.com> [vsyrjala v2: Add/fix kerneldocs, verify bitmasks] Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180219202823.10508-1-ville.syrjala@linux.intel.com Acked-by: Harry Wentland <harry.wentland@amd.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> (cherry picked from commit 80f690e9e3a60f628de61748be4dd2fd6baf5cc8)
2019-09-17drm/blend: Add a generic alpha propertyMaxime Ripard
Some drivers duplicate the logic to create a property to store a per-plane alpha. This is especially useful if we ever want to support extra protocols for Wayland like: https://lists.freedesktop.org/archives/wayland-devel/2017-August/034741.html Let's create a helper in order to move that to the core. Acked-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Acked-by: Sean Paul <seanpaul@chromium.org> Reviewed-by: Boris Brezillon <boris.brezillon@bootlin.com> Reviewed-by: Eric Anholt <eric@anholt.net> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com> Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com> Link: https://patchwork.freedesktop.org/patch/msgid/6e1ce0db78fcfc407e94913c64819e65109d034d.1523432341.git-series.maxime.ripard@bootlin.com (cherry picked from commit ae0e28265e216dad11d4cbde42fc15e92919af78)
2019-09-16MLK-22599 drm/imx: dpu: kms: Support full screen CRTC backgroundLiu Ying
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 <victor.liu@nxp.com> (cherry picked from commit ba18a9874cf010032413ca70f9b358399a143037)
2019-09-06tcp: be more careful in tcp_fragment()Eric Dumazet
commit b617158dc096709d8600c53b6052144d12b89fab upstream. 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 <edumazet@google.com> Reported-by: Andrew Prout <aprout@ll.mit.edu> Tested-by: Andrew Prout <aprout@ll.mit.edu> Tested-by: Jonathan Lemon <jonathan.lemon@gmail.com> Tested-by: Michal Kubecek <mkubecek@suse.cz> Acked-by: Neal Cardwell <ncardwell@google.com> Acked-by: Yuchung Cheng <ycheng@google.com> Acked-by: Christoph Paasch <cpaasch@apple.com> Cc: Jonathan Looney <jtl@netflix.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Matthieu Baerts <matthieu.baerts@tessares.net> Signed-off-by: Sasha Levin <sashal@kernel.org> (cherry picked from commit 8c3088f895a0cfdf630973a9cd32f5e085eb973c)
2019-09-06tcp: fix tcp_set_congestion_control() use from bpf hookEric Dumazet
[ 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 <edumazet@google.com> Cc: Lawrence Brakmo <brakmo@fb.com> Reported-by: Neal Cardwell <ncardwell@google.com> Acked-by: Neal Cardwell <ncardwell@google.com> Acked-by: Lawrence Brakmo <brakmo@fb.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> (cherry picked from commit adcac7370d7d9c6c8f58c590fff117d95c65fb61)
2019-09-06tcp: add tcp_min_snd_mss sysctlEric 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 <edumazet@google.com> Suggested-by: Jonathan Looney <jtl@netflix.com> Acked-by: Neal Cardwell <ncardwell@google.com> Cc: Yuchung Cheng <ycheng@google.com> Cc: Tyler Hicks <tyhicks@canonical.com> Cc: Bruce Curtis <brucec@netflix.com> Cc: Jonathan Lemon <jonathan.lemon@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> (cherry picked from commit cd6f35b8421ff20365ff711c0ac7647fd70e9af7)
2019-09-06tcp: tcp_fragment() should apply sane memory limitsEric 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 <edumazet@google.com> Reported-by: Jonathan Looney <jtl@netflix.com> Acked-by: Neal Cardwell <ncardwell@google.com> Acked-by: Yuchung Cheng <ycheng@google.com> Reviewed-by: Tyler Hicks <tyhicks@canonical.com> Cc: Bruce Curtis <brucec@netflix.com> Cc: Jonathan Lemon <jonathan.lemon@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> (cherry picked from commit 9daf226ff92679d09aeca1b5c1240e3607153336)
2019-09-06tcp: limit payload size of sacked skbsEric 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 Backport notes, provided by Joao Martins <joao.m.martins@oracle.com> v4.15 or since commit 737ff314563 ("tcp: use sequence distance to detect reordering") had switched from the packet-based FACK tracking and switched to sequence-based. v4.14 and older still have the old logic and hence on tcp_skb_shift_data() needs to retain its original logic and have @fack_count in sync. In other words, we keep the increment of pcount with tcp_skb_pcount(skb) to later used that to update fack_count. To make it more explicit we track the new skb that gets incremented to pcount in @next_pcount, and we get to avoid the constant invocation of tcp_skb_pcount(skb) all together. Fixes: 832d11c5cd07 ("tcp: Try to restore large SKBs while SACK processing") Signed-off-by: Eric Dumazet <edumazet@google.com> Reported-by: Jonathan Looney <jtl@netflix.com> Acked-by: Neal Cardwell <ncardwell@google.com> Reviewed-by: Tyler Hicks <tyhicks@canonical.com> Cc: Yuchung Cheng <ycheng@google.com> Cc: Bruce Curtis <brucec@netflix.com> Cc: Jonathan Lemon <jonathan.lemon@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> (cherry picked from commit d632920554c5aec81d8a79c23dac07efcbabbd54)
2019-09-06tcp: clear icsk_backoff in tcp_write_queue_purge()Eric Dumazet
[ Upstream commit 04c03114be82194d4a4858d41dba8e286ad1787c ] soukjin bae reported a crash in tcp_v4_err() handling ICMP_DEST_UNREACH after tcp_write_queue_head(sk) returned a NULL pointer. Current logic should have prevented this : if (seq != tp->snd_una || !icsk->icsk_retransmits || !icsk->icsk_backoff || fastopen) break; Problem is the write queue might have been purged and icsk_backoff has not been cleared. Signed-off-by: Eric Dumazet <edumazet@google.com> Reported-by: soukjin bae <soukjin.bae@samsung.com> Acked-by: Neal Cardwell <ncardwell@google.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> (cherry picked from commit 3a493b762f31fc0c571051cdfb0d80f49498e5fd)
2019-08-06MLK-22025-1 usb: chipidea: phy enter low power mode when host suspendLi Jun
On some imx host, if USB PHY is active when bus suspended, host may have problem on taking over resume signal of remote wakeup from usb device, resolve this by making PHY enter low power mode right after bus suspended. Acked-by: Peter Chen <peter.chen@nxp.com> Signed-off-by: Li Jun <jun.li@nxp.com> (cherry picked from commit 704c710f6d0267558c7443a7afbf63767b623947)
2019-07-17MLK-22265 dt-bindings: pinctrl: imx8mm: Update head fileAnson Huang
Update i.MX8MM pinctrl head file according to reference manual Rev.1, 03/2019. Signed-off-by: Anson Huang <Anson.Huang@nxp.com> Reviewed-by: Jacky Bai <ping.bai@nxp.com>
2019-06-25MLK-21963-1 reset: Add driver for dispmix resetFancy Fang
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 <chen.fang@nxp.com>
2019-06-21usb: common: change debug message APIPawel Laszczak
It ported from below patch, and change for v4.14. https://www.spinics.net/lists/linux-usb/msg177137.html Signed-off-by: Pawel Laszczak <pawell@cadence.com> Signed-off-by: Peter Chen <peter.chen@nxp.com>
2019-06-20MLK-21399 irqchip: gic-v3: Rework the ERR11171 workaroundAbel Vesa
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 <abel.vesa@nxp.com> Reviewed-by: Leonard Crestez <leonard.crestez@nxp.com>
2019-06-06MLK-21940-1: ASoC: fsl_asrc: Update mxc_asrc uapiShengjiu Wang
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 <shengjiu.wang@nxp.com> Reviewed-by: Daniel Baluta <daniel.baluta@nxp.com> Reviewed-by: Viorel Suman <viorel.suman@nxp.com>
2019-06-04MLK-21700-3 imx8mm: Switch to imx8m_clk_compositeLeonard Crestez
This is a large change but realigns us with upstream is useful and make git diff useful. This was already done on imx8mq after that SOC was upstreamed. Mixing dts and driver changes is intentional because changes only compile together. Signed-off-by: Leonard Crestez <leonard.crestez@nxp.com> Reviewed-by: Abel Vesa <abel.vesa@nxp.com> (cherry picked from commit 29845d2ebf6708ef87213328a4ce0f29cef7722a)
2019-05-27MLK-21823-1 dt-bindings: add i.MX8MN clock and pin headerBai Ping
Add i.MX8MN clock and pin definition. Signed-off-by: Bai Ping <ping.bai@nxp.com> Signed-off-by: Anson Huang <Anson.Huang@nxp.com> Reviewed-by: Abel Vesa <abel.vesa@nxp.com> Reviewed-by: Bai Ping <ping.bai@nxp.com>
2019-05-20MLK-21770: media: v4l: Add packed YUV444 24bpp pixel formatMirela Rabulea
The added format is V4L2_PIX_FMT_YUV24, this is a packed YUV 4:4:4 format, with 8 bits for each component, 24 bits per sample. Signed-off-by: Mirela Rabulea <mirela.rabulea@nxp.com> Reviewed-by: Laurentiu Palcu <laurentiu.palcu@nxp.com> Acked-by: Leonard Crestez <leonard.crestez@nxp.com>
2019-05-14MLK-21526: Revert "block: Unexport elv_register_queue() and ↵Mircea Pop
elv_unregister_queue()" This reverts commit 83d016ac86428dbca8a62d3e4fdc29e3ea39e535. Reverting the patch will solve the issue introduced by MLK-18870 fix The fix is adding the following patch on 4.14 bsp kernel 83d016ac86428("block: Unexport elv_register_queue() and elv_unregister_queue()") The upstream patch that remove the correlation with export elv_register_queue() is not applied on IMX kernel BSP. c100ec49fdd22("dm: fix incomplete request_queue initialization") Having missing patch a compilation issue will be generated if DM is enabled Decision not to cherry-pick the c100ec49fdd22("dm:fix incomplete request_queue initialization") from upstream because the patch adds new DM Crypt functionalities and to revoke the patch that remove the export. Signed-off-by: Mircea Pop <mircea.pop@nxp.com>
2019-05-14crypto: drbg - move to generic async completionGilad Ben-Yossef
DRBG is starting an async. crypto op and waiting for it complete. Move it over to generic code doing the same. The code now also passes CRYPTO_TFM_REQ_MAY_SLEEP flag indicating crypto request memory allocation may use GFP_KERNEL which should be perfectly fine as the code is obviously sleeping for the completion of the request any way. Signed-off-by: Gilad Ben-Yossef <gilad@benyossef.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> (cherry picked from commit 85a2dea4bdbfa7565818ca094d08e838cf62da77)
2019-05-14crypto: algif - move to generic async completionGilad Ben-Yossef
algif starts several async crypto ops and waits for their completion. Move it over to generic code doing the same. Signed-off-by: Gilad Ben-Yossef <gilad@benyossef.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> (cherry picked from commit 2c3f8b162106a7d12097d02eb22459f57fab8247)
2019-05-14crypto: introduce crypto wait for async opGilad Ben-Yossef
Invoking a possibly async. crypto op and waiting for completion while correctly handling backlog processing is a common task in the crypto API implementation and outside users of it. This patch adds a generic implementation for doing so in preparation for using it across the board instead of hand rolled versions. Signed-off-by: Gilad Ben-Yossef <gilad@benyossef.com> CC: Eric Biggers <ebiggers3@gmail.com> CC: Jonathan Cameron <Jonathan.Cameron@huawei.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> (cherry picked from commit ada69a1639eca54ff74d839a6513c43db8d57d70)
2019-05-10MLK-21656-2 drm/imx: dpu: crtc: Tune enablement sequence to correctly switch ↵Liu Ying
Tcon mode 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 <victor.liu@nxp.com> (cherry picked from commit ec323921dc2173128f071d0238e6439f5536aca1)
2019-05-07MLK-21633-1: mtd: hyperbus: change the hbmc ops functionsHan Xu
add the prepare/unprepare functions in hbmc ops Signed-off-by: Han Xu <han.xu@nxp.com>
2019-05-07mtd: Add support for HyperBus memory devicesVignesh Raghavendra
Cypress' HyperBus is Low Signal Count, High Performance Double Data Rate Bus interface between a host system master and one or more slave interfaces. HyperBus is used to connect microprocessor, microcontroller, or ASIC devices with random access NOR flash memory (called HyperFlash) or self refresh DRAM (called HyperRAM). Its a 8-bit data bus (DQ[7:0]) with Read-Write Data Strobe (RWDS) signal and either Single-ended clock(3.0V parts) or Differential clock (1.8V parts). It uses ChipSelect lines to select b/w multiple slaves. At bus level, it follows a separate protocol described in HyperBus specification[1]. HyperFlash follows CFI AMD/Fujitsu Extended Command Set (0x0002) similar to that of existing parallel NORs. Since HyperBus is x8 DDR bus, its equivalent to x16 parallel NOR flash wrt bits per clock cycle. But HyperBus operates at >166MHz frequencies. HyperRAM provides direct random read/write access to flash memory array. But, HyperBus memory controllers seem to abstract implementation details and expose a simple MMIO interface to access connected flash. Add support for registering HyperFlash devices with MTD framework. MTD maps framework along with CFI chip support framework are used to support communicating with flash. Framework is modelled along the lines of spi-nor framework. HyperBus memory controller (HBMC) drivers calls hyperbus_register_device() to register a single HyperFlash device. HyperFlash core parses MMIO access information from DT, sets up the map_info struct, probes CFI flash and registers it with MTD framework. Some HBMC masters need calibration/training sequence[3] to be carried out, in order for DLL inside the controller to lock, by reading a known string/pattern. This is done by repeatedly reading CFI Query Identification String. Calibration needs to be done before trying to detect flash as part of CFI flash probe. HyperRAM is not supported at the moment. HyperBus specification can be found at[1] HyperFlash datasheet can be found at[2] [1] https://www.cypress.com/file/213356/download [2] https://www.cypress.com/file/213346/download [3] http://www.ti.com/lit/ug/spruid7b/spruid7b.pdf Table 12-5741. HyperFlash Access Sequence Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
2019-05-07mtd: cfi_cmdset_0002: Add support for polling status registerVignesh Raghavendra
HyperFlash devices are compliant with CFI AMD/Fujitsu Extended Command Set(0x0002) for flash operations, therefore drivers/mtd/chips/cfi_cmdset_0002.c can be used as is. But these devices do not support DQ polling method of determining chip ready/good status. These flashes provide Status Register whose bits can be polled to know status of flash operation. Cypress HyperFlash datasheet here[1], talks about CFI Amd/Fujitsu Extended Query version 1.5. Bit 0 of "Software Features supported" field of CFI Primary Vendor-Specific Extended Query table indicates presence/absence of status register and Bit 1 indicates whether or not DQ polling is supported. Using these bits, its possible to determine whether flash supports DQ polling or need to use Status Register. Add support for polling Status Register to know device ready/status of erase/write operations when DQ polling is not supported. Print error messages on erase/program failure by looking at related Status Register bits. [1] https://www.cypress.com/file/213346/download Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>