BMC/Intel-BMC/linux.git/include/uapi, branch dev-5.15-intel

soc: aspeed: mctp: Add IOCTL to set own EID

2022-06-09T17:57:41+00:00

The driver doesn't implement MCTP logic, which means that it requires its clients to prepare valid MCTP over PCIe packets. Because we support MCTP stacks in both kernel and userspace, and since MCTP protocol is a part of userspace, we need userspace to update own EID information in kernel to provide it for in-kernel aspeed-mctp clients. Previously, own EID information was updated by userspace using SET_EID_INFO which now is deprecated and replaced by SET_EID_EXT_INFO to pass CPU EID and Domain ID mappings. To provide own EID information for in-kernel clients, add a dedicated IOCTL. Signed-off-by: Iwona Winiarska

soc: aspeed: mctp: Mark GET_EID_INFO/SET_EID_INFO as deprecated

2022-06-09T17:57:41+00:00

ASPEED_MCTP_GET_EID_INFO and ASPEED_MCTP_SET_EID_INFO shouldn't be used in future projects - they are replaced by EXT_INFO variants. Update documentation for aspeed-mctp UAPI header to mark them as deprecated. Signed-off-by: Iwona Winiarska

Merge commit '49caedb668e476c100d727f2174724e0610a2b92' of https://github.com/openbmc/linux into openbmc/dev-5.15-intel-bump_v5.15.36

2022-05-12T14:46:40+00:00

Signed-off-by: Sujoy Ray

peci: mctp: Add DomainId support for peci-mctp

2022-04-15T07:15:51+00:00

Get DomainId from peci subsystem message to send message to requested EID. Required EID is taken from aspeed-mctp based on the discovery performed by user-space application. For each particular agent behind master, information about its BDF/DomainId is sufficient to get its EID. Signed-off-by: Krzysztof Richert

soc: aspeed: mctp: Add IOCTLs for extended EID information

2022-04-15T07:15:51+00:00

For PECI over MCTP purposes, aspeed-mctp driver needs to be extended that allows to set Domain ID information. Signed-off-by: Krzysztof Richert

Merge tag 'v5.15.34' into dev-5.15

2022-04-14T08:19:30+00:00

This is the 5.15.34 stable release Signed-off-by: Joel Stanley

bpf: Make remote_port field in struct bpf_sk_lookup 16-bit wide

2022-04-13T18:59:25+00:00

commit 9a69e2b385f443f244a7e8b8bcafe5ccfb0866b4 upstream. remote_port is another case of a BPF context field documented as a 32-bit value in network byte order for which the BPF context access converter generates a load of a zero-padded 16-bit integer in network byte order. First such case was dst_port in bpf_sock which got addressed in commit 4421a582718a ("bpf: Make dst_port field in struct bpf_sock 16-bit wide"). Loading 4-bytes from the remote_port offset and converting the value with bpf_ntohl() leads to surprising results, as the expected value is shifted by 16 bits. Reduce the confusion by splitting the field in two - a 16-bit field holding a big-endian integer, and a 16-bit zero-padding anonymous field that follows it. Suggested-by: Alexei Starovoitov Signed-off-by: Jakub Sitnicki Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20220209184333.654927-2-jakub@cloudflare.com Signed-off-by: Greg Kroah-Hartman

can: isotp: set default value for N_As to 50 micro seconds

2022-04-13T18:59:08+00:00

[ Upstream commit 530e0d46c61314c59ecfdb8d3bcb87edbc0f85d3 ] The N_As value describes the time a CAN frame needs on the wire when transmitted by the CAN controller. Even very short CAN FD frames need arround 100 usecs (bitrate 1Mbit/s, data bitrate 8Mbit/s). Having N_As to be zero (the former default) leads to 'no CAN frame separation' when STmin is set to zero by the receiving node. This 'burst mode' should not be enabled by default as it could potentially dump a high number of CAN frames into the netdev queue from the soft hrtimer context. This does not affect the system stability but is just not nice and cooperative. With this N_As/frame_txtime value the 'burst mode' is disabled by default. As user space applications usually do not set the frame_txtime element of struct can_isotp_options the new in-kernel default is very likely overwritten with zero when the sockopt() CAN_ISOTP_OPTS is invoked. To make sure that a N_As value of zero is only set intentional the value '0' is now interpreted as 'do not change the current value'. When a frame_txtime of zero is required for testing purposes this CAN_ISOTP_FRAME_TXTIME_ZERO u32 value has to be set in frame_txtime. Link: https://lore.kernel.org/all/20220309120416.83514-2-socketcan@hartkopp.net Signed-off-by: Oliver Hartkopp Signed-off-by: Marc Kleine-Budde Signed-off-by: Sasha Levin

bpf: Make dst_port field in struct bpf_sock 16-bit wide

2022-04-13T18:59:02+00:00

[ Upstream commit 4421a582718ab81608d8486734c18083b822390d ] Menglong Dong reports that the documentation for the dst_port field in struct bpf_sock is inaccurate and confusing. From the BPF program PoV, the field is a zero-padded 16-bit integer in network byte order. The value appears to the BPF user as if laid out in memory as so: offsetof(struct bpf_sock, dst_port) + 0 + 8 +16 0x00 +24 0x00 32-, 16-, and 8-bit wide loads from the field are all allowed, but only if the offset into the field is 0. 32-bit wide loads from dst_port are especially confusing. The loaded value, after converting to host byte order with bpf_ntohl(dst_port), contains the port number in the upper 16-bits. Remove the confusion by splitting the field into two 16-bit fields. For backward compatibility, allow 32-bit wide loads from offsetof(struct bpf_sock, dst_port). While at it, allow loads 8-bit loads at offset [0] and [1] from dst_port. Reported-by: Menglong Dong Signed-off-by: Jakub Sitnicki Link: https://lore.kernel.org/r/20220130115518.213259-2-jakub@cloudflare.com Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin

bpf: Fix comment for helper bpf_current_task_under_cgroup()

2022-04-08T12:24:14+00:00

commit 58617014405ad5c9f94f464444f4972dabb71ca7 upstream. Fix the descriptions of the return values of helper bpf_current_task_under_cgroup(). Fixes: c6b5fb8690fa ("bpf: add documentation for eBPF helpers (42-50)") Signed-off-by: Hengqi Chen Signed-off-by: Daniel Borkmann Acked-by: Yonghong Song Link: https://lore.kernel.org/bpf/20220310155335.1278783-1-hengqi.chen@gmail.com Signed-off-by: Greg Kroah-Hartman