mirror of
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/
synced 2026-11-13 07:31:07 +00:00
1,233,488 commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
|
|
00c2cae6b6 |
scsi: lpfc: Fix lpfc_name struct packing
clang points out that the lpfc_name structure has an 8-byte alignment
requirement on most architectures, but is embedded in a number of other
structures that are forced to be only 1-byte aligned:
drivers/scsi/lpfc/lpfc_hw.h:1516:30: error: field pe within 'struct lpfc_fdmi_reg_port_list' is less aligned than 'struct lpfc_fdmi_port_entry' and is usually due to 'struct lpfc_fdmi_reg_port_list' being packed, which can lead to unaligned accesses [-Werror,-Wunaligned-access]
struct lpfc_fdmi_port_entry pe;
drivers/scsi/lpfc/lpfc_hw.h:850:19: error: field portName within 'struct _ADISC' is less aligned than 'struct lpfc_name' and is usually due to 'struct _ADISC' being packed, which can lead to unaligned accesses [-Werror,-Wunaligned-access]
drivers/scsi/lpfc/lpfc_hw.h:851:19: error: field nodeName within 'struct _ADISC' is less aligned than 'struct lpfc_name' and is usually due to 'struct _ADISC' being packed, which can lead to unaligned accesses [-Werror,-Wunaligned-access]
drivers/scsi/lpfc/lpfc_hw.h:922:19: error: field portName within 'struct _RNID' is less aligned than 'struct lpfc_name' and is usually due to 'struct _RNID' being packed, which can lead to unaligned accesses [-Werror,-Wunaligned-access]
drivers/scsi/lpfc/lpfc_hw.h:923:19: error: field nodeName within 'struct _RNID' is less aligned than 'struct lpfc_name' and is usually due to 'struct _RNID' being packed, which can lead to unaligned accesses [-Werror,-Wunaligned-access]
From the git history, I can see that all the __packed annotations were done
specifically to avoid introducing implicit padding around the lpfc_name
instances, though this was probably the wrong approach.
To improve this, only annotate the one uint64_t field inside of lpfc_name
as packed, with an explicit 4-byte alignment, as is the default already on
the 32-bit x86 ABI but not on most others. With this, the other __packed
annotations can be removed again, as this avoids the incorrect padding.
Two other structures change their layout as a result of this change:
- struct _LOGO never gained a __packed annotation even though it has the
same alignment problem as the others but is not used anywhere in the
driver today.
- struct serv_param similarly has this issue, and it is used, my guess is
that this is only an internal structure rather than part of a binary
interface, so the padding has no negative effect here.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Link: https://lore.kernel.org/r/20230616090705.2623408-1-arnd@kernel.org
Reviewed-by: Justin Tee <justin.tee@broadcom.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
|
||
|
|
53bf91641a |
inet: Cleanup on charging memory for newly accepted sockets
If there is no net-memcg associated with the sock, don't bother calculating its memory usage for charge. Signed-off-by: Abel Wu <wuyun.abel@bytedance.com> Link: https://lore.kernel.org/r/20230620092712.16217-1-wuyun.abel@bytedance.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> |
||
|
|
ca4fa87435 |
selftests: tc-testing: add one test for flushing explicitly created chain
Add the test for additional reference to chains that are explicitly
created by RTM_NEWCHAIN message.
The test result:
1..1
ok 1 c2b4 - soft lockup alarm will be not generated after delete the prio 0
filter of the chain
This is a follow up to commit
|
||
|
|
1ca09f5746 |
dt-bindings: net: micrel,ks8851: allow SPI device properties
The Micrel KS8851 can be attached to SPI or parallel bus and the
difference is expressed in compatibles. Allow common SPI properties
when this is a SPI variant and narrow the parallel memory bus properties
to the second case.
This fixes dtbs_check warning:
qcom-msm8960-cdp.dtb: ethernet@0: Unevaluated properties are not allowed ('spi-max-frequency' was unexpected)
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Reviewed-by: Conor Dooley <conor.dooley@microchip.com>
Link: https://lore.kernel.org/r/20230619170134.65395-1-krzysztof.kozlowski@linaro.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
||
|
|
6a0a6dd8df |
dt-bindings: net: bluetooth: qualcomm: document VDD_CH1
WCN3990 comes with two chains - CH0 and CH1 - where each takes VDD regulator. It seems VDD_CH1 is optional (Linux driver does not care about it), so document it to fix dtbs_check warnings like: sdm850-lenovo-yoga-c630.dtb: bluetooth: 'vddch1-supply' does not match any of the regexes: 'pinctrl-[0-9]+' Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Acked-by: Conor Dooley <conor.dooley@microchip.com> Link: https://lore.kernel.org/r/20230617165716.279857-1-krzysztof.kozlowski@linaro.org Signed-off-by: Jakub Kicinski <kuba@kernel.org> |
||
|
|
e748d0fd66 |
net: hsr: Disable promiscuous mode in offload mode
When port-to-port forwarding for interfaces in HSR node is enabled, disable promiscuous mode since L2 frame forward happens at the offloaded hardware. Signed-off-by: Ravi Gunasekaran <r-gunasekaran@ti.com> Reviewed-by: Simon Horman <simon.horman@corigine.com> Link: https://lore.kernel.org/r/20230614114710.31400-1-r-gunasekaran@ti.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> |
||
|
|
3d5786ea47 |
selftests/bpf: Add vrf_socket_lookup tests
Verify that socket lookup via TC/XDP with all BPF APIs is VRF aware. Signed-off-by: Gilad Sever <gilad9366@gmail.com> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Reviewed-by: Eyal Birger <eyal.birger@gmail.com> Acked-by: Stanislav Fomichev <sdf@google.com> Link: https://lore.kernel.org/bpf/20230621104211.301902-5-gilad9366@gmail.com |
||
|
|
9a5cb79762 |
bpf: Fix bpf socket lookup from tc/xdp to respect socket VRF bindings
When calling bpf_sk_lookup_tcp(), bpf_sk_lookup_udp() or
bpf_skc_lookup_tcp() from tc/xdp ingress, VRF socket bindings aren't
respoected, i.e. unbound sockets are returned, and bound sockets aren't
found.
VRF binding is determined by the sdif argument to sk_lookup(), however
when called from tc the IP SKB control block isn't initialized and thus
inet{,6}_sdif() always returns 0.
Fix by calculating sdif for the tc/xdp flows by observing the device's
l3 enslaved state.
The cg/sk_skb hooking points which are expected to support
inet{,6}_sdif() pass sdif=-1 which makes __bpf_skc_lookup() use the
existing logic.
Fixes:
|
||
|
|
97fbfeb869 |
bpf: Call __bpf_sk_lookup()/__bpf_skc_lookup() directly via TC hookpoint
skb->dev always exists in the tc flow. There is no need to use bpf_skc_lookup(), bpf_sk_lookup() from this code path. This change facilitates fixing the tc flow to be VRF aware. Signed-off-by: Gilad Sever <gilad9366@gmail.com> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Reviewed-by: Shmulik Ladkani <shmulik.ladkani@gmail.com> Reviewed-by: Eyal Birger <eyal.birger@gmail.com> Acked-by: Stanislav Fomichev <sdf@google.com> Link: https://lore.kernel.org/bpf/20230621104211.301902-3-gilad9366@gmail.com |
||
|
|
6e98730bc0 |
bpf: Factor out socket lookup functions for the TC hookpoint.
Change BPF helper socket lookup functions to use TC specific variants: bpf_tc_sk_lookup_tcp() / bpf_tc_sk_lookup_udp() / bpf_tc_skc_lookup_tcp() instead of sharing implementation with the cg / sk_skb hooking points. This allows introducing a separate logic for the TC flow. The tc functions are identical to the original code. Signed-off-by: Gilad Sever <gilad9366@gmail.com> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Reviewed-by: Shmulik Ladkani <shmulik.ladkani@gmail.com> Reviewed-by: Eyal Birger <eyal.birger@gmail.com> Acked-by: Stanislav Fomichev <sdf@google.com> Link: https://lore.kernel.org/bpf/20230621104211.301902-2-gilad9366@gmail.com |
||
|
|
ff9b63c80b |
Merge branch 'leds-trigger-netdev-add-additional-modes'
Christian Marangi says: ==================== leds: trigger: netdev: add additional modes This is a continue of [1]. It was decided to take a more gradual approach to implement LEDs support for switch and phy starting with basic support and then implementing the hw control part when we have all the prereq done. This should be the final part for the netdev trigger. I added net-next tag and added netdev mailing list since I was informed that this should be merged with netdev branch. We collect some info around and we found a good set of modes that are common in almost all the PHY and Switch. These modes are: - Modes for dedicated link speed(10, 100, 1000 mbps). Additional mode can be added later following this example. - Modes for half and full duplex. The original idea was to add hw control only modes. While the concept makes sense in practice it would results in lots of additional code and extra check to make sure we are setting correct modes. With the suggestion from Andrew it was pointed out that using the ethtool APIs we can actually get the current link speed and duplex and this effectively removed the problem of having hw control only modes since we can fallback to software. Since these modes are supported by software, we can skip providing an user for this in the LED driver to support hw control for these new modes (that will come right after this is merged) and prevent this to be another multi subsystem series. For link speed and duplex we use ethtool APIs. To call ethtool APIs, rtnl lock is needed but this can be skipped on handling netdev events as the lock is already held. [1] https://lore.kernel.org/lkml/20230216013230.22978-1-ansuelsmth@gmail.com/ ==================== Link: https://lore.kernel.org/r/20230619204700.6665-1-ansuelsmth@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> |
||
|
|
b655892ffd |
leds: trigger: netdev: expose hw_control status via sysfs
Expose hw_control status via sysfs for the netdev trigger to give userspace better understanding of the current state of the trigger and the LED. Signed-off-by: Christian Marangi <ansuelsmth@gmail.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Reviewed-by: Kalesh AP <kalesh-anakkur.purayil@broadcom.com> Acked-by: Lee Jones <lee@kernel.org> Signed-off-by: Jakub Kicinski <kuba@kernel.org> |
||
|
|
f22f95b9ff |
leds: trigger: netdev: add additional specific link duplex mode
Add additional modes for specific link duplex. Use ethtool APIs to get the current link duplex and enable the LED accordingly. Under netdev event handler the rtnl lock is already held and is not needed to be set to access ethtool APIs. This is especially useful for PHY and Switch that supports LEDs hw control for specific link duplex. Add additional modes: - half_duplex: Turn on LED when link is half duplex - full_duplex: Turn on LED when link is full duplex Signed-off-by: Christian Marangi <ansuelsmth@gmail.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Acked-by: Lee Jones <lee@kernel.org> Signed-off-by: Jakub Kicinski <kuba@kernel.org> |
||
|
|
d5e01266e7 |
leds: trigger: netdev: add additional specific link speed mode
Add additional modes for specific link speed. Use ethtool APIs to get the current link speed and enable the LED accordingly. Under netdev event handler the rtnl lock is already held and is not needed to be set to access ethtool APIs. This is especially useful for PHY and Switch that supports LEDs hw control for specific link speed. (example scenario a PHY that have 2 LED connected one green and one orange where the green is turned on with 1000mbps speed and orange is turned on with 10mpbs speed) On mode set from sysfs we check if we have enabled split link speed mode and reject enabling generic link mode to prevent wrong and redundant configuration. Rework logic on the set baseline state to support these new modes to select if we need to turn on or off the LED. Add additional modes: - link_10: Turn on LED when link speed is 10mbps - link_100: Turn on LED when link speed is 100mbps - link_1000: Turn on LED when link speed is 1000mbps Signed-off-by: Christian Marangi <ansuelsmth@gmail.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Acked-by: Lee Jones <lee@kernel.org> Signed-off-by: Jakub Kicinski <kuba@kernel.org> |
||
|
|
7ad7b7023f |
bnxt_en: Link representors to PCI device
Link VF representors to parent PCI device to benefit from systemd defined naming scheme. Without this change the representor is visible as ethN. Signed-off-by: Ivan Vecera <ivecera@redhat.com> Reviewed-by: Simon Horman <simon.horman@corigine.com> Reviewed-by: Michael Chan <michael.chan@broadcom.com> Link: https://lore.kernel.org/r/20230620144855.288443-1-ivecera@redhat.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> |
||
|
|
f31b6c649e |
Merge branch 'selftests-preparations-for-out-of-order-operations-patches-in-mlxsw'
Petr Machata says: ==================== selftests: Preparations for out-of-order-operations patches in mlxsw The mlxsw driver currently makes the assumption that the user applies configuration in a bottom-up manner. Thus netdevices need to be added to the bridge before IP addresses are configured on that bridge or SVI added on top of it. Enslaving a netdevice to another netdevice that already has uppers is in fact forbidden by mlxsw for this reason. Despite this safety, it is rather easy to get into situations where the offloaded configuration is just plain wrong. Over the course of the following several patchsets, mlxsw code is going to be adjusted to diminish the space of wrongly offloaded configurations. Ideally the offload state will reflect the actual state, regardless of the sequence of operation used to construct that state. Several selftests build configurations that will not be offloadable in the future on some systems. The reason is that what will get offloaded is the actual configuration, not the configuration steps. For example, when a port is added to a bridge that has an IP address, that bridge will get a RIF, which it would not have with the current code. But on Nvidia Spectrum-1 machines, MAC addresses of all RIFs need to have the same prefix, which the bridge will violate. The RIF thus couldn't be created, and the enslavement is therefore canceled, because it would lead to an unoffloadable configuration. This breaks some selftests. In this patchset, adjust selftests to avoid the configurations that mlxsw would be incapable of offloading, while maintaining relevance with regards to the feature that is being tested. There are generally two cases of fixes: - Disabling IPv6 autogen on bridges that do not participate in routing, either because of the abovementioned requirement to keep the same MAC prefix on all in-HW router interfaces, or, on 802.1ad bridges, because in-HW router interfaces are not supported at all. - Setting the bridge MAC address to what it will become after the first member port is attached, so that the in-HW router interface is created with a supported MAC address. The patchset is then split thus: - Patches #1-#7 adjust generic selftests - Patches #8-#16 adjust mlxsw-specific selftests ==================== Link: https://lore.kernel.org/r/cover.1687265905.git.petrm@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> |
||
|
|
664bc72dd2 |
selftests: mlxsw: one_armed_router: Use port MAC for bridge address
In a future patch, mlxsw will start adding RIFs to uppers of front panel port netdevices, if they have an IP address. At the time that the front panel port is enslaved to the bridge, the bridge MAC address does not have the same prefix as other interfaces in the system. On Nvidia Spectrum-1 machines all the RIFs have to have the same 38-bit MAC address prefix. Since the bridge does not obey this limitation, the RIF cannot be created, and the enslavement attempt is vetoed on the grounds of the configuration not being offloadable. The bridge eventually inherits MAC address from its first member, after the enslavement is acked. A number of (mainly VXLAN) selftests already work around the problem by setting the MAC address to whatever it will eventually be anyway. Do the same for this selftest. Signed-off-by: Petr Machata <petrm@nvidia.com> Reviewed-by: Danielle Ratson <danieller@nvidia.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org> |
||
|
|
5541577521 |
selftests: mlxsw: vxlan: Disable IPv6 autogen on bridges
In a future patch, mlxsw will start adding RIFs to uppers of front panel port netdevices, if they have an IP address. At the time that the front panel port is enslaved to the bridge (this holds for all bridges used here), the bridge MAC address does not have the same prefix as other interfaces in the system. On Nvidia Spectrum-1 machines all the RIFs have to have the same 38-bit MAC address prefix. Since the bridge does not obey this limitation, the RIF cannot be created, and the enslavement attempt is vetoed on the grounds of the configuration not being offloadable. The selftest itself however checks various aspects of VXLAN offloading and the bridges do not need to participate in routing traffic. The IP addresses or the RIFs are irrelevant. Fix by disabling automatic IPv6 address generation for the HW-offloaded bridges in this selftest, thus exempting them from mlxsw router attention. Signed-off-by: Petr Machata <petrm@nvidia.com> Reviewed-by: Danielle Ratson <danieller@nvidia.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org> |
||
|
|
08035d8e35 |
selftests: mlxsw: spectrum: q_in_vni_veto: Disable IPv6 autogen on a bridge
In a future patch, mlxsw will start adding RIFs to uppers of front panel port netdevices, if they have an IP address. At the time that the front panel port is enslaved to the bridge, the bridge MAC address does not have the same prefix as other interfaces in the system. On Nvidia Spectrum-1 machines all the RIFs have to have the same 38-bit MAC address prefix. Since the bridge does not obey this limitation, the RIF cannot be created, and the enslavement attempt is vetoed on the grounds of the configuration not being offloadable. The selftest itself however checks vetoing of a different aspect of the configuration and the bridge does not need to participate in routing traffic. The IP address or the RIF are irrelevant. Fix by disabling automatic IPv6 address generation for the HW-offloaded bridge in this selftest, thus exempting it from mlxsw router attention. Signed-off-by: Petr Machata <petrm@nvidia.com> Reviewed-by: Danielle Ratson <danieller@nvidia.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org> |
||
|
|
ea2d5f757e |
selftests: mlxsw: qos_mc_aware: Disable IPv6 autogen on bridges
In a future patch, mlxsw will start adding RIFs to uppers of front panel port netdevices, if they have an IP address. At the time that the front panel port is enslaved to the bridge (this holds for both bridges used here), the bridge MAC address does not have the same prefix as other interfaces in the system. On Nvidia Spectrum-1 machines all the RIFs have to have the same 38-bit MAC address prefix. Since the bridge does not obey this limitation, the RIF cannot be created, and the enslavement attempt is vetoed on the grounds of the configuration not being offloadable. The selftest itself however checks traffic prioritization and scheduling, and the bridges serve for their L2 forwarding capabilities, and do not need to participate in routing traffic. The IP addresses or the RIFs are irrelevant. Fix by disabling automatic IPv6 address generation for the HW-offloaded bridges in this selftest, thus exempting them from mlxsw router attention. Signed-off-by: Petr Machata <petrm@nvidia.com> Reviewed-by: Danielle Ratson <danieller@nvidia.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org> |
||
|
|
ec7023e674 |
selftests: mlxsw: qos_ets_strict: Disable IPv6 autogen on bridges
In a future patch, mlxsw will start adding RIFs to uppers of front panel port netdevices, if they have an IP address. At the time that the front panel port is enslaved to the bridge (this holds for both bridges used here), the bridge MAC address does not have the same prefix as other interfaces in the system. On Nvidia Spectrum-1 machines all the RIFs have to have the same 38-bit MAC address prefix. Since the bridge does not obey this limitation, the RIF cannot be created, and the enslavement attempt is vetoed on the grounds of the configuration not being offloadable. The selftest itself however checks traffic prioritization and scheduling, and the bridges serve for their L2 forwarding capabilities, and do not need to participate in routing traffic. The IP addresses or the RIFs are irrelevant. Fix by disabling automatic IPv6 address generation for the HW-offloaded bridges in this selftest, thus exempting them from mlxsw router attention. Signed-off-by: Petr Machata <petrm@nvidia.com> Reviewed-by: Danielle Ratson <danieller@nvidia.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org> |
||
|
|
6349f9bbbf |
selftests: mlxsw: qos_dscp_bridge: Disable IPv6 autogen on a bridge
In a future patch, mlxsw will start adding RIFs to uppers of front panel port netdevices, if they have an IP address. At the time that the front panel port is enslaved to the bridge, the bridge MAC address does not have the same prefix as other interfaces in the system. On Nvidia Spectrum-1 machines all the RIFs have to have the same 38-bit MAC address prefix. Since the bridge does not obey this limitation, the RIF cannot be created, and the enslavement attempt is vetoed on the grounds of the configuration not being offloadable. The selftest itself however checks DCB DSCP-based prioritization, and the bridge serves for its L2 forwarding capabilities, and does not need to participate in routing traffic. The IP address or the RIF are irrelevant. Fix by disabling automatic IPv6 address generation for the HW-offloaded bridge in this selftest, thus exempting it from mlxsw router attention. Signed-off-by: Petr Machata <petrm@nvidia.com> Reviewed-by: Danielle Ratson <danieller@nvidia.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org> |
||
|
|
32b3a7bf85 |
selftests: mlxsw: mirror_gre_scale: Disable IPv6 autogen on a bridge
In a future patch, mlxsw will start adding RIFs to uppers of front panel port netdevices, if they have an IP address. At the time that the front panel port is enslaved to the bridge, the bridge MAC address does not have the same prefix as other interfaces in the system. On Nvidia Spectrum-1 machines all the RIFs have to have the same 38-bit MAC address prefix. Since the bridge does not obey this limitation, the RIF cannot be created, and the enslavement attempt is vetoed on the grounds of the configuration not being offloadable. The selftest itself however checks how many mirroring sessions a machine is capable of offloading. The IP address or the RIF are irrelevant. Fix by disabling automatic IPv6 address generation for the HW-offloaded bridge in this selftest, thus exempting it from mlxsw router attention. Signed-off-by: Petr Machata <petrm@nvidia.com> Reviewed-by: Danielle Ratson <danieller@nvidia.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org> |
||
|
|
a758dc469a |
selftests: mlxsw: extack: Disable IPv6 autogen on bridges
In a future patch, mlxsw will start adding RIFs to uppers of front panel port netdevices, if they have an IP address. At the time that the front panel port is enslaved to the bridge (this holds for all bridges used here), the bridge MAC address does not have the same prefix as other interfaces in the system. On Nvidia Spectrum-1 machines all the RIFs have to have the same 38-bit MAC address prefix. Since the bridge does not obey this limitation, the RIF cannot be created, and the enslavement attempt is vetoed on the grounds of the configuration not being offloadable. The selftest itself however checks whether a different vetoed aspect of the configuration provides an extack. The IP address or the RIF are irrelevant. Fix by disabling automatic IPv6 address generation for the HW-offloaded bridges in this selftest, thus exempting them from mlxsw router attention. Signed-off-by: Petr Machata <petrm@nvidia.com> Reviewed-by: Danielle Ratson <danieller@nvidia.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org> |
||
|
|
8cfdd300a5 |
selftests: mlxsw: q_in_q_veto: Disable IPv6 autogen on bridges
In a future patch, mlxsw will start adding RIFs to uppers of front panel port netdevices, if they have an IP address. The swp enslavement to the 802.1ad bridge is not allowed, because RIFs are not allowed to be created for 802.1ad bridges, but the address indicates one needs to be created. Thus the veto selftests fail already during the port enslavement. Then the attempt to create a VLAN on top of the same bridge is not vetoed, because the bridge is not related to mlxsw, and the selftest fails. Fix by disabling automatic IPv6 address generation for the bridges in this selftest, thus exempting them from the mlxsw router attention. Signed-off-by: Petr Machata <petrm@nvidia.com> Reviewed-by: Amit Cohen <amcohen@nvidia.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org> |
||
|
|
5e71bf50c2 |
selftests: forwarding: router_bridge: Use port MAC for bridge address
In a future patch, mlxsw will start adding RIFs to uppers of front panel port netdevices, if they have an IP address. At the time that the front panel port is enslaved to the bridge, the bridge MAC address does not have the same prefix as other interfaces in the system. On Nvidia Spectrum-1 machines all the RIFs have to have the same 38-bit MAC address prefix. Since the bridge does not obey this limitation, the RIF cannot be created, and the enslavement attempt is vetoed on the grounds of the configuration not being offloadable. The bridge eventually inherits MAC address from its first member, after the enslavement is acked. A number of (mainly VXLAN) selftests already work around the problem by setting the MAC address to whatever it will eventually be anyway. Do the same here. Signed-off-by: Petr Machata <petrm@nvidia.com> Reviewed-by: Danielle Ratson <danieller@nvidia.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org> |
||
|
|
8fd32576e6 |
selftests: forwarding: mirror_gre_*: Use port MAC for bridge address
In a future patch, mlxsw will start adding RIFs to uppers of front panel port netdevices, if they have an IP address. At the time that the front panel port is enslaved to the bridge, the bridge MAC address does not have the same prefix as other interfaces in the system. On Nvidia Spectrum-1 machines all the RIFs have to have the same 38-bit MAC address prefix. Since the bridge does not obey this limitation, the RIF cannot be created, and the enslavement attempt is vetoed on the grounds of the configuration not being offloadable. The bridge eventually inherits MAC address from its first member, after the enslavement is acked. A number of (mainly VXLAN) selftests already work around the problem by setting the MAC address to whatever it will eventually be anyway. Do the same for several mirror_gre selftests. Signed-off-by: Petr Machata <petrm@nvidia.com> Reviewed-by: Danielle Ratson <danieller@nvidia.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org> |
||
|
|
92c3bb5393 |
selftests: forwarding: mirror_gre_*: Disable IPv6 autogen on bridges
In a future patch, mlxsw will start adding RIFs to uppers of front panel port netdevices, if they have an IP address. At the time that the front panel port is enslaved to the bridge, the bridge MAC address does not have the same prefix as other interfaces in the system. On Nvidia Spectrum-1 machines all the RIFs have to have the same 38-bit MAC address prefix. Since the bridge does not obey this limitation, the RIF cannot be created, and the enslavement attempt is vetoed on the grounds of the configuration not being offloadable. These two selftests however check mirroring traffic to a gretap netdevice. The bridge here does not participate in routing traffic and the IP address or the RIF are irrelevant. Fix by disabling automatic IPv6 address generation for the HW-offloaded bridges in these selftests, thus exempting them from mlxsw router attention. Since the bridges are only used for L2 forwarding, this change should not hinder usefulness of this selftest for testing SW datapath or HW datapaths in other devices. Signed-off-by: Petr Machata <petrm@nvidia.com> Reviewed-by: Danielle Ratson <danieller@nvidia.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org> |
||
|
|
f61018dc3e |
selftests: forwarding: pedit_dsfield: Disable IPv6 autogen on a bridge
In a future patch, mlxsw will start adding RIFs to uppers of front panel port netdevices, if they have an IP address. At the time that the front panel port is enslaved to the bridge, the bridge MAC address does not have the same prefix as other interfaces in the system. On Nvidia Spectrum-1 machines all the RIFs have to have the same 38-bit MAC address prefix. Since the bridge does not obey this limitation, the RIF cannot be created, and the enslavement attempt is vetoed on the grounds of the configuration not being offloadable. The selftest itself however checks whether skbedit changes packet priority as appropriate. The bridge thus does not need to participate in routing traffic and the IP address or the RIF are irrelevant. Fix by disabling automatic IPv6 address generation for the HW-offloaded bridge in this selftest, thus exempting it from mlxsw router attention. Since the bridge is only used for L2 forwarding, this change should not hinder usefulness of this selftest for testing SW datapath or HW datapaths in other devices. Signed-off-by: Petr Machata <petrm@nvidia.com> Reviewed-by: Danielle Ratson <danieller@nvidia.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org> |
||
|
|
d7442b7d28 |
selftests: forwarding: skbedit_priority: Disable IPv6 autogen on a bridge
In a future patch, mlxsw will start adding RIFs to uppers of front panel port netdevices, if they have an IP address. At the time that the front panel port is enslaved to the bridge, the bridge MAC address does not have the same prefix as other interfaces in the system. On Nvidia Spectrum-1 machines all the RIFs have to have the same 38-bit MAC address prefix. Since the bridge does not obey this limitation, the RIF cannot be created, and the enslavement attempt is vetoed on the grounds of the configuration not being offloadable. The selftest itself however checks operation of pedit on IPv4 and IPv6 dsfield and its parts. The bridge thus does not need to participate in routing traffic and the IP address or the RIF are irrelevant. Fix by disabling automatic IPv6 address generation for the HW-offloaded bridge in this selftest, thus exempting it from mlxsw router attention. Since the bridge is only used for L2 forwarding, this change should not hinder usefulness of this selftest for testing SW datapath or HW datapaths in other devices. Signed-off-by: Petr Machata <petrm@nvidia.com> Reviewed-by: Danielle Ratson <danieller@nvidia.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org> |
||
|
|
c801533304 |
selftests: forwarding: dual_vxlan_bridge: Disable IPv6 autogen on bridges
In a future patch, mlxsw will start adding RIFs to uppers of front panel port netdevices, if they have an IP address. This will cause this selftest to fail spuriously. The swp enslavement to the 802.1ad bridge is not allowed, because RIFs are not allowed to be created for 802.1ad bridges, but the address indicates one needs to be created. Fix by disabling automatic IPv6 address generation for the HW-offloaded bridge in this selftest, thus exempting it from mlxsw router attention. Signed-off-by: Petr Machata <petrm@nvidia.com> Reviewed-by: Amit Cohen <amcohen@nvidia.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org> |
||
|
|
8c3736ce59 |
selftests: forwarding: q_in_vni: Disable IPv6 autogen on bridges
In a future patch, mlxsw will start adding RIFs to uppers of front panel port netdevices, if they have an IP address. This will cause this selftest to fail spuriously. The swp enslavement to the 802.1ad bridge is not allowed, because RIFs are not allowed to be created for 802.1ad bridges, but the address indicates one needs to be created. Fix by disabling automatic IPv6 address generation for the HW-offloaded bridge in this selftest, thus exempting it from mlxsw router attention. Signed-off-by: Petr Machata <petrm@nvidia.com> Reviewed-by: Amit Cohen <amcohen@nvidia.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org> |
||
|
|
59bb14bda2 |
bpf-for-netdev
-----BEGIN PGP SIGNATURE----- iHUEABYIAB0WIQTFp0I1jqZrAX+hPRXbK58LschIgwUCZJK5DwAKCRDbK58LschI gyUtAQD4gT4BEVHRqvniw9yyqYo0BvElAznutDq7o9kFHFep2gEAoksEWS84OdZj 0L5mSKjXrpHKzmY/jlMrVIcTb3VzOw0= =gAYE -----END PGP SIGNATURE----- Merge tag 'for-netdev' of https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf Daniel Borkmann says: ==================== pull-request: bpf 2023-06-21 We've added 7 non-merge commits during the last 14 day(s) which contain a total of 7 files changed, 181 insertions(+), 15 deletions(-). The main changes are: 1) Fix a verifier id tracking issue with scalars upon spill, from Maxim Mikityanskiy. 2) Fix NULL dereference if an exception is generated while a BPF subprogram is running, from Krister Johansen. 3) Fix a BTF verification failure when compiling kernel with LLVM_IAS=0, from Florent Revest. 4) Fix expected_attach_type enforcement for kprobe_multi link, from Jiri Olsa. 5) Fix a bpf_jit_dump issue for x86_64 to pick the correct JITed image, from Yonghong Song. * tag 'for-netdev' of https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf: bpf: Force kprobe multi expected_attach_type for kprobe_multi link bpf/btf: Accept function names that contain dots selftests/bpf: add a test for subprogram extables bpf: ensure main program has an extable bpf: Fix a bpf_jit_dump issue for x86_64 with sysctl bpf_jit_enable. selftests/bpf: Add test cases to assert proper ID tracking on spill bpf: Fix verifier id tracking of scalars on spill ==================== Link: https://lore.kernel.org/r/20230621101116.16122-1-daniel@iogearbox.net Signed-off-by: Jakub Kicinski <kuba@kernel.org> |
||
|
|
e973dfe929 |
cgroup/misc: Expose misc.current on cgroup v2 root
Hello, This patch is to expose misc.current on cgroup v2 root for tracking how much of the resource has been consumed in total on the system. Most of the cloud infrastucture use cgroup to fetch the host information for scheduling purpose. Currently, the misc controller can be used by Intel TDX HKIDs and AMD SEV ASIDs, which are both used for creating encrypted VMs. Intel TDX and AMD SEV are mostly be used by the cloud providers for providing confidential VMs. In actual use of a server, these confidential VMs may be launched in different ways. For the cloud solution, there are kubvirt and coco (tracked by kubepods.slice); on host, they can be booted directly through qemu by end user (tracked by user.slice), etc. In this complex environment, when wanting to know how many resource is used in total it has to iterate through all existing slices to get the value of each misc.current and add them up to calculate the total number of consumed keys. So exposing misc.current to root cgroup tends to give much easier when calculates how much resource has been used in total, which helps to schedule and count resources for the cloud infrastucture. Signed-off-by: LeiZhou-97 <lei.zhou@intel.com> Signed-off-by: Tejun Heo <tj@kernel.org> |
||
|
|
36de5f303c |
cgroup: Avoid -Wstringop-overflow warnings
Address the following -Wstringop-overflow warnings seen when
built with ARM architecture and aspeed_g4_defconfig configuration
(notice that under this configuration CGROUP_SUBSYS_COUNT == 0):
kernel/cgroup/cgroup.c:1208:16: warning: 'find_existing_css_set' accessing 4 bytes in a region of size 0 [-Wstringop-overflow=]
kernel/cgroup/cgroup.c:1258:15: warning: 'css_set_hash' accessing 4 bytes in a region of size 0 [-Wstringop-overflow=]
kernel/cgroup/cgroup.c:6089:18: warning: 'css_set_hash' accessing 4 bytes in a region of size 0 [-Wstringop-overflow=]
kernel/cgroup/cgroup.c:6153:18: warning: 'css_set_hash' accessing 4 bytes in a region of size 0 [-Wstringop-overflow=]
These changes are based on commit
|
||
|
|
0feedcaa0a |
TI SoC driver updates for v6.5
* pruss: Add helper functions for ethernet client driver usage, add compile-testing, fixup function pointer casts * smartreflex: Cosmetic optimization for using devm_ioremap_resource * wkup_m3_ipc: Fix error checking around debugfs_create_dir -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEE+KKGk1TrgjIXoxo03bWEnRc2JJ0FAmSLPWMACgkQ3bWEnRc2 JJ0bUQ//YjHvITXq33UCszxgV5acwvLdYpqElaTxnnB7Q3hIq7CMT3++BgCUY6SN hELY6rrvU8yvgPmf3w/yhDcGafUBq/fWr2HoXe6Vn/Rd7yBXp9LWp6BtgBCnpBRX 2J+wY17w43vbPwxaEV7/NorYQeV8o4okysk3NIVBpGEyA9BlnjpMC2ZA/PEYmDmm rn55yRI4X9N8eaYg6YO1Ve/UFhVQ+u8lL3GBrlIiwOfn2/Og1u4RLzJ91cr7JugJ f1qaLzWmIOLp9M47nH+N6mtYHo+zAZnZWgAs95r5ghOXJw0rWscRX7j0n+ZsTIRs uf0Nt1yzku4gvJazAk6Z9O8nlt8iXkADPSsCeUNspS9ZuUl0Dn6st8yqqNzhHOBx 80lveUcGheROvaF9cwgQz+PR7QvEgu7y5rIGgNXiPbPdQSP48jHpPzjhVdBe4Jm5 w+uQMgOp84CLVJt0jRTrWeYt0zI6z0SgqcM0p4I2uA0jHpF/Ib1ZL+rKCef5utFP Z02h8f1J0qf7YnrNKxY19P+dZWdGtyzMsn7CIxZw5bPfQuohTa2RTQ7eIM0gcmR6 +cQ5qZmDRNphi9kda3p26d42FOWRmxtIaZoHK+3O+iqvgEaro/HpniMgY4LGoTny q5HSRDPWWVQ8HdX3fLAHJvCWgcQOvkDA+sqI9dDeBe4L+K1HNEk= =FN1i -----END PGP SIGNATURE----- gpgsig -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEiK/NIGsWEZVxh/FrYKtH/8kJUicFAmSTWvMACgkQYKtH/8kJ UifYYg/9HRDAi9nHyBBJI02/8kSR3u6v4+qcnl4fngP2oij4kBS2VGdpdV8Y2wTt 7LlemtBzqXIRU7tkvKkO1GW9H1fADzGCaW3IwiLieFmbNS/FQUL3tvWyFloqF1hw t6FhMhV9flHDfKsI0pkG3optd9u1Evrcnll+ZsQM9kmTl9XAn61812UYXif973Zl 8SqXZtXmxZ52+FrV+8bURE4FJ9VyVJw7rrjJveAC9hIQ45Ohd1UDtW3wE0R/qWy1 lbkxIDn12ewNKHpZuuF5VKtTj+ba5weciyOW2SCdl2Lc3Hp/lqgMW/geWAUvXBNX HwnG2mzC/tD/yNUVxlmKepItyyZU4TvLx8syYQq900h6ysTDAzmeA68IGjuej5f9 ZlpGnn12p6dD/LsYeFRv7dmVrvz8yKLZtqA37TCHbDUyRN831NckskYYI9KhY/XD +JVLifqXMAUjXS84By469hrYigtEy1CeVCSyunvIkkksih4bnsFnN8hHpZNcQBBb fTTObTipPyeXDY3e6oAMgp/Ni7da6zu0b5KSiDX6rWb1kfySBMQHyMkIynP8AYJW lp7HUuTYQ6odq5lsNgXF0Z7T3DYcd2nqwYdNh36wajAVCC4HIov5WzIt+Dn9jJpm 87Dy4UZhD/ZFKu7PoAXuOgTtvtDEVsRTOXTznt2QDvPFHZSTff0= =UvY7 -----END PGP SIGNATURE----- Merge tag 'ti-driver-soc-for-v6.5' of https://git.kernel.org/pub/scm/linux/kernel/git/ti/linux into soc/drivers TI SoC driver updates for v6.5 * pruss: Add helper functions for ethernet client driver usage, add compile-testing, fixup function pointer casts * smartreflex: Cosmetic optimization for using devm_ioremap_resource * wkup_m3_ipc: Fix error checking around debugfs_create_dir * tag 'ti-driver-soc-for-v6.5' of https://git.kernel.org/pub/scm/linux/kernel/git/ti/linux: wkup_m3_ipc.c: Fix error checking for debugfs_create_dir soc: ti: pruss: Add helper functions to set GPI mode, MII_RT_event and XFR soc: ti: pruss: Add pruss_cfg_read()/update(), pruss_cfg_get_gpmux()/set_gpmux() APIs soc: ti: pruss: Add pruss_{request,release}_mem_region() API soc: ti: pruss: Add pruss_get()/put() API soc: ti: pruss: Allow compile-testing soc: ti: pruss: Avoid cast to incompatible function type soc: ti: smartreflex: Use devm_platform_ioremap_resource() Link: https://lore.kernel.org/r/20230615164134.6sd5hudyadq3fvk4@garage Signed-off-by: Arnd Bergmann <arnd@arndb.de> |
||
|
|
e8b4858b15 |
dt-bindings: bus: ti-sysc: fix typo
Fix typo (period vs comma) in list of valid clock names. Signed-off-by: Mans Rullgard <mans@mansr.com> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://lore.kernel.org/r/20230620200917.24958-1-mans@mansr.com Signed-off-by: Rob Herring <robh@kernel.org> |
||
|
|
37d1fc51dd |
More Qualcomm driver updates for v6.5
The detection of split/non-split firmware files in the MDT loader is corrected. The Geni driver is updated to not enable unused interrupts, in some configurations. The count unit for MSM8998 in BWMON is corrected. RPM master stats driver is corrected to check for the right return value of devm_ioremap(). Support for socinfo version 18 and 19 are aded, and IPQ5300 is added to the list of platforms. -----BEGIN PGP SIGNATURE----- iQJJBAABCAAzFiEEBd4DzF816k8JZtUlCx85Pw2ZrcUFAmSLPJsVHGFuZGVyc3Nv bkBrZXJuZWwub3JnAAoJEAsfOT8Nma3Fc9AQAMvf/8aE2FyhH3LE9n1otbRa82Lv 5MjvAM9N6PUJgMSuA71lZm6Bh3h/3SpbGjuRGkfGi4ZpkjZiI37ButZQq8YKVcOi hDPjGiF8oiO1wk+JEwrC29jgpL+37T7/7jSynO2cYfu+uKXt3MhF9kmDeIiydjyf hpN6IhGuyLm+dx38x9Vzsq4ew4uFNos+zP0ZInScSJV8UQ5sJjUCjQ4FDu1bHoFn wQXa0Bd5ObYJilh71on9eJO7dQYLapv5omHI0lM04cYpYGfPpSTmXQwnbpmL7xqF dyLiE+eq6jpi5yWIVpEFFwonty7Ixuq4yuMwMafYVGIriQ8a8J56HvfvZQ2FSb7D 1F/Rx74qkx1LEenNOBM5rUFyIGc93Up19DzFPNBX/WjJW0+7yBlXNUsg/bI2a/xV Z+jURxcUWKa/ugiqjMZRXQ7VXC2uhrjD8xn22+w8eyziRoPPecq5KITizHv3CkOT G7AhI69nFn8zhXHJ3cp4ci4AWzOCW4HXnTE9H8XMDFcu6hxylJDovrqCtt0nWqg+ QPKSqVtUF7BX/UMhhE5XdxqkxG//MyMN2W4dowxv+u35+6DCydyEm3XFuD85ETnt YJx4iC5n8IGfb5jfOIyLK0JHQNU9ijPSd9rssLRebh96m4H0Op9gHlxDHyXghaRS umZA+uKoxQQZhEXn =KYPl -----END PGP SIGNATURE----- gpgsig -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEiK/NIGsWEZVxh/FrYKtH/8kJUicFAmSTWk8ACgkQYKtH/8kJ Uicu3hAAgerZS9Wdt+w+2cUhnkWWayByRwUmTvowFUR8vsbWLJVf1UwYQFiHVXhn BsPSSGWSRm3vyUZjZyv3GegoWLsxH3LD8s7QngjPpF75HI+2ekD8J+tLNRiNqPll /cZ1iQFVoTtfYUzAFpgBrYlFYV9P7B/6ghjEhuMc0HWLN4xFJ+13HL5NdCtvbDyn zTrBSDlz3j94+PoS6n/y+9r8nLNZyp5Li5FUEoXf7uABI9dUqWokoSDV1hRA7zeF MewEEcH7p5AZiL54L7cfLAlKwPQrUNYjerNxeljrwcp621wECniB030JmYKslSzS ccfracaf7EBqRuu4SYH47VeLadikpBxrjP39CJFAlKQhB2X3uUNrSYjLyTLDkRRA X/SN4sbm0ipToa6FlGJ68D3Ca+MHs541U6fhMgQuJ+S4D0pBjbmKUmQfs76L2Eu4 0ZDyYCQuJFmvd/P6ZKjX6hmkxDJ4OItop+K6doedAFf0/tAp6APry05aF56mbhDW tsBJ0ABlFNY73wMhSu7HMm2rB7mDl3LnVfv67HrWAzaB+c23rkUDki67a1Gtr3lV mG05JMSG2nETBRPv+II3pG/q7GzJwlqzHNxy3mwtBRILlzLjEl5fK+HgZRtGN8zr 7620aNOKR3lA7XGih1/ztlbpVqgH0c6Ahnm3pCHoQJJjMrK8oWI= =YKVY -----END PGP SIGNATURE----- Merge tag 'qcom-drivers-for-6.5-2' of https://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux into soc/drivers More Qualcomm driver updates for v6.5 The detection of split/non-split firmware files in the MDT loader is corrected. The Geni driver is updated to not enable unused interrupts, in some configurations. The count unit for MSM8998 in BWMON is corrected. RPM master stats driver is corrected to check for the right return value of devm_ioremap(). Support for socinfo version 18 and 19 are aded, and IPQ5300 is added to the list of platforms. * tag 'qcom-drivers-for-6.5-2' of https://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux: soc: qcom: geni-se: Do not bother about enable/disable of interrupts in secondary sequencer dt-bindings: sram: qcom,imem: document qdu1000 soc: qcom: icc-bwmon: Fix MSM8998 count unit dt-bindings: soc: qcom,rpmh-rsc: Require power-domains soc: qcom: socinfo: Add Soc ID for IPQ5300 dt-bindings: arm: qcom,ids: add SoC ID for IPQ5300 soc: qcom: Fix a IS_ERR() vs NULL bug in probe soc: qcom: socinfo: Add support for new fields in revision 19 soc: qcom: socinfo: Add support for new fields in revision 18 dt-bindings: firmware: scm: Add compatible for SDX75 soc: qcom: mdt_loader: Fix split image detection Link: https://lore.kernel.org/r/20230615163104.1461905-1-andersson@kernel.org Signed-off-by: Arnd Bergmann <arnd@arndb.de> |
||
|
|
aaeb1b6367 |
PMIC wrapper
- support companion device - add support for MT6795 SPMI: - add support for MT8186 SVS: - change gpu node name to match binding -----BEGIN PGP SIGNATURE----- iQJLBAABCAA1FiEEUdvKHhzqrUYPB/u8L21+TfbCqH4FAmSK6xwXHG1hdHRoaWFz LmJnZ0BnbWFpbC5jb20ACgkQL21+TfbCqH7XOg//cMmnV6P1Nfwiaf9id88Pudky wPRvKFzLGS9svznGexacOXZyUg7SDckaNoqEow4JLpO/SLdNdiDIQ17pj3g2txt0 4VCQOK/h2c6nfhYYcsSnekowuLyCivXKcp+25hZ1cORu+r48u028HdXZu/7P/6Xk l83xnETBIQIehlMerPRJ+tDhbEqc6yj6A277aqkrgCNm4ohWfUUQNPbjBSPHDW/7 ABd28KjY4ZkTAM88fRxjJS8JkXRC8CRMaBETH2MQjytXHqJ6oKe11o/cWNVII94f 4cwN6FMlKVcTC03CMEbo/l376xCgsrko+v3eREHaZuG+ESprJd8xOo/wTM4ESBN8 wFXCvjm8NlpaSZD00FayfQzprOHiK671T4p7ayeP3rcneI0/WRDCJTL20ngghcct 4ZGEvj7sK/oV7chTqt+PWAmBjrF7g4NwOR6Q5uPkcRkIn8d/dKnZh89ZFPt8/Ghi dAGrHyBJz2lwKwwH5WLgWhHRHkJk0f3UfoETbU/PvN9QWqnceH2zmx84Tv+IAb6K 1m8P7qqhlA4DatyW8dLwKXo+M70hD8vUcy7gDnPY0C8A6yRJNvmnN5Iny/bNUn2Z mUDfjC2Nh0p09Td39bL/uMawqkyokLOwnzWNkM+RS9GStzJbfXYAO0wrD+10f5zc 8HKg2/lBmNBthF0D2Cg= =ZMgG -----END PGP SIGNATURE----- gpgsig -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEiK/NIGsWEZVxh/FrYKtH/8kJUicFAmSTWfYACgkQYKtH/8kJ UifbLA//cJrJ9/aTffYlVjyaQyBHyzTLKN9REn844ERhSPeDcWOAcyfqMmcAoKgB rQTm6R+JOgldxI8FogcDbL44yAz+rw4fmnKCPhq5JDQbdDXA/KzTTCzIsN6Uukvr RykIMCOirCE68MjfOFmMQPM266AhW+2O/qTYTg7DiAcecA39DJRxZ2sNvUTbgA/R pDRnaAw1vphcghnhi3vyAKeJjPFC+M0VqX71aJAXPEeNKCu7sZDeIKZ4C0dcPrOX Rl6fzpHcciZ1amJx2aoj0wAqmu9RM9M4TdmEGWZvav3TzgMKgxd5EHcPI4Shqjmc ScxPcYNUc3cibUUix/5f+anuU+7Tf+SXi0T9VZU4lrAaXOdDk0z1rnnood1O34Yv iZXa0Qsb1irFhhgXwMQGwK9gR/LN9VFOSxVy9UZBMeP5RihiYCN+SmWrf+YHQlw3 iArLh18GX0ikN/SJvnqnYcHCALMWlQhdgHGR4jA5LgvbcPTt3NZH2y11aByK7Y2g fepcKV0nhinyR5fKhBimOqAHW3+gEFMXjqbzZ41nbcVKjiNXQTfi58mAh8n2jsBt 61B8PAQLowYKeZvKFbcnodWOg7bTSma91ca5JFK3nTd9ijeOhG4Iy0pLsN9/qxNP y6yyxy/PjCYeJnqkL+F2OustXwwxbED45CGNrz3fQ0+HtoJWE8A= =hwjN -----END PGP SIGNATURE----- Merge tag 'v6.4-next-soc' of https://git.kernel.org/pub/scm/linux/kernel/git/matthias.bgg/linux into soc/drivers PMIC wrapper - support companion device - add support for MT6795 SPMI: - add support for MT8186 SVS: - change gpu node name to match binding * tag 'v6.4-next-soc' of https://git.kernel.org/pub/scm/linux/kernel/git/matthias.bgg/linux: soc: mediatek: remove DDP_DOMPONENT_DITHER from enum soc: mediatek: SVS: Fix MT8192 GPU node name soc: mediatek: mtk-mutex: Remove unnecessary .owner dt-bindings: phy: mediatek,dsi-phy: Add compatible for MT6795 Helio X10 dt-bindings: pwm: Add compatible for MediaTek MT6795 dt-bindings: spmi: spmi-mtk-pmif: Document mediatek,mt8195-spmi as fallback of mediatek,mt8186-spmi soc: mediatek: pwrap: Add support for MT6795 Helio X10 soc: mediatek: mtk-pmic-wrap: Add support for MT6331 w/ MT6332 companion soc: mediatek: mtk-pmic-wrap: Add support for companion PMICs soc: mediatek: pwrap: Add kerneldoc for struct pwrap_slv_type soc: mediatek: pwrap: Move PMIC read test sequence in function dt-bindings: soc: mediatek: pwrap: Add compatible for MT6795 Helio X10 Link: https://lore.kernel.org/r/1ed1e5ae-6305-e63a-84a0-3c43f69c8f8b@gmail.com Signed-off-by: Arnd Bergmann <arnd@arndb.de> |
||
|
|
a08000d5e0 |
Qualcomm driver updates for v6.5
Konrad Dybcio is promoted, from reviewer, to co-maintainer. The mdt_loader gets a fix to the detection of split binaries, where the previous logic sometimes concluded that the first segments was not split, in a split image. The unconditional calling of scm_pas_mem_setup() turns out to cause a regression and is reverted. The altmode subfunction of pmic_glink is enabled for SM8450. A new driver for exposing power statistics from the RPM, for debugging purposes, is introduced. OCMEM gets a debug prints of the hardware version, QMI helpers are transitioned to alloc_ordered_workqueue() and an error message in ramp_controller is improved. An API is introduced to the SMEM driver to allow other drivers to query the SoC id, rather than open-coding the parsing of the relevant SMEM item. This is then used to clean up the Qualcomm NVMEM-based cpufreq driver. Socinfo is extended with knowledge about IPQ5018, IPQ5312 and IPQ5302. -----BEGIN PGP SIGNATURE----- iQJJBAABCAAzFiEEBd4DzF816k8JZtUlCx85Pw2ZrcUFAmSFHJsVHGFuZGVyc3Nv bkBrZXJuZWwub3JnAAoJEAsfOT8Nma3FrtoQAMUN2gF5ZP3rlSEkQbKNMDhNHXVw S8AexPk6Qw8BcEBOD4YPqrmfrMvNP7Bqh3QkfS/7m5vx0o8bUOw+Xz+C4+9LSUD7 /qW29GlQllwMuRNOdH3J/nYXwpV5WJyiSF/jXy0/GRbz+D/XYSNDC57z/lXTcKKq dYJrKxms6EF4AgHe88V0bmk6/V4xfa5p6xW3pCG7GLqNHOvhZ16oUmoPiZGVpQMk go/HsoIB00HktKflTLOUXJWD6qVOVNCaQQEarx+zY1txfmvpVGL+PO6Eaxt00Sa4 pHRvB0CIZPNvdDWELfsfRx6DbPBJRGBlneag04BI918fx4X+jn4uP+1jzw9am03U M78k0LGBY23Psy6KhoMu5MM4Cntt3kTQ0SwHl/xayzTrAhK2xdmd1bo67ArRl+HX OZrZ7Se3Cm16CAWqsW42so6MJeDllc8d/ahN/e2NwsNy1lhosK06jRJEdh3N238D ouL56HoxrweYB0kbK4TkPLewrLZC7DYnr0KMVsPhsSraeJBaBPOVZDhuNSUXXMtf WdyCRMMxKU3OweLcJiKuGFzNqr2963341Y6NlD+tf1Uy5IEnbIp4jFi9BsJBNVZt NucOXJYm5OJeAHp8BcMFbnL8uA1NqEYQXwezodPSIGqHzxBtGf6f0hALsIpiUQnA GLDp99yVujEN2dsE =9Fv4 -----END PGP SIGNATURE----- gpgsig -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEiK/NIGsWEZVxh/FrYKtH/8kJUicFAmSTVmkACgkQYKtH/8kJ Uid08g//b5kJZnsiWA43LrkblMSEdZoeijrn+x2NU95YQ4s/oz2RnUtgNCGDhM84 Fi60PzU5L1JVj6GVeL51J5jlBGKzGqe4FfPTN4aPlSV4Z0B3cuevgWmHnw4Mh/zj t/1b5QVVZxbKKxb8MP+U2iAvyxVwIhIA4zehh0+XGagV3qquURO7QLtLUg42Yx51 HFLADq2JI8trm+CjjCNBv9mq7EipC/g0nbsCs98nxl/sPC7PqtNxL6BXCuz3a8BX JvA1LVRP2JYkQfb6SMnTFiqkT6LdB7bt6oXZdnwnsNTI1nhFqbMJRMsToWb3HEvv 9lprraDpaufbzvB1b+x8Aar4OmbbWaY2ZpNJqqzCM5eVW2Zs/p5J+ZfOYVigtQYO qIQvENv+eKETu4nVvdlf72FPAVe+GXnVAcl3LEwhMUxYcRMha4JT0i8mndnCzpT+ tZLdkBMp/t7rZPIa7D+07Xmorefw9e9rwynQg2C2yw3AV5v7j09dPJDFITFcF6Yl 7ADtoy7zHTTv6/0n04RfPC9jPMoi8RbPoVNMVAWW7t7S0984o3gqWXJPLWJdTzA/ ODOupqmvSpZld1rUklKKH/dY/Ha7iUTSci7rZrXSafXR8LBEn2FO6ehZqUvk7T/u qM3rs5wacHP2OcNDtwHHJoyfHXpxaQ2JqVOcUNkcdcwhN9dbdxA= =4/0b -----END PGP SIGNATURE----- Merge tag 'qcom-drivers-for-6.5' of https://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux into soc/drivers Qualcomm driver updates for v6.5 Konrad Dybcio is promoted, from reviewer, to co-maintainer. The mdt_loader gets a fix to the detection of split binaries, where the previous logic sometimes concluded that the first segments was not split, in a split image. The unconditional calling of scm_pas_mem_setup() turns out to cause a regression and is reverted. The altmode subfunction of pmic_glink is enabled for SM8450. A new driver for exposing power statistics from the RPM, for debugging purposes, is introduced. OCMEM gets a debug prints of the hardware version, QMI helpers are transitioned to alloc_ordered_workqueue() and an error message in ramp_controller is improved. An API is introduced to the SMEM driver to allow other drivers to query the SoC id, rather than open-coding the parsing of the relevant SMEM item. This is then used to clean up the Qualcomm NVMEM-based cpufreq driver. Socinfo is extended with knowledge about IPQ5018, IPQ5312 and IPQ5302. * tag 'qcom-drivers-for-6.5' of https://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux: (23 commits) soc: qcom: ocmem: Add OCMEM hardware version print cpufreq: qcom-nvmem: use helper to get SMEM SoC ID cpufreq: qcom-nvmem: use SoC ID-s from bindings soc: qcom: smem: introduce qcom_smem_get_soc_id() soc: qcom: smem: Switch to EXPORT_SYMBOL_GPL() soc: qcom: socinfo: move SMEM item struct and defines to a header soc: qcom: mdt_loader: Fix unconditional call to scm_pas_mem_setup MAINTAINERS: Add Konrad Dybcio as linux-arm-msm co-maintainer dt-bindings: sram: qcom,imem: Document MSM8226 soc: qcom: socinfo: Add Soc ID for IPQ5312 and IPQ5302 dt-bindings: arm: qcom,ids: add SoC ID for IPQ5312 and IPQ5302 soc: qcom: socinfo: Add IDs for IPQ5018 family dt-bindings: arm: qcom,ids: Add IDs for IPQ5018 family soc: qcom: Introduce RPM master stats driver dt-bindings: soc: qcom: Add RPM Master stats soc: qcom: qmi: Use alloc_ordered_workqueue() to create ordered workqueues soc: qcom: ramp_controller: Improve error message for failure in .remove() dt-bindings: soc: qcom: smd-rpm: allow MSM8226 over SMD soc: qcom: rpmpd: use correct __le32 type dt-bindings: soc: qcom: eud: Fix compatible string in the example ... Link: https://lore.kernel.org/r/20230611010044.2481875-1-andersson@kernel.org Signed-off-by: Arnd Bergmann <arnd@arndb.de> |
||
|
|
09f4406a02 |
PCI: tegra: Changes for v6.5-rc1
This contains updates to the PCI driver for Tegra194 and later devices that depend on the memory controller interconnect changes. -----BEGIN PGP SIGNATURE----- iQJHBAABCAAxFiEEiOrDCAFJzPfAjcif3SOs138+s6EFAmSDRaMTHHRyZWRpbmdA bnZpZGlhLmNvbQAKCRDdI6zXfz6zoSfhD/9JvmO5pX/zBODNPAO6XbUPswShzw5b zU7tQ7zhY8C2rkSDg+OmYO/a1WdXWnV+9ngLKZjIGygJd6akb0BMgDbFep3ZndaB xAhayvEh38kAXe4jGWFEUut/dhQsbezU4s57GxWU4gtm4RDCVl1JqXfakAgJvXmb WU1ay/yGc+7AWVXAYWm3fkuo8QgJCkOeA17Przrt7IakQF74qJZ3UN1Z2HjdNwCp KRuGqmZLRRnwzfOvWZWOq/bhr+zmbmqoLCyqraanUhaCQ1ltFWdsJ/v6eAteh1Ue IfEZznjNv5EmaH931Te++PoyhHKW9J13R6gyg2jY2pd493tADY7GyVnviUiuN9Rq XvuVodsyrbt0LX7VPQNjihsAwUwZA9N2L8OAKkPE1EBMEabzVVxZSoCQL34cCP01 EdlfgPPYR5tR+JV36R9yrTxTYvaLZxoRT9UZIlr3bu9JbkCzeGYzRwCax9l59/Kc u4FsBr46pVm/5tMlYtPzKrzwQqOt5/6qF8lbW9n8diMM36fCW9DvoBh6Mg57OEDm wRhnxxmXA1LP07iob81DruVqFfjJytA1OYh+R3qrxHzUSlPaBFTDEUd7/Lqls7f+ rjthxf+Wpyprwm7g84/3kDRzBlU1OQL00WIqQK9OKXPuxyQtyfhFcX2zXo+rAylb 6Iihsv+DFJskTQ== =qnyT -----END PGP SIGNATURE----- gpgsig -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEiK/NIGsWEZVxh/FrYKtH/8kJUicFAmSTVGcACgkQYKtH/8kJ UidNrQ//bKwagRP21klSIJSWc47iYbVjDxBGB11dzIAOH3OFGOJ1lVbBNOSLeeIN t7DZvi/ZPxVyHCOgk4FhETWnVP/dEbTBzaiJzyHu0e6QhzdHtAhOf9JhK+9SbF4b CohXuzAVUCQZEHLEG4YdW3uQq7H4iIxWaiECDYXM+wIzgFYIZAliR7mNNP/LiO6u 0n0ugEUqqqPglYEQ6Lu7Aw6U1IPHvQVnZUy9D1f7kQjwFQxHE8c/gTOHX+5FEHt5 Whm376mM1FgFGUL8k8b5MJ6lpXZ3tQizC0h76tucapWX/aaKSn21COGN+CjzXIJm FHIhClRokcdzz1rDL1uMatska7GS1vszAjzotNZYsoMLm9BL2YRJO+n0iEewSDa1 dDNIjpF3ffkuxmr5FSnd8oM+fREX2oljZ0WEyKsuDlklZMUmMLh6kBIWPsg6NuoU bFyIsdRQD7H14BJpX6oy/DhydFz7+hnjgmInRAWn9xLEzChOKfQA+Z4jGD80Pc8k 40dXPP7c3EjnIUFOE35Gvq/BLbqWmW7nVkc2ibtZU9XeIBfmDqcdeb6ab83Yw6Zt 3oinAtIGg2RjxtXpkYUFjmaKArHAdceX3qdAYTSnFLVJk6PNmL59AkUOGLVeWEq0 GAt1R2VzlSfBzNLVwhi1a3eetOA0JO4PLZ1VcCmjC51uVl28ONA= =BDY/ -----END PGP SIGNATURE----- Merge tag 'tegra-for-6.5-pci' of git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux into soc/drivers PCI: tegra: Changes for v6.5-rc1 This contains updates to the PCI driver for Tegra194 and later devices that depend on the memory controller interconnect changes. * tag 'tegra-for-6.5-pci' of git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux: PCI: tegra194: Add interconnect support in Tegra234 PCI: tegra194: Fix possible array out of bounds access Link: https://lore.kernel.org/r/20230609193620.2275240-5-thierry.reding@gmail.com Signed-off-by: Arnd Bergmann <arnd@arndb.de> |
||
|
|
095ee35a33 |
memory: tegra: Changes for v6.5-rc1
This introduces an interconnect provider for the memory controller and external memory controller found on Tegra234 chips that will eventually be used to dynamically scale the EMC frequency based on a device's bandwidth needs. -----BEGIN PGP SIGNATURE----- iQJHBAABCAAxFiEEiOrDCAFJzPfAjcif3SOs138+s6EFAmSDRTcTHHRyZWRpbmdA bnZpZGlhLmNvbQAKCRDdI6zXfz6zoaKyD/4sjVTfnZ9YoXkcPFd6zr1I8pNMC2pk yyDtSHN0EGcw5goSHF+Akqv5O0JEh8YAW0pQ+fxO3KdEGlZEYNBlC9rgjpz7TzHE 6zsajiIvLYOwSTbjVVlFn2U4H6ihFdawzag/vRDqu1b3wExus9VigWnEgHtj/RJT q1ODZXkwZrOBR3Z034ji6jJIQXVg54sEvt/Zlq7iYXabLXg8u5NDEbSd4GVBNwPB SwBUfc9ja/Y5xUKaXA/hqQ7gIfm4Hs5XVyCbLT75j259qVantbxtlURB3cme080m rRdyScngYFxuyBzQtQzLq+6u5tYJN6q3WUlXWvxI/gMw2IezFH6p0jXfCByriSMD 6d7h6Jk2d6bub3RUWLsurruHYSPqqvM9tI5sN6ZY4nq4uo0MplFEcrQBFXIJAJhy X/JaO9166K0mX73wNFoEmmay5ZTd8wLKvGdlfaHUdUKJcldhh3Ivhl2r0w9Ij6qE w1+QjUxtgabSb/69+3o2m4iil2I5Scc8jr3Vu1riW1yemKSQX7xS0PZ4a6k5/78O 2NGaFZqvs7Uo1EYGz91f50Go1hGLZOH0MMMjd+NSj3pZQvpB+BZ8rlGG7umbjIUF aTBj5hcXN3bBx4VQGnLFwUEbEd6GIog+d6COtpmQzixwdXxw8aUB/m7ouFSegz34 MMEoE0i11HMlyg== =OJYg -----END PGP SIGNATURE----- gpgsig -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEiK/NIGsWEZVxh/FrYKtH/8kJUicFAmSTVC0ACgkQYKtH/8kJ UieyxRAAiJKwY9bILWnKTPIJ+AlTDzp5ramSVsjD7KzlH6/pgWydgzRRhP/9zz87 f1/wnmMJ2vgWWa1g1NfeX4P8vZyHYsGiuBvQrevzP6Ekc0q19j6CI5tu5zDTy1aF dqZtkpOTqO5+ioTL5bTem2XISvWNnK1TyaWzSHnvbNgfvrWtMiqij9mJyeaF3hdm yCN0XbO8UaChbUobjgjzwg09BvrsN2CtG/2DATIgHUWDrkW0vER0QZRCF0V9mg3O 5kszkfLAsm/7TcQiPAeHEc2IXNRnYl1f4Gkjg7e47Itxkv5+rm/liejdYMZfIQmc Kj0eQerTB974qrcBsrwVE12lNwDK4+3FbAWOZjbXaLtYf27+pSjoG0YVduv8VUNi H81ehi+pHma7Boekf2i9XMVC1+EBBlpPBjxCpaDN5ck7kIkO2bBMX9avTGE9qfn5 9lpU64z6xHv/3YEcnOty4Ggs0V3ZLz4iRkFfWUDtYYsXnFyes1K9ooaDzHojisk0 /vE0KqImlZdlBuBUYpgEBcM/s4V1PtpN3nQtVpUUb77M90GmTLGwLjM8+Y1+JuXV N9eGiPR8YhuMzy4eQR4YEfIqPqwEstRqkOicctJaCDi3Hg4OXmUdUDS66vV9wm+V ntfdphilxBp2EHG42IhKkVH5LdSm/17xbxd2t1RwZ7cMZ7Q5hpw= =7PpG -----END PGP SIGNATURE----- Merge tag 'tegra-for-6.5-memory' of git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux into soc/drivers memory: tegra: Changes for v6.5-rc1 This introduces an interconnect provider for the memory controller and external memory controller found on Tegra234 chips that will eventually be used to dynamically scale the EMC frequency based on a device's bandwidth needs. * tag 'tegra-for-6.5-memory' of git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux: memory: tegra: Make CPU cluster BW request a multiple of MC channels memory: tegra: Add software memory clients in Tegra234 memory: tegra: Add memory clients for Tegra234 memory: tegra: Add interconnect support for DRAM scaling in Tegra234 dt-bindings: tegra: Add ICC IDs for dummy memory clients dt-bindings: tegra: Document compatible for IGX Link: https://lore.kernel.org/r/20230609193620.2275240-4-thierry.reding@gmail.com Signed-off-by: Arnd Bergmann <arnd@arndb.de> |
||
|
|
b161ec3d38 |
firmware: tegra: Changes for v6.5-rc1
This adds support for using system memory as shared memory between the CPU and the BPMP, which will be needed for Tegra264 support. -----BEGIN PGP SIGNATURE----- iQJHBAABCAAxFiEEiOrDCAFJzPfAjcif3SOs138+s6EFAmSDRD0THHRyZWRpbmdA bnZpZGlhLmNvbQAKCRDdI6zXfz6zoc7MEAC7nU4P96tevI2AyS4b2LCPW/Rk969y PSHxZQuewhGysy+zmwrxy+dpJ0ONfD6ae8lQ1p0XXITDC2Z5yHJASgmbuxznS4gl OVn3PjB+GXVLYbz3B2HZW/lPN/t6w3mDcjmH3XJ5wuGdlV0PAJy4V9I+WJIKFAGq m26NpfkwsQnC99weCQd8F6/m+tAU54bLBULipv/nv6pbBoc7222+PGiC4dXrTR32 WZiSiqcKXpweMeGcPRiKXokgvn2PphbawQxQf9Ejh9ufWpB3ddrWHniY5obv8Vnj MBYXsL1QVoGo/d1FXbFgw2Vx4F9FXZQh3YHIR3dFf57ytwhZHwqKFFJSL4LoA1bH CD+IDrtgXte+mo6VcoPXbkaPNmMEzLRRLSqOoKsWnQHadhF5PGoDLSZ8yb3/QME+ PP7VgLRgvLP8u7aY6+foNktBrY9KJfXvZa9YXOISHz5CNtXNuc0rBw0wTTdnSt/v VYbDP+5s++8fWFr/dd+q2NaZxGoM6ZUNDsVMn1g9AFnYxEKc7KVn6XJVijFWeqFu TkPDLfvp0/x+6lwTYa19s7w2cTB+fUPKIqlpWR66QZ+MZb76RRE0Ymp+hCleK6PY 5nn/7UpfP38RS+EoL11zedcQ329MgLmrBNWjAzpJEdLGCDkEIZRw7pXg1P2EWsJS f8gyVgb5O2RGYw== =fwZn -----END PGP SIGNATURE----- gpgsig -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEiK/NIGsWEZVxh/FrYKtH/8kJUicFAmSTU7cACgkQYKtH/8kJ UieF4xAA43v/+kPsHfZoBhzM+DlLQUQhsQMzIrH/xncDd+Pw8zvtxGIpQy4Ubq/c kORhtyVHiIiDzFa6zg9pb24YIBAm3irkVIq9bBUlrCaWT5ias32FGyvZjaSwqhC1 MyeRZ4GT9AkJ0SucAS8sGy0VcP3r+utfeXzimXb46kXXKX4styMn5QDMbzwjJN2x RJd6PhzE0rleujQ8/YfTKwdIc6I8i+RM2LdoAK/AVnSeVBkFciWGsqxydEmdlSiD a06N075zOBK+GW4DNF/IrxcAyk3Q7FrCNDRrkJABN/DTG0EYGwZSFuBquE2TweGc 5+HwDAjFZnuOZsqqfAb0jWsprkGhEa7Ahur45W48I/Iyfo1ZkxZjn/yFgJVbYw8V V/7Rfe9mI09SAVR2qRYiQcUGhhGK/ityuNk5xTY8xr/ob3EO17UibwX0s0FiPfX6 kq8SL4LWKoy4azDNtm1+Xdew5cAqWFZhxLXgwlXuym7FUoSotzP/aMCujM4tno/p Hc5ZtlVPyAJQbRz4YoWEANU2FLUUkq1FOZ4n8IF9hQ8AZIQ5Ujc7p4MY8o6gqByn 4JW0+Vw9tF9fl1Y/kUkjSdsUryt0bFlBEdJK101tFHpTLDRqMd4IbWDmtRP0rRsC iYYv/16JU49Eez4fYflEbDGvAVfn1L0C3Tey7jhwToLzxUVbkhc= =3AXn -----END PGP SIGNATURE----- Merge tag 'tegra-for-6.5-firmware' of git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux into soc/drivers firmware: tegra: Changes for v6.5-rc1 This adds support for using system memory as shared memory between the CPU and the BPMP, which will be needed for Tegra264 support. * tag 'tegra-for-6.5-firmware' of git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux: firmware: tegra: bpmp: Add support for DRAM MRQ GSCs Link: https://lore.kernel.org/r/20230609193620.2275240-2-thierry.reding@gmail.com Signed-off-by: Arnd Bergmann <arnd@arndb.de> |
||
|
|
bc889e870e |
soc/tegra: Changes for v6.5-rc1
This adds initial support for identifying the Tegra264 SoC family and fixes potential issues when reading from the FUSE block. A new software wake event for the AON cluster is added on Tegra234 and the debugfs initialization is drastically simplified. -----BEGIN PGP SIGNATURE----- iQJHBAABCAAxFiEEiOrDCAFJzPfAjcif3SOs138+s6EFAmSDRAMTHHRyZWRpbmdA bnZpZGlhLmNvbQAKCRDdI6zXfz6zoePdD/kBmBNU0jOYOPCIDvL9/ZGallfogOyQ 7+MEyY/POCYiWiBFS2qixGHr9yu5KgmEc8y7Mq7C7/PmC5y4EoLuZF7QRiCUl78t wyCROYb0WqBivAMdDFyXyxxJDCmNXGUqZyx6QpGQlJEwWlrJMExQsaw9F6366/JR q0QPkKtzGGVXwxwpH3XdrfD/9cUOhTe8oGZ9uPW/q3j0JqO1x9pcnVSUWU3nXeEy pvQjJjXAlB+9imAYuykDZMTUhlTqTrQTREk4JlG1UQkrs9vh4SDrPYh7IKlhbKct /crML7JOZwoIAQ2lmapqrSijS03jo3F1RvEJVigYSXZhkFFwRRxuUs70jD/zGYbO FIKzkQAr0cY7Dphkos3H8Rneyd87kJ7f1LDLNnTDXU/LaGWzZSaxJFqbTlRPL/Pr HC6oRtwhD1FDEZO74lxfRDrlWiX6xBHsB+uOhTHM65e7whWO216YQDS8hyxHcnUb fV51tuo3Fs5Hlb9nsYnFS7hE4YEQ3Tmq2fI/wHSesmMm14U3DMkhIvUff8dZLRc3 Wp/3XsRPfHuh1kZCHi4VDUeHSY07W1uqkBqrYBOXugNc7ZLiVhQV5lCRFMJPPvCz wS0d0CUNhxa7tcXu/GLaMCm5CsUkovC1cC2YqqLqk8PtfABX1OCZZadn4qUk53wl hlMER8mbyF0Ypw== =mlOG -----END PGP SIGNATURE----- gpgsig -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEiK/NIGsWEZVxh/FrYKtH/8kJUicFAmSTUe4ACgkQYKtH/8kJ UidTRBAAnWhSOO8MaR7tmDnJO7ldOcUYWpoWViLM4Cgt6WLt0HM5F3Dre0PtTgWS Fv0CCIuRVDk9UK2Sg3XG27aOkJmGgK2s5ZHROfk2WlacOXkLL3/C3ieZcXRom5rn BQXAXLGd1sgTHQ7VSLDYApw//XpwmSczE7HeYZ+96z0XUuCFgQJgAHWisN7cPc4m PjY55BIZKLvVCFRb09Zu8uZaXYtp/w8EEmgYioV2PbuM4nbdjb32ivs76G3+A80T 8gLqx5AO/0kx3roZSlgP9AgHAXy2snT42Hc+o/1EiblwKICXv/wmVFP3Z2a8596y y81kPfgARm09YV/9ehKoJVxxYEmG3i97SA1ATc5Y7whtmGSB+11AFZyedf6iaXk1 MT6AIKNgVES6Xa5kIJ2DgxCaUMe7VhvfohN8VIaeqDY4Iyo/XwlW4RsWId5saL5a BPSlLBplhKYdy8O9H0WDEc+c1Gkk8zT/O5rA6rITmbqF8sMvzyKTEtslyx5vPzp4 ZaiD6XMQHFNQUC1v4i+zV5MkYoTT04ML4GGwd8AjkVPQUSaOUOBMDP9cHEWttFpT NLdk36ZSu1Yz/dahBHTHrwCvejcTl7V+KoB1Fhc19sK1wZIVfdd2jt4sjm+QLr2T 3cxcjnvozKtyRCcEt1+r9BpnF6t05eSGNS0ZS124MS61wwewKqY= =rooh -----END PGP SIGNATURE----- Merge tag 'tegra-for-6.5-soc' of git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux into soc/drivers soc/tegra: Changes for v6.5-rc1 This adds initial support for identifying the Tegra264 SoC family and fixes potential issues when reading from the FUSE block. A new software wake event for the AON cluster is added on Tegra234 and the debugfs initialization is drastically simplified. * tag 'tegra-for-6.5-soc' of git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux: soc/tegra: pmc: Use devm_clk_notifier_register() soc/tegra: pmc: Simplify debugfs initialization soc/tegra: fuse: Fix Tegra234 fuse size soc/tegra: pmc: Add AON SW Wake support for Tegra234 soc/tegra: fuse: Add support for Tegra264 Link: https://lore.kernel.org/r/20230609193620.2275240-1-thierry.reding@gmail.com Signed-off-by: Arnd Bergmann <arnd@arndb.de> |
||
|
|
dad9774dea |
A single regression fix for a regression fix:
For a long time the tick was aligned to clock MONOTONIC so that the tick event happened at a multiple of nanoseconds per tick starting from clock MONOTONIC = 0. At some point this changed as the refined jiffies clocksource which is used during boot before the TSC or other clocksources becomes usable, was adjusted with a boot offset, so that time 0 is closer to the point where the kernel starts. This broke the assumption in the tick code that when the tick setup happens early on ktime_get() will return a multiple of nanoseconds per tick. As a consequence applications which aligned their periodic execution so that it does not collide with the tick were not longer guaranteed that the tick period starts from time 0. The fix for this regression was to realign the tick when it is initially set up to a multiple of tick periods. That works as long as the underlying tick device supports periodic mode, but breaks under certain conditions when the tick device supports only one shot mode. Depending on the offset, the alignment delta to clock MONOTONIC can get in a range where the minimal programming delta of the underlying clock event device is larger than the calculated delta to the next tick. This results in a boot hang as the tick code tries to play catch up, but as the tick never fires jiffies are not advanced so it keeps trying for ever. Solve this by moving the tick alignement into the NOHZ / HIGHRES enablement code because at that point it is guaranteed that the underlying clocksource is high resolution capable and not longer depending on the tick. This is far before user space starts, so at the point where applications try to align their timers, the old behaviour of the tick happening at a multiple of nanoseconds per tick starting from clock MONOTONIC = 0 is restored. -----BEGIN PGP SIGNATURE----- iQJHBAABCgAxFiEEQp8+kY+LLUocC4bMphj1TA10mKEFAmSTUNQTHHRnbHhAbGlu dXRyb25peC5kZQAKCRCmGPVMDXSYoQQjD/4+zHK7IxRK+1k1lIStxksEudVeNuqK 7RZKNTawZFSChrxGmv5uhmqYDK9/tudnZot+uyAXI81JHnnGSXbco+VrAA2DQ2v2 w/oxhAHIAobJWDzUuCqT2YsseDVNoTGMrTTPrL4klXqhVtShVOLTI/603+macEiw Olqmd7XxlyhCloNqoMIh18EwSNIs78kP3YAQHUmq3NoRkJT5c3wWKvZy38WOxSJ9 Jjpw75tePfcwWte9fGVq+oJ8hOWkPAKN5hFL8420RrEgdIkxKlhVmuyG48ieZKH1 LE1brB5iaU8+M91PevZMRlD7oio8u/d6xX1vT3Cqz9UBe1NLj1I0ToX6COhwSNxm 50U0HJ5wGlpodu4IyBHXTG45UAVwpOg/EgDlFigeP3Nxl6h45ugrA010r6FqE1zV KltjNGsk/OD5d8ywW+yManU2mySm9znqmWN2zbjRGm138Tuz7vglcBhFB6jEJFUF V8vYPLwI4J2gqifx8NoFBIfLuZp/+D4LOQiJ7XRc9CVm3JLK8Xi8fxnHGTBwJHIn 45WU4hzmY7fjR/gGhAyG7lH6tlo7VTC9/lrO+YtAy2hL2sK14+m/ZH7836I5bAhw EgSyVlcfR6tgO55I3JgkbNIyO5TUAZPZIAY1TlyR53xXvMkb9aZTh9UMm1xMJ3uX +sQaLAuDFNUQSg== =/uvx -----END PGP SIGNATURE----- Merge tag 'timers-urgent-2023-06-21' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull timer fix from Thomas Gleixner: "A single regression fix for a regression fix: For a long time the tick was aligned to clock MONOTONIC so that the tick event happened at a multiple of nanoseconds per tick starting from clock MONOTONIC = 0. At some point this changed as the refined jiffies clocksource which is used during boot before the TSC or other clocksources becomes usable, was adjusted with a boot offset, so that time 0 is closer to the point where the kernel starts. This broke the assumption in the tick code that when the tick setup happens early on ktime_get() will return a multiple of nanoseconds per tick. As a consequence applications which aligned their periodic execution so that it does not collide with the tick were not longer guaranteed that the tick period starts from time 0. The fix for this regression was to realign the tick when it is initially set up to a multiple of tick periods. That works as long as the underlying tick device supports periodic mode, but breaks under certain conditions when the tick device supports only one shot mode. Depending on the offset, the alignment delta to clock MONOTONIC can get in a range where the minimal programming delta of the underlying clock event device is larger than the calculated delta to the next tick. This results in a boot hang as the tick code tries to play catch up, but as the tick never fires jiffies are not advanced so it keeps trying for ever. Solve this by moving the tick alignement into the NOHZ / HIGHRES enablement code because at that point it is guaranteed that the underlying clocksource is high resolution capable and not longer depending on the tick. This is far before user space starts, so at the point where applications try to align their timers, the old behaviour of the tick happening at a multiple of nanoseconds per tick starting from clock MONOTONIC = 0 is restored" * tag 'timers-urgent-2023-06-21' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: tick/common: Align tick period during sched_timer setup |
||
|
|
017fb83ee0 |
block: Improve kernel-doc headers
Fix the documentation of the devt_from_partuuid() return value. Fix the following two recently introduced kernel-doc warnings: block/bdev.c:570: warning: Function parameter or member 'hops' not described in 'bd_finish_claiming' block/early-lookup.c:46: warning: Function parameter or member 'devt' not described in 'devt_from_partuuid' Cc: Christoph Hellwig <hch@lst.de> Fixes: |
||
|
|
fa50d6b8a5 |
coresight: Updates for v6.5
CoreSight and hwtracing subsystem updates for v6.5 includes:
- Fixes to the CTI module reference leaks. This involves,
redesign of how the helper devices are tracked and CTI
devices have been converted to helper devices.
- Fix removal of the trctraceidr file from sysfs for ETMs.
- Match all ETMv4 instances based on the ETMv4 architected
registers and the CoreSight Component ID (CID), than having
to add individual PIDs for CPUs.
- Add support for Dummy CoreSight source and sink drivers.
- Add James Clark as Reviewer for the CoreSight kernel drivers
- Fixes to HiSilicon PCIe Tune and Trace Device driver
Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEuFy0byloRoXZHaWBxcXRZPKyBqEFAmSS/goACgkQxcXRZPKy
BqFShQ//Z25Qnf0y2VdOBgZ1xWYeOTjkeQ2AVYE2hepV78N5rnI8BgcwlBNrF5IA
uTu2U+nSenkCurWk+wOrmXaQ2SXkEEp2Gsm866WzeL4OjWsqxpdoZ1l2u7/YqxMK
4QIP2ELS71KcQMIIJ31eYDSMro/gA8xDPh2QGhZKihUQAsoVQOghX7Y1eoT+4a/V
pvsngu71iM45jHR1eFkp9/rQCKhy9OA58Q8gtg21uotOja9jvHQpRZ4TGN7en0CP
RDVmIaxRDh3sPWoVpIPYs3nL8DX2NeSX5BVC/xq2P0UAHN6C9rp+Kom1XN7VZqS6
UdgyNw1iulwtGW0zF5jwZrj5ZGMY4CFQhS6R3/DF5ohzuSwtSOY32cYyLKrUjmpx
W0Nj7Pu/UaHU/kTu5+qItgTp0FP6du9p2VnZZuhroGLkGRSi2u392gKmPnKbErx5
8tLo2ucAw1Kasm7pef2rj9M9etcWJws+dD1qWg96fvuKvJQX9+milweyg0I4NTXy
p8GHpITZ65chWUJjqlxgnbvhB2V1eKP6bpG3sjzhCC2h9yXyzn4grOoSu/XNVQdx
W3ldxRMlsoIFBbUb42yJQROSVezaYVC+5sk+fufRVbNR3b5ZmJOGYiCUtM+MMvtj
q/1M/liPOYIf6Ix94EzxujdU12Ki5XLb5rWZqS3Gvebc8OG+o9E=
=XWfo
-----END PGP SIGNATURE-----
Merge tag 'coresight-next-v6.5' of git://git.kernel.org/pub/scm/linux/kernel/git/coresight/linux into char-misc-next
Suzuki writes:
coresight: Updates for v6.5
CoreSight and hwtracing subsystem updates for v6.5 includes:
- Fixes to the CTI module reference leaks. This involves,
redesign of how the helper devices are tracked and CTI
devices have been converted to helper devices.
- Fix removal of the trctraceidr file from sysfs for ETMs.
- Match all ETMv4 instances based on the ETMv4 architected
registers and the CoreSight Component ID (CID), than having
to add individual PIDs for CPUs.
- Add support for Dummy CoreSight source and sink drivers.
- Add James Clark as Reviewer for the CoreSight kernel drivers
- Fixes to HiSilicon PCIe Tune and Trace Device driver
Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
* tag 'coresight-next-v6.5' of git://git.kernel.org/pub/scm/linux/kernel/git/coresight/linux: (27 commits)
hwtracing: hisi_ptt: Fix potential sleep in atomic context
hwtracing: hisi_ptt: Advertise PERF_PMU_CAP_NO_EXCLUDE for PTT PMU
hwtracing: hisi_ptt: Export available filters through sysfs
hwtracing: hisi_ptt: Add support for dynamically updating the filter list
hwtracing: hisi_ptt: Factor out filter allocation and release operation
coresight: dummy: Update type of mode parameter in dummy_{sink,source}_enable()
Documentation: trace: Add documentation for Coresight Dummy Trace
dt-bindings: arm: Add support for Coresight dummy trace
Coresight: Add coresight dummy driver
MAINTAINERS: coresight: Add James Clark as Reviewer
coresight: etm4x: Match all ETM4 instances based on DEVARCH and DEVTYPE
coresight: etm4x: Make etm4_remove_dev() return void
coresight: etm4x: Fix missing trctraceidr file in sysfs
coresight: Fix CTI module refcount leak by making it a helper device
coresight: Enable and disable helper devices adjacent to the path
coresight: Refactor out buffer allocation function for ETR
coresight: Make refcount a property of the connection
coresight: Store in-connections as well as out-connections
coresight: Simplify connection fixup mechanism
coresight: Store pointers to connections rather than an array of them
...
|
||
|
|
92852219a3 |
interconnect changes for 6.5
This pull request contains the interconnect changes for the 6.5-rc1 merge window which is a mix of core and driver changes with the following highlights: - Support for configuring QoS on the Qualcomm's RPM-based platforms, that required special handling of some interface (non-scaling) clocks. - Support for clock-based interconnect providers for cases when clock corresponds to bus bandwidth. This is used to enable CPU cluster bandwidth scaling on MSM8996 platforms. One patch is touching a file in the clock subsystem that has been acked by the maintainer. Core changes: interconnect: add clk-based icc provider support interconnect: icc-clk: fix modular build interconnect: drop unused icc_get() interface Driver changes: interconnect: qcom: rpm: Rename icc desc clocks to bus_blocks interconnect: qcom: rpm: Rename icc provider num_clocks to num_bus_clocks interconnect: qcom: rpm: Drop unused parameters interconnect: qcom: rpm: Set QoS registers only once interconnect: qcom: rpm: Handle interface clocks interconnect: qcom: icc-rpm: Enforce 2 or 0 bus clocks interconnect: qcom: rpm: Don't use clk_get_optional for bus clocks anymore interconnect: qcom: msm8996: Promote to core_initcall interconnect: qcom: rpm: allocate enough data in probe() dt-bindings: interconnect/msm8996-cbf: add defines to be used by CBF clk: qcom: cbf-msm8996: scale CBF clock according to the CPUfreq dt-bindings: interconnect: fsl,imx8m-noc: drop unneeded quotes Signed-off-by: Georgi Djakov <djakov@kernel.org> -----BEGIN PGP SIGNATURE----- iQIcBAABAgAGBQJkkyQsAAoJEIDQzArG2BZj7GQQAMLrW2sZcxJhq5Fe2wKV4W5M ItIE7xME1Vk9PvuulZIJ57tZIKfOTJpXwwbh6qWJOejYGePrmgtT89iS0fadO81f yCKv2O2hD+Xukv+gFzyuX3AYEfur7myaCTfmRx93xVDYUz0d95Kj4BlYA84xkjXU i+wte+nX/nw9W78s+Y9BHcs389a3HTre0WR1c0eOboPmt8D0U9cBOdiZMHkSUc+4 /8RDUYRdsTBR0AblpPExm2JjoSRKUGEw7N8ZFZhOXaejCjmGoeVXeTdnHO+tjXaq HQ9290C9Pz0BZWdKXaFFfjc4Wqu3RYjdXJmHNo74a4sFHE+H/j33eRSgC24qMWg5 5hRsH8+gv0ZhoyLv6Ucd2MRQQvvUYCLNNeTlQ2/RkOFuqewLKqpXCiihbuKUpOi0 CLeWKTDjNlIM5murJURXX88+xjZ1UvpuBXe/U+i9jrhjSQ6IjnAppoDw7anrrxTE ldLGFPzJoWL8VO1H0povS08/kd25+fgkjL/3pZHagSMLjDWNOXA+xDLkRYGBCNi7 rZpLT/4nBFTcrcYEsJ2EPAqHYK19kD76NVrz+Fj2gzF9Ych3q+2MSkLb132Qkyzf qLn3SqWJQoPAhy0kQbOt3XBnYon8QjVEpcZIWf9J3Qr2au4SdHi7hr3ki86a5Pfz ne03bJDC237hO6q4jY0b =Smk9 -----END PGP SIGNATURE----- Merge tag 'icc-6.5-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/djakov/icc into char-misc-next Georgi writes: interconnect changes for 6.5 This pull request contains the interconnect changes for the 6.5-rc1 merge window which is a mix of core and driver changes with the following highlights: - Support for configuring QoS on the Qualcomm's RPM-based platforms, that required special handling of some interface (non-scaling) clocks. - Support for clock-based interconnect providers for cases when clock corresponds to bus bandwidth. This is used to enable CPU cluster bandwidth scaling on MSM8996 platforms. One patch is touching a file in the clock subsystem that has been acked by the maintainer. Core changes: interconnect: add clk-based icc provider support interconnect: icc-clk: fix modular build interconnect: drop unused icc_get() interface Driver changes: interconnect: qcom: rpm: Rename icc desc clocks to bus_blocks interconnect: qcom: rpm: Rename icc provider num_clocks to num_bus_clocks interconnect: qcom: rpm: Drop unused parameters interconnect: qcom: rpm: Set QoS registers only once interconnect: qcom: rpm: Handle interface clocks interconnect: qcom: icc-rpm: Enforce 2 or 0 bus clocks interconnect: qcom: rpm: Don't use clk_get_optional for bus clocks anymore interconnect: qcom: msm8996: Promote to core_initcall interconnect: qcom: rpm: allocate enough data in probe() dt-bindings: interconnect/msm8996-cbf: add defines to be used by CBF clk: qcom: cbf-msm8996: scale CBF clock according to the CPUfreq dt-bindings: interconnect: fsl,imx8m-noc: drop unneeded quotes Signed-off-by: Georgi Djakov <djakov@kernel.org> * tag 'icc-6.5-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/djakov/icc: dt-bindings: interconnect: fsl,imx8m-noc: drop unneeded quotes interconnect: icc-clk: fix modular build clk: qcom: cbf-msm8996: scale CBF clock according to the CPUfreq interconnect: drop unused icc_get() interface interconnect: qcom: rpm: allocate enough data in probe() interconnect: qcom: msm8996: Promote to core_initcall interconnect: qcom: rpm: Don't use clk_get_optional for bus clocks anymore interconnect: qcom: icc-rpm: Enforce 2 or 0 bus clocks interconnect: qcom: rpm: Handle interface clocks interconnect: add clk-based icc provider support dt-bindings: interconnect/msm8996-cbf: add defines to be used by CBF interconnect: qcom: rpm: Set QoS registers only once interconnect: qcom: rpm: Drop unused parameters interconnect: qcom: rpm: Rename icc provider num_clocks to num_bus_clocks interconnect: qcom: rpm: Rename icc desc clocks to bus_blocks |
||
|
|
a4bd03e7cb |
ARM: dts: Move .dts files to vendor sub-directories
The arm dts directory has grown to 1559 boards which makes it a bit unwieldy to maintain and use. Past attempts stalled out due to plans to move .dts files out of the kernel tree. Doing that is no longer planned (any time soon at least), so let's go ahead and group .dts files by vendors. This move aligns arm with arm64 .dts file structure. -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEktVUI4SxYhzZyEuo+vtdtY28YcMFAmSTQqAACgkQ+vtdtY28 YcOJtQ/8CUerhXJZTaSCUiOJw7OgPfIU74YZDpByxtHjdKNqL4/khgTBwFxJmeSG QBinBfmXQRUu/vpnCEuODOkILJbe+uUjzBy+cB4a4XR2waVSJSz2tR8U0sN0qqo+ yQ4Sd+ViYIMHmLEfxspBxOYp89Ko/Z+IvOUaZquGnS1X7tTWmlBtQQ5QWDWJ2cwn tJMZ2+b14TOHT3qoJsG5fippxVHIVnjfSxTPRSOlBuuQSnataV/KQUNUYFCxzHhH smM8WZ4RCYMy6pArHpVrGxpI6UvcPuuKQK825B7kWC3YZQ1REU0ub0L1aONeNMAG e9gsmDme4HWUyTNxQ7TjbzMDGGOXvB0I04G/+1MNJBlW6nCcgCqylz/7nUzq5+0j FUAhxZBZtDV6JblKTIT68iV+ibvnbKc5MXZE6FpYRD87d5IQ3yfgAgzCrcPMpZBg kFmOaHFQh4BKjiI4bOVKSXS35XRoCqBA7xDONTV0yJyx4iySZaNYWaUmSunRmtXc lX1w6iDEAwaLfTtCEWMIx6hCZv9CLE3Q2AjehoEqoHOOJ+DC2s+4ianw/iiexQ0J 2LDrXAeU5PDkyODlbc6Wa7O2NwDXfLFK1/roMCITI7ibjADwDpahlrTGFV5GyNNF 3+dWqH6S8RuomIjYRsnt79zmsIMErw+U0qon72peEjBS+FkwHnc= =Jjgv -----END PGP SIGNATURE----- gpgsig -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEiK/NIGsWEZVxh/FrYKtH/8kJUicFAmSTSlsACgkQYKtH/8kJ UienLRAArmPvsuwNtx4p/brAgYHRED+c/71dGy3y2c4/m/3Int1t+vNzNT65UfL6 ActweykUwWOP5HHhMkhCY1NyyOSHkMhrSAt7uWpghSPR3iPQ3R8rK+7n3mA2y98l 1Swursyf9tr3PRlmeERkdZbD8Wm4CEtfHKtzt6EwVCYNuCF+oJwjQzr4UFUJB0bj 3keg8rxzNqh1C/ttd2n/1n8eb51+Q4vADof3HC5OfhIjmWrTuhGukjoGdmJ1Ze5E f5bu6YyFNEF7kujiXoT4ZIv9yCQzpTkhFnnUabkXQ50s09CIZ+KM+/OdLm3EP/zy efUvHncfzs56n1IoJGlgQyQ3uzKAjwtwXqKyD+mPC+GIEPDhWmKRAkcoW1L9Box2 pefiSIjTsVwXLM96h7HaUp+KnW0JjSploqMMNcHSmmoSh10Wa38ODHEoYhJJQxqV pu2Dx9AZDaqvkjQaFFYWubpgcs6hL1M0PxzZI1b/cU54BBEOkFcMCCk3jObEAn5H 1gsDsW2KM5fRD0qzlvZIW1I2oHpt52ip+HImsCSRldbXJRBnlofXur1Wn3rorbM5 +5SavKlZ0SE4GYPQXdD1Pi9PHoe9euU5oV5Einz8zZU3HzhUaNp+TqggXDA6jLSz z6nFzX3JJpV6IN7jdYuGwlK3hqncVYVEkQi70SbFGHbgUfiLjIM= =h4ch -----END PGP SIGNATURE----- Merge tag 'arm-dts-mv-for-6.5' of git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux into soc/dt ARM: dts: Move .dts files to vendor sub-directories The arm dts directory has grown to 1559 boards which makes it a bit unwieldy to maintain and use. Past attempts stalled out due to plans to move .dts files out of the kernel tree. Doing that is no longer planned (any time soon at least), so let's go ahead and group .dts files by vendors. This move aligns arm with arm64 .dts file structure. * tag 'arm-dts-mv-for-6.5' of git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux: ARM: dts: Move .dts files to vendor sub-directories kbuild: Support flat DTBs install ARM: dts: Add .dts files missing from the build ARM: dts: allwinner: Use quoted #include Link: https://lore.kernel.org/r/20230621185025.GA3197738-robh@kernel.org Signed-off-by: Arnd Bergmann <arnd@arndb.de> |
||
|
|
75bfb70457 |
nfsd: remove redundant assignments to variable len
There are a few assignments to variable len where the value is not
being read and so the assignments are redundant and can be removed.
In one case, the variable len can be removed completely. Cleans up
4 clang scan warnings of the form:
fs/nfsd/export.c💯7: warning: Although the value stored to 'len'
is used in the enclosing expression, the value is never actually
read from 'len' [deadcode.DeadStores]
Signed-off-by: Colin Ian King <colin.i.king@gmail.com>
Reviewed-by: Jeff Layton <jlayton@kernel.org>
Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
|