summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2022-01-05net: hns3: create new set of common rss init APIs for PF and VF reuseJie Wang
This patch creates new set of common rss init APIs for PF and VF rss module. Subfunctions called by rss init process are also created include rss tuple configuration and rss indirect table configuration. These new common rss init APIs will be used to replace the old PF and VF rss init APIs in next patches. Signed-off-by: Jie Wang <wangjie125@huawei.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-01-05net: hns3: refactor VF rss set APIs with new common rss set APIsJie Wang
This patch uses new common rss set APIs to replace the old APIs in VF rss module and removes those old rss set APIs. The related macros in VF are also modified. Signed-off-by: Jie Wang <wangjie125@huawei.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-01-05net: hns3: refactor PF rss set APIs with new common rss set APIsJie Wang
This patch uses new common rss set APIs to replace the old APIs in PF rss module and deletes the old rss set APIs. The related macros are also modified. Signed-off-by: Jie Wang <wangjie125@huawei.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-01-05net: hns3: create new set of common rss set APIs for PF and VF moduleJie Wang
Currently, hns3 PF and VF rss module have two sets of rss set APIs to configure rss. There is no need to keep two sets of these same APIs. So this patch creates new set of common rss set APIs for PF and VF reuse. These new APIs will be used to unify old APIs in next patches. Signed-off-by: Jie Wang <wangjie125@huawei.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-01-05net: hns3: refactor VF rss get APIs with new common rss get APIsJie Wang
This patch firstly uses new rss parameter struct(hclge_comm_rss_cfg) as child member of hclgevf_dev and deletes the original child rss parameter member(hclgevf_rss_cfg). All the rss parameter members used in VF rss module is modified according to the new hclge_comm_rss_cfg. Secondly VF rss get APIs are refactored to use new common rss get APIs. The old rss get APIs in VF are deleted. Signed-off-by: Jie Wang <wangjie125@huawei.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-01-05net: hns3: refactor PF rss get APIs with new common rss get APIsJie Wang
This patch firstly uses new rss parameter struct(hclge_comm_rss_cfg) as child member of hclge_dev and deletes the original child rss parameter members in vport. All the vport child rss parameter members used in PF rss module is modified according to the new hclge_comm_rss_cfg. Secondly PF rss get APIs are refactored to use new common rss get APIs. The old rss get APIs in PF are deleted. Signed-off-by: Jie Wang <wangjie125@huawei.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-01-05net: hns3: create new set of common rss get APIs for PF and VF rss moduleJie Wang
The PF and VF rss get APIs are almost the same espect the suffixes of API names. These same impementions bring double development and bugfix work. So this patch creates new common rss get APIs for PF and VF rss module. Subfunctions called by rss query process are also created(e.g. rss tuple conversion APIs). These new common rss get APIs will be used to replace PF and VF old rss APIs in next patches. Signed-off-by: Jie Wang <wangjie125@huawei.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-01-05net: hns3: refactor hclge_comm_send function in PF/VF driversJie Wang
Currently, there are two different sets of special command codes in PF and VF cmdq modules, this is because VF driver only uses small part of all the command codes. In other words, these not used command codes in VF are also sepcial command codes theoretically. So this patch unifes the special command codes and deletes the bool param is_pf of hclge_comm_send. All the related functions are refactored according to the new hclge_comm_send function prototype. Signed-off-by: Jie Wang <wangjie125@huawei.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-01-05net: hns3: create new rss common structure hclge_comm_rss_cfgJie Wang
Currently PF stores its rss parameters in vport structure. VF stores rss configurations in hclgevf_rss_cfg structure. Actually hns3 rss parameters are same beween PF and VF. The two set of rss parameters are redundent and may add extra bugfix work. So this patch creates new common rss parameter struct(hclge_comm_rss_cfg) to unify PF and VF rss configurations. These new structures will be used to unify rss configurations in PF and VF rss APIs in next patches. Signed-off-by: Jie Wang <wangjie125@huawei.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-01-05dt-bindings: rng: timeriomem_rng: convert TimerIO RNG to dtschemaKrzysztof Kozlowski
Convert the TimerIO RNG bindings to DT schema. Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> Signed-off-by: Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/20211227183251.132525-8-krzysztof.kozlowski@canonical.com
2022-01-05dt-bindings: rng: st,rng: convert ST RNG to dtschemaKrzysztof Kozlowski
Convert the ST RNG bindings to DT schema. Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> Signed-off-by: Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/20211227183251.132525-7-krzysztof.kozlowski@canonical.com
2022-01-05dt-bindings: rng: ti,omap-rom-rng: convert OMAP ROM RNG to dtschemaKrzysztof Kozlowski
Convert the OMAP ROM RNG bindings to DT schema. Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> Signed-off-by: Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/20211227183251.132525-6-krzysztof.kozlowski@canonical.com
2022-01-05dt-bindings: rng: nuvoton,npcm-rng: convert Nuvoton NPCM RNG to dtschemaKrzysztof Kozlowski
Convert the Nuvoton NPCM RNG bindings to DT schema. Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> Signed-off-by: Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/20211227183251.132525-5-krzysztof.kozlowski@canonical.com
2022-01-05dt-bindings: rng: ti,keystone-rng: convert TI Keystone RNG to dtschemaKrzysztof Kozlowski
Convert the TI Keystone RNG bindings to DT schema. Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> Signed-off-by: Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/20211227183251.132525-4-krzysztof.kozlowski@canonical.com
2022-01-05dt-bindings: rng: atmel,at91-trng: document sama7g5 TRNGKrzysztof Kozlowski
Add compatbile for Microchip sama7g5 TRNG. Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> Acked-by: Nicolas Ferre <nicolas.ferre@microchip.com> Signed-off-by: Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/20211227183251.132525-3-krzysztof.kozlowski@canonical.com
2022-01-05dt-bindings: rng: atmel,at91-trng: convert Atmel TRNG to dtschemaKrzysztof Kozlowski
Convert the Atmel TRNG bindings to DT schema. Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> Acked-by: Nicolas Ferre <nicolas.ferre@microchip.com> Signed-off-by: Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/20211227183251.132525-2-krzysztof.kozlowski@canonical.com
2022-01-05dt-bindings: rng: apm,x-gene-rng: convert APM RNG to dtschemaKrzysztof Kozlowski
Convert the APM X-Gene RNG bindings to DT schema. Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> Signed-off-by: Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/20211227183251.132525-1-krzysztof.kozlowski@canonical.com
2022-01-05Revert "RDMA/mlx5: Fix releasing unallocated memory in dereg MR flow"Maor Gottlieb
This patch is not the full fix and still causes to call traces during mlx5_ib_dereg_mr(). This reverts commit f0ae4afe3d35e67db042c58a52909e06262b740f. Fixes: f0ae4afe3d35 ("RDMA/mlx5: Fix releasing unallocated memory in dereg MR flow") Link: https://lore.kernel.org/r/20211222101312.1358616-1-maorg@nvidia.com Signed-off-by: Maor Gottlieb <maorg@nvidia.com> Acked-by: Leon Romanovsky <leonro@nvidia.com> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
2022-01-05bpf/selftests: Fix namespace mount setup in tc_redirectJiri Olsa
The tc_redirect umounts /sys in the new namespace, which can be mounted as shared and cause global umount. The lazy umount also takes down mounted trees under /sys like debugfs, which won't be available after sysfs mounts again and could cause fails in other tests. # cat /proc/self/mountinfo | grep debugfs 34 23 0:7 / /sys/kernel/debug rw,nosuid,nodev,noexec,relatime shared:14 - debugfs debugfs rw # cat /proc/self/mountinfo | grep sysfs 23 86 0:22 / /sys rw,nosuid,nodev,noexec,relatime shared:2 - sysfs sysfs rw # mount | grep debugfs debugfs on /sys/kernel/debug type debugfs (rw,nosuid,nodev,noexec,relatime) # ./test_progs -t tc_redirect #164 tc_redirect:OK Summary: 1/4 PASSED, 0 SKIPPED, 0 FAILED # mount | grep debugfs # cat /proc/self/mountinfo | grep debugfs # cat /proc/self/mountinfo | grep sysfs 25 86 0:22 / /sys rw,relatime shared:2 - sysfs sysfs rw Making the sysfs private under the new namespace so the umount won't trigger the global sysfs umount. Reported-by: Hangbin Liu <haliu@redhat.com> Signed-off-by: Jiri Olsa <jolsa@kernel.org> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Cc: Jussi Maki <joamaki@gmail.com> Link: https://lore.kernel.org/bpf/20220104121030.138216-1-jolsa@kernel.org
2022-01-05bpftool: Probe for instruction set extensionsPaul Chaignon
This patch introduces new probes to check whether the kernel supports instruction set extensions v2 and v3. The first introduced eBPF instructions BPF_J{LT,LE,SLT,SLE} in commit 92b31a9af73b ("bpf: add BPF_J{LT,LE,SLT,SLE} instructions"). The second introduces 32-bit variants of all jump instructions in commit 092ed0968bb6 ("bpf: verifier support JMP32"). These probes are useful for userspace BPF projects that want to use newer instruction set extensions on newer kernels, to reduce the programs' sizes or their complexity. LLVM already provides an mcpu=probe option to automatically probe the kernel and select the newest-supported instruction set extension. That is however not flexible enough for all use cases. For example, in Cilium, we only want to use the v3 instruction set extension on v5.10+, even though it is supported on all kernels v5.1+. Signed-off-by: Paul Chaignon <paul@isovalent.com> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Reviewed-by: Quentin Monnet <quentin@isovalent.com> Link: https://lore.kernel.org/bpf/3bfedcd9898c1f41ac67ca61f144fec84c6c3a92.1641314075.git.paul@isovalent.com
2022-01-05bpftool: Probe for bounded loop supportPaul Chaignon
This patch introduces a new probe to check whether the verifier supports bounded loops as introduced in commit 2589726d12a1 ("bpf: introduce bounded loops"). This patch will allow BPF users such as Cilium to probe for loop support on startup and only unconditionally unroll loops on older kernels. The results are displayed as part of the miscellaneous section, as shown below. $ bpftool feature probe | grep loops Bounded loop support is available $ bpftool feature probe macro | grep LOOPS #define HAVE_BOUNDED_LOOPS $ bpftool feature probe -j | jq .misc { "have_large_insn_limit": true, "have_bounded_loops": true } Signed-off-by: Paul Chaignon <paul@isovalent.com> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Reviewed-by: Quentin Monnet <quentin@isovalent.com> Link: https://lore.kernel.org/bpf/f7807c0b27d79f48e71de7b5a99c680ca4bd0151.1641314075.git.paul@isovalent.com
2022-01-05bpftool: Refactor misc. feature probePaul Chaignon
There is currently a single miscellaneous feature probe, HAVE_LARGE_INSN_LIMIT, to check for the 1M instructions limit in the verifier. Subsequent patches will add additional miscellaneous probes, which follow the same pattern at the existing probe. This patch therefore refactors the probe to avoid code duplication in subsequent patches. The BPF program type and the checked error numbers in the HAVE_LARGE_INSN_LIMIT probe are changed to better generalize to other probes. The feature probe retains its current behavior despite those changes. Signed-off-by: Paul Chaignon <paul@isovalent.com> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Reviewed-by: Quentin Monnet <quentin@isovalent.com> Link: https://lore.kernel.org/bpf/956c9329a932c75941194f91790d01f31dfbe01b.1641314075.git.paul@isovalent.com
2022-01-05arm64: Drop outdated links in commentsKees Cook
As started by commit 05a5f51ca566 ("Documentation: Replace lkml.org links with lore"), an effort was made to replace lkml.org links with lore to better use a single source that's more likely to stay available long-term. However, it seems these links don't offer much value here, so just remove them entirely. Cc: Joe Perches <joe@perches.com> Suggested-by: Will Deacon <will@kernel.org> Link: https://lore.kernel.org/lkml/20210211100213.GA29813@willie-the-truck/ Signed-off-by: Kees Cook <keescook@chromium.org> Link: https://lore.kernel.org/r/20211215191835.1420010-1-keescook@chromium.org [catalin.marinas@arm.com: removed the arch/arm changes] Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
2022-01-05Merge branch 'lan966x-extend-switchdev-and-mdb-support'David S. Miller
Horatiu Vultur says: ==================== net: lan966x: Extend switchdev with mdb support This patch series extends lan966x with mdb support by implementing the switchdev callbacks: SWITCHDEV_OBJ_ID_PORT_MDB and SWITCHDEV_OBJ_ID_HOST_MDB. It adds support for both ipv4/ipv6 entries and l2 entries. v2->v3: - rename PGID_FIRST and PGID_LAST to PGID_GP_START and PGID_GP_END - don't forget and relearn an entry for the CPU if there are more references to the cpu. v1->v2: - rename lan966x_mac_learn_impl to __lan966x_mac_learn - rename lan966x_mac_cpu_copy to lan966x_mac_ip_learn - fix grammar and typos in comments and commit messages - add reference counter for entries that copy frames to CPU ==================== Reviewed-by: Vladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-01-05net: lan966x: Extend switchdev with mdb supportHoratiu Vultur
Extend lan966x driver with mdb support by implementing the switchdev calls: SWITCHDEV_OBJ_ID_PORT_MDB and SWITCHDEV_OBJ_ID_HOST_MDB. It is allowed to add both ipv4/ipv6 entries and l2 entries. To add ipv4/ipv6 entries is not required to use the PGID table while for l2 entries it is required. The PGID table is much smaller than MAC table so only fewer l2 entries can be added. Signed-off-by: Horatiu Vultur <horatiu.vultur@microchip.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-01-05net: lan966x: Add PGID_GP_START and PGID_GP_ENDHoratiu Vultur
The first entries in the PGID table are used by the front ports while the last entries are used for different purposes like flooding mask, copy to CPU, etc. So add these macros to define which entries can be used for general purpose. Signed-off-by: Horatiu Vultur <horatiu.vultur@microchip.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-01-05net: lan966x: Add function lan966x_mac_ip_learn()Horatiu Vultur
Extend mac functionality with the function lan966x_mac_ip_learn. This function adds an entry in the MAC table for IP multicast addresses. These entries can copy a frame to the CPU but also can forward on the front ports. This functionality is needed for mdb support. In case the CPU and some of the front ports subscribe to an IP multicast address. Signed-off-by: Horatiu Vultur <horatiu.vultur@microchip.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-01-05Merge branch 'mtk_eth_soc-refactoring-and-clause45'David S. Miller
Daniel Golle says: ==================== net: ethernet: mtk_eth_soc: refactoring and Clause 45 Rework value and type of mdio read and write functions in mtk_eth_soc and generally clean up and unify both functions. Then add support to access Clause 45 phy registers, using newly introduced helper inline functions added by a patch Russell King has suggested in a reply to an earlier version of this series [1]. All three commits are tested on the Bananapi BPi-R64 board having MediaTek MT7531BE DSA gigE switch using clause 22 MDIO and Ubiquiti UniFi 6 LR access point having Aquantia AQR112C PHY using clause 45 MDIO. [1]: https://lore.kernel.org/netdev/Ycr5Cna76eg2B0An@shell.armlinux.org.uk/ v11: also address return value of mtk_mdio_busy_wait v10: correct order of SoB lines in 2/3, change patch order in series v9: improved formatting and Cc missing maintainer v8: add patch from Russel King, switch to bitfield helper macros v7: remove unneeded variables and order OR-ed call parameters v6: further clean up functions and more cleanly separate patches v5: fix wrong variable name in first patch covered by follow-up patch v4: clean-up return values and types, split into two commits v3: return -1 instead of 0xffff on error in _mtk_mdio_write v2: use MII_DEVADDR_C45_SHIFT and MII_REGADDR_C45_MASK to extract device id and register address. Unify read and write functions to have identical types and parameter names where possible as we are anyway already replacing both function bodies. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
2022-01-05net: ethernet: mtk_eth_soc: implement Clause 45 MDIO accessDaniel Golle
Implement read and write access to IEEE 802.3 Clause 45 Ethernet phy registers while making use of new mdiobus_c45_regad and mdiobus_c45_devad helpers. Tested on the Ubiquiti UniFi 6 LR access point featuring MediaTek MT7622BV WiSoC with Aquantia AQR112C. Signed-off-by: Daniel Golle <daniel@makrotopia.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-01-05net: mdio: add helpers to extract clause 45 regad and devad fieldsRussell King (Oracle)
Add a couple of helpers and definitions to extract the clause 45 regad and devad fields from the regnum passed into MDIO drivers. Tested-by: Daniel Golle <daniel@makrotopia.org> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Signed-off-by: Daniel Golle <daniel@makrotopia.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-01-05net: ethernet: mtk_eth_soc: fix return values and refactor MDIO opsDaniel Golle
Instead of returning -1 (-EPERM) when MDIO bus is stuck busy while writing or 0xffff if it happens while reading, return the appropriate -ETIMEDOUT. Also fix return type to int instead of u32. Refactor functions to use bitfield helpers instead of having various masking and shifting constants in the code, which also results in the register definitions in the header file being more obviously related to what is stated in the MediaTek's Reference Manual. Fixes: 656e705243fd0 ("net-next: mediatek: add support for MT7623 ethernet") Signed-off-by: Daniel Golle <daniel@makrotopia.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-01-05ima: silence measurement list hexdump during kexecBruno Meneguele
Directly calling print_hex_dump() dumps the IMA measurement list on soft resets (kexec) straight to the syslog (kmsg/dmesg) without considering the DEBUG flag or the dynamic debug state, causing the output to be always printed, including during boot time. Since this output is only valid for IMA debugging, but not necessary on normal kexec operation, print_hex_dump_debug() adheres to the pr_debug() behavior: the dump is only printed to syslog when DEBUG is defined or when explicitly requested by the user through dynamic debugging. Signed-off-by: Bruno Meneguele <bmeneg@redhat.com> Signed-off-by: Mimi Zohar <zohar@linux.ibm.com>
2022-01-05Merge branch '40GbE' of ↵David S. Miller
git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/net-queue Tony Nguyen says: ==================== Intel Wired LAN Driver Updates 2022-01-04 This series contains updates to i40e and iavf drivers. Mateusz adjusts displaying of failed VF MAC message when the failure is expected as well as modifying an NVM info message to not confuse the user for i40e. Di Zhu fixes a use-after-free issue MAC filters for i40e. Jedrzej fixes an issue with misreporting of Rx and Tx queues during reinitialization for i40e. Karen correct checking of channel queue configuration to occur against active queues for iavf. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
2022-01-05can: netlink: report the CAN controller mode supported flagsVincent Mailhol
Currently, the CAN netlink interface provides no easy ways to check the capabilities of a given controller. The only method from the command line is to try each CAN_CTRLMODE_* individually to check whether the netlink interface returns an -EOPNOTSUPP error or not (alternatively, one may find it easier to directly check the source code of the driver instead...) This patch introduces a method for the user to check both the supported and the static capabilities. The proposed method introduces a new IFLA nest: IFLA_CAN_CTRLMODE_EXT which extends the current IFLA_CAN_CTRLMODE. This is done to guaranty a full forward and backward compatibility between the kernel and the user land applications. The IFLA_CAN_CTRLMODE_EXT nest contains one single entry: IFLA_CAN_CTRLMODE_SUPPORTED. Because this entry is only used in one direction: kernel to userland, no new struct nla_policy are introduced. Below table explains how IFLA_CAN_CTRLMODE_SUPPORTED (hereafter: "supported") and can_ctrlmode::flags (hereafter: "flags") allow us to identify both the supported and the static capabilities, when masked with any of the CAN_CTRLMODE_* bit flags: supported & flags & Controller capabilities CAN_CTRLMODE_* CAN_CTRLMODE_* ----------------------------------------------------------------------- false false Feature not supported (always disabled) false true Static feature (always enabled) true false Feature supported but disabled true true Feature supported and enabled Link: https://lore.kernel.org/all/20211213160226.56219-5-mailhol.vincent@wanadoo.fr Signed-off-by: Vincent Mailhol <mailhol.vincent@wanadoo.fr> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2022-01-05can: dev: reorder struct can_priv members for better packingVincent Mailhol
Save eight bytes of holes on x86-64 architectures by reordering the members of struct can_priv. Before: | $ pahole -C can_priv drivers/net/can/dev/dev.o | struct can_priv { | struct net_device * dev; /* 0 8 */ | struct can_device_stats can_stats; /* 8 24 */ | const struct can_bittiming_const * bittiming_const; /* 32 8 */ | const struct can_bittiming_const * data_bittiming_const; /* 40 8 */ | struct can_bittiming bittiming; /* 48 32 */ | /* --- cacheline 1 boundary (64 bytes) was 16 bytes ago --- */ | struct can_bittiming data_bittiming; /* 80 32 */ | const struct can_tdc_const * tdc_const; /* 112 8 */ | struct can_tdc tdc; /* 120 12 */ | /* --- cacheline 2 boundary (128 bytes) was 4 bytes ago --- */ | unsigned int bitrate_const_cnt; /* 132 4 */ | const u32 * bitrate_const; /* 136 8 */ | const u32 * data_bitrate_const; /* 144 8 */ | unsigned int data_bitrate_const_cnt; /* 152 4 */ | u32 bitrate_max; /* 156 4 */ | struct can_clock clock; /* 160 4 */ | unsigned int termination_const_cnt; /* 164 4 */ | const u16 * termination_const; /* 168 8 */ | u16 termination; /* 176 2 */ | | /* XXX 6 bytes hole, try to pack */ | | struct gpio_desc * termination_gpio; /* 184 8 */ | /* --- cacheline 3 boundary (192 bytes) --- */ | u16 termination_gpio_ohms[2]; /* 192 4 */ | enum can_state state; /* 196 4 */ | u32 ctrlmode; /* 200 4 */ | u32 ctrlmode_supported; /* 204 4 */ | int restart_ms; /* 208 4 */ | | /* XXX 4 bytes hole, try to pack */ | | struct delayed_work restart_work; /* 216 88 */ | | /* XXX last struct has 4 bytes of padding */ | | /* --- cacheline 4 boundary (256 bytes) was 48 bytes ago --- */ | int (*do_set_bittiming)(struct net_device *); /* 304 8 */ | int (*do_set_data_bittiming)(struct net_device *); /* 312 8 */ | /* --- cacheline 5 boundary (320 bytes) --- */ | int (*do_set_mode)(struct net_device *, enum can_mode); /* 320 8 */ | int (*do_set_termination)(struct net_device *, u16); /* 328 8 */ | int (*do_get_state)(const struct net_device *, enum can_state *); /* 336 8 */ | int (*do_get_berr_counter)(const struct net_device *, struct can_berr_counter *); /* 344 8 */ | unsigned int echo_skb_max; /* 352 4 */ | | /* XXX 4 bytes hole, try to pack */ | | struct sk_buff * * echo_skb; /* 360 8 */ | | /* size: 368, cachelines: 6, members: 32 */ | /* sum members: 354, holes: 3, sum holes: 14 */ | /* paddings: 1, sum paddings: 4 */ | /* last cacheline: 48 bytes */ | }; After: | $ pahole -C can_priv drivers/net/can/dev/dev.o | struct can_priv { | struct net_device * dev; /* 0 8 */ | struct can_device_stats can_stats; /* 8 24 */ | const struct can_bittiming_const * bittiming_const; /* 32 8 */ | const struct can_bittiming_const * data_bittiming_const; /* 40 8 */ | struct can_bittiming bittiming; /* 48 32 */ | /* --- cacheline 1 boundary (64 bytes) was 16 bytes ago --- */ | struct can_bittiming data_bittiming; /* 80 32 */ | const struct can_tdc_const * tdc_const; /* 112 8 */ | struct can_tdc tdc; /* 120 12 */ | /* --- cacheline 2 boundary (128 bytes) was 4 bytes ago --- */ | unsigned int bitrate_const_cnt; /* 132 4 */ | const u32 * bitrate_const; /* 136 8 */ | const u32 * data_bitrate_const; /* 144 8 */ | unsigned int data_bitrate_const_cnt; /* 152 4 */ | u32 bitrate_max; /* 156 4 */ | struct can_clock clock; /* 160 4 */ | unsigned int termination_const_cnt; /* 164 4 */ | const u16 * termination_const; /* 168 8 */ | u16 termination; /* 176 2 */ | | /* XXX 6 bytes hole, try to pack */ | | struct gpio_desc * termination_gpio; /* 184 8 */ | /* --- cacheline 3 boundary (192 bytes) --- */ | u16 termination_gpio_ohms[2]; /* 192 4 */ | unsigned int echo_skb_max; /* 196 4 */ | struct sk_buff * * echo_skb; /* 200 8 */ | enum can_state state; /* 208 4 */ | u32 ctrlmode; /* 212 4 */ | u32 ctrlmode_supported; /* 216 4 */ | int restart_ms; /* 220 4 */ | struct delayed_work restart_work; /* 224 88 */ | | /* XXX last struct has 4 bytes of padding */ | | /* --- cacheline 4 boundary (256 bytes) was 56 bytes ago --- */ | int (*do_set_bittiming)(struct net_device *); /* 312 8 */ | /* --- cacheline 5 boundary (320 bytes) --- */ | int (*do_set_data_bittiming)(struct net_device *); /* 320 8 */ | int (*do_set_mode)(struct net_device *, enum can_mode); /* 328 8 */ | int (*do_set_termination)(struct net_device *, u16); /* 336 8 */ | int (*do_get_state)(const struct net_device *, enum can_state *); /* 344 8 */ | int (*do_get_berr_counter)(const struct net_device *, struct can_berr_counter *); /* 352 8 */ | | /* size: 360, cachelines: 6, members: 32 */ | /* sum members: 354, holes: 1, sum holes: 6 */ | /* paddings: 1, sum paddings: 4 */ | /* last cacheline: 40 bytes */ | }; Link: https://lore.kernel.org/all/20211213160226.56219-4-mailhol.vincent@wanadoo.fr Signed-off-by: Vincent Mailhol <mailhol.vincent@wanadoo.fr> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2022-01-05can: dev: add sanity check in can_set_static_ctrlmode()Vincent Mailhol
Previous patch removed can_priv::ctrlmode_static to replace it with can_get_static_ctrlmode(). A condition sine qua non for this to work is that the controller static modes should never be set in can_priv::ctrlmode_supported (c.f. the comment on can_priv::ctrlmode_supported which states that it is for "options that can be *modified* by netlink"). Also, this condition is already correctly fulfilled by all existing drivers which rely on the ctrlmode_static feature. Nonetheless, we added an extra safeguard in can_set_static_ctrlmode() to return an error value and to warn the developer who would be adventurous enough to set to static a given feature that is already set to supported. The drivers which rely on the static controller mode are then updated to check the return value of can_set_static_ctrlmode(). Link: https://lore.kernel.org/all/20211213160226.56219-3-mailhol.vincent@wanadoo.fr Signed-off-by: Vincent Mailhol <mailhol.vincent@wanadoo.fr> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2022-01-05can: dev: replace can_priv::ctrlmode_static by can_get_static_ctrlmode()Vincent Mailhol
The statically enabled features of a CAN controller can be retrieved using below formula: | u32 ctrlmode_static = priv->ctrlmode & ~priv->ctrlmode_supported; As such, there is no need to store this information. This patch remove the field ctrlmode_static of struct can_priv and provides, in replacement, the inline function can_get_static_ctrlmode() which returns the same value. Link: https://lore.kernel.org/all/20211213160226.56219-2-mailhol.vincent@wanadoo.fr Signed-off-by: Vincent Mailhol <mailhol.vincent@wanadoo.fr> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2022-01-05can: do not increase tx_bytes statistics for RTR framesVincent Mailhol
The actual payload length of the CAN Remote Transmission Request (RTR) frames is always 0, i.e. no payload is transmitted on the wire. However, those RTR frames still use the DLC to indicate the length of the requested frame. As such, net_device_stats::tx_bytes should not be increased when sending RTR frames. The function can_get_echo_skb() already returns the correct length, even for RTR frames (c.f. [1]). However, for historical reasons, the drivers do not use can_get_echo_skb()'s return value and instead, most of them store a temporary length (or dlc) in some local structure or array. Using the return value of can_get_echo_skb() solves the issue. After doing this, such length/dlc fields become unused and so this patch does the adequate cleaning when needed. This patch fixes all the CAN drivers. Finally, can_get_echo_skb() is decorated with the __must_check attribute in order to force future drivers to correctly use its return value (else the compiler would emit a warning). [1] commit ed3320cec279 ("can: dev: __can_get_echo_skb(): fix real payload length return value for RTR frames") Link: https://lore.kernel.org/all/20211207121531.42941-6-mailhol.vincent@wanadoo.fr Cc: Nicolas Ferre <nicolas.ferre@microchip.com> Cc: Alexandre Belloni <alexandre.belloni@bootlin.com> Cc: Ludovic Desroches <ludovic.desroches@microchip.com> Cc: Maxime Ripard <mripard@kernel.org> Cc: Chen-Yu Tsai <wens@csie.org> Cc: Jernej Skrabec <jernej.skrabec@gmail.com> Cc: Yasushi SHOJI <yashi@spacecubics.com> Cc: Oliver Hartkopp <socketcan@hartkopp.net> Cc: Stephane Grosjean <s.grosjean@peak-system.com> Cc: Andreas Larsson <andreas@gaisler.com> Tested-by: Jimmy Assarsson <extja@kvaser.com> # kvaser Signed-off-by: Vincent Mailhol <mailhol.vincent@wanadoo.fr> Acked-by: Stefan Mätje <stefan.maetje@esd.eu> # esd_usb2 Tested-by: Stefan Mätje <stefan.maetje@esd.eu> # esd_usb2 [mkl: add conversion for grcan] Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2022-01-05can: do not increase rx_bytes statistics for RTR framesVincent Mailhol
The actual payload length of the CAN Remote Transmission Request (RTR) frames is always 0, i.e. no payload is transmitted on the wire. However, those RTR frames still use the DLC to indicate the length of the requested frame. As such, net_device_stats::rx_bytes should not be increased for the RTR frames. This patch fixes all the CAN drivers. Link: https://lore.kernel.org/all/20211207121531.42941-5-mailhol.vincent@wanadoo.fr Cc: Marc Kleine-Budde <mkl@pengutronix.de> Cc: Nicolas Ferre <nicolas.ferre@microchip.com> Cc: Alexandre Belloni <alexandre.belloni@bootlin.com> Cc: Ludovic Desroches <ludovic.desroches@microchip.com> Cc: Chandrasekar Ramakrishnan <rcsekar@samsung.com> Cc: Maxime Ripard <mripard@kernel.org> Cc: Chen-Yu Tsai <wens@csie.org> Cc: Jernej Skrabec <jernej.skrabec@gmail.com> Cc: Yasushi SHOJI <yashi@spacecubics.com> Cc: Appana Durga Kedareswara rao <appana.durga.rao@xilinx.com> Cc: Naga Sureshkumar Relli <naga.sureshkumar.relli@xilinx.com> Cc: Michal Simek <michal.simek@xilinx.com> Cc: Stephane Grosjean <s.grosjean@peak-system.com> Tested-by: Jimmy Assarsson <extja@kvaser.com> # kvaser Signed-off-by: Vincent Mailhol <mailhol.vincent@wanadoo.fr> Acked-by: Stefan Mätje <stefan.maetje@esd.eu> # esd_usb2 Tested-by: Stefan Mätje <stefan.maetje@esd.eu> # esd_usb2 Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2022-01-05can: do not copy the payload of RTR framesVincent Mailhol
The actual payload length of the CAN Remote Transmission Request (RTR) frames is always 0, i.e. no payload is transmitted on the wire. However, those RTR frames still use the DLC to indicate the length of the requested frame. For this reason, it is incorrect to copy the payload of RTR frames (the payload buffer would only contain garbage data). This patch encapsulates the payload copy in a check toward the RTR flag. Link: https://lore.kernel.org/all/20211207121531.42941-4-mailhol.vincent@wanadoo.fr Cc: Yasushi SHOJI <yashi@spacecubics.com> Tested-by: Yasushi SHOJI <yashi@spacecubics.com> Signed-off-by: Vincent Mailhol <mailhol.vincent@wanadoo.fr> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2022-01-05can: kvaser_usb: do not increase tx statistics when sending error message framesVincent Mailhol
The CAN error message frames (i.e. error skb) are an interface specific to socket CAN. The payload of the CAN error message frames does not correspond to any actual data sent on the wire. Only an error flag and a delimiter are transmitted when an error occurs (c.f. ISO 11898-1 section 10.4.4.2 "Error flag"). For this reason, it makes no sense to increment the tx_packets and tx_bytes fields of struct net_device_stats when sending an error message frame because no actual payload will be transmitted on the wire. N.B. Sending error message frames is a very specific feature which, at the moment, is only supported by the Kvaser Hydra hardware. Please refer to [1] for more details on the topic. [1] https://lore.kernel.org/linux-can/CAMZ6RqK0rTNg3u3mBpZOoY51jLZ-et-J01tY6-+mWsM4meVw-A@mail.gmail.com/t/#u Link: https://lore.kernel.org/all/20211207121531.42941-3-mailhol.vincent@wanadoo.fr Co-developed-by: Jimmy Assarsson <extja@kvaser.com> Signed-off-by: Jimmy Assarsson <extja@kvaser.com> Signed-off-by: Vincent Mailhol <mailhol.vincent@wanadoo.fr> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2022-01-05can: do not increase rx statistics when generating a CAN rx error message frameVincent Mailhol
The CAN error message frames (i.e. error skb) are an interface specific to socket CAN. The payload of the CAN error message frames does not correspond to any actual data sent on the wire. Only an error flag and a delimiter are transmitted when an error occurs (c.f. ISO 11898-1 section 10.4.4.2 "Error flag"). For this reason, it makes no sense to increment the rx_packets and rx_bytes fields of struct net_device_stats because no actual payload were transmitted on the wire. This patch fixes all the CAN drivers. Link: https://lore.kernel.org/all/20211207121531.42941-2-mailhol.vincent@wanadoo.fr CC: Marc Kleine-Budde <mkl@pengutronix.de> CC: Nicolas Ferre <nicolas.ferre@microchip.com> CC: Alexandre Belloni <alexandre.belloni@bootlin.com> CC: Ludovic Desroches <ludovic.desroches@microchip.com> CC: Chandrasekar Ramakrishnan <rcsekar@samsung.com> CC: Maxime Ripard <mripard@kernel.org> CC: Chen-Yu Tsai <wens@csie.org> CC: Jernej Skrabec <jernej.skrabec@gmail.com> CC: Appana Durga Kedareswara rao <appana.durga.rao@xilinx.com> CC: Naga Sureshkumar Relli <naga.sureshkumar.relli@xilinx.com> CC: Michal Simek <michal.simek@xilinx.com> CC: Stephane Grosjean <s.grosjean@peak-system.com> Tested-by: Jimmy Assarsson <extja@kvaser.com> # kvaser Signed-off-by: Vincent Mailhol <mailhol.vincent@wanadoo.fr> Acked-by: Stefan Mätje <stefan.maetje@esd.eu> # esd_usb2 Tested-by: Stefan Mätje <stefan.maetje@esd.eu> # esd_usb2 Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2022-01-05can: etas_es58x: es58x_init_netdev: populate net_device::dev_portVincent Mailhol
The field dev_port of struct net_device indicates the port number of a network device [1]. This patch populates this field. This field can be helpful to distinguish between the two network interfaces of a dual channel device (i.e. ES581.4 or ES582.1). Indeed, at the moment, all the network interfaces of a same device share the same static udev attributes c.f. output of: | udevadm info --attribute-walk /sys/class/net/canX The dev_port attribute can then be used to write some udev rules to, for example, assign a permanent name to each network interface based on the serial/dev_port pair (which is convenient when you have a test bench with several CAN devices connected simultaneously and wish to keep consistent interface names upon reboot). [1] https://www.kernel.org/doc/Documentation/ABI/testing/sysfs-class-net Link: https://lore.kernel.org/all/20211026180553.1953189-1-mailhol.vincent@wanadoo.fr Suggested-by: Lukas Magel <lukas.magel@escrypt.com> Signed-off-by: Vincent Mailhol <mailhol.vincent@wanadoo.fr> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2022-01-05can: sja1000: sp_probe(): use platform_get_irq() to get the interruptLad Prabhakar
It is preferred that drivers use platform_get_irq() instead of irq_of_parse_and_map(), so replace. Link: https://lore.kernel.org/all/20211221200016.13459-1-prabhakar.mahadev-lad.rj@bp.renesas.com Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2022-01-05can: ti_hecc: ti_hecc_probe(): use platform_get_irq() to get the interruptLad Prabhakar
platform_get_resource(pdev, IORESOURCE_IRQ, ..) relies on static allocation of IRQ resources in DT core code, this causes an issue when using hierarchical interrupt domains using "interrupts" property in the node as this bypasses the hierarchical setup and messes up the irq chaining. In preparation for removal of static setup of IRQ resource from DT core code use platform_get_irq(). Link: https://lore.kernel.org/all/20211221194508.11737-1-prabhakar.mahadev-lad.rj@bp.renesas.com Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2022-01-05platform/x86: Add Asus TF103C dock driverHans de Goede
Add a driver for the keyboard, touchpad and USB port of the keyboard dock for the Asus TF103C 2-in-1 tablet. This keyboard dock has its own I2C attached embedded controller and the keyboard and touchpad are also connected over I2C, instead of using the usual USB connection. This means that the keyboard dock requires this special driver to function. Cc: Michał Mirosław <mirq-linux@rere.qmqm.pl> Cc: Ion Agorria <ion@agorria.com> Cc: Svyatoslav Ryhel <clamor95@gmail.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20211226141849.156407-1-hdegoede@redhat.com
2022-01-05platform/x86: x86-android-tablets: Add TM800A550L dataHans de Goede
The whitelabel (sold as various brands) TM800A550L tablets's DSDT contains a whole bunch of bogus ACPI I2C devices and the ACPI node describing the touchscreen is bad (the IRQ is missing). Enumeration of these is skipped through the acpi_quirk_skip_i2c_client_enumeration(). Add support for manually instantiating the (now) missing I2C devices by adding the necessary device info to the x86-android-tablets module, including instantiating an actually working i2c-client for the touchscreen. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20211229231431.437982-13-hdegoede@redhat.com
2022-01-05platform/x86: x86-android-tablets: Add Asus MeMO Pad 7 ME176C dataHans de Goede
Asus MeMO Pad 7 ME176C tablets have an Android factory img with everything hardcoded in the kernel instead of properly described in the DSDT. Add support for manually instantiating all the missing I2C devices by adding the necessary device info to the x86-android-tablets module. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20211229231431.437982-12-hdegoede@redhat.com
2022-01-05platform/x86: x86-android-tablets: Add Asus TF103C dataHans de Goede
Asus TF103C tablets have an Android factory img with everything hardcoded in the kernel instead of properly described in the DSDT. Add support for manually instantiating all the missing I2C devices by adding the necessary device info to the x86-android-tablets module. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20211229231431.437982-11-hdegoede@redhat.com
2022-01-05platform/x86: x86-android-tablets: Add support for preloading modulesHans de Goede
Since the x86-android-tablets code does all it work from module_init() it cannot use -EPROBE_DEFER to wait for e.g. interrupt providing GPIO-chips or PMIC-cells to show up. To make sure things will still work when some necessary resource providers are build as module allow the per board info to specify a list of modules to pre-load before instantiating the I2C clients. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20211229231431.437982-10-hdegoede@redhat.com