aboutsummaryrefslogtreecommitdiffstats
path: root/drivers
AgeCommit message (Collapse)AuthorFilesLines
2021-06-07drm/amdkfd: remove duplicate include of kfd_svm.hWan Jiabing1-1/+0
kfd_svm.h is included duplicately in commit 42de677f79999 ("drm/amdkfd: register svm range"). After checking possible related header files, remove the former one to make the code format more reasonable. Signed-off-by: Wan Jiabing <wanjiabing@vivo.com> Reviewed-by: Felix Kuehling <Felix.Kuehling@amd.com> Signed-off-by: Felix Kuehling <Felix.Kuehling@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2021-06-07drm/amdgpu: fix VM handling for GART allocationsChristian König1-2/+2
For GTT allocations with a GART address the res contains the VMID0 addresses and can't be used for VM handling. So ignore the res when the pages array is given or we fill the page tables with nonsense. Signed-off-by: Christian König <christian.koenig@amd.com> Reviewed-by: Nirmoy Das <nirmoy.das@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2021-06-07drm/amdgpu: Fixing "Indirect register access for Navi12 sriov" for vega10Peng Ju Zhou2-3/+4
The NV12 and VEGA10 share the same interface W/RREG32_SOC15*, the callback functions in these macros may not be defined, so NULL pointer must be checked but not in macro __WREG32_SOC15_RLC__, fixing the lock of NULL pointer check. Signed-off-by: Peng Ju Zhou <PengJu.Zhou@amd.com> Reviewed-by: Emily Deng <Emily.Deng@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2021-06-07drm/amdgpu: Update psp fw attestation support listJohn Clements1-0/+3
Disable support on APU Reviewed-by: Changfeng <Changfeng.Zhu@amd.com> Signed-off-by: John Clements <john.clements@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2021-06-07drm/amdkfd: add sdma poison consumption handlingHawking Zhang2-1/+7
Follow the same apporach as GFX to handle SDMA poison consumption. Send SIGBUS to application when receives SDMA_ECC interrupt and issue gpu reset either mode 2 or mode 1 to get the engine back Signed-off-by: Hawking Zhang <Hawking.Zhang@amd.com> Reviewed-by: Dennis Li<dennis.li@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2021-06-07drm/amdkfd: pages_addr offset must be 0 for system rangePhilip Yang1-1/+1
prange->offset is for VRAM range mm_nodes, if multiple ranges share same mm_nodes, migrate range back to VRAM will reuse the VRAM at offset of the same mm_nodes. For system memory pages_addr array, the offset is always 0, otherwise, update GPU mapping will use incorrect system memory page, and cause system memory corruption. Signed-off-by: Philip Yang <Philip.Yang@amd.com> Reviewed-by: Felix Kuehling <Felix.Kuehling@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2021-06-07drm/amdgpu: Modify register access in sdma_v5_2 to use _SOC15 macrosRohit Khaire1-35/+35
In SRIOV environment, KMD should access SDMA registers through RLCG if GC indirect access flag enabled. Using _SOC15 read/write macros ensures that they go through RLC when the flag is enabled. Signed-off-by: Rohit Khaire <rohit.khaire@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2021-06-07drm/ttm: fix warning after moving resource to ghost objChristian König1-0/+1
After we moved the resource to the ghost the bo->resource pointer needs to be reset since the owner of the resource is now the ghost. Signed-off-by: Christian König <christian.koenig@amd.com> Reviewed-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210607175737.1405-1-christian.koenig@amd.com
2021-06-07drm/i915/display: Drop FIXME about turn off infoframesJosé Roberto de Souza1-1/+0
intel_dp_set_infoframes() call in intel_ddi_post_disable_dp() will take care to disable all enabled infoframes. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Reviewed-by: Radhakrishna Sripada <radhakrishna.sripada@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210514232247.144542-4-jose.souza@intel.com
2021-06-07drm/i915/display: Allow fastsets when DP_SDP_VSC infoframe do not match with PSR enabledJosé Roberto de Souza1-1/+16
When PSR is enabled it handles DP_SDP_VSC, changing revision and all the other fields as necessary. It can also enabled and disable this SDP as needed without a full modeset. So here masking DP_SDP_VSC bit when previous and future state PSR enabled, it will still be checked when comparing the asked state to what was programmed to hardware. Cc: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com> Cc: Radhakrishna Sripada <radhakrishna.sripada@intel.com> Reported-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Fixes: 78b772e1a01f ("drm/i915/display: Fill PSR state during hardware configuration read out") Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Reviewed-by: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210514232247.144542-2-jose.souza@intel.com
2021-06-07drm/i915/display: Fix fastsets involving PSRJosé Roberto de Souza1-5/+5
Commit 78b772e1a01f ("drm/i915/display: Fill PSR state during hardware configuration read out") is not allowing fastsets to happen when PSR states changes but PSR is a feature that can be enabled and disabled during fastsets. So here moving the PSR pipe conf checks to a block that is only executed when checking if HW state matches with requested state, not during the phase where it checks if fastset is possible or not. There still a state mismatch not allowing fastsets between states turning off or on PSR because of crtc_state->infoframes.enable BIT(DP_SDP_VSC) but at least for now it will allow a fastset between PSR1 <-> PSR2, that is a case heavilly used by CI due to pipe CRC not work with PSR2, but the remaning issue will be fixed in a future patch. Cc: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com> Cc: Radhakrishna Sripada <radhakrishna.sripada@intel.com> Reported-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Fixes: 78b772e1a01f ("drm/i915/display: Fill PSR state during hardware configuration read out") Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Reviewed-by: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210514232247.144542-1-jose.souza@intel.com
2021-06-07drm/ttm: fix access to uninitialized variable.Christian König1-1/+1
The resource is not allocated yet, so no chance that this will work. Use the placement instead. Signed-off-by: Christian König <christian.koenig@amd.com> Reviewed-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210607171152.15914-1-christian.koenig@amd.com
2021-06-07ice: fix clang warning regarding deadcode.DeadStoresPaul M Stillwell Jr1-5/+1
clang generates deadcode.DeadStores warnings when a variable is used to read a value, but then that value isn't used later in the code. Fix this warning. Signed-off-by: Paul M Stillwell Jr <paul.m.stillwell.jr@intel.com> Tested-by: Tony Brelinski <tonyx.brelinski@intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2021-06-07ice: downgrade error print to debug printAnirudh Venkataramanan1-1/+1
Failing to add or remove LLDP filter doesn't seem to be a fatal error, so downgrade the dev_err message to a dev_dbg message. Signed-off-by: Anirudh Venkataramanan <anirudh.venkataramanan@intel.com> Tested-by: Tony Brelinski <tonyx.brelinski@intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2021-06-07ice: Detect and report unsupported module power levelsAnirudh Venkataramanan5-2/+48
Determine whether an unsupported power configuration is preventing link establishment by storing and checking the link_cfg_err_byte. Print error messages when module power levels are unsupported. Also add a new flag bit to prevent spamming said error messages. Co-developed-by: Jeb Cramer <jeb.j.cramer@intel.com> Signed-off-by: Jeb Cramer <jeb.j.cramer@intel.com> Signed-off-by: Anirudh Venkataramanan <anirudh.venkataramanan@intel.com> Tested-by: Tony Brelinski <tonyx.brelinski@intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2021-06-07ice: (re)initialize NVM fields when rebuildingJacob Keller1-0/+6
After performing a flash update, a device EMP reset may occur. This reset will cause the newly downloaded firmware to be initialized. When this happens, the driver still reports the previous NVM version information. This is because the NVM versions are cached within the hw structure. This can be confusing, as the new firmware is in fact running in this case. Handle this by calling ice_init_nvm when rebuilding the driver state. This will update the flash version information and ensures that the current values are displayed when reporting the NVM versions to the stack. Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Tested-by: Tony Brelinski <tonyx.brelinski@intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2021-06-07ice: wait for reset before reporting devlink infoJacob Keller5-0/+42
Requesting device firmware information while the device is busy cleaning up after a reset can result in an unexpected failure: This occurs because the command is attempting to access the device AdminQ while it is down. Resolve this by having the command wait for a while until the reset is complete. To do this, introduce a reset_wait_queue and associated helper function "ice_wait_for_reset". This helper will use the wait queue to sleep until the driver is done rebuilding. Use of a wait queue is preferred because the potential sleep duration can be several seconds. To ensure that the thread wakes up properly, a new wake_up call is added during all code paths which clear the reset state bits associated with the driver rebuild flow. Using this ensures that tools can request device information without worrying about whether the driver is cleaning up from a reset. Specifically, it is expected that a flash update could result in a device reset, and it is better to delay the response for information until the reset is complete rather than exit with an immediate failure. Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Tested-by: Tony Brelinski <tonyx.brelinski@intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2021-06-07ice: add error message when pldmfw_flash_image failsJacob Keller1-0/+10
When flashing a new firmware image onto the device, the pldmfw library parses the image contents looking for a matching record. If no record can be found, the function reports an error of -ENOENT. This can produce a very confusing error message and experience for the user: $devlink dev flash pci/0000:ab:00.0 file image.bin devlink answers: No such file or directory This is because the ENOENT error code is interpreted as a missing file or directory. The pldmfw library does not have direct access to the extack pointer as it is generic and non-netdevice specific. The only way that ENOENT is returned by the pldmfw library is when no record matches. Catch this specific error and report a suitable extended ack message: $devlink dev flash pci/0000:ab:00.0 file image.bin Error: ice: Firmware image has no record matching this device devlink answers: No such file or directory In addition, ensure that we log an error message to the console whenever this function fails. Because our driver specific PLDM operation functions potentially set the extended ACK message, avoid overwriting this with a generic message. This change should result in an improved experience when attempting to flash an image that does not have a compatible record. Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Tested-by: Tony Brelinski <tonyx.brelinski@intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2021-06-07ice: add extack when unable to read device capsJacob Keller1-0/+3
When filling out information for the DEVLINK_CMD_INFO_GET, the driver needs to read some device capabilities. Add an extack message to properly inform the caller of the failure, as we do for other failures in this function. Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Tested-by: Tony Brelinski <tonyx.brelinski@intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2021-06-07ice: use static inline for dummy functionsJesse Brandeburg5-29/+33
Trivial: The driver had previously attempted to use #define macros to make functions that have no use in certain configs disappear. Using static inlines instead allows for certain static checkers to process the code better, and results in no functional change. Signed-off-by: Jesse Brandeburg <jesse.brandeburg@intel.com> Tested-by: Tony Brelinski <tonyx.brelinski@intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2021-06-07ice: Re-organizes reqstd/avail {R, T}XQ check/code for efficiencySalil Mehta1-6/+8
If user has explicitly requested the number of {R,T}XQs, then it is unnecessary to get the count of already available {R,T}XQs from the PF avail_{r,t}xqs bitmap. This value will get overridden by user specified value in any case. Re-organize this code for improving the flow, readability and efficiency. This scope of improvement was found during the review of the ICE driver code. Fixes: 87324e747fde ("ice: Implement ethtool ops for channels") Cc: intel-wired-lan@lists.osuosl.org Tested-by: Tony Brelinski <tonyx.brelinski@intel.com> Signed-off-by: Salil Mehta <salil.mehta@huawei.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2021-06-07ice: set the value of global config lock timeout longerLiwei Song1-1/+1
It may need hold Global Config Lock a longer time when download DDP package file, extend the timeout value to 5000ms to ensure that download can be finished before other AQ command got time to run, this will fix the issue below when probe the device, 5000ms is a test value that work with both Backplane and BreakoutCable NVM image: ice 0000:f4:00.0: VSI 12 failed lan queue config, error ICE_ERR_CFG ice 0000:f4:00.0: Failed to delete VSI 12 in FW - error: ICE_ERR_AQ_TIMEOUT ice 0000:f4:00.0: probe failed due to setup PF switch: -12 ice: probe of 0000:f4:00.0 failed with error -12 Signed-off-by: Liwei Song <liwei.song@windriver.com> Tested-by: Tony Brelinski <tonyx.brelinski@intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2021-06-07ice: Refactor VIRTCHNL_OP_CONFIG_VSI_QUEUES handlingBrett Creeley3-23/+59
Currently, when a VF requests queue configuration via VIRTCHNL_OP_CONFIG_VSI_QUEUES the PF driver expects that this message will only be called once and we always assume the queues being configured start from 0. This is incorrect and is causing issues when a VF tries to send this message for multiple queue blocks. Fix this by using the queue_id specified in the virtchnl message and allowing for individual Rx and/or Tx queues to be configured. Also, reduce the duplicated for loops for configuring the queues by moving all the logic into a single for loop. Signed-off-by: Brett Creeley <brett.creeley@intel.com> Tested-by: Konrad Jankowski <konrad0.jankowski@intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2021-06-07ice: Refactor ice_setup_rx_ctxKrzysztof Kazimierczak4-56/+78
Move AF_XDP logic and buffer allocation out of ice_setup_rx_ctx() to a new function ice_vsi_cfg_rxq(), so the function actually sets up the Rx context. Signed-off-by: Krzysztof Kazimierczak <krzysztof.kazimierczak@intel.com> Co-developed-by: Tony Nguyen <anthony.l.nguyen@intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com> Tested-by: Kiran Bhandare <kiranx.bhandare@intel.com>
2021-06-07cpufreq: loongson2: Remove unused linux/sched.h headersHailong Liu1-1/+0
Since commit 759f534e93ac(CPUFREQ: Loongson2: drop set_cpus_allowed_ptr()), the header <linux/sched.h> is useless in oongson2_cpufreq.c, so remove it. Signed-off-by: Hailong Liu <liu.hailong6@zte.com.cn> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2021-06-07cpufreq: sh: Remove unused linux/sched.h headersHailong Liu1-1/+0
Since commit '205dcc1ecbc5(cpufreq/sh: Replace racy task affinity logic)' the header <linux/sched.h> is useless in sh-cpufreq.c, so remove it. Signed-off-by: Hailong Liu <liu.hailong6@zte.com.cn> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2021-06-07ice: Save VF's MAC across rebootBrett Creeley2-17/+31
If a VM reboots and/or VF driver is unloaded, its cached hardware MAC address (hw_lan_addr.addr) is cleared in some cases. If the VF is trusted, then the PF driver allows the VF to clear its old MAC address even if this MAC was configured by a host administrator. If the VF is untrusted, then the PF driver allows the VF to clear its old MAC address only if the host admin did not set it. For the trusted VF case, this is unexpected and will cause issues because the host configured MAC (i.e. via XML) will be cleared on VM reboot. For the untrusted VF case, this is done to be consistent and it will allow the VF to keep the same MAC across VM reboot. Fix this by introducing dev_lan_addr to the VF structure. This will be the VF's MAC address when it's up and running and in most cases will be the same as the hw_lan_addr. However, to address the VM reboot and unload/reload problem, the driver will never allow the hw_lan_addr to be cleared via VIRTCHNL_OP_DEL_ETH_ADDR. When the VF's MAC is changed, the dev_lan_addr and hw_lan_addr will always be updated with the same value. The only ways the VF's MAC can change are the following: - Set the VF's MAC administratively on the host via iproute2. - If the VF is trusted and changes/sets its own MAC. - If the VF is untrusted and the host has not set the MAC via iproute2. Signed-off-by: Brett Creeley <brett.creeley@intel.com> Tested-by: Konrad Jankowski <konrad0.jankowski@intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2021-06-07ice: Manage VF's MAC address for both legacy and new casesBrett Creeley2-27/+141
Currently there is no way for a VF driver to specify if it wants to change it's hardware address. New bits are being added to virtchnl.h in struct virtchnl_ether_addr that allow for the VF to correctly communicate this information. However, legacy VF drivers that don't support the new virtchnl.h bits still need to be supported. Make a best effort attempt at saving the VF's primary/device address in the legacy case and depend on the VIRTCHNL_ETHER_ADDR_PRIMARY type for the new case. Legacy case - If a unicast MAC is being added and the hw_lan_addr.addr is empty, then populate it. This assumes that the address is the VF's hardware address. If a unicast MAC is being added and the hw_lan_addr.addr is not empty, then cache it in the legacy_last_added_umac.addr. If a unicast MAC is being deleted and it matches the hw_lan_addr.addr, then zero the hw_lan_addr.addr. Also, if the legacy_last_added_umac.addr has not expired, copy the legacy_last_added_umac.addr into the hw_lan_addr.addr. This is done because we cannot guarantee the order of VIRTCHNL_OP_ADD_ETH_ADDR and VIRTCHNL_OP_DEL_ETH_ADDR. New case - If a unicast MAC is being added and it's specified as VIRTCHNL_ETHER_ADDR_PRIMARY, then replace the current hw_lan_addr.addr. If a unicast MAC is being deleted and it's type is specified as VIRTCHNL_ETHER_ADDR_PRIMARY, then zero the hw_lan_addr.addr. Untrusted VFs - Only allow above legacy/new changes to their hardware address if the PF has not set it administratively via iproute2. Trusted VFs - Always allow above legacy/new changes to their hardware address even if the PF has administratively set it via iproute2. Also, change the variable dflt_lan_addr to hw_lan_addr to clearly represent the purpose of this variable since it's purpose is to act as a hardware programmed MAC address for the VF. Signed-off-by: Brett Creeley <brett.creeley@intel.com> Tested-by: Konrad Jankowski <konrad0.jankowski@intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2021-06-07spi: hisi-kunpeng: Add debugfs supportJay Fang1-1/+50
This patch uses debugfs_regset32 interface to create the registers dump file. Use it instead of creating a generic debugfs file with manually written read callback function. With these entries, users can check all the SPI controller registers during run time. Signed-off-by: Jay Fang <f.fangjian@huawei.com> Link: https://lore.kernel.org/r/1622789718-13977-1-git-send-email-f.fangjian@huawei.com Signed-off-by: Mark Brown <broonie@kernel.org>
2021-06-07regulator: mt6359: Get rid of linear_range tablesAxel Lin1-98/+59
The MT6359_BUCK and MT6359_LDO_LINEAR macros setup both linear settings (min_uV, uV_step, linear_min_sel) and linar_range (linear_ranges, n_linear_ranges) settings. All the linear range tables actually only has one entry. Let's simplify it by using linear instead of linear range. The linear_min_sel setting is 0 for all cases, remove it from the macros. Signed-off-by: Axel Lin <axel.lin@ingics.com> Link: https://lore.kernel.org/r/20210606065052.1417111-3-axel.lin@ingics.com Signed-off-by: Mark Brown <broonie@kernel.org>
2021-06-07regulator: mt6359: Use unsigned int for volt_tablesAxel Lin1-18/+18
The regulator_desc expects "const unsigned int *volt_table", thus use unsigned int instead of u32. Signed-off-by: Axel Lin <axel.lin@ingics.com> Link: https://lore.kernel.org/r/20210606065052.1417111-2-axel.lin@ingics.com Signed-off-by: Mark Brown <broonie@kernel.org>
2021-06-07regulator: mt6358: Use unsigned int for volt_tablesAxel Lin1-11/+11
The regulator_desc expects "const unsigned int *volt_table", thus use unsigned int instead of u32. Signed-off-by: Axel Lin <axel.lin@ingics.com> Link: https://lore.kernel.org/r/20210606065052.1417111-1-axel.lin@ingics.com Signed-off-by: Mark Brown <broonie@kernel.org>
2021-06-07regulator: max77686: Convert to use regulator_set_ramp_delay_regmapAxel Lin1-33/+9
Use regulator_set_ramp_delay_regmap instead of open-coded. Signed-off-by: Axel Lin <axel.lin@ingics.com> Link: https://lore.kernel.org/r/20210605013424.1298773-1-axel.lin@ingics.com Signed-off-by: Mark Brown <broonie@kernel.org>
2021-06-07Merge tag 'tb-mfd-regulator-rtc-v5.14' of git://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd into regulator-5.14Mark Brown6-28/+1133
Immutable branch between MFD, Regulator and RTC due for the v5.14 merge window
2021-06-07regmap-irq: Introduce inverted status registers supportMaxim Kochetkov1-0/+7
Some interrupt controllers have inverted status register: cleared bits is active interrupts and set bits is inactive interrupts, so add inverted status support to the framework. Signed-off-by: Maxim Kochetkov <fido_max@inbox.ru> Link: https://lore.kernel.org/r/20210525034204.5272-1-fido_max@inbox.ru Signed-off-by: Mark Brown <broonie@kernel.org>
2021-06-07s390: use struct tpi_info in lowcore.hSven Schnelle1-4/+2
Signed-off-by: Sven Schnelle <svens@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com> Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
2021-06-07s390: add struct tpi_info to struct pt_regsSven Schnelle2-2/+2
To avoid casting ptrace members, add a union containing both struct tpi_info and explicit int_code/int_parm members. Signed-off-by: Sven Schnelle <svens@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com> Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
2021-06-07s390/cio: add tpi.h header fileSven Schnelle1-12/+1
For future work we need the struct tpi_info declaration in asm/ptrace.h. Due to circular dependencies it cannot stay in asm/lowcore.h or asm/cio.h, which would be the preferred location. Therefore add it in its own header file. Also fix a typo in the length of a reserved field that did not have a functional effect beyond an incorrect field value in the s390_cio_tpi tracepoint. Fixes: 2ab59de7c5ce ("s390/cio: Consolidate inline assemblies and related data definitions") Signed-off-by: Sven Schnelle <svens@linux.ibm.com> Acked-by: Peter Oberparleiter <oberpar@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com> Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
2021-06-07s390/ccwgroup: use BUS_NOTIFY_UNBOUND_DRIVER to trigger ungroupingJulian Wiedmann1-1/+1
ccwgroup_notifier() currently listens for BUS_NOTIFY_UNBIND_DRIVER events, and triggers an ungrouping for the affected device. Looking at __device_release_driver(), we can wait for a little longer until the driver has been fully unbound and eg. bus->remove() has been called. So listen for BUS_NOTIFY_UNBOUND_DRIVER instead. Due to locking the current code should work just fine, but this clarifies our intent. Signed-off-by: Julian Wiedmann <jwi@linux.ibm.com> Reviewed-by: Vineeth Vijayan <vneethv@linux.ibm.com> Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
2021-06-07s390/ccwgroup: simplify ungrouping when driver deregistersJulian Wiedmann1-9/+0
driver_unregister() ends up calling __device_release_driver() for each device that is bound to the driver. Thus ccwgroup_notifier() will see a BUS_NOTIFY_UNBIND_DRIVER event for these ccwgroup devices, and trigger the ungrouping. So there's no need to also trigger the ungrouping from within ccwgroup_driver_unregister(), remove it. Signed-off-by: Julian Wiedmann <jwi@linux.ibm.com> Reviewed-by: Vineeth Vijayan <vneethv@linux.ibm.com> Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
2021-06-07s390/vfio-ap: clean up vfio_ap_drv's definitionJulian Wiedmann1-7/+6
Define & initialize the driver struct in one go, so that everything is in one place. Signed-off-by: Julian Wiedmann <jwi@linux.ibm.com> Reviewed-by: Halil Pasic <pasic@linux.ibm.com> Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
2021-06-07s390/ap: extend AP change bindings-complete uevent with counterHarald Freudenberger1-2/+8
Userspace udev rules need an indication about the very first AP change BINDINGS=complete uevent. So now this uevent is extend with an additional key-value entry COMPLETECOUNT=<counter>. The very first uevent will show counter=1 and the following BINDINGS=complete uevents increase this counter by 1. Here is an example how the very first BINDINGS=complete uevent looks like: KERNEL[106.079510] change /devices/ap (ap) ACTION=change DEVPATH=/devices/ap SUBSYSTEM=ap BINDINGS=complete COMPLETECOUNT=1 SEQNUM=10686 Signed-off-by: Harald Freudenberger <freude@linux.ibm.com> Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
2021-06-07s390/sclp_vt220: fix console name to match deviceValentin Vidic1-2/+2
Console name reported in /proc/consoles: ttyS1 -W- (EC p ) 4:65 does not match the char device name: crw--w---- 1 root root 4, 65 May 17 12:18 /dev/ttysclp0 so debian-installer inside a QEMU s390x instance gets confused and fails to start with the following error: steal-ctty: No such file or directory Signed-off-by: Valentin Vidic <vvidic@valentin-vidic.from.hr> Link: https://lore.kernel.org/r/20210427194010.9330-1-vvidic@valentin-vidic.from.hr Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com> Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
2021-06-07s390/ccwgroup: release the cdevs from within dev->release()Julian Wiedmann1-32/+17
Wiring up the cdevs is an essential part of the gdev creation. So release them during the gdev destruction, ie. on the last put_device(). This could cause us to hold on to the cdevs a tiny bit longer, but that's not a real concern. As we have much less certainty of what context this put_device() is executed from, switch to irqsave locking. Signed-off-by: Julian Wiedmann <jwi@linux.ibm.com> Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
2021-06-07s390/ap: wire up bus->probe and bus->removeJulian Wiedmann1-2/+2
Hijacking the device_driver's probe/remove callbacks for purely bus-internal logic is a very unconvential construct. Instead just set up our callbacks in the AP bus struct, and really_probe() will call them in the same way as before. Signed-off-by: Julian Wiedmann <jwi@linux.ibm.com> Reviewed-by: Harald Freudenberger <freude@linux.ibm.com> Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
2021-06-07s390/zcrypt: remove zcrypt_device_countJulian Wiedmann3-4/+0
It's evidently unused. Signed-off-by: Julian Wiedmann <jwi@linux.ibm.com> Reviewed-by: Harald Freudenberger <freude@linux.ibm.com> Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
2021-06-07s390/crypto: fix function/prototype mismatchesSven Schnelle2-6/+6
gcc-11 warns: drivers/s390/crypto/zcrypt_ccamisc.c:298:38: warning: argument 4 of type u8[64] {aka unsigned char[64]} with mismatched bound [-Warray-parameter=] 298 | u32 keybitsize, u8 seckey[SECKEYBLOBSIZE]) | ~~~^~~~~~~~~~~~~~~~~~~~~~ In file included from drivers/s390/crypto/zcrypt_ccamisc.c:24: drivers/s390/crypto/zcrypt_ccamisc.h:162:63: note: previously declared as u8 * {aka unsigned char *} 162 | int cca_genseckey(u16 cardnr, u16 domain, u32 keybitsize, u8 *seckey); | ~~~~^~~~~~ drivers/s390/crypto/zcrypt_ccamisc.c:441:41: warning: argument 5 of type u8[64] {aka unsigned char[64]} with mismatched bound [-Warray-parameter=] 441 | const u8 *clrkey, u8 seckey[SECKEYBLOBSIZE]) | ~~~^~~~~~~~~~~~~~~~~~~~~~ In file included from drivers/s390/crypto/zcrypt_ccamisc.c:24: drivers/s390/crypto/zcrypt_ccamisc.h:168:42: note: previously declared as u8 * {aka unsigned char *} 168 | const u8 *clrkey, u8 *seckey); | ~~~~^~~~~~ Fix this by making the prototypes match the functions. Signed-off-by: Sven Schnelle <svens@linux.ibm.com> Cc: Harald Freudenberger <freude@linux.ibm.com> Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
2021-06-07drm/hyperv: Handle feature change message from deviceDeepak Rawat3-0/+10
Virtual device inform if screen update is needed or not with SYNTHVID_FEATURE_CHANGE message. Handle this message to set dirt_needed flag. Suggested-by: Dexuan Cui <decui@microsoft.com> Signed-off-by: Deepak Rawat <drawat.floss@gmail.com> Acked-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patchwork.freedesktop.org/patch/msgid/20210527112230.1274-2-drawat.floss@gmail.com
2021-06-07drm/hyperv: Add DRM driver for hyperv synthetic video deviceDeepak Rawat7-0/+1091
DRM driver for hyperv synthetic video device, based on hyperv_fb framebuffer driver. Also added config option "DRM_HYPERV" to enabled this driver. v2: - Add support for gen2 VM - Fixed review comments v3: - Split into multiple files as suggested by Thomas Zimmermann - Fixed hibernation issue as suggested by Dexuan Cui - Use ioremap_cache as suggested by Dexuan Cui - Incorporated other review comments v4: - Fix bitrotted code - Review comments - Updated the copyright and license to match hyperv_fb v5: - Address review comments and rebased with drm-misc-next v6: - Minor code/comment improvement as suggested by Dexuan Cui Signed-off-by: Deepak Rawat <drawat.floss@gmail.com> Acked-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patchwork.freedesktop.org/patch/msgid/20210527112230.1274-1-drawat.floss@gmail.com
2021-06-07ACPI: scan: Add function to fetch dependent of ACPI deviceDaniel Scally1-0/+35
In some ACPI tables we encounter, devices use the _DEP method to assert a dependence on other ACPI devices as opposed to the OpRegions that the specification intends. We need to be able to find those devices "from" the dependee, so add a callback and a wrapper to walk over the acpi_dep_list and return the dependent ACPI device. Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Signed-off-by: Daniel Scally <djrscally@gmail.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>