- 28 Mar, 2023 17 commits
-
-
Dario Binacchi authored
Add support for the basic extended CAN controller (bxCAN) found in many low- to middle-end STM32 SoCs. It supports the Basic Extended CAN protocol versions 2.0A and B with a maximum bit rate of 1 Mbit/s. The controller supports two channels (CAN1 as primary and CAN2 as secondary) and the driver can enable either or both of the channels. They share some of the required logic (e. g. clocks and filters), and that means you cannot use the secondary CAN without enabling some hardware resources managed by the primary CAN. Each channel has 3 transmit mailboxes, 2 receive FIFOs with 3 stages and 28 scalable filter banks. It also manages 4 dedicated interrupt vectors: - transmit interrupt - FIFO 0 receive interrupt - FIFO 1 receive interrupt - status change error interrupt Driver uses all 3 available mailboxes for transmission and FIFO 0 for reception. Rx filter rules are configured to the minimum. They accept all messages and assign filter 0 to CAN1 and filter 14 to CAN2 in identifier mask mode with 32 bits width. It enables and uses transmit, receive buffers for FIFO 0 and error and status change interrupts. Signed-off-by:
Dario Binacchi <dario.binacchi@amarulasolutions.com> Reviewed-by:
Vincent Mailhol <mailhol.vincent@wanadoo.fr> Link: https://lore.kernel.org/all/20230328073328.3949796-6-dario.binacchi@amarulasolutions.comSigned-off-by:
Marc Kleine-Budde <mkl@pengutronix.de>
-
Dario Binacchi authored
Add pin configurations for using CAN controller on stm32f469-disco board. They are located on the Arduino compatible connector CN5 (CAN1) and on the extension connector CN12 (CAN2). Signed-off-by:
-
Dario Binacchi authored
Add support for bxcan (Basic eXtended CAN controller) to STM32F429. The chip contains two CAN peripherals, CAN1 the primary and CAN2 the secondary, that share some of the required logic like clock and filters. This means that the secondary CAN can't be used without the primary CAN. Signed-off-by:
-
Dario Binacchi authored
Add documentation of device tree bindings for the STM32 basic extended CAN (bxcan) controller. Signed-off-by:
Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/all/20230328073328.3949796-3-dario.binacchi@amarulasolutions.com [mkl: drop unneeded quotes] Signed-off-by:
-
Dario Binacchi authored
Since commit ad440432 ("dt-bindings: mfd: Ensure 'syscon' has a more specific compatible") it is required to provide at least 2 compatibles string for syscon node. This patch documents the new compatible for stm32f4 SoC to support global/shared CAN registers access for bxCAN controllers. Signed-off-by:
-
Oliver Hartkopp authored
With ISO 15765-2:2016 the PDU size is not limited to 2^12 - 1 (4095) bytes but can be represented as a 32 bit unsigned integer value which allows 2^32 - 1 bytes (~4GB). The use-cases like automotive unified diagnostic services (UDS) and flashing of ECUs still use the small static buffers which are provided at socket creation time. When a use-case requires to transfer PDUs up to 1025 kByte the maximum PDU size can now be extended by setting the module parameter max_pdu_size. The extended size buffers are only allocated on a per-socket/connection base when needed at run-time. changes since v2: https://lore.kernel.org/all/20230313172510.3851-1-socketcan@hartkopp.net - use ARRAY_SIZE() to reference DEFAULT_MAX_PDU_SIZE only at one place changes since v1: https://lore.kernel.org/all/20230311143446.3183-1-socketcan@hartkopp.net - limit the minimum 'max_pdu_size' to 4095 to maintain the classic behavior before ISO 15765-2:2016 Link: https://github.com/raspberrypi/linux/issues/5371Signed-off-by:
Oliver Hartkopp <socketcan@hartkopp.net> Link: https://lore.kernel.org/all/20230326115911.15094-1-socketcan@hartkopp.netSigned-off-by:
-
Jakub Kicinski authored
Merge tag 'linux-can-next-for-6.4-20230327' of git://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can-next Marc Kleine-Budde says: ==================== pull-request: can-next 2023-03-27 The first 2 patches by Geert Uytterhoeven add transceiver support and improve the error messages in the rcar_canfd driver. Cai Huoqing contributes 3 patches which remove a redundant call to pci_clear_master() in the c_can, ctucanfd and kvaser_pciefd driver. Frank Jungclaus's patch replaces the struct esd_usb_msg with a union in the esd_usb driver to improve readability. Markus Schneider-Pargmann contributes 5 patches to improve the performance in the m_can driver, especially for SPI attached controllers like the tcan4x5x. * tag 'linux-can-next-for-6.4-20230327' of git://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can-next: can: m_can: Keep interrupts enabled during peripheral read can: m_can: Disable unused interrupts can: m_can: Remove double interrupt enable can: m_can: Always acknowledge all interrupts can: m_can: Remove repeated check for is_peripheral can: esd_usb: Improve code readability by means of replacing struct esd_usb_msg with a union can: kvaser_pciefd: Remove redundant pci_clear_master can: ctucanfd: Remove redundant pci_clear_master can: c_can: Remove redundant pci_clear_master can: rcar_canfd: Improve error messages can: rcar_canfd: Add transceiver support ==================== Link: https://lore.kernel.org/r/20230327073354.1003134-1-mkl@pengutronix.deSigned-off-by:
Jakub Kicinski <kuba@kernel.org>
-
Jakub Kicinski authored
Shay Agroskin says: ==================== Add tx push buf len param to ethtool This patchset adds a new sub-configuration to ethtool get/set queue params (ethtool -g) called 'tx-push-buf-len'. This configuration specifies the maximum number of bytes of a transmitted packet a driver can push directly to the underlying device ('push' mode). The motivation for pushing some of the bytes to the device has the advantages of - Allowing a smart device to take fast actions based on the packet's header - Reducing latency for small packets that can be copied completely into the device This new param is practically similar to tx-copybreak value that can be set using ethtool's tunable but conceptually serves a different purpose. While tx-copybreak is used to reduce the overhead of DMA mapping and makes no sense to use if less than the whole segment gets copied, tx-push-buf-len allows to improve performance by analyzing the packet's data (usually headers) before performing the DMA operation. The configuration can be queried and set using the commands: $ ethtool -g [interface] # ethtool -G [interface] tx-push-buf-len [number of bytes] This patchset also adds support for the new configuration in ENA driver for which this parameter ensures efficient resources management on the device side. ==================== Link: https://lore.kernel.org/r/20230323163610.1281468-1-shayagr@amazon.comSigned-off-by: -
Shay Agroskin authored
LLQ is auto enabled by the device and disabling it isn't supported on new ENA generations while on old ones causes sub-optimal performance. This patch adds advertisement of push-mode when LLQ mode is used, but rejects an attempt to modify it. Reviewed-by:
Michal Kubiak <michal.kubiak@intel.com> Signed-off-by:
Shay Agroskin <shayagr@amazon.com> Signed-off-by:
-
Shay Agroskin authored
The ENA driver allows for two distinct values for the number of bytes of the packet's payload that can be written directly to the device. For a value of 224 the driver turns on Large LLQ Header mode in which the first 224 of the packet's payload are written to the LLQ. Reviewed-by:
-
Shay Agroskin authored
With the ability to modify LLQ entry size, the size of packet's payload that can be written directly to the device changes. This patch makes the driver recalculate this information every device negotiation (also called device reset). Reviewed-by:
-
David Arinzon authored
Allow configuring the device with large LLQ headers. The Low Latency Queue (LLQ) allows the driver to write the first N bytes of the packet, along with the rest of the TX descriptors directly into device (N can be either 96 or 224 for large LLQ headers configuration). Having L4 TCP/UDP headers contained in the first 96 bytes of the packet is required to get maximum performance from the device. Reviewed-by:
Simon Horman <simon.horman@corigine.com> Reviewed-by:
David Arinzon <darinzon@amazon.com> Signed-off-by:
-
Shay Agroskin authored
Move ena_calc_io_queue_size() implementation closer to the file's beginning so that it can be later called from ena_device_init() function without adding a function declaration. Also add an empty line at some spots to separate logical blocks in funcitons. Reviewed-by:
-
Shay Agroskin authored
This attribute, which is part of ethtool's ring param configuration allows the user to specify the maximum number of the packet's payload that can be written directly to the device. Example usage: # ethtool -G [interface] tx-push-buf-len [number of bytes] Co-developed-by: -
Shay Agroskin authored
Similar to NL_SET_ERR_MSG_FMT, add a macro which sets netlink policy error message with a format string. Signed-off-by:
-
Tom Rix authored
clang with W=1 reports drivers/net/ethernet/qlogic/qed/qed_ll2.c:649:6: error: variable 'num_ooo_add_to_peninsula' set but not used [-Werror,-Wunused-but-set-variable] u32 num_ooo_add_to_peninsula = 0, cid; ^ This variable is not used so remove it. Signed-off-by:Tom Rix <trix@redhat.com> Reviewed-by:
-
Eric Dumazet authored
Currently, MAX_SKB_FRAGS value is 17. For standard tcp sendmsg() traffic, no big deal because tcp_sendmsg() attempts order-3 allocations, stuffing 32768 bytes per frag. But with zero copy, we use order-0 pages. For BIG TCP to show its full potential, we add a config option to be able to fit up to 45 segments per skb. This is also needed for BIG TCP rx zerocopy, as zerocopy currently does not support skbs with frag list. We have used MAX_SKB_FRAGS=45 value for years at Google before we deployed 4K MTU, with no adverse effect, other than a recent issue in mlx4, fixed in commit 26782aad ("net/mlx4: MLX4_TX_BOUNCE_BUFFER_SIZE depends on MAX_SKB_FRAGS") Back then, goal was to be able to receive full size (64KB) GRO packets without the frag_list overhead. Note that /proc/sys/net/core/max_skb_frags can also be used to limit the number of fragments TCP can use in tx packets. By default we keep the old/legacy value of 17 until we get more coverage for the updated values. Sizes of struct skb_shared_info on 64bit arches MAX_SKB_FRAGS | sizeof(struct skb_shared_info): ============================================== 17 320 21 320+64 = 384 25 320+128 = 448 29 320+192 = 512 33 320+256 = 576 37 320+320 = 640 41 320+384 = 704 45 320+448 = 768 This inflation might cause problems for drivers assuming they could pack both the incoming packet (for MTU=1500) and skb_shared_info in half a page, using build_skb(). v3: fix build error when CONFIG_NET=n v2: fix two build errors assuming MAX_SKB_FRAGS was "unsigned long" Signed-off-by:
Eric Dumazet <edumazet@google.com> Reviewed-by:
Nikolay Aleksandrov <razor@blackwall.org> Reviewed-by:
Jason Xing <kerneljasonxing@gmail.com> Link: https://lore.kernel.org/r/20230323162842.1935061-1-eric.dumazet@gmail.comSigned-off-by:
-
- 27 Mar, 2023 23 commits
-
-
Heiner Kallweit authored
This fixes the following warning when compiled with GCC 12.2.0 and W=1. net/core/dev_ioctl.c:475: warning: Function parameter or member 'data' not described in 'dev_ioctl' Signed-off-by:
Heiner Kallweit <hkallweit1@gmail.com> Reviewed-by:
David S. Miller <davem@davemloft.net>
-
Heiner Kallweit authored
Use devm_clk_get_optional_enabled to simplify the code. Signed-off-by:
Florian Fainelli <f.fainelli@gmail.com> Signed-off-by:
-
Jakub Kicinski authored
I was a bit too optimistic in commit bf51d277 ("tools: ynl: fix get_mask utility routine"), not every mask we use is necessarily coming from an enum of type "flags". We also allow flipping an enum into flags on per-attribute basis. That's done by the 'enum-as-flags' property of an attribute. Restore this functionality, it's not currently used by any in-tree family. Signed-off-by:
-
Jakub Kicinski authored
Other tests set up the connection fully on both ends before communicating any data. Add a test which will queue up TLS records to TCP before the TLS ULP is installed. Signed-off-by:
-
Michal Michalik authored
While testing the tool I noticed we miss the u16 type on payload create. On the code inspection it turned out we miss also u64 - add them. We also miss the decoding of u16 despite the fact `NlAttr` class supports it - add it. Signed-off-by:
Michal Michalik <michal.michalik@intel.com> Acked-by:
-
David S. Miller authored
Sean Anderson says: ==================== net: sunhme: Probe/IRQ cleanups Well, I've had these patches kicking around in my tree since last October, so I guess I had better get around to posting them. This series is mainly a cleanup/consolidation of the probe process, with some interrupt changes as well. Some of these changes are SBUS- (AKA SPARC-) specific, so this should really get some testing there as well to ensure nothing breaks. I've CC'd a few SPARC mailing lists in hopes that someone there can try this out. I also have an SBUS card I ordered by mistake if anyone has a SPARC computer but lacks this card. Changes in v4: - Tweak variable order for yuletide - Move uninitialized return to its own commit - Use correct SBUS/PCI accessors - Rework hme_version to set the default in pci/sbus_probe and override it (if necessary) in common_probe Changes in v3: - Incorperate a fix from another series into this commit Changes in v2: - Move happy_meal_begin_auto_negotiation earlier and remove forward declaration - Make some more includes common - Clean up mac address init - Inline error returns ==================== Signed-off-by: -
Sean Anderson authored
Most of the second half of the PCI/SBUS probe functions are the same. Consolidate them into a common function. Signed-off-by:
Sean Anderson <seanga2@gmail.com> Reviewed-by:
-
Sean Anderson authored
The err_out label used to have cleanup. Now that it just returns, inline it everywhere. Signed-off-by:
-
Sean Anderson authored
Clean up some oddities suggested during review. Signed-off-by:
-
Sean Anderson authored
The mac address initialization is braodly the same between PCI and SBUS, and one was clearly copied from the other. Consolidate them. We still have to have some ifdefs because pci_(un)map_rom is only implemented for PCI, and idprom is only implemented for SPARC. Signed-off-by:
-
Sean Anderson authored
The PCI half of this driver was converted in commit 914d9b27 ("sunhme: switch to devres"). Do the same for the SBUS half. Signed-off-by:
-
Sean Anderson authored
Alphabetize includes to make it clearer where to add new ones. Signed-off-by:
-
Sean Anderson authored
Instead of registering one interrupt handler for all four SBUS Quattro HMEs, let each HME register its own handler. To make this work, we don't handle the IRQ if none of the status bits are set. This reduces the complexity of the driver, and makes it easier to ensure things happen before/after enabling IRQs. I'm not really sure why we request IRQs in two different places (and leave them running after removing the driver!). A lot of things in this driver seem to just be crusty, and not necessarily intentional. I'm assuming that's the case here as well. This really needs to be tested by someone with an SBUS Quattro card. Signed-off-by:
-
Sean Anderson authored
The sunhme driver never used the hardware MII polling feature. Even the if-def'd out happy_meal_poll_start was removed by 2002 [1]. Remove the various places in the driver which needlessly guard against MII interrupts which will never be enabled. [1] https://lwn.net/2002/0411/a/2.5.8-pre3.php3Signed-off-by:
-
Sean Anderson authored
If we've tried regular autonegotiation and forcing the link mode, just restart autonegotiation instead of reinitializing the whole NIC. Signed-off-by:
-
Sean Anderson authored
Fix an uninitialized return code if we never found a qfe slot. It would be a bug if we ever got into this situation, but it's good to return something tracable. Fixes: acb3f35f ("sunhme: forward the error code from pci_enable_device()") Reported-by:
kernel test robot <lkp@intel.com> Reported-by:
Dan Carpenter <error27@gmail.com> Signed-off-by:
-
David S. Miller authored
Veerasenareddy Burru says: ==================== octeon_ep: deferred probe and mailbox Implement Deferred probe, mailbox enhancements and heartbeat monitor. v4 -> v5: - addressed review comments https://lore.kernel.org/all/20230323104703.GD36557@unreal/ replaced atomic_inc() + atomic_read() with atomic_inc_return(). v3 -> v4: - addressed review comments on v3 https://lore.kernel.org/all/20230214051422.13705-1-vburru@marvell.com/ - 0004-xxx.patch v3 is split into 0004-xxx.patch and 0005-xxx.patch in v4. - API changes to accept function ID are moved to 0005-xxx.patch. - fixed rct violations. - reverted newly added changes that do not yet have use cases. v2 -> v3: - removed SRIOV VF support changes from v2, as new drivers which use ndo_get_vf_xxx() and ndo_set_vf_xxx() are not accepted. https://lore.kernel.org/all/20221207200204.6819575a@kernel.org/ Will implement VF representors and submit again. - 0007-xxx.patch and 0008-xxx.patch from v2 are removed and 0009-xxx.patch in v2 is now 0007-xxx.patch in v3. - accordingly, changed title for cover letter. v1 -> v2: - remove separate workqueue task to wait for firmware ready. instead defer probe when firmware is not ready. Reported-by:Leon Romanovsky <leon@kernel.org> - This change has resulted in update of 0001-xxx.patch and all other patches in the patchset. ==================== Signed-off-by:
-
Veerasenareddy Burru authored
Monitor periodic heartbeat messages from device firmware. Presence of heartbeat indicates the device is active and running. If the heartbeat is missed for configured interval indicates firmware has crashed and device is unusable; in this case, PF driver stops and uninitialize the device. Signed-off-by:
Veerasenareddy Burru <vburru@marvell.com> Signed-off-by:
Abhijit Ayarekar <aayarekar@marvell.com> Signed-off-by:
-
Veerasenareddy Burru authored
Update control mailbox API to include function id in get stats and link info. Signed-off-by:
-
Veerasenareddy Burru authored
Add asynchronous notification support to the control mailbox. Signed-off-by:
-
Veerasenareddy Burru authored
Extend control command structure to include vfid and update APIs to accept VF ID. Signed-off-by:
-
Veerasenareddy Burru authored
Enhance control mailbox protocol to support following - separate command and response queues * command queue to send control commands to firmware. * response queue to receive responses and notifications from firmware. - variable size messages using scatter/gather Signed-off-by: -
Veerasenareddy Burru authored
Add control mailbox support for multiple PFs. Update control mbox base address calculation based on PF function link. Signed-off-by:
-
