- 05 Nov, 2020 28 commits
-
-
Zou Wei authored
Fix coccicheck warnings: ./dpaa_eth.c:2549:2-22: WARNING: Assignment of 0/1 to bool variable ./dpaa_eth.c:2562:2-22: WARNING: Assignment of 0/1 to bool variable Reported-by:
Hulk Robot <hulkci@huawei.com> Signed-off-by:
Zou Wei <zou_wei@huawei.com> Acked-by:
Madalin Bucur <madalin.bucur@oss.nxp.com> Link: https://lore.kernel.org/r/1604405100-33255-1-git-send-email-zou_wei@huawei.comSigned-off-by:
Jakub Kicinski <kuba@kernel.org>
-
Alexandru Ardelean authored
The ADIN1300/ADIN1200 support cable diagnostics using TDR. The cable fault detection is automatically run on all four pairs looking at all combinations of pair faults by first putting the PHY in standby (clear the LINK_EN bit, PHY_CTRL_3 register, Address 0x0017) and then enabling the diagnostic clock (set the DIAG_CLK_EN bit, PHY_CTRL_1 register, Address 0x0012). Cable diagnostics can then be run (set the CDIAG_RUN bit in the CDIAG_RUN register, Address 0xBA1B). The results are reported for each pair in the cable diagnostics results registers, CDIAG_DTLD_RSLTS_0, CDIAG_DTLD_RSLTS_1, CDIAG_DTLD_RSLTS_2, and CDIAG_DTLD_RSLTS_3, Address 0xBA1D to Address 0xBA20). The distance to the first fault for each pair is reported in the cable fault distance registers, CDIAG_FLT_DIST_0, CDIAG_FLT_DIST_1, CDIAG_FLT_DIST_2, and CDIAG_FLT_DIST_3, Address 0xBA21 to Address 0xBA24). This change implements support for this using phylib's cable-test support. Reviewed-by:
Andrew Lunn <andrew@lunn.ch> Signed-off-by:
Alexandru Ardelean <alexandru.ardelean@analog.com> Link: https://lore.kernel.org/r/20201103074436.93790-2-alexandru.ardelean@analog.comSigned-off-by:
-
Alexandru Ardelean authored
When the PHY powers up, the diagnostics clock isn't enabled (bit 2 in register PHY_CTRL_1 (0x0012)). Also, the PHY is not in standby mode, so bit 13 in PHY_CTRL_3 (0x0017) is always set at power up. The standby mode and the diagnostics clock are both meant to be for the cable diagnostics feature of the PHY (in phylib this would be equivalent to the cable-test support), and for the frame-generator feature of the PHY. In standby mode, the PHY doesn't negotiate links or manage links. To use the cable diagnostics/test (or frame-generator), the PHY must be first set in standby mode, so that the link operation doesn't interfere. Then, the diagnostics clock must be enabled. For the cable-test feature, when the operation finishes, the PHY goes into PHY_UP state, and the config_aneg hook is called. For the ADIN PHY, we need to make sure that during autonegotiation configuration/setup the PHY is removed from standby mode and the diagnostics clock is disabled, so that normal operation is resumed. This change does that by moving the set of the ADIN1300_LINKING_EN bit (2) in the config_aneg (to disable standby mode). Previously, this was set in the downshift setup, because the downshift retry value and the ADIN1300_LINKING_EN are in the same register. And the ADIN1300_DIAG_CLK_EN bit (13) is cleared, to disable the diagnostics clock. Reviewed-by:
-
Jakub Kicinski authored
Nikolay Aleksandrov says: ==================== selftests: net: bridge: add tests for MLDv2 This is the second selftests patch-set for the new multicast functionality which adds tests for the bridge's MLDv2 support. The tests use full precooked packets which are sent via mausezahn and the resulting state after each test is checked for proper X,Y sets, (*,G) source list, source list entry timers, (S,G) existence and flags, packet forwarding and blocking, exclude group expiration and (*,G) auto-add. The first 3 patches factor out common functions which are used by IGMPv3 tests in lib.sh and add support for IPv6 test UDP packet, then patch 4 adds the first test with the initial MLDv2 setup. The following new tests are added: - base case: MLDv2 report ff02::cc is_include - include -> allow report - include -> is_include report - include -> is_exclude report - include -> to_exclude report - exclude -> allow report - exclude -> is_include report - exclude -> is_exclude report - exclude -> to_exclude report - include -> block report - exclude -> block report - exclude timeout (move to include + entry deletion) - S,G port entry automatic add to a *,G,exclude port The variable names and set notation are the same as per RFC 3810, for more information check RFC 3810 sections 2.3 and 7. ==================== Link: https://lore.kernel.org/r/20201103172412.1044840-1-razor@blackwall.orgSigned-off-by:
-
Nikolay Aleksandrov authored
When we have *,G ports in exclude mode and a new S,G,port is added the kernel has to automatically create an S,G entry for each exclude port to get proper forwarding. Signed-off-by:
Nikolay Aleksandrov <nikolay@nvidia.com> Signed-off-by:
-
Nikolay Aleksandrov authored
Test that when a group in exclude mode expires it changes mode to include and the blocked entries are deleted. Signed-off-by:
-
Nikolay Aleksandrov authored
The test checks for the following case: Router State Report Received New Router State Actions EXCLUDE (X,Y) BLOCK (A) EXCLUDE (X+(A-Y),Y) (A-X-Y) = Filter Timer Send Q(MA,A-Y) Signed-off-by: -
Nikolay Aleksandrov authored
The test checks for the following case: Router State Report Received New Router State Actions INCLUDE (A) BLOCK (B) INCLUDE (A) Send Q(MA,A*B) Signed-off-by:
-
Nikolay Aleksandrov authored
The test checks for the following case: Router State Report Received New Router State Actions EXCLUDE (X,Y) TO_EX (A) EXCLUDE (A-Y,Y*A) (A-X-Y) = Filter Timer Delete (X-A) Delete (Y-A) Send Q(MA,A-Y) Filter Timer=MALI Signed-off-by: -
Nikolay Aleksandrov authored
The test checks for the following case: Router State Report Received New Router State Actions EXCLUDE (X,Y) IS_EX (A) EXCLUDE (A-Y, Y*A) (A-X-Y)=MALI Delete (X-A) Delete (Y-A) Filter Timer=MALI Signed-off-by: -
Nikolay Aleksandrov authored
The test checks for the following case: Router State Report Received New Router State Actions EXCLUDE (X,Y) IS_IN (A) EXCLUDE (X+A, Y-A) (A)=MALI Signed-off-by:
-
Nikolay Aleksandrov authored
The test checks for the following case: Router State Report Received New Router State Actions EXCLUDE (X,Y) ALLOW (A) EXCLUDE (X+A,Y-A) (A)=MALI Signed-off-by:
-
Nikolay Aleksandrov authored
The test checks for the following case: Router State Report Received New Router State Actions INCLUDE (A) TO_EX (B) EXCLUDE (A*B,B-A) (B-A)=0 Delete (A-B) Send Q(MA,A*B) Filter Timer=MALI Signed-off-by: -
Nikolay Aleksandrov authored
The test checks for the following case: Router State Report Received New Router State Actions INCLUDE (A) IS_EX (B) EXCLUDE (A*B, B-A) (B-A)=0 Delete (A-B) Filter Timer=MALI Signed-off-by: -
Nikolay Aleksandrov authored
The test checks for the following case: Router State Report Received New Router State Actions INCLUDE (A) IS_IN (B) INCLUDE (A+B) (B)=MALI Signed-off-by:
-
Nikolay Aleksandrov authored
The test checks for the following case: Router State Report Received New Router State Actions INCLUDE (A) ALLOW (B) INCLUDE (A+B) (B)=MALI Signed-off-by:
-
Nikolay Aleksandrov authored
Add the initial setup for MLDv2 tests with the first test of a simple is_include report. For MLDv2 we need to setup the bridge properly and we also send the full precooked packets instead of relying on mausezahn to fill in some parts. For verification we use the generic S,G state checking functions from lib.sh. Signed-off-by:
-
Nikolay Aleksandrov authored
Factor out S,G entry state checking functions for existence, forwarding, blocking and timer to lib.sh so they can be later used by MLDv2 tests. Add brmcast_ suffix to their name to make the relation to the bridge explicit. Signed-off-by:
-
Nikolay Aleksandrov authored
In order to test an IPv6 multicast packet we need to pass different tc and mausezahn protocols only, so add a simple check for the destination address which decides if we should generate an IPv4 or IPv6 mcast packet. Signed-off-by:
-
Nikolay Aleksandrov authored
Factor out mcast_packet_test into lib.sh so it can be later extended and reused by MLDv2 tests. Signed-off-by:
-
DENG Qingfang authored
MT7530/7531 has a global RX packet length register, which can be used to set MTU. Supported packet length values are 1522 (1518 if untagged), 1536, 1552, and multiple of 1024 (from 2048 to 15360). Signed-off-by:
DENG Qingfang <dqfext@gmail.com> Link: https://lore.kernel.org/r/20201103050618.11419-1-dqfext@gmail.comSigned-off-by:
-
Jakub Kicinski authored
Alex Elder says: ==================== net: ipa: tell GSI the IPA version The GSI code that supports IPA avoids having knowledge about the IPA layer it serves. One result of this is that Boolean flags are used during GSI initialization to convey that certain hardware version-dependent special behaviors should be used. A given version of IPA hardware uses a fixed/well-defined version of GSI, so the IPA version really implies the GSI version. If given only the IPA version, the GSI code supporting IPA can use it to implement certain special behaviors required for IPA *or* GSI. This avoids the need to pass and maintain numerous Boolean flags. ==================== Link: https://lore.kernel.org/r/20201102175400.6282-1-elder@linaro.orgSigned-off-by:
-
Alex Elder authored
We enable a channel doorbell engine only for IPA v3.5.1, and that is now handled directly by gsi_channel_program(). When initially setting up a channel, we want that doorbell engine enabled, and we can request that independent of the IPA version. Doing that makes the "legacy" argument to gsi_channel_setup_one() unnecessary. And with that gone we can get rid of the "legacy" argument to gsi_channel_setup(), and gsi_setup() as well. Signed-off-by:
Alex Elder <elder@linaro.org> Signed-off-by:
-
Alex Elder authored
Use the IPA version in gsi_channel_program() to determine whether we should enable the GSI doorbell engine when requested. This way, callers only say whether or not it should be enabled if needed, regardless of hardware version. Rename the "legacy" argument to gsi_channel_reset(), and have it indicate whether the doorbell engine should be enabled when reprogramming following the reset. Change all callers of gsi_channel_reset() to indicate whether to enable the doorbell engine after reset, independent of hardware version. Rework a little logic in ipa_endpoint_reset() to get rid of the "legacy" variable previously passed to gsi_channel_reset(). Signed-off-by:
-
Alex Elder authored
A quirk of IPA v3.5.1 requires a channel reset on an RX channel to be performed twice. Use the IPA version in gsi_channel_reset() rather than the passed-in legacy flag to determine that. This is actually a bug fix, because this double reset is supposed to occur independent of whether we're enabling the doorbell engine. Now they will be independent. Signed-off-by:
-
Alex Elder authored
A quirk of IPA v4.2 requires the AP to allocate the GSI channels that are owned by the modem. Rather than pass a flag argument to gsi_channel_init(), use the IPA version directly in that function to determine whether modem channels need to be allocated. Signed-off-by:
-
Alex Elder authored
Record the IPA version passed to gsi_init() in the GSI structure. This allows that value to be used directly where needed, rather than passing and storing certain flag arguments through the code. In particular, for all but one supported version of IPA, the command channel is programmed to only use an "escape buffer". By storing the IPA version, we can do a simple version check in one location, and avoid storing a flag field in every channel (and passing a flag along while initializing channels to set that field properly). Signed-off-by:
-
Alex Elder authored
Although GSI is integral to IPA, it is a separate hardware component and the IPA code supporting it has been structured to avoid explicit dependence on IPA details. An example of this is that gsi_init() is passed a number of Boolean flags to indicate special behaviors, whose values are dependent on the IPA hardware version. Looking ahead, newer hardware versions would require even more such special behaviors. For any given version of IPA hardware (like 3.5.1 or 4.2), the GSI hardware version is fixed (in this case, 1.3 and 2.2, respectively). So the IPA version *implies* the GSI version, and the IPA version can be used as effectively the equivalent of the GSI hardware version. Rather than proliferating new special behavior flags, just provide the IPA version to the GSI layer when it is initialized. The GSI code can then use that directly to determine whether special behaviors are required. The IPA version enumerated type is already isolated to its own header file, so the exposure of this IPA detail is very limited. For now, just change gsi_init() to pass the version rather than the Boolean flags, and set the flag values internal to that function. Signed-off-by:
-
- 04 Nov, 2020 12 commits
-
-
Alex Elder authored
With IPA v3.5.1, if IPA aggregation is active at the time an underlying GSI channel reset is performed, some special handling is required. There is logic in ipa_endpoint_reset() that arranges for that special handling, but it's done for all hardware versions, not just IPA v3.5.1. Fix the logic to properly restrict the special behavior. Signed-off-by:
-
Vinay Kumar Yadav authored
patch adds a logic to utilize multiple queues to process requests. The queue selection logic uses a round-robin distribution technique using a counter. Signed-off-by:
Ayush Sawal <ayush.sawal@chelsio.com> Signed-off-by:
Vinay Kumar Yadav <vinay.yadav@chelsio.com> Link: https://lore.kernel.org/r/20201102162832.22344-1-vinay.yadav@chelsio.comSigned-off-by:
-
Colin Ian King authored
An incorrect sizeof() is being used, sizeof(u64 *) is not correct, it should be sizeof(*sq->sqb_ptrs). Addresses-Coverity: ("Sizeof not portable (SIZEOF_MISMATCH)") Signed-off-by:Colin Ian King <colin.king@canonical.com> Link: https://lore.kernel.org/r/20201102134601.698436-1-colin.king@canonical.comSigned-off-by:
-
Colin Ian King authored
The variable err is being initialized with a value that is never read and it is being updated later with a new value. The initialization is redundant and can be removed. Addresses-Coverity: ("Unused value") Signed-off-by: -
kernel test robot authored
Condition !A || A && B is equivalent to !A || B. Generated by: scripts/coccinelle/misc/excluded_middle.cocci Fixes: b76f0ea0 ("coccinelle: misc: add excluded_middle.cocci script") CC: Denis Efremov <efremov@linux.com> Signed-off-by:
kernel test robot <lkp@intel.com> Signed-off-by:
Julia Lawall <julia.lawall@inria.fr> Link: https://lore.kernel.org/r/alpine.DEB.2.22.394.2011020936100.3077@hadrienSigned-off-by:
-
Willy Liu authored
Realtek single-port 2.5Gbps Ethernet PHYs are list as below: RTL8226-CG: the 1st generation 2.5Gbps single port PHY RTL8226B-CG/RTL8221B-CG: the 2nd generation 2.5Gbps single port PHY RTL8221B-VB-CG: the 3rd generation 2.5Gbps single port PHY RTL8221B-VM-CG: the 2.5Gbps single port PHY with MACsec feature This patch adds the minimal drivers to manage these transceivers. Signed-off-by:
Willy Liu <willy.liu@realtek.com> Reviewed-by:
-
Jakub Kicinski authored
Sebastian Andrzej Siewior says: ==================== fsl/qbman: in_interrupt() cleanup. This is the in_interrupt() clean for FSL DPAA framework and the two users. The `napi' parameter has been renamed to `sched_napi', the other parts are same as in the previous post [0]. [0] https://lkml.kernel.org/r/20201027225454.3492351-1-bigeasy@linutronix.de ==================== Link: https://lore.kernel.org/r/20201101232257.3028508-1-bigeasy@linutronix.deSigned-off-by:
-
Sebastian Andrzej Siewior authored
The driver uses in_irq() + in_serving_softirq() magic to decide if NAPI scheduling is required or packet processing. The usage of in_*() in drivers is phased out and Linus clearly requested that code which changes behaviour depending on context should either be separated or the context be conveyed in an argument passed by the caller, which usually knows the context. Use the `sched_napi' argument passed by the callback. It is set true if called from the interrupt handler and NAPI should be scheduled. Signed-off-by:
Sebastian Andrzej Siewior <bigeasy@linutronix.de> Cc: Aymen Sghaier <aymen.sghaier@nxp.com> Cc: Herbert Xu <herbert@gondor.apana.org.au> Cc: Li Yang <leoyang.li@nxp.com> Reviewed-by:
Horia Geantă <horia.geanta@nxp.com> Signed-off-by:
Camelia Groza <camelia.groza@nxp.com>
-
Sebastian Andrzej Siewior authored
The driver uses in_irq() + in_serving_softirq() magic to decide if NAPI scheduling is required or packet processing. The usage of in_*() in drivers is phased out and Linus clearly requested that code which changes behaviour depending on context should either be separated or the context be conveyed in an argument passed by the caller, which usually knows the context. Use the `sched_napi' argument passed by the callback. It is set true if called from the interrupt handler and NAPI should be scheduled. Signed-off-by:
-
Sebastian Andrzej Siewior authored
dpaa_eth_napi_schedule() and caam_qi_napi_schedule() schedule NAPI if invoked from: - Hard interrupt context - Any context which is not serving soft interrupts Any context which is not serving soft interrupts includes hard interrupts so the in_irq() check is redundant. caam_qi_napi_schedule() has a comment about this: /* * In case of threaded ISR, for RT kernels in_irq() does not return * appropriate value, so use in_serving_softirq to distinguish between * softirq and irq contexts. */ if (in_irq() || !in_serving_softirq()) This has nothing to do with RT. Even on a non RT kernel force threaded interrupts run obviously in thread context and therefore in_irq() returns false when invoked from the handler. The extension of the in_irq() check with !in_serving_softirq() was there when the drivers were added, but in the out of tree FSL BSP the original condition was in_irq() which got extended due to failures on RT. The usage of in_xxx() in drivers is phased out and Linus clearly requested that code which changes behaviour depending on context should either be separated or the context be conveyed in an argument passed by the caller, which usually knows the context. Right he is, the above construct is clearly showing why. The following callchains have been analyzed to end up in dpaa_eth_napi_schedule(): qman_p_poll_dqrr() __poll_portal_fast() fq->cb.dqrr() dpaa_eth_napi_schedule() portal_isr() __poll_portal_fast() fq->cb.dqrr() dpaa_eth_napi_schedule() Both need to schedule NAPI. The crypto part has another code path leading up to this: kill_fq() empty_retired_fq() qman_p_poll_dqrr() __poll_portal_fast() fq->cb.dqrr() dpaa_eth_napi_schedule() kill_fq() is called from task context and ends up scheduling NAPI, but that's pointless and an unintended side effect of the !in_serving_softirq() check. The code path: caam_qi_poll() -> qman_p_poll_dqrr() is invoked from NAPI and I *assume* from crypto's NAPI device and not from qbman's NAPI device. I *guess* it is okay to skip scheduling NAPI (because this is what happens now) but could be changed if it is wrong due to `budget' handling. Add an argument to __poll_portal_fast() which is true if NAPI needs to be scheduled. This requires propagating the value to the caller including `qman_cb_dqrr' typedef which is used by the dpaa and the crypto driver. Signed-off-by: -
Sergej Bauer authored
This is the 3rd revision of the patch fix for potential null pointer dereference with lan743x card. The simpliest way to reproduce: boot with bare lan743x and issue "ethtool ethN" commant where ethN is the interface with lan743x card. Example: $ sudo ethtool eth7 dmesg: [ 103.510336] BUG: kernel NULL pointer dereference, address: 0000000000000340 ... [ 103.510836] RIP: 0010:phy_ethtool_get_wol+0x5/0x30 [libphy] ... [ 103.511629] Call Trace: [ 103.511666] lan743x_ethtool_get_wol+0x21/0x40 [lan743x] [ 103.511724] dev_ethtool+0x1507/0x29d0 [ 103.511769] ? avc_has_extended_perms+0x17f/0x440 [ 103.511820] ? tomoyo_init_request_info+0x84/0x90 [ 103.511870] ? tomoyo_path_number_perm+0x68/0x1e0 [ 103.511919] ? tty_insert_flip_string_fixed_flag+0x82/0xe0 [ 103.511973] ? inet_ioctl+0x187/0x1d0 [ 103.512016] dev_ioctl+0xb5/0x560 [ 103.512055] sock_do_ioctl+0xa0/0x140 [ 103.512098] sock_ioctl+0x2cb/0x3c0 [ 103.512139] __x64_sys_ioctl+0x84/0xc0 [ 103.512183] do_syscall_64+0x33/0x80 [ 103.512224] entry_SYSCALL_64_after_hwframe+0x44/0xa9 [ 103.512274] RIP: 0033:0x7f54a9cba427 ... Previous versions can be found at: v1: initial version https://lkml.org/lkml/2020/10/28/921 v2: do not return from lan743x_ethtool_set_wol if netdev->phydev == NULL, just skip the call of phy_ethtool_set_wol() instead. https://lkml.org/lkml/2020/10/31/380 v3: in function lan743x_ethtool_set_wol: use ternary operator instead of if-else sentence (review by Markus Elfring) return -ENETDOWN insted of -EIO (review by Andrew Lunn) Signed-off-by:Sergej Bauer <sbauer@blackbox.su> Link: https://lore.kernel.org/r/20201101223556.16116-1-sbauer@blackbox.suSigned-off-by:
-
Heiner Kallweit authored
We had to remove flag IRQF_NO_THREAD because it conflicts with shared interrupts in case legacy interrupts are used. Following up on the linked discussion set IRQF_NO_THREAD if MSI or MSI-X is used, because both guarantee that interrupt won't be shared. Signed-off-by:
Heiner Kallweit <hkallweit1@gmail.com> Link: https://www.spinics.net/lists/netdev/msg695341.html Link: https://lore.kernel.org/r/446cf5b8-dddd-197f-cb96-66783141ade4@gmail.comSigned-off-by:
-
