- 22 Jan, 2021 9 commits
-
-
Jakub Kicinski authored
Alex Elder says: ==================== net: ipa: remove a build dependency Unlike the original (temporary) IPA notification mechanism, the generic remoteproc SSR notification code does not require the IPA driver to maintain a pointer to the modem subsystem remoteproc structure. The IPA driver was converted to use the newer SSR notifiers, but the specification and use of a phandle for the modem subsystem was never removed. This series removes the lookup of the remoteproc pointer, and that removes the need for the modem DT property. It also removes the reference to the "modem-remoteproc" property from the DT binding, and from the DT files that specified them. ==================== Link: https://lore.kernel.org/r/20210120212606.12556-1-elder@linaro.orgSigned-off-by:
Jakub Kicinski <kuba@kernel.org>
-
Alex Elder authored
The "modem-remoteproc" property is no longer required for the IPA driver, so get rid of it. Signed-off-by:
Alex Elder <elder@linaro.org> Signed-off-by:
-
Alex Elder authored
The "modem-remoteproc" property is no longer required for the IPA driver, so get rid of it. Signed-off-by:
-
Alex Elder authored
The IPA driver uses the remoteproc SSR notifier now, rather than the temporary IPA notification system used initially. As a result it no longer needs a property identifying the modem subsystem DT node. Use GIC_SPI rather than 0 in the example interrupt definition. Signed-off-by:
-
Alex Elder authored
The IPA driver currently requires a DT property to be defined whose value is the phandle for the modem subsystem. This was needed to look up a remoteproc structure pointer used when registering for notifications in the original IPA notification mechanism. Remoteproc provides a more generic SSR notifier system, and the IPA driver switched over to it last summer, but this remoteproc phandle dependency was not removed at that time. Get rid of the IPA remoteproc pointer and stop requiring the phandle be specified. This avoids a link error (rproc_put() not defined) for certain configurations. Reported-by:
Randy Dunlap <rdunlap@infradead.org> Signed-off-by:
-
Michael Walle authored
If the MII interface is used, the PHY is the clock master, thus don't set the clock rate. On Zynq-7000, this will prevent the following warning: macb e000b000.ethernet eth0: unable to generate target frequency: 25000000 Hz Signed-off-by:
Michael Walle <michael@walle.cc> Reviewed-by:
Andrew Lunn <andrew@lunn.ch> Link: https://lore.kernel.org/r/20210120194303.28268-1-michael@walle.ccSigned-off-by:
-
Arnd Bergmann authored
The tango4 platform is getting removed, and this driver has no other known users, so it can be removed. Cc: Marc Gonzalez <marc.w.gonzalez@free.fr> Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Acked-by:
Mans Rullgard <mans@mansr.com> Link: https://lore.kernel.org/r/20210120150703.1629527-1-arnd@kernel.orgSigned-off-by:
-
Heiner Kallweit authored
The comment is quite weird, there is no such thing as a vendor-specific VPD id. 0x82 is the value of PCI_VPD_LRDT_ID_STRING. So what we are doing here is simply checking whether the byte at VPD address VPD_BASE is a valid string LRDT, same as what is done a few lines later in the code. LRDT = Large Resource Data Tag, see PCI 2.2 spec, VPD chapter v2: - don't set VPD_BASE / VPD_BASE_OLD separately Signed-off-by:
Heiner Kallweit <hkallweit1@gmail.com> Link: https://lore.kernel.org/r/644ef22f-e86a-5cc1-0f27-f873ab165696@gmail.comSigned-off-by:
-
Jiapeng Zhong authored
Fix the following coccicheck warnings: ./drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c:5142:2-33: WARNING: Assignment of 0/1 to bool variable. Reported-by:
Abaci Robot <abaci@linux.alibaba.com> Signed-off-by:
Jiapeng Zhong <abaci-bugfix@linux.alibaba.com> Link: https://lore.kernel.org/r/1611126111-22079-1-git-send-email-abaci-bugfix@linux.alibaba.comSigned-off-by:
-
- 21 Jan, 2021 31 commits
-
-
George McCollister authored
Add myself as maintainer of the Arrow SpeedChips XRS7000 series Ethernet switch driver. Suggested-by:
George McCollister <george.mccollister@gmail.com> Link: https://lore.kernel.org/r/20210120135323.73856-1-george.mccollister@gmail.comSigned-off-by:
-
Jakub Kicinski authored
Rasmus Villemoes says: ==================== ucc_geth improvements This is a resend of some improvements to the ucc_geth driver that was previously sent together with bug fixes, which have by now been applied. v2: rebase to net/master; address minor style issues; don't introduce a use-after-free in patch "don't statically allocate eight ucc_geth_info". ==================== Link: https://lore.kernel.org/r/20210119150802.19997-1-rasmus.villemoes@prevas.dkSigned-off-by:
-
Rasmus Villemoes authored
Since kmalloc() is nowadays [1] guaranteed to return naturally aligned (i.e., aligned to the size itself) memory for power-of-2 sizes, we don't need to over-allocate the align amount, compute an aligned address within the allocation, and (for later freeing) also storing the original pointer [2]. Instead, just round up the length we want to allocate to the alignment requirements, then round that up to the next power of 2. In theory, this could allocate up to about twice as much memory as we needed. In practice, (a) kmalloc() would in most cases anyway return a power-of-2-sized allocation and (b) with the default values of the bdRingLen[RT]x fields, the length is already itself a power of 2 greater than the alignment. So we actually end up saving memory compared to the current situtation (e.g. for tx, we currently allocate 128+32 bytes, which kmalloc() likely rounds up to 192 or 256; with this patch, we just allocate 128 bytes.) Also struct ucc_geth_private becomes a little smaller. [1] 59bb4798 ("mm, sl[aou]b: guarantee natural alignment for kmalloc(power-of-two)") [2] That storing was anyway done in a u32, which works on 32 bit machines, but is not very elegant and certainly makes a reader of the code pause for a while. Signed-off-by:
Rasmus Villemoes <rasmus.villemoes@prevas.dk> Signed-off-by:
-
Rasmus Villemoes authored
The numQueuesTx and numQueuesRx members of struct ucc_geth_info are never set to anything but 1, and never have been. It's unclear how well the code supporting multiple queues would work. Until somebody wants to play with enabling that, help the compiler eliminate a lot of dead code and loops that are not really loops by creating static inline helpers. If and when the numQueuesTx/numQueuesRx fields are re-introduced, it suffices to update those helper to return the appropriate field. This cuts the .text segment of ucc_geth.o by 8%. Signed-off-by:
-
Rasmus Villemoes authored
The translation from the ucc_geth_num_of_threads enum value to the actual count can be written somewhat more compactly with a small lookup table, allowing us to replace the four switch statements. Signed-off-by:
-
Rasmus Villemoes authored
Signed-off-by:
-
Rasmus Villemoes authored
The bd_mem_part member of ucc_geth_info always has the value MEM_PART_SYSTEM, and AFAICT, there has never been any code setting it to any other value. Moreover, muram is a somewhat precious resource, so there's no point using that when normal memory serves just as well. Apart from removing a lot of dead code, this is also motivated by wanting to clean up the "store result from kmalloc() in a u32" mess. Signed-off-by:
-
Rasmus Villemoes authored
These macros both have the value 32, there's no point first initializing align to a lower value. If anything, one could throw in a BUILD_BUG_ON(UCC_GETH_TX_BD_RING_ALIGNMENT < 4), but it's not worth it - lots of code depends on named constants having sensible values. Signed-off-by:
-
Rasmus Villemoes authored
struct ucc_geth_info is somewhat large, and on systems with only one or two UCC instances, that just wastes a few KB of memory. So allocate and populate a chunk of memory at probe time instead of initializing them all during driver init. Note that the existing "ug_info == NULL" check was dead code, as the address of some static array element can obviously never be NULL. Signed-off-by:
-
Rasmus Villemoes authored
Signed-off-by:
-
Rasmus Villemoes authored
Reduce the code duplication a bit by moving the parsing of rx-clock-name and the fallback handling to a helper function. Signed-off-by:
-
Rasmus Villemoes authored
These fields are only used within ucc_geth_startup(), so they might as well be local variables in that function rather than being stashed in struct ucc_geth_private. Aside from making that struct a tiny bit smaller, it also shortens some lines (getting rid of pointless casts while here), and fixes the problems with using IS_ERR_VALUE() on a u32 as explained in commit 800cd6fb ("soc: fsl: qe: change return type of cpm_muram_alloc() to s32"). Signed-off-by:
-
Rasmus Villemoes authored
Signed-off-by:
-
Rasmus Villemoes authored
These buffers have all just been handed out from qe_muram_alloc(), aka cpm_muram_alloc(), and the helper cpm_muram_alloc_common() already does memset_io(cpm_muram_addr(start), 0, size); Signed-off-by: -
Rasmus Villemoes authored
This removes the explicit NULL checks, and allows us to stop storing at least some of the _offset values separately. Signed-off-by:
-
Rasmus Villemoes authored
Add a helper that takes a virtual address rather than the muram offset. This will be used in a couple of places to avoid having to store both the offset and the virtual address, as well as removing NULL checks from the callers. Signed-off-by:
Li Yang <leoyang.li@nxp.com> Signed-off-by:
-
Rasmus Villemoes authored
The two functions cpm_muram_offset() and cpm_muram_dma() both need a cast currently, one casts muram_vbase to do the pointer arithmetic on void pointers, the other casts the passed-in address u8*. It's simpler and more consistent to just always use void* and drop all the casting. Signed-off-by:
-
Rasmus Villemoes authored
Allow passing const-qualified pointers without requiring a cast in the caller. Signed-off-by:
-
Rasmus Villemoes authored
In theory, such a read-after-write might be required by the hardware, but nothing in the data sheet suggests that to be the case. The name test also suggests that it's some debug leftover. Signed-off-by:
-
Jakub Kicinski authored
George Cherian says: ==================== Add devlink health reporters for NIX block Devlink health reporters are added for the NIX block. Address Jakub's comment to add devlink support for error reporting. https://www.spinics.net/lists/netdev/msg670712.html This series is in continuation to https://www.spinics.net/lists/netdev/msg707798.html Added Documentation for the same. ==================== Link: https://lore.kernel.org/r/20210119100120.2614730-1-george.cherian@marvell.comSigned-off-by:
-
George Cherian authored
Add devlink health reporter documentation for NIX block. Signed-off-by:
George Cherian <george.cherian@marvell.com> Signed-off-by:
-
George Cherian authored
Add health reporters for RVU NIX block. NIX Health reporters handle following HW event groups - GENERAL events - ERROR events - RAS events - RVU event Output: # devlink health pci/0002:01:00.0: reporter hw_npa_intr state healthy error 0 recover 0 grace_period 0 auto_recover true auto_dump true reporter hw_npa_gen state healthy error 0 recover 0 grace_period 0 auto_recover true auto_dump true reporter hw_npa_err state healthy error 0 recover 0 grace_period 0 auto_recover true auto_dump true reporter hw_npa_ras state healthy error 0 recover 0 grace_period 0 auto_recover true auto_dump true reporter hw_nix_intr state healthy error 0 recover 0 grace_period 0 auto_recover true auto_dump true reporter hw_nix_gen state healthy error 0 recover 0 grace_period 0 auto_recover true auto_dump true reporter hw_nix_err state healthy error 0 recover 0 grace_period 0 auto_recover true auto_dump true reporter hw_nix_ras state healthy error 0 recover 0 grace_period 0 auto_recover true auto_dump true # devlink health dump show pci/0002:01:00.0 reporter hw_nix_intr NIX_AF_RVU: NIX RVU Interrupt Reg : 1 Unmap Slot Error # devlink health dump show pci/0002:01:00.0 reporter hw_nix_gen NIX_AF_GENERAL: NIX General Interrupt Reg : 1 Rx multicast pkt drop Each reporter dump shows the Register value and the description of the cause. Signed-off-by:Sunil Kovvuri Goutham <sgoutham@marvell.com> Signed-off-by:
Jerin Jacob <jerinj@marvell.com> Signed-off-by:
-
Martin Blumenstingl authored
When has_prg_eth1_rgmii_rx_delay is true then we support RX delays between 0ps and 3000ps in 200ps steps. Swap the validation of the RX delay based on the has_prg_eth1_rgmii_rx_delay flag so the 200ps check is now applied correctly on G12A SoCs (instead of only allow 0ps or 2000ps on G12A, but 0..3000ps in 200ps steps on older SoCs which don't support that). Fixes: de94fc10 ("net: stmmac: dwmac-meson8b: add support for the RGMII RX delay on G12A") Reported-by:
Martijn van Deventer <martijn@martijnvandeventer.nl> Signed-off-by:
Martin Blumenstingl <martin.blumenstingl@googlemail.com> Link: https://lore.kernel.org/r/20210119202424.591349-1-martin.blumenstingl@googlemail.comSigned-off-by:
-
Xin Long authored
This patch is to let it always do CRC checksum in sctp_gso_segment() by removing CRC flag from the dev features in gre_gso_segment() for SCTP over GRE, just as it does in Commit 527beb8e ("udp: support sctp over udp in skb_udp_tunnel_segment") for SCTP over UDP. It could set csum/csum_start in GSO CB properly in sctp_gso_segment() after that commit, so it would do checksum with gso_make_checksum() in gre_gso_segment(), and Commit 622e32b7 ("net: gre: recompute gre csum for sctp over gre tunnels") can be reverted now. Note that when need_csum is false, we can still leave CRC checksum of SCTP to HW by not clearing this CRC flag if it's supported, as Jakub and Alex noticed. v1->v2: - improve the changelog. - fix "rev xmas tree" in varibles declaration. v2->v3: - remove CRC flag from dev features only when need_csum is true. Signed-off-by:
Xin Long <lucien.xin@gmail.com> Link: https://lore.kernel.org/r/00439f24d5f69e2c6fa2beadc681d056c15c258f.1610772251.git.lucien.xin@gmail.comSigned-off-by:
-
Xin Long authored
In __skb_udp_tunnel_segment(), when it's a SCTP over VxLAN/GENEVE packet and need_csum is false, which means the outer udp checksum doesn't need to be computed, csum_start and csum_offset could be used by the inner SCTP CRC CSUM for SCTP HW CRC offload. So this patch is to not remove the CRC flag from dev features when need_csum is false. Signed-off-by:
-
wenxu authored
This patch add the TCA_FLOWER_KEY_CT_FLAGS_INVALID flag to match the ct_state with invalid for conntrack. Signed-off-by:
wenxu <wenxu@ucloud.cn> Acked-by:
Marcelo Ricardo Leitner <marcelo.leitner@gmail.com> Link: https://lore.kernel.org/r/1611045110-682-1-git-send-email-wenxu@ucloud.cnSigned-off-by:
-
Jakub Kicinski authored
After recent changes to the error path of register_netdevice() we no longer need a version of unregister_netdevice_many() which does not set net_todo. We can inline the rollback_registered() functions into respective unregister_netdevice() calls. Link: https://lore.kernel.org/r/20210119202521.3108236-1-kuba@kernel.orgSigned-off-by:
-
Jakub Kicinski authored
Similar to the change for rollback_registered() - rollback_registered_many() was a part of unregister_netdevice_many() minus the net_set_todo(), which is no longer needed. Functionally this patch moves the list_empty() check back after: BUG_ON(dev_boot_phase); ASSERT_RTNL(); but I can't find any reason why that would be an issue. Reviewed-by:
Edwin Peer <edwin.peer@broadcom.com> Signed-off-by:
-
Jakub Kicinski authored
Move rollback_registered_many() and add a temporary forward declaration to make merging the code into unregister_netdevice_many() easier to review. No functional changes. Reviewed-by:
-
Jakub Kicinski authored
rollback_registered() is a local helper, it's common for driver code to call unregister_netdevice_queue(dev, NULL) when they want to unregister netdevices under rtnl_lock. Inline rollback_registered() and adjust the only remaining caller. Reviewed-by:
-
Jakub Kicinski authored
Commit 93ee31f1 ("[NET]: Fix free_netdev on register_netdev failure.") moved net_set_todo() outside of rollback_registered() so that rollback_registered() can be used in the failure path of register_netdevice() but without risking a double free. Since commit cf124db5 ("net: Fix inconsistent teardown and release of private netdev state."), however, we have a better way of handling that condition, since destructors don't call free_netdev() directly. After the change in commit c269a24c ("net: make free_netdev() more lenient with unregistering devices") we can now move net_set_todo() back. Reviewed-by:
-
