- 06 Apr, 2023 1 commit
-
-
Jakub Kicinski authored
Merge tag 'linux-can-next-for-6.4-20230404-2' of git://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can-next Marc Kleine-Budde says: ==================== pull-request: can-next 2023-04-04-2 The first patch is by Oliver Hartkopp and makes the maximum pdu size of the CAN ISOTP protocol configurable. The following 5 patches are by Dario Binacchi and add support for the bxCAN controller by ST. Geert Uytterhoeven's patch for the rcar_canfd driver fixes a sparse warning. Peng Fan's patch adds an optional power-domains property to the flexcan device tree binding. Frank Jungclaus adds support for CAN_CTRLMODE_BERR_REPORTING to the esd_usb driver. The last patch is by Oliver Hartkopp and converts the USB IDs of the kvaser_usb driver to hexadecimal values. * tag 'linux-can-next-for-6.4-20230404-2' of git://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can-next: kvaser_usb: convert USB IDs to hexadecimal values can: esd_usb: Add support for CAN_CTRLMODE_BERR_REPORTING dt-bindings: can: fsl,flexcan: add optional power-domains property can: rcar_canfd: rcar_canfd_probe(): fix plain integer in transceivers[] init can: bxcan: add support for ST bxCAN controller ARM: dts: stm32: add pin map for CAN controller on stm32f4 ARM: dts: stm32: add CAN support on stm32f429 dt-bindings: net: can: add STM32 bxcan DT bindings dt-bindings: arm: stm32: add compatible for syscon gcan node can: isotp: add module parameter for maximum pdu size ==================== Link: https://lore.kernel.org/r/20230404145908.1714400-1-mkl@pengutronix.deSigned-off-by:
Jakub Kicinski <kuba@kernel.org>
-
- 05 Apr, 2023 2 commits
-
-
Simon Horman authored
The arguments passed to the trace events are of type unsigned int, however the signature of the events used __le32 parameters. I may be missing the point here, but sparse flagged this and it does seem incorrect to me. net/qrtr/ns.c: note: in included file (through include/trace/trace_events.h, include/trace/define_trace.h, include/trace/events/qrtr.h): ./include/trace/events/qrtr.h:11:1: warning: cast to restricted __le32 ./include/trace/events/qrtr.h:11:1: warning: restricted __le32 degrades to integer ./include/trace/events/qrtr.h:11:1: warning: restricted __le32 degrades to integer ... (a lot more similar warnings) net/qrtr/ns.c:115:47: expected restricted __le32 [usertype] service net/qrtr/ns.c:115:47: got unsigned int service net/qrtr/ns.c:115:61: warning: incorrect type in argument 2 (different base types) ... (a lot more similar warnings) Fixes: dfddb540 ("net: qrtr: Add tracepoint support") Reviewed-by:
Manivannan Sadhasivam <mani@kernel.org> Signed-off-by:
Simon Horman <horms@kernel.org> Link: https://lore.kernel.org/r/20230402-qrtr-trace-types-v1-1-92ad55008dd3@kernel.orgSigned-off-by:
-
Heiner Kallweit authored
Enable EDPD PHY tunable support for the G12A internal PHY, reusing the recently added tunable support in the smsc driver. Signed-off-by:
Heiner Kallweit <hkallweit1@gmail.com> Reviewed-by:
Simon Horman <simon.horman@corigine.com> Acked-by:
Martin Blumenstingl <martin.blumenstingl@googlemail.com> Link: https://lore.kernel.org/r/8d309575-067c-7321-33cf-6ffac11f7c8d@gmail.comSigned-off-by:
-
- 04 Apr, 2023 13 commits
-
-
Oliver Hartkopp authored
USB IDs are usually represented in 16 bit hexadecimal values. To match the common representation in lsusb and for searching USB IDs in the internet convert the decimal values to lowercase hexadecimal. changes since v1: https://lore.kernel.org/all/20230327175344.4668-1-socketcan@hartkopp.net - drop the aligned block indentation (suggested by Jimmy) - use lowercase hex values (suggested by Alex) Signed-off-by:
Oliver Hartkopp <socketcan@hartkopp.net> Acked-by:
Jimmy Assarsson <extja@kvaser.com> Reviewed-by:
Alexander Dahl <ada@thorsis.com> Link: https://lore.kernel.org/all/20230329090915.3127-1-socketcan@hartkopp.netSigned-off-by:
Marc Kleine-Budde <mkl@pengutronix.de>
-
Frank Jungclaus authored
Announce that the driver supports CAN_CTRLMODE_BERR_REPORTING by means of priv->can.ctrlmode_supported. Until now berr reporting always has been active without taking care of the berr-reporting parameter given to an "ip link set ..." command. Additionally apply some changes to function esd_usb_rx_event(): - If berr reporting is off and it is also no state change, then immediately return. - Unconditionally (even in case of the above "immediate return") store tx- and rx-error counters, so directly use priv->bec.txerr and priv->bec.rxerr instead of intermediate variables. - Not directly related, but to better point out the linkage between a failed alloc_can_err_skb() and stats->rx_dropped++: Move the increment of the rx_dropped statistic counter (back) to directly behind the err_skb allocation. Signed-off-by:
Frank Jungclaus <frank.jungclaus@esd.eu> Link: https://lore.kernel.org/all/20230330184446.2802135-1-frank.jungclaus@esd.euSigned-off-by:
-
Peng Fan authored
Add optional power-domains property for i.MX8 usage. Signed-off-by:
Peng Fan <peng.fan@nxp.com> Acked-by:
Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/all/20230328054602.1974255-1-peng.fan@oss.nxp.comSigned-off-by:
-
Geert Uytterhoeven authored
Fix the following compile warning with C=1: | drivers/net/can/rcar/rcar_canfd.c:1852:59: warning: Using plain integer as NULL pointer Fixes: a0340df7 ("can: rcar_canfd: Add transceiver support") Reported-by:
Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by:
Steen Hegelund <Steen.Hegelund@microchip.com> Link: https://lore.kernel.org/all/7f7b0dde0caa2d2977b4fb5b65b63036e75f5022.1680071972.git.geert+renesas@glider.beSigned-off-by:
-
Paolo Abeni authored
Arseniy Krasnov says: ==================== vsock: return errors other than -ENOMEM to socket this patchset removes behaviour, where error code returned from any transport was always switched to ENOMEM. This works in the same way as patch from Bobby Eshleman: commit c43170b7 ("vsock: return errors other than -ENOMEM to socket"), but for receive calls. VMCI transport is also updated (both tx and rx SOCK_STREAM callbacks), because it returns VMCI specific error code to af_vsock.c (like VMCI_ERROR_*). Tx path is already merged to net, so it was excluded from patchset in v4. At the same time, virtio and Hyper-V transports are using general error codes, so there is no need to update them. vsock_test suite is also updated. Link to v1: https://lore.kernel.org/netdev/97f19214-ba04-c47e-7486-72e8aa16c690@sberdevices.ru/ Link to v2: https://lore.kernel.org/netdev/60abc0da-0412-6e25-eeb0-8e32e3ec21e7@sberdevices.ru/ Link to v3: https://lore.kernel.org/netdev/dead4842-333a-015e-028b-302151336ff9@sberdevices.ru/ ==================== Link: https://lore.kernel.org/r/0d20e25a-640c-72c1-2dcb-7a53a05e3132@sberdevices.ruSigned-off-by:
Paolo Abeni <pabeni@redhat.com>
-
Arseniy Krasnov authored
This updates expected return values for invalid buffer test. Now such values are returned from transport, not from af_vsock.c. Signed-off-by:
Arseniy Krasnov <AVKrasnov@sberdevices.ru> Reviewed-by:
Stefano Garzarella <sgarzare@redhat.com> Signed-off-by:
-
Arseniy Krasnov authored
This removes behaviour, where error code returned from any transport was always switched to ENOMEM. This works in the same way as: commit c43170b7 ("vsock: return errors other than -ENOMEM to socket"), but for receive calls. Signed-off-by:
-
Arseniy Krasnov authored
This adds conversion of VMCI specific error code to general -ENOMEM. It is preparation for the next patch, which changes af_vsock.c behaviour on receive to pass value returned from transport to the user. Signed-off-by:
Vishnu Dasa <vdasa@vmware.com> Reviewed-by:
-
Jakub Kicinski authored
Íñigo Huguet says: ==================== sfc: support unicast PTP Unicast PTP was not working with sfc NICs. The reason was that these NICs don't timestamp all incoming packets, but instead they only timestamp packets of the queues that are selected for that. Currently, only one RX queue is configured for timestamp: the RX queue of the PTP channel. The packets that are put in the PTP RX queue are selected according to firmware filters configured from the driver. Multicast PTP was already working because the needed filters are known in advance, so they're inserted when PTP is enabled. This patches add the ability to dynamically add filters for unicast addresses, extracted from the TX PTP-event packets. Since we don't know in advance how many filters we'll need, some info about the filters need to be saved. This will allow to check if a filter already exists or if a filter is too old and should be removed. Note that the previous point is unnecessary for multicast filters, but I've opted to change how they're handled to match the new unicast's filters to avoid having duplicate insert/remove_filters functions, once for each type of filter. Tested: With ptp4l, all combinations of IPv4/IPv6, master/slave and unicast/multicast Reported-by:
Yalin Li <yalli@redhat.com> ==================== Link: https://lore.kernel.org/r/20230331111404.17256-1-ihuguet@redhat.comSigned-off-by:
-
Íñigo Huguet authored
Filters inserted to support unicast PTP mode might become unused after some time, so we need to remove them to avoid accumulating many of them. Refresh the expiration time of a filter each time it's used. Then check periodically if any filter hasn't been used for a long time (30s) and remove it. Reported-by:
Íñigo Huguet <ihuguet@redhat.com> Reviewed-by:
Edward Cree <ecree.xilinx@gmail.com> Signed-off-by:
-
Íñigo Huguet authored
When sending a PTP event packet, add the correct filters that will make that future incoming unicast PTP event packets will be timestamped. The unicast address for the filter is gotten from the outgoing skb before sending it. Until now they were not timestamped because only filters that match with the PTP multicast addressed were being configured into the NIC for the PTP special channel. Packets received through different channels are not timestamped, getting "received SYNC without timestamp" error in ptp4l. Note that the inserted filters are never removed unless the NIC is stopped or reconfigured, so efx_ptp_stop is called. Removal of old filters will be handled by the next patch. Additionally, cleanup a bit efx_ptp_xmit_skb_mc to use the reverse xmas tree convention and remove an unnecessary assignment to rc variable in void function. Reported-by:
-
Íñigo Huguet authored
Add a second list for unicast filters and generalize the efx_ptp_insert/remove_filters functions to allow acting in any of the 2 lists. No filters for unicast are inserted yet. That will be done in the next patch. The reason to use 2 different lists instead of a single one is that, in next patches, we will want to check if unicast filters are already added and if they're expired. We don't need that for multicast filters. Reported-by:
-
Íñigo Huguet authored
Instead of using a fixed sized array for the PTP filters, use a list. This is not actually necessary at this point because the filters for multicast PTP are a fixed number, but this is a preparation for the following patches adding support for unicast PTP. To avoid confusion with the new struct type efx_ptp_rxfilter, change the name of some local variables from rxfilter to spec, given they're of the type efx_filter_spec. Reported-by:
-
- 03 Apr, 2023 24 commits
-
-
David S. Miller authored
Daniel Golle says: ==================== net: dsa: add support for MT7988 The MediaTek MT7988 SoC comes with a built-in switch very similar to previous MT7530 and MT7531. However, the switch address space is mapped into the SoCs memory space rather than being connected via MDIO. Using MMIO simplifies register access and also removes the need for a bus lock, and for that reason also makes interrupt handling more light-weight. Note that this is different from previous SoCs like MT7621 and MT7623N which also came with an integrated MT7530-like switch which yet had to be accessed via MDIO. Split-off the part of the driver registering an MDIO driver, then add another module acting as MMIO/platform driver. The whole series has been tested on various MediaTek boards: * MT7623A + MT7530 (BPi-R2) * MT7986A + MT7531 (BPi-R3) * MT7988A reference board Changes since v1: * use 'internal' PHY mode where appropriate * use regmap_update_bits in mt7530_rmw * improve dt-bindings Changes since RFC v3: * WARN_ON_ONCE if register read fails * move probing of the reset GPIO and reset controller link out of common probe function, as they are not actually common Changes since RFC v2: * split into many small commits to ease review * introduce helper functions to reduce code duplication * use helpers for locking to make lock-skipping easier and less ugly to implement. * add dt-bindings for mediatek,mt7988-switch Changes since initial RFC: * use regmap for register access and move register access to bus- specific driver * move initialization of MT7531 SGMII PCS to MDIO driver ==================== Signed-off-by:David S. Miller <davem@davemloft.net>
-
Daniel Golle authored
Add documentation for the built-in switch which can be found in the MediaTek MT7988 SoC. Signed-off-by:
Daniel Golle <daniel@makrotopia.org> Signed-off-by:
-
Daniel Golle authored
Add driver for the built-in Gigabit Ethernet switch which can be found in the MediaTek MT7988 SoC. The switch shares most of its design with MT7530 and MT7531, but has it's registers mapped into the SoCs register space rather than being connected externally or internally via MDIO. Introduce a new platform driver to support that. Signed-off-by:
Andrew Lunn <andrew@lunn.ch> Signed-off-by:
-
Daniel Golle authored
As MT7530 and MT7531 internally use 32-bit wide registers, each access to any register of the switch requires several operations on the MDIO bus. Hence if there is congruent access, e.g. due to PCS or PHY polling, this can mess up and interfere with another ongoing register access sequence. However, the MDIO bus mutex is only relevant for MDIO-connected switches. Prepare switches which have there registers directly mapped into the SoCs register space via MMIO which do not require such locking. There we can simply use regmap's default locking mechanism. Hence guard mutex operations to only be performed in case of MDIO connected switches. Signed-off-by:
-
Daniel Golle authored
Split MT7530 switch driver into a common part and a part specific for MDIO connected switches and multi-chip modules. Move MDIO-specific functions to newly introduced mt7530-mdio.c while keeping the common parts in mt7530.c. Introduce new Kconfig symbol CONFIG_NET_DSA_MT7530_MDIO which is implied by CONFIG_NET_DSA_MT7530. Signed-off-by:
-
Daniel Golle authored
MT7988 shares a significant part of the setup function with MT7531. Split-off those parts into a shared function which is going to be used also by mt7988_setup. Signed-off-by:
-
Daniel Golle authored
Move commonly used parts from mt7530_remove into new mt7530_remove_common helper function which will be used by both, mt7530_remove and the to-be-introduced mt7988_remove. Signed-off-by:
-
Daniel Golle authored
Move commonly used parts from mt7530_probe into new mt7530_probe_common helper function which will be used by both, mt7530_probe and the to-be-introduced mt7988_probe. Signed-off-by:
-
Daniel Golle authored
In preparation of splitting mt7530.c into a driver for MDIO-connected as well as MDIO-accessed built-in switches on one hand and MMIO-accessed built-in switches move the p5_inft_modes() function from mt7530.h to mt7530.c. The function is only needed there and will trigger a compiler warning about a defined but unused function otherwise when including mt7530.h in the to-be-introduced bus-specific drivers. Signed-off-by:
-
Daniel Golle authored
As the MDIO bus lock only needs to be involved if actually operating on an MDIO-connected switch we will need to skip locking for built-in switches which are accessed via MMIO. Create helper functions which simplify that upcoming change. Signed-off-by:
-
Daniel Golle authored
Move creating the SGMII PCS from mt753x_setup() to the more appropriate mt7530_probe() function. This is done also in preparation of moving all functions related to MDIO-connected MT753x switches to a separate module. Signed-off-by:
-
Daniel Golle authored
Use regmap API to access the switch register space. Signed-off-by:
-
Daniel Golle authored
Instead of wrapping the locked register accessor functions, use the unlocked variants and add locking wrapper functions to let regmap handle the locking. This is a preparation towards being able to always use regmap to access switch registers instead of open-coded accessor functions. Signed-off-by:
-
Daniel Golle authored
Instead of macro templates use a dedidated function and allocated regmap_config when creating the regmaps for the pcs-mtk-lynxi instances. This is in preparation to switching to use unlocked regmap accessors and have regmap's locking API handle locking for us. Signed-off-by:
-
Daniel Golle authored
Simply returning the negative error value instead of the read value doesn't seem like a good idea. Return 0 instead and add WARN_ON_ONCE(1) so this kind of error will not go unnoticed. Suggested-by:
-
David S. Miller authored
Heiner Kallweit says: ==================== net: phy: smsc: add support for edpd tunable This adds support for the EDPD PHY tunable. Per default EDPD is disabled in interrupt mode, the tunable can be used to override this, e.g. if the link partner doesn't use EDPD. The interval to check for energy can be chosen between 1000ms and 2000ms. Note that this value consists of the 1000ms phylib interval for state machine runs plus the time to wait for energy being detected. ==================== Signed-off-by: -
Heiner Kallweit authored
Enable EDPD PHY tunable support for all drivers using lan87xx_read_status. Signed-off-by:
-
Heiner Kallweit authored
This adds support for the EDPD PHY tunable. Per default EDPD is disabled in interrupt mode, the tunable can be used to override this, e.g. if the link partner doesn't use EDPD. The interval to check for energy can be chosen between 1000ms and 2000ms. Note that this value consists of the 1000ms phylib interval for state machine runs plus the time to wait for energy being detected. v2: - consider that phylib core holds phydev->lock when calling the phy tunable hooks Signed-off-by:
-
Heiner Kallweit authored
Add a member edpd_max_wait_ms to the private data structure in preparation of making the wait period configurable by supporting the edpd phy tunable. v2: - rename constant to EDPD_MAX_WAIT_DFLT_MS Signed-off-by:
-
Heiner Kallweit authored
Add flag edpd_mode_set_by_user in preparation of adding edpd phy tunable support. This flag will allow users to override the default behavior of edpd being disabled if interrupt mode is used. Signed-off-by:
-
Heiner Kallweit authored
Clear edpd_enable if interupt mode is used, this avoids having to check for PHY_POLL multiple times. Signed-off-by:
-
Heiner Kallweit authored
Add helper smsc_phy_config_edpd() and explicitly clear bit MII_LAN83C185_EDPWRDOWN is edpd_enable isn't set. Boot loader may have left whatever value. Signed-off-by:
-
Heiner Kallweit authored
Rename the flag to edpd_enable, as we're not enabling energy but edpd (energy detect power down) mode. In addition change the type to a bit field member in preparation of adding further flags. Signed-off-by:
-
David S. Miller authored
Vladimir Oltean says: ==================== net: Convert dsa_master_ioctl() to netdev notifier This is preparatory work in order for Maxim Georgiev to be able to start the API conversion process of hardware timestamping from ndo_eth_ioctl() to ndo_hwtstamp_set(): https://lore.kernel.org/netdev/20230331045619.40256-1-glipus@gmail.com/ In turn, Maxim Georgiev's work is a preparation so that Köry Maincent is able to make the active hardware timestamping layer selectable by user space. https://lore.kernel.org/netdev/20230308135936.761794-1-kory.maincent@bootlin.com/ So, quite some dependency chain. Before this patch set, DSA prevented the conversion of any networking driver from the ndo_eth_ioctl() API to the ndo_hwtstamp_set() API, because it wanted to validate the hwtstamping settings on the DSA master, and it was only coded up to do this using the old API. After this patch set, a new netdev notifier exists, which does not depend on anything that would constitute the "soon-to-be-legacy" API, but rather, it uses a newly introduced struct kernel_hwtstamp_config, and it doesn't issue any ioctl at all, being thus compatible both with ndo_eth_ioctl(), and with the not-yet-introduced, but now possible, ndo_hwtstamp_set(). ==================== Signed-off-by:
-
