- 27 Jan, 2021 20 commits
-
-
Marc Kleine-Budde authored
In Classical CAN there are RTR frames. RTR frames have the RTR bit set, may have a dlc != 0, but contain no data. This patch changes the RX-path to no copy any data for RTR frames, so that the data field in the CAN frame stays 0x0. Link: https://lore.kernel.org/r/20210114153448.1506901-4-mkl@pengutronix.deSigned-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
-
Marc Kleine-Budde authored
CAN-FD frames have only specific frame length (0, 1, 2, 3, 4, 5, 6, 7, 8, 12, 16, 20, 24, 32, 48, 64). A CAN-FD frame provided by user space might not cover the whole CAN-FD frame. To avoid sending garbage over the CAN bus the driver pads the CAN frame with 0x0 (if MCP251XFD_SANITIZE_CAN is activated). This patch cleans up the pad len calculation. Rounding to full u32 brings no benefit, in case of CRC transfers, the hw_tx_obj->data is not aligned to u32 anyway. Link: https://lore.kernel.org/r/20210114153448.1506901-3-mkl@pengutronix.deSigned-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
-
Marc Kleine-Budde authored
This patch replaces an open coded check if the TX ring is full by a check if mcp251xfd_get_tx_free() returns 0. Link: https://lore.kernel.org/r/20210114153448.1506901-2-mkl@pengutronix.deSigned-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
-
Su Yanjun authored
The sizeof(u32) is hardcoded. It's better to use the config value from the regmap. It increases the size of target object, but it's flexible when new mcp chip need other val_bytes. Link: https://lore.kernel.org/r/20210122081334.213957-1-suyanjun218@gmail.comSigned-off-by: Su Yanjun <suyanjun218@gmail.com> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
-
Tom Rix authored
This change fixes the checkpatch warning described in this commit commit cbacb5ab ("docs: printk-formats: Stop encouraging use of unnecessary %h[xudi] and %hh[xudi]") Standard integer promotion is already done and %hx and %hhx is useless so do not encourage the use of %hh[xudi] or %h[xudi]. Link: https://lore.kernel.org/r/20210124150916.1920434-1-trix@redhat.comSigned-off-by: Tom Rix <trix@redhat.com> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
-
Marc Kleine-Budde authored
In commit 652562e5 ("can: length: can_fd_len2dlc(): simplify length calculcation") the readability of the code degraded and became more error prone. To counteract this, partially convert that patch and replace open coded values (of the original code) with proper defines. Fixes: 652562e5 ("can: length: can_fd_len2dlc(): simplify length calculcation") Cc: Vincent MAILHOL <mailhol.vincent@wanadoo.fr> Link: https://lore.kernel.org/r/20210118201346.79422-1-socketcan@hartkopp.netSigned-off-by: Oliver Hartkopp <socketcan@hartkopp.net> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
-
Vincent Mailhol authored
The can_get_state_str() function is also relevant to the drivers. Export the symbol and make it visible in the can/dev.h header. Link: https://lore.kernel.org/r/20210119170355.12040-1-mailhol.vincent@wanadoo.frSigned-off-by: Vincent Mailhol <mailhol.vincent@wanadoo.fr> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
-
Marc Kleine-Budde authored
This patch fixes two typos found by codespell. Fixes: 812f0116 ("can: flexcan: add CAN wakeup function for i.MX8QM") Link: https://lore.kernel.org/r/20210127085529.2768537-2-mkl@pengutronix.deSigned-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
-
Marc Kleine-Budde authored
This patch fixes a typo found by codespell. Fixes: 94c23097 ("can: gw: support modification of Classical CAN DLCs") Link: https://lore.kernel.org/r/20210127085529.2768537-3-mkl@pengutronix.deSigned-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
-
Jakub Kicinski authored
Emil Renner Berthing says: ==================== net: usbnet: convert to new tasklet API This converts the usbnet driver to use the new tasklet API introduced in commit 12cc923f ("tasklet: Introduce new initialization API") It is split into two commits for ease of reviewing. ==================== Link: https://lore.kernel.org/r/20210123173221.5855-1-esmil@mailme.dkSigned-off-by: Jakub Kicinski <kuba@kernel.org>
-
Emil Renner Berthing authored
This converts the driver to use the new tasklet API introduced in commit 12cc923f ("tasklet: Introduce new initialization API") Signed-off-by: Emil Renner Berthing <kernel@esmil.dk> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
-
Emil Renner Berthing authored
Initialize tasklet using tasklet_init() rather than open-coding it. Signed-off-by: Emil Renner Berthing <kernel@esmil.dk> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
-
Jakub Kicinski authored
Rasmus Villemoes says: ==================== net: dsa: mv88e6xxx: remove some 6250-specific methods v2: - resend now that the bug-fix patch (87fe0436, "net: dsa: mv88e6xxx: also read STU state in mv88e6250_g1_vtu_getnext") is in net and also merged to net-next. - include various tags in patch 1. - add second similar patch for loadpurge. ==================== Link: https://lore.kernel.org/r/20210125150449.115032-1-rasmus.villemoes@prevas.dkSigned-off-by: Jakub Kicinski <kuba@kernel.org>
-
Rasmus Villemoes authored
Apart from the mask used to get the high bits of the fid, mv88e6185_g1_vtu_loadpurge() and mv88e6250_g1_vtu_loadpurge() are identical. Since the entry->fid passed in should never exceed the number of databases, we can simply use the former as-is as replacement for the latter. Suggested-by: Tobias Waldekranz <tobias@waldekranz.com> Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk> Reviewed-by: Vladimir Oltean <olteanv@gmail.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
-
Rasmus Villemoes authored
mv88e6250_g1_vtu_getnext is almost identical to mv88e6185_g1_vtu_getnext, except for the 6250 only having 64 databases instead of 256. We can reduce code duplication by simply masking off the extra two garbage bits when assembling the fid from VTU op [3:0] and [11:8]. Reviewed-by: Tobias Waldekranz <tobias@waldekranz.com> Tested-by: Tobias Waldekranz <tobias@waldekranz.com> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk> Reviewed-by: Vladimir Oltean <olteanv@gmail.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
-
Seth David Schoen authored
Add selftests for kernel behavior with regard to various classes of unallocated/reserved IPv4 addresses, checking whether or not these addresses can be assigned as unicast addresses on links and used in routing. Expect the current kernel behavior at the time of this patch. That is: * 0/8 and 240/4 may be used as unicast, with the exceptions of 0.0.0.0 and 255.255.255.255; * the lowest address in a subnet may only be used as a broadcast address; * 127/8 may not be used as unicast (the route_localnet option, which is disabled by default, still leaves it treated slightly specially); * 224/4 may not be used as unicast. Signed-off-by: Seth David Schoen <schoen@loyalty.org> Suggested-by: John Gilmore <gnu@toad.com> Acked-by: Dave Taht <dave.taht@gmail.com> Reviewed-by: David Ahern <dsahern@kernel.org> Link: https://lore.kernel.org/r/20210126040834.GR24989@frotz.zork.netSigned-off-by: Jakub Kicinski <kuba@kernel.org>
-
Arnd Bergmann authored
When TLS is a module, the built-in bonding driver may cause a link error: x86_64-linux-ld: drivers/net/bonding/bond_main.o: in function `bond_start_xmit': bond_main.c:(.text+0xc451): undefined reference to `tls_validate_xmit_skb' Add a dependency to avoid the problem. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Link: https://lore.kernel.org/r/20210125113209.2248522-1-arnd@kernel.orgSigned-off-by: Jakub Kicinski <kuba@kernel.org>
-
Michael Chan authored
Use the various netif_level() helpers to simplify the C code. This was suggested by Joe Perches. Cc: Joe Perches <joe@perches.com> Signed-off-by: Michael Chan <michael.chan@broadcom.com> Link: https://lore.kernel.org/r/1611642024-3166-1-git-send-email-michael.chan@broadcom.comSigned-off-by: Jakub Kicinski <kuba@kernel.org>
-
Dongliang Mu authored
Every line of code should start with tab (8 characters) Signed-off-by: Dongliang Mu <mudongliangabcd@gmail.com> Link: https://lore.kernel.org/r/20210123051102.1091541-1-mudongliangabcd@gmail.comSigned-off-by: Jakub Kicinski <kuba@kernel.org>
-
Nikolay Aleksandrov authored
Fix the messed up indentation in br_multicast_eht_set_entry_lookup(). Fixes: baa74d39 ("net: bridge: multicast: add EHT source set handling functions") Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: Nikolay Aleksandrov <nikolay@nvidia.com> Link: https://lore.kernel.org/r/20210125082040.13022-1-razor@blackwall.orgSigned-off-by: Jakub Kicinski <kuba@kernel.org>
-
- 26 Jan, 2021 20 commits
-
-
wengjianfeng authored
change 'regster' to 'register' Signed-off-by: wengjianfeng <wengjianfeng@yulong.com> Acked-by: Mark Greer <mgreer@animalcreek.com> Link: https://lore.kernel.org/r/20210123082550.3748-1-samirweng1979@163.comSigned-off-by: Jakub Kicinski <kuba@kernel.org>
-
wengjianfeng authored
change 'paquet' to 'packet' Signed-off-by: wengjianfeng <wengjianfeng@yulong.com> Link: https://lore.kernel.org/r/20210123074835.9448-1-samirweng1979@163.comSigned-off-by: Jakub Kicinski <kuba@kernel.org>
-
Jakub Kicinski authored
Michael Chan says: ==================== bnxt_en: Error recovery improvements. This series contains a number of improvements in the area of error recovery. Most error recovery scenarios are tightly coordinated with the firmware. A number of patches add retry logic to establish connection with the firmware if there are indications that the firmware is still alive and will likely transition back to the normal state. Some patches speed up the recovery process and make it more reliable. There are some cleanup patches as well. ==================== Link: https://lore.kernel.org/r/1611558501-11022-1-git-send-email-michael.chan@broadcom.comSigned-off-by: Jakub Kicinski <kuba@kernel.org>
-
Michael Chan authored
Once the firmware fatal condition is detected, we should cease comminication with the firmware and hardware quickly even if there are many completion entries in the completion rings. This will speed up the recovery process and prevent further I/Os that may cause further exceptions. Do not proceed in the NAPI poll function if fatal condition is detected. Call napi_complete() and return without arming interrupts. Cleanup of all rings and reset are imminent. Reviewed-by: Pavan Chebbi <pavan.chebbi@broadcom.com> Reviewed-by: Vasundhara Volam <vasundhara-v.volam@broadcom.com> Reviewed-by: Edwin Peer <edwin.peer@broadcom.com> Signed-off-by: Michael Chan <michael.chan@broadcom.com> Acked-by: Willem de Bruijn <willemb@google.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
-
Michael Chan authored
Combine the three netdev_warn() calls into a single call, printed at the NETIF_MSG_HW log level. Reviewed-by: Vasundhara Volam <vasundhara-v.volam@broadcom.com> Signed-off-by: Michael Chan <michael.chan@broadcom.com> Acked-by: Willem de Bruijn <willemb@google.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
-
Michael Chan authored
In the event of a fatal firmware error, firmware will notify the host and then it will proceed to do core reset when it sees that all functions have disabled Bus Master. To prevent Master Aborts and other hard errors, we need to quiesce all activities in addition to disabling Bus Master before the chip goes into core reset. Reviewed-by: Edwin Peer <edwin.peer@broadcom.com> Reviewed-by: Vasundhara Volam <vasundhara-v.volam@broadcom.com> Signed-off-by: Michael Chan <michael.chan@broadcom.com> Acked-by: Willem de Bruijn <willemb@google.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
-
Michael Chan authored
In the event of a fatal firmware error, we want to disable IRQ early in the recovery sequence. This change will allow it to be called safely again as part of the normal shutdown sequence. Reviewed-by: Edwin Peer <edwin.peer@broadcom.com> Reviewed-by: Vasundhara Volam <vasundhara-v.volam@broadcom.com> Signed-off-by: Michael Chan <michael.chan@broadcom.com> Acked-by: Willem de Bruijn <willemb@google.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
-
Michael Chan authored
Up until now, we don't need to keep track of this state because NAPI is always enabled once and disabled once during bring up and shutdown. For better error recovery in subsequent patches, we want to quiesce the device earlier during fatal error conditions. The normal shutdown sequence will disable NAPI again and the flag will prevent disabling NAPI twice. Reviewed-by: Pavan Chebbi <pavan.chebbi@broadcom.com> Reviewed-by: Andy Gospodarek <gospo@broadcom.com> Reviewed-by: Edwin Peer <edwin.peer@broadcom.com> Reviewed-by: Vasundhara Volam <vasundhara-v.volam@broadcom.com> Signed-off-by: Michael Chan <michael.chan@broadcom.com> Acked-by: Willem de Bruijn <willemb@google.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
-
Michael Chan authored
This code to check if we have reached the maximum wait time after firmware reset is used multiple times. Add a helper function to do this. Reviewed-by: Edwin Peer <edwin.peer@broadcom.com> Signed-off-by: Michael Chan <michael.chan@broadcom.com> Acked-by: Willem de Bruijn <willemb@google.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
-
Vasundhara Volam authored
Firmware may be in the middle of reset when the driver tries to do ifup. In that case, firmware will return a special error code and the driver will retry 10 times with 50 msecs delay after each retry. Signed-off-by: Vasundhara Volam <vasundhara-v.volam@broadcom.com> Signed-off-by: Michael Chan <michael.chan@broadcom.com> Acked-by: Willem de Bruijn <willemb@google.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
-
Edwin Peer authored
Drawing a hard line on aborted resets prevents a NIC open in some scenarios that may otherwise be recoverable. For example, if a firmware recovery happened while a PF was down and an attempt was made to bring up an associated VF in this state, then it was impossible to ever bring up this VF without a rebind or reload of its driver. Attempt to reinitialize the firmware when an aborted reset (or failed init after a reset) is discovered during open - it may succeed. Also take care to allow the user to retry opening the NIC even after an aborted reset. Signed-off-by: Edwin Peer <edwin.peer@broadcom.com> Signed-off-by: Michael Chan <michael.chan@broadcom.com> Acked-by: Willem de Bruijn <willemb@google.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
-
Edwin Peer authored
Firmware is capable of generating asynchronous debug notifications. The event data is opaque to the driver and is simply logged. Debug notifications can be enabled by turning on hardware status messages using the ethtool msglvl interface. Reviewed-by: Pavan Chebbi <pavan.chebbi@broadcom.com> Signed-off-by: Edwin Peer <edwin.peer@broadcom.com> Signed-off-by: Michael Chan <michael.chan@broadcom.com> Acked-by: Willem de Bruijn <willemb@google.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
-
Vasundhara Volam authored
The timeout period for firmware messages is passed to the driver from the firmware in the response of the first command. This timeout period is multiplied by a factor for certain long running commands such as NVRAM commands. In some cases, the timeout period can become really long and it can cause hung task warnings if firmware has crashed or is not responding. To avoid such long delays, cap all firmware commands to a max timeout value of 40 seconds. Reviewed-by: Edwin Peer <edwin.peer@broadcom.com> Signed-off-by: Vasundhara Volam <vasundhara-v.volam@broadcom.com> Signed-off-by: Michael Chan <michael.chan@broadcom.com> Acked-by: Willem de Bruijn <willemb@google.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
-
Vasundhara Volam authored
If firmware is in reset or in bad state, it won't be able to return VPD data. Move bnxt_vpd_read_info() until after bnxt_fw_init_one_p1() successfully returns. By then we would have established proper communications with the firmware. Reviewed-by: Edwin Peer <edwin.peer@broadcom.com> Signed-off-by: Vasundhara Volam <vasundhara-v.volam@broadcom.com> Signed-off-by: Michael Chan <michael.chan@broadcom.com> Acked-by: Willem de Bruijn <willemb@google.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
-
Michael Chan authored
The first HWRM_VER_GET message to firmware during probe may timeout if firmware is under reset. This can happen during hot-plug for example. On P5 and newer chips, we can check if firmware is in the boot stage by reading a status register. Retry 5 times if the status register shows that firmware is not ready and not in error state. Reviewed-by: Edwin Peer <edwin.peer@broadcom.com> Signed-off-by: Michael Chan <michael.chan@broadcom.com> Acked-by: Willem de Bruijn <willemb@google.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
-
Edwin Peer authored
Add missing support for handling NO_MASTER crashes while ports are administratively down (ifdown). On some SoC platforms, the driver needs to assist the firmware to recover from a crash via OP-TEE. This is performed in a similar fashion to what is done during driver probe. Signed-off-by: Edwin Peer <edwin.peer@broadcom.com> Signed-off-by: Michael Chan <michael.chan@broadcom.com> Acked-by: Willem de Bruijn <willemb@google.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
-
Michael Chan authored
Define macros to check for the various states in the lower 16 bits of the health register. Replace the C code that checks for these values with the newly defined macros. Reviewed-by: Edwin Peer <edwin.peer@broadcom.com> Signed-off-by: Michael Chan <michael.chan@broadcom.com> Acked-by: Willem de Bruijn <willemb@google.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
-
Michael Chan authored
Updates to backing store APIs, QoS profiles, and push buffer initial index support. Since the new HWRM_FUNC_BACKING_STORE_CFG message size has increased, we need to add some compat. logic to fall back to the smaller legacy size if firmware cannot accept the larger message size. The new fields added to the structure are not used yet. Signed-off-by: Michael Chan <michael.chan@broadcom.com> Acked-by: Willem de Bruijn <willemb@google.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
-
Jakub Kicinski authored
DENG Qingfang says: ==================== dsa: add MT7530 GPIO support MT7530's LED controller can be used as GPIO controller. Add support for it. ==================== Link: https://lore.kernel.org/r/20210125044322.6280-1-dqfext@gmail.comSigned-off-by: Jakub Kicinski <kuba@kernel.org>
-
DENG Qingfang authored
MT7530's LED controller can drive up to 15 LED/GPIOs. Add support for GPIO control and allow users to use its GPIOs by setting gpio-controller property in device tree. Signed-off-by: DENG Qingfang <dqfext@gmail.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
-