summaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2023-07-28ynl: expose xdp-zc-max-segsStanislav Fomichev1-2/+3
Also rename it to dashes, to match the rest. And fix unrelated spelling error while we're at it. Signed-off-by: Stanislav Fomichev <sdf@google.com> Reviewed-by: Jakub Kicinski <kuba@kernel.org> Link: https://lore.kernel.org/r/20230727163001.3952878-2-sdf@google.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-07-28Merge branch '100GbE' of git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/nexDavid S. Miller16-135/+2128
t-queue Tony Nguyen says: ==================== ice: Implement support for SRIOV + LAG Dave Ertman says: Implement support for SRIOV VF's on interfaces that are in an aggregate interface. The first interface added into the aggregate will be flagged as the primary interface, and this primary interface will be responsible for managing the VF's resources. VF's created on the primary are the only VFs that will be supported on the aggregate. Only Active-Backup mode will be supported and only aggregates whose primary interface is in switchdev mode will be supported. The ice-lag DDP must be loaded to support this feature. Additional restrictions on what interfaces can be added to the aggregate and still support SRIOV VFs are: - interfaces have to all be on the same physical NIC - all interfaces have to have the same QoS settings - interfaces have to have the FW LLDP agent disabled - only the primary interface is to be put into switchdev mode - no more than two interfaces in the aggregate --- v2: - Move NULL check for q_ctx in ice_lag_qbuf_recfg() earlier (patch 6) v1: https://lore.kernel.org/netdev/20230726182141.3797928-1-anthony.l.nguyen@intel.com/ ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
2023-07-28IPv6: add extack info for IPv6 address add/deleteHangbin Liu4-27/+59
Add extack info for IPv6 address add/delete, which would be useful for users to understand the problem without having to read kernel code. Suggested-by: Beniamino Galvani <bgalvani@redhat.com> Reviewed-by: Ido Schimmel <idosch@nvidia.com> Reviewed-by: David Ahern <dsahern@kernel.org> Signed-off-by: Hangbin Liu <liuhangbin@gmail.com> Reviewed-by: Simon Horman <simon.horman@corigine.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2023-07-28Merge branch 'selftest-ptp'David S. Miller1-2/+71
Alex Maftei says: ==================== selftests/ptp: Add support for new timestamp IOCTLs PTP_SYS_OFFSET_EXTENDED was added in November 2018 in 361800876f80 (" ptp: add PTP_SYS_OFFSET_EXTENDED ioctl") and PTP_SYS_OFFSET_PRECISE was added in February 2016 in 719f1aa4a671 ("ptp: Add PTP_SYS_OFFSET_PRECISE for driver crosstimestamping") The PTP selftest code is lacking support for these two IOCTLS. This short series of patches adds support for them. Changes in v2: - Fixed rebase issues (v1 somehow ended up with patch 1 being from the first manual split of my changes and patch 2 being from rebase 2 out of 3) - Rebased on top of net-next ==================== Acked-by: Richard Cochran <richardcochran@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2023-07-28selftests/ptp: Add -X option for testing PTP_SYS_OFFSET_PRECISEAlex Maftei1-1/+30
The -X option was chosen because X looks like a cross, and the underlying callback is 'get cross timestamp'. Signed-off-by: Alex Maftei <alex.maftei@amd.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2023-07-28selftests/ptp: Add -x option for testing PTP_SYS_OFFSET_EXTENDEDAlex Maftei1-2/+42
The -x option (where 'x' stands for eXtended) takes an argument which represents the number of samples to request from the PTP device. The help message will display the maximum number of samples allowed. Providing an invalid argument will also display the maximum number of samples allowed. Signed-off-by: Alex Maftei <alex.maftei@amd.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2023-07-28Merge tag 'linux-can-next-for-6.6-20230728' of ↵David S. Miller20-124/+225
git://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can-next linux-can-next-for-6.6-20230728 Marc Kleine-Budde says: ==================== Hello netdev-team, this is a pull request of 21 patches for net-next/master. The 1st patch is by Gerhard Uttenthaler, which adds Gerhard as the maintainer ems_pci driver. Peter Seiderer's patch removes a unused function from the peak_usb driver. The next 4 patches are by John Watts and add support for the sun4i_can driver on the Allwinner D1. Rob Herring's patch corrects the DT includes in various CAN drivers. Followed by 14 patches from me concerning the gs_usb driver. The first 11 are various cleanups consisting of coding style improvements, error path printout cleanups, and removal of unneeded usb_kill_anchored_urbs(). The last 3 convert the driver to use NAPI to avoid out-of-order reception of CAN frames. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
2023-07-28Merge branch 'sfc-siena-next'David S. Miller24-4020/+42
Martin Habets says: ==================== sfc: Remove Siena bits from sfc.ko Last year we split off Siena into it's own driver under directory siena. This patch series removes the now unused Falcon and Siena code from sfc.ko. No functional changes are intended. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
2023-07-28sfc: Remove vfdi.hMartin Habets1-252/+0
It was only used for Siena SRIOV, so nothing includes it any more in this directory. Signed-off-by: Martin Habets <habetsm.xilinx@gmail.com> Acked-by: Edward Cree <ecree.xilinx@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2023-07-28sfc: Cleanups in io.hMartin Habets2-80/+9
Most of the Falcon locking description does not apply to EF10. Signed-off-by: Martin Habets <habetsm.xilinx@gmail.com> Acked-by: Edward Cree <ecree.xilinx@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2023-07-28sfc: Miscellaneous comment removalsMartin Habets4-21/+2
Remove comments that only apply to Falcon and Siena. Signed-off-by: Martin Habets <habetsm.xilinx@gmail.com> Acked-by: Edward Cree <ecree.xilinx@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2023-07-28sfc: Remove struct efx_special_bufferMartin Habets8-75/+25
The attributes index and entries are no longer needed, so use struct efx_buffer instead. next_buffer_table was also Siena specific. Removed some checkpatch warnings. Signed-off-by: Martin Habets <habetsm.xilinx@gmail.com> Acked-by: Edward Cree <ecree.xilinx@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2023-07-28sfc: Filter cleanups for Falcon and SienaMartin Habets2-23/+0
unicast_filter and multicast_hash are no longer needed. Signed-off-by: Martin Habets <habetsm.xilinx@gmail.com> Acked-by: Edward Cree <ecree.xilinx@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2023-07-28sfc: Remove some NIC type indirections that are no longer neededMartin Habets5-19/+0
The special handling for SRIOV reset and FLR is not needed on EF10. Signed-off-by: Martin Habets <habetsm.xilinx@gmail.com> Acked-by: Edward Cree <ecree.xilinx@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2023-07-28sfc: Remove PTP code for SienaMartin Habets2-226/+1
rx_tx_inline is now always true. The special event list is no longer needed, event handling is always inline. Event MCDI_EVENT_CODE_PTP_RX is no longer needed. Signed-off-by: Martin Habets <habetsm.xilinx@gmail.com> Acked-by: Edward Cree <ecree.xilinx@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2023-07-28sfc: Remove EFX_REV_SIENA_A0Martin Habets2-9/+1
The workarounds for bug 8568 and 17213 are no longer needed. Signed-off-by: Martin Habets <habetsm.xilinx@gmail.com> Acked-by: Edward Cree <ecree.xilinx@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2023-07-28sfc: Remove support for siena high priority queueMartin Habets4-50/+2
This also removes TC support code, since that was never supported for EF10. TC support for EF100 is not handled from efx.c. Signed-off-by: Martin Habets <habetsm.xilinx@gmail.com> Acked-by: Edward Cree <ecree.xilinx@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2023-07-28sfc: Remove siena_nic_data and statsMartin Habets1-95/+0
These are no longer used, and the two Siena specific functions are no longer present in sfc.ko. Signed-off-by: Martin Habets <habetsm.xilinx@gmail.com> Acked-by: Edward Cree <ecree.xilinx@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2023-07-28sfc: Remove falcon referencesMartin Habets6-3170/+2
Siena was using functions from the Falcon architecture. These start with the efx_farch prefix. Now that both of these are in separate modules the references are no longer used in the sfc.ko module. Signed-off-by: Martin Habets <habetsm.xilinx@gmail.com> Acked-by: Edward Cree <ecree.xilinx@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2023-07-28Merge branch 'rxfh-custom-rss'David S. Miller4-54/+86
Joe Damato says: ==================== rxfh with custom RSS fixes Greetings: Welcome to v2, now via net-next. No functional changes; only style changes (see the summary below). While attempting to get the RX flow hash key for a custom RSS context on my mlx5 NIC, I got an error: $ sudo ethtool -u eth1 rx-flow-hash tcp4 context 1 Cannot get RX network flow hashing options: Invalid argument I dug into this a bit and noticed two things: 1. ETHTOOL_GRXFH supports custom RSS contexts, but ETHTOOL_SRXFH does not. I moved the copy logic out of ETHTOOL_GRXFH and into a helper so that both ETHTOOL_{G,S}RXFH now call it, which fixes ETHTOOL_SRXFH. This is patch 1/2. 2. mlx5 defaulted to RSS context 0 for both ETHTOOL_{G,S}RXFH paths. I have modified the driver to support custom contexts for both paths. It is now possible to get and set the flow hash key for custom RSS contexts with mlx5. This is patch 2/2. See commit messages for more details. Thanks. v2: - Rebased on net-next - Adjusted arguments of mlx5e_rx_res_rss_get_hash_fields and mlx5e_rx_res_rss_set_hash_fields to move rss_idx next to the rss argument - Changed return value of both mlx5e_rx_res_rss_get_hash_fields and mlx5e_rx_res_rss_set_hash_fields to -ENOENT when the rss entry is NULL - Changed order of local variables in mlx5e_get_rss_hash_opt and mlx5e_set_rss_hash_opt ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
2023-07-28net/mlx5: Fix flowhash key set/get for custom RSSJoe Damato3-17/+48
mlx5 flow hash field retrieval and set only worked on the default RSS context as of commit f01cc58c18d6 ("net/mlx5e: Support multiple RSS contexts"), not custom RSS contexts. For example, before this patch attempting to retrieve the flow hash fields for RSS context 1 fails: $ sudo ethtool -u eth1 rx-flow-hash tcp4 context 1 Cannot get RX network flow hashing options: Invalid argument This patch fixes getting and setting the flow hash fields for contexts other than the default context. Getting the flow hash fields for RSS context 1: $ sudo ethtool -u eth1 rx-flow-hash tcp4 context 1 For RSS context 1: TCP over IPV4 flows use these fields for computing Hash flow key: IP DA Now, setting the flash hash fields to a custom value: $ sudo ethtool -U eth1 rx-flow-hash tcp4 sdfn context 1 And retrieving them again: $ sudo ethtool -u eth1 rx-flow-hash tcp4 context 1 For RSS context 1: TCP over IPV4 flows use these fields for computing Hash flow key: IP SA IP DA L4 bytes 0 & 1 [TCP/UDP src port] L4 bytes 2 & 3 [TCP/UDP dst port] Signed-off-by: Joe Damato <jdamato@fastly.com> Reviewed-by: Tariq Toukan <tariqt@nvidia.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2023-07-28net: ethtool: Unify ETHTOOL_{G,S}RXFH rxnfc copyJoe Damato1-37/+38
ETHTOOL_GRXFH correctly copies in the full struct ethtool_rxnfc when FLOW_RSS is set; ETHTOOL_SRXFH needs a similar code path to handle the FLOW_RSS case so that ethtool can set the flow hash for custom RSS contexts (if supported by the driver). The copy code from ETHTOOL_GRXFH has been pulled out in to a helper so that it can be called in both ETHTOOL_{G,S}RXFH code paths. Acked-by: Edward Cree <ecree.xilinx@gmail.com> Signed-off-by: Joe Damato <jdamato@fastly.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2023-07-28Merge patch series "can: gs_usb: convert to NAPI"Marc Kleine-Budde8-39/+116
Marc Kleine-Budde <mkl@pengutronix.de> says: Traditionally USB drivers used netif_rx to pass the received CAN frames/skbs to the network stack. In netif_rx() the skbs are queued to the local CPU. If IRQs are handled in round robin, CAN frames may be delivered out-of-order to user space. To support devices without timestamping the TX path of the rx-offload helper is cleaned up and extended: - rename rx_offload_get_echo_skb() -> can_rx_offload_get_echo_skb_queue_timestamp() - add can_rx_offload_get_echo_skb_queue_tail() The last patch converts the gs_usb driver to NAPI with the rx-offload helper. Link: https://lore.kernel.org/all/20230718-gs_usb-rx-offload-v2-0-716e542d14d5@pengutronix.de Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2023-07-28can: gs_usb: convert to NAPI/rx-offload to avoid OoO receptionMarc Kleine-Budde2-19/+67
The driver used to pass received CAN frames/skbs to the network stack with netif_rx(). In netif_rx() the skbs are queued to the local CPU. If IRQs are handled in round robin, OoO packets may occur. To avoid out-of-order reception convert the driver from netif_rx() to NAPI. For USB devices with timestamping support use the rx-offload helper can_rx_offload_queue_timestamp() for the RX, and can_rx_offload_get_echo_skb_queue_timestamp() for the TX path. Devices without timestamping support use can_rx_offload_queue_tail() for RX, and can_rx_offload_get_echo_skb_queue_tail() for the TX path. Link: https://lore.kernel.org/all/559D628C.5020100@hartkopp.net Link: https://github.com/candle-usb/candleLight_fw/issues/166 Link: https://lore.kernel.org/all/20230718-gs_usb-rx-offload-v2-3-716e542d14d5@pengutronix.de Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2023-07-28can: rx-offload: add can_rx_offload_get_echo_skb_queue_tail()Marc Kleine-Budde2-2/+30
Add can_rx_offload_get_echo_skb_queue_tail(). This function addds the echo skb at the end of rx-offload the queue. This is intended for devices without timestamp support. Link: https://lore.kernel.org/all/20230718-gs_usb-rx-offload-v2-2-716e542d14d5@pengutronix.de Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2023-07-28can: rx-offload: rename rx_offload_get_echo_skb() -> ↵Marc Kleine-Budde6-18/+19
can_rx_offload_get_echo_skb_queue_timestamp() Rename the rx_offload_get_echo_skb() function to can_rx_offload_get_echo_skb_queue_timestamp(), since it inserts the echo skb into the rx-offload queue sorted by timestamp. This is a preparation for adding can_rx_offload_get_echo_skb_queue_tail(), which adds the echo skb to the end of the queue. This is intended for devices that do not support timestamps. Link: https://lore.kernel.org/all/20230718-gs_usb-rx-offload-v2-1-716e542d14d5@pengutronix.de Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2023-07-28Merge patch series "can: gs_usb-cleanups: various clenaups"Marc Kleine-Budde1-60/+52
Marc Kleine-Budde <mkl@pengutronix.de> says: This is a cleanup series of the gs_usb driver. Align the driver more to the kernel coding style, make use of locally defined variables, clean up printouts in various error paths, remove some not needed usb_kill_anchored_urbs() from the shut down paths. Link: https://lore.kernel.org/all/20230718-gs_usb-cleanups-v1-0-c3b9154ec605@pengutronix.de Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2023-07-28can: gs_usb: gs_usb_disconnect(): remove not needed usb_kill_anchored_urbs()Marc Kleine-Budde1-1/+0
In gs_usb_disconnect(), all channels are destroyed first, then all anchored RX URBs (parent->rx_submitted) are disposed with usb_kill_anchored_urbs(). The call to usb_kill_anchored_urbs() is not needed, as gs_destroy_candev() of the last active channel already disposes the RX URBS. Remove not needed call to usb_kill_anchored_urbs() from gs_usb_disconnect(). Link: https://lore.kernel.org/all/20230718-gs_usb-cleanups-v1-11-c3b9154ec605@pengutronix.de Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2023-07-28can: gs_usb: gs_destroy_candev(): remove not needed usb_kill_anchored_urbs()Marc Kleine-Budde1-1/+0
In gs_destroy_candev(), the netdev is unregistered first, then all anchored TX URBs (dev->tx_submitted) are disposed with usb_kill_anchored_urbs(). The call to usb_kill_anchored_urbs() is not needed, as unregister_candev() calls gs_can_close(), which already disposes the TX URBS. Remove not needed call to usb_kill_anchored_urbs() from gs_destroy_candev(). Link: https://lore.kernel.org/all/20230718-gs_usb-cleanups-v1-10-c3b9154ec605@pengutronix.de Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2023-07-28can: gs_usb: gs_can_close(): don't complain about failed device reset during ↵Marc Kleine-Budde1-3/+1
ndo_stop When the USB device is unplugged, gs_can_close() (which implements the struct net_device_ops::ndo_stop callback) is called. In this function an attempt is made to shut down the USB device with a USB control message. For disconnected devices this will fail and a warning message is printed. Silence the driver by removing the printout of the error message if the reset command fails. Link: https://lore.kernel.org/all/20230718-gs_usb-cleanups-v1-9-c3b9154ec605@pengutronix.de Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2023-07-28can: gs_usb: gs_can_start_xmit(), gs_can_open(): clean up printouts in error ↵Marc Kleine-Budde1-6/+3
path Remove unnecessary "out of memory" message from the error path of gs_can_start_xmit() and gs_can_open(). Convert the printout in case of a failing usb_submit_urb() in gs_can_open() from numbers to human readable error codes. Link: https://lore.kernel.org/all/20230718-gs_usb-cleanups-v1-8-c3b9154ec605@pengutronix.de Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2023-07-28can: gs_usb: gs_usb_receive_bulk_callback(): count RX overflow errors also ↵Marc Kleine-Budde1-2/+3
in case of OOM In case of an RX overflow error from the CAN controller and an OOM where no skb can be allocated, the error counters are not incremented. Fix this by first incrementing the error counters and then allocate the skb. Fixes: d08e973a77d1 ("can: gs_usb: Added support for the GS_USB CAN devices") Link: https://lore.kernel.org/all/20230718-gs_usb-cleanups-v1-7-c3b9154ec605@pengutronix.de Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2023-07-28can: gs_usb: gs_usb_receive_bulk_callback(): make use of statsMarc Kleine-Budde1-5/+5
Make use the previously assigned variable stats instead of using netdev->stats. Link: https://lore.kernel.org/all/20230718-gs_usb-cleanups-v1-6-c3b9154ec605@pengutronix.de Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2023-07-28can: gs_usb: gs_usb_receive_bulk_callback(): make use of netdevMarc Kleine-Budde1-2/+2
Make use the previously assigned variable netdev instead of using dev->netdev. Link: https://lore.kernel.org/all/20230718-gs_usb-cleanups-v1-5-c3b9154ec605@pengutronix.de Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2023-07-28can: gs_usb: uniformly use "parent" as variable name for struct gs_usbMarc Kleine-Budde1-31/+31
To ease readability and maintainability uniformly use the variable name "parent" for the struct gs_usb in the gs_usb driver. Link: https://lore.kernel.org/all/20230718-gs_usb-cleanups-v1-4-c3b9154ec605@pengutronix.de Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2023-07-28can: gs_usb: gs_usb_set_timestamp(): remove return statements form void functionMarc Kleine-Budde1-2/+0
Remove the return statements from void gs_usb_set_timestamp() function, as it's not generally useful. Link: https://lore.kernel.org/all/20230718-gs_usb-cleanups-v1-3-c3b9154ec605@pengutronix.de Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2023-07-28can: gs_usb: gs_usb_probe(): align block commentMarc Kleine-Budde1-2/+2
Indent block comment so that it aligns the * on each line. Link: https://lore.kernel.org/all/20230718-gs_usb-cleanups-v1-2-c3b9154ec605@pengutronix.de Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2023-07-28can: gs_usb: remove leading space from goto labelsMarc Kleine-Budde1-6/+6
Remove leading spaces from goto labels in accordance with the kernel encoding style. Link: https://lore.kernel.org/all/20230718-gs_usb-cleanups-v1-1-c3b9154ec605@pengutronix.de Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2023-07-28can: Explicitly include correct DT includes, part 2Rob Herring8-8/+0
The DT of_device.h and of_platform.h date back to the separate of_platform_bus_type before it as merged into the regular platform bus. As part of that merge prepping Arm DT support 13 years ago, they "temporarily" include each other. They also include platform_device.h and of.h. As a result, there's a pretty much random mix of those include files used throughout the tree. In order to detangle these headers and replace the implicit includes with struct declarations, users need to explicitly include the correct includes. Signed-off-by: Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/all/20230724211841.805053-1-robh@kernel.org Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2023-07-28Merge patch series "Add support for Allwinner D1 CAN controllers"Marc Kleine-Budde4-7/+55
John Watts <contact@jookia.org> says: This patch series adds support for the Allwinner D1 CAN controllers. It requires adding a new device tree compatible and driver support to work around some hardware quirks. This has been tested on the Mango Pi MQ Dual running a T113 and a Lichee Panel 86 running a D1. Changes in v2: - Re-ordered patches to work with bisecting - Fixed device tree label underscores - Fixed email headers - Link to v1: https://lore.kernel.org/all/20230715112523.2533742-1-contact@jookia.org Link: https://lore.kernel.org/all/20230721221552.1973203-2-contact@jookia.org Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2023-07-28can: peak_usb: remove unused/legacy peak_usb_netif_rx() functionPeter Seiderer2-15/+0
Remove unused/legacy peak_usb_netif_rx() function (not longer used since commit 28e0a70cede3 ("can: peak_usb: CANFD: store 64-bits hw timestamps"). Signed-off-by: Peter Seiderer <ps.report@gmx.net> Link: https://lore.kernel.org/all/20230721180758.26199-1-ps.report@gmx.net Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2023-07-28can: sun4i_can: Add support for the Allwinner D1John Watts2-3/+13
The controllers present in the D1 are extremely similar to the R40 and require the same reset quirks, but An extra quirk is needed to support receiving packets. Signed-off-by: John Watts <contact@jookia.org> Link: https://lore.kernel.org/all/20230721221552.1973203-6-contact@jookia.org Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2023-07-28MAINTAINERS: Add myself as maintainer of the ems_pci.c driverGerhard Uttenthaler1-0/+7
At the suggestion of Marc Kleine-Budde [1], I add myself as maintainer of the ems_pci.c driver. [1] https://lore.kernel.org/all/20230720-purplish-quizzical-247024e66671-mkl@pengutronix.de Signed-off-by: Gerhard Uttenthaler <uttenthaler@ems-wuensche.com> Link: https://lore.kernel.org/all/20230720144032.28960-1-uttenthaler@ems-wuensche.com Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2023-07-28can: sun4i_can: Add acceptance register quirkJohn Watts1-2/+8
The Allwinner D1's CAN controllers have the ACPC and ACPM registers moved down. Compensate for this by adding an offset quirk for the acceptance registers. Signed-off-by: John Watts <contact@jookia.org> Link: https://lore.kernel.org/all/20230721221552.1973203-5-contact@jookia.org Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2023-07-28riscv: dts: allwinner: d1: Add CAN controller nodesJohn Watts1-0/+30
The Allwinner D1, T113 provide two CAN controllers that are variants of the R40 controller. I have tested support for these controllers on two boards: - A Lichee Panel RV 86 Panel running a D1 chip - A Mango Pi MQ Dual running a T113-s3 chip Both of these fully support both CAN controllers. Signed-off-by: John Watts <contact@jookia.org> Link: https://lore.kernel.org/all/20230721221552.1973203-4-contact@jookia.org Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2023-07-28dt-bindings: net: can: Add support for Allwinner D1 CAN controllerJohn Watts1-2/+4
The Allwinner D1 has two CAN controllers, both a variant of the R40 controller. Unfortunately the registers for the D1 controllers are moved around enough to be incompatible and require a new compatible. Introduce the "allwinner,sun20i-d1-can" compatible to support this. Signed-off-by: John Watts <contact@jookia.org> Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://lore.kernel.org/all/20230721221552.1973203-3-contact@jookia.org Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2023-07-28net: Explicitly include correct DT includesRob Herring90-92/+88
The DT of_device.h and of_platform.h date back to the separate of_platform_bus_type before it as merged into the regular platform bus. As part of that merge prepping Arm DT support 13 years ago, they "temporarily" include each other. They also include platform_device.h and of.h. As a result, there's a pretty much random mix of those include files used throughout the tree. In order to detangle these headers and replace the implicit includes with struct declarations, users need to explicitly include the correct includes. Acked-by: Alex Elder <elder@linaro.org> Reviewed-by: Bhupesh Sharma <bhupesh.sharma@linaro.org> Reviewed-by: Wei Fang <wei.fang@nxp.com> Signed-off-by: Rob Herring <robh@kernel.org> Reviewed-by: Simon Horman <simon.horman@corigine.com> Link: https://lore.kernel.org/r/20230727014944.3972546-1-robh@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-07-28Revert "net: stmmac: correct MAC propagation delay"Jakub Kicinski4-56/+0
This reverts commit 20bf98c94146eb6fe62177817cb32f53e72dd2e8. Richard raised concerns about correctness of the code on previous generations of the HW. Fixes: 20bf98c94146 ("net: stmmac: correct MAC propagation delay") Link: https://lore.kernel.org/all/ZMGIuKVP7BEotbrn@hoboy.vegasvil.org/ Link: https://lore.kernel.org/r/20230726224054.3241127-1-kuba@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-07-28Merge branch 'net-stmmac-increase-clk_ptp_ref-rate'Jakub Kicinski3-3/+22
Andrew Halaney says: ==================== net: stmmac: Increase clk_ptp_ref rate This series aims to increase the clk_ptp_ref rate to get the best possible PTP timestamping resolution possible. Some modified disclosure about my development/testing process from the RFC/RFT v1 follows. Disclosure: I don't know much about PTP beyond what you can google in an afternoon, don't have access to documentation about the stmmac IP, and have only tested that (based on code comments and git commit history) the programming of the subsecond register (and the clock rate) makes more sense with these changes. Qualcomm has tested a similar change offlist, verifying PTP more formally as I understand it. The last version was an RFC/RFT, but I didn't get a lot of confirmation that doing patch 3 in that series (essentially setting clk_ptp_ref to whatever its max value is) for the whole stmmac ecosystem was a safe idea. So I am erring on the side of caution and doing this for the Qualcomm platform only. See v1 for an approach that would apply to all stmmac platform drivers with clk_ptp_ref. v1: https://lore.kernel.org/netdev/20230711205732.364954-1-ahalaney@redhat.com/ ==================== Link: https://lore.kernel.org/r/20230725211853.895832-2-ahalaney@redhat.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-07-28net: stmmac: dwmac-qcom-ethqos: Use max frequency for clk_ptp_refAndrew Halaney1-0/+18
Qualcomm clocks can set their frequency to a variety of levels generally. Let's use the max for clk_ptp_ref to ensure the best timestamping resolution possible. Without this, the default value of the clock is used. For sa8775p-ride this is 19.2 MHz, far less than the 230.4 MHz possible. Reviewed-by: Simon Horman <simon.horman@corigine.com> Signed-off-by: Andrew Halaney <ahalaney@redhat.com> Link: https://lore.kernel.org/r/20230725211853.895832-4-ahalaney@redhat.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>