aboutsummaryrefslogtreecommitdiffstats
path: root/drivers
AgeCommit message (Collapse)AuthorFilesLines
2021-05-26Input: cyttsp - probe from compatiblesLinus Walleij2-0/+16
The driver (both SPI and I2C interface) should probe from the compatible strings, cypress,cy8ctma340 etc when using device tree, not as now, where it is probing implicitly from the I2C/SPI node name "cypress,cyttsp-i2c" etc. Reviewed-by: Javier Martinez Canillas <javier@dowhile0.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/20210526230352.1433537-2-linus.walleij@linaro.org Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
2021-05-26i40e: Replace one-element array with flexible-array memberGustavo A. R. Silva2-4/+3
There is a regular need in the kernel to provide a way to declare having a dynamically sized set of trailing elements in a structure. Kernel code should always use “flexible array members”[1] for these cases. The older style of one-element or zero-length arrays should no longer be used[2]. Refactor the code according to the use of a flexible-array member in struct i40e_qvlist_info instead of one-element array, and use the struct_size() helper. [1] https://en.wikipedia.org/wiki/Flexible_array_member [2] https://www.kernel.org/doc/html/v5.10/process/deprecated.html#zero-length-and-one-element-arrays Link: https://github.com/KSPP/linux/issues/79 Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org> Acked-by: Shiraz Saleem <shiraz.saleem@intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2021-05-26firmware: arm_ffa: Add support for MEM_* interfacesSudeep Holla1-0/+199
Most of the MEM_* APIs share the same parameters, so they can be generalised. Currently only MEM_SHARE is implemented and the user space interface for that is not added yet. Link: https://lore.kernel.org/r/20210521151033.181846-6-sudeep.holla@arm.com Tested-by: Jens Wiklander <jens.wiklander@linaro.org> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2021-05-26firmware: arm_ffa: Setup in-kernel users of FFA partitionsSudeep Holla3-0/+233
Parse the FFA nodes from the device-tree and register all the partitions whose services will be used in the kernel. In order to also enable in-kernel users of FFA interface, let us add simple set of operations for such devices. The in-kernel users are registered without the character device interface. Link: https://lore.kernel.org/r/20210521151033.181846-5-sudeep.holla@arm.com Tested-by: Jens Wiklander <jens.wiklander@linaro.org> Reviewed-by: Jens Wiklander <jens.wiklander@linaro.org> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2021-05-26firmware: arm_ffa: Add support for SMCCC as transport to FFA driverSudeep Holla4-1/+50
There are requests to keep the transport separate in order to allow other possible transports like virtio. So let us keep the SMCCC transport specific routines abstracted. It is kept simple for now. Once we add another transport, we can develop better abstraction. Link: https://lore.kernel.org/r/20210521151033.181846-4-sudeep.holla@arm.com Tested-by: Jens Wiklander <jens.wiklander@linaro.org> Reviewed-by: Jens Wiklander <jens.wiklander@linaro.org> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2021-05-26firmware: arm_ffa: Add initial Arm FFA driver supportSudeep Holla4-11/+341
This just add a basic driver that sets up the transport(e.g. SMCCC), checks the FFA version implemented, get the partition ID for self and sets up the Tx/Rx buffers for communication. Link: https://lore.kernel.org/r/20210521151033.181846-3-sudeep.holla@arm.com Tested-by: Jens Wiklander <jens.wiklander@linaro.org> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2021-05-26firmware: arm_ffa: Add initial FFA bus support for device enumerationSudeep Holla5-0/+229
The Arm FF for Armv8-A specification has concept of endpoints or partitions. In the Normal world, a partition could be a VM when the Virtualization extension is enabled or the kernel itself. In order to handle multiple partitions, we can create a FFA device for each such partition on a dedicated FFA bus. Similarly, different drivers requiring FFA transport can be registered on the same bus. We can match the device and drivers using UUID. This is mostly for the in-kernel users with FFA drivers. Link: https://lore.kernel.org/r/20210521151033.181846-2-sudeep.holla@arm.com Tested-by: Jens Wiklander <jens.wiklander@linaro.org> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2021-05-26spi: Enable tracing of the SPI setup CS selectionAndy Shevchenko1-0/+4
It is helpful to see what state of CS signal was during one or another SPI operation. All the same for SPI setup. Enable tracing of the SPI setup and CS selection. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Message-Id: <20210526195655.75691-1-andriy.shevchenko@linux.intel.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2021-05-26nfc: st-nci: remove unnecessary labelswengjianfeng1-10/+5
Some labels are only used once, so we delete them and use the return statement instead of the goto statement. Signed-off-by: wengjianfeng <wengjianfeng@yulong.com> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> Link: https://lore.kernel.org/r/20210526011624.11204-1-samirweng1979@163.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2021-05-26nfc: st95hf: remove unnecessary assignment and labelwengjianfeng1-5/+2
In function st95hf_in_send_cmd, the variable rc is assigned then goto error label, which just returns rc, so we use return to replace it. Since error label only used once in the function, so we remove error label. Signed-off-by: wengjianfeng <wengjianfeng@yulong.com> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> Link: https://lore.kernel.org/r/20210526005651.12652-1-samirweng1979@163.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2021-05-26RDMA/mlx5: Take qp type from mlx5_ib_qpMaor Gottlieb5-36/+31
Change all the places in the mlx5_ib driver to take the qp type from the mlx5_ib_qp struct, except the QP initialization flow. It will ensure that we check the right QP type also for vendor specific QPs. Link: https://lore.kernel.org/r/b2e16cd65b59cd24fa81c01c7989248da44e58ea.1621413899.git.leonro@nvidia.com Signed-off-by: Maor Gottlieb <maorg@nvidia.com> Signed-off-by: Leon Romanovsky <leonro@nvidia.com> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
2021-05-26fbdev: matrox: use modern module_init()Arnd Bergmann1-3/+2
This is one of the last drivers with a global init_module() function instead of the modern module_init() annotation. Convert it over. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patchwork.freedesktop.org/patch/msgid/20210514213316.635070-1-arnd@kernel.org
2021-05-26drm/fb-helper: improve DRM fbdev emulation device namesJavier Martinez Canillas1-1/+1
Framebuffer devices that are registered by DRM drivers for fbdev emulation have a "drmfb" suffix in their name. But makes them to be quite confusing for drivers that already have "drm" in their name: $ cat /proc/fb 0 rockchipdrmdrmfb $ cat /proc/fb 0 simpledrmdrmfb Also, there isn't a lot of value in adding these "drmfb" suffices to their names, since users shouldn't really care if the FB devices were registered by a real fbdev driver or a DRM driver using the fbdev emulation. What programs should be interested about is if there's a DRM device, and there are better ways to query that info than reading this procfs entry. So let's just remove the suffix, which leads to much better device names: $ cat /proc/fb 0 rockchipdrm $ cat /proc/fb 0 simpledrm Suggested-by: Thomas Zimmermann <tzimmermann@suse.de> Signed-off-by: Javier Martinez Canillas <javierm@redhat.com> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patchwork.freedesktop.org/patch/msgid/20210525151313.3379622-1-javierm@redhat.com
2021-05-26drm/hisilicon/kirin: Use the correct HiSilicon copyrightHao Fang6-6/+6
s/Hisilicon/HiSilicon/. It should use capital S, according to https://www.hisilicon.com/en. Signed-off-by: Hao Fang <fanghao11@huawei.com> Acked-by: Tian Tao <tiantao6@hisilicon.com> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patchwork.freedesktop.org/patch/msgid/1621678529-14389-1-git-send-email-fanghao11@huawei.com
2021-05-26drm: fix leaked dma handles after removing drm_pci_freeJoseph Kogut2-0/+3
After removing drm_pci_alloc/free, some instances where drm_pci_free() would have kfreed the dma handle were skipped. Ensure these handles are freed properly. Signed-off-by: Joseph Kogut <joseph.kogut@gmail.com> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patchwork.freedesktop.org/patch/msgid/20210518212859.4148903-1-joseph.kogut@gmail.com
2021-05-26drm/kconfig: Remove unused select of DRM_KMS_FB_HELPERThomas Zimmermann1-1/+0
The option DRM_KMS_FB_HELPER has been removed. Also remove the last remaining select statement for it. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Fixes: 91185d55b32e ("drm: Remove DRM_KMS_FB_HELPER Kconfig option") Acked-by: Maxime Ripard <maxime@cerno.tech> Reported-by: Geert Uytterhoeven <geert@linux-m68k.org> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Maxime Ripard <mripard@kernel.org> Cc: David Airlie <airlied@linux.ie> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: dri-devel@lists.freedesktop.org Link: https://patchwork.freedesktop.org/patch/msgid/20210526100825.29450-1-tzimmermann@suse.de
2021-05-26drm/ttm: Remove ttm_bo_mmap() and friendsThomas Zimmermann1-53/+0
The function ttm_bo_mmap is unused. Remove it and it's helpers; including the verify_access callback in struct ttm_device_funcs. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Christian König <christian.koenig@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210525151055.8174-8-tzimmermann@suse.de
2021-05-26drm/vmwgfx: Inline vmw_verify_access()Thomas Zimmermann2-14/+2
Vmwgfx is the only user of the TTM's verify_access callback. Inline the call and avoid the indirection through the function pointer. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Zack Rusin <zackr@vmware.com> Acked-by: Christian König <christian.koenig@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210525151055.8174-7-tzimmermann@suse.de
2021-05-26drm/vmwgfx: Inline ttm_bo_mmap() into vmwgfx driverThomas Zimmermann1-3/+53
The vmwgfx driver is the only remaining user of ttm_bo_mmap(). Inline the code. The internal helper ttm_bo_vm_lookup() is now also part of vmwgfx as vmw_bo_vm_lookup(). v2: * replace pr_err() with drm_err() (Zack) Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Zack Rusin <zackr@vmware.com> Acked-by: Christian König <christian.koenig@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210525151055.8174-6-tzimmermann@suse.de
2021-05-26drm/nouveau: Implement mmap as GEM object functionThomas Zimmermann5-61/+38
Moving the driver-specific mmap code into a GEM object function allows for using DRM helpers for various mmap callbacks. The GEM object function is provided by GEM TTM helpers. Nouveau's implementation of verify_access is unused and has been removed. Access permissions are validated by the DRM helpers. As a side effect, nouveau_ttm_vm_ops and nouveau_ttm_fault() are now implemented in nouveau's GEM code. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Christian König <christian.koenig@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210525151055.8174-5-tzimmermann@suse.de
2021-05-26drm/radeon: Implement mmap as GEM object functionThomas Zimmermann4-67/+51
Moving the driver-specific mmap code into a GEM object function allows for using DRM helpers for various mmap callbacks. This change also allows to support prime-based mmap via DRM's helper drm_gem_prime_mmap(). Permission checks are implemented by drm_gem_mmap(), with an additional check for radeon_ttm_tt_has_userptr() in the GEM object function. The function radeon_verify_access() is now unused and has thus been removed. As a side effect, radeon_ttm_vm_ops and radeon_ttm_fault() are now implemented in amdgpu's GEM code. v3: * remove unnecessary checks from mmap (Christian) v2: * rename radeon_ttm_vm_ops and radeon_ttm_fault() to radeon_gem_vm_ops and radeon_gem_fault() (Christian) * fix commit description (Alex) Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Christian König <christian.koenig@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210525151055.8174-4-tzimmermann@suse.de
2021-05-26drm/amdgpu: Implement mmap as GEM object functionThomas Zimmermann6-126/+57
Moving the driver-specific mmap code into a GEM object function allows for using DRM helpers for various mmap callbacks. This change resolves several inconsistencies between regular mmap and prime-based mmap. The vm_ops field in vma is now set for all mmap'ed areas. Previously it way only set for regular mmap calls, prime-based mmap used TTM's default vm_ops. The function amdgpu_verify_access() is no longer being called and therefore removed by this patch. As a side effect, amdgpu_ttm_vm_ops and amdgpu_ttm_fault() are now implemented in amdgpu's GEM code. v4: * rebased v3: * rename mmap function to amdgpu_gem_object_mmap() (Christian) * remove unnecessary checks from mmap (Christian) v2: * rename amdgpu_ttm_vm_ops and amdgpu_ttm_fault() to amdgpu_gem_vm_ops and amdgpu_gem_fault() (Christian) * the check for kfd_bo has meanwhile been removed Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Christian König <christian.koenig@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210525151055.8174-3-tzimmermann@suse.de
2021-05-26drm/ttm: Don't override vm_ops callbacks, if setThomas Zimmermann1-1/+6
Drivers may want to set their own callbacks for a VM area. Only set TTM's callbacks if the vm_ops field is clear. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Christian König <christian.koenig@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210525151055.8174-2-tzimmermann@suse.de
2021-05-26regulator: rk808: Convert to use regulator_set_ramp_delay_regmapAxel Lin1-65/+51
Use regulator_set_ramp_delay_regmap instead of open-coded. Signed-off-by: Axel Lin <axel.lin@ingics.com> Message-Id: <20210525141203.2562884-1-axel.lin@ingics.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2021-05-26cxl/mem: Get rid of @cxlm.baseBen Widawsky2-15/+11
@cxlm.base only existed to support holding the base found in the register block mapping code, and pass it along to the register setup code. Now that the register setup function has all logic around managing the registers, from DVSEC to iomapping up to populating our CXL specific information, it is easy to turn the @base values into local variables and remove them from our device driver state. Acked-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Signed-off-by: Ben Widawsky <ben.widawsky@intel.com> Link: https://lore.kernel.org/r/20210520212953.1181695-1-ben.widawsky@intel.com Signed-off-by: Dan Williams <dan.j.williams@intel.com>
2021-05-26cxl/mem: Move register locator logic into reg setupBen Widawsky1-67/+68
Start moving code around to ultimately get rid of @cxlm.base. The @cxlm.base member serves no purpose other than intermediate storage of the offset found in cxl_mem_map_regblock() later used by cxl_mem_setup_regs(). Aside from wanting to get rid of this useless member, it will help later when adding new register block identifiers. While @cxlm.base still exists, it will become trivial to remove it in a future patch. No functional change is meant to be introduced in this patch. Signed-off-by: Ben Widawsky <ben.widawsky@intel.com> Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Link: https://lore.kernel.org/r/20210407222625.320177-4-ben.widawsky@intel.com Signed-off-by: Dan Williams <dan.j.williams@intel.com>
2021-05-26cxl/mem: Split creation from mapping in probeBen Widawsky1-24/+40
Add a new function specifically for mapping the register blocks and offsets within. The new function can be used more generically for other register block identifiers. No functional change is meant to be introduced in this patch with the exception of a dev_err printed when the device register block isn't found. Signed-off-by: Ben Widawsky <ben.widawsky@intel.com> Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Link: https://lore.kernel.org/r/20210407222625.320177-3-ben.widawsky@intel.com Signed-off-by: Dan Williams <dan.j.williams@intel.com>
2021-05-26cxl/mem: Use dev instead of pdev->devBen Widawsky1-1/+1
Trivial cleanup. Signed-off-by: Ben Widawsky <ben.widawsky@intel.com> Acked-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Link: https://lore.kernel.org/r/20210407222625.320177-2-ben.widawsky@intel.com Signed-off-by: Dan Williams <dan.j.williams@intel.com>
2021-05-26cxl/mem: Demarcate vendor specific capability IDsBen Widawsky1-1/+4
Vendor capabilities occupy 0x8000 to 0xFFFF according to CXL 2.0 spec 8.2.8.2.1 CXL Device Capabilities. While they are not defined by the spec, they are allowed and not "unknown". Call this detail out in the logs to let users easily distinguish the difference. This patch is a squash of two earlier patches and take in some minor suggestions from both Vishal and Dan. Cc: Vishal Verma <vishal.l.verma@intel.com> Cc: Dan Williams <dan.j.williams@intel.com> Signed-off-by: Ben Widawsky <ben.widawsky@intel.com> Reviewed-by: Vishal Verma <vishal.l.verma@intel.com> Link: https://lore.kernel.org/r/20210520204852.1070780-1-ben.widawsky@intel.com Signed-off-by: Dan Williams <dan.j.williams@intel.com>
2021-05-26cxl/pci.c: Add a 'label_storage_size' attribute to the memdevVishal Verma2-0/+15
The 'Identify Device' mailbox command returns an 'lsa_size', which is the size of the label storage area on the device. Export it as a sysfs attribute so that userspace tooling to read/write the LSA can determine the size without having to run an 'Identify Device' on their own. Cc: Ben Widawsky <ben.widawsky@intel.com> Cc: Dan Williams <dan.j.williams@intel.com> Signed-off-by: Vishal Verma <vishal.l.verma@intel.com> Reviewed-by: Dan Williams <dan.j.williams@intel.com> Link: https://lore.kernel.org/r/20210520194745.1095517-1-vishal.l.verma@intel.com Signed-off-by: Dan Williams <dan.j.williams@intel.com>
2021-05-26cxl: Rename mem to pciBen Widawsky3-16/+10
As the driver has undergone development, it's become clear that the majority [entirety?] of the current functionality in mem.c is actually a layer encapsulating functionality exposed through PCI based interactions. This layer can be used either in isolation or to provide functionality for higher level functionality. CXL capabilities exist in a parallel domain to PCIe. CXL devices are enumerable and controllable via "legacy" PCIe mechanisms; however, their CXL capabilities are a superset of PCIe. For example, a CXL device may be connected to a non-CXL capable PCIe root port, and therefore will not be able to participate in CXL.mem or CXL.cache operations, but can still be accessed through PCIe mechanisms for CXL.io operations. To properly represent the PCI nature of this driver, and in preparation for introducing a new driver for the CXL.mem / HDM decoder (Host-managed Device Memory) capabilities of a CXL memory expander, rename mem.c to pci.c so that mem.c is available for this new driver. The result of the change is that there is a clear layering distinction in the driver, and a systems administrator may load only the cxl_pci module and gain access to such operations as, firmware update, offline provisioning of devices, and error collection. In addition to freeing up the file name for another purpose, there are two primary reasons this is useful, 1. Acting upon devices which don't have full CXL capabilities. This may happen for instance if the CXL device is connected in a CXL unaware part of the platform topology. 2. Userspace-first provisioning for devices without kernel driver interference. This may be useful when provisioning a new device in a specific manner that might otherwise be blocked or prevented by the real CXL mem driver. Reviewed-by: Dan Williams <dan.j.williams@intel.com> Signed-off-by: Ben Widawsky <ben.widawsky@intel.com> Link: https://lore.kernel.org/r/20210526174413.802913-1-ben.widawsky@intel.com Signed-off-by: Dan Williams <dan.j.williams@intel.com>
2021-05-26mtd: spi-nor: otp: fix kerneldoc typosMichael Walle1-2/+2
Use the correct argument names in the kerneldoc. Fixes: cad3193fe9d1 ("mtd: spi-nor: implement OTP support for Winbond and similar flashes") Reported-by: Pratyush Yadav <p.yadav@ti.com> Signed-off-by: Michael Walle <michael@walle.cc> Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com> Reviewed-by: Pratyush Yadav <p.yadav@ti.com>
2021-05-26mtd: spi-nor: Add documentation for spi_nor_soft_reset()Pratyush Yadav1-0/+15
Document what the function does and that it should only be used when it is known that the device supports it. This will avoid unaware programmers thinking that they can arbitrarily use it to reset the device. Suggested-by: Michael Walle <michael@walle.cc> Signed-off-by: Pratyush Yadav <p.yadav@ti.com> Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com> Reviewed-by: Michael Walle <michael@walle.cc>
2021-05-26mtd: spi-nor: nxp-spifi: Use SPI_MODE_X_MASKAndy Shevchenko1-1/+1
Use SPI_MODE_X_MASK instead of open coded variant. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com> Reviewed-by: Michael Walle <michael@walle.cc>
2021-05-26ixgbe: reduce checker warningsJesse Brandeburg1-4/+4
Fix the sparse warnings in the ixgbe crypto offload code. These changes were made in the most conservative way (force cast) in order to hopefully not break the code. I suspect that the code might still be broken on big-endian architectures, but no one is complaining, so I'm just leaving it functionally the same. Signed-off-by: Jesse Brandeburg <jesse.brandeburg@intel.com> Cc: Shannon Nelson <snelson@pensando.io> Tested-by: Dave Switzer <david.switzer@intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2021-05-26ixgbe: use checker safe conversionsJesse Brandeburg1-5/+4
The ixgbe hardware needs some very specific programming for certain registers, which led to some misguided usage of ntohs instead of using be16_to_cpu(), as well as a home grown swap followed by an ntohs. Sparse didn't like this at all, and this fixes the C=2 build, with code that uses native kernel interface. Signed-off-by: Jesse Brandeburg <jesse.brandeburg@intel.com> Tested-by: Dave Switzer <david.switzer@intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2021-05-26igbvf: convert to strongly typed descriptorsJesse Brandeburg1-21/+21
The igbvf driver for some reason never strongly typed it's descriptor formats. Make this driver like the rest of the Intel drivers and use __le* for our little endian descriptors. Signed-off-by: Jesse Brandeburg <jesse.brandeburg@intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2021-05-26intel: call csum functions with well formatted argumentsJesse Brandeburg2-2/+2
The sparse build (C=2) found that there were two drivers who had not been convered to call the csum_replace_by_diff() function with sparse clean arguments. Most if not all drivers force the cast like this patch does. So these drivers are now joining the party (a bit late), but with no functional change. Signed-off-by: Jesse Brandeburg <jesse.brandeburg@intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2021-05-26igb: override two checker warningsJesse Brandeburg1-2/+2
The igb PTP code was using htons() on a constant to try to byte swap the value before writing it to a register. This byte swap has the consequence of triggering sparse conflicts between the register write which expect cpu ordered input, and the code which generated a big endian constant. Just override the cast to make sure code doesn't change but silence the warning. Can't do a __swab16 in this case because big endian systems would then write the wrong value. Signed-off-by: Jesse Brandeburg <jesse.brandeburg@intel.com> Tested-by: Dave Switzer <david.switzer@intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2021-05-26igb: fix assignment on big endian machinesJesse Brandeburg1-2/+2
The igb driver was trying hard to be sparse correct, but somehow ended up converting a variable into little endian order and then tries to OR something with it. A much plainer way of doing things is to leave all variables and OR operations in CPU (non-endian) mode, and then convert to little endian only once, which is what this change does. This probably fixes a bug that might have been seen only on big endian systems. Signed-off-by: Jesse Brandeburg <jesse.brandeburg@intel.com> Tested-by: Dave Switzer <david.switzer@intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2021-05-26igb: handle vlan types with checker enabledJesse Brandeburg2-4/+5
The sparse build (C=2) finds some issues with how the driver dealt with the (very difficult) hardware that in some generations uses little-endian, and in others uses big endian, for the VLAN field. The code as written picks __le16 as a type and for some hardware revisions we override it to __be16 as done in this patch. This impacted the VF driver as well so fix it there too. Also change the vlan_tci assignment to override the sparse warning without changing functionality. Signed-off-by: Jesse Brandeburg <jesse.brandeburg@intel.com> Tested-by: Dave Switzer <david.switzer@intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2021-05-26igb/igc: use strongly typed pointerJesse Brandeburg2-2/+2
The igb and igc driver both use a trick of creating a local type pointer on the stack to ease dealing with a receive descriptor in 64 bit chunks for printing. Sparse however was not taken into account and receive descriptors are always in little endian order, so just make the unions use __le64 instead of u64. No functional change. Signed-off-by: Jesse Brandeburg <jesse.brandeburg@intel.com> Tested-by: Dvora Fuxbrumer <dvorax.fuxbrumer@linux.intel.com> Tested-by: Dave Switzer <david.switzer@intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2021-05-26fm10k: move error checkJesse Brandeburg1-5/+5
The error check and set_bit are placed in such a way that sparse (C=2) warns: .../fm10k_pci.c:1395:9: warning: context imbalance in 'fm10k_msix_mbx_pf' - different lock contexts for basic block Which seems a little odd, but the code can obviously be moved to where the variable is being set without changing functionality at all, and it even seems to make a bit more sense with the check closer to the set. Signed-off-by: Jesse Brandeburg <jesse.brandeburg@intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2021-05-26intel: remove checker warningJesse Brandeburg3-3/+3
The sparse checker (C=2) found an assignment where we were mixing types when trying to convert from data read directly from the device NVM, to an array in CPU order in-memory, which unfortunately the driver tries to do in-place. This is easily solved by using the swap operation instead of an assignment, and is already proven in other Intel drivers to be functionally correct and the same code, just without a sparse warning. The change is the same in all three drivers. Signed-off-by: Jesse Brandeburg <jesse.brandeburg@intel.com> Tested-by: Dave Switzer <david.switzer@intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2021-05-26e100: handle eeprom as little endianJesse Brandeburg1-6/+6
Sparse tool was warning on some implicit conversions from little endian data read from the EEPROM on the e100 cards. Fix these by being explicit about the conversions using le16_to_cpu(). Signed-off-by: Jesse Brandeburg <jesse.brandeburg@intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2021-05-26Merge tag 'mtd/fixes-for-5.13-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/mtd/linuxLinus Torvalds8-22/+80
Pull MTD fixes from Miquel Raynal: "MTD parsers: - Fix ofpart subpartitions parsing Raw NAND: - Fix external use of SW Hamming ECC helper (txx9ndfmc, tmio, sharpsl, ndfc, lpc32xx_slc, fsmc, cs553x)" * tag 'mtd/fixes-for-5.13-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux: mtd: parsers: ofpart: fix parsing subpartitions mtd: rawnand: txx9ndfmc: Fix external use of SW Hamming ECC helper mtd: rawnand: tmio: Fix external use of SW Hamming ECC helper mtd: rawnand: sharpsl: Fix external use of SW Hamming ECC helper mtd: rawnand: ndfc: Fix external use of SW Hamming ECC helper mtd: rawnand: lpc32xx_slc: Fix external use of SW Hamming ECC helper mtd: rawnand: fsmc: Fix external use of SW Hamming ECC helper mtd: rawnand: cs553x: Fix external use of SW Hamming ECC helper
2021-05-26drm/i915: Drop redundant has_hdmi_sink checkVille Syrjälä1-12/+10
intel_hdmi_bpc_possible() will check has_hdmi_sink for us, so no need to check it in intel_hdmi_mode_clock_valid() anymore. Cc: Werner Sembach <wse@tuxedocomputers.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210511160532.21446-7-ville.syrjala@linux.intel.com Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
2021-05-26drm/i915: Move the TMDS clock division into intel_hdmi_mode_clock_valid()Ville Syrjälä1-3/+3
Now that we have to tell intel_hdmi_mode_clock_valid() whether we're asking about 4:4:4 or 4:2:0 output it can take care of the dotclock->TMDS clock conversion. Cc: Werner Sembach <wse@tuxedocomputers.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210511160532.21446-6-ville.syrjala@linux.intel.com Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
2021-05-26drm/i915: Check sink deep color capabilitis during HDMI .mode_valid()Ville Syrjälä1-7/+9
Currently HDMI .mode_valid() only checks whether the source can do deep color. Let's check whether the sink can do it as well. Cc: Werner Sembach <wse@tuxedocomputers.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210511160532.21446-5-ville.syrjala@linux.intel.com Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
2021-05-26drm/i915: Move platform checks into intel_hdmi_bpc_possible()Ville Syrjälä1-6/+7
Let's put the platform checks into intel_hdmi_bpc_possible() so that it'll confirm both the source and sink capabilities. Cc: Werner Sembach <wse@tuxedocomputers.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210511160532.21446-4-ville.syrjala@linux.intel.com Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Copyright © 1996 – 2026 Jason A. Donenfeld. All Rights Reverse Engineered.