aboutsummaryrefslogtreecommitdiffstats
AgeCommit message (Collapse)AuthorFilesLines
2022-07-21Merge tag 'dt-bindings-aspeed-5.20' of git://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux-dt into arm/dtArnd Bergmann2-0/+88
Devicetree bindings for Aspeed boards 1. Document the compatibles of existing Aspeed-based boards. 2. Add jabil,rbp-bmc compatible. * tag 'dt-bindings-aspeed-5.20' of git://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux-dt: dt-bindings: arm: aspeed: add Aspeed Evaluation boards dt-bindings: arm: aspeed: document board compatibles dt-bindings: arm: aspeed: document board compatibles Link: https://lore.kernel.org/r/20220721072415.11424-1-krzysztof.kozlowski@linaro.org Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2022-07-21drm/bridge: parade-ps8640: Fix regulator supply orderChen-Yu Tsai1-2/+2
The datasheet says that VDD12 must be enabled and at full voltage before VDD33 is enabled. Reorder the bulk regulator supply names so that VDD12 is enabled before VDD33. Any enable ramp delays should be handled by setting proper constraints on the regulators. Fixes: bc1aee7fc8f0 ("drm/bridge: Add I2C based driver for ps8640 bridge") Signed-off-by: Chen-Yu Tsai <wenst@chromium.org> Reviewed-by: Neil Armstrong <narmstrong@baylibre.com> Signed-off-by: Robert Foss <robert.foss@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20220721092258.3397461-1-wenst@chromium.org
2022-07-21dmaengine: idxd: Correct IAX operation code namesFenghua Yu1-3/+3
Some IAX operation code nomenclatures are misleading or don't match with others: 1. Operation code 0x4c is Zero Compress 32. IAX_OPCODE_DECOMP_32 is a misleading name. Change it to IAX_OPCODE_ZERO_COMP_32. 2. Operation code 0x4d is Zero Compress 16. IAX_OPCODE_DECOMP_16 is a misleading name. Change it to IAX_OPCODE_ZERO_COMP_16. 3. IAX_OPCDE_FIND_UNIQUE is corrected to match with other nomenclatures. Co-developed-by: Li Zhang <li4.zhang@intel.com> Signed-off-by: Li Zhang <li4.zhang@intel.com> Signed-off-by: Fenghua Yu <fenghua.yu@intel.com> Reviewed-by: Dave Jiang <dave.jiang@intel.com> Link: https://lore.kernel.org/r/20220707002052.1546361-1-fenghua.yu@intel.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2022-07-21ASoC: amd: acp: Drop superfluous mmap callbackVenkata Prasad Potturu1-8/+0
Remove mmap callback as ASoC AMD drivers just call the standard mmap handler. Signed-off-by: Venkata Prasad Potturu <venkataprasad.potturu@amd.com> Reviewed-by: Vijendar Mukunda <Vijendar.Mukunda@amd.com> Link: https://lore.kernel.org/r/20220721062043.3016985-2-venkataprasad.potturu@amd.com Signed-off-by: Mark Brown <broonie@kernel.org>
2022-07-21ASoC: amd: acp: Modify local variables name to genericVenkata Prasad Potturu1-5/+5
Change local variables name to be generic in irq handler. Signed-off-by: Venkata Prasad Potturu <venkataprasad.potturu@amd.com> Reviewed-by: Vijendar Mukunda <Vijendar.Mukunda@amd.com> Link: https://lore.kernel.org/r/20220721062043.3016985-1-venkataprasad.potturu@amd.com Signed-off-by: Mark Brown <broonie@kernel.org>
2022-07-21ASoC: qcom: q6dsp: Fix an off-by-one in q6adm_alloc_copp()Christophe JAILLET1-1/+1
find_first_zero_bit() returns MAX_COPPS_PER_PORT at max here. So 'idx' should be tested with ">=" or the test can't match. Fixes: 7b20b2be51e1 ("ASoC: qdsp6: q6adm: Add q6adm driver") Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Link: https://lore.kernel.org/r/0fca3271649736053eb9649d87e1ca01b056be40.1658394124.git.christophe.jaillet@wanadoo.fr Signed-off-by: Mark Brown <broonie@kernel.org>
2022-07-21ASoC: imx-card: use snd_pcm_format_t type for asrc_formatShengjiu Wang1-3/+5
Fix sparse warning: sound/soc/fsl/imx-card.c:653:59: sparse: warning: incorrect type in assignment (different base types) sound/soc/fsl/imx-card.c:653:59: sparse: expected unsigned int [usertype] asrc_format sound/soc/fsl/imx-card.c:653:59: sparse: got restricted snd_pcm_format_t [usertype] sound/soc/fsl/imx-card.c:655:59: sparse: warning: incorrect type in assignment (different base types) sound/soc/fsl/imx-card.c:655:59: sparse: expected unsigned int [usertype] asrc_format sound/soc/fsl/imx-card.c:655:59: sparse: got restricted snd_pcm_format_t [usertype] Fixes: aa736700f42f ("ASoC: imx-card: Add imx-card machine driver") Signed-off-by: Shengjiu Wang <shengjiu.wang@nxp.com> Link: https://lore.kernel.org/r/1658399393-28777-6-git-send-email-shengjiu.wang@nxp.com Signed-off-by: Mark Brown <broonie@kernel.org>
2022-07-21ASoC: fsl_easrc: use snd_pcm_format_t type for sample_formatShengjiu Wang2-4/+7
Fix sparse warning: sound/soc/fsl/fsl_easrc.c:562:33: sparse: warning: restricted snd_pcm_format_t degrades to integer sound/soc/fsl/fsl_easrc.c:563:34: sparse: warning: restricted snd_pcm_format_t degrades to integer sound/soc/fsl/fsl_easrc.c:565:38: sparse: warning: restricted snd_pcm_format_t degrades to integer sound/soc/fsl/fsl_easrc.c:566:39: sparse: warning: restricted snd_pcm_format_t degrades to integer sound/soc/fsl/fsl_easrc.c:608:33: sparse: warning: restricted snd_pcm_format_t degrades to integer sound/soc/fsl/fsl_easrc.c:609:34: sparse: warning: restricted snd_pcm_format_t degrades to integer sound/soc/fsl/fsl_easrc.c:615:40: sparse: warning: restricted snd_pcm_format_t degrades to integer sound/soc/fsl/fsl_easrc.c:616:41: sparse: warning: restricted snd_pcm_format_t degrades to integer sound/soc/fsl/fsl_easrc.c:1465:51: sparse: warning: incorrect type in assignment (different base types) sound/soc/fsl/fsl_easrc.c:1465:51: sparse: expected unsigned int sample_format sound/soc/fsl/fsl_easrc.c:1465:51: sparse: got restricted snd_pcm_format_t [usertype] format sound/soc/fsl/fsl_easrc.c:1467:52: sparse: warning: incorrect type in assignment (different base types) sound/soc/fsl/fsl_easrc.c:1467:52: sparse: expected unsigned int sample_format sound/soc/fsl/fsl_easrc.c:1467:52: sparse: got restricted snd_pcm_format_t [usertype] asrc_format sound/soc/fsl/fsl_easrc.c:1470:52: sparse: warning: incorrect type in assignment (different base types) sound/soc/fsl/fsl_easrc.c:1470:52: sparse: expected unsigned int sample_format sound/soc/fsl/fsl_easrc.c:1470:52: sparse: got restricted snd_pcm_format_t [usertype] format sound/soc/fsl/fsl_easrc.c:1472:51: sparse: warning: incorrect type in assignment (different base types) sound/soc/fsl/fsl_easrc.c:1472:51: sparse: expected unsigned int sample_format sound/soc/fsl/fsl_easrc.c:1472:51: sparse: got restricted snd_pcm_format_t [usertype] asrc_format sound/soc/fsl/fsl_easrc.c:1484:41: sparse: warning: incorrect type in argument 2 (different base types) sound/soc/fsl/fsl_easrc.c:1484:41: sparse: expected restricted snd_pcm_format_t [usertype] *in_raw_format sound/soc/fsl/fsl_easrc.c:1484:41: sparse: got unsigned int * sound/soc/fsl/fsl_easrc.c:1485:41: sparse: warning: incorrect type in argument 3 (different base types) sound/soc/fsl/fsl_easrc.c:1485:41: sparse: expected restricted snd_pcm_format_t [usertype] *out_raw_format sound/soc/fsl/fsl_easrc.c:1485:41: sparse: got unsigned int * sound/soc/fsl/fsl_easrc.c:1937:60: sparse: warning: incorrect type in argument 3 (different base types) sound/soc/fsl/fsl_easrc.c:1937:60: sparse: expected unsigned int [usertype] *out_value sound/soc/fsl/fsl_easrc.c:1937:60: sparse: got restricted snd_pcm_format_t * sound/soc/fsl/fsl_easrc.c:1943:49: sparse: warning: restricted snd_pcm_format_t degrades to integer Fixes: 955ac624058f ("ASoC: fsl_easrc: Add EASRC ASoC CPU DAI drivers") Signed-off-by: Shengjiu Wang <shengjiu.wang@nxp.com> Link: https://lore.kernel.org/r/1658399393-28777-5-git-send-email-shengjiu.wang@nxp.com Signed-off-by: Mark Brown <broonie@kernel.org>
2022-07-21ASoC: fsl-asoc-card: force cast the asrc_format typeShengjiu Wang1-2/+3
Fix sparse warning: sound/soc/fsl/fsl-asoc-card.c:833:45: sparse: warning: incorrect type in argument 3 (different base types) sound/soc/fsl/fsl-asoc-card.c:833:45: sparse: expected unsigned int [usertype] *out_value sound/soc/fsl/fsl-asoc-card.c:833:45: sparse: got restricted snd_pcm_format_t * Fixes: 859e364302c5 ("ASoC: fsl-asoc-card: Support new property fsl, asrc-format") Signed-off-by: Shengjiu Wang <shengjiu.wang@nxp.com> Link: https://lore.kernel.org/r/1658399393-28777-4-git-send-email-shengjiu.wang@nxp.com Signed-off-by: Mark Brown <broonie@kernel.org>
2022-07-21ASoC: fsl_asrc: force cast the asrc_format typeShengjiu Wang1-2/+4
Fix sparse warning: sound/soc/fsl/fsl_asrc.c:1177:60: sparse: warning: incorrect type in argument 3 (different base types) sound/soc/fsl/fsl_asrc.c:1177:60: sparse: expected unsigned int [usertype] *out_value sound/soc/fsl/fsl_asrc.c:1177:60: sparse: got restricted snd_pcm_format_t * sound/soc/fsl/fsl_asrc.c:1200:47: sparse: warning: restricted snd_pcm_format_t degrades to integer Fixes: 4520af41fd21 ("ASoC: fsl_asrc: Support new property fsl,asrc-format") Signed-off-by: Shengjiu Wang <shengjiu.wang@nxp.com> Link: https://lore.kernel.org/r/1658399393-28777-3-git-send-email-shengjiu.wang@nxp.com Signed-off-by: Mark Brown <broonie@kernel.org>
2022-07-21ASoC: fsl_sai: Don't use plain integer as NULL pointerShengjiu Wang1-1/+1
Fix sparse warning: sound/soc/fsl/fsl_sai.c:64:39: sparse: warning: Using plain integer as NULL pointer Fixes: b4ee8a913e61 ("ASoc: fsl_sai: Add pinctrl operation for PDM and DSD") Signed-off-by: Shengjiu Wang <shengjiu.wang@nxp.com> Link: https://lore.kernel.org/r/1658399393-28777-2-git-send-email-shengjiu.wang@nxp.com Signed-off-by: Mark Brown <broonie@kernel.org>
2022-07-21dmaengine: imx-dma: Cast of_device_get_match_data() with (uintptr_t)Fabio Estevam1-1/+1
Change the of_device_get_match_data() cast to (uintptr_t) to silence the following clang warning: drivers/dma/imx-dma.c:1048:20: warning: cast to smaller integer type 'enum imx_dma_type' from 'const void *' [-Wvoid-pointer-to-enum-cast] Reported-by: kernel test robot <lkp@intel.com> Fixes: 0ab785c894e6 ("dmaengine: imx-dma: Remove unused .id_table") Signed-off-by: Fabio Estevam <festevam@denx.de> Link: https://lore.kernel.org/r/20220706111327.940764-1-festevam@gmail.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2022-07-21dmaengine: dw-axi-dmac: ignore interrupt if no descriptorBen Dooks1-0/+6
If the channel has no descriptor and the interrupt is raised then the kernel will OOPS. Check the result of vchan_next_desc() in the handler axi_chan_block_xfer_complete() to avoid the error happening. Signed-off-by: Ben Dooks <ben.dooks@sifive.com> Link: https://lore.kernel.org/r/20220708170153.269991-4-ben.dooks@sifive.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2022-07-21dmaengine: dw-axi-dmac: do not print NULL LLI during errorBen Dooks1-0/+5
During debugging we have seen an issue where axi_chan_dump_lli() is passed a NULL LLI pointer which ends up causing an OOPS due to trying to get fields from it. Simply print NULL LLI and exit to avoid this. Signed-off-by: Ben Dooks <ben.dooks@sifive.com> Link: https://lore.kernel.org/r/20220708170153.269991-3-ben.dooks@sifive.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2022-07-21libbpf: Fix str_has_sfx()'s return valueDan Carpenter1-3/+3
The return from strcmp() is inverted so it wrongly returns true instead of false and vice versa. Fixes: a1c9d61b19cb ("libbpf: Improve library identification for uprobe binary path resolution") Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Acked-by: Martin KaFai Lau <kafai@fb.com> Cc: Alan Maguire <alan.maguire@oracle.com> Link: https://lore.kernel.org/bpf/YtZ+/dAA195d99ak@kili
2022-07-21libbpf: Fix sign expansion bug in btf_dump_get_enum_value()Dan Carpenter1-1/+1
The code here is supposed to take a signed int and store it in a signed long long. Unfortunately, the way that the type promotion works with this conditional statement is that it takes a signed int, type promotes it to a __u32, and then stores that as a signed long long. The result is never negative. This is from static analysis, but I made a little test program just to test it before I sent the patch: #include <stdio.h> int main(void) { unsigned long long src = -1ULL; signed long long dst1, dst2; int is_signed = 1; dst1 = is_signed ? *(int *)&src : *(unsigned int *)0; dst2 = is_signed ? (signed long long)*(int *)&src : *(unsigned int *)0; printf("%lld\n", dst1); printf("%lld\n", dst2); return 0; } Fixes: d90ec262b35b ("libbpf: Add enum64 support for btf_dump") Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Acked-by: Martin KaFai Lau <kafai@fb.com> Link: https://lore.kernel.org/bpf/YtZ+LpgPADm7BeEd@kili
2022-07-21HID: wacom: Force pen out of prox if no events have been received in a whileJason Gerecke3-0/+44
Prox-out events may not be reliably sent by some AES firmware. This can cause problems for users, particularly due to arbitration logic disabling touch input while the pen is in prox. This commit adds a timer which is reset every time a new prox event is received. When the timer expires we check to see if the pen is still in prox and force it out if necessary. This is patterend off of the same solution used by 'hid-letsketch' driver which has a similar problem. Link: https://github.com/linuxwacom/input-wacom/issues/310 Signed-off-by: Jason Gerecke <jason.gerecke@wacom.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2022-07-21HID: nintendo: Add missing array terminationGuenter Roeck1-0/+1
joycon_dpad_inputs_jc[] is unterminated. This may result in odd warnings such as input: input_set_capability: invalid code 3077588140 for type 1 or in kernel crashes in nintendo_hid_probe(). Terminate the array to fix the problem. Fixes: 2af16c1f846bd ("HID: nintendo: add nintendo switch controller driver") Cc: Daniel J. Ogorchock <djogorchock@gmail.com> Signed-off-by: Guenter Roeck <linux@roeck-us.net> Reviewed-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Cc: stable@vger.kernel.org Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2022-07-21HID: lg-g15: Fix comment typoJason Wang1-1/+1
The double `with' is duplicated in line 769, remove one. Signed-off-by: Jason Wang <wangborong@cdjrlc.com> Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2022-07-21HID: amd_sfh: Implement SFH1.1 functionalityBasavaraj Natikar8-0/+895
Newer AMD SOCs use SFH1.1 memory access with new PCI-id. Hence add new sfh1_1 sub directory to implement SFH1.1 functionality by defining new PCI id, interface functions, descriptor functions and handlers which invokes sfh1.1. Signed-off-by: Basavaraj Natikar <Basavaraj.Natikar@amd.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2022-07-21HID: amd_sfh: Move interrupt handling to common interfaceBasavaraj Natikar3-8/+10
Interrupt handling can be used in multiple files to support all AMD SOCs. Hence move interrupt handling to common interface. Signed-off-by: Basavaraj Natikar <Basavaraj.Natikar@amd.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2022-07-21HID: amd_sfh: Move amd_sfh_work to common interfaceBasavaraj Natikar2-2/+4
amd_sfh_work can be used in multiple files to support all AMD SOCs. Hence move amd_sfh_work to common interface. Signed-off-by: Basavaraj Natikar <Basavaraj.Natikar@amd.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2022-07-21HID: amd_sfh: Move global functions to staticBasavaraj Natikar3-12/+5
Move global functions declared from header files and make them as static functions wherever applicable. Signed-off-by: Basavaraj Natikar <Basavaraj.Natikar@amd.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2022-07-21HID: amd_sfh: Add remove operation in amd_mp2_opsBasavaraj Natikar2-1/+4
Add remove operation as part of amd_mp2_ops structure to support all AMD SOCs and use wherever applicable. Signed-off-by: Basavaraj Natikar <Basavaraj.Natikar@amd.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2022-07-21HID: amd_sfh: Add PM operations in amd_mp2_opsBasavaraj Natikar3-39/+58
Add PM operations as part of amd_mp2_ops structure to support all AMD SOCs and use wherever applicable. Signed-off-by: Basavaraj Natikar <Basavaraj.Natikar@amd.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2022-07-21HID: amd_sfh: Add descriptor operations in amd_mp2_opsBasavaraj Natikar7-25/+42
Add dynamic descriptor operations as part of amd_mp2_ops structure to support all AMD SOCs and use wherever applicable. Signed-off-by: Basavaraj Natikar <Basavaraj.Natikar@amd.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2022-07-21HID: amd_sfh: Move request_list variable to client dataBasavaraj Natikar2-5/+8
request_list variable can be used in multiple files to support all AMD SOCs. Hence move request_list variable to client data. Signed-off-by: Basavaraj Natikar <Basavaraj.Natikar@amd.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2022-07-21HID: amd_sfh: Move request_list struct to header fileBasavaraj Natikar2-10/+9
request_list structure can be used in multiple files to support all AMD SOCs. Hence move request_list structure to header file. Signed-off-by: Basavaraj Natikar <Basavaraj.Natikar@amd.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2022-07-21HID: amd_sfh: Move common macros and structuresBasavaraj Natikar2-41/+60
Introduce common macros and structures to support multiple generations of AMD SOCs, move them to amd_sfh_common.h. Signed-off-by: Basavaraj Natikar <Basavaraj.Natikar@amd.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2022-07-21HID: amd_sfh: Add NULL check for hid deviceBasavaraj Natikar1-4/+8
On removal of hid device during SFH set report may cause NULL pointer exception. Hence add NULL check for hid device before accessing. Fixes: 4b2c53d93a4b ("SFH:Transport Driver to add support of AMD Sensor Fusion Hub (SFH)") Signed-off-by: Basavaraj Natikar <Basavaraj.Natikar@amd.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2022-07-21HID: core: remove unneeded assignment in hid_process_report()Lukas Bulwahn1-1/+1
Commit bebcc522fbee ("HID: core: for input reports, process the usages by priority list") split the iteration into two distinct loops in hid_process_report(). After this change, the variable field is only used while iterating in the second loop and the assignment of values to this variable in the first loop is simply not needed. Remove the unneeded assignment during retrieval. No functional change and no change in the resulting object code. This was discovered as a dead store with clang-analyzer. Signed-off-by: Lukas Bulwahn <lukas.bulwahn@gmail.com> Reviewed-by: Tom Rix <trix@redhat.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2022-07-21net/cdc_ncm: Increase NTB max RX/TX values to 64kbŁukasz Spintzyk1-2/+2
DisplayLink ethernet devices require NTB buffers larger then 32kb in order to run with highest performance. This patch is changing upper limit of the rx and tx buffers. Those buffers are initialized with CDC_NCM_NTB_DEF_SIZE_RX and CDC_NCM_NTB_DEF_SIZE_TX which is 16kb so by default no device is affected by increased limit. Rx and tx buffer is increased under two conditions: - Device need to advertise that it supports higher buffer size in dwNtbMaxInMaxSize and dwNtbMaxOutMaxSize. - cdc_ncm/rx_max and cdc_ncm/tx_max driver parameters must be adjusted with udev rule or ethtool. Summary of testing and performance results: Tests were performed on following devices: - DisplayLink DL-3xxx family device - DisplayLink DL-6xxx family device - ASUS USB-C2500 2.5G USB3 ethernet adapter - Plugable USB3 1G USB3 ethernet adapter - EDIMAX EU-4307 USB-C ethernet adapter - Dell DBQBCBC064 USB-C ethernet adapter Performance measurements were done with: - iperf3 between two linux boxes - http://openspeedtest.com/ instance running on local test machine Insights from tests results: - All except one from third party usb adapters were not affected by increased buffer size to their advertised dwNtbOutMaxSize and dwNtbInMaxSize. Devices were generally reaching 912-940Mbps both download and upload. Only EDIMAX adapter experienced decreased download size from 929Mbps to 827Mbps with iper3, with openspeedtest decrease was from 968Mbps to 886Mbps. - DisplayLink DL-3xxx family devices experienced performance increase with iperf3 download from 300Mbps to 870Mbps and upload from 782Mbps to 844Mbps. With openspeedtest download increased from 556Mbps to 873Mbps and upload from 727Mbps to 973Mbps - DiplayLink DL-6xxx family devices are not affected by increased buffer size. Signed-off-by: Łukasz Spintzyk <lukasz.spintzyk@synaptics.com> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Link: https://lore.kernel.org/r/20220720060518.541-2-lukasz.spintzyk@synaptics.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2022-07-21net/cdc_ncm: Enable ZLP for DisplayLink ethernet devicesDominik Czerwik1-1/+24
This improves performance and stability of DL-3xxx/DL-5xxx/DL-6xxx device series. Specifically prevents device from temporary network dropouts when playing video from the web and network traffic going through is high. Signed-off-by: Dominik Czerwik <dominik.czerwik@synaptics.com> Signed-off-by: Łukasz Spintzyk <lukasz.spintzyk@synaptics.com> Link: https://lore.kernel.org/r/20220720060518.541-1-lukasz.spintzyk@synaptics.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2022-07-21drm: correct commentsLiu Zixian2-2/+2
On failure, these functions return error pointer, not NULL. Signed-off-by: Liu Zixian <liuzixian4@huawei.com> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://patchwork.freedesktop.org/patch/msgid/20220718015357.1722-1-liuzixian4@huawei.com
2022-07-21drm/vc4: Add explicit declaration of 'drmm_of_get_bridge'Wang Jingjin1-0/+8
Fix the error of implicit declaration of function 'drmm_of_get_bridge': drivers/gpu/drm/vc4/vc4_dpi.c:278:11: error: implicit declaration of function ‘drmm_of_get_bridge’; did you mean ‘devm_drm_of_get_bridge’? [-Werror=implicit-function-declaration] bridge = drmm_of_get_bridge(drm, dev->of_node, 0, 0); Fixes: 055af0235aef ("drm/vc4: dpi: Switch to drmm_of_get_bridge") Signed-off-by: Wang Jingjin <wangjingjin1@huawei.com> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://patchwork.freedesktop.org/patch/msgid/20220716020741.4124893-1-wangjingjin1@huawei.com
2022-07-21ID: intel-ish-hid: hid-client: drop unexpected word "the" in the commentsJiang Jian1-1/+1
there is an unexpected word "the" in the comments that need to be dropped file: drivers/hid/intel-ish-hid/ishtp-hid-client.c line: 331 * @device: Pointer to the the ishtp client device for which this message changed to * @device: Pointer to the ishtp client device for which this message Signed-off-by: Jiang Jian <jiangjian@cdjrlc.com> Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2022-07-21HID: mcp2221: prevent a buffer overflow in mcp_smbus_write()Harshit Mogalapalli1-0/+3
Smatch Warning: drivers/hid/hid-mcp2221.c:388 mcp_smbus_write() error: __memcpy() '&mcp->txbuf[5]' too small (59 vs 255) drivers/hid/hid-mcp2221.c:388 mcp_smbus_write() error: __memcpy() 'buf' too small (34 vs 255) The 'len' variable can take a value between 0-255 as it can come from data->block[0] and it is user data. So add an bound check to prevent a buffer overflow in memcpy(). Fixes: 67a95c21463d ("HID: mcp2221: add usb to i2c-smbus host bridge") Signed-off-by: Harshit Mogalapalli <harshit.m.mogalapalli@oracle.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2022-07-21ceph: rely on vfs for setgid strippingYang Xu1-4/+0
Now that we finished moving setgid stripping for regular files in setgid directories into the vfs, individual filesystem don't need to manually strip the setgid bit anymore. Drop the now unneeded code from ceph. Link: https://lore.kernel.org/r/1657779088-2242-4-git-send-email-xuyang2018.jy@fujitsu.com Reviewed-by: Xiubo Li <xiubli@redhat.com> Reviewed-by: Christian Brauner (Microsoft)<brauner@kernel.org> Reviewed-and-Tested-by: Jeff Layton <jlayton@kernel.org> Signed-off-by: Yang Xu <xuyang2018.jy@fujitsu.com> Signed-off-by: Christian Brauner (Microsoft) <brauner@kernel.org>
2022-07-21fs: move S_ISGID stripping into the vfs_*() helpersYang Xu3-15/+70
Move setgid handling out of individual filesystems and into the VFS itself to stop the proliferation of setgid inheritance bugs. Creating files that have both the S_IXGRP and S_ISGID bit raised in directories that themselves have the S_ISGID bit set requires additional privileges to avoid security issues. When a filesystem creates a new inode it needs to take care that the caller is either in the group of the newly created inode or they have CAP_FSETID in their current user namespace and are privileged over the parent directory of the new inode. If any of these two conditions is true then the S_ISGID bit can be raised for an S_IXGRP file and if not it needs to be stripped. However, there are several key issues with the current implementation: * S_ISGID stripping logic is entangled with umask stripping. If a filesystem doesn't support or enable POSIX ACLs then umask stripping is done directly in the vfs before calling into the filesystem. If the filesystem does support POSIX ACLs then unmask stripping may be done in the filesystem itself when calling posix_acl_create(). Since umask stripping has an effect on S_ISGID inheritance, e.g., by stripping the S_IXGRP bit from the file to be created and all relevant filesystems have to call posix_acl_create() before inode_init_owner() where we currently take care of S_ISGID handling S_ISGID handling is order dependent. IOW, whether or not you get a setgid bit depends on POSIX ACLs and umask and in what order they are called. Note that technically filesystems are free to impose their own ordering between posix_acl_create() and inode_init_owner() meaning that there's additional ordering issues that influence S_SIGID inheritance. * Filesystems that don't rely on inode_init_owner() don't get S_ISGID stripping logic. While that may be intentional (e.g. network filesystems might just defer setgid stripping to a server) it is often just a security issue. This is not just ugly it's unsustainably messy especially since we do still have bugs in this area years after the initial round of setgid bugfixes. So the current state is quite messy and while we won't be able to make it completely clean as posix_acl_create() is still a filesystem specific call we can improve the S_SIGD stripping situation quite a bit by hoisting it out of inode_init_owner() and into the vfs creation operations. This means we alleviate the burden for filesystems to handle S_ISGID stripping correctly and can standardize the ordering between S_ISGID and umask stripping in the vfs. We add a new helper vfs_prepare_mode() so S_ISGID handling is now done in the VFS before umask handling. This has S_ISGID handling is unaffected unaffected by whether umask stripping is done by the VFS itself (if no POSIX ACLs are supported or enabled) or in the filesystem in posix_acl_create() (if POSIX ACLs are supported). The vfs_prepare_mode() helper is called directly in vfs_*() helpers that create new filesystem objects. We need to move them into there to make sure that filesystems like overlayfs hat have callchains like: sys_mknod() -> do_mknodat(mode) -> .mknod = ovl_mknod(mode) -> ovl_create(mode) -> vfs_mknod(mode) get S_ISGID stripping done when calling into lower filesystems via vfs_*() creation helpers. Moving vfs_prepare_mode() into e.g. vfs_mknod() takes care of that. This is in any case semantically cleaner because S_ISGID stripping is VFS security requirement. Security hooks so far have seen the mode with the umask applied but without S_ISGID handling done. The relevant hooks are called outside of vfs_*() creation helpers so by calling vfs_prepare_mode() from vfs_*() helpers the security hooks would now see the mode without umask stripping applied. For now we fix this by passing the mode with umask settings applied to not risk any regressions for LSM hooks. IOW, nothing changes for LSM hooks. It is worth pointing out that security hooks never saw the mode that is seen by the filesystem when actually creating the file. They have always been completely misplaced for that to work. The following filesystems use inode_init_owner() and thus relied on S_ISGID stripping: spufs, 9p, bfs, btrfs, ext2, ext4, f2fs, hfsplus, hugetlbfs, jfs, minix, nilfs2, ntfs3, ocfs2, omfs, overlayfs, ramfs, reiserfs, sysv, ubifs, udf, ufs, xfs, zonefs, bpf, tmpfs. All of the above filesystems end up calling inode_init_owner() when new filesystem objects are created through the ->mkdir(), ->mknod(), ->create(), ->tmpfile(), ->rename() inode operations. Since directories always inherit the S_ISGID bit with the exception of xfs when irix_sgid_inherit mode is turned on S_ISGID stripping doesn't apply. The ->symlink() and ->link() inode operations trivially inherit the mode from the target and the ->rename() inode operation inherits the mode from the source inode. All other creation inode operations will get S_ISGID handling via vfs_prepare_mode() when called from their relevant vfs_*() helpers. In addition to this there are filesystems which allow the creation of filesystem objects through ioctl()s or - in the case of spufs - circumventing the vfs in other ways. If filesystem objects are created through ioctl()s the vfs doesn't know about it and can't apply regular permission checking including S_ISGID logic. Therfore, a filesystem relying on S_ISGID stripping in inode_init_owner() in their ioctl() callpath will be affected by moving this logic into the vfs. We audited those filesystems: * btrfs allows the creation of filesystem objects through various ioctls(). Snapshot creation literally takes a snapshot and so the mode is fully preserved and S_ISGID stripping doesn't apply. Creating a new subvolum relies on inode_init_owner() in btrfs_new_subvol_inode() but only creates directories and doesn't raise S_ISGID. * ocfs2 has a peculiar implementation of reflinks. In contrast to e.g. xfs and btrfs FICLONE/FICLONERANGE ioctl() that is only concerned with the actual extents ocfs2 uses a separate ioctl() that also creates the target file. Iow, ocfs2 circumvents the vfs entirely here and did indeed rely on inode_init_owner() to strip the S_ISGID bit. This is the only place where a filesystem needs to call mode_strip_sgid() directly but this is self-inflicted pain. * spufs doesn't go through the vfs at all and doesn't use ioctl()s either. Instead it has a dedicated system call spufs_create() which allows the creation of filesystem objects. But spufs only creates directories and doesn't allo S_SIGID bits, i.e. it specifically only allows 0777 bits. * bpf uses vfs_mkobj() but also doesn't allow S_ISGID bits to be created. The patch will have an effect on ext2 when the EXT2_MOUNT_GRPID mount option is used, on ext4 when the EXT4_MOUNT_GRPID mount option is used, and on xfs when the XFS_FEAT_GRPID mount option is used. When any of these filesystems are mounted with their respective GRPID option then newly created files inherit the parent directories group unconditionally. In these cases non of the filesystems call inode_init_owner() and thus did never strip the S_ISGID bit for newly created files. Moving this logic into the VFS means that they now get the S_ISGID bit stripped. This is a user visible change. If this leads to regressions we will either need to figure out a better way or we need to revert. However, given the various setgid bugs that we found just in the last two years this is a regression risk we should take. Associated with this change is a new set of fstests to enforce the semantics for all new filesystems. Link: https://lore.kernel.org/ceph-devel/20220427092201.wvsdjbnc7b4dttaw@wittgenstein [1] Link: e014f37db1a2 ("xfs: use setattr_copy to set vfs inode attributes") [2] Link: 01ea173e103e ("xfs: fix up non-directory creation in SGID directories") [3] Link: fd84bfdddd16 ("ceph: fix up non-directory creation in SGID directories") [4] Link: https://lore.kernel.org/r/1657779088-2242-3-git-send-email-xuyang2018.jy@fujitsu.com Suggested-by: Dave Chinner <david@fromorbit.com> Suggested-by: Christian Brauner (Microsoft) <brauner@kernel.org> Reviewed-by: Darrick J. Wong <djwong@kernel.org> Reviewed-and-Tested-by: Jeff Layton <jlayton@kernel.org> Signed-off-by: Yang Xu <xuyang2018.jy@fujitsu.com> [<brauner@kernel.org>: rewrote commit message] Signed-off-by: Christian Brauner (Microsoft) <brauner@kernel.org>
2022-07-21platform/chrome: cros_kunit_util: add default value for `msg->result`Tzung-Bi Shih2-1/+6
Add default value for `msg->result` so that it won't be garbage bytes when the mock list is empty. Signed-off-by: Tzung-Bi Shih <tzungbi@kernel.org> Reviewed-by: Guenter Roeck <groeck@chromium.org> Link: https://lore.kernel.org/r/20220720044754.4026295-3-tzungbi@kernel.org
2022-07-21platform/chrome: merge Kunit utils and test casesTzung-Bi Shih3-24/+5
Merge CROS_KUNIT and CROS_EC_PROTO_KUNIT_TEST so that when they're built as modules cros_kunit_util doesn't need to export the symbols. Signed-off-by: Tzung-Bi Shih <tzungbi@kernel.org> Reviewed-by: Guenter Roeck <groeck@chromium.org> Link: https://lore.kernel.org/r/20220720044754.4026295-2-tzungbi@kernel.org
2022-07-21x86/extable: Fix ex_handler_msr() print conditionPeter Zijlstra2-11/+25
On Fri, Jun 17, 2022 at 02:08:52PM +0300, Stephane Eranian wrote: > Some changes to the way invalid MSR accesses are reported by the > kernel is causing some problems with messages printed on the > console. > > We have seen several cases of ex_handler_msr() printing invalid MSR > accesses once but the callstack multiple times causing confusion on > the console. > The problem here is that another earlier commit (5.13): > > a358f40600b3 ("once: implement DO_ONCE_LITE for non-fast-path "do once" functionality") > > Modifies all the pr_*_once() calls to always return true claiming > that no caller is ever checking the return value of the functions. > > This is why we are seeing the callstack printed without the > associated printk() msg. Extract the ONCE_IF(cond) part into __ONCE_LTE_IF() and use that to implement DO_ONCE_LITE_IF() and fix the extable code. Fixes: a358f40600b3 ("once: implement DO_ONCE_LITE for non-fast-path "do once" functionality") Reported-by: Stephane Eranian <eranian@google.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Tested-by: Stephane Eranian <eranian@google.com> Link: https://lkml.kernel.org/r/YqyVFsbviKjVGGZ9@worktop.programming.kicks-ass.net
2022-07-21x86,nospec: Simplify {JMP,CALL}_NOSPECPeter Zijlstra1-6/+18
Have {JMP,CALL}_NOSPEC generate the same code GCC does for indirect calls and rely on the objtool retpoline patching infrastructure. There's no reason these should be alternatives while the vast bulk of compiler generated retpolines are not. Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
2022-07-21sched/core: Fix the bug that task won't enqueue into core tree when update cookieCruz Zhao1-4/+5
In function sched_core_update_cookie(), a task will enqueue into the core tree only when it enqueued before, that is, if an uncookied task is cookied, it will not enqueue into the core tree until it enqueue again, which will result in unnecessary force idle. Here follows the scenario: CPU x and CPU y are a pair of SMT siblings. 1. Start task a running on CPU x without sleeping, and task b and task c running on CPU y without sleeping. 2. We create a cookie and share it to task a and task b, and then we create another cookie and share it to task c. 3. Simpling core_forceidle_sum of task a and b from /proc/PID/sched And we will find out that core_forceidle_sum of task a takes 30% time of the sampling period, which shouldn't happen as task a and b have the same cookie. Then we migrate task a to CPU x', migrate task b and c to CPU y', where CPU x' and CPU y' are a pair of SMT siblings, and sampling again, we will found out that core_forceidle_sum of task a and b are almost zero. To solve this problem, we enqueue the task into the core tree if it's on rq. Fixes: 6e33cad0af49("sched: Trivial core scheduling cookie management") Signed-off-by: Cruz Zhao <CruzZhao@linux.alibaba.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Link: https://lkml.kernel.org/r/1656403045-100840-2-git-send-email-CruzZhao@linux.alibaba.com
2022-07-21nohz/full, sched/rt: Fix missed tick-reenabling bug in dequeue_task_rt()Nicolas Saenz Julienne1-6/+9
dequeue_task_rt() only decrements 'rt_rq->rt_nr_running' after having called sched_update_tick_dependency() preventing it from re-enabling the tick on systems that no longer have pending SCHED_RT tasks but have multiple runnable SCHED_OTHER tasks: dequeue_task_rt() dequeue_rt_entity() dequeue_rt_stack() dequeue_top_rt_rq() sub_nr_running() // decrements rq->nr_running sched_update_tick_dependency() sched_can_stop_tick() // checks rq->rt.rt_nr_running, ... __dequeue_rt_entity() dec_rt_tasks() // decrements rq->rt.rt_nr_running ... Every other scheduler class performs the operation in the opposite order, and sched_update_tick_dependency() expects the values to be updated as such. So avoid the misbehaviour by inverting the order in which the above operations are performed in the RT scheduler. Fixes: 76d92ac305f2 ("sched: Migrate sched to use new tick dependency mask model") Signed-off-by: Nicolas Saenz Julienne <nsaenzju@redhat.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Reviewed-by: Valentin Schneider <vschneid@redhat.com> Reviewed-by: Phil Auld <pauld@redhat.com> Link: https://lore.kernel.org/r/20220628092259.330171-1-nsaenzju@redhat.com
2022-07-21sched/deadline: Fix BUG_ON condition for deboosted tasksJuri Lelli1-1/+4
Tasks the are being deboosted from SCHED_DEADLINE might enter enqueue_task_dl() one last time and hit an erroneous BUG_ON condition: since they are not boosted anymore, the if (is_dl_boosted()) branch is not taken, but the else if (!dl_prio) is and inside this one we BUG_ON(!is_dl_boosted), which is of course false (BUG_ON triggered) otherwise we had entered the if branch above. Long story short, the current condition doesn't make sense and always leads to triggering of a BUG. Fix this by only checking enqueue flags, properly: ENQUEUE_REPLENISH has to be present, but additional flags are not a problem. Fixes: 64be6f1f5f71 ("sched/deadline: Don't replenish from a !SCHED_DEADLINE entity") Signed-off-by: Juri Lelli <juri.lelli@redhat.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Cc: stable@vger.kernel.org Link: https://lkml.kernel.org/r/20220714151908.533052-1-juri.lelli@redhat.com
2022-07-21drm/i915/selftests: Fix comment typoJason Wang1-1/+1
Fix the double `wait' typo in comment. Signed-off-by: Jason Wang <wangborong@cdjrlc.com> Reviewed-by: Andrzej Hajda <andrzej.hajda@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220716040520.31676-1-wangborong@cdjrlc.com
2022-07-21drm/i915/gt: Remove unneeded semicolonJason Wang1-1/+1
The semicolon after the `}' is unneeded. Signed-off-by: Jason Wang <wangborong@cdjrlc.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> [Removed line mention when pushing] Link: https://patchwork.freedesktop.org/patch/msgid/20220716184439.72056-1-wangborong@cdjrlc.com
2022-07-21dt-bindings: arm: aspeed: add Aspeed Evaluation boardsKrzysztof Kozlowski1-0/+3
Document the new compatibles used on Aspeed Evaluation boards. Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Acked-by: Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/20220529104928.79636-3-krzysztof.kozlowski@linaro.org
2022-07-21RDMA/rxe: Fix spelling mistake in error printZhang Jiaming1-1/+1
There is a spelling mistake (writeable) in function rxe_check_bind_mw. Fix it. Signed-off-by: Zhang Jiaming <jiaming@nfschina.com> Reviewed-by: Bob Pearson <rpearsonhpe@gmail.com> Signed-off-by: Leon Romanovsky <leon@kernel.org>
Copyright © 1996 – 2026 Jason A. Donenfeld. All Rights Reverse Engineered.