- 05 Oct, 2023 27 commits
-
-
Marc Kleine-Budde authored
This is a cleanup patch, no functional change intended. As at91_irq_err_frame() is called from the IRQ handler move it in front of the IRQ handler next to at91_irq_err(). Link: https://lore.kernel.org/all/20231005-at91_can-rx_offload-v2-20-9987d53600e0@pengutronix.deSigned-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
-
Marc Kleine-Budde authored
This is a preparation patch to convert the driver to the rx-offload helper. In rx-offload RX, TX-done and CAN error handling are done in the IRQ handler, SKB are pushed to the network stack in the NAPI poll function. Move the CAN frame error handling from the NAPI function at91_poll() to the IRQ handler at91_poll(). To reflect this change, rename at91_poll_err() to at91_irq_err_frame(). Link: https://lore.kernel.org/all/20231005-at91_can-rx_offload-v2-19-9987d53600e0@pengutronix.deSigned-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
-
Marc Kleine-Budde authored
at91_poll_err() allocates a can error SKB, to inform the user space about the CAN error. Then it fills the SKB with information the error information and increases the net device error stats. In case no SBK can be allocated (e.g. due to an OOM) or the NAPI quota is 0 the function is left early and no stats are updated. This is not helpful to the user, as there is no information about the faulty CAN bus. Increase the error stats even if no quota is left or no SKB can be allocated. While there treat No-Acknowledgment as a bus error, too. Link: https://lore.kernel.org/all/20231005-at91_can-rx_offload-v2-18-9987d53600e0@pengutronix.deSigned-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
-
Marc Kleine-Budde authored
This is a preparation patch for the cleanup of at91_poll_err(). Fold at91_poll_err_frame() into at91_poll_err() so that it can be easier modified. Link: https://lore.kernel.org/all/20231005-at91_can-rx_offload-v2-17-9987d53600e0@pengutronix.deSigned-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
-
Marc Kleine-Budde authored
Add support for Linux-PHY based CAN transceivers. Link: https://lore.kernel.org/all/20231005-at91_can-rx_offload-v2-16-9987d53600e0@pengutronix.deSigned-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
-
Marc Kleine-Budde authored
If request_irq() fails, forward the return value. Link: https://lore.kernel.org/all/20231005-at91_can-rx_offload-v2-15-9987d53600e0@pengutronix.deSigned-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
-
Marc Kleine-Budde authored
In at91_chip_start() first all IRQs are disabled, they do not have to be disabled again at the end of the function before the requested IRQs are enabled. Remove the 2nd disable of all IRQs at the end of the function. Link: https://lore.kernel.org/all/20231005-at91_can-rx_offload-v2-14-9987d53600e0@pengutronix.deSigned-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
-
Marc Kleine-Budde authored
This message isn't really helpful for the general reader of the kernel logs, so should not be printed with info level. Link: https://lore.kernel.org/all/20231005-at91_can-rx_offload-v2-13-9987d53600e0@pengutronix.deSigned-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
-
Marc Kleine-Budde authored
To increase code readability, use the same naming of the counters for the TX FIFO as in the other drivers implementing the same algorithm. Link: https://lore.kernel.org/all/20231005-at91_can-rx_offload-v2-12-9987d53600e0@pengutronix.deSigned-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
-
Marc Kleine-Budde authored
Since 6388b396 ("can: at91_can: add support for the AT91SAM9X5 SOCs") the number of mailboxes used for RX and TX is no longer constant, but depends on the IP core used. Remove the fixed number of mailboxes from the comment. Link: https://lore.kernel.org/all/20231005-at91_can-rx_offload-v2-11-9987d53600e0@pengutronix.deSigned-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
-
Marc Kleine-Budde authored
Add more register definitions found in the data sheet. Link: https://lore.kernel.org/all/20231005-at91_can-rx_offload-v2-10-9987d53600e0@pengutronix.deSigned-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
-
Marc Kleine-Budde authored
Use FIELD_PREP() to access the individual fields of the MCR register. Link: https://lore.kernel.org/all/20231005-at91_can-rx_offload-v2-9-9987d53600e0@pengutronix.deSigned-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
-
Marc Kleine-Budde authored
Use FIELD_PREP() to access the individual fields of the MSR register. Link: https://lore.kernel.org/all/20231005-at91_can-rx_offload-v2-8-9987d53600e0@pengutronix.deSigned-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
-
Marc Kleine-Budde authored
Use FIELD_PREP() and FIELD_GET() to access the individual fields of the MID register. Link: https://lore.kernel.org/all/20231005-at91_can-rx_offload-v2-7-9987d53600e0@pengutronix.deSigned-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
-
Marc Kleine-Budde authored
Use FIELD_PREP() to access the individual fields of the MMR register. Link: https://lore.kernel.org/all/20231005-at91_can-rx_offload-v2-6-9987d53600e0@pengutronix.deSigned-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
-
Marc Kleine-Budde authored
Use FIELD_GET() to access the individual fields of the ECR register. Link: https://lore.kernel.org/all/20231005-at91_can-rx_offload-v2-5-9987d53600e0@pengutronix.deSigned-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
-
Marc Kleine-Budde authored
Use FIELD_PREP() to access the individual fields of the BR register. Link: https://lore.kernel.org/all/20231005-at91_can-rx_offload-v2-4-9987d53600e0@pengutronix.deSigned-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
-
Marc Kleine-Budde authored
Improve code readability by removing one level of indention. If a mailbox is not ready, continue the loop early. Link: https://lore.kernel.org/all/20231005-at91_can-rx_offload-v2-3-9987d53600e0@pengutronix.deSigned-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
-
Marc Kleine-Budde authored
Convert the driver to use a consistent indention of one space after defines and in enums. That makes it easier to add new defines, which will be done in the coming patches. Link: https://lore.kernel.org/all/20231005-at91_can-rx_offload-v2-2-9987d53600e0@pengutronix.deSigned-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
-
Marc Kleine-Budde authored
can: dev: add can_state_get_by_berr_counter() to return the CAN state based on the current error counters Some CAN controllers do not have a register that contains the current CAN state, but only a register that contains the error counters. Introduce a new function can_state_get_by_berr_counter() that returns the current TX and RX state depending on the provided CAN bit error counters. Link: https://lore.kernel.org/all/20231005-at91_can-rx_offload-v2-1-9987d53600e0@pengutronix.deSigned-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
-
Marc Kleine-Budde authored
Marc Kleine-Budde <mkl@pengutronix.de> says: There are 2 BUG_ON() in the CAN dev helpers. During the update/test of the at91_can driver to rx-offload the one in can_restart() was triggered, due to a race condition in can_restart() and a hardware limitation of the at91_can IP core. This series fixes the race condition, replaces BUG_ON() with an error message, and does some cleanup. Finally, the BUG_ON() in can_put_echo_skb() is also replaced with error handling. Changes in v2: - 4/5: move "Restarted" debug message and stats after successful restart (Thanks Vincent) - Link to v1: https://lore.kernel.org/all/20231004-can-dev-fix-can-restart-v1-0-2e52899eaaf5@pengutronix.de Link: https://lore.kernel.org/all/20231005-can-dev-fix-can-restart-v2-0-91b5c1fd922c@pengutronix.deSigned-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
-
Marc Kleine-Budde authored
If the "struct can_priv::echoo_skb" is accessed out of bounds, this would cause a kernel crash. Instead, issue a meaningful warning message and return with an error. Fixes: a6e4bc53 ("can: make the number of echo skb's configurable") Link: https://lore.kernel.org/all/20231005-can-dev-fix-can-restart-v2-5-91b5c1fd922c@pengutronix.deReviewed-by: Vincent Mailhol <mailhol.vincent@wanadoo.fr> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
-
Marc Kleine-Budde authored
Move the debug message "restarted" and the CAN restart stats_after_ the successful restart of the CAN device, because the restart may fail. While there update the error message from printing the error number to printing symbolic error names. Link: https://lore.kernel.org/all/20231005-can-dev-fix-can-restart-v2-4-91b5c1fd922c@pengutronix.deReviewed-by: Vincent Mailhol <mailhol.vincent@wanadoo.fr> [mkl: mention stats in subject and description, too] Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
-
Marc Kleine-Budde authored
Reverse the logic in the if statement and eliminate the need for a goto to simplify code readability. Link: https://lore.kernel.org/all/20231005-can-dev-fix-can-restart-v2-3-91b5c1fd922c@pengutronix.deReviewed-by: Vincent Mailhol <mailhol.vincent@wanadoo.fr> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
-
Marc Kleine-Budde authored
This race condition was discovered while updating the at91_can driver to use can_bus_off(). The following scenario describes how the converted at91_can driver would behave. When a CAN device goes into BUS-OFF state, the driver usually stops/resets the CAN device and calls can_bus_off(). This function sets the netif carrier to off, and (if configured by user space) schedules a delayed work that calls can_restart() to restart the CAN device. The can_restart() function first checks if the carrier is off and triggers an error message if the carrier is OK. Then it calls the driver's do_set_mode() function to restart the device, then it sets the netif carrier to on. There is a race window between these two calls. The at91 CAN controller (observed on the sama5d3, a single core 32 bit ARM CPU) has a hardware limitation. If the device goes into bus-off while sending a CAN frame, there is no way to abort the sending of this frame. After the controller is enabled again, another attempt is made to send it. If the bus is still faulty, the device immediately goes back to the bus-off state. The driver calls can_bus_off(), the netif carrier is switched off and another can_restart is scheduled. This occurs within the race window before the original can_restart() handler marks the netif carrier as OK. This would cause the 2nd can_restart() to be called with an OK netif carrier, resulting in an error message. The flow of the 1st can_restart() looks like this: can_restart() // bail out if netif_carrier is OK netif_carrier_ok(dev) priv->do_set_mode(dev, CAN_MODE_START) // enable CAN controller // sama5d3 restarts sending old message // CAN devices goes into BUS_OFF, triggers IRQ // IRQ handler start at91_irq() at91_irq_err_line() can_bus_off() netif_carrier_off() schedule_delayed_work() // IRQ handler end netif_carrier_on() The 2nd can_restart() will be called with an OK netif carrier and the error message will be printed. To close the race window, first set the netif carrier to on, then restart the controller. In case the restart fails with an error code, roll back the netif carrier to off. Fixes: 39549eef ("can: CAN Network device driver and Netlink interface") Link: https://lore.kernel.org/all/20231005-can-dev-fix-can-restart-v2-2-91b5c1fd922c@pengutronix.deReviewed-by: Vincent Mailhol <mailhol.vincent@wanadoo.fr> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
-
Marc Kleine-Budde authored
During testing, I triggered a can_restart() with the netif carrier being OK [1]. The BUG_ON, which checks if the carrier is OK, results in a fatal kernel crash. This is neither helpful for debugging nor for a production system. [1] The root cause is a race condition in can_restart() which will be fixed in the next patch. Do not crash the kernel, issue an error message instead, and continue restarting the CAN device anyway. Fixes: 39549eef ("can: CAN Network device driver and Netlink interface") Link: https://lore.kernel.org/all/20231005-can-dev-fix-can-restart-v2-1-91b5c1fd922c@pengutronix.deReviewed-by: Vincent Mailhol <mailhol.vincent@wanadoo.fr> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
-
Justin Stitt authored
`strncpy` is deprecated for use on NUL-terminated destination strings [1] and as such we should prefer more robust and less ambiguous string interfaces. NUL-padding is not required since card is already zero-initialized: | card = kzalloc(sizeof(*card), GFP_KERNEL); A suitable replacement is `strscpy` [2] due to the fact that it guarantees NUL-termination on the destination buffer without unnecessarily NUL-padding. Link: https://www.kernel.org/doc/html/latest/process/deprecated.html#strncpy-on-nul-terminated-strings [1] Link: https://manpages.debian.org/testing/linux-manual-4.8/strscpy.9.en.html [2] Link: https://github.com/KSPP/linux/issues/90 Cc: linux-hardening@vger.kernel.org Signed-off-by: Justin Stitt <justinstitt@google.com> Reviewed-by: Kees Cook <keescook@chromium.org> Link: https://lore.kernel.org/all/20231005-strncpy-drivers-net-can-sja1000-peak_pci-c-v1-1-c36e1702cd56@google.comSigned-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
-
- 04 Oct, 2023 5 commits
-
-
Jiapeng Chong authored
The call netdev_{put, hold} of dev_{put, hold} will check NULL, so there is no need to check before using dev_{put, hold}, remove it to silence the warning: ./net/can/raw.c:497:2-9: WARNING: NULL check before dev_{put, hold} functions is not needed. Reported-by: Abaci Robot <abaci@linux.alibaba.com> Closes: https://bugzilla.openanolis.cn/show_bug.cgi?id=6231Signed-off-by: Jiapeng Chong <jiapeng.chong@linux.alibaba.com> Reported-by: Simon Horman <horms@kernel.org> Acked-by: Oliver Hartkopp <socketcan@hartkopp.net> Link: https://lore.kernel.org/all/20230825064656.87751-1-jiapeng.chong@linux.alibaba.comSigned-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
-
Marc Kleine-Budde authored
Vincent Mailhol <mailhol.vincent@wanadoo.fr> says: The kernel recently added new warnings, one of which triggers a known false positive on the etas_es58x module. In an effort to keep es58x_etas free of any W=12 (excluding those produced by foreign headers), add a workaround to silence it. While at it, this series also fix a checkpatch warning which I knew existed for a long time but was too lazy to tackle. v2 -> v3: * if the parsing of one of the version/revision numbers fail, es58x_parse_product_info() immediately returns. If this occurs early, the other version/revision numbers would still be set to zero (which is now considered a valid version number). Set the version and revision to an invalid number before starting the parsing so that everything is set even if an early return occurs. v1 -> v2: * v1 had two different check logics for the version numbers: - check that none of the sub-version number are zero to make sure the parsing succeeded - check that all of the sub-version number fit the expected digit range to please GCC. v2 simplifies things by merging those two logics together. Link: https://lore.kernel.org/all/20230924110914.183898-1-mailhol.vincent@wanadoo.fr [mkl: fixed typos] Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
-
Vincent Mailhol authored
Fix below checkpatch warning: WARNING: Missing a blank line after declarations #2233: FILE: drivers/net/can/usb/etas_es58x/es58x_core.c:2233: + int ret = es58x_init_netdev(es58x_dev, ch_idx); + if (ret) { Fixes: d8f26fd6 ("can: etas_es58x: remove es58x_get_product_info()") Signed-off-by: Vincent Mailhol <mailhol.vincent@wanadoo.fr> Link: https://lore.kernel.org/all/20230924110914.183898-3-mailhol.vincent@wanadoo.frSigned-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
-
Vincent Mailhol authored
Following [1], es58x_devlink.c now triggers the following format-truncation GCC warnings: drivers/net/can/usb/etas_es58x/es58x_devlink.c: In function ‘es58x_devlink_info_get’: drivers/net/can/usb/etas_es58x/es58x_devlink.c:201:41: warning: ‘%02u’ directive output may be truncated writing between 2 and 3 bytes into a region of size between 1 and 3 [-Wformat-truncation=] 201 | snprintf(buf, sizeof(buf), "%02u.%02u.%02u", | ^~~~ drivers/net/can/usb/etas_es58x/es58x_devlink.c:201:30: note: directive argument in the range [0, 255] 201 | snprintf(buf, sizeof(buf), "%02u.%02u.%02u", | ^~~~~~~~~~~~~~~~ drivers/net/can/usb/etas_es58x/es58x_devlink.c:201:3: note: ‘snprintf’ output between 9 and 12 bytes into a destination of size 9 201 | snprintf(buf, sizeof(buf), "%02u.%02u.%02u", | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 202 | fw_ver->major, fw_ver->minor, fw_ver->revision); | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ drivers/net/can/usb/etas_es58x/es58x_devlink.c:211:41: warning: ‘%02u’ directive output may be truncated writing between 2 and 3 bytes into a region of size between 1 and 3 [-Wformat-truncation=] 211 | snprintf(buf, sizeof(buf), "%02u.%02u.%02u", | ^~~~ drivers/net/can/usb/etas_es58x/es58x_devlink.c:211:30: note: directive argument in the range [0, 255] 211 | snprintf(buf, sizeof(buf), "%02u.%02u.%02u", | ^~~~~~~~~~~~~~~~ drivers/net/can/usb/etas_es58x/es58x_devlink.c:211:3: note: ‘snprintf’ output between 9 and 12 bytes into a destination of size 9 211 | snprintf(buf, sizeof(buf), "%02u.%02u.%02u", | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 212 | bl_ver->major, bl_ver->minor, bl_ver->revision); | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ drivers/net/can/usb/etas_es58x/es58x_devlink.c:221:38: warning: ‘%03u’ directive output may be truncated writing between 3 and 5 bytes into a region of size between 2 and 4 [-Wformat-truncation=] 221 | snprintf(buf, sizeof(buf), "%c%03u/%03u", | ^~~~ drivers/net/can/usb/etas_es58x/es58x_devlink.c:221:30: note: directive argument in the range [0, 65535] 221 | snprintf(buf, sizeof(buf), "%c%03u/%03u", | ^~~~~~~~~~~~~ drivers/net/can/usb/etas_es58x/es58x_devlink.c:221:3: note: ‘snprintf’ output between 9 and 13 bytes into a destination of size 9 221 | snprintf(buf, sizeof(buf), "%c%03u/%03u", | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 222 | hw_rev->letter, hw_rev->major, hw_rev->minor); | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ This is not an actual bug because the sscanf() parsing makes sure that the u8 are only two digits long and the u16 only three digits long. Thus below declaration: char buf[max(sizeof("xx.xx.xx"), sizeof("axxx/xxx"))]; allocates just what is needed to represent either of the versions. This warning was known but ignored because, at the time of writing, -Wformat-truncation was not present in the kernel, not even at W=3 [2]. One way to silence this warning is to check the range of all sub version numbers are valid: [0, 99] for u8 and range [0, 999] for u16. The module already has a logic which considers that when all the sub version numbers are zero, the version number is not set. Note that not having access to the device specification, this was an arbitrary decision. This logic can thus be removed in favor of global check that would cover both cases: - the version number is not set (parsing failed) - the version number is not valid (paranoiac check to please gcc) Before starting to parse the product info string, set the version sub-numbers to the maximum unsigned integer thus violating the definitions of struct es58x_sw_version or struct es58x_hw_revision. Then, rework the es58x_sw_version_is_set() and es58x_hw_revision_is_set() functions: remove the check that the sub-numbers are non zero and replace it by a check that they fit in the expected number of digits. This done, rename the functions to reflect the change and rewrite the documentation. While doing so, also add a description of the return value. Finally, the previous version only checked that &es58x_hw_revision.letter was not the null character. Replace this check by an alphanumeric character check to make sure that we never return a special character or a non-printable one and update the documentation of struct es58x_hw_revision accordingly. All those extra checks are paranoid but have the merit to silence the newly introduced W=1 format-truncation warning [1]. [1] commit 6d4ab2e9 ("extrawarn: enable format and stringop overflow warnings in W=1") Link: https://git.kernel.org/torvalds/c/6d4ab2e97dcf [2] https://lore.kernel.org/all/CAMZ6Rq+K+6gbaZ35SOJcR9qQaTJ7KR0jW=XoDKFkobjhj8CHhw@mail.gmail.com/Reported-by: Marc Kleine-Budde <mkl@pengutronix.de> Closes: https://lore.kernel.org/linux-can/20230914-carrousel-wrecker-720a08e173e9-mkl@pengutronix.de/ Fixes: 9f06631c ("can: etas_es58x: export product information through devlink_ops::info_get()") Signed-off-by: Vincent Mailhol <mailhol.vincent@wanadoo.fr> Link: https://lore.kernel.org/all/20230924110914.183898-2-mailhol.vincent@wanadoo.frSigned-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
-
Miquel Raynal authored
There is likely a copy-paste error here, as the exact same comment appears below in this function, one time calling set_reset_mode(), the other set_normal_mode(). Fixes: 429da1cc ("can: Driver for the SJA1000 CAN controller") Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Reviewed-by: Simon Horman <horms@kernel.org> Link: https://lore.kernel.org/all/20230922155130.592187-1-miquel.raynal@bootlin.comSigned-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
-
- 03 Oct, 2023 8 commits
-
-
Patrick Rohr authored
This change adds a sysctl to opt-out of RFC4862 section 5.5.3e's valid lifetime derivation mechanism. RFC4862 section 5.5.3e prescribes that the valid lifetime in a Router Advertisement PIO shall be ignored if it less than 2 hours and to reset the lifetime of the corresponding address to 2 hours. An in-progress 6man draft (see draft-ietf-6man-slaac-renum-07 section 4.2) is currently looking to remove this mechanism. While this draft has not been moving particularly quickly for other reasons, there is widespread consensus on section 4.2 which updates RFC4862 section 5.5.3e. Cc: Maciej Żenczykowski <maze@google.com> Cc: Lorenzo Colitti <lorenzo@google.com> Cc: Jen Linkova <furry@google.com> Signed-off-by: Patrick Rohr <prohr@google.com> Reviewed-by: Jiri Pirko <jiri@nvidia.com> Reviewed-by: David Ahern <dsahern@kernel.org> Link: https://lore.kernel.org/r/20230925214711.959704-1-prohr@google.comSigned-off-by: Jakub Kicinski <kuba@kernel.org>
-
Jakub Kicinski authored
Bagas Sanjaya says: ==================== Documentation fixes for dpll subsystem Here is a mini docs fixes for dpll subsystem. The fixes are all code block-related. This series is triggered because I was emailed by kernel test robot, alerting htmldocs warnings (see patch [1/2]). [1]: https://lore.kernel.org/all/20230918093240.29824-1-bagasdotme@gmail.com/ ==================== Link: https://lore.kernel.org/r/20230928052708.44820-1-bagasdotme@gmail.comSigned-off-by: Jakub Kicinski <kuba@kernel.org>
-
Bagas Sanjaya authored
DPLL_CMD_PIN_GET netlink command output for mux-type pins looks ugly with normal paragraph formatting. Format it as a code block instead. Signed-off-by: Bagas Sanjaya <bagasdotme@gmail.com> Acked-by: Randy Dunlap <rdunlap@infradead.org> Tested-by: Randy Dunlap <rdunlap@infradead.org> Reviewed-by: Vadim Fedorenko <vadim.fedorenko@linux.dev> Link: https://lore.kernel.org/r/20230928052708.44820-3-bagasdotme@gmail.comSigned-off-by: Jakub Kicinski <kuba@kernel.org>
-
Bagas Sanjaya authored
kernel test robot and Stephen Rothwell report htmldocs warnings: Documentation/driver-api/dpll.rst:427: WARNING: Error in "code-block" directive: maximum 1 argument(s) allowed, 18 supplied. .. code-block:: c <snipped>... Documentation/driver-api/dpll.rst:444: WARNING: Error in "code-block" directive: maximum 1 argument(s) allowed, 21 supplied. .. code-block:: c <snipped>... Documentation/driver-api/dpll.rst:474: WARNING: Error in "code-block" directive: maximum 1 argument(s) allowed, 12 supplied. .. code-block:: c <snipped>... Fix these above by adding missing blank line separator after code-block directive. Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202309180456.lOhxy9gS-lkp@intel.com/Reported-by: Stephen Rothwell <sfr@canb.auug.org.au> Closes: https://lore.kernel.org/linux-next/20230918131521.155e9e63@canb.auug.org.au/ Fixes: dbb291f1 ("dpll: documentation on DPLL subsystem interface") Signed-off-by: Bagas Sanjaya <bagasdotme@gmail.com> Acked-by: Randy Dunlap <rdunlap@infradead.org> Tested-by: Randy Dunlap <rdunlap@infradead.org> Reviewed-by: Vadim Fedorenko <vadim.fedorenko@linux.dev> Link: https://lore.kernel.org/r/20230928052708.44820-2-bagasdotme@gmail.comSigned-off-by: Jakub Kicinski <kuba@kernel.org>
-
Jakub Kicinski authored
Przemek Kitszel says: ==================== introduce DEFINE_FLEX() macro Add DEFINE_FLEX() macro, that helps on-stack allocation of structures with trailing flex array member. Expose __struct_size() macro which reads size of data allocated by DEFINE_FLEX(). Accompany new macros introduction with actual usage, in the ice driver - hence targeting for netdev tree. Obvious benefits include simpler resulting code, less heap usage, less error checking. Less obvious is the fact that compiler has more room to optimize, and as a whole, even with more stuff on the stack, we end up with overall better (smaller) report from bloat-o-meter: add/remove: 8/6 grow/shrink: 7/18 up/down: 2211/-2270 (-59) (individual results in each patch). ==================== Link: https://lore.kernel.org/r/20230912115937.1645707-1-przemyslaw.kitszel@intel.comSigned-off-by: Jakub Kicinski <kuba@kernel.org>
-
Przemek Kitszel authored
Use DEFINE_FLEX() macro for 1-elem flex array members of ice_switch.c Signed-off-by: Przemek Kitszel <przemyslaw.kitszel@intel.com> Link: https://lore.kernel.org/r/20230912115937.1645707-8-przemyslaw.kitszel@intel.comSigned-off-by: Jakub Kicinski <kuba@kernel.org>
-
Przemek Kitszel authored
Use DEFINE_FLEX() macro for 1-elem flex array use case of struct ice_aqc_dis_txq_item. Signed-off-by: Przemek Kitszel <przemyslaw.kitszel@intel.com> Link: https://lore.kernel.org/r/20230912115937.1645707-7-przemyslaw.kitszel@intel.comSigned-off-by: Jakub Kicinski <kuba@kernel.org>
-
Przemek Kitszel authored
Use DEFINE_FLEX() macro for 1-elem flex array use case of struct ice_aqc_add_tx_qgrp. Signed-off-by: Przemek Kitszel <przemyslaw.kitszel@intel.com> Link: https://lore.kernel.org/r/20230912115937.1645707-6-przemyslaw.kitszel@intel.comSigned-off-by: Jakub Kicinski <kuba@kernel.org>
-