summaryrefslogtreecommitdiff
path: root/include/uapi
AgeCommit message (Collapse)AuthorFilesLines
2021-07-01Merge branch 'dev-5.10' into dev-5.10-inteldev-5.10.46-intelJae Hyun Yoo2-0/+4
This is the 5.10.46 stable release. Signed-off-by: Jae Hyun Yoo <jae.hyun.yoo@intel.com>
2021-06-24Merge tag 'v5.10.46' into dev-5.10Joel Stanley2-0/+4
This is the 5.10.46 stable release Signed-off-by: Joel Stanley <joel@jms.id.au>
2021-06-23icmp: don't send out ICMP messages with a source address of 0.0.0.0Toke Høiland-Jørgensen1-0/+3
[ Upstream commit 321827477360934dc040e9d3c626bf1de6c3ab3c ] When constructing ICMP response messages, the kernel will try to pick a suitable source address for the outgoing packet. However, if no IPv4 addresses are configured on the system at all, this will fail and we end up producing an ICMP message with a source address of 0.0.0.0. This can happen on a box routing IPv4 traffic via v6 nexthops, for instance. Since 0.0.0.0 is not generally routable on the internet, there's a good chance that such ICMP messages will never make it back to the sender of the original packet that the ICMP message was sent in response to. This, in turn, can create connectivity and PMTUd problems for senders. Fortunately, RFC7600 reserves a dummy address to be used as a source for ICMP messages (192.0.0.8/32), so let's teach the kernel to substitute that address as a last resort if the regular source address selection procedure fails. Below is a quick example reproducing this issue with network namespaces: ip netns add ns0 ip l add type veth peer netns ns0 ip l set dev veth0 up ip a add 10.0.0.1/24 dev veth0 ip a add fc00:dead:cafe:42::1/64 dev veth0 ip r add 10.1.0.0/24 via inet6 fc00:dead:cafe:42::2 ip -n ns0 l set dev veth0 up ip -n ns0 a add fc00:dead:cafe:42::2/64 dev veth0 ip -n ns0 r add 10.0.0.0/24 via inet6 fc00:dead:cafe:42::1 ip netns exec ns0 sysctl -w net.ipv4.icmp_ratelimit=0 ip netns exec ns0 sysctl -w net.ipv4.ip_forward=1 tcpdump -tpni veth0 -c 2 icmp & ping -w 1 10.1.0.1 > /dev/null tcpdump: verbose output suppressed, use -v[v]... for full protocol decode listening on veth0, link-type EN10MB (Ethernet), snapshot length 262144 bytes IP 10.0.0.1 > 10.1.0.1: ICMP echo request, id 29, seq 1, length 64 IP 0.0.0.0 > 10.0.0.1: ICMP net 10.1.0.1 unreachable, length 92 2 packets captured 2 packets received by filter 0 packets dropped by kernel With this patch the above capture changes to: IP 10.0.0.1 > 10.1.0.1: ICMP echo request, id 31127, seq 1, length 64 IP 192.0.0.8 > 10.0.0.1: ICMP net 10.1.0.1 unreachable, length 92 Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Reported-by: Juliusz Chroboczek <jch@irif.fr> Reviewed-by: David Ahern <dsahern@kernel.org> Signed-off-by: Toke Høiland-Jørgensen <toke@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-06-18HID: hid-input: add mapping for emoji picker keyDmitry Torokhov1-0/+1
[ Upstream commit 7b229b13d78d112e2c5d4a60a3c6f602289959fa ] HUTRR101 added a new usage code for a key that is supposed to invoke and dismiss an emoji picker widget to assist users to locate and enter emojis. This patch adds a new key definition KEY_EMOJI_PICKER and maps 0x0c/0x0d9 usage code to this new keycode. Additionally hid-debug is adjusted to recognize this new usage code as well. Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-05-26Merge branch 'dev-5.10' into dev-5.10-intelJae Hyun Yoo7-6/+113
This is the 5.10.39 stable release Signed-off-by: Jae Hyun Yoo <jae.hyun.yoo@intel.com>
2021-05-24Merge tag 'v5.10.39' into dev-5.10Joel Stanley4-2/+107
This is the 5.10.39 stable release Signed-off-by: Joel Stanley <joel@jms.id.au>
2021-05-19netfilter: xt_SECMARK: add new revision to fix structure layoutPablo Neira Ayuso1-0/+6
[ Upstream commit c7d13358b6a2f49f81a34aa323a2d0878a0532a2 ] This extension breaks when trying to delete rules, add a new revision to fix this. Fixes: 5e6874cdb8de ("[SECMARK]: Add xtables SECMARK target") Signed-off-by: Phil Sutter <phil@nwl.cc> Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-05-19f2fs: move ioctl interface definitions to separated fileChao Yu1-0/+87
[ Upstream commit fa4320cefb8537a70cc28c55d311a1f569697cd3 ] Like other filesystem does, we introduce a new file f2fs.h in path of include/uapi/linux/, and move f2fs-specified ioctl interface definitions to that file, after then, in order to use those definitions, userspace developer only need to include the new header file rather than copy & paste definitions from fs/f2fs/f2fs.h. Signed-off-by: Chao Yu <yuchao0@huawei.com> Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-05-14net/packet: make packet_fanout.arr size configurable up to 64KTanner Love1-0/+12
[ Upstream commit 9c661b0b85444e426d3f23250305eeb16f6ffe88 ] One use case of PACKET_FANOUT is lockless reception with one socket per CPU. 256 is a practical limit on increasingly many machines. Increase PACKET_FANOUT_MAX to 64K. Expand setsockopt PACKET_FANOUT to take an extra argument max_num_members. Also explicitly define a fanout_args struct, instead of implicitly casting to an integer. This documents the API and simplifies the control flow. If max_num_members is not specified or is set to 0, then 256 is used, same as before. Signed-off-by: Tanner Love <tannerlove@google.com> Signed-off-by: Willem de Bruijn <willemb@google.com> Reviewed-by: Eric Dumazet <edumazet@google.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-05-14tty: actually undefine superseded ASYNC flagsJohan Hovold1-2/+2
[ Upstream commit d09845e98a05850a8094ea8fd6dd09a8e6824fff ] Some kernel-internal ASYNC flags have been superseded by tty-port flags and should no longer be used by kernel drivers. Fix the misspelled "__KERNEL__" compile guards which failed their sole purpose to break out-of-tree drivers that have not yet been updated. Fixes: 5c0517fefc92 ("tty: core: Undefine ASYNC_* flags superceded by TTY_PORT* flags") Signed-off-by: Johan Hovold <johan@kernel.org> Link: https://lore.kernel.org/r/20210407095208.31838-2-johan@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-05-12Merge tag 'v5.10.36' into dev-5.10Joel Stanley3-4/+6
This is the 5.10.36 stable release Signed-off-by: Joel Stanley <joel@jms.id.au>
2021-05-11usb: webcam: Invalid size of Processing Unit DescriptorPawel Laszczak1-1/+2
[ Upstream commit 6a154ec9ef6762c774cd2b50215c7a8f0f08a862 ] According with USB Device Class Definition for Video Device the Processing Unit Descriptor bLength should be 12 (10 + bmControlSize), but it has 11. Invalid length caused that Processing Unit Descriptor Test Video form CV tool failed. To fix this issue patch adds bmVideoStandards into uvc_processing_unit_descriptor structure. The bmVideoStandards field was added in UVC 1.1 and it wasn't part of UVC 1.0a. Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Pawel Laszczak <pawell@cadence.com> Reviewed-by: Peter Chen <peter.chen@kernel.org> Link: https://lore.kernel.org/r/20210315071748.29706-1-pawell@gli-login.cadence.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-05-08fixup! hwmon: Add PECI cputemp driverJae Hyun Yoo1-1/+1
This commit refines the driver to use the PCS 9 reading for generic module readings. Signed-off-by: Jae Hyun Yoo <jae.hyun.yoo@intel.com> Change-Id: Idbf155c6b2dbd6f44d7e6bbe53a2b98bdf45e8f2
2021-05-07capabilities: require CAP_SETFCAP to map uid 0Serge E. Hallyn1-1/+2
[ Upstream commit db2e718a47984b9d71ed890eb2ea36ecf150de18 ] cap_setfcap is required to create file capabilities. Since commit 8db6c34f1dbc ("Introduce v3 namespaced file capabilities"), a process running as uid 0 but without cap_setfcap is able to work around this as follows: unshare a new user namespace which maps parent uid 0 into the child namespace. While this task will not have new capabilities against the parent namespace, there is a loophole due to the way namespaced file capabilities are represented as xattrs. File capabilities valid in userns 1 are distinguished from file capabilities valid in userns 2 by the kuid which underlies uid 0. Therefore the restricted root process can unshare a new self-mapping namespace, add a namespaced file capability onto a file, then use that file capability in the parent namespace. To prevent that, do not allow mapping parent uid 0 if the process which opened the uid_map file does not have CAP_SETFCAP, which is the capability for setting file capabilities. As a further wrinkle: a task can unshare its user namespace, then open its uid_map file itself, and map (only) its own uid. In this case we do not have the credential from before unshare, which was potentially more restricted. So, when creating a user namespace, we record whether the creator had CAP_SETFCAP. Then we can use that during map_write(). With this patch: 1. Unprivileged user can still unshare -Ur ubuntu@caps:~$ unshare -Ur root@caps:~# logout 2. Root user can still unshare -Ur ubuntu@caps:~$ sudo bash root@caps:/home/ubuntu# unshare -Ur root@caps:/home/ubuntu# logout 3. Root user without CAP_SETFCAP cannot unshare -Ur: root@caps:/home/ubuntu# /sbin/capsh --drop=cap_setfcap -- root@caps:/home/ubuntu# /sbin/setcap cap_setfcap=p /sbin/setcap unable to set CAP_SETFCAP effective capability: Operation not permitted root@caps:/home/ubuntu# unshare -Ur unshare: write failed /proc/self/uid_map: Operation not permitted Note: an alternative solution would be to allow uid 0 mappings by processes without CAP_SETFCAP, but to prevent such a namespace from writing any file capabilities. This approach can be seen at [1]. Background history: commit 95ebabde382 ("capabilities: Don't allow writing ambiguous v3 file capabilities") tried to fix the issue by preventing v3 fscaps to be written to disk when the root uid would map to the same uid in nested user namespaces. This led to regressions for various workloads. For example, see [2]. Ultimately this is a valid use-case we have to support meaning we had to revert this change in 3b0c2d3eaa83 ("Revert 95ebabde382c ("capabilities: Don't allow writing ambiguous v3 file capabilities")"). Link: https://git.kernel.org/pub/scm/linux/kernel/git/sergeh/linux.git/log/?h=2021-04-15/setfcap-nsfscaps-v4 [1] Link: https://github.com/containers/buildah/issues/3071 [2] Signed-off-by: Serge Hallyn <serge@hallyn.com> Reviewed-by: Andrew G. Morgan <morgan@kernel.org> Tested-by: Christian Brauner <christian.brauner@ubuntu.com> Reviewed-by: Christian Brauner <christian.brauner@ubuntu.com> Tested-by: Giuseppe Scrivano <gscrivan@redhat.com> Cc: Eric Biederman <ebiederm@xmission.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-04-21dmaengine: idxd: fix delta_rec and crc size field for completion recordDave Jiang1-2/+2
[ Upstream commit 4ac823e9cd85f66da274c951d21bf9f6b714b729 ] The delta_rec_size and crc_val in the completion record should be 32bits and not 16bits. Fixes: bfe1d56091c1 ("dmaengine: idxd: Init and probe for Intel data accelerators") Reported-by: Nikhil Rao <nikhil.rao@intel.com> Signed-off-by: Dave Jiang <dave.jiang@intel.com> Link: https://lore.kernel.org/r/161645618572.2003490.14466173451736323035.stgit@djiang5-desk3.ch.intel.com Signed-off-by: Vinod Koul <vkoul@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-04-13Merge branch 'dev-5.10' into dev-5.10-intelJae Hyun Yoo3-5/+3
Signed-off-by: Jae Hyun Yoo <jae.hyun.yoo@intel.com>
2021-04-12mailbox: ioctl to fetch mailbox sizeArun P. Mohanan1-0/+11
The size of mailbox differ from AST2500, AST2600 A0 and A1. Add an ioctl support to fetch the mailbox size. Tested: Verfied ioctl call returns mailbox size as expected. Change-Id: I4e261aaf8aa3fb108d6ad152d30a17b114d70ccd Signed-off-by: Arun P. Mohanan <arun.p.m@linux.intel.com>
2021-04-06Merge tag 'v5.10.27' into dev-5.10Joel Stanley3-5/+3
This is the 5.10.27 stable release
2021-03-30psample: Fix user API breakageIdo Schimmel1-4/+1
commit e43accba9b071dcd106b5e7643b1b106a158cbb1 upstream. Cited commit added a new attribute before the existing group reference count attribute, thereby changing its value and breaking existing applications on new kernels. Before: # psample -l libpsample ERROR psample_group_foreach: failed to recv message: Operation not supported After: # psample -l Group Num Refcount Group Seq 1 1 0 Fix by restoring the value of the old attribute and remove the misleading comments from the enumerator to avoid future bugs. Cc: stable@vger.kernel.org Fixes: d8bed686ab96 ("net: psample: Add tunnel support") Signed-off-by: Ido Schimmel <idosch@nvidia.com> Reported-by: Adiel Bidani <adielb@nvidia.com> Reviewed-by: Jiri Pirko <jiri@nvidia.com> Reviewed-by: Petr Machata <petrm@nvidia.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-03-17net: l2tp: reduce log level of messages in receive path, add counter insteadMatthias Schiffer1-0/+1
commit 3e59e8856758eb5a2dfe1f831ef53b168fd58105 upstream. Commit 5ee759cda51b ("l2tp: use standard API for warning log messages") changed a number of warnings about invalid packets in the receive path so that they are always shown, instead of only when a special L2TP debug flag is set. Even with rate limiting these warnings can easily cause significant log spam - potentially triggered by a malicious party sending invalid packets on purpose. In addition these warnings were noticed by projects like Tunneldigger [1], which uses L2TP for its data path, but implements its own control protocol (which is sufficiently different from L2TP data packets that it would always be passed up to userspace even with future extensions of L2TP). Some of the warnings were already redundant, as l2tp_stats has a counter for these packets. This commit adds one additional counter for invalid packets that are passed up to userspace. Packets with unknown session are not counted as invalid, as there is nothing wrong with the format of these packets. With the additional counter, all of these messages are either redundant or benign, so we reduce them to pr_debug_ratelimited(). [1] https://github.com/wlanslovenija/tunneldigger/issues/160 Fixes: 5ee759cda51b ("l2tp: use standard API for warning log messages") Signed-off-by: Matthias Schiffer <mschiffer@universe-factory.net> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-03-17uapi: nfnetlink_cthelper.h: fix userspace compilation errorDmitry V. Levin1-1/+1
commit c33cb0020ee6dd96cc9976d6085a7d8422f6dbed upstream. Apparently, <linux/netfilter/nfnetlink_cthelper.h> and <linux/netfilter/nfnetlink_acct.h> could not be included into the same compilation unit because of a cut-and-paste typo in the former header. Fixes: 12f7a505331e6 ("netfilter: add user-space connection tracking helper infrastructure") Cc: <stable@vger.kernel.org> # v3.6 Signed-off-by: Dmitry V. Levin <ldv@altlinux.org> Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-03-15Merge branch 'dev-5.10' into dev-5.10-intelJae Hyun Yoo2-2/+4
Signed-off-by: Jae Hyun Yoo <jae.hyun.yoo@intel.com>
2021-03-15Move JTAG state matrix to JTAG core header fileCastro, Omar Eduardo1-0/+131
- Move TDI state matrix to core header file - These changes are done based on feedback from Paul Fertser, from the OpenOCD. Test: SPR ASD Sanity and jtag_test finished successfully. ICX ASD Sanity and jtag_test finished successfully. Change-Id: Idb612e50d5a8ea5929f7c9241d279c345587983a Signed-off-by: Castro, Omar Eduardo <omar.eduardo.castro@intel.com>
2021-03-12Merge tag 'v5.10.23' into dev-5.10Joel Stanley1-0/+2
This is the 5.10.23 stable release Signed-off-by: Joel Stanley <joel@jms.id.au>
2021-03-11ASD Prevent TDI remaining bits to be override during JTAG xferErnesto Corona1-0/+3
JTAG xfer length is measured in bits and it is allowed to send non 8-bit aligned xfers. For such xfers we will read the content of the remaining bits in the last byte of tdi buffer and restore those bits along with the xfer readback. Add also linux types to JTAG header to remove external dependencies. Test: SPR ASD Sanity and jtag_test finished successfully. SKX ASD Sanity and jtag_test finished successfully. Signed-off-by: Ernesto Corona <ernesto.corona@intel.com>
2021-03-11aspeed-mctp: Add EID information related ioctlsKarol Wachowski1-0/+29
Implement two new ioctls for storing EID related information: * ASPEED_MCTP_IOCTL_GET_EID_INFO * ASPEED_MCTP_IOCTL_SET_EID_INFO Driver stores EID mapping in a list which is traversed when one tries to get information using ASPEED_MCTP_IOCTL_GET_EID_INFO ioctl, when given EID mapping is not found in the list, next entry is returned. When there are no entries with EIDs higher than specified in the IOCTL call -ENODEV is returned. Whenever new information about EID mapping is stored with ASPEED_MCTP_IOCTL_SET_EID_INFO ioctl driver empties exsiting list of mappings and creates new one based on user input. After insertion list is sorted by EID. Invalid input such as duplicated EIDs will cause driver to return -EINVAL. Signed-off-by: Karol Wachowski <karol.wachowski@intel.com>
2021-03-11soc: aspeed: mctp: Add API to register client for MCTP typeAndrzej Kacprowski1-0/+16
MCTP client can register for receiving packets with selected MCTP message type or PCIE vendor defined message type. Vendor defined type is 2 bytes but in Intel VDMs the first byte is variable and only the second byte contains constant message type - to support this use case we have to specify 2 byte mask that is applied to packet type before comparing with registered vendor type. When MCTP packet arrives its header is compared with a list of registered (vendor) types. If no client registered for packet's (vendor) type then the packet is dispatched to the default client. Fragmented packets are not considered for type matching. Only one client can register for given (vendor) type. Client can register for multiple (vendor) types. All packet fields must be specified in big endian byte order. This feature allows to support multiple clients simultaneously but only one client per (vendor) message type. For example we can have PECI client in kernel that uses PECI vendor message type, dcpmm daemon in user space that handles NVDIMM vendor type messages and mctpd service that handles MCTP control and PLDM message types. tested with peci_mctp_test application Signed-off-by: Andrzej Kacprowski <andrzej.kacprowski@linux.intel.com>
2021-03-11soc: aspeed: mctp: Add IOCTL to register default clientAndrzej Kacprowski1-0/+5
Add IOCTL to register given client as default client that receives all packets that were not dispatched to other clients. This IOCTL is intended to be used by mctpd service or test application that should receive all packets that are not claimed by other clients. mctpd service might not be the first user space client since dcpmm or telemetry client can start before mctpd or mctpd can crash and be restarted automatically at any time. To preserve backward compatibility with mctpd, the first user space client will be registered automatically as default client - once mctpd is modified to call ASPEED_MCTP_IOCTL_REGISTER_DEFAULT_HANDLER we can remove this workaround. Signed-off-by: Andrzej Kacprowski <andrzej.kacprowski@linux.intel.com>
2021-03-11hwmon: peci: PCS utilsZbigniew Lukwinski1-1/+4
1. Helpers for reading/writing PCS registers added. 2. PECI sensor configuration structure definition and helpers added. 3. New PECI PCS index and parameters definitions added. Tested: * on WilsonCity platform * hwmon/peci modules work as before the change Signed-off-by: Zbigniew Lukwinski <zbigniew.lukwinski@linux.intel.com>
2021-03-11soc: aspeed: mctp: Add initial driver for ast2600-mctpIwona Winiarska1-0/+67
Currently, there is no proper MCTP networking subsystem in Linux. Until we are able to work out the details of that, we are going to expose HW to userspace using raw read/write interface. Because of that, this driver is not intended to be submitted upstream. Here we are providing a simple device driver for AST2600 MCTP controller. v2: Added workarounds for BMC reboot/reset, corrected endianess comment, changed TX_BUF_ADDR to be consistent, fixed typos. v3: Added workaround for RX hang, added swapping PCIe VDM header to network order, corrected buffer allocation size. v4: Fixed TX broken after sending 32 byte packet Signed-off-by: Iwona Winiarska <iwona.winiarska@intel.com> Signed-off-by: Andrzej Kacprowski <andrzej.kacprowski@linux.intel.com>
2021-03-11enable AST2600 I3CJae Hyun Yoo1-0/+38
This commit ports I3C related changes from Aspeed SDK v00.05.05. It also includes Vitor's I3C cdev implementation which isn't upstreamed yet so it should be refined later. Signed-off-by: Ryan Chen <ryan_chen@aspeedtech.com> Signed-off-by: Vitor Soares <soares@synopsys.com> Signed-off-by: Jae Hyun Yoo <jae.hyun.yoo@intel.com>
2021-03-11drivers: jtag: Add JTAG core driverErnesto Corona1-0/+235
JTAG class driver provide infrastructure to support hardware/software JTAG platform drivers. It provide user layer API interface for flashing and debugging external devices which equipped with JTAG interface using standard transactions. Driver exposes set of IOCTL to user space for: - XFER: SIR (Scan Instruction Register, IEEE 1149.1 Data Register scan); SDR (Scan Data Register, IEEE 1149.1 Instruction Register scan); - GIOCSTATUS read the current TAPC state of the JTAG controller - SIOCSTATE Forces the JTAG TAPC to go into a particular state. - SIOCFREQ/GIOCFREQ for setting and reading JTAG frequency. - IOCBITBANG for low level control of JTAG signals. Driver core provides set of internal APIs for allocation and registration: - jtag_register; - jtag_unregister; - jtag_alloc; - jtag_free; Platform driver on registration with jtag-core creates the next entry in dev folder: /dev/jtagX Signed-off-by: Oleksandr Shamray <oleksandrs@mellanox.com> Signed-off-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: Ernesto Corona <ernesto.corona@intel.com> Acked-by: Philippe Ombredanne <pombredanne@nexb.com> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Arnd Bergmann <arnd@arndb.de> Cc: Boris Brezillon <bbrezillon@kernel.org> Cc: Randy Dunlap <rdunlap@infradead.org> Cc: Johan Hovold <johan@kernel.org> Cc: Jens Axboe <axboe@kernel.dk> Cc: Joel Stanley <joel@jms.id.au> Cc: Palmer Dabbelt <palmer@sifive.com> Cc: Kees Cook <keescook@chromium.org> Cc: William Breathitt Gray <vilhelm.gray@gmail.com> Cc: Federico Vaga <federico.vaga@cern.ch> Cc: Jonathan Cameron <Jonathan.Cameron@huawei.com> Cc: Tony Luck <tony.luck@intel.com> Cc: Christian Gromm <christian.gromm@microchip.com> Cc: Linus Walleij <linus.walleij@linaro.org> Cc: Yiwei Zhang <zzyiwei@google.com> Cc: Alessandro Rubini <rubini@gnudd.com> Cc: Viresh Kumar <viresh.kumar@linaro.org> Cc: Mika Westerberg <mika.westerberg@linux.intel.com> Cc: Steven Filary <steven.a.filary@intel.com> Cc: Vadim Pasternak <vadimp@mellanox.com> Cc: Amithash Prasad <amithash@fb.com> Cc: Patrick Williams <patrickw3@fb.com> Cc: Rgrs <rgrs@protonmail.com>
2021-03-11i2c: Add mux hold/unhold msg typesJae Hyun Yoo1-0/+1
This commit adds mux hold/unhold message types to support extended mux control for IPMB and MCTP devices. A hold or an unhold message can be added at the end of I2C message stream wrapped by repeated-start, also can be used as a single message independantly. This mux hold/unhold message will be delivered throughout all mux levels in the path. Means that if it goes to multi-level mux path, all muxes will be held/unheld by this message. 1. Hold message struct i2c_msg msg; uint16_t timeout = 5000; // timeout in ms. 5 secs in this example. msg.addr = 0x0; // any value can be used. addr will be ignored in this packet. msg.flags = I2C_M_HOLD; // set this flag to indicate it's a hold message. msg.len = sizeof(uint16_t); // timeout value will be delivered using two bytes buffer. msg.buf = (uint8_t *)&timeout; // set timeout value. 2. Unhold message struct i2c_msg msg; uint16_t timeout = 0; // set 0 for an unhold message. msg.addr = 0x0; // any value can be used. addr will be ignored in this packet. msg.flags = I2C_M_HOLD; // set this flag to indicate it's an unhold message. msg.len = sizeof(uint16_t); // timeout value will be delivered using two bytes buffer. msg.buf = (uint8_t *)&timeout; // set timeout value. This unhold message can be delivered to a mux adapter even when a bus is locked so that any holding state can be unheld immediately by invoking this unhold message. This patch would not be welcomed from upstream so it should be kept in downstream only. Signed-off-by: Jae Hyun Yoo <jae.hyun.yoo@intel.com>
2021-03-11Add AST2500 JTAG driverCorona, Ernesto1-0/+73
Update AST2500 JTAG driver. Remove Legacy driver but keep headers. Signed-off-by: Corona, Ernesto <ernesto.corona@intel.com>
2021-03-11Aspeed LPC SIO driverYong Li1-0/+45
Add lpc sio device driver for AST2500/2400 Signed-off-by: Yong Li <yong.b.li@intel.com> Signed-off-by: Jae Hyun Yoo <jae.hyun.yoo@intel.com>
2021-03-11Add peci-cpupower driverZhikuiRen1-0/+1
peci-cpupower reads CPU energy counter through peci and computes average power in mW since last read. Signed-off-by: ZhikuiRen <zhikui.ren@intel.com>
2021-03-11peci: Add support for PECI bus driver coreJae Hyun Yoo1-0/+661
This commit adds driver implementation for PECI bus core into linux driver framework. PECI (Platform Environment Control Interface) is a one-wire bus interface that provides a communication channel from Intel processors and chipset components to external monitoring or control devices. PECI is designed to support the following sideband functions: * Processor and DRAM thermal management - Processor fan speed control is managed by comparing Digital Thermal Sensor (DTS) thermal readings acquired via PECI against the processor-specific fan speed control reference point, or TCONTROL. Both TCONTROL and DTS thermal readings are accessible via the processor PECI client. These variables are referenced to a common temperature, the TCC activation point, and are both defined as negative offsets from that reference. - PECI based access to the processor package configuration space provides a means for Baseboard Management Controllers (BMC) or other platform management devices to actively manage the processor and memory power and thermal features. * Platform Manageability - Platform manageability functions including thermal, power, and error monitoring. Note that platform 'power' management includes monitoring and control for both the processor and DRAM subsystem to assist with data center power limiting. - PECI allows read access to certain error registers in the processor MSR space and status monitoring registers in the PCI configuration space within the processor and downstream devices. - PECI permits writes to certain registers in the processor PCI configuration space. * Processor Interface Tuning and Diagnostics - Processor interface tuning and diagnostics capabilities (Intel Interconnect BIST). The processors Intel Interconnect Built In Self Test (Intel IBIST) allows for infield diagnostic capabilities in the Intel UPI and memory controller interfaces. PECI provides a port to execute these diagnostics via its PCI Configuration read and write capabilities. * Failure Analysis - Output the state of the processor after a failure for analysis via Crashdump. PECI uses a single wire for self-clocking and data transfer. The bus requires no additional control lines. The physical layer is a self-clocked one-wire bus that begins each bit with a driven, rising edge from an idle level near zero volts. The duration of the signal driven high depends on whether the bit value is a logic '0' or logic '1'. PECI also includes variable data transfer rate established with every message. In this way, it is highly flexible even though underlying logic is simple. The interface design was optimized for interfacing between an Intel processor and chipset components in both single processor and multiple processor environments. The single wire interface provides low board routing overhead for the multiple load connections in the congested routing area near the processor and chipset components. Bus speed, error checking, and low protocol overhead provides adequate link bandwidth and reliability to transfer critical device operating conditions and configuration information. This implementation provides the basic framework to add PECI extensions to the Linux bus and device models. A hardware specific 'Adapter' driver can be attached to the PECI bus to provide sideband functions described above. It is also possible to access all devices on an adapter from userspace through the /dev interface. A device specific 'Client' driver also can be attached to the PECI bus so each processor client's features can be supported by the 'Client' driver through an adapter connection in the bus. Signed-off-by: Jason M Biils <jason.m.bills@linux.intel.com> Signed-off-by: Yunge Zhu <yunge.zhu@linux.intel.com> Signed-off-by: Fengguang Wu <fengguang.wu@intel.com> Signed-off-by: Jae Hyun Yoo <jae.hyun.yoo@linux.intel.com> Reviewed-by: Haiyue Wang <haiyue.wang@linux.intel.com> Reviewed-by: James Feist <james.feist@linux.intel.com> Reviewed-by: Vernon Mauery <vernon.mauery@linux.intel.com>
2021-03-07net/sched: cls_flower: Reject invalid ct_state flags ruleswenxu1-0/+2
commit 1bcc51ac0731aab1b109b2cd5c3d495f1884e5ca upstream. Reject the unsupported and invalid ct_state flags of cls flower rules. Fixes: e0ace68af2ac ("net/sched: cls_flower: Add matching on conntrack info") Signed-off-by: wenxu <wenxu@ucloud.cn> Reviewed-by: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com> Reviewed-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-03-04Merge tag 'v5.10.20' into dev-5.10Joel Stanley1-2/+2
This is the 5.10.20 stable release Signed-off-by: Joel Stanley <joel@jms.id.au>
2021-03-04drm/fourcc: fix Amlogic format modifier masksSimon Ser1-2/+2
[ Upstream commit cc3283f8f41f741fbaef63d0503d8fb4a7919100 ] The comment says the layout and options use 8 bits, and the shift uses 8 bits. However the mask is 0xf, ie. 0b00001111 (4 bits). This could be surprising when introducing new layouts or options that take more than 4 bits, as this would silently drop the high bits. Make the masks consistent with the comment and the shift. Found when writing a drm_info patch [1]. [1]: https://github.com/ascent12/drm_info/pull/67 Signed-off-by: Simon Ser <contact@emersion.fr> Fixes: d6528ec88309 ("drm/fourcc: Add modifier definitions for describing Amlogic Video Framebuffer Compression") Cc: Neil Armstrong <narmstrong@baylibre.com> Cc: Sam Ravnborg <sam@ravnborg.org> Cc: Kevin Hilman <khilman@baylibre.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Acked-by: Neil Armstrong <narmstrong@baylibre.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210110125103.15447-1-contact@emersion.fr Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-02-09soc: aspeed: xdma: Add reset ioctlEddie James1-0/+4
Users of the XDMA engine need a way to reset it if something goes wrong. Problems on the host side, or user error, such as incorrect host address, may result in the DMA operation never completing and no way to determine what went wrong. Therefore, add an ioctl to reset the engine so that users can recover in this situation. Signed-off-by: Eddie James <eajames@linux.ibm.com> Acked-by: Andrew Jeffery <andrew@aj.id.au> Reviewed-by: Joel Stanley <joel@jms.id.au> Link: https://lore.kernel.org/r/1588697905-23444-5-git-send-email-eajames@linux.ibm.com Signed-off-by: Joel Stanley <joel@jms.id.au>
2021-02-09soc: aspeed: Add XDMA Engine DriverEddie James1-0/+38
The XDMA engine embedded in the AST2500 and AST2600 SOCs performs PCI DMA operations between the SOC (acting as a BMC) and a host processor in a server. This commit adds a driver to control the XDMA engine and adds functions to initialize the hardware and memory and start DMA operations. Signed-off-by: Eddie James <eajames@linux.ibm.com> Reviewed-by: Andrew Jeffery <andrew@aj.id.au> Reviewed-by: Joel Stanley <joel@jms.id.au> Link: https://lore.kernel.org/r/1588697905-23444-3-git-send-email-eajames@linux.ibm.com Signed-off-by: Joel Stanley <joel@jms.id.au>
2021-02-04uapi: fix big endian definition of ipv6_rpl_sr_hdrJustin Iurman1-3/+3
commit 07d46d93c9acdfe0614071d73c415dd5f745cc6e upstream. Following RFC 6554 [1], the current order of fields is wrong for big endian definition. Indeed, here is how the header looks like: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Header | Hdr Ext Len | Routing Type | Segments Left | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CmprI | CmprE | Pad | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ This patch reorders fields so that big endian definition is now correct. [1] https://tools.ietf.org/html/rfc6554#section-3 Fixes: cfa933d938d8 ("include: uapi: linux: add rpl sr header definition") Signed-off-by: Justin Iurman <justin.iurman@uliege.be> Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-01-30RDMA/vmw_pvrdma: Fix network_hdr_type reported in WCBryan Tan1-0/+7
commit 9f206f7398f6f6ec7dd0198c045c2459b4f720b6 upstream. The PVRDMA device HW interface defines network_hdr_type according to an old definition of the internal kernel rdma_network_type enum that has since changed, resulting in the wrong rdma_network_type being reported. Fix this by explicitly defining the enum used by the PVRDMA device and adding a function to convert the pvrdma_network_type to rdma_network_type enum. Cc: stable@vger.kernel.org # 5.10+ Fixes: 1c15b4f2a42f ("RDMA/core: Modify enum ib_gid_type and enum rdma_network_type") Link: https://lore.kernel.org/r/1611026189-17943-1-git-send-email-bryantan@vmware.com Reviewed-by: Adit Ranadive <aditr@vmware.com> Signed-off-by: Bryan Tan <bryantan@vmware.com> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-01-30media: v4l2-subdev.h: BIT() is not available in userspaceHans Verkuil1-1/+1
commit a53e3c189cc6460b60e152af3fc24edf8e0ea9d2 upstream. The BIT macro is not available in userspace, so replace BIT(0) by 0x00000001. Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Fixes: 6446ec6cbf46 ("media: v4l2-subdev: add VIDIOC_SUBDEV_QUERYCAP ioctl") Cc: <stable@vger.kernel.org> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-01-12bcache: introduce BCH_FEATURE_INCOMPAT_LOG_LARGE_BUCKET_SIZE for large bucketColy Li1-1/+1
commit b16671e8f493e3df40b1fb0dff4078f391c5099a upstream. When large bucket feature was added, BCH_FEATURE_INCOMPAT_LARGE_BUCKET was introduced into the incompat feature set. It used bucket_size_hi (which was added at the tail of struct cache_sb_disk) to extend current 16bit bucket size to 32bit with existing bucket_size in struct cache_sb_disk. This is not a good idea, there are two obvious problems, - Bucket size is always value power of 2, if store log2(bucket size) in existing bucket_size of struct cache_sb_disk, it is unnecessary to add bucket_size_hi. - Macro csum_set() assumes d[SB_JOURNAL_BUCKETS] is the last member in struct cache_sb_disk, bucket_size_hi was added after d[] which makes csum_set calculate an unexpected super block checksum. To fix the above problems, this patch introduces a new incompat feature bit BCH_FEATURE_INCOMPAT_LOG_LARGE_BUCKET_SIZE, when this bit is set, it means bucket_size in struct cache_sb_disk stores the order of power-of-2 bucket size value. When user specifies a bucket size larger than 32768 sectors, BCH_FEATURE_INCOMPAT_LOG_LARGE_BUCKET_SIZE will be set to incompat feature set, and bucket_size stores log2(bucket size) more than store the real bucket size value. The obsoleted BCH_FEATURE_INCOMPAT_LARGE_BUCKET won't be used anymore, it is renamed to BCH_FEATURE_INCOMPAT_OBSO_LARGE_BUCKET and still only recognized by kernel driver for legacy compatible purpose. The previous bucket_size_hi is renmaed to obso_bucket_size_hi in struct cache_sb_disk and not used in bcache-tools anymore. For cache device created with BCH_FEATURE_INCOMPAT_LARGE_BUCKET feature, bcache-tools and kernel driver still recognize the feature string and display it as "obso_large_bucket". With this change, the unnecessary extra space extend of bcache on-disk super block can be avoided, and csum_set() may generate expected check sum as well. Fixes: ffa470327572 ("bcache: add bucket_size_hi into struct cache_sb_disk for large bucket") Signed-off-by: Coly Li <colyli@suse.de> Cc: stable@vger.kernel.org # 5.9+ Signed-off-by: Jens Axboe <axboe@kernel.dk> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-01-06uapi: move constants from <linux/kernel.h> to <linux/const.h>Petr Vorel8-14/+12
commit a85cbe6159ffc973e5702f70a3bd5185f8f3c38d upstream. and include <linux/const.h> in UAPI headers instead of <linux/kernel.h>. The reason is to avoid indirect <linux/sysinfo.h> include when using some network headers: <linux/netlink.h> or others -> <linux/kernel.h> -> <linux/sysinfo.h>. This indirect include causes on MUSL redefinition of struct sysinfo when included both <sys/sysinfo.h> and some of UAPI headers: In file included from x86_64-buildroot-linux-musl/sysroot/usr/include/linux/kernel.h:5, from x86_64-buildroot-linux-musl/sysroot/usr/include/linux/netlink.h:5, from ../include/tst_netlink.h:14, from tst_crypto.c:13: x86_64-buildroot-linux-musl/sysroot/usr/include/linux/sysinfo.h:8:8: error: redefinition of `struct sysinfo' struct sysinfo { ^~~~~~~ In file included from ../include/tst_safe_macros.h:15, from ../include/tst_test.h:93, from tst_crypto.c:11: x86_64-buildroot-linux-musl/sysroot/usr/include/sys/sysinfo.h:10:8: note: originally defined here Link: https://lkml.kernel.org/r/20201015190013.8901-1-petr.vorel@gmail.com Signed-off-by: Petr Vorel <petr.vorel@gmail.com> Suggested-by: Rich Felker <dalias@aerifal.cx> Acked-by: Rich Felker <dalias@libc.org> Cc: Peter Korsgaard <peter@korsgaard.com> Cc: Baruch Siach <baruch@tkos.co.il> Cc: Florian Weimer <fweimer@redhat.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-12-30binder: add flag to clear buffer on txn completeTodd Kjos1-0/+1
commit 0f966cba95c78029f491b433ea95ff38f414a761 upstream. Add a per-transaction flag to indicate that the buffer must be cleared when the transaction is complete to prevent copies of sensitive data from being preserved in memory. Signed-off-by: Todd Kjos <tkjos@google.com> Link: https://lore.kernel.org/r/20201120233743.3617529-1-tkjos@google.com Cc: stable <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-12-30devlink: use _BITUL() macro instead of BIT() in the UAPI headerTobias Klauser1-1/+1
[ Upstream commit 75f4d4544db9fa34e1f04174f27d9f8a387be37d ] The BIT() macro is not available for the UAPI headers. Moreover, it can be defined differently in user space headers. Thus, replace its usage with the _BITUL() macro which is already used in other macro definitions in <linux/devlink.h>. Fixes: dc64cc7c6310 ("devlink: Add devlink reload limit option") Signed-off-by: Tobias Klauser <tklauser@distanz.ch> Link: https://lore.kernel.org/r/20201215102531.16958-1-tklauser@distanz.ch Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-12-26crypto: af_alg - avoid undefined behavior accessing salg_nameEric Biggers1-0/+16
commit 92eb6c3060ebe3adf381fd9899451c5b047bb14d upstream. Commit 3f69cc60768b ("crypto: af_alg - Allow arbitrarily long algorithm names") made the kernel start accepting arbitrarily long algorithm names in sockaddr_alg. However, the actual length of the salg_name field stayed at the original 64 bytes. This is broken because the kernel can access indices >= 64 in salg_name, which is undefined behavior -- even though the memory that is accessed is still located within the sockaddr structure. It would only be defined behavior if the array were properly marked as arbitrary-length (either by making it a flexible array, which is the recommended way these days, or by making it an array of length 0 or 1). We can't simply change salg_name into a flexible array, since that would break source compatibility with userspace programs that embed sockaddr_alg into another struct, or (more commonly) declare a sockaddr_alg like 'struct sockaddr_alg sa = { .salg_name = "foo" };'. One solution would be to change salg_name into a flexible array only when '#ifdef __KERNEL__'. However, that would keep userspace without an easy way to actually use the longer algorithm names. Instead, add a new structure 'sockaddr_alg_new' that has the flexible array field, and expose it to both userspace and the kernel. Make the kernel use it correctly in alg_bind(). This addresses the syzbot report "UBSAN: array-index-out-of-bounds in alg_bind" (https://syzkaller.appspot.com/bug?extid=92ead4eb8e26a26d465e). Reported-by: syzbot+92ead4eb8e26a26d465e@syzkaller.appspotmail.com Fixes: 3f69cc60768b ("crypto: af_alg - Allow arbitrarily long algorithm names") Cc: <stable@vger.kernel.org> # v4.12+ Signed-off-by: Eric Biggers <ebiggers@google.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
generated by cgit v1.2.3 (git 2.39.0) at 2026-10-13 09:24:58 +0300