aboutsummaryrefslogtreecommitdiffstats
AgeCommit message (Collapse)AuthorFilesLines
2022-09-20efi: libstub: fix type confusion for load_options_sizeArd Biesheuvel3-11/+12
Even though it is unlikely to ever make a difference, let's use u32 consistently for the size of the load_options provided by the firmware (aka the command line) While at it, do some general cleanup too: use efi_char16_t, avoid using options_chars in places where it really means options_size, etc. Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
2022-09-20gfs2: Check sb_bsize_shift after reading superblockAndrew Price1-1/+4
Fuzzers like to scribble over sb_bsize_shift but in reality it's very unlikely that this field would be corrupted on its own. Nevertheless it should be checked to avoid the possibility of messy mount errors due to bad calculations. It's always a fixed value based on the block size so we can just check that it's the expected value. Tested with: mkfs.gfs2 -O -p lock_nolock /dev/vdb for i in 0 -1 64 65 32 33; do gfs2_edit -p sb field sb_bsize_shift $i /dev/vdb mount /dev/vdb /mnt/test && umount /mnt/test done Before this patch we get a withdraw after [ 76.413681] gfs2: fsid=loop0.0: fatal: invalid metadata block [ 76.413681] bh = 19 (type: exp=5, found=4) [ 76.413681] function = gfs2_meta_buffer, file = fs/gfs2/meta_io.c, line = 492 and with UBSAN configured we also get complaints like [ 76.373395] UBSAN: shift-out-of-bounds in fs/gfs2/ops_fstype.c:295:19 [ 76.373815] shift exponent 4294967287 is too large for 64-bit type 'long unsigned int' After the patch, these complaints don't appear, mount fails immediately and we get an explanation in dmesg. Reported-by: syzbot+dcf33a7aae997956fe06@syzkaller.appspotmail.com Signed-off-by: Andrew Price <anprice@redhat.com> Signed-off-by: Andreas Gruenbacher <agruenba@redhat.com>
2022-09-20RDMA/srpt: Use flex array destination for memcpy()Hangyu Hua1-1/+1
In preparation for FORTIFY_SOURCE performing run-time destination buffer bounds checking for memcpy(), specify the destination output buffer explicitly, instead of asking memcpy() to write past the end of what looked like a fixed-size object. Notice that srp_rsp[] is a pointer to a structure that contains flexible-array member data[]: struct srp_rsp { ... __be32 sense_data_len; __be32 resp_data_len; u8 data[]; }; link: https://github.com/KSPP/linux/issues/201 Signed-off-by: Hangyu Hua <hbh25y@gmail.com> Link: https://lore.kernel.org/r/20220909022943.8896-1-hbh25y@gmail.com Reviewed-by: Bart Van Assche <bvanassche@acm.org> Reviewed-by: Gustavo A. R. Silva <gustavoars@kernel.org> Signed-off-by: Leon Romanovsky <leon@kernel.org>
2022-09-20Merge branch 'for-linus' into for-nextTakashi Iwai4-28/+25
2022-09-20Revert "ALSA: usb-audio: Clean up endpoint setups at PCM prepare"Takashi Iwai1-10/+30
This reverts commit 32eeeed963ad4f41b422b3e314d96ded7283b201. As the fix for endpoint configuration split is reverted at next, do another revert here for a clean patch application. Signed-off-by: Takashi Iwai <tiwai@suse.de>
2022-09-20Revert "ALSA: usb-audio: Split endpoint setups for hw_params and prepare"Takashi Iwai3-23/+20
This reverts commit ff878b408a03bef5d610b7e2302702e16a53636e. Unfortunately the recent fix seems bringing another regressions with PulseAudio / pipewire, at least for Steinberg and MOTU devices. As a temporary solution, do a straight revert. The issue for Android will be revisited again later by another different fix (if any). Fixes: ff878b408a03 ("ALSA: usb-audio: Split endpoint setups for hw_params and prepare") Cc: <stable@vger.kernel.org> BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=216500 Link: https://lore.kernel.org/r/20220920113929.25162-1-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
2022-09-20ALSA: es18xx: Remove the unneeded result variableye xingchen1-4/+1
Return the value inb() directly instead of storing it in another redundant variable. Reported-by: Zeal Robot <zealci@zte.com.cn> Signed-off-by: ye xingchen <ye.xingchen@zte.com.cn> Link: https://lore.kernel.org/r/20220920064605.215318-1-ye.xingchen@zte.com.cn Signed-off-by: Takashi Iwai <tiwai@suse.de>
2022-09-20RDMA/erdma: Make hardware internal opcodes invisible to driverCheng Xu2-5/+4
Some opcodes are used in hardware internally, and driver does not care about them. So, we change them to reserved opcodes in driver. Signed-off-by: Cheng Xu <chengyou@linux.alibaba.com> Link: https://lore.kernel.org/r/20220909093822.33868-4-chengyou@linux.alibaba.com Signed-off-by: Leon Romanovsky <leon@kernel.org>
2022-09-20RDMA/erdma: Remove redundant includesCheng Xu9-56/+1
Many of erdma's includes are redundant, because they are already included indirectly by kernel headers or custom headers. So we remove all the unnecessary direct-includes. Besides, add linux/pci.h to erdma.h because it's also used in the file. Signed-off-by: Cheng Xu <chengyou@linux.alibaba.com> Link: https://lore.kernel.org/r/20220909093822.33868-3-chengyou@linux.alibaba.com Signed-off-by: Leon Romanovsky <leon@kernel.org>
2022-09-20RDMA/erdma: Eliminate unnecessary casting for erdma_post_cmd_waitCheng Xu5-22/+12
erdma_post_cmd_wait does not use the 'u64 *req' input parameter directly. So it is better to define it to 'void *req', and by this we can eliminate the casting when calling erdma_post_cmd_wait. Signed-off-by: Cheng Xu <chengyou@linux.alibaba.com> Link: https://lore.kernel.org/r/20220909093822.33868-2-chengyou@linux.alibaba.com Signed-off-by: Leon Romanovsky <leon@kernel.org>
2022-09-20Support for CS42L83 on Apple machinesMark Brown9-126/+529
Merge series from Martin Povišer <povik+lin@cutebit.org>: there's a CS42L83 headphone jack codec found in Apple computers (in the recent 'Apple Silicon' ones as well as in earlier models, one example [1]). The part isn't publicly documented, but it appears almost identical to CS42L42, for which we have a driver in kernel. This series adapts the CS42L42 driver to the new part, and makes one change in anticipation of a machine driver for the Apple computers. Patch 1 adds new compatible to the cs42l42 schema. Patches 2 to 7 are taken from Richard's recent series [2] adding soundwire support to cs42l42. They are useful refactorings to build on in the later patches, and also this way our work doesn't diverge. (I fixed missing free_irq path in cs42l42_init, did s/Soundwire/SoundWire/ in changelogs, rebased.) Patch 8 exports some regmap-related symbols from cs42l42.c so they can be used to create cs42l83 regmap in cs42l83-i2c.c later. Patch 9 is the cs42l83 support proper. Patch 10 implements 'set_bclk_ratio' on the cs42l42 core. This will be called by the upcoming ASoC machine driver for 'Apple Silicon' Macs. (We have touched on this change to be made in earlier discussion, see [3] and replies.) Patch 11 brings cs42l42-i2c.c in sync with cs42l83-i2c.c on dev_err_probe() usage.
2022-09-20ASoC: SOF: Intel: override mclk_id for ES8336 supportMark Brown8-5/+143
Merge series from Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>: This patchset solves a known issue with ES8336 platforms wrt MCLK selection. Most of the devices use the MCLK0 signal, but some devices do use the MCLK1 signal. The MCLK is defined in the topology, it would be a nightmare to generate more topology files just for one MCLK difference. With a minor extension to the intel-nhlt library, the MCLK information can be found by parsing the NHLT table, and we can override the mclk_id at boot time. The only known issues for this platform remain the detection of GPIO and microphone connections, currently only possible with manual quirks. Thanks to Eugene J. Markow for testing this patchset.
2022-09-20ASoC: SOF: Intel: hda: override mclk_id after parsing NHLT SSP blobPierre-Louis Bossart1-0/+28
The NHLT is already used to determine which SSP is connected to an audio codec, we can parse the SSP blob to get the mclk_id from NHLT. Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Reviewed-by: Kai Vehmanen <kai.vehmanen@linux.intel.com> Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com> Link: https://lore.kernel.org/r/20220919115350.43104-5-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2022-09-20ALSA: hda: intel-nhlt: add intel_nhlt_ssp_mclk_mask()Pierre-Louis Bossart2-0/+86
SOF topologies hard-code the MCLK used for SSP connections. That was a bad idea in hindsight, this information should really come from BIOS and/or machine driver. This patch introduces a helper to scan all SSP endpoints connected to a codec, and all formats to see what MCLK is used. When BIT(0) of the mdivc offset if set in the SSP blob, MCLK0 is used, and likewise when BIT(1) is set MCLK1 is used. The case where both MCLKs are used is possible but has never been seen in practice so should be treated as an error by the caller. Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Reviewed-by: Kai Vehmanen <kai.vehmanen@linux.intel.com> Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com> Reviewed-by: Takashi Iwai <tiwai@suse.de> Link: https://lore.kernel.org/r/20220919115350.43104-4-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2022-09-20ASoC: soc.h: use array instead of playback/capture_widgetKuninori Morimoto2-11/+12
snd_soc_pcm_runtime has playback/capture_widget for Codec2Coddec. The naming is unclear. This patch names it as c2c_widget and uses array. struct snd_soc_pcm_runtime { ... => struct snd_soc_dapm_widget *playback_widget; => struct snd_soc_dapm_widget *capture_widget; ... } Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Link: https://lore.kernel.org/r/87pmfqv9mk.wl-kuninori.morimoto.gx@renesas.com Signed-off-by: Mark Brown <broonie@kernel.org>
2022-09-20ASoC: soc.h: use defined number instead of direct numberKuninori Morimoto1-1/+1
snd_soc_pcm_runtime has dpcm for Playback/Capture, but it is defined directly "2". It should use defined number. struct snd_soc_pcm_runtime { ... => struct snd_soc_dpcm_runtime dpcm[2]; ... } This patch fixup it. Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Link: https://lore.kernel.org/r/87r106v9mv.wl-kuninori.morimoto.gx@renesas.com Signed-off-by: Mark Brown <broonie@kernel.org>
2022-09-20ASoC: soc.h: remove num_cpus/codecsKuninori Morimoto9-30/+26
Current rtd has both dai_link pointer (A) and num_cpus/codecs (B). (A) rtd->dai_link = dai_link; (B) rtd->num_cpus = dai_link->num_cpus; (B) rtd->num_codecs = dai_link->num_codecs; But, we can get num_cpus/codecs (B) via dai_link (A). This means we don't need to keep num_cpus/codecs on rtd. This patch removes these. Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Link: https://lore.kernel.org/r/87sfkmv9n3.wl-kuninori.morimoto.gx@renesas.com Signed-off-by: Mark Brown <broonie@kernel.org>
2022-09-20hid: topre: Add driver fixing report descriptorHarry Stern4-0/+59
The Topre REALFORCE R2 firmware incorrectly reports that interface descriptor number 1, input report descriptor 2's events are array events rather than variable events. That particular report descriptor is used to report keypresses when there are more than 6 keys held at a time. This bug prevents events from this interface from being registered properly, so only 6 keypresses (from a different interface) can be registered at once, rather than full n-key rollover. This commit fixes the bug by setting the correct value in a report_fixup function. The original bug report can be found here: Link: https://gitlab.freedesktop.org/libinput/libinput/-/issues/804 Thanks to Benjamin Tissoires for diagnosing the issue with the report descriptor. Signed-off-by: Harry Stern <harry@harrystern.net> Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Link: https://lore.kernel.org/r/20220911003614.297613-1-harry@harrystern.net
2022-09-20RDMA/srp: Fix srp_abort()Bart Van Assche1-3/+1
Fix the code for converting a SCSI command pointer into an SRP request pointer. Cc: Xiao Yang <yangx.jy@fujitsu.com> Fixes: ad215aaea4f9 ("RDMA/srp: Make struct scsi_cmnd and struct srp_request adjacent") Signed-off-by: Bart Van Assche <bvanassche@acm.org> Link: https://lore.kernel.org/r/20220908233139.3042628-1-bvanassche@acm.org Signed-off-by: Leon Romanovsky <leon@kernel.org>
2022-09-20HID: multitouch: Add memory barriersAndri Yngvason1-4/+4
This fixes broken atomic checks which cause a race between the release-timer and processing of hid input. I noticed that contacts were sometimes sticking, even with the "sticky fingers" quirk enabled. This fixes that problem. Cc: stable@vger.kernel.org Fixes: 9609827458c3 ("HID: multitouch: optimize the sticky fingers timer") Signed-off-by: Andri Yngvason <andri@yngvason.is> Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Link: https://lore.kernel.org/r/20220907150159.2285460-1-andri@yngvason.is
2022-09-20RDMA/qib: fix repeated words in commentswangjianli1-1/+1
Delete the redundant word 'to'. Signed-off-by: wangjianli <wangjianli@cdjrlc.com> Link: https://lore.kernel.org/r/20220908132036.42355-1-wangjianli@cdjrlc.com Signed-off-by: Leon Romanovsky <leon@kernel.org>
2022-09-20RDMA/hfi1: fix repeated words in commentswangjianli2-2/+2
Delete the redundant word 'to'. Signed-off-by: wangjianli <wangjianli@cdjrlc.com> Link: https://lore.kernel.org/r/20220908131824.41106-1-wangjianli@cdjrlc.com Signed-off-by: Leon Romanovsky <leon@kernel.org>
2022-09-20HID: convert defines of HID class requests into a proper enumBenjamin Tissoires3-13/+16
This allows to export the type in BTF and so in the automatically generated vmlinux.h. It will also add some static checks on the users when we change the ll driver API (see not below). Note that we need to also do change in the ll_driver API, but given that this will have a wider impact outside of this tree, we leave this as a TODO for the future. Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Link: https://lore.kernel.org/r/20220902132938.2409206-11-benjamin.tissoires@redhat.com
2022-09-20HID: export hid_report_type to uapiBenjamin Tissoires3-22/+27
When we are dealing with eBPF, we need to have access to the report type. Currently our implementation differs from the USB standard, making it impossible for users to know the exact value besides hardcoding it themselves. And instead of a blank define, convert it as an enum. Note that we need to also do change in the ll_driver API, but given that this will have a wider impact outside of this tree, we leave this as a TODO for the future. Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Link: https://lore.kernel.org/r/20220902132938.2409206-10-benjamin.tissoires@redhat.com
2022-09-20HID: core: store the unique system identifier in hid_deviceBenjamin Tissoires2-1/+5
This unique identifier is currently used only for ensuring uniqueness in sysfs. However, this could be handful for userspace to refer to a specific hid_device by this id. 2 use cases are in my mind: LEDs (and their naming convention), and HID-BPF. Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Link: https://lore.kernel.org/r/20220902132938.2409206-9-benjamin.tissoires@redhat.com
2022-09-20HID: Add driver for PhoenixRC Flight ControllerMarcus Folkesson5-0/+129
The PhoenixRC is a controller with 8 channels for use in flight simulators. Signed-off-by: Marcus Folkesson <marcus.folkesson@gmail.com> Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Link: https://lore.kernel.org/r/20220914184345.270456-1-marcus.folkesson@gmail.com
2022-09-20HID: Add driver for VRC-2 Car ControllerMarcus Folkesson4-0/+108
VRC-2 is 2-axis controller often used in car simulators. Signed-off-by: Marcus Folkesson <marcus.folkesson@gmail.com> Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Link: https://lore.kernel.org/r/20220902082552.2433744-2-marcus.folkesson@gmail.com
2022-09-20Merge branch 'seg6-add-next-c-sid-support-for-srv6-end-behavior'Paolo Abeni4-19/+1530
Andrea Mayer says: ==================== seg6: add NEXT-C-SID support for SRv6 End behavior The Segment Routing (SR) architecture is based on loose source routing. A list of instructions, called segments, can be added to the packet headers to influence the forwarding and processing of the packets in an SR enabled network. In SRv6 (Segment Routing over IPv6 data plane) [1], the segment identifiers (SIDs) are IPv6 addresses (128 bits) and the segment list (SID List) is carried in the Segment Routing Header (SRH). A segment may correspond to a "behavior" that is executed by a node when the packet is received. The Linux kernel currently supports a large subset of the behaviors described in [2] (e.g., End, End.X, End.T and so on). Some SRv6 scenarios (i.e.: traffic-engineering, fast-rerouting, VPN, mobile network backhaul, etc.) may require a large number of segments (i.e. up to 15). Therefore, reducing the size of the SID List is useful to minimize the impact on MTU (Maximum Transfer Unit) and to enable SRv6 on legacy hardware devices with limited processing power that can suffer from long IPv6 headers. Draft-ietf-spring-srv6-srh-compression [3] extends the SRv6 architecture by providing different mechanisms for the efficient representation (i.e. compression) of the SID List. The NEXT-C-SID mechanism described in [3] offers the possibility of encoding several SRv6 segments within a single 128 bit SID address. Such a SID address is called a Compressed SID Container. In this way, the length of the SID List can be drastically reduced. In some cases, the SRH can be omitted, as the IPv6 Destination Address can carry the whole Segment List, using its compressed representation. The NEXT-C-SID mechanism relies on the "flavors" framework defined in [2]. The flavors represent additional operations that can modify or extend a subset of the existing behaviors. In this patchset we extend the SRv6 Subsystem in order to support the NEXT-C-SID mechanism. In details the patchset is made of: - patch 1/3: add netlink_ext_ack support in parsing SRv6 behavior attributes; - patch 2/3: add NEXT-C-SID support for SRv6 End behavior; - patch 3/3: add selftest for NEXT-C-SID in SRv6 End behavior. The corresponding iproute2 patch for supporting the NEXT-C-SID in SRv6 End behavior is provided in a separated patchset. Comments, improvements and suggestions are always appreciated. [1] - https://datatracker.ietf.org/doc/html/rfc8754 [2] - https://datatracker.ietf.org/doc/html/rfc8986 [3] - https://datatracker.ietf.org/doc/html/draft-ietf-spring-srv6-srh-compression ==================== Link: https://lore.kernel.org/r/20220912171619.16943-1-andrea.mayer@uniroma2.it Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2022-09-20selftests: seg6: add selftest for NEXT-C-SID flavor in SRv6 End behaviorAndrea Mayer2-0/+1146
This selftest is designed for testing the support of NEXT-C-SID flavor for SRv6 End behavior. It instantiates a virtual network composed of several nodes: hosts and SRv6 routers. Each node is realized using a network namespace that is properly interconnected to others through veth pairs. The test considers SRv6 routers implementing IPv4/IPv6 L3 VPNs leveraged by hosts for communicating with each other. Such routers i) apply different SRv6 Policies to the traffic received from connected hosts, considering the IPv4 or IPv6 protocols; ii) use the NEXT-C-SID compression mechanism for encoding several SRv6 segments within a single 128-bit SID address, referred to as a Compressed SID (C-SID) container. The NEXT-C-SID is provided as a "flavor" of the SRv6 End behavior, enabling it to properly process the C-SID containers. The correct execution of the enabled NEXT-C-SID SRv6 End behavior is verified through reachability tests carried out between hosts belonging to the same VPN. Signed-off-by: Andrea Mayer <andrea.mayer@uniroma2.it> Acked-by: David Ahern <dsahern@kernel.org> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2022-09-20seg6: add NEXT-C-SID support for SRv6 End behaviorAndrea Mayer2-3/+356
The NEXT-C-SID mechanism described in [1] offers the possibility of encoding several SRv6 segments within a single 128 bit SID address. Such a SID address is called a Compressed SID (C-SID) container. In this way, the length of the SID List can be drastically reduced. A SID instantiated with the NEXT-C-SID flavor considers an IPv6 address logically structured in three main blocks: i) Locator-Block; ii) Locator-Node Function; iii) Argument. C-SID container +------------------------------------------------------------------+ | Locator-Block |Loc-Node| Argument | | |Function| | +------------------------------------------------------------------+ <--------- B -----------> <- NF -> <------------- A ---------------> (i) The Locator-Block can be any IPv6 prefix available to the provider; (ii) The Locator-Node Function represents the node and the function to be triggered when a packet is received on the node; (iii) The Argument carries the remaining C-SIDs in the current C-SID container. The NEXT-C-SID mechanism relies on the "flavors" framework defined in [2]. The flavors represent additional operations that can modify or extend a subset of the existing behaviors. This patch introduces the support for flavors in SRv6 End behavior implementing the NEXT-C-SID one. An SRv6 End behavior with NEXT-C-SID flavor works as an End behavior but it is capable of processing the compressed SID List encoded in C-SID containers. An SRv6 End behavior with NEXT-C-SID flavor can be configured to support user-provided Locator-Block and Locator-Node Function lengths. In this implementation, such lengths must be evenly divisible by 8 (i.e. must be byte-aligned), otherwise the kernel informs the user about invalid values with a meaningful error code and message through netlink_ext_ack. If Locator-Block and/or Locator-Node Function lengths are not provided by the user during configuration of an SRv6 End behavior instance with NEXT-C-SID flavor, the kernel will choose their default values i.e., 32-bit Locator-Block and 16-bit Locator-Node Function. [1] - https://datatracker.ietf.org/doc/html/draft-ietf-spring-srv6-srh-compression [2] - https://datatracker.ietf.org/doc/html/rfc8986 Signed-off-by: Andrea Mayer <andrea.mayer@uniroma2.it> Reviewed-by: David Ahern <dsahern@kernel.org> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2022-09-20seg6: add netlink_ext_ack support in parsing SRv6 behavior attributesAndrea Mayer1-16/+28
An SRv6 behavior instance can be set up using mandatory and/or optional attributes. In the setup phase, each supplied attribute is parsed and processed. If the parsing operation fails, the creation of the behavior instance stops and an error number/code is reported to the user. In many cases, it is challenging for the user to figure out exactly what happened by relying only on the error code. For this reason, we add the support for netlink_ext_ack in parsing SRv6 behavior attributes. In this way, when an SRv6 behavior attribute is parsed and an error occurs, the kernel can send a message to the userspace describing the error through a meaningful text message in addition to the classic error code. Signed-off-by: Andrea Mayer <andrea.mayer@uniroma2.it> Reviewed-by: David Ahern <dsahern@kernel.org> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2022-09-20HID: sony: Fix double word in commentsShaomin Deng1-1/+1
Remove the repeated word "not" in comments. Signed-off-by: Shaomin Deng <dengshaomin@cdjrlc.com> Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Link: https://lore.kernel.org/r/20220904154515.25143-1-dengshaomin@cdjrlc.com
2022-09-20hid: hid-logitech-hidpp: avoid unnecessary assignments in hidpp_connect_eventHangyu Hua1-1/+3
hidpp->delayed_input can't be assigned to an object that already call input_free_device when input_register_device fails. Fixes: c39e3d5fc9dd ("HID: logitech-hidpp: late bind the input device on wireless connection") Signed-off-by: Hangyu Hua <hbh25y@gmail.com> Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Link: https://lore.kernel.org/r/20220812025515.19467-1-hbh25y@gmail.com
2022-09-20RDMA/irdma: Validate udata inlen and outlenShiraz Saleem1-7/+60
Currently ib_copy_from_udata and ib_copy_to_udata could underfill the request and response buffer if the user-space passes an undersized value for udata->inlen or udata->outlen respectively [1] This could lead to undesirable behavior. Zero initing the buffer only goes as far as preventing using the buffer uninitialized. Validate udata->inlen and udata->outlen passed from user-space to ensure they are at least the required minimum size. [1] https://lore.kernel.org/linux-rdma/MWHPR11MB0029F37D40D9D4A993F8F549E9D79@MWHPR11MB0029.namprd11.prod.outlook.com/ Fixes: b48c24c2d710 ("RDMA/irdma: Implement device supported verb APIs") Reported-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Shiraz Saleem <shiraz.saleem@intel.com> Link: https://lore.kernel.org/r/20220907191324.1173-3-shiraz.saleem@intel.com Signed-off-by: Leon Romanovsky <leon@kernel.org>
2022-09-20RDMA/irdma: Align AE id codes to correct flush code and eventSindhu-Devale6-21/+38
A number of asynchronous event (AE) ids were not aligned to the correct flush_code and event_type. Fix these up so that the correct IBV error and event codes are returned to application. Also, add handling for new AE ids like IRDMA_AE_INVALID_REQUEST to return the correct WC error code. Fixes: 44d9e52977a1 ("RDMA/irdma: Implement device initialization definitions") Signed-off-by: Sindhu-Devale <sindhu.devale@intel.com> Signed-off-by: Shiraz Saleem <shiraz.saleem@intel.com> Link: https://lore.kernel.org/r/20220907191324.1173-2-shiraz.saleem@intel.com Signed-off-by: Leon Romanovsky <leon@kernel.org>
2022-09-20Merge branch 'revert-fec-ptp-changes'Paolo Abeni3-96/+31
Francesco Dolcini says: ==================== Revert fec PTP changes Revert the last 2 FEC PTP changes from Csókás Bence, they are causing multiple issues and we are at 6.0-rc5. ==================== Link: https://lore.kernel.org/r/20220912070143.98153-1-francesco.dolcini@toradex.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2022-09-20Revert "net: fec: Use a spinlock to guard `fep->ptp_clk_on`"Francesco Dolcini3-19/+27
This reverts commit b353b241f1eb9b6265358ffbe2632fdcb563354f, this is creating multiple issues, just not ready to be merged yet. Link: https://lore.kernel.org/all/CAHk-=wj1obPoTu1AHj9Bd_BGYjdjDyPP+vT5WMj8eheb3A9WHw@mail.gmail.com/ Link: https://lore.kernel.org/all/20220907143915.5w65kainpykfobte@pengutronix.de/ Fixes: b353b241f1eb ("net: fec: Use a spinlock to guard `fep->ptp_clk_on`") Signed-off-by: Francesco Dolcini <francesco.dolcini@toradex.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Tested-by: Marc Kleine-Budde <mkl@pengutronix.de> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2022-09-20Revert "fec: Restart PPS after link state change"Francesco Dolcini3-77/+4
This reverts commit f79959220fa5fbda939592bf91c7a9ea90419040, this is creating multiple issues, just not ready to be merged yet. Link: https://lore.kernel.org/all/20220905180542.GA3685102@roeck-us.net/ Link: https://lore.kernel.org/all/CAHk-=wj1obPoTu1AHj9Bd_BGYjdjDyPP+vT5WMj8eheb3A9WHw@mail.gmail.com/ Fixes: f79959220fa5 ("fec: Restart PPS after link state change") Signed-off-by: Francesco Dolcini <francesco.dolcini@toradex.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Tested-by: Marc Kleine-Budde <mkl@pengutronix.de> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2022-09-20HID: logitech-hidpp: Detect hi-res scrolling supportBastien Nocera1-57/+61
Rather than relying on a never-ending stream of patches for quirks. This change will detect whether HID++ 1.0 hi-res scroll, HID++ 2.0 hi-res scroll or HID++ 2.0 hi-res scroll wheel is supported, and enable the feature without the need for quirks. Tested on a Logitech M705 mouse that was unsupported before this change. [ 9.365324] logitech-hidpp-device 0003:046D:406D.0006: input,hidraw3: USB HID v1.11 Mouse [Logitech M705] on usb-0000:00:14.0-4/input2:3 [ 57.472434] logitech-hidpp-device 0003:046D:406D.0006: HID++ 4.5 device connected. [ 57.616429] logitech-hidpp-device 0003:046D:406D.0006: Detected HID++ 2.0 hi-res scroll wheel [ 57.712424] logitech-hidpp-device 0003:046D:406D.0006: wheel multiplier = 8 Link: https://bugzilla.kernel.org/show_bug.cgi?id=216480 Signed-off-by: Bastien Nocera <hadess@hadess.net> Reviewed-by: Harry Cutts <hcutts@chromium.org> Tested-by: Peter F. Patel-Schneider <pfpschneider@gmail.com> Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Link: https://lore.kernel.org/r/20220914132146.6435-1-hadess@hadess.net
2022-09-20net: dsa: microchip: lan937x: fix maximum frame length checkRakesh Sankaranarayanan1-4/+0
Maximum frame length check is enabled in lan937x switch on POR, But it is found to be disabled on driver during port setup operation. Due to this, packets are not dropped when transmitted with greater than configured value. For testing, setup made for lan1->lan2 transmission and configured lan1 interface with a frame length (less than 1500 as mentioned in documentation) and transmitted packets with greater than configured value. Expected no packets at lan2 end, but packets observed at lan2. Based on the documentation, packets should get discarded if the actual packet length doesn't match the frame length configured. Frame length check should be disabled only for cascaded ports due to tailtags. This feature was disabled on ksz9477 series due to ptp issue, which is not in lan937x series. But since lan937x took ksz9477 as base, frame length check disabled here as well. Patch added to remove this portion from port setup so that maximum frame length check will be active for normal ports. Fixes: 55ab6ffaf378 ("net: dsa: microchip: add DSA support for microchip LAN937x") Signed-off-by: Rakesh Sankaranarayanan <rakesh.sankaranarayanan@microchip.com> Link: https://lore.kernel.org/r/20220912051228.1306074-1-rakesh.sankaranarayanan@microchip.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2022-09-20arm64: efi: enable generic EFI compressed bootArd Biesheuvel3-2/+14
Wire up the generic EFI zboot support for arm64. Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Tested-by: Jeremy Linton <jeremy.linton@arm.com> Acked-by: Catalin Marinas <catalin.marinas@arm.com>
2022-09-20open: always initialize ownership fieldsTetsuo Handa1-0/+2
Beginning of the merge window we introduced the vfs{g,u}id_t types in b27c82e12965 ("attr: port attribute changes to new types") and changed various codepaths over including chown_common(). During that change we forgot to account for the case were the passed ownership value is -1. In this case the ownership fields in struct iattr aren't initialized but we rely on them being initialized by the time we generate the ownership to pass down to the LSMs. All the major LSMs don't care about the ownership values at all. Only Tomoyo uses them and so it took a while for syzbot to unearth this issue. Fix this by initializing the ownership fields and do it within the retry_deleg block. While notify_change() doesn't alter the ownership fields currently we shouldn't rely on it. Since no kernel has been released with these changes this does not needed to be backported to any stable kernels. [Christian Brauner (Microsoft) <brauner@kernel.org>] * rewrote commit message * use INVALID_VFS{G,U}ID macros Fixes: b27c82e12965 ("attr: port attribute changes to new types") # mainline only Reported-and-tested-by: syzbot+541e21dcc32c4046cba9@syzkaller.appspotmail.com Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> Reviewed-by: Seth Forshee (DigitalOcean) <sforshee@kernel.org> Signed-off-by: Christian Brauner (Microsoft) <brauner@kernel.org>
2022-09-20net-next: gro: Fix use of skb_gro_header_slowRichard Gobert1-1/+1
In the cited commit, the function ipv6_gro_receive was accidentally changed to use skb_gro_header_slow, without attempting the fast path. Fix it. Fixes: 35ffb6654729 ("net: gro: skb_gro_header helper function") Signed-off-by: Richard Gobert <richardbgobert@gmail.com> Link: https://lore.kernel.org/r/20220911184835.GA105063@debian Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2022-09-20mmc: sdhci-of-aspeed: Add dependency on ARCH_ASPEEDPeter Robinson1-0/+1
The MMC_SDHCI_OF_ASPEED is part of the Aspeed silicon so it makes sense to depend on ARCH_ASPEED and for compile testing. Signed-off-by: Peter Robinson <pbrobinson@gmail.com> Link: https://lore.kernel.org/r/20220916115602.370003-1-pbrobinson@gmail.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2022-09-20mmc: mtk-sd: Add support for MT6795 Helio X10AngeloGioacchino Del Regno1-0/+14
Add support for MT6795 with a new compatible string and platform data. Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Link: https://lore.kernel.org/r/20220915120923.86038-3-angelogioacchino.delregno@collabora.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2022-09-20mmc: mtk-sd: Reorder of_device_id and platform data by nameAngeloGioacchino Del Regno1-49/+50
Both of_device_id compatible strings and platform data were partially ordered by name. Fix the ordering. This commit brings no functional changes. Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Link: https://lore.kernel.org/r/20220915120923.86038-2-angelogioacchino.delregno@collabora.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2022-09-20mmc: sdhci-sprd: Fix the limitation of divWenchao Chen1-3/+3
Because the bit field size of the divider coefficient register is 1023, it is limited before returning the value. Signed-off-by: Wenchao Chen <wenchao.chen@unisoc.com> Link: https://lore.kernel.org/r/20220914063702.20283-1-wenchao.chen666@gmail.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2022-09-20net/mlx5e: Ensure macsec_rule is always initiailized in macsec_fs_{r,t}x_add_rule()Nathan Chancellor1-2/+2
Clang warns: drivers/net/ethernet/mellanox/mlx5/core/en_accel/macsec_fs.c:539:6: error: variable 'macsec_rule' is used uninitialized whenever 'if' condition is true [-Werror,-Wsometimes-uninitialized] if (err) ^~~ drivers/net/ethernet/mellanox/mlx5/core/en_accel/macsec_fs.c:598:9: note: uninitialized use occurs here return macsec_rule; ^~~~~~~~~~~ drivers/net/ethernet/mellanox/mlx5/core/en_accel/macsec_fs.c:539:2: note: remove the 'if' if its condition is always false if (err) ^~~~~~~~ drivers/net/ethernet/mellanox/mlx5/core/en_accel/macsec_fs.c:523:38: note: initialize the variable 'macsec_rule' to silence this warning union mlx5e_macsec_rule *macsec_rule; ^ = NULL drivers/net/ethernet/mellanox/mlx5/core/en_accel/macsec_fs.c:1131:6: error: variable 'macsec_rule' is used uninitialized whenever 'if' condition is true [-Werror,-Wsometimes-uninitialized] if (err) ^~~ drivers/net/ethernet/mellanox/mlx5/core/en_accel/macsec_fs.c:1215:9: note: uninitialized use occurs here return macsec_rule; ^~~~~~~~~~~ drivers/net/ethernet/mellanox/mlx5/core/en_accel/macsec_fs.c:1131:2: note: remove the 'if' if its condition is always false if (err) ^~~~~~~~ drivers/net/ethernet/mellanox/mlx5/core/en_accel/macsec_fs.c:1118:38: note: initialize the variable 'macsec_rule' to silence this warning union mlx5e_macsec_rule *macsec_rule; ^ = NULL 2 errors generated. If macsec_fs_{r,t}x_ft_get() fail, macsec_rule will be uninitialized. Initialize it to NULL at the top of each function so that it cannot be used uninitialized. Fixes: e467b283ffd5 ("net/mlx5e: Add MACsec TX steering rules") Fixes: 3b20949cb21b ("net/mlx5e: Add MACsec RX steering rules") Link: https://github.com/ClangBuiltLinux/linux/issues/1706 Signed-off-by: Nathan Chancellor <nathan@kernel.org> Reviewed-by: Raed Salem <raeds@nvidia.com> Link: https://lore.kernel.org/r/20220911085748.461033-1-nathan@kernel.org Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2022-09-20pinctrl: cy8c95x0: Align function names in cy8c95x0_pmxopsAndy Shevchenko1-6/+6
Align the function names in the cy8c95x0_pmxops() to follow the struct pinmux_ops members naming schema. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20220916205450.86278-3-andriy.shevchenko@linux.intel.com Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2022-09-20pinctrl: cy8c95x0: Drop atomicity on operations on push_pullAndy Shevchenko1-7/+8
The push_pull member is always accessed under the mutex, hence no need to use atomic operations on it. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20220916205450.86278-2-andriy.shevchenko@linux.intel.com Signed-off-by: Linus Walleij <linus.walleij@linaro.org>