- 03 Jun, 2024 12 commits
-
-
David S. Miller authored
Vladimir Oltean says: ==================== Probing cleanup for the Felix DSA driver This is a follow-up to Russell King's request for code consolidation among felix_vsc9959, seville_vsc9953 and ocelot_ext, stated here: https://lore.kernel.org/all/Zh1GvcOTXqb7CpQt@shell.armlinux.org.uk/ Details are in individual patches. Testing was done on NXP LS1028A (felix_vsc9959). ==================== Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Vladimir Oltean authored
Now that the common felix_register_switch() from the umbrella driver is the only entity that accesses these data structures, we can remove them from the list of the exported symbols. Signed-off-by:
Vladimir Oltean <vladimir.oltean@nxp.com> Reviewed-by:
Sai Krishna <saikrishnag@marvell.com> Signed-off-by:
-
Vladimir Oltean authored
Russell King suggested that felix_vsc9959, seville_vsc9953 and ocelot_ext have a large portion of duplicated init code, which could be made common [1]. [1]: https://lore.kernel.org/all/Zh1GvcOTXqb7CpQt@shell.armlinux.org.uk/ Here, we take the following common steps: - "felix" and "ds" structure allocation - "felix", "ocelot" and "ds" basic structure initialization - dsa_register_switch() call and we make a common function out of them. For every driver except felix_vsc9959, this is also the entire probing procedure. For felix_vsc9959, we also need to do some PCI-specific stuff, which can easily be reordered to be done before, and unwound on failure. We also have to convert the bus-specific platform_set_drvdata() and pci_set_drvdata() calls into dev_set_drvdata(). But this should have no impact on the behavior. Suggested-by:
"Russell King (Oracle)" <linux@armlinux.org.uk> Signed-off-by:
Colin Foster <colin.foster@in-advantage.com> Signed-off-by:
-
Vladimir Oltean authored
Russell King points out that seville_vsc9953 populates felix->info->num_tx_queues = 8, but this doesn't make it all the way into ds->num_tx_queues (which is how the user interface netdev queues get allocated) [1]. [1]: https://lore.kernel.org/all/20240415160150.yejcazpjqvn7vhxu@skbuf/ When num_tx_queues=0 for seville, this is implicitly converted to 1 by dsa_user_create(), and this is good enough for basic operation for a switch port. The tc qdisc offload layer works with netdev TX queues, so for QoS offload we need to pretend we have multiple TX queues. The VSC9953, like ocelot_ext, doesn't export QoS offload, so it doesn't really matter. But we can definitely set num_tx_queues=8 for all switches. The felix->info->num_tx_queues construct itself seems unnecessary. It was introduced by commit de143c0e ("net: dsa: felix: Configure Time-Aware Scheduler via taprio offload") at a time when vsc9959 (LS1028A) was the only switch supported by the driver. 8 traffic classes, and 1 queue per traffic class, is a common architectural feature of all switches in the family. So they could all just set OCELOT_NUM_TC and be fine. Signed-off-by:
-
Vladimir Oltean authored
The current placement of devm_request_threaded_irq() is inconvenient. It is between the allocation of the "felix" structure and dsa_register_switch(), both of which we'd like to refactor into a function that's common for all switches. But the IRQ is specific to felix_vsc9959. A closer inspection of the felix_irq_handler() code suggests that it does things that depend on the data structures having been fully initialized. For example, ocelot_get_txtstamp() takes &port->tx_skbs.lock, which has only been initialized in ocelot_init_port() which has not run yet. It is not one of those IRQF_SHARED IRQs, so CONFIG_DEBUG_SHIRQ_FIXME shouldn't apply here, and thus, it doesn't really matter, because in practice, the IRQ will not be triggered so early. Nonetheless, it is a good practice for the driver to be prepared for it to fire as soon as it is requested. Create a new felix->info method for running custom code for vsc9959 from within felix_setup(), and move the request_irq() call there. The ocelot_ext should have an IRQ as well, so this should be a step in the right direction for that model (VSC7512) as well. Some minor changes are made while moving the code. Casts from void * aren't necessary, so drop them, and rename felix_irq_handler() to the more specific vsc9959_irq_handler(). Signed-off-by:
-
Vladimir Oltean authored
Russell King suggested that felix_vsc9959, seville_vsc9953 and ocelot_ext have a large portion of duplicated init and teardown code, which could be made common [1]. The teardown code could even be simplified away if we made use of devres, something which is used here and there in the felix driver, just not very consistently. [1] https://lore.kernel.org/all/Zh1GvcOTXqb7CpQt@shell.armlinux.org.uk/ Prepare the ground in the felix_vsc9959 driver, by allocating the data structures using devres and deleting the kfree() calls. This also deletes the "Failed to allocate ..." message, since memory allocation errors are extremely loud anyway, and it's hard to miss them. Suggested-by:
-
Vladimir Oltean authored
Since commit 6fffbc7a ("PCI: Honor firmware's device disabled status"), PCI device drivers with OF bindings no longer need this check. Signed-off-by:
-
Vladimir Oltean authored
Russell King suggested that felix_vsc9959, seville_vsc9953 and ocelot_ext have a large portion of duplicated init and teardown code, which could be made common [1]. The teardown code could even be simplified away if we made use of devres, something which is used here and there in the felix driver, just not very consistently. [1] https://lore.kernel.org/all/Zh1GvcOTXqb7CpQt@shell.armlinux.org.uk/ Prepare the ground in the seville_vsc9953 driver, by allocating the data structures using devres and deleting the kfree() calls. This also deletes the "Failed to allocate ..." message, since memory allocation errors are extremely loud anyway, and it's hard to miss them. Suggested-by:
-
Vladimir Oltean authored
Russell King suggested that felix_vsc9959, seville_vsc9953 and ocelot_ext have a large portion of duplicated init and teardown code, which could be made common [1]. The teardown code could even be simplified away if we made use of devres, something which is used here and there in the felix driver, just not very consistently. [1] https://lore.kernel.org/all/Zh1GvcOTXqb7CpQt@shell.armlinux.org.uk/ Prepare the ground in the ocelot_ext driver, by allocating the data structures using devres and deleting the kfree() calls. This also deletes the "Failed to allocate ..." message, since memory allocation errors are extremely loud anyway, and it's hard to miss them. Suggested-by:
-
David S. Miller authored
Guangguan Wang says: ==================== net/smc: Change the upper boundary of SMC-R's snd_buf and rcv_buf to 512MB SMCR_RMBE_SIZES is the upper boundary of SMC-R's snd_buf and rcv_buf. The maximum bytes of snd_buf and rcv_buf can be calculated by 2^SMCR_ RMBE_SIZES * 16KB. SMCR_RMBE_SIZES = 5 means the upper boundary is 512KB. TCP's snd_buf and rcv_buf max size is configured by net.ipv4.tcp_w/rmem[2] whose default value is 4MB or 6MB, is much larger than SMC-R's upper boundary. In some scenarios, such as Recommendation System, the communication pattern is mainly large size send/recv, where the size of snd_buf and rcv_buf greatly affects performance. Due to the upper boundary disadvantage, SMC-R performs poor than TCP in those scenarios. So it is time to enlarge the upper boundary size of SMC-R's snd_buf and rcv_buf, so that the SMC-R's snd_buf and rcv_buf can be configured to larger size for performance gain in such scenarios. The SMC-R rcv_buf's size will be transferred to peer by the field rmbe_size in clc accept and confirm message. The length of the field rmbe_size is four bits, which means the maximum value of SMCR_RMBE_SIZES is 15. In case of frequently adjusting the value of SMCR_RMBE_SIZES in different scenarios, set the value of SMCR_RMBE_SIZES to the maximum value 15, which means the upper boundary of SMC-R's snd_buf and rcv_buf is 512MB. As the real memory usage is determined by the value of net.smc.w/rmem, not by the upper boundary, set the value of SMCR_RMBE_SIZES to the maximum value has no side affects. ==================== Signed-off-by: -
Guangguan Wang authored
SMCR_RMBE_SIZES is the upper boundary of SMC-R's snd_buf and rcv_buf. The maximum bytes of snd_buf and rcv_buf can be calculated by 2^SMCR_ RMBE_SIZES * 16KB. SMCR_RMBE_SIZES = 5 means the upper boundary is 512KB. TCP's snd_buf and rcv_buf max size is configured by net.ipv4.tcp_w/rmem[2] whose default value is 4MB or 6MB, is much larger than SMC-R's upper boundary. In some scenarios, such as Recommendation System, the communication pattern is mainly large size send/recv, where the size of snd_buf and rcv_buf greatly affects performance. Due to the upper boundary disadvantage, SMC-R performs poor than TCP in those scenarios. So it is time to enlarge the upper boundary size of SMC-R's snd_buf and rcv_buf, so that the SMC-R's snd_buf and rcv_buf can be configured to larger size for performance gain in such scenarios. The SMC-R rcv_buf's size will be transferred to peer by the field rmbe_size in clc accept and confirm message. The length of the field rmbe_size is four bits, which means the maximum value of SMCR_RMBE_SIZES is 15. In case of frequently adjusting the value of SMCR_RMBE_SIZES in different scenarios, set the value of SMCR_RMBE_SIZES to the maximum value 15, which means the upper boundary of SMC-R's snd_buf and rcv_buf is 512MB. As the real memory usage is determined by the value of net.smc.w/rmem, not by the upper boundary, set the value of SMCR_RMBE_SIZES to the maximum value has no side affects. Signed-off-by:
Guangguan Wang <guangguan.wang@linux.alibaba.com> Co-developed-by:
Wen Gu <guwen@linux.alibaba.com> Signed-off-by:
-
Guangguan Wang authored
SG_MAX_SINGLE_ALLOC is used to limit maximum number of entries that will be allocated in one piece of scatterlist. When the entries of scatterlist exceeds SG_MAX_SINGLE_ALLOC, sg chain will be used. From commit 7c703e54 ("arch: switch the default on ARCH_HAS_SG_CHAIN"), we can know that the macro CONFIG_ARCH_NO_SG_CHAIN is used to identify whether sg chain is supported. So, SMC-R's rmb buffer should be limited by SG_MAX_SINGLE_ALLOC only when the macro CONFIG_ARCH_NO_SG_CHAIN is defined. Fixes: a3fe3d01 ("net/smc: introduce sg-logic for RMBs") Signed-off-by:
-
- 01 Jun, 2024 28 commits
-
-
Kuniyuki Iwashima authored
When splice() support was added in commit 2b514574 ("net: af_unix: implement splice for stream af_unix sockets"), we had to release unix_sk(sk)->readlock (current iolock) before calling splice_to_pipe(). Due to the unlock, commit 73ed5d25 ("af-unix: fix use-after-free with concurrent readers while splicing") added a safeguard in unix_stream_read_generic(); we had to bump the skb refcount before calling ->recv_actor() and then check if the skb was consumed by a concurrent reader. However, the pipe side locking was refactored, and since commit 25869262 ("skb_splice_bits(): get rid of callback"), we can call splice_to_pipe() without releasing unix_sk(sk)->iolock. Now, the skb is always alive after the ->recv_actor() callback, so let's remove the unnecessary drop_skb logic. This is mostly the revert of commit 73ed5d25 ("af-unix: fix use-after-free with concurrent readers while splicing"). Signed-off-by:
Kuniyuki Iwashima <kuniyu@amazon.com> Link: https://lore.kernel.org/r/20240529144648.68591-1-kuniyu@amazon.comSigned-off-by:
Jakub Kicinski <kuba@kernel.org>
-
Jakub Kicinski authored
Merge branch 'lan78xx-enable-125-mhz-clk-and-auto-speed-configuration-for-lan7801-if-no-eeprom-is-detected' Rengarajan says: ==================== lan78xx: Enable 125 MHz CLK and Auto Speed configuration for LAN7801 if NO EEPROM is detected This patch series adds the support for 125 MHz clock, Auto speed and auto duplex configuration for LAN7801 in the absence of EEPROM. ==================== Link: https://lore.kernel.org/r/20240529140256.1849764-1-rengarajan.s@microchip.comSigned-off-by:
-
Rengarajan S authored
Enabled ASD/ADD configuration for LAN7801 in the absence of EEPROM. After the lite reset these contents go back to defaults where ASD/ ADD is disabled. The check is already available for LAN7800. Reviewed-by:
Simon Horman <horms@kernel.org> Signed-off-by:
Rengarajan S <rengarajan.s@microchip.com> Link: https://lore.kernel.org/r/20240529140256.1849764-3-rengarajan.s@microchip.comSigned-off-by:
-
Rengarajan S authored
The 125MHz and 25MHz clock configurations are enabled in the initialization regardless of EEPROM (125MHz is needed for RGMII 1000Mbps operation). After a lite reset (lan78xx_reset), these contents go back to defaults(all 0, so no 125MHz or 25MHz clock). Reviewed-by:
-
Jakub Kicinski authored
Linus Walleij says: ==================== net: ethernet: cortina: Use phylib for RX and TX pause This patch series switches the Cortina Gemini ethernet driver to use phylib to set up RX and TX pause for the PHY. v3: https://lore.kernel.org/r/20240513-gemini-ethernet-fix-tso-v3-0-b442540cc140@linaro.org v2: https://lore.kernel.org/r/20240511-gemini-ethernet-fix-tso-v2-0-2ed841574624@linaro.org v1: https://lore.kernel.org/r/20240509-gemini-ethernet-fix-tso-v1-0-10cd07b54d1c@linaro.org ==================== Link: https://lore.kernel.org/r/20240529-gemini-phylib-fixes-v4-0-16487ca4c2fe@linaro.orgSigned-off-by:
-
Linus Walleij authored
The Cortina Gemini ethernet can very well set up TX or RX pausing, so add this functionality to the driver in a .set_pauseparam() callback. Essentially just call down to phylib and let phylib deal with this, .adjust_link() will respect the setting from phylib. Signed-off-by:
Linus Walleij <linus.walleij@linaro.org> Reviewed-by:
Andrew Lunn <andrew@lunn.ch> Link: https://lore.kernel.org/r/20240529-gemini-phylib-fixes-v4-3-16487ca4c2fe@linaro.orgSigned-off-by:
-
Linus Walleij authored
Instead of directly poking into registers of the PHY, use the existing function to query phylib about this directly. Suggested-by:
-
Linus Walleij authored
The callback passed to of_phy_get_and_connect() in the Cortina Gemini driver is called "gmac_speed_set" which is archaic, rename it to "gmac_adjust_link" following the pattern of most other drivers. Reviewed-by:
-
Jakub Kicinski authored
Matteo Croce says: ==================== net: visibility of memory limits in netns Some programs need to know the size of the network buffers to operate correctly, export the following sysctls read-only in network namespaces: - net.core.rmem_default - net.core.rmem_max - net.core.wmem_default - net.core.wmem_max ==================== Link: https://lore.kernel.org/r/20240530232722.45255-1-technoboy85@gmail.comSigned-off-by:
-
Matteo Croce authored
Add a selftest which checks that the sysctl is present in a netns, that the value is read from the init one, and that it's readonly. Signed-off-by:
Matteo Croce <teknoraver@meta.com> Link: https://lore.kernel.org/r/20240530232722.45255-3-technoboy85@gmail.comSigned-off-by:
-
Matteo Croce authored
The following sysctl are global and can't be read from a netns: net.core.rmem_default net.core.rmem_max net.core.wmem_default net.core.wmem_max Make the following sysctl parameters available readonly from within a network namespace, allowing a container to read them. Signed-off-by:
Eric Dumazet <edumazet@google.com> Reviewed-by:
Shakeel Butt <shakeel.butt@linux.dev> Link: https://lore.kernel.org/r/20240530232722.45255-2-technoboy85@gmail.comSigned-off-by:
-
Vadim Fedorenko authored
The ethtool_ts_stats structure was introduced earlier this year. Now it's time to support this group of counters in more drivers. This patch adds support to bnxt driver. Signed-off-by:
Vadim Fedorenko <vadfed@meta.com> Reviewed-by:
Michael Chan <michael.chan@broadcom.com> Link: https://lore.kernel.org/r/20240530204751.99636-1-vadfed@meta.comSigned-off-by:
-
Jakub Kicinski authored
Jacob Keller says: ==================== ice: Introduce ETH56G PHY model for E825C products E825C products have a different PHY model than E822, E823 and E810 products. This PHY is ETH56G and its support is necessary to have functional PTP stack for E825C products. This series refactors the ice driver to add support for the new PHY model. Karol introduces the ice_ptp_hw structure. This is used to replace some hard-coded values relating to the PHY quad and port numbers, as well as to hold the phy_model type. Jacob refactors the driver code that converts between the ice_ptp_tmr_cmd enumeration and hardware register values to better re-use logic and reduce duplication when introducing another PHY type. Sergey introduces functions to help enable and disable the Tx timestamp interrupts. This makes the ice_ptp.c code more generic and encapsulates the PHY specifics into ice_ptp_hw.c Karol introduces helper functions to clear the valid bits for Tx and Rx timestamps. This enables informing hardware to discard stale timestamps after performing clock operations. Sergey moves the Clock Generation Unit (CGU) logic out of the E822 specific area of the ice_ptp_hw.c file as it will be re-used for other device PHY models. Jacob introduces a helper function for obtaining the base increment values, moving this logic out of ice_ptp.c and into the ice_ptp_hw.c file to better encapsulate hardware differences. Sergey builds on these refactors to introduce the new ETH56G PHY model used by the E825C products. This includes introducing the required helpers, constants, and PHY model checks. Karol simplifies the CGU logic by using anonymous structures, dropping an unnecessary ".field" name for accessing the CGU data. Michal Michalik updates the CGU logic to support the E825C hardware, ensuring that the clock generation is configured properly. Grzegorz Nitka adds support to read the NAC topology data from the device. This is in preparation for supporting devices which combine two NACs together, connecting all ports to the same clock source. This enables the driver to determine if its operating on such a device, or if its operating on the standard 1-NAC configuration. Grzsecgorz Nitka adjusts the PTP initialization to prepare for the 2x50G E825C devices, introducing special mapping for the PHY ports to prepare for support of the 2-NAC devices. With this, the ice driver is capable of handling PTP for the single-NAC E825C devices. Complete support for the 2-NAC devices requirs some work on how the ports connect to the clock owner. During review of this work, it was pointed out that our existing use of auxiliary bus is disliked, and Jiri requested that we change it. We are currently working on developing a replacement solution for the auxiliary bus implementation and have dropped the relevant changes out of this series. A future series will refactor the port to clock connection, at which time we will finish the support for 2-NAC E825C devices. Signed-off-by:
Jacob Keller <jacob.e.keller@intel.com> ==================== Link: https://lore.kernel.org/r/20240528-next-2024-05-28-ptp-refactors-v1-0-c082739bb6f6@intel.comSigned-off-by:
-
Grzegorz Nitka authored
>From FW/HW perspective, 2 port topology in E825C devices requires merging of 2 port mapping internally and breakout mapping externally. As a consequence, it requires different port numbering from PTP code perspective. For that topology, pf_id can not be used to index PTP ports. Even if the 2nd port is identified as port with pf_id = 1, all PHY operations need to be performed as it was port 2. Thus, special mapping is needed for the 2nd port. This change adds detection of 2x50G topology and applies 'custom' mapping on the 2nd port. Signed-off-by:
Grzegorz Nitka <grzegorz.nitka@intel.com> Reviewed-by:
Arkadiusz Kubalewski <arkadiusz.kubalewski@intel.com> Signed-off-by:
Karol Kolacinski <karol.kolacinski@intel.com> Tested-by:
Pucha Himasekhar Reddy <himasekharx.reddy.pucha@intel.com> Signed-off-by:
-
Grzegorz Nitka authored
Add new device capability ICE_AQC_CAPS_NAC_TOPOLOGY which allows to determine the mode of operation (1 or 2 NAC). Define a new structure to store data from new capability and corresponding parser code. Co-developed-by:
Prathisna Padmasanan <prathisna.padmasanan@intel.com> Signed-off-by:
Pawel Kaminski <pawel.kaminski@intel.com> Reviewed-by:
Mateusz Polchlopek <mateusz.polchlopek@intel.com> Reviewed-by:
Przemek Kitszel <przemyslaw.kitszel@intel.com> Reviewed-by:
-
Michal Michalik authored
The CGU layout of E825-C is a little different than E822/E823. Add support the new hardware adding relevant functions. Signed-off-by:
Michal Michalik <michal.michalik@intel.com> Reviewed-by:
-
Karol Kolacinski authored
Simplify the code by using anonymous struct in CGU registers instead of naming each structure 'field'. Suggested-by:
-
Sergey Temerkhanov authored
E825C products feature a new PHY model - ETH56G. Introduces all necessary PHY definitions, functions etc. for ETH56G PHY, analogous to E82X and E810 ones with addition of a few HW-specific functionalities for ETH56G like one-step timestamping. It ensures correct PTP initialization and operation for E825C products. Co-developed-by:
Sergey Temerkhanov <sergey.temerkhanov@intel.com> Reviewed-by:
-
Jacob Keller authored
Add a new helper for getting base clock increment value for specific HW. Reviewed-by:
-
Sergey Temerkhanov authored
Move CGU block to the beginning of ice_ptp_hw.c Signed-off-by:
-
Karol Kolacinski authored
Add a possibility to mark all transmitted/received timestamps as invalid by clearing PHY OFFSET_READY registers. Reviewed-by:
-
Sergey Temerkhanov authored
Introduce functions enabling/disabling Tx TS interrupts for the E822 and ETH56G PHYs Signed-off-by:
-
Jacob Keller authored
Multiple places in the driver code need to convert enum ice_ptp_tmr_cmd values into register bits for both the main timer and the PHY port timers. The main MAC register has one bit scheme for timer commands, while the PHY commands use a different scheme. The E810 and E830 devices use the same scheme for port commands as used for the main timer. However, E822 and ETH56G hardware has a separate scheme used by the PHY. Introduce helper functions to convert the timer command enumeration into the register values, reducing some code duplication, and making it easier to later refactor the individual port write commands. Reviewed-by:
-
Karol Kolacinski authored
Create new ice_ptp_hw struct and use it for all HW and PTP-related fields from struct ice_hw. Replace definitions with struct fields, which values are set accordingly to a specific device. Reviewed-by:
-
Abhishek Chauhan authored
Currently there are no strict checks while setting SO_TXTIME from userspace. With the recent development in skb->tstamp_type clockid with unsupported clocks results in warn_on_once, which causes unnecessary aborts in some systems which enables panic on warns. Add validation in setsockopt to support only CLOCK_REALTIME, CLOCK_MONOTONIC and CLOCK_TAI to be set from userspace. Link: https://lore.kernel.org/netdev/bc037db4-58bb-4861-ac31-a361a93841d3@linux.dev/ Link: https://lore.kernel.org/lkml/6bdba7b6-fd22-4ea5-a356-12268674def1@quicinc.com/ Fixes: 1693c5db ("net: Add additional bit to support clockid_t timestamp type") Reported-by: syzbot+d7b227731ec589e7f4f0@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=d7b227731ec589e7f4f0 Reported-by: syzbot+30a35a2e9c5067cc43fa@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=30a35a2e9c5067cc43faSigned-off-by:
Abhishek Chauhan <quic_abchauha@quicinc.com> Acked-by:
Martin KaFai Lau <martin.lau@kernel.org> Reviewed-by:
Willem de Bruijn <willemb@google.com> Link: https://lore.kernel.org/r/20240529183130.1717083-1-quic_abchauha@quicinc.comSigned-off-by:
-
Jakub Kicinski authored
Matthieu Baerts says: ==================== doc: mptcp: new general doc and fixes A general documentation about MPTCP was missing since its introduction in v5.6. The last patch adds a new 'mptcp' page in the 'networking' documentation. The first patch is a fix for a missing sysctl entry introduced in v6.10 rc0, and the second one reorder the sysctl entries. Signed-off-by:
Matthieu Baerts (NGI0) <matttbe@kernel.org> ==================== v2: https://lore.kernel.org/r/20240528-upstream-net-20240520-mptcp-doc-v2-0-47f2d5bc2ef3@kernel.org v1: https://lore.kernel.org/r/20240520-upstream-net-20240520-mptcp-doc-v1-0-e3ad294382cb@kernel.org Link: https://lore.kernel.org/r/20240530-upstream-net-20240520-mptcp-doc-v3-0-e94cdd9f2673@kernel.orgSigned-off-by:
-
Matthieu Baerts (NGI0) authored
A general documentation about MPTCP was missing since its introduction in v5.6. Most of what is there comes from our recently updated mptcp.dev website, with additional links to resources from the kernel documentation. This is a first version, mainly targeting app developers and users. Link: https://www.mptcp.devReviewed-by:
Mat Martineau <martineau@kernel.org> Signed-off-by:
-
Matthieu Baerts (NGI0) authored
Similar to what is done in other 'sysctl' pages: it looks clearer from a readability perspective. This might cause troubles in the short/mid-term with the backports, but by not putting new entries at the end, this can help to reduce conflicts in case of backports in the long term. We don't change the information here too often, so it looks OK to do that. Reviewed-by:
-
