aboutsummaryrefslogtreecommitdiffstats
path: root/drivers
AgeCommit message (Collapse)AuthorFilesLines
2022-09-06scsi: qla2xxx: Fix spelling mistake "definiton" -> "definition"Colin Ian King1-1/+1
There is a spelling mistake in a MODULE_PARM_DESC description. Fix it. Link: https://lore.kernel.org/r/20220906140010.194273-1-colin.i.king@gmail.com Signed-off-by: Colin Ian King <colin.i.king@gmail.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2022-09-06scsi: mpt3sas: Fix use-after-free warningSreekanth Reddy1-1/+1
Fix the following use-after-free warning which is observed during controller reset: refcount_t: underflow; use-after-free. WARNING: CPU: 23 PID: 5399 at lib/refcount.c:28 refcount_warn_saturate+0xa6/0xf0 Link: https://lore.kernel.org/r/20220906134908.1039-2-sreekanth.reddy@broadcom.com Signed-off-by: Sreekanth Reddy <sreekanth.reddy@broadcom.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2022-09-06scsi: hisi_sas: Don't send bcast events from HW during nexus HA resetJohn Garry1-4/+12
Remote devices may go missing from the per-device nexus reset part of the HA nexus, i.e after the controller reset. This is because libsas may find the devices to be gone as the phy may be temporarily down when processing the bcast event generated from the nexus reset. Filter out bcast events during this time to stop the devices being lost. Link: https://lore.kernel.org/r/1662378529-101489-6-git-send-email-john.garry@huawei.com Signed-off-by: John Garry <john.garry@huawei.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2022-09-06scsi: hisi_sas: Add helper to process bcast eventsJohn Garry5-13/+18
Add a helper for bcast processing to reduce duplication. Link: https://lore.kernel.org/r/1662378529-101489-5-git-send-email-john.garry@huawei.com Signed-off-by: John Garry <john.garry@huawei.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2022-09-06scsi: hisi_sas: Drain bcast events in hisi_sas_rescan_topology()John Garry1-0/+7
In resetting the controller, SATA devices may be lost. The issue is that when we insert the bcast events to rescan the topology in hisi_sas_rescan_topology(), when we subsequently nexus reset the SATA devices in hisi_sas_async_I_T_nexus_reset(), there is a small timing window in which the remote phy is down and we process the bcast event (meaning that libsas judges that the disk is lost). Ensure that all bcast events are processed prior to the nexus reset to close this window. Link: https://lore.kernel.org/r/1662378529-101489-4-git-send-email-john.garry@huawei.com Signed-off-by: John Garry <john.garry@huawei.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2022-09-06scsi: hisi_sas: Clear HISI_SAS_HW_FAULT_BIT earlierJohn Garry1-1/+1
Once the controller HW has been reset then we can unset flag HISI_SAS_HW_FAULT_BIT. In clearing this flag earlier we can now successfully execute commands in hisi_sas_controller_reset_done(), like bcast processing. Link: https://lore.kernel.org/r/1662378529-101489-3-git-send-email-john.garry@huawei.com Signed-off-by: John Garry <john.garry@huawei.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2022-09-06scsi: hisi_sas: Revert change to limit max hw sectors for v3 HWJohn Garry1-7/+0
Now that libsas and the SCSI core code limits the default sectors from commit 4cbfca5f7750 ("scsi: scsi_transport_sas: cap shost opt_sectors according to DMA optimal limit") and commit 608128d391fa ("scsi: sd: allow max_sectors be capped at DMA optimal size limit"), there is no need for the hack to limit the max HW sectors. Link: https://lore.kernel.org/r/1662378529-101489-2-git-send-email-john.garry@huawei.com Signed-off-by: John Garry <john.garry@huawei.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2022-09-06scsi: esas2r: Use flex array destination for memcpy()Kees Cook2-2/+2
In preparation for FORTIFY_SOURCE performing run-time destination buffer bounds checking for memcpy(), specify the destination output buffer explicitly, instead of asking memcpy() to write past the end of what looked like a fixed-size object. Silences future run-time warning: memcpy: detected field-spanning write (size 80) of single field "trc + 1" (size 64) There is no binary code output differences from this change. Link: https://lore.kernel.org/r/20220901205729.2260982-1-keescook@chromium.org Cc: Bradley Grove <linuxdrivers@attotech.com> Cc: "James E.J. Bottomley" <jejb@linux.ibm.com> Cc: "Martin K. Petersen" <martin.petersen@oracle.com> Cc: linux-scsi@vger.kernel.org Reviewed-by: Gustavo A. R. Silva <gustavoars@kernel.org> Signed-off-by: Kees Cook <keescook@chromium.org> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2022-09-06scsi: 3w-9xxx: Avoid disabling device if failing to enable itLetu Ren1-1/+1
The original code will "goto out_disable_device" and call pci_disable_device() if pci_enable_device() fails. The kernel will generate a warning message like "3w-9xxx 0000:00:05.0: disabling already-disabled device". We shouldn't disable a device that failed to be enabled. A simple return is fine. Link: https://lore.kernel.org/r/20220829110115.38789-1-fantasquex@gmail.com Reported-by: Zheyu Ma <zheyuma97@gmail.com> Signed-off-by: Letu Ren <fantasquex@gmail.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2022-09-06scsi: ufs: core: Print UFSHCD capabilities in controller's sysfs nodeDaniil Lunev1-0/+35
Userspace may want to manually control when the data should go into WriteBooster buffer. The control happens via "wb_on" node, but presently, there is no simple way to check if WriteBooster is supported and enabled. Expose the Write Booster and Clock Scaling capabilities to be able to determine if the Write Booster is available and if its manual control is blocked by Clock Scaling mechanism. Link: https://lore.kernel.org/r/20220829081845.v8.1.Ibf9efc9be50783eeee55befa2270b7d38552354c@changeid Reviewed-by: Bart Van Assche <bvanassche@acm.org> Signed-off-by: Daniil Lunev <dlunev@chromium.org> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2022-09-06scsi: qlogicpti: Fix dma_map_sg() checkJack Wang1-1/+2
Add missing error check for dma_map_sg(). Cc: "James E.J. Bottomley" <jejb@linux.ibm.com> Cc: "Martin K. Petersen" <martin.petersen@oracle.com> Cc: linux-scsi@vger.kernel.org Cc: linux-kernel@vger.kernel.org Link: https://lore.kernel.org/r/20220826101435.79170-1-jinpu.wang@ionos.com Signed-off-by: Jack Wang <jinpu.wang@ionos.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2022-09-06scsi: core: Convert scsi_decide_disposition() to use SCSIML_STATMike Christie2-25/+11
Don't use: - DID_TARGET_FAILURE - DID_NEXUS_FAILURE - DID_ALLOC_FAILURE - DID_MEDIUM_ERROR Instead use the SCSI midlayer internal values. Link: https://lore.kernel.org/r/20220812010027.8251-10-michael.christie@oracle.com Reviewed-by: Bart Van Assche <bvanassche@acm.org> Signed-off-by: Mike Christie <michael.christie@oracle.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2022-09-06scsi: core: Add error codes for internal SCSI midlayer useMike Christie3-0/+38
If a driver returns: - DID_TARGET_FAILURE - DID_NEXUS_FAILURE - DID_ALLOC_FAILURE - DID_MEDIUM_ERROR we hit a couple bugs: 1. The SCSI error handler runs because scsi_decide_disposition() has no case statements for them and we return FAILED. 2. For SG IO the userspace app gets a success status instead of failed, because scsi_result_to_blk_status() clears those errors. This patch adds a new internal error code byte for use by the SCSI midlayer. This will be used instead of the above error codes, so we don't have to play that clearing the host code game in scsi_result_to_blk_status() and drivers cannot accidentally use them. A subsequent commit will then remove the internal users of the above codes and convert us to use the new ones. Link: https://lore.kernel.org/r/20220812010027.8251-9-michael.christie@oracle.com Reviewed-by: Bart Van Assche <bvanassche@acm.org> Signed-off-by: Mike Christie <michael.christie@oracle.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2022-09-06scsi: cxlflash: Drop DID_ALLOC_FAILURE useMike Christie1-1/+1
DID_ALLOC_FAILURE is internal to the SCSI layer. Drivers must not use it because: 1. It's not propagated upwards, so SG IO/passthrough users will not see an error and think a command was successful. 2. There is no handling for it in scsi_decide_disposition() so it results in entering SCSI error handling. By the code comment, it looks like the driver wanted a retryable error code, so this has it use DID_ERROR. Link: https://lore.kernel.org/r/20220812010027.8251-8-michael.christie@oracle.com Signed-off-by: Mike Christie <michael.christie@oracle.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2022-09-06scsi: qla2xxx: Drop DID_TARGET_FAILURE useMike Christie1-1/+1
DID_TARGET_FAILURE is internal to the SCSI layer. Drivers must not use it because: 1. It's not propagated upwards, so SG IO/passthrough users will not see an error and think a command was successful. 2. There is no handling for it in scsi_decide_disposition() so it results in entering SCSI error handling. This has qla2xxx use DID_NO_CONNECT because it looks like we hit this error when we can't find a port. It will give us the same hard error behavior and it seems to match the error where we can't find the endpoint. Link: https://lore.kernel.org/r/20220812010027.8251-7-michael.christie@oracle.com Reviewed-by: Himanshu Madhani <himanshu.madhani@oracle.com> Signed-off-by: Mike Christie <michael.christie@oracle.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2022-09-06scsi: virtio_scsi: Drop DID_NEXUS_FAILURE useMike Christie1-1/+1
DID_NEXUS_FAILURE is internal to the SCSI layer. Drivers must not use it because: 1. It's not propagated upwards, so SG IO/passthrough users will not see an error and think a command was successful. 2. There is no handling for it in scsi_decide_disposition() so it results in entering SCSI error handling. virtio_scsi gets this when something like qemu returns VIRTIO_SCSI_S_NEXUS_FAILURE. It looks like qemu returns that error code if host OS returns DID_NEXUS_FAILURE (qemu's internal SCSI_HOST_RESERVATION_ERROR maps to DID_NEXUS_FAILURE). This shouldn't happen for Linux since we don't propagate that error code to userspace. This has us convert VIRTIO_SCSI_S_NEXUS_FAILURE to a SAM_STAT_RESERVATION_CONFLICT in case some other virt layer is returning it. In that case we will still get the reservation confict failure we expect. Link: https://lore.kernel.org/r/20220812010027.8251-6-michael.christie@oracle.com Acked-by: Paolo Bonzini <pbonzini@redhat.com> Acked-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Mike Christie <michael.christie@oracle.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2022-09-06scsi: virtio_scsi: Drop DID_TARGET_FAILURE useMike Christie1-1/+1
DID_TARGET_FAILURE is internal to the SCSI layer. Drivers must not use it because: 1. It's not propagated upwards, so SG IO/passthrough users will not see an error and think a command was successful. 2. There is no handling for it in scsi_decide_disposition() so it results in entering SCSI error handling. virtio_scsi gets this when something like qemu returns VIRTIO_SCSI_S_TARGET_FAILURE. It looks like qemu returns that error code if a host OS returns it, but this shouldn't happen for Linux since we never propagate that error to userspace. This has us use DID_BAD_TARGET in case some other virt layer is returning it. In that case we will still get a hard error like before and it conveys something unexpected happened. Link: https://lore.kernel.org/r/20220812010027.8251-5-michael.christie@oracle.com Acked-by: Paolo Bonzini <pbonzini@redhat.com> Acked-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Mike Christie <michael.christie@oracle.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2022-09-06scsi: uas: Drop DID_TARGET_FAILURE useMike Christie1-1/+1
DID_TARGET_FAILURE is internal to the SCSI layer. Drivers must not use it because: 1. It's not propagated upwards, so SG IO/passthrough users will not see an error and think a command was successful. 2. There is no handling for it in scsi_decide_disposition() so it results in entering SCSI error handling. It looks like the driver wanted a hard failure so this swaps it with DID_BAD_TARGET which gives us that behavior. The error looks like it's for a case where the target did not support a TMF we wanted to use (maybe not a bad target but disappointing so close enough). Link: https://lore.kernel.org/r/20220812010027.8251-4-michael.christie@oracle.com Signed-off-by: Mike Christie <michael.christie@oracle.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2022-09-06scsi: storvsc: Drop DID_TARGET_FAILURE useMike Christie1-1/+1
DID_TARGET_FAILURE is internal to the SCSI layer. Drivers must not use it because: 1. It's not propagated upwards, so SG IO/passthrough users will not see an error and think a command was successful. 2. There is no handling for it in scsi_decide_disposition() so it results in the SCSI error handling running. It looks like the driver wanted a hard failure so swap it with DID_BAD_TARGET. Link: https://lore.kernel.org/r/20220812010027.8251-3-michael.christie@oracle.com Signed-off-by: Mike Christie <michael.christie@oracle.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2022-09-06scsi: xen: Drop use of internal host codesMike Christie2-20/+0
The error codes: - DID_TARGET_FAILURE - DID_NEXUS_FAILURE - DID_ALLOC_FAILURE - DID_MEDIUM_ERROR are internal to the SCSI layer. Drivers must not use them because: 1. They are not propagated upwards, so SG IO/passthrough users will not see an error and think a command was successful. xen-scsiback will never see this error and should not try to send it. 2. There is no handling for them in scsi_decide_disposition() so if xen-scsifront were to return the error to the SCSI midlayer then it kicks off the error handler which is definitely not what we want. Remove the use from xen-scsifront/back. Link: https://lore.kernel.org/r/20220812010027.8251-2-michael.christie@oracle.com Reviewed-by: Juergen Gross <jgross@suse.com> Signed-off-by: Mike Christie <michael.christie@oracle.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2022-09-06Merge tag 'for-linus' of git://git.armlinux.org.uk/~rmk/linux-armLinus Torvalds1-1/+7
Pull ARM fix from Russell King: "Just one fix for now for the AMBA bus code from Isaac Manjarres" * tag 'for-linus' of git://git.armlinux.org.uk/~rmk/linux-arm: ARM: 9229/1: amba: Fix use-after-free in amba_read_periphid()
2022-09-06drm/panel-edp: Fix typo in kerneldoc comment (appers=>appears)Douglas Anderson1-1/+1
Ever since I got the spell-check working in my editor this one has been bugging me. Fix it. Signed-off-by: Douglas Anderson <dianders@chromium.org> Acked-by: Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/20220720162314.1.Ieef5bc3848df40b71605b70bb571d6429e8978de@changeid
2022-09-06iavf: Fix race between iavf_close and iavf_reset_taskMichal Jaron1-36/+141
During stress tests with adding VF to namespace and changing vf's trust there was a race between iavf_reset_task and iavf_close. Sometimes when IAVF_FLAG_AQ_DISABLE_QUEUES from iavf_close was sent to PF after reset and before IAVF_AQ_GET_CONFIG was sent then PF returns error IAVF_NOT_SUPPORTED to disable queues request and following requests. There is need to get_config before other aq_required will be send but iavf_close clears all flags, if get_config was not sent before iavf_close, then it will not be send at all. In case when IAVF_FLAG_AQ_GET_OFFLOAD_VLAN_V2_CAPS was sent before IAVF_FLAG_AQ_DISABLE_QUEUES then there was rtnl_lock deadlock between iavf_close and iavf_adminq_task until iavf_close timeouts and disable queues was sent after iavf_close ends. There was also a problem with sending delete/add filters. Sometimes when filters was not yet added to PF and in iavf_close all filters was set to remove there might be a try to remove nonexistent filters on PF. Add aq_required_tmp to save aq_required flags and send them after disable_queues will be handled. Clear flags given to iavf_down different than IAVF_FLAG_AQ_GET_CONFIG as this flag is necessary to sent other aq_required. Remove some flags that we don't want to send as we are in iavf_close and we want to disable interface. Remove filters which was not yet sent and send del filters flags only when there are filters to remove. Signed-off-by: Michal Jaron <michalx.jaron@intel.com> Signed-off-by: Mateusz Palczewski <mateusz.palczewski@intel.com> Tested-by: Konrad Jankowski <konrad0.jankowski@intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2022-09-06ice: Simplify memory allocation in ice_sched_init_port()Christophe JAILLET1-2/+2
'buf' is locale to the ice_sched_init_port() function. There is no point in using devm_kzalloc()/devm_kfree(). use kzalloc()/kfree() instead. Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2022-09-06ice: switch: Simplify memory allocationChristophe JAILLET1-4/+2
'rbuf' is locale to the ice_get_initial_sw_cfg() function. There is no point in using devm_kzalloc()/devm_kfree(). use kzalloc()/kfree() instead. Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Reviewed-by: Michal Swiatkowski <michal.swiatkowski@linux.intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2022-09-06ice: add helper function to check FW API versionPaul Greenwalt1-28/+29
Several functions in ice_common.c check the firmware API version to see if the current API version meets some minimum requirement. Improve the readability of these checks by introducing ice_is_fw_api_min_ver, a helper function to perform that check. Signed-off-by: Paul Greenwalt <paul.greenwalt@intel.com> Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Tested-by: Gurucharan <gurucharanx.g@intel.com> (A Contingent worker at Intel) Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2022-09-06ice: Check if reset in progress while waiting for offsetsMichal Michalik1-0/+3
Occasionally while waiting to valid offsets from hardware we get reset. Add check for reset before proceeding to execute scheduled work. Co-developed-by: Karol Kolacinski <karol.kolacinski@intel.com> Signed-off-by: Karol Kolacinski <karol.kolacinski@intel.com> Signed-off-by: Michal Michalik <michal.michalik@intel.com> Tested-by: Gurucharan <gurucharanx.g@intel.com> (A Contingent worker at Intel) Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2022-09-06ice: Allow operation with reduced device MSI-XTony Nguyen1-81/+96
The driver currently takes an all or nothing approach for device MSI-X vectors. Meaning if it does not get its full allocation, it will fail and not load. There is no reason it can't work with a reduced number of MSI-X vectors. Take a similar approach as commit 741106f7bd8d ("ice: Improve MSI-X fallback logic") and, instead, adjust the MSI-X request to make use of what is available. Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com> Tested-by: Petr Oros <poros@redhat.com> Tested-by: Gurucharan <gurucharanx.g@intel.com> (A Contingent worker at Intel)
2022-09-06i40e: add description and modify interrupts configuration procedureJaroslaw Gawin2-21/+27
Add description for values written into registers QINT_XXXX and small cosmetic changes for MSI/LEGACY interrupts configuration in the same way as for MSI-X. Descriptions confirm the code is written correctly and make the code clear. Small cosmetic changes for MSI/LEGACY interrupts make code clear in the same manner as for MSI-X interrupts. Signed-off-by: Jaroslaw Gawin <jaroslawx.gawin@intel.com> Signed-off-by: Andrii Staikov <andrii.staikov@intel.com> Tested-by: Gurucharan <gurucharanx.g@intel.com> (A Contingent worker at Intel) Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2022-09-06drm/i915: Don't try to disable host RPS when this was never enabled.Rodrigo Vivi1-0/+3
Specially in GT reset case this could be triggered and try to disable things that had never been enabled. Let's add some protection here. Cc: Ashutosh Dixit <ashutosh.dixit@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Ashutosh Dixit <ashutosh.dixit@intel.com> Acked-by: Nirmoy Das <nirmoy.das@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220902095126.373036-1-rodrigo.vivi@intel.com
2022-09-06coresight: cti-sysfs: Mark coresight_cti_reg_store() as __maybe_unusedNathan Chancellor1-3/+3
When building without CONFIG_CORESIGHT_CTI_INTEGRATION_REGS, there is a warning about coresight_cti_reg_store() being unused in the file: drivers/hwtracing/coresight/coresight-cti-sysfs.c:184:16: warning: 'coresight_cti_reg_store' defined but not used [-Wunused-function] 184 | static ssize_t coresight_cti_reg_store(struct device *dev, | ^~~~~~~~~~~~~~~~~~~~~~~ This is expected as coresight_cti_reg_store() is only used in the coresight_cti_reg_rw macro, which is only used in a block guarded by CONFIG_CORESIGHT_CTI_INTEGRATION_REGS. Mark coresight_cti_reg_store() as __maybe_unused to clearly indicate that the function may be unused depending on the configuration. Fixes: fbca79e55429 ("coresight: cti-sysfs: Re-use same functions for similar sysfs register accessors") Signed-off-by: Nathan Chancellor <nathan@kernel.org> Reviewed-by: James Clark <james.clark@arm.com> Link: https://lore.kernel.org/r/20220901195055.1932340-1-nathan@kernel.org Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
2022-09-06drm/scheduler: quieten kernel-doc warningsRandy Dunlap1-1/+2
Fix kernel-doc warnings in gpu_scheduler.h and sched_main.c. Quashes these warnings: include/drm/gpu_scheduler.h:332: warning: missing initial short description on line: * struct drm_sched_backend_ops include/drm/gpu_scheduler.h:412: warning: missing initial short description on line: * struct drm_gpu_scheduler include/drm/gpu_scheduler.h:461: warning: Function parameter or member 'dev' not described in 'drm_gpu_scheduler' drivers/gpu/drm/scheduler/sched_main.c:201: warning: missing initial short description on line: * drm_sched_dependency_optimized drivers/gpu/drm/scheduler/sched_main.c:995: warning: Function parameter or member 'dev' not described in 'drm_sched_init' Fixes: 2d33948e4e00 ("drm/scheduler: add documentation") Fixes: 8ab62eda177b ("drm/sched: Add device pointer to drm_gpu_scheduler") Fixes: 542cff7893a3 ("drm/sched: Avoid lockdep spalt on killing a processes") Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Cc: David Airlie <airlied@linux.ie> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: Andrey Grodzovsky <andrey.grodzovsky@amd.com> Cc: Nayan Deshmukh <nayan26deshmukh@gmail.com> Cc: Alex Deucher <alexander.deucher@amd.com> Cc: Christian König <christian.koenig@amd.com> Cc: Jiawei Gu <Jiawei.Gu@amd.com> Cc: dri-devel@lists.freedesktop.org Acked-by: Christian König <christian.koenig@amd.com> Signed-off-by: Andrey Grodzovsky <andrey.grodzovsky@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220404213040.12912-1-rdunlap@infradead.org
2022-09-06i40e: Add basic support for I710 devicesStanislaw Grzeszczak3-1/+7
Intel introduces a new line of 1G ethernet adapters with Device ID 0x0DD2 Signed-off-by: Stanislaw Grzeszczak <stanislaw.a.grzeszczak@intel.com> Signed-off-by: Mateusz Palczewski <mateusz.palczewski@intel.com> Tested-by: Gurucharan <gurucharanx.g@intel.com> (A Contingent worker at Intel) Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2022-09-06drm/i915: consider HAS_FLAT_CCS() in needs_ccs_pagesMatthew Auld2-1/+4
Just move the HAS_FLAT_CCS() check into needs_ccs_pages. This also then fixes i915_ttm_memcpy_allowed() which was incorrectly reporting true on DG1, even though it doesn't have small-BAR or flat-CCS. References: https://gitlab.freedesktop.org/drm/intel/-/issues/6605 Fixes: efeb3caf4341 ("drm/i915/ttm: disallow CPU fallback mode for ccs pages") Signed-off-by: Matthew Auld <matthew.auld@intel.com> Cc: Nirmoy Das <nirmoy.das@intel.com> Reviewed-by: Nirmoy Das <nirmoy.das@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220905105329.41455-1-matthew.auld@intel.com (cherry picked from commit 873fef8833ea794526b7f4179088e565078fe0e8) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2022-09-06drm/i915: Implement WaEdpLinkRateDataReloadVille Syrjälä1-0/+22
A lot of modern laptops use the Parade PS8461E MUX for eDP switching. The MUX can operate in jitter cleaning mode or redriver mode, the first one resulting in higher link quality. The jitter cleaning mode needs to know the link rate used and the MUX achieves this by snooping the LINK_BW_SET, LINK_RATE_SELECT and SUPPORTED_LINK_RATES DPCD accesses. When the MUX is powered down (seems this can happen whenever the display is turned off) it loses track of the snooped link rates so when we do the LINK_RATE_SELECT write it no longer knowns which link rate we're selecting, and thus it falls back to the lower quality redriver mode. This results in unstable high link rates (eg. usually 8.1Gbps link rate no longer works correctly). In order to avoid all that let's re-snoop SUPPORTED_LINK_RATES from the sink at the start of every link training. Unfortunately we don't have a way to detect the presence of the MUX. It looks like the set of laptops equipped with this MUX is fairly large and contains devices from multiple manufacturers. It may also still be growing with new models. So a quirk doesn't seem like a very easily maintainable option, thus we shall attempt to do this unconditionally on all machines that use LINK_RATE_SELECT. Hopefully this extra DPCD read doesn't cause issues for any unaffected machine. If that turns out to be the case we'll need to convert this into a quirk in the future. Cc: stable@vger.kernel.org Cc: Jason A. Donenfeld <Jason@zx2c4.com> Cc: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/6205 Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220902070319.15395-1-ville.syrjala@linux.intel.com Tested-by: Aaron Ma <aaron.ma@canonical.com> Tested-by: Jason A. Donenfeld <Jason@zx2c4.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> (cherry picked from commit 25899c590cb5ba9b9f284c6ca8e7e9086793d641) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2022-09-06drm/i915/slpc: Let's fix the PCODE min freq table setup for SLPCRodrigo Vivi3-10/+61
We need to inform PCODE of a desired ring frequencies so PCODE update the memory frequencies to us. rps->min_freq and rps->max_freq are the frequencies used in that request. However they were unset when SLPC was enabled and PCODE never updated the memory freq. v2 (as Suggested by Ashutosh): if SLPC is in use, let's pick the right frequencies from the get_ia_constants instead of the fake init of rps' min and max. v3: don't forget the max <= min return v4: Move all the freq conversion to intel_rps.c. And the max <= min check to where it belongs. v5: (Ashutosh) Fix old comment s/50 HZ/50 MHz and add a doc explaining the "raw format" Fixes: 7ba79a671568 ("drm/i915/guc/slpc: Gate Host RPS when SLPC is enabled") Cc: <stable@vger.kernel.org> # v5.15+ Cc: Ashutosh Dixit <ashutosh.dixit@intel.com> Tested-by: Sushma Venkatesh Reddy <sushma.venkatesh.reddy@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Ashutosh Dixit <ashutosh.dixit@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220831214538.143950-1-rodrigo.vivi@intel.com (cherry picked from commit 018a7bdbb090b9155a6509a0d1a684db4afaa5b1) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2022-09-06drm/i915/bios: Copy the whole MIPI sequence blockVille Syrjälä1-0/+7
Turns out the MIPI sequence block version number and new block size fields are considered part of the block header and are not included in the reported new block size field itself. Bump up the block size appropriately so that we'll copy over the last five bytes of the block as well. For this particular machine those last five bytes included parts of the GPIO op for the backlight on sequence, causing the backlight no longer to turn back on: Sequence 6 - MIPI_SEQ_BACKLIGHT_ON Delay: 20000 us - GPIO index 0, number 0, set 0 (0x00) + GPIO index 1, number 70, set 1 (0x01) Cc: stable@vger.kernel.org Fixes: e163cfb4c96d ("drm/i915/bios: Make copies of VBT data blocks") Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/6652 Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220829135834.8585-1-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com> (cherry picked from commit a06289f3f72431f3777af95ea1226b5b0abdc426) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2022-09-06Input: xpad - add support for XBOX One Elite paddlesChristopher Crockett1-60/+192
An effort has been made to support every official model and firmware version I could track down info on. The following controllers _should_ have working paddles with this PR: - Xbox Elite (**untested**) - Xbox Elite Series 2 on early firmwares (**untested**) - Xbox Elite Series 2 on v4 firmwares (Tested v4.8.1908.0) - Xbox Elite Series 2 on v5 pre-BLE firmwares (**untested**) - Xbox Elite Series 2 on v5 post-BLE firmwares (Tested v5.13.3143.0) This patch also introduces correct handling for the Elite 1 controller and properly suppresses paddle inputs when using a custom profile slot. Starting with firmware v5.11, certain inputs for the Elite 2 were moved to an extra packet that is not enabled by default. We must first manually enable this extra packet in order to correctly process paddle input data with these later firmwares. Signed-off-by: Christopher Crockett <chaorace@gmail.com> Signed-off-by: Pavel Rojtberg <rojtberg@gmail.com> Tested-by: Bastien Nocera <hadess@hadess.net> Link: https://lore.kernel.org/r/20220818154411.510308-5-rojtberg@gmail.com Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
2022-09-06Input: xpad - Poweroff XBOX360W on mode button long pressSantosh De Massari1-0/+24
Newer gamepads turn themselves off when the mode button is held down. For XBOX360W gamepads we must do this in the driver. Do not use BIT() macro for consistency within the file. Signed-off-by: Santosh De Massari <s.demassari@gmail.com> Signed-off-by: Pavel Rojtberg <rojtberg@gmail.com> Link: https://lore.kernel.org/r/20220818154411.510308-4-rojtberg@gmail.com Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
2022-09-06Input: xpad - fix wireless 360 controller breaking after suspendCameron Gutman1-1/+0
Suspending and resuming the system can sometimes cause the out URB to get hung after a reset_resume. This causes LED setting and force feedback to break on resume. To avoid this, just drop the reset_resume callback so the USB core rebinds xpad to the wireless pads on resume if a reset happened. A nice side effect of this change is the LED ring on wireless controllers is now set correctly on system resume. Cc: stable@vger.kernel.org Fixes: 4220f7db1e42 ("Input: xpad - workaround dead irq_out after suspend/ resume") Signed-off-by: Cameron Gutman <aicommander@gmail.com> Signed-off-by: Pavel Rojtberg <rojtberg@gmail.com> Link: https://lore.kernel.org/r/20220818154411.510308-3-rojtberg@gmail.com Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
2022-09-06Input: xpad - add supported devices as contributed on githubPavel Rojtberg1-0/+19
This is based on multiple commits at https://github.com/paroj/xpad Cc: stable@vger.kernel.org Signed-off-by: Jasper Poppe <jgpoppe@gmail.com> Signed-off-by: Jeremy Palmer <jpalmer@linz.govt.nz> Signed-off-by: Ruineka <ruinairas1992@gmail.com> Signed-off-by: Cleber de Mattos Casali <clebercasali@gmail.com> Signed-off-by: Kyle Gospodnetich <me@kylegospodneti.ch> Signed-off-by: Pavel Rojtberg <rojtberg@gmail.com> Link: https://lore.kernel.org/r/20220818154411.510308-2-rojtberg@gmail.com Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
2022-09-06Revert "drm/i915: Fix intel_dp_mst_compute_link_config"Jani Nikula1-14/+2
This reverts commit c6266862de1665b8c8006f58612db2dea66a29f6. Part of a series where patches were modified while applying to resolve conflicts, leading to further conflicts between drm-misc-next and drm-intel-next, resulting in build failures in drm-tip. To be applied again on a baseline with drm-misc-next and drm-intel-next in sync. Acked-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2022-09-06Revert "drm/i915: Extract drm_dp_atomic_find_vcpi_slots cycle to separate function"Jani Nikula1-41/+13
This reverts commit 7ae5ab441402b8165de4658ba9398d8378f7dd1e. Part of a series where patches were modified while applying to resolve conflicts, leading to further conflicts between drm-misc-next and drm-intel-next, resulting in build failures in drm-tip. To be applied again on a baseline with drm-misc-next and drm-intel-next in sync. Acked-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2022-09-06Revert "drm/i915: Add DSC support to MST path"Jani Nikula3-174/+42
This reverts commit e1a84ba850128b3984973786829e610ae4ee0e2e. Part of a series where patches were modified while applying to resolve conflicts, leading to further conflicts between drm-misc-next and drm-intel-next, resulting in build failures in drm-tip. To be applied again on a baseline with drm-misc-next and drm-intel-next in sync. Acked-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2022-09-06binder: fix binder_alloc kernel-doc warningsCarlos Llamas1-3/+2
Update the kernel-doc section of struct binder_alloc to fix the following warnings reported by ./scripts/kernel-doc: warning: Function parameter or member 'mutex' not described in 'binder_alloc' warning: Function parameter or member 'vma_addr' not described in 'binder_alloc' No functional changes in this patch. Reviewed-by: Christian Brauner (Microsoft) <brauner@kernel.org> Acked-by: Todd Kjos <tkjos@google.com> Signed-off-by: Carlos Llamas <cmllamas@google.com> Link: https://lore.kernel.org/r/20220906135948.3048225-4-cmllamas@google.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-09-06binder: remove binder_alloc_set_vma()Carlos Llamas1-23/+2
The mmap_locked asserts here are not needed since this is only called back from the mmap stack in ->mmap() and ->close() which always acquire the lock first. Remove these asserts along with binder_alloc_set_vma() altogether since it's trivial enough to be consumed by callers. Cc: Liam R. Howlett <Liam.Howlett@oracle.com> Signed-off-by: Carlos Llamas <cmllamas@google.com> Link: https://lore.kernel.org/r/20220906135948.3048225-3-cmllamas@google.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-09-06binder: rename alloc->vma_vm_mm to alloc->mmCarlos Llamas2-19/+19
Rename ->vma_vm_mm to ->mm to reflect the fact that we no longer cache this reference from vma->vm_mm but from current->mm instead. No functional changes in this patch. Reviewed-by: Christian Brauner (Microsoft) <brauner@kernel.org> Acked-by: Todd Kjos <tkjos@google.com> Signed-off-by: Carlos Llamas <cmllamas@google.com> Link: https://lore.kernel.org/r/20220906135948.3048225-2-cmllamas@google.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-09-06misc: microchip: pci1xxxx: fix dependency issues in building the pci1xxxx's aux bus driver.Kumaravel Thiagarajan1-1/+3
build errors and warnings listed below and reported by kernel test robot <lkp@intel.com> on the char-misc-next branch are fixed in this add-on patch. errors: ERROR: modpost: "auxiliary_device_init" [drivers/misc/mchp_pci1xxxx/mchp_pci1xxxx_gp.ko] undefined! ERROR: modpost: "__auxiliary_device_add" [drivers/misc/mchp_pci1xxxx/mchp_pci1xxxx_gp.ko] undefined! ERROR: modpost: "auxiliary_driver_unregister" [drivers/misc/mchp_pci1xxxx/mchp_pci1xxxx_gpio.ko] undefined! ERROR: modpost: "__auxiliary_driver_register" [drivers/misc/mchp_pci1xxxx/mchp_pci1xxxx_gpio.ko] undefined! ia64-linux-ld: drivers/misc/mchp_pci1xxxx/mchp_pci1xxxx_gp.o: in function `gp_aux_bus_probe.part.0': mchp_pci1xxxx_gp.c:(.text+0x342): undefined reference to `auxiliary_device_init' ia64-linux-ld: mchp_pci1xxxx_gp.c:(.text+0x392): undefined reference to `__auxiliary_device_add' ia64-linux-ld: mchp_pci1xxxx_gp.c:(.text+0x5c2): undefined reference to `auxiliary_device_init' ia64-linux-ld: mchp_pci1xxxx_gp.c:(.text+0x612): undefined reference to `__auxiliary_device_add' ia64-linux-ld: drivers/misc/mchp_pci1xxxx/mchp_pci1xxxx_gpio.o: in function `pci1xxxx_gpio_driver_init': mchp_pci1xxxx_gpio.c:(.init.text+0x42): undefined reference to `__auxiliary_driver_register' warnings: unmet direct dependencies detected for GPIOLIB_IRQCHIP when selected by GP_PCI1XXXX Fixes: 393fc2f5948f ("misc: microchip: pci1xxxx: load auxiliary bus driver for the PIO function in the multi-function endpoint of pci1xxxx device.") Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: Kumaravel Thiagarajan <kumaravel.thiagarajan@microchip.com> Link: https://lore.kernel.org/r/20220906124951.696776-1-kumaravel.thiagarajan@microchip.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-09-06drm/i915: split out i915_gem.c declarations to i915_gem.hJani Nikula2-36/+43
Declutter i915_drv.h by splitting out the declarations for i915_gem.[ch]. Add a fixme comment about the rest of the stuff in i915_gem.h that doesn't really belong there. Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/82a353c5c4b52df2354f9413b547c7619a45d92d.1662390010.git.jani.nikula@intel.com
2022-09-06drm/i915: un-inline i915_gem_drain_freed_objects()Jani Nikula2-16/+16
I can't idenfity a single hot path that would require i915_gem_drain_freed_objects() to be inline. Un-inline it. Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/6c289c55afee0d9a3067122db63277b8d60cf74f.1662390010.git.jani.nikula@intel.com
Copyright © 1996 – 2026 Jason A. Donenfeld. All Rights Reverse Engineered.