16 Nov, 2022

1 commit

  • When a plane transitions from a video tiled format (G1/G2) to linear,
    without performing a disable/enable sequence, the screen will go
    green because the scaler for that specific channel FREEZES.

    The problem happens because we don't flag the DTRC channel as 'not
    running' when we switch it to bypass mode. And also because, when DPR
    is set up, it checks to see whether the DTRC channel is running or not
    in order to properly set the addresses. But, since it finds the channel
    running, it continues to use the internal DTRC ARIDs, instead of
    using the actual buffer location in DDR. Hence DPR fails with an AXI
    read error, which leads to scaler freezing.

    The solution is to properly flag the DTRC channel when switching to
    bypass mode and move the dcss_dpr_addr_set() after the
    dcss_plane_set_dtrc_base() is called, so that the DTRC channel is
    already flagged as "not running" by the time we set the DPR addresses.

    Signed-off-by: Laurentiu Palcu
    Reviewed-by: Liu Ying
    Acked-by: Jason Liu

    Laurentiu Palcu
     

15 Nov, 2022

1 commit

  • hsm rng and kernel hwrng requires
    ele rng must be started before access.

    earlier start rng was part of kernel hwrng initialization.
    hence to make the common implementation,
    moving start rng code to ele mu probe.

    - moved ele_get_trng_state to ele_mu_probe.
    - moved ele_start_rng to ele_mu_probe.

    Signed-off-by: Gaurav Jain
    Reviewed-by: Pankaj Gupta
    Reviewed-by: Varun Sethi

    Gaurav Jain
     

11 Nov, 2022

1 commit

  • Pointer variable 'struct ele_mu_device_ctx *waiting_rsp_dev',
    member to the structure 'ele_mu_priv', is used to hold the
    device context waiting for the response.

    This pointer variable continue to hold the stale context.

    It is now cleaned-up to point to NULL, once response is received.

    Signed-off-by: Pankaj Gupta
    Reviewed-by: Gaurav Jain
    Reviewed-by: Rahul Kumar Yadav

    Pankaj Gupta
     

10 Nov, 2022

2 commits

  • When running the 'kms_atomic_transition' IGT test suite, the following
    messages appear in the dmesg:

    [drm] [CRTC:38:crtc-0] dpu_crtc_atomic_flush: wait for content shdld done timeout
    [drm] [CRTC:38:crtc-0] dpu_crtc_atomic_flush: FrameGen requests to read empty FIFO

    It turns out that the test tries to perform various plane transitions on
    the same CRTC which can lead to 2 planes having the same source module.

    One example of sequence that leads to the problem is the following:
    1. Perform an atomic update on planes 1 and 2. The source modules
    assigned will be fetchlayer-0x00 and fetchwarp-0x02. Planes 0 and
    3 are assigned no FB;
    2. Perform an atomic update on planes 0 an 1. The source module for the
    plane-0 will be fetchlayer-0x00. However, since current_source for
    plane-1 is already fetchlayer-0x00, we end up reusing it without
    checking first whether it was used already or not. Hence both
    plane-0 and plane-1 will use the same fetchlayer-0x00 module...

    So, to fix this, move the current source checks to a separate function
    where we also check whether the source was not already used for a
    previous plane. If it was used, fall-back to looking for the first
    available module.

    Signed-off-by: Laurentiu Palcu
    Reviewed-by: Liu Ying
    Acked-by: Jason Liu

    Laurentiu Palcu
     
  • When usb 3.0 hub connect with one USB 2.0 device and NO USB 3.0 device,
    some usb hub reports endless port reset message.

    [ 190.324169] usb 2-1: new SuperSpeed USB device number 88 using xhci-hcd
    [ 190.352834] hub 2-1:1.0: USB hub found
    [ 190.356995] hub 2-1:1.0: 4 ports detected
    [ 190.700056] usb 2-1: USB disconnect, device number 88
    [ 192.472139] usb 2-1: new SuperSpeed USB device number 89 using xhci-hcd
    [ 192.500820] hub 2-1:1.0: USB hub found
    [ 192.504977] hub 2-1:1.0: 4 ports detected
    [ 192.852066] usb 2-1: USB disconnect, device number 89

    The reason is the runtime pm state of USB2.0 port is active and
    USB 3.0 port is suspend, so parent device is active state.

    cat /sys/bus/platform/devices/5b110000.usb/5b130000.usb/xhci-hcd.1.auto/usb2/power/runtime_status

    suspended

    cat /sys/bus/platform/devices/5b110000.usb/5b130000.usb/xhci-hcd.1.auto/usb1/power/runtime_status

    active

    cat /sys/bus/platform/devices/5b110000.usb/5b130000.usb/xhci-hcd.1.auto/power/runtime_status

    active

    cat /sys/bus/platform/devices/5b110000.usb/5b130000.usb/power/runtime_status

    active

    So xhci_cdns3_suspend_quirk() have not called. U3 configure is not applied.

    move U3 configure into host start. Reinit again in resume function in case
    controller power lost during suspend.

    Cc: stable@vger.kernel.org 5.10
    Signed-off-by: Li Jun
    Signed-off-by: Frank Li
    Reviewed-by: Peter Chen
    Acked-by: Alexander Stein

    Li Jun
     

09 Nov, 2022

7 commits

  • Commit 056d3fed3d1f ("tee: add tee_shm_register_{user,kernel}_buf()")
    refactored tee_shm_register() into corresponding user and kernel space
    functions named tee_shm_register_{user,kernel}_buf(). The upstream fix
    commit 573ae4f13f63 ("tee: add overflow check in register_shm_helper()")
    only applied to tee_shm_register_user_buf().

    But the stable kernel 4.19, 5.4, 5.10 and 5.15 don't have the above
    mentioned tee_shm_register() refactoring commit. Hence a direct backport
    wasn't possible and the fix has to be rather applied to
    tee_ioctl_shm_register().

    Somehow the fix was correctly backported to 4.19 and 5.4 stable kernels
    but the backports for 5.10 and 5.15 stable kernels were broken as fix
    was applied to common tee_shm_register() function which broke its kernel
    space users such as trusted keys driver.

    Fortunately the backport for 5.10 stable kernel was incidently fixed by:
    commit 606fe84a4185 ("tee: fix memory leak in tee_shm_register()"). So
    fix the backport for 5.15 stable kernel as well.

    Fixes: 578c349570d2 ("tee: add overflow check in register_shm_helper()")
    Reported-by: Sahil Malhotra
    Signed-off-by: Sumit Garg

    Sumit Garg
     
  • commit 46f8a29272e51b6df7393d58fc5cb8967397ef2b upstream.

    If the VDUSE application provides a smaller config space
    than the driver expects, the driver may use uninitialized
    memory from the stack.

    This patch prevents it by initializing the buffer passed by
    the driver to store the config value.

    This fix addresses CVE-2022-2308.

    Cc: stable@vger.kernel.org # v5.15+
    Fixes: c8a6153b6c59 ("vduse: Introduce VDUSE - vDPA Device in Userspace")
    Reviewed-by: Xie Yongji
    Acked-by: Jason Wang
    Signed-off-by: Maxime Coquelin
    Message-Id:
    Signed-off-by: Michael S. Tsirkin
    Reviewed-by: Chaitanya Kulkarni
    Signed-off-by: Greg Kroah-Hartman
    (cherry picked from commit dc248ddf41eab4566e95b1ee2433c8a5134ad94a)

    Maxime Coquelin
     
  • commit 8e30538eca016de8e252bef174beadecd64239f0 upstream.

    The dma_map_single() doesn't permit zero length mapping. It causes a follow
    panic.

    A panic was reported on arm64:

    [ 60.137988] ------------[ cut here ]------------
    [ 60.142630] kernel BUG at kernel/dma/swiotlb.c:624!
    [ 60.147508] Internal error: Oops - BUG: 0 [#1] PREEMPT SMP
    [ 60.152992] Modules linked in: dw_hdmi_cec crct10dif_ce simple_bridge rcar_fdp1 vsp1 rcar_vin videobuf2_vmalloc rcar_csi2 v4l
    2_mem2mem videobuf2_dma_contig videobuf2_memops pci_endpoint_test videobuf2_v4l2 videobuf2_common rcar_fcp v4l2_fwnode v4l2_asyn
    c videodev mc gpio_bd9571mwv max9611 pwm_rcar ccree at24 authenc libdes phy_rcar_gen3_usb3 usb_dmac display_connector pwm_bl
    [ 60.186252] CPU: 0 PID: 508 Comm: pcitest Not tainted 6.0.0-rc1rpci-dev+ #237
    [ 60.193387] Hardware name: Renesas Salvator-X 2nd version board based on r8a77951 (DT)
    [ 60.201302] pstate: 00000005 (nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
    [ 60.208263] pc : swiotlb_tbl_map_single+0x2c0/0x590
    [ 60.213149] lr : swiotlb_map+0x88/0x1f0
    [ 60.216982] sp : ffff80000a883bc0
    [ 60.220292] x29: ffff80000a883bc0 x28: 0000000000000000 x27: 0000000000000000
    [ 60.227430] x26: 0000000000000000 x25: ffff0004c0da20d0 x24: ffff80000a1f77c0
    [ 60.234567] x23: 0000000000000002 x22: 0001000040000010 x21: 000000007a000000
    [ 60.241703] x20: 0000000000200000 x19: 0000000000000000 x18: 0000000000000000
    [ 60.248840] x17: 0000000000000000 x16: 0000000000000000 x15: ffff0006ff7b9180
    [ 60.255977] x14: ffff0006ff7b9180 x13: 0000000000000000 x12: 0000000000000000
    [ 60.263113] x11: 0000000000000000 x10: 0000000000000000 x9 : 0000000000000000
    [ 60.270249] x8 : 0001000000000010 x7 : ffff0004c6754b20 x6 : 0000000000000000
    [ 60.277385] x5 : ffff0004c0da2090 x4 : 0000000000000000 x3 : 0000000000000001
    [ 60.284521] x2 : 0000000040000000 x1 : 0000000000000000 x0 : 0000000040000010
    [ 60.291658] Call trace:
    [ 60.294100] swiotlb_tbl_map_single+0x2c0/0x590
    [ 60.298629] swiotlb_map+0x88/0x1f0
    [ 60.302115] dma_map_page_attrs+0x188/0x230
    [ 60.306299] pci_endpoint_test_ioctl+0x5e4/0xd90 [pci_endpoint_test]
    [ 60.312660] __arm64_sys_ioctl+0xa8/0xf0
    [ 60.316583] invoke_syscall+0x44/0x108
    [ 60.320334] el0_svc_common.constprop.0+0xcc/0xf0
    [ 60.325038] do_el0_svc+0x2c/0xb8
    [ 60.328351] el0_svc+0x2c/0x88
    [ 60.331406] el0t_64_sync_handler+0xb8/0xc0
    [ 60.335587] el0t_64_sync+0x18c/0x190
    [ 60.339251] Code: 52800013 d2e00414 35fff45c d503201f (d4210000)
    [ 60.345344] ---[ end trace 0000000000000000 ]---

    To fix it, this patch adds a checking the payload length if it is zero.

    Fixes: 343dc693f7b7 ("misc: pci_endpoint_test: Prevent some integer overflows")
    Cc: stable
    Signed-off-by: Shunsuke Mie
    Link: https://lore.kernel.org/r/20220907020100.122588-2-mie@igel.co.jp
    Signed-off-by: Greg Kroah-Hartman
    Signed-off-by: Greg Kroah-Hartman
    (cherry picked from commit e5ebcbb4f967af2083d409271aaf7c7d8351603f)

    Shunsuke Mie
     
  • commit 3e42deaac06567c7e86d287c305ccda24db4ae3d upstream.

    Each transfer test functions have same parameter checking code. This patch
    unites those to an introduced function.

    Signed-off-by: Shunsuke Mie
    Cc: stable
    Link: https://lore.kernel.org/r/20220907020100.122588-1-mie@igel.co.jp
    Signed-off-by: Greg Kroah-Hartman
    (cherry picked from commit cb9defecf381415f6aeb433a05a6c4374775e9d6)

    Shunsuke Mie
     
  • commit a17b9841152e7f4621619902b347e2cc39c32996 upstream.

    Suspending and resuming the system can sometimes cause the out
    URB to get hung after a reset_resume. This causes LED setting
    and force feedback to break on resume. To avoid this, just drop
    the reset_resume callback so the USB core rebinds xpad to the
    wireless pads on resume if a reset happened.

    A nice side effect of this change is the LED ring on wireless
    controllers is now set correctly on system resume.

    Cc: stable@vger.kernel.org
    Fixes: 4220f7db1e42 ("Input: xpad - workaround dead irq_out after suspend/ resume")
    Signed-off-by: Cameron Gutman
    Signed-off-by: Pavel Rojtberg
    Link: https://lore.kernel.org/r/20220818154411.510308-3-rojtberg@gmail.com
    Signed-off-by: Dmitry Torokhov
    Signed-off-by: Greg Kroah-Hartman
    (cherry picked from commit 2c657a0cbd481eda0a6e12c45f55f03d3332223b)

    Cameron Gutman
     
  • commit b382c5e37344883dc97525d05f1f6b788f549985 upstream.

    This is based on multiple commits at https://github.com/paroj/xpad

    Cc: stable@vger.kernel.org
    Signed-off-by: Jasper Poppe
    Signed-off-by: Jeremy Palmer
    Signed-off-by: Ruineka
    Signed-off-by: Cleber de Mattos Casali
    Signed-off-by: Kyle Gospodnetich
    Signed-off-by: Pavel Rojtberg
    Link: https://lore.kernel.org/r/20220818154411.510308-2-rojtberg@gmail.com
    Signed-off-by: Dmitry Torokhov
    Signed-off-by: Greg Kroah-Hartman
    (cherry picked from commit db4db28fccb47a4476f2ea1fd5ea22da8f6bedde)

    Pavel Rojtberg
     
  • commit 1833b6f46d7e2830251a063935ab464256defe22 upstream.

    If the tool on the other side (e.g. wmediumd) gets confused
    about the rate, we hit a warning in mac80211. Silence that
    by effectively duplicating the check here and dropping the
    frame silently (in mac80211 it's dropped with the warning).

    Reported-by: Sönke Huster
    Tested-by: Sönke Huster
    Signed-off-by: Johannes Berg
    Signed-off-by: Greg Kroah-Hartman
    (cherry picked from commit fff244e9171b2ca692469d41c68b36607bd73ab0)

    Johannes Berg
     

07 Nov, 2022

7 commits

  • In order to make the underneath API easier to change in the future,
    prevent users from dereferencing fwnode from struct device.
    Instead, use the specific dev_fwnode() API for that.

    Signed-off-by: zhaoxiao
    Signed-off-by: David S. Miller
    (cherry picked from commit 105b0468d7b2e6779a188a83b7e128368acb8a1d)

    zhaoxiao
     
  • When compiling with -Wformat, clang emits the following warning:

    drivers/net/ethernet/freescale/xgmac_mdio.c:243:22: warning: format
    specifies type 'unsigned char' but the argument has type 'int'
    [-Wformat]
    phy_id, dev_addr, regnum);
    ^~~~~~
    ./include/linux/dev_printk.h:163:47: note: expanded from macro 'dev_dbg'
    dev_printk(KERN_DEBUG, dev, dev_fmt(fmt), ##__VA_ARGS__); \
    ~~~ ^~~~~~~~~~~
    ./include/linux/dev_printk.h:129:34: note: expanded from macro 'dev_printk'
    _dev_printk(level, dev, fmt, ##__VA_ARGS__); \
    ~~~ ^~~~~~~~~~~

    The types of these arguments are unconditionally defined, so this patch
    updates the format character to the correct ones for ints and unsigned
    ints.

    Link: https://github.com/ClangBuiltLinux/linux/issues/378
    Signed-off-by: Bill Wendling
    Link: https://lore.kernel.org/r/20220316213114.2352352-1-morbo@google.com
    Signed-off-by: Jakub Kicinski
    (cherry picked from commit c011072c90353814a9d8e2b3cd111e77ae8601ed)

    Bill Wendling
     
  • In case of error, the function devm_ioremap() returns NULL pointer
    not ERR_PTR(). The IS_ERR() test in the return value check should
    be replaced with NULL test.

    Fixes: 1d14eb15dc2c ("net/fsl: xgmac_mdio: Use managed device resources")
    Reported-by: Hulk Robot
    Signed-off-by: Wei Yongjun
    Reviewed-by: Tobias Waldekranz
    Signed-off-by: David S. Miller
    (cherry picked from commit cc4598cf179ff636d7634008045905a88480bb88)

    Wei Yongjun
     
  • There is a spelling mistake in a dev_err message. Fix it.

    Signed-off-by: Colin Ian King
    Signed-off-by: David S. Miller
    (cherry picked from commit 34a79c5dca4aeabc26073ef36233ea1f409b4d4b)

    Colin Ian King
     
  • Support the standard "clock-frequency" attribute to set the generated
    MDC frequency. If not specified, the driver will leave the divisor
    bits untouched.

    Signed-off-by: Tobias Waldekranz
    Reviewed-by: Andrew Lunn
    Signed-off-by: David S. Miller
    (cherry picked from commit dd8f467eda72cdaff50e4636c382709124956da3)

    Tobias Waldekranz
     
  • Support the standard "suppress-preamble" attribute to disable preamble
    generation.

    Signed-off-by: Tobias Waldekranz
    Reviewed-by: Andrew Lunn
    Signed-off-by: David S. Miller
    (cherry picked from commit 909bea73485fab5e99e222e727e82b259d667880)

    Tobias Waldekranz
     
  • All of the resources used by this driver has managed interfaces, so
    use them. Heed the warning in the comment before platform_get_resource
    and use a bare devm_ioremap to allow for non-exclusive access to the
    IO memory.

    Signed-off-by: Tobias Waldekranz
    Reviewed-by: Andrew Lunn
    Signed-off-by: David S. Miller
    (cherry picked from commit 1d14eb15dc2c3961ffe88d20df17fb2e2eaf1504)

    Tobias Waldekranz
     

03 Nov, 2022

2 commits

  • lx2160ardb and lx2162aqds failed to read out thermal zone when using
    Linux 5.15.71-lf-5.15.52-2.1.0-2798-g393a61ecb9db. This is because the
    IPBRR0s of lx2160ardb, lx2162aqds and i.MX93 have the same value
    0x01900201. It is wrong to use IPBRR0 to determine whether the current
    TMU belongs to i.MX93 or not, so that change to use compatible.

    Signed-off-by: Alice Guo
    Reviewed-by: Ye Li
    Acked-by: Jason Liu

    Alice Guo
     
  • LPUART only support the system wakeup when the UART clock on, but on
    imx93, system mem suspend will shut-off the UART clocks, cause the
    system cannot be waken up.
    So need to add asynchronous wakeup support for LPUART in Low-Power mode,
    now LPUART does not need any clocks to wake-up the Arm platform with the
    asynchronous interrupts.

    Signed-off-by: Sherry Sun
    Reviewed-by: Jacky Bai
    Acked-by: Jason Liu

    Sherry Sun
     

26 Oct, 2022

18 commits

  • Add support for the case when the BPF program attached to a ring with an
    XSK pool returns the XDP_TX verdict. The frame needs to go back on the
    interface it came from.

    No dma_map or dma_sync_for_device is necessary, just a small impedance
    matching logic with the XDP_TX procedure we have in place for non-XSK,
    since the data structures are different (xdp_buff vs xdp_frame; cannot
    have multi-buffer with XSK).

    In the TX confirmation routine, just release the RX buffer (as opposed
    to non-XSK XDP_TX). Recycling might be possible, but I haven't
    experimented with it.

    Signed-off-by: Vladimir Oltean

    Vladimir Oltean
     
  • Schedule NAPI by hand from enetc_xsk_wakeup(), and send frames from the
    XSK TX queue from NAPI context. Add them to the completion queue from
    the enetc_clean_tx_ring() procedure which is common for all kinds of
    traffic.

    We reuse one of the TX rings for XDP (XDP_TX/XDP_REDIRECT) for XSK as
    well. They are already affine with CPUs and cropped from the TX rings
    that the network stack can use when XDP is enabled (with or without
    AF_XDP).

    Signed-off-by: Vladimir Oltean

    Vladimir Oltean
     
  • Add support for filling an RX ring with buffers coming from an XSK umem.
    Although enetc has up to 8 RX rings, we still use one of the 2 per-CPU
    RX rings for XSK.

    To set up an XSK pool on one of the RX queues, we stop the device and
    open it again. While not ideal, the alternative would have been way more
    complex.

    Since the RX procedure in the NAPI poll function is completely different
    (both the API for creating an xdp_buff, as well as refilling the ring
    with memory from user space), create a separate enetc_clean_rx_ring_xsk()
    function which gets called when we have both an XSK pool and an XDK
    program on this RX queue.

    Signed-off-by: Vladimir Oltean

    Vladimir Oltean
     
  • XSK transmission will reuse this procedure, and will also need the logic
    for setting the "final" bit of a TX BD, based on tx_swbd->is_eof.
    Not sure why this was left to be done by the caller of
    enetc_xdp_map_tx_buff(), but move it inside.

    Signed-off-by: Vladimir Oltean

    Vladimir Oltean
     
  • napi_synchronize() from enetc_stop() waits until the softirq has
    finished execution and does not reschedule anymore. However under high
    traffic load, this will never happen, and the interface can never be
    closed.

    The solution chosen here is probably not the best; it is adapted from
    i40e. Normally one would quiesce the RX ring and let the softirq finish
    what remains there. But I couldn't immediately see how to do that (plus
    the fact that the NAPI poll routine is written to update the consumer
    index which makes the device want to put more buffers in the RX ring,
    which restarts the madness again).

    Since the enetc hardirq may trigger while we have ENETC_DOWN set, it may
    happen that enetc_msix() masks it, but enetc_poll() never unmasks it.
    To prevent a stall in that case, schedule all NAPI instances when
    ENETC_DOWN gets cleared.

    Signed-off-by: Vladimir Oltean

    Vladimir Oltean
     
  • v->rx_ring.stats.bytes is apparently only used for interrupt coalescing,
    not for printing to ethtool -S. I am unable to find a functional problem
    caused by the lack of updating this counter, but it is updated from the
    stack NAPI poll routine, so update it from the XDP one too.

    Signed-off-by: Vladimir Oltean

    Vladimir Oltean
     
  • Create naming consistency between the free procedures for a TX and an RX
    software BD.

    Signed-off-by: Vladimir Oltean

    Vladimir Oltean
     
  • There are multiple code paths in the driver which DMA unmap and free the
    page held by the shadow copy of an RX buffer descriptor. Refactor them
    to call the same helper function, which will make it easier to add
    support for one more RX software BD type in the future (XSK buffer).

    Signed-off-by: Vladimir Oltean

    Vladimir Oltean
     
  • In a strange twist of events, some libraries such as libbpf perform an
    ETHTOOL_GCHANNELS ioctl to find out the max number of queues a device
    has, number which in turn is used for attaching XDP sockets to queues.

    To add compatibility with libbpf, it is therefore desirable to report
    something to this ethtool callback.

    According to the ethtool man page, "A channel is an IRQ and the set of
    queues that can trigger that IRQ".

    In enetc (embedded in NXP LS1028A, a dual core SoC, and LS1018A, a
    single core SoC), the enetc_alloc_msix() function allocates a number of
    MSI-X interrupt vectors equal to priv->bdr_int_num (which in turn is
    equal to the number of CPUs, 2 or 1). Each interrupt vector has 1 RX
    ring to process (there are more than 2 RX rings available on an ENETC
    port, but the driver only uses up to 2). In addition, the up to 8 TX
    rings are distributed in a round-robing manner between the up to 2
    available interrupt vectors.

    Therefore, even if we have more resources than 2 RX rings, given the
    definitions, we can only report 2 combined channels. So do that.

    Signed-off-by: Vladimir Oltean

    Vladimir Oltean
     
  • If we see frames with RX errors, consume them, mark their buffers for
    refill, and go through the rest of the ring until the NAPI budget is
    done. Right now we exit and ask the softirq to be rescheduled.

    Signed-off-by: Vladimir Oltean

    Vladimir Oltean
     
  • Calling enetc_bd_unused() on an RX ring returns the number of
    descriptors necessary for the ring to be full with descriptors owned by
    hardware (for it to put packets in).

    Putting this value in a variable named "cleaned_cnt" is misleading,
    especially since we may start the NAPI poll routine (enetc_clean_rx_ring)
    with a non-zero cleaned_cnt.

    Signed-off-by: Vladimir Oltean

    Vladimir Oltean
     
  • In a future patch, the XDP RX queues will have to register a shared page
    memory model, or an XSK pool memory model. For that, the registration
    needs to be more dynamic than the current one, done in enetc_pf_probe()
    -> enetc_alloc_msix().

    Move it to enetc_open()/enetc_close() and create some nicer names for
    it.

    Signed-off-by: Vladimir Oltean

    Vladimir Oltean
     
  • Follow the convention from this driver, which is to name "struct
    net_device *" as "ndev", and the convention from other drivers, to name
    "struct netdev_bpf *" as "bpf".

    Signed-off-by: Vladimir Oltean

    Vladimir Oltean
     
  • Eliminate a 4 byte hole on arm64, to be able to introduce a new member
    to this structure in a future patch without increasing the overall
    structure size.

    Before:

    struct enetc_rx_swbd {
    struct page * page; /* 0 8 */
    enum dma_data_direction dir; /* 8 4 */

    /* XXX 4 bytes hole, try to pack */

    dma_addr_t dma; /* 16 8 */
    u16 page_offset; /* 24 2 */
    u16 len; /* 26 2 */

    /* size: 32, cachelines: 1, members: 5 */
    /* sum members: 24, holes: 1, sum holes: 4 */
    /* padding: 4 */
    /* last cacheline: 32 bytes */
    };

    After:

    struct enetc_rx_swbd {
    struct page * page; /* 0 8 */
    dma_addr_t dma; /* 8 8 */
    enum dma_data_direction dir; /* 16 4 */
    u16 page_offset; /* 20 2 */
    u16 len; /* 22 2 */

    /* size: 24, cachelines: 1, members: 5 */
    /* last cacheline: 24 bytes */
    };

    Signed-off-by: Vladimir Oltean

    Vladimir Oltean
     
  • Under memory pressure, enetc_refill_rx_ring() may fail, and when called
    during the enetc_open() -> enetc_setup_rxbdr() procedure, this is not
    checked for.

    An extreme case of memory pressure will result in exactly zero buffers
    being allocated for the RX ring, and in such a case it is expected that
    hardware drops all RX packets due to lack of buffers.

    There are 2 problems. One is that the hardware drop doesn't happen, the
    other is that even if this is fixed, the driver has undefined behavior
    and may even crash. Explanation for the latter follows below.

    The enetc NAPI poll procedure is shared between RX and TX conf, and
    enetc_poll() calls enetc_clean_rx_ring() even if the reason why NAPI was
    scheduled is TX.

    The enetc_clean_rx_ring() function (and its XDP derivative) is not
    prepared to handle such a condition. It has this loop exit condition:

    rxbd = enetc_rxbd(rx_ring, i);
    bd_status = le32_to_cpu(rxbd->r.lstatus);
    if (!bd_status)
    break;

    otherwise said, the NAPI poll procedure does not look at the Producer
    Index of the RX ring, instead it just walks circularly through the
    descriptors until it finds one which is not Ready.

    The driver undefined behavior is caused by the fact that the
    enetc_rxbd(rx_ring, i) RX descriptor is only initialized by
    enetc_refill_rx_ring() if page allocation has succeeded.

    If memory allocation ever failed, enetc_clean_rx_ring() looks at
    rxbd->r.lstatus as an exit condition, but "rxbd" itself is uninitialized
    memory. If it contains junk, then junk buffers will be processed.

    To fix this problem, memset the DMA coherent area used for RX buffer
    descriptors in enetc_dma_alloc_bdr(). This makes all BDs be "not ready"
    by default, which makes enetc_clean_rx_ring() exit early from the BD
    processing loop when there is no valid buffer available.

    The other problem (hardware does not drop packet in lack of buffers)
    is due to an initial misconfiguration of the RX ring consumer index,
    misconfiguration which is usually masked away by the proper
    configuration done by enetc_refill_rx_ring() - when page allocation does
    not fail.

    The hardware guide recommends BD rings to be configured as follows:

    | Configure the receive ring producer index register RBaPIR with a value
    | of 0. The producer index is initially configured by software but owned
    | by hardware after the ring has been enabled. Hardware increments the
    | index when a frame is received which may consume one or more BDs.
    | Hardware is not allowed to increment the producer index to match the
    | consumer index since it is used to indicate an empty condition. The ring
    | can hold at most RBLENR[LENGTH]-1 received BDs.
    |
    | Configure the receive ring consumer index register RBaCIR. The
    | consumer index is owned by software and updated during operation of the
    | of the BD ring by software, to indicate that any receive data occupied
    | in the BD has been processed and it has been prepared for new data.
    | - If consumer index and producer index are initialized to the same
    | value, it indicates that all BDs in the ring have been prepared and
    | hardware owns all of the entries.
    | - If consumer index is initialized to producer index plus N, it would
    | indicate N BDs have been prepared. Note that hardware cannot start if
    | only a single buffer is prepared due to the restrictions described in
    | (2).
    | - Software may write consumer index to match producer index anytime
    | while the ring is operational to indicate all received BDs prior have
    | been processed and new BDs prepared for hardware.

    The reset-default value of the consumer index is 0, and this makes the
    ENETC think that all buffers have been initialized (when in reality none
    were).

    To operate using no buffer, we must initialize the CI to PI + 1.

    Fixes: d4fd0404c1c9 ("enetc: Introduce basic PF and VF ENETC ethernet drivers")
    Signed-off-by: Vladimir Oltean

    Vladimir Oltean
     
  • It is unnecessary for i.MX93 watchdog to wait 2.5 clocks after RCS is
    done so that set post_rcs_wait to false when the compatible of watchdog
    device node is "fsl,imx93-wdt".

    Signed-off-by: Alice Guo

    Alice Guo
     
  • This reverts commit e31164f8ce44ded55e1adcbc0d945194cd00b91a.

    The issue of LF-7367 was introduced by the commit . Now
    the commit is reverted, so revert this patch too.

    Signed-off-by: Wei Fang
    Reviewed-by: Jun Li

    Wei Fang
     
  • This reverts commit 4001ceb77b9ce47d456248854761abbd7870d6b8.

    This patch introduce the problem that can not resume from suspend state
    on some platfroms. So revert the patch.
    Reproduce command: /unit_tests/Power_Management/suspend_quick_auto.sh
    log:
    28.381366] Filesystems sync: 0.057 seconds
    [ 28.386284] Freezing user space processes ... (elapsed 0.020 seconds) done.
    [ 28.413957] OOM killer disabled.
    [ 28.417224] Freezing remaining freezable tasks ... (elapsed 0.117 seconds) done.
    [ 29.189253] Unable to handle kernel paging request at virtual address dead000000000122
    [ 29.197206] Mem abort info:
    [ 29.200008] ESR = 0x96000044
    [ 29.203070] EC = 0x25: DABT (current EL), IL = 32 bits
    [ 29.208389] SET = 0, FnV = 0
    [ 29.211449] EA = 0, S1PTW = 0
    [ 29.214597] FSC = 0x04: level 0 translation fault
    [ 29.219483] Data abort info:
    [ 29.222361] ISV = 0, ISS = 0x00000044
    [ 29.226202] CM = 0, WnR = 1
    [ 29.229176] [dead000000000122] address between user and kernel address ranges
    [ 29.236318] Internal error: Oops: 96000044 [#1] PREEMPT SMP
    [ 29.241891] Modules linked in: fsl_jr_uio overlay caam_jr caamkeyblob_desc caamhash_desc caamalg_desc crypto_engine authenc libdes crct10dif_ce imx8_media_dev(C) snd_soc_imx_card snd_soc_fsl_asoc_card snd_soc_imx_audmux snd_soc_imx_hdmi dw_hdmi_cec snd_soc_fsl_easrc snd_soc_fsl_xcvr snd_soc_fsl_micfil snd_soc_fsl_sai snd_soc_fsl_asrc snd_soc_fsl_aud2htx snd_soc_wm8960 flexcan can_dev caam secvio error imx_dsp_rproc fuse
    [ 29.279144] CPU: 2 PID: 794 Comm: rtcwakeup.out Tainted: G C 5.15.71+g2c94ea52cdf4 #1
    [ 29.288278] Hardware name: NXP i.MX8MPlus EVK board (DT)
    [ 29.293588] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
    [ 29.300551] pc : destroy_workqueue+0x188/0x2c0
    [ 29.305001] lr : destroy_workqueue+0x174/0x2c0
    [ 29.309445] sp : ffff80001c38b9b0
    [ 29.312756] x29: ffff80001c38b9b0 x28: 00000006a520bfa1 x27: ffff800008839450
    [ 29.319897] x26: 0000000000000002 x25: ffff800009c419e4 x24: 0000000000000100
    [ 29.327037] x23: ffff0000c64f5a20 x22: ffff800009c3f530 x21: ffff0000c64f5a00
    [ 29.334178] x20: ffff0000c64f5988 x19: ffff0000c1a38940 x18: ffff800009dd8c6c
    [ 29.341318] x17: 000000040044ffff x16: 00400032b5503510 x15: 0000000000000000
    [ 29.348458] x14: ffff0000c00d5400 x13: ffff80016f9d4000 x12: 0000000034d4d91d
    [ 29.355599] x11: 0000000000000000 x10: 0000000000000990 x9 : ffff80001c38b7a0
    [ 29.362739] x8 : ffff0000c6fb79f0 x7 : ffff0000c1815800 x6 : 0000000000000000
    [ 29.369879] x5 : 00000000410fd030 x4 : 0000000000000000 x3 : dead000000000122
    [ 29.377018] x2 : ffff0000cc815610 x1 : dead000000000122 x0 : ffff800009c3f568
    [ 29.384159] Call trace:
    [ 29.386603] destroy_workqueue+0x188/0x2c0
    [ 29.390700] stmmac_suspend+0x1f4/0x2b0
    [ 29.394540] stmmac_pltfr_suspend+0x20/0x54
    [ 29.398726] platform_pm_suspend+0x2c/0x70
    [ 29.402827] dpm_run_callback.constprop.0+0x3c/0xd4
    [ 29.407708] __device_suspend+0x114/0x3fc
    [ 29.411719] dpm_suspend+0x11c/0x200
    [ 29.415296] dpm_suspend_start+0x9c/0xa4
    [ 29.419220] suspend_devices_and_enter+0xf8/0x590
    [ 29.423926] pm_suspend+0x2e0/0x340
    [ 29.427415] state_store+0x8c/0x110
    [ 29.430904] kobj_attr_store+0x18/0x30
    [ 29.434655] sysfs_kf_write+0x44/0x54
    [ 29.438322] kernfs_fop_write_iter+0x118/0x1ac
    [ 29.442769] new_sync_write+0xe8/0x184
    [ 29.446520] vfs_write+0x22c/0x290
    [ 29.449924] ksys_write+0x68/0xf4
    [ 29.453240] __arm64_sys_write+0x1c/0x2c
    [ 29.457165] invoke_syscall+0x48/0x114
    [ 29.460917] el0_svc_common.constprop.0+0xd4/0xfc
    [ 29.465624] do_el0_svc+0x28/0x90
    [ 29.468940] el0_svc+0x28/0x80
    [ 29.471997] el0t_64_sync_handler+0xa4/0x130
    [ 29.476268] el0t_64_sync+0x1a0/0x1a4
    [ 29.479935] Code: f9000441 d2802443 9100e2c0 f2fbd5a3 (f9000022)
    [ 29.486029] ---[ end trace c457bc915e3c8e3f ]---

    Signed-off-by: Wei Fang
    Reviewed-by: Jun Li

    Wei Fang
     

24 Oct, 2022

1 commit