summaryrefslogtreecommitdiff
path: root/drivers
AgeCommit message (Collapse)Author
2021-06-22platform/x86: intel_skl_int3472: Fix dependencies (drop CLKDEV_LOOKUP)Andy Shevchenko
Besides the fact that COMMON_CLK selects CLKDEV_LOOKUP, the latter is going to be removed from clock framework. Reviewed-by: Daniel Scally <djrscally@gmail.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20210618125516.53510-3-andriy.shevchenko@linux.intel.com Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2021-06-22platform/x86: intel_skl_int3472: Free ACPI device resources after useAndy Shevchenko
We may free ACPI device resources immediately after use. Refactor skl_int3472_parse_crs() accordingly. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Daniel Scally <djrscally@gmail.com> Tested-by: Daniel Scally <djrscally@gmail.com> Link: https://lore.kernel.org/r/20210618125516.53510-2-andriy.shevchenko@linux.intel.com Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2021-06-22platform/x86: Remove "default n" entriesAndy Shevchenko
Linus already once did that for PDx86, don't repeat our mistakes. TL;DR: 'n' *is* the default 'default'. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20210618125516.53510-1-andriy.shevchenko@linux.intel.com Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2021-06-22Revert "drm: add a locked version of drm_is_current_master"Daniel Vetter
This reverts commit 1815d9c86e3090477fbde066ff314a7e9721ee0f. Unfortunately this inverts the locking hierarchy, so back to the drawing board. Full lockdep splat below: ====================================================== WARNING: possible circular locking dependency detected 5.13.0-rc7-CI-CI_DRM_10254+ #1 Not tainted ------------------------------------------------------ kms_frontbuffer/1087 is trying to acquire lock: ffff88810dcd01a8 (&dev->master_mutex){+.+.}-{3:3}, at: drm_is_current_master+0x1b/0x40 but task is already holding lock: ffff88810dcd0488 (&dev->mode_config.mutex){+.+.}-{3:3}, at: drm_mode_getconnector+0x1c6/0x4a0 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #2 (&dev->mode_config.mutex){+.+.}-{3:3}: __mutex_lock+0xab/0x970 drm_client_modeset_probe+0x22e/0xca0 __drm_fb_helper_initial_config_and_unlock+0x42/0x540 intel_fbdev_initial_config+0xf/0x20 [i915] async_run_entry_fn+0x28/0x130 process_one_work+0x26d/0x5c0 worker_thread+0x37/0x380 kthread+0x144/0x170 ret_from_fork+0x1f/0x30 -> #1 (&client->modeset_mutex){+.+.}-{3:3}: __mutex_lock+0xab/0x970 drm_client_modeset_commit_locked+0x1c/0x180 drm_client_modeset_commit+0x1c/0x40 __drm_fb_helper_restore_fbdev_mode_unlocked+0x88/0xb0 drm_fb_helper_set_par+0x34/0x40 intel_fbdev_set_par+0x11/0x40 [i915] fbcon_init+0x270/0x4f0 visual_init+0xc6/0x130 do_bind_con_driver+0x1e5/0x2d0 do_take_over_console+0x10e/0x180 do_fbcon_takeover+0x53/0xb0 register_framebuffer+0x22d/0x310 __drm_fb_helper_initial_config_and_unlock+0x36c/0x540 intel_fbdev_initial_config+0xf/0x20 [i915] async_run_entry_fn+0x28/0x130 process_one_work+0x26d/0x5c0 worker_thread+0x37/0x380 kthread+0x144/0x170 ret_from_fork+0x1f/0x30 -> #0 (&dev->master_mutex){+.+.}-{3:3}: __lock_acquire+0x151e/0x2590 lock_acquire+0xd1/0x3d0 __mutex_lock+0xab/0x970 drm_is_current_master+0x1b/0x40 drm_mode_getconnector+0x37e/0x4a0 drm_ioctl_kernel+0xa8/0xf0 drm_ioctl+0x1e8/0x390 __x64_sys_ioctl+0x6a/0xa0 do_syscall_64+0x39/0xb0 entry_SYSCALL_64_after_hwframe+0x44/0xae other info that might help us debug this: Chain exists of: &dev->master_mutex --> &client->modeset_mutex --> &dev->mode_config.mutex Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(&dev->mode_config.mutex); lock(&client->modeset_mutex); lock(&dev->mode_config.mutex); lock(&dev->master_mutex); *** DEADLOCK *** 1 lock held by kms_frontbuffer/1087: #0: ffff88810dcd0488 (&dev->mode_config.mutex){+.+.}-{3:3}, at: drm_mode_getconnector+0x1c6/0x4a0 stack backtrace: CPU: 7 PID: 1087 Comm: kms_frontbuffer Not tainted 5.13.0-rc7-CI-CI_DRM_10254+ #1 Hardware name: Intel Corporation Ice Lake Client Platform/IceLake U DDR4 SODIMM PD RVP TLC, BIOS ICLSFWR1.R00.3234.A01.1906141750 06/14/2019 Call Trace: dump_stack+0x7f/0xad check_noncircular+0x12e/0x150 __lock_acquire+0x151e/0x2590 lock_acquire+0xd1/0x3d0 __mutex_lock+0xab/0x970 drm_is_current_master+0x1b/0x40 drm_mode_getconnector+0x37e/0x4a0 drm_ioctl_kernel+0xa8/0xf0 drm_ioctl+0x1e8/0x390 __x64_sys_ioctl+0x6a/0xa0 do_syscall_64+0x39/0xb0 entry_SYSCALL_64_after_hwframe+0x44/0xae Note that this broke the intel-gfx CI pretty much across the board because it has to reboot machines after it hits a lockdep splat. Testcase: igt/debugfs_test/read_all_entries Acked-by: Petri Latvala <petri.latvala@intel.com> Fixes: 1815d9c86e30 ("drm: add a locked version of drm_is_current_master") Cc: Desmond Cheong Zhi Xi <desmondcheongzx@gmail.com> Cc: Emil Velikov <emil.l.velikov@gmail.com> Cc: stable@vger.kernel.org Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Maxime Ripard <mripard@kernel.org> Cc: Thomas Zimmermann <tzimmermann@suse.de> Cc: David Airlie <airlied@linux.ie> Cc: Daniel Vetter <daniel@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20210622075409.2673805-1-daniel.vetter@ffwll.ch
2021-06-22gpiolib: cdev: zero padding during conversion to gpioline_info_changedGabriel Knezek
When userspace requests a GPIO v1 line info changed event, lineinfo_watch_read() populates and returns the gpioline_info_changed structure. It contains 5 words of padding at the end which are not initialized before being returned to userspace. Zero the structure in gpio_v2_line_info_change_to_v1() before populating its contents. Fixes: aad955842d1c ("gpiolib: cdev: support GPIO_V2_GET_LINEINFO_IOCTL and GPIO_V2_GET_LINEINFO_WATCH_IOCTL") Signed-off-by: Gabriel Knezek <gabeknez@linux.microsoft.com> Reviewed-by: Kent Gibson <warthog618@gmail.com> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
2021-06-22RDMA/mlx5: Refactor get_ts_format functions to simplify codeAharon Landau
QPC, SQC and RQC timestamp formats and capabilities are always equal because they represent general hardware support. So instead of code duplication, let's merge them into general enum and logic. Signed-off-by: Aharon Landau <aharonl@nvidia.com> Reviewed-by: Maor Gottlieb <maorg@nvidia.com> Signed-off-by: Leon Romanovsky <leonro@nvidia.com>
2021-06-21ipmi: kcs_bmc_aspeed: Fix less than zero comparison of a unsigned intColin Ian King
The comparisons of the unsigned int hw_type to less than zero always false because it is unsigned. Fix this by using an int for the assignment and less than zero check. Addresses-Coverity: ("Unsigned compared against 0") Fixes: 9d2df9a0ad80 ("ipmi: kcs_bmc_aspeed: Implement KCS SerIRQ configuration") Signed-off-by: Colin Ian King <colin.king@canonical.com> Message-Id: <20210616162913.15259-1-colin.king@canonical.com> Signed-off-by: Corey Minyard <cminyard@mvista.com>
2021-06-21ipmi: kcs_bmc_aspeed: Optionally apply status addressAndrew Jeffery
Some Aspeed KCS devices can derive the status register address from the address of the data register. As such, the address of the status register can be implicit in the configuration if desired. On the other hand, sometimes address schemes might be requested that are incompatible with the default addressing scheme. Allow these requests where possible if the devicetree specifies the status register address. Signed-off-by: Andrew Jeffery <andrew@aj.id.au> Reviewed-by: Chia-Wei Wang <chiawei_wang@aspeedtech.com> Message-Id: <20210608104757.582199-17-andrew@aj.id.au> Signed-off-by: Corey Minyard <cminyard@mvista.com>
2021-06-21ipmi: kcs_bmc_aspeed: Fix IBFIE typo from datasheetAndrew Jeffery
Input Buffer Full Interrupt Enable (IBFIE) is typoed as IBFIF for some registers in the datasheet. Fix the driver to use the sensible acronym. Signed-off-by: Andrew Jeffery <andrew@aj.id.au> Reviewed-by: Zev Weiss <zweiss@equinix.com> Message-Id: <20210608104757.582199-16-andrew@aj.id.au> Signed-off-by: Corey Minyard <cminyard@mvista.com>
2021-06-21ipmi: kcs_bmc_aspeed: Implement KCS SerIRQ configurationAndrew Jeffery
Apply the SerIRQ ID and level/sense behaviours from the devicetree if provided. Signed-off-by: Andrew Jeffery <andrew@aj.id.au> Message-Id: <20210608104757.582199-15-andrew@aj.id.au> Signed-off-by: Corey Minyard <cminyard@mvista.com>
2021-06-21ipmi: kcs_bmc: Add serio adaptorAndrew Jeffery
kcs_bmc_serio acts as a bridge between the KCS drivers in the IPMI subsystem and the existing userspace interfaces available through the serio subsystem. This is useful when userspace would like to make use of the BMC KCS devices for purposes that aren't IPMI. Signed-off-by: Andrew Jeffery <andrew@aj.id.au> Message-Id: <20210608104757.582199-12-andrew@aj.id.au> Reviewed-by: Zev Weiss <zweiss@equinix.com> Signed-off-by: Corey Minyard <cminyard@mvista.com>
2021-06-21ipmi: kcs_bmc: Enable IBF on openAndrew Jeffery
This way devices don't get delivered IRQs when no-one is interested. Signed-off-by: Andrew Jeffery <andrew@aj.id.au> Message-Id: <20210608104757.582199-11-andrew@aj.id.au> Signed-off-by: Corey Minyard <cminyard@mvista.com>
2021-06-21ipmi: kcs_bmc: Allow clients to control KCS IRQ stateAndrew Jeffery
Add a mechanism for controlling whether the client associated with a KCS device will receive Input Buffer Full (IBF) and Output Buffer Empty (OBE) events. This enables an abstract implementation of poll() for KCS devices. A wart in the implementation is that the ASPEED KCS devices don't support an OBE interrupt for the BMC. Instead we pretend it has one by polling the status register waiting for the Output Buffer Full (OBF) bit to clear, and generating an event when OBE is observed. Cc: CS20 KWLiu <KWLIU@nuvoton.com> Signed-off-by: Andrew Jeffery <andrew@aj.id.au> Reviewed-by: Zev Weiss <zweiss@equinix.com> Message-Id: <20210608104757.582199-10-andrew@aj.id.au> Signed-off-by: Corey Minyard <cminyard@mvista.com>
2021-06-21ipmi: kcs_bmc: Decouple the IPMI chardev from the coreAndrew Jeffery
Now that we have untangled the data-structures, split the userspace interface out into its own module. Userspace interfaces and drivers are registered to the KCS BMC core to support arbitrary binding of either. Signed-off-by: Andrew Jeffery <andrew@aj.id.au> Message-Id: <20210608104757.582199-9-andrew@aj.id.au> Reviewed-by: Zev Weiss <zweiss@equinix.com> Signed-off-by: Corey Minyard <cminyard@mvista.com>
2021-06-21ipmi: kcs_bmc: Strip private client data from struct kcs_bmcAndrew Jeffery
Move all client-private data out of `struct kcs_bmc` into the KCS client implementation. With this change the KCS BMC core code now only concerns itself with abstract `struct kcs_bmc` and `struct kcs_bmc_client` types, achieving expected separation of concerns. Further, the change clears the path for implementation of alternative userspace interfaces. The chardev data-structures are rearranged in the same manner applied to the KCS device driver data-structures in an earlier patch - `struct kcs_bmc_client` is embedded in the client's private data and we exploit container_of() to translate as required. Finally, now that it is free of client data, `struct kcs_bmc` is renamed to `struct kcs_bmc_device` to contrast `struct kcs_bmc_client`. Signed-off-by: Andrew Jeffery <andrew@aj.id.au> Reviewed-by: Zev Weiss <zweiss@equinix.com> Message-Id: <20210608104757.582199-8-andrew@aj.id.au> Signed-off-by: Corey Minyard <cminyard@mvista.com>
2021-06-21ipmi: kcs_bmc: Split headers into device and clientAndrew Jeffery
Strengthen the distinction between code that abstracts the implementation of the KCS behaviours (device drivers) and code that exploits KCS behaviours (clients). Neither needs to know about the APIs required by the other, so provide separate headers. Signed-off-by: Andrew Jeffery <andrew@aj.id.au> Message-Id: <20210608104757.582199-7-andrew@aj.id.au> Reviewed-by: Zev Weiss <zweiss@equinix.com> Signed-off-by: Corey Minyard <cminyard@mvista.com>
2021-06-21ipmi: kcs_bmc: Turn the driver data-structures inside-outAndrew Jeffery
Make the KCS device drivers responsible for allocating their own memory. Until now the private data for the device driver was allocated internal to the private data for the chardev interface. This coupling required the slightly awkward API of passing through the struct size for the driver private data to the chardev constructor, and then retrieving a pointer to the driver private data from the allocated chardev memory. In addition to being awkward, the arrangement prevents the implementation of alternative userspace interfaces as the device driver private data is not independent. Peel a layer off the onion and turn the data-structures inside out by exploiting container_of() and embedding `struct kcs_device` in the driver private data. Signed-off-by: Andrew Jeffery <andrew@aj.id.au> Reviewed-by: Zev Weiss <zweiss@equinix.com> Message-Id: <20210608104757.582199-6-andrew@aj.id.au> Signed-off-by: Corey Minyard <cminyard@mvista.com>
2021-06-21ipmi: kcs_bmc: Split out kcs_bmc_cdev_ipmiAndrew Jeffery
Take steps towards defining a coherent API to separate the KCS device drivers from the userspace interface. Decreasing the coupling will improve the separation of concerns and enable the introduction of alternative userspace interfaces. For now, simply split the chardev logic out to a separate file. The code continues to build into the same module. Signed-off-by: Andrew Jeffery <andrew@aj.id.au> Reviewed-by: Zev Weiss <zweiss@equinix.com> Message-Id: <20210608104757.582199-5-andrew@aj.id.au> Signed-off-by: Corey Minyard <cminyard@mvista.com>
2021-06-21ipmi: kcs_bmc: Rename {read,write}_{status,data}() functionsAndrew Jeffery
Rename the functions in preparation for separating the IPMI chardev out from the KCS BMC core. Signed-off-by: Andrew Jeffery <andrew@aj.id.au> Reviewed-by: Zev Weiss <zweiss@equinix.com> Message-Id: <20210608104757.582199-4-andrew@aj.id.au> Signed-off-by: Corey Minyard <cminyard@mvista.com>
2021-06-21ipmi: kcs_bmc: Make status update atomicAndrew Jeffery
Enable more efficient implementation of read-modify-write sequences. Both device drivers for the KCS BMC stack use regmaps. The new callback allows us to exploit regmap_update_bits(). Signed-off-by: Andrew Jeffery <andrew@aj.id.au> Reviewed-by: Zev Weiss <zweiss@equinix.com> Message-Id: <20210608104757.582199-3-andrew@aj.id.au> Signed-off-by: Corey Minyard <cminyard@mvista.com>
2021-06-21ipmi: kcs_bmc_aspeed: Use of match data to extract KCS propertiesAndrew Jeffery
Unpack and remove the aspeed_kcs_probe_of_v[12]() functions to aid rearranging how the private device-driver memory is allocated. Signed-off-by: Andrew Jeffery <andrew@aj.id.au> Message-Id: <20210608104757.582199-2-andrew@aj.id.au> Reviewed-by: Zev Weiss <zweiss@equinix.com> Signed-off-by: Corey Minyard <cminyard@mvista.com>
2021-06-21RDMA/rxe: Don't overwrite errno from ib_umem_get()Xiao Yang
rxe_mr_init_user() always returns the fixed -EINVAL when ib_umem_get() fails so it's hard for user to know which actual error happens in ib_umem_get(). For example, ib_umem_get() will return -EOPNOTSUPP when trying to pin pages on a DAX file. Return actual error as mlx4/mlx5 does. Link: https://lore.kernel.org/r/20210621071456.4259-1-ice_yangxiao@163.com Signed-off-by: Xiao Yang <yangx.jy@fujitsu.com> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
2021-06-21IB/mlx4: Avoid field-overflowing memcpy()Kees Cook
In preparation for FORTIFY_SOURCE performing compile-time and run-time field bounds checking for memcpy(), memmove(), and memset(), avoid intentionally writing across neighboring array fields. Use the ether_addr_copy() helper instead, as already done for smac. Link: https://lore.kernel.org/r/20210616203744.1248551-1-keescook@chromium.org Signed-off-by: Kees Cook <keescook@chromium.org> Reviewed-by: Leon Romanovsky <leonro@nvidia.com> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
2021-06-21rnbd/rtrs-clt: Query and use max_segments from rtrs-clt.Jack Wang
With fast memory registration on write request, rnbd-clt can do bigger IO without split. rnbd-clt now can query rtrs-clt to get the max_segments, instead of using BMAX_SEGMENTS. BMAX_SEGMENTS is not longer needed, so remove it. Link: https://lore.kernel.org/r/20210621055340.11789-6-jinpu.wang@ionos.com Cc: Jens Axboe <axboe@kernel.dk> Signed-off-by: Jack Wang <jinpu.wang@cloud.ionos.com> Reviewed-by: Md Haris Iqbal <haris.iqbal@cloud.ionos.com> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
2021-06-21RDMA/rtrs-clt: Raise MAX_SEGMENTSJack Wang
As we can do fast memory registration on write, we can increase the max_segments, default to 512K. Link: https://lore.kernel.org/r/20210621055340.11789-5-jinpu.wang@ionos.com Signed-off-by: Jack Wang <jinpu.wang@cloud.ionos.com> Reviewed-by: Md Haris Iqbal <haris.iqbal@cloud.ionos.com> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
2021-06-21RDMA/rtrs_clt: Alloc less memory with write path fast memory registrationJack Wang
With write path fast memory registration, we need less memory for each request. With fast memory registration, we can reduce max_send_sge to save memory usage. Also convert the kmalloc_array to kcalloc. Link: https://lore.kernel.org/r/20210621055340.11789-4-jinpu.wang@ionos.com Signed-off-by: Jack Wang <jinpu.wang@cloud.ionos.com> Reviewed-by: Md Haris Iqbal <haris.iqbal@cloud.ionos.com> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
2021-06-21RDMA/rtrs-clt: Write path fast memory registrationJack Wang
With fast memory registration in write path, we can reduce the memory consumption by using less max_send_sge, support IO bigger than 116 KB (29 segments * 4 KB) without splitting, and it also make the IO path more symmetric. To avoid some times MR reg failed, waiting for the invalidation to finish before the new mr reg. Introduce a refcount, only finish the request when both local invalidation and io reply are there. Link: https://lore.kernel.org/r/20210621055340.11789-3-jinpu.wang@ionos.com Signed-off-by: Jack Wang <jinpu.wang@cloud.ionos.com> Signed-off-by: Md Haris Iqbal <haris.iqbal@ionos.com> Signed-off-by: Dima Stepanov <dmitrii.stepanov@ionos.com> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
2021-06-21RDMA/rtrs: Introduce head/tail wrJack Wang
Introduce tail wr, we can send as the last wr, we want to send the local invalidate wr after rdma wr in later patch. While at it, also fix coding style issue. Link: https://lore.kernel.org/r/20210621055340.11789-2-jinpu.wang@ionos.com Signed-off-by: Jack Wang <jinpu.wang@cloud.ionos.com> Reviewed-by: Md Haris Iqbal <haris.iqbal@cloud.ionos.com> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
2021-06-21RDMA/bnxt_re: Update ABI to pass wqe-mode to user spaceDevesh Sharma
Changing ucontext ABI response structure to pass wqe_mode to user library. A flag in comp_mask has been set to indicate presence of wqe_mode. Moved wqe-mode ABI to uapi/rdma/bnxt_re-abi.h Link: https://lore.kernel.org/r/20210616202817.1185276-1-devesh.sharma@broadcom.com Signed-off-by: Devesh Sharma <devesh.sharma@broadcom.com> Reviewed-by: Leon Romanovsky <leonro@nvidia.com> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
2021-06-21IB/core: Removed port validity check from ib_get_cached_subnet_prefixAnand Khoje
Removed port validity check from ib_get_cached_subnet_prefix() as this check is not needed because "port_num" is valid. Link: https://lore.kernel.org/r/20210616154509.1047-2-anand.a.khoje@oracle.com Suggested-by: Leon Romanovsky <leonro@nvidia.com> Signed-off-by: Anand Khoje <anand.a.khoje@oracle.com> Signed-off-by: Haakon Bugge <haakon.bugge@oracle.com> Reviewed-by: Leon Romanovsky <leonro@nvidia.com> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
2021-06-21RDMA: Fix kernel-doc warnings about wrong commentLeon Romanovsky
Compilation with W=1 produces warnings similar to the below. drivers/infiniband/ulp/ipoib/ipoib_main.c:320: warning: This comment starts with '/**', but isn't a kernel-doc comment. Refer Documentation/doc-guide/kernel-doc.rst All such occurrences were found with the following one line git grep -A 1 "\/\*\*" drivers/infiniband/ Link: https://lore.kernel.org/r/e57d5f4ddd08b7a19934635b44d6d632841b9ba7.1623823612.git.leonro@nvidia.com Reviewed-by: Jack Wang <jinpu.wang@ionos.com> #rtrs Reviewed-by: Dennis Dalessandro <dennis.dalessandro@cornelisnetworks.com> Signed-off-by: Leon Romanovsky <leonro@nvidia.com> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
2021-06-21ibmvnic: Use strscpy() instead of strncpy()Kees Cook
Since these strings are expected to be NUL-terminated and the buffers are exactly sized (in vnic_client_data_len()) with no padding, strncpy() can be safely replaced with strscpy() here, as strncpy() on NUL-terminated string is considered deprecated[1]. This has the side-effect of silencing a -Warray-bounds warning due to the compiler being confused about the vlcd incrementing: In file included from ./include/linux/string.h:253, from ./include/linux/bitmap.h:10, from ./include/linux/cpumask.h:12, from ./include/linux/mm_types_task.h:14, from ./include/linux/mm_types.h:5, from ./include/linux/buildid.h:5, from ./include/linux/module.h:14, from drivers/net/ethernet/ibm/ibmvnic.c:35: In function '__fortify_strncpy', inlined from 'vnic_add_client_data' at drivers/net/ethernet/ibm/ibmvnic.c:3919:2: ./include/linux/fortify-string.h:39:30: warning: '__builtin_strncpy' offset 12 from the object at 'v lcd' is out of the bounds of referenced subobject 'name' with type 'char[]' at offset 12 [-Warray-bo unds] 39 | #define __underlying_strncpy __builtin_strncpy | ^ ./include/linux/fortify-string.h:51:9: note: in expansion of macro '__underlying_strncpy' 51 | return __underlying_strncpy(p, q, size); | ^~~~~~~~~~~~~~~~~~~~ drivers/net/ethernet/ibm/ibmvnic.c: In function 'vnic_add_client_data': drivers/net/ethernet/ibm/ibmvnic.c:3883:7: note: subobject 'name' declared here 3883 | char name[]; | ^~~~ [1] https://www.kernel.org/doc/html/latest/process/deprecated.html#strncpy-on-nul-terminated-strings Cc: Dany Madden <drt@linux.ibm.com> Cc: Sukadev Bhattiprolu <sukadev@linux.ibm.com> Cc: Thomas Falcon <tlfalcon@linux.ibm.com> Cc: Michael Ellerman <mpe@ellerman.id.au> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Cc: Paul Mackerras <paulus@samba.org> Cc: "David S. Miller" <davem@davemloft.net> Cc: Jakub Kicinski <kuba@kernel.org> Cc: netdev@vger.kernel.org Cc: linuxppc-dev@lists.ozlabs.org Signed-off-by: Kees Cook <keescook@chromium.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-06-21vfio/iommu_type1: rename vfio_group struck to vfio_iommu_groupMax Gurtovoy
The vfio_group structure is already defined in vfio module so in order to improve code readability and for simplicity, rename the vfio_group structure in vfio_iommu_type1 module to vfio_iommu_group. Signed-off-by: Max Gurtovoy <mgurtovoy@nvidia.com> Link: https://lore.kernel.org/r/20210608112841.51897-1-mgurtovoy@nvidia.com Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
2021-06-21net: dsa: mv88e6xxx: Fix adding vlan 0Eldar Gasanov
8021q module adds vlan 0 to all interfaces when it starts. When 8021q module is loaded it isn't possible to create bond with mv88e6xxx interfaces, bonding module dipslay error "Couldn't add bond vlan ids", because it tries to add vlan 0 to slave interfaces. There is unexpected behavior in the switch. When a PVID is assigned to a port the switch changes VID to PVID in ingress frames with VID 0 on the port. Expected that the switch doesn't assign PVID to tagged frames with VID 0. But there isn't a way to change this behavior in the switch. Fixes: 57e661aae6a8 ("net: dsa: mv88e6xxx: Link aggregation support") Signed-off-by: Eldar Gasanov <eldargasanov2@gmail.com> Reviewed-by: Vladimir Oltean <olteanv@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-06-21drm/amd/display: Fix edp_bootup_bl_level initialization issueLogush Oliver
[why] Updating the file to fix the missing line Signed-off-by: Logush Oliver <ollogush@amd.com> Reviewed-by: Charlene Liu <Charlene.Liu@amd.com> Acked-by: Bindu Ramamurthy <bindu.r@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2021-06-21drm/amd/display: get refclk from MICROSECOND_TIME_BASE_DIV HW registerCharlene Liu
[why] recent VBIOS dce_infotable reference clock change caused a I2c regression. instead of relying on vbios, let's get it from HW directly. Signed-off-by: Charlene Liu <Charlene.Liu@amd.com> Reviewed-by: Chris Park <Chris.Park@amd.com> Reviewed-by: Nicholas Kazlauskas <Nicholas.Kazlauskas@amd.com> Acked-by: Bindu Ramamurthy <bindu.r@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2021-06-21drm/amd/display: Delay PSR entryRoman Li
[Why] After panel power up, if PSR entry attempted too early, PSR state may get stuck in transition. This could happen if the panel is not ready to respond to the SDP PSR entry message. In this case dmub f/w is unable to abort PSR entry since abortion is not permitted after the SDP has been sent. [How] Skip 5 pageflips before PSR enable. Signed-off-by: Roman Li <roman.li@amd.com> Reviewed-by: Hersen Wu <hersenxs.wu@amd.com> Acked-by: Bindu Ramamurthy <bindu.r@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2021-06-21drm/amd/display: get socBB from VBIOS for dcn302 and dcn303Aurabindo Pillai
[why] Some SOC BB paramters may vary per SKU, and it does not make sense for driver to hardcode these values. This change was added for dcn30 and dcn301, but not for dcn302 and dcn303 [how] Parse the values from VBIOS if available, and use them if valid Fixes: 93669c8e480dca ("drm/amd/display: get socBB from VBIOS") Signed-off-by: Aurabindo Pillai <aurabindo.pillai@amd.com> Reviewed-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com> Acked-by: Alex Deucher <alexander.deucher@amd.com> Acked-by: Bindu Ramamurthy <bindu.r@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2021-06-21drm/amd/display: Fix incorrect variable nameWesley Chalmers
[WHY] extended_end_address can only be calculated from the extended_address and extended_size Signed-off-by: Wesley Chalmers <Wesley.Chalmers@amd.com> Reviewed-by: Ashley Thomas <Ashley.Thomas2@amd.com> Acked-by: Bindu Ramamurthy <bindu.r@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2021-06-21drm/amd/display: Clear lane settings after LTTPRs have been trainedMartin Tsai
[Why] The voltage swing has to start from the minimum level when transmit TPS1 over Main-Link in clock recovery sequence. The lane settings from current design will inherit the existing VS/PE values that could be adjusted by Repeater X, and to use the adjusted voltage swing level in Repeater X-1 or DPRX could violate DP specs. [How] To reset VS from lane settings after LTTPRs have been trained to meet the requirement. Signed-off-by: Martin Tsai <martin.tsai@amd.com> Reviewed-by: Wenjing Liu <Wenjing.Liu@amd.com> Acked-by: Bindu Ramamurthy <bindu.r@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2021-06-21drm/amd/display: Clamp VStartup value at DML calculations timeNikola Cornij
[why] Some timings with a large VBlank cause the value to overflow the register related, while also producing other wrong values in DML output. [how] Clamp VStartup at the DCN3.1 maximum value Signed-off-by: Nikola Cornij <nikola.cornij@amd.com> Reviewed-by: Dmytro Laktyushkin <Dmytro.Laktyushkin@amd.com> Acked-by: Bindu Ramamurthy <bindu.r@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2021-06-21drm/amd/display: Multiplane cursor position incorrect when plane rotatedAric Cyr
[Why] When video plane is rotate the cursor position is incorrect and not matching the desktop location. [How] When a plane is rotated 90 or 270 degrees, the src_rect.width and height should be swapped when determining the scaling factor compared to the dst_rect. Signed-off-by: Aric Cyr <aric.cyr@amd.com> Reviewed-by: Jun Lei <Jun.Lei@amd.com> Acked-by: Bindu Ramamurthy <bindu.r@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2021-06-21Revert "drm/amdgpu/gfx9: fix the doorbell missing when in CGPG issue."Yifan Zhang
This reverts commit 631003101c516ea29a74aee59666708857b9a805. Reason for revert: side effect of enlarging CP_MEC_DOORBELL_RANGE may cause some APUs fail to enter gfxoff in certain user cases. Signed-off-by: Yifan Zhang <yifan1.zhang@amd.com> Acked-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2021-06-21net: ll_temac: Remove left-over debug messageEsben Haabendal
Fixes: f63963411942 ("net: ll_temac: Avoid ndo_start_xmit returning NETDEV_TX_BUSY") Signed-off-by: Esben Haabendal <esben@geanix.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-06-21Revert "drm/amdgpu/gfx10: enlarge CP_MEC_DOORBELL_RANGE_UPPER to cover full ↵Yifan Zhang
doorbell." This reverts commit 1ba7b24ba68e7c04b1e67d986d02b966b4eaaaa0. Reason for revert: Side effect of enlarging CP_MEC_DOORBELL_RANGE may cause some APUs fail to enter gfxoff in certain user cases. Signed-off-by: Yifan Zhang <yifan1.zhang@amd.com> Acked-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2021-06-21net: mana: Fix a memory leak in an error handling path in 'mana_create_txq()'Christophe JAILLET
If this test fails we must free some resources as in all the other error handling paths of this function. Fixes: ca9c54d2d6a5 ("net: mana: Add a driver for Microsoft Azure Network Adapter (MANA)") Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Reviewed-by: Dexuan Cui <decui@microsoft.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-06-21net: hns3: Fix a memory leak in an error handling path in ↵Christophe JAILLET
'hclge_handle_error_info_log()' If this 'kzalloc()' fails we must free some resources as in all the other error handling paths of this function. Fixes: 2e2deee7618b ("net: hns3: add the RAS compatibility adaptation solution") Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Reviewed-by: Jiaran Zhang <zhangjiaran@huawei.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-06-21Merge branch 'hch-mdev-direct-v4' into v5.14/vfio/nextAlex Williamson
2021-06-21vfio/mdev: Allow the mdev_parent_ops to specify the device driver to bindJason Gunthorpe
This allows a mdev driver to opt out of using vfio_mdev.c, instead the driver will provide a 'struct mdev_driver' and register directly with the driver core. Much of mdev_parent_ops becomes unused in this mode: - create()/remove() are done via the mdev_driver probe()/remove() - mdev_attr_groups becomes mdev_driver driver.dev_groups - Wrapper function callbacks are replaced with the same ones from struct vfio_device_ops Signed-off-by: Jason Gunthorpe <jgg@nvidia.com> Signed-off-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Cornelia Huck <cohuck@redhat.com> Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Reviewed-by: Kirti Wankhede <kwankhede@nvidia.com> Link: https://lore.kernel.org/r/20210617142218.1877096-8-hch@lst.de Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
2021-06-21vfio/mdev: Remove CONFIG_VFIO_MDEV_DEVICEJason Gunthorpe
For some reason the vfio_mdev shim mdev_driver has its own module and kconfig. As the next patch requires access to it from mdev.ko merge the two modules together and remove VFIO_MDEV_DEVICE. A later patch deletes this driver entirely. Signed-off-by: Jason Gunthorpe <jgg@nvidia.com> Signed-off-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Cornelia Huck <cohuck@redhat.com> Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Reviewed-by: Kirti Wankhede <kwankhede@nvidia.com> Link: https://lore.kernel.org/r/20210617142218.1877096-7-hch@lst.de Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
generated by cgit (git 2.34.1) at 2025-09-21 06:35:13 +0000