aboutsummaryrefslogtreecommitdiffstats
path: root/drivers
AgeCommit message (Collapse)AuthorFilesLines
2021-06-10drm/amd/pm: Add navi1x throttler translationGraham Sider1-0/+34
Perform dependent to independent throttle status translation for navi1x. Signed-off-by: Graham Sider <Graham.Sider@amd.com> Reviewed-by: Evan Quan <evan.quan@amd.com> Reviewed-by: Lijo Lazar <lijo.lazar@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2021-06-10drm/amd/pm: Add arcturus throttler translationGraham Sider1-5/+28
Perform dependent to independent throttle status translation for arcturus. Signed-off-by: Graham Sider <Graham.Sider@amd.com> Reviewed-by: Evan Quan <evan.quan@amd.com> Reviewed-by: Lijo Lazar <lijo.lazar@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2021-06-10drm/amd/pm: Add common throttler translation funcGraham Sider2-0/+17
Defines smu_cmn_get_indep_throttler_status which performs ASIC independent translation given a corresponding lookup table. Signed-off-by: Graham Sider <Graham.Sider@amd.com> Reviewed-by: Evan Quan <evan.quan@amd.com> Reviewed-by: Lijo Lazar <lijo.lazar@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2021-06-10drm/amd/pm: Add ASIC independent throttle bitsGraham Sider1-0/+42
Add new defines for thermal throttle status bits which are ASIC independent. This bit field will be visible to userspace via gpu_metrics alongside the previous ASIC dependent bit fields. Seperated into four types: power throttlers (16 bits), current throttlers (16 bits), temperature (24 bits), other (8 bits). Signed-off-by: Graham Sider <Graham.Sider@amd.com> Reviewed-by: Evan Quan <evan.quan@amd.com> Reviewed-by: Lijo Lazar <lijo.lazar@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2021-06-10drm/amd/pm: Add u64 throttler status field to gpu_metricsGraham Sider2-1/+60
This patch set adds support for a new ASIC independant u64 throttler status field (indep_throttle_status). Piggybacks off the gpu_metrics_v1_3 bump and similarly bumps gpu_metrics_v2 version (to v2_2) to add field. Signed-off-by: Graham Sider <Graham.Sider@amd.com> Reviewed-by: Evan Quan <evan.quan@amd.com> Reviewed-by: Lijo Lazar <lijo.lazar@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2021-06-10drm/amdgpu: Added support for loading auxiliary PSP FWJohn Clements1-8/+46
In the case with xgmi connected to cpu load alternate psp fw Reviewed-by: Hawking Zhang <Hawking.Zhang@amd.com> Signed-off-by: John Clements <john.clements@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2021-06-10drm/amdgpu: Updated fw header structure sourceJohn Clements3-60/+56
synchronized fw header with latest source Reviewed-by: Hawking Zhang <Hawking.Zhang@amd.com> Signed-off-by: John Clements <john.clements@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2021-06-10drm/amdkfd: use allowed domain for vmbo validationNirmoy Das1-17/+4
Fixes handling when page tables are in system memory. v3: remove struct amdgpu_vm_parser. v2: remove unwanted variable. change amdgpu_amdkfd_validate instead of amdgpu_amdkfd_bo_validate. Signed-off-by: Nirmoy Das <nirmoy.das@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Reviewed-by: Felix Kuehling <Felix.Kuehling@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2021-06-10hwmon: (tps23861) correct shunt LSB valuesRobert Marko1-2/+2
Current shunt LSB values got reversed during in the original driver commit. So, correct the current shunt LSB values according to the datasheet. This caused reading slightly skewed current values. Fixes: fff7b8ab2255 ("hwmon: add Texas Instruments TPS23861 driver") Signed-off-by: Robert Marko <robert.marko@sartura.hr> Link: https://lore.kernel.org/r/20210609220728.499879-3-robert.marko@sartura.hr Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2021-06-10hwmon: (tps23861) set current shunt valueRobert Marko1-0/+12
TPS23861 has a configuration bit for setting of the current shunt value used on the board. Its bit 0 of the General Mask 1 register. According to the datasheet bit values are: 0 for 255 mOhm (Default) 1 for 250 mOhm So, configure the bit before registering the hwmon device according to the value passed in the DTS or default one if none is passed. This caused potentially reading slightly skewed values due to max current value being 1.02A when 250mOhm shunt is used instead of 1.0A when 255mOhm is used. Fixes: fff7b8ab2255 ("hwmon: add Texas Instruments TPS23861 driver") Signed-off-by: Robert Marko <robert.marko@sartura.hr> Link: https://lore.kernel.org/r/20210609220728.499879-2-robert.marko@sartura.hr Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2021-06-10hwmon: (tps23861) define regmap max registerRobert Marko1-0/+1
Define the max register address the device supports. This allows reading the whole register space via regmap debugfs, without it only register 0x0 is visible. This was forgotten in the original driver commit. Fixes: fff7b8ab2255 ("hwmon: add Texas Instruments TPS23861 driver") Signed-off-by: Robert Marko <robert.marko@sartura.hr> Link: https://lore.kernel.org/r/20210609220728.499879-1-robert.marko@sartura.hr Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2021-06-10memory: pl353-smc: Declare variables following a reverse christmas tree orderMiquel Raynal1-3/+3
This is a purely cosmetic change. Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/r/20210610082040.2075611-15-miquel.raynal@bootlin.com Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
2021-06-10memory: pl353-smc: Avoid useless acronyms in descriptionsMiquel Raynal1-1/+1
APER does not mean anything, while it seems legitimate to call this clock the AXI peripheral clock. Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/r/20210610082040.2075611-14-miquel.raynal@bootlin.com Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
2021-06-10memory: pl353-smc: Let lower level controller drivers handle initsMiquel Raynal1-294/+0
There is no point in having all these definitions at the SMC bus level, these are extremely tight to the NAND controller driver implementation, are not particularly generic, imply more boilerplate than needed, do not really follow the device model by receiving no argument and some of them are actually buggy. Let's get rid of these right now as there is no current user and keep this driver at a simple level: only the SMC bare initializations. The NAND controller driver which I am going to introduce will take care of redefining properly all these helpers and using them directly. Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/r/20210610082040.2075611-13-miquel.raynal@bootlin.com Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
2021-06-10memory: pl353-smc: Rename goto labelsMiquel Raynal1-4/+4
A goto label is better named do_something: than out_something_to_do: Use the former wording and really describe what the jump involves. Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/r/20210610082040.2075611-12-miquel.raynal@bootlin.com Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
2021-06-10memory: pl353-smc: Fix styleMiquel Raynal1-2/+2
Use proper spacing. Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/r/20210610082040.2075611-11-miquel.raynal@bootlin.com Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
2021-06-10USB: serial: cp210x: fix CP2102N-A01 modem controlJohan Hovold1-5/+59
CP2102N revision A01 (firmware version <= 1.0.4) has a buggy flow-control implementation that uses the ulXonLimit instead of ulFlowReplace field of the flow-control settings structure (erratum CP2102N_E104). A recent change that set the input software flow-control limits incidentally broke RTS control for these devices when CRTSCTS is not set as the new limits would always enable hardware flow control. Fix this by explicitly disabling flow control for the buggy firmware versions and only updating the input software flow-control limits when IXOFF is requested. This makes sure that the terminal settings matches the default zero ulXonLimit (ulFlowReplace) for these devices. Link: https://lore.kernel.org/r/20210609161509.9459-1-johan@kernel.org Reported-by: David Frey <dpfrey@gmail.com> Reported-by: Alex Villacís Lasso <a_villacis@palosanto.com> Tested-by: Alex Villacís Lasso <a_villacis@palosanto.com> Fixes: f61309d9c96a ("USB: serial: cp210x: set IXOFF thresholds") Cc: stable@vger.kernel.org # 5.12 Signed-off-by: Johan Hovold <johan@kernel.org>
2021-06-10drm/msm/dsi: Stash away calculated vco frequency on recalcStephen Boyd2-0/+2
A problem was reported on CoachZ devices where the display wouldn't come up, or it would be distorted. It turns out that the PLL code here wasn't getting called once dsi_pll_10nm_vco_recalc_rate() started returning the same exact frequency, down to the Hz, that the bootloader was setting instead of 0 when the clk was registered with the clk framework. After commit 001d8dc33875 ("drm/msm/dsi: remove temp data from global pll structure") we use a hardcoded value for the parent clk frequency, i.e. VCO_REF_CLK_RATE, and we also hardcode the value for FRAC_BITS, instead of getting it from the config structure. This combination of changes to the recalc function allows us to properly calculate the frequency of the PLL regardless of whether or not the PLL has been clk_prepare()d or clk_set_rate()d. That's a good improvement. Unfortunately, this means that now we won't call down into the PLL clk driver when we call clk_set_rate() because the frequency calculated in the framework matches the frequency that is set in hardware. If the rate is the same as what we want it should be OK to not call the set_rate PLL op. The real problem is that the prepare op in this driver uses a private struct member to stash away the vco frequency so that it can call the set_rate op directly during prepare. Once the set_rate op is never called because recalc_rate told us the rate is the same, we don't set this private struct member before the prepare op runs, so we try to call the set_rate function directly with a frequency of 0. This effectively kills the PLL and configures it for a rate that won't work. Calling set_rate from prepare is really quite bad and will confuse any downstream clks about what the rate actually is of their parent. Fixing that will be a rather large change though so we leave that to later. For now, let's stash away the rate we calculate during recalc so that the prepare op knows what frequency to set, instead of 0. This way things keep working and the display can enable the PLL properly. In the future, we should remove that code from the prepare op so that it doesn't even try to call the set rate function. Cc: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Cc: Abhinav Kumar <abhinavk@codeaurora.org> Fixes: 001d8dc33875 ("drm/msm/dsi: remove temp data from global pll structure") Signed-off-by: Stephen Boyd <swboyd@chromium.org> Link: https://lore.kernel.org/r/20210608195519.125561-1-swboyd@chromium.org Signed-off-by: Rob Clark <robdclark@chromium.org>
2021-06-10drm/i915: apply WaEnableVGAAccessThroughIOPort as neededEmil Velikov1-0/+3
Currently as the workaround is applied the screen flickers. As a result we do not achieve seamless boot experience. Avoiding the issue in the common use-case might be hard, although we can resolve it for dual GPU setups - when the "other" GPU is primary and/or outputs are connected to it. With this I was able to get seamless experience on my Intel/Nvidia box, running systemd-boot and sddm/Xorg. Note that the i915 driver is within initrd while the Nvidia one is not. Without this patch, the splash presented by systemd-boot (UEFI BGRT) is torn down as the code-path kicks in, leaving the monitor blank until the login manager starts. Same issue were reported with plymouth/grub, although personally I wasn't able to get them to behave on my setup. Suggested-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Emil Velikov <emil.velikov@collabora.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210604154905.660142-1-emil.l.velikov@gmail.com
2021-06-10usb: cdns3: cdns3-gadget: Use list_move_tail instead of list_del/list_add_tailBaokun Li1-3/+1
Using list_move_tail() instead of list_del() + list_add_tail(). Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: Baokun Li <libaokun1@huawei.com> Link: https://lore.kernel.org/r/20210609072720.1358527-1-libaokun1@huawei.com Signed-off-by: Peter Chen <peter.chen@kernel.org>
2021-06-10scsi: lpfc: vmid: Introduce VMID in I/O pathGaurav Srivastava1-0/+174
Introduce the VMID in the I/O path. Check if the VMID is enabled and if the I/O belongs to a VM or not. Link: https://lore.kernel.org/r/20210608043556.274139-14-muneendra.kumar@broadcom.com Reviewed-by: Hannes Reinecke <hare@suse.de> Signed-off-by: Gaurav Srivastava <gaurav.srivastava@broadcom.com> Signed-off-by: James Smart <jsmart2021@gmail.com> Signed-off-by: Muneendra Kumar <muneendra.kumar@broadcom.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2021-06-10scsi: lpfc: vmid: Add QFPA and VMID timeout check in worker threadGaurav Srivastava1-0/+43
Add a periodic check for issuing of QFPA command and VMID timeout in the worker thread. The inactivity timeout check is added via the timer function. Link: https://lore.kernel.org/r/20210608043556.274139-13-muneendra.kumar@broadcom.com Reviewed-by: Hannes Reinecke <hare@suse.de> Signed-off-by: Gaurav Srivastava <gaurav.srivastava@broadcom.com> Signed-off-by: James Smart <jsmart2021@gmail.com> Signed-off-by: Muneendra Kumar <muneendra.kumar@broadcom.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2021-06-10scsi: lpfc: vmid: Timeout implementation for VMIDGaurav Srivastava2-0/+145
Implement timeout functionality for the VMID. After the set time period of inactivity, the VMID is deregistered from the switch. Link: https://lore.kernel.org/r/20210608043556.274139-12-muneendra.kumar@broadcom.com Reviewed-by: Hannes Reinecke <hare@suse.de> Signed-off-by: Gaurav Srivastava <gaurav.srivastava@broadcom.com> Signed-off-by: James Smart <jsmart2021@gmail.com> Signed-off-by: Muneendra Kumar <muneendra.kumar@broadcom.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2021-06-10scsi: lpfc: vmid: Append the VMID to the wqe before sendingGaurav Srivastava1-0/+14
Add the VMID in wqe before sending out the request. The type of VMID depends on the configured type and is checked before being appended. Link: https://lore.kernel.org/r/20210608043556.274139-11-muneendra.kumar@broadcom.com Reviewed-by: Hannes Reinecke <hare@suse.de> Signed-off-by: Gaurav Srivastava <gaurav.srivastava@broadcom.com> Signed-off-by: James Smart <jsmart2021@gmail.com> Signed-off-by: Muneendra Kumar <muneendra.kumar@broadcom.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2021-06-10scsi: lpfc: vmid: Implement CT commands for appidGaurav Srivastava1-0/+255
Implement CT commands for registering and deregistering the appid for the application. Also, a small change in decrementing the ndlp ref counter has been added. Link: https://lore.kernel.org/r/20210608043556.274139-10-muneendra.kumar@broadcom.com Reviewed-by: Hannes Reinecke <hare@suse.de> Signed-off-by: Gaurav Srivastava <gaurav.srivastava@broadcom.com> Signed-off-by: James Smart <jsmart2021@gmail.com> Signed-off-by: Muneendra Kumar <muneendra.kumar@broadcom.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2021-06-10scsi: lpfc: vmid: Functions to manage VMIDsGaurav Srivastava1-0/+118
Implement routines to save, retrieve, and remove the VMIDs from the data structure. A hash table is used to save the VMIDs and the corresponding UUIDs associated with the application/VMs. Link: https://lore.kernel.org/r/20210608043556.274139-9-muneendra.kumar@broadcom.com Reviewed-by: Hannes Reinecke <hare@suse.de> Signed-off-by: Gaurav Srivastava <gaurav.srivastava@broadcom.com> Signed-off-by: James Smart <jsmart2021@gmail.com> Signed-off-by: Muneendra Kumar <muneendra.kumar@broadcom.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2021-06-10scsi: lpfc: vmid: Implement ELS commands for appidGaurav Srivastava1-4/+362
Implement ELS commands QFPA and UVEM for the priority tagging appid support. Link: https://lore.kernel.org/r/20210608043556.274139-8-muneendra.kumar@broadcom.com Reviewed-by: Hannes Reinecke <hare@suse.de> Signed-off-by: Gaurav Srivastava <gaurav.srivastava@broadcom.com> Signed-off-by: James Smart <jsmart2021@gmail.com> Signed-off-by: Muneendra Kumar <muneendra.kumar@broadcom.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2021-06-10scsi: lpfc: vmid: Add support for VMID in mailbox commandGaurav Srivastava5-0/+114
Add supporting datastructures for mailbox command which helps in determining if the firmware supports appid. Allocate resources for VMID at initialization time and clean them up on removal. Link: https://lore.kernel.org/r/20210608043556.274139-7-muneendra.kumar@broadcom.com Reviewed-by: Hannes Reinecke <hare@suse.de> Signed-off-by: Gaurav Srivastava <gaurav.srivastava@broadcom.com> Signed-off-by: James Smart <jsmart2021@gmail.com> Signed-off-by: Muneendra Kumar <muneendra.kumar@broadcom.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2021-06-10scsi: lpfc: vmid: VMID parameter initializationGaurav Srivastava1-0/+48
Initialize parameters such as type of VMID, max number of VMIDs supported and timeout value for the VMID registration based on the user input. Link: https://lore.kernel.org/r/20210608043556.274139-6-muneendra.kumar@broadcom.com Reviewed-by: Hannes Reinecke <hare@suse.de> Signed-off-by: Gaurav Srivastava <gaurav.srivastava@broadcom.com> Signed-off-by: James Smart <jsmart2021@gmail.com> Signed-off-by: Muneendra Kumar <muneendra.kumar@broadcom.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2021-06-10scsi: lpfc: vmid: Add datastructure for supporting VMID in lpfcGaurav Srivastava5-4/+262
Add the primary datastructures needed to implement VMID in the lpfc driver. Maintain the capability, current state, and hash table for the vmid/appid along with other information. This implementation supports the two versions of vmid implementation (app header and priority tagging). Link: https://lore.kernel.org/r/20210608043556.274139-5-muneendra.kumar@broadcom.com Reviewed-by: Hannes Reinecke <hare@suse.de> Signed-off-by: Gaurav Srivastava <gaurav.srivastava@broadcom.com> Signed-off-by: James Smart <jsmart2021@gmail.com> Signed-off-by: Muneendra Kumar <muneendra.kumar@broadcom.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2021-06-10scsi: nvme: Added a new sysfs attribute appid_storeMuneendra Kumar1-1/+71
Add a new sysfs attribute, appid_store, which can be used to set the application identifier in the blkcg associated with a cgroup id. Below is the interface provided to set the app_id: echo "<cgroupid>:<appid>" >> /sys/class/fc/fc_udev_device/appid_store echo "457E:100000109b521d27" >> /sys/class/fc/fc_udev_device/appid_store Link: https://lore.kernel.org/r/20210608043556.274139-4-muneendra.kumar@broadcom.com Reviewed-by: Himanshu Madhani <himanshu.madhani@oracle.com> Reviewed-by: Hannes Reinecke <hare@suse.de> Signed-off-by: Muneendra Kumar <muneendra.kumar@broadcom.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2021-06-10scsi: blkcg: Add app identifier support for blkcgMuneendra Kumar1-0/+13
Add a unique application identifier (i.e fc_app_id member) in blkcg. This allows identification of traffic belonging to an specific both on the host and in the fabric infrastructure. As an example, this allows the storage stack to uniquely identify traffic belong to particular virtual machine. Link: https://lore.kernel.org/r/20210608043556.274139-3-muneendra.kumar@broadcom.com Reviewed-by: Himanshu Madhani <himanshu.madhani@oracle.com> Reviewed-by: Hannes Reinecke <hare@suse.de> Acked-by: Tejun Heo <tj@kernel.org> Signed-off-by: Muneendra Kumar <muneendra.kumar@broadcom.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2021-06-10clk: renesas: Add support for R9A07G044 SoCLad Prabhakar5-0/+141
Define the clock outputs supported by RZ/G2L (R9A07G044) SoC and bind it with RZ/G2L CPG core. Based on a patch in the BSP by Binh Nguyen <binh.nguyen.jz@renesas.com>. Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> Reviewed-by: Biju Das <biju.das.jz@bp.renesas.com> Link: https://lore.kernel.org/r/20210609153230.6967-10-prabhakar.mahadev-lad.rj@bp.renesas.com Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2021-06-10clk: renesas: Add CPG core wrapper for RZ/G2L SoCLad Prabhakar4-0/+883
Add CPG core wrapper for RZ/G2L family. Based on a patch in the BSP by Binh Nguyen <binh.nguyen.jz@renesas.com>. Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> Reviewed-by: Biju Das <biju.das.jz@bp.renesas.com> Link: https://lore.kernel.org/r/20210609153230.6967-9-prabhakar.mahadev-lad.rj@bp.renesas.com Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2021-06-10soc: renesas: Add support to read LSI DEVID register of RZ/G2{L,LC} SoC'sLad Prabhakar1-1/+32
Add support for reading the LSI DEVID register which is present in SYSC block of RZ/G2{L,LC} SoC's. Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> Reviewed-by: Biju Das <biju.das.jz@bp.renesas.com> Link: https://lore.kernel.org/r/20210609163717.3083-3-prabhakar.mahadev-lad.rj@bp.renesas.com Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2021-06-10soc: renesas: Add ARCH_R9A07G044 for the new RZ/G2L SoC'sLad Prabhakar1-0/+5
Add ARCH_R9A07G044 as a configuration symbol for the new Renesas RZ/G2L SoC variants. Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> Reviewed-by: Biju Das <biju.das.jz@bp.renesas.com> Link: https://lore.kernel.org/r/20210609153230.6967-5-prabhakar.mahadev-lad.rj@bp.renesas.com Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2021-06-10ACPI: scan: initialize local variable to avoid garbage being returnedColin Ian King1-1/+1
In the unlikely event that there are no callback calls made in acpi_walk_dep_device_list(), local variable ret will be returned as an uninitialized value. Clean up static analysis warnings by ensuring ret is initialized. Addresses-Coverity: ("Uninitialized scalar variable") Fixes: a9e10e587304 ("ACPI: scan: Extend acpi_walk_dep_device_list()") Signed-off-by: Colin Ian King <colin.king@canonical.com> Reviewed-by: Daniel Scally <djrscally@gmail.com> [ rjw: Subject and changelog edits ] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2021-06-10ACPI: Remove redundant clearing of context->ret.pointer from acpi_run_osc()Hans de Goede1-2/+0
context->ret.pointer already gets set to NULL at the beginning of acpi_run_osc() and it only gets assigned a new value in the success path near the end of acpi_run_osc(), so the clearing of context->ret.pointer (when status != AE_OK) at the end of acpi_run_osc() is redundant since it will always already be NULL when status != AE_OK. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2021-06-10drm/etnaviv: add HWDB entry for GC7000 rev 6204Sascha Hauer1-0/+31
This is the 3D GPU found on the i.MX8MP SoC. The feature bits are taken from the NXP downstream kernel driver 6.4.3.p1.305572. Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de> Signed-off-by: Lucas Stach <l.stach@pengutronix.de> Reviewed-by: Christian Gmeiner <christian.gmeiner@gmail.com>
2021-06-10ACPI: Add \_SB._OSC bit for PRMErik Kaneda1-0/+1
Signed-off-by: Erik Kaneda <erik.kaneda@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2021-06-10ACPI: PRM: implement OperationRegion handler for the PlatformRtMechanism subtypeErik Kaneda5-0/+320
Platform Runtime Mechanism (PRM) is a firmware interface that exposes a set of binary executables that can either be called from the AML interpreter or device drivers by bypassing the AML interpreter. This change implements the AML interpreter path. According to the specification [1], PRM services are listed in an ACPI table called the PRMT. This patch parses module and handler information listed in the PRMT and registers the PlatformRtMechanism OpRegion handler before ACPI tables are loaded. Each service is defined by a 16-byte GUID and called from writing a 26-byte ASL buffer containing the identifier to a FieldUnit object defined inside a PlatformRtMechanism OperationRegion. OperationRegion (PRMR, PlatformRtMechanism, 0, 26) Field (PRMR, BufferAcc, NoLock, Preserve) { PRMF, 208 // Write to this field to invoke the OperationRegion Handler } The 26-byte ASL buffer is defined as the following: Byte Offset Byte Length Description ============================================================= 0 1 PRM OperationRegion handler status 1 8 PRM service status 9 1 PRM command 10 16 PRM handler GUID The ASL caller fills out a 26-byte buffer containing the PRM command and the PRM handler GUID like so: /* Local0 is the PRM data buffer */ Local0 = buffer (26){} /* Create byte fields over the buffer */ CreateByteField (Local0, 0x9, CMD) CreateField (Local0, 0x50, 0x80, GUID) /* Fill in the command and data fields of the data buffer */ CMD = 0 // run command GUID = ToUUID("xxxx-xx-xxx-xxxx") /* * Invoke PRM service with an ID that matches GUID and save the * result. */ Local0 = (\_SB.PRMT.PRMF = Local0) Byte offset 0 - 8 are written by the handler as a status passed back to AML and used by ASL like so: /* Create byte fields over the buffer */ CreateByteField (Local0, 0x0, PSTA) CreateQWordField (Local0, 0x1, USTA) In this ASL code, PSTA contains a status from the OperationRegion and USTA contains a status from the PRM service. The 26-byte buffer is recieved by acpi_platformrt_space_handler. This handler will look at the command value and the handler guid and take the approperiate actions. Command value Action ===================================================================== 0 Run the PRM service indicated by the PRM handler GUID (bytes 10-26) 1 Prevent PRM runtime updates from happening to the service's parent module 2 Allow PRM updates from happening to the service's parent module This patch enables command value 0. Link: https://uefi.org/sites/default/files/resources/Platform%20Runtime%20Mechanism%20-%20with%20legal%20notice.pdf # [1] Signed-off-by: Erik Kaneda <erik.kaneda@intel.com> [ rjw: Subject and changelog edits ] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2021-06-10RDMA/irdma: Store PBL info address a pointer typeShiraz Saleem5-24/+23
The level1 PBL info address is stored as u64. This requires casting through a uinptr_t before used as a pointer type. And this leads to sparse warning such as this when uinptr_t is missing: drivers/infiniband/hw/irdma/hw.c: In function 'irdma_destroy_virt_aeq': drivers/infiniband/hw/irdma/hw.c:579:23: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast] 579 | dma_addr_t *pg_arr = (dma_addr_t *)aeq->palloc.level1.addr; This can be fixed using an intermediate uintptr_t, but rather it is better to fix the structure irdm_pble_info to store the address as u64* and the VA it is assigned in irdma_chunk as a void*. This greatly reduces the casting on this address. Fixes: 44d9e52977a1 ("RDMA/irdma: Implement device initialization definitions") Link: https://lore.kernel.org/r/20210609234924.938-1-shiraz.saleem@intel.com Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: Shiraz Saleem <shiraz.saleem@intel.com> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
2021-06-10IB/cm: Remove dgid from the cm_id_priv avJason Gunthorpe1-9/+4
It turns out this is only being used to store the LID for SIDR mode to search the RB tree for request de-duplication. Store the LID value directly and don't pretend it is a GID. Link: https://lore.kernel.org/r/2e7c87b6f662c90c642fc1838e363ad3e6ef14a4.1623236345.git.leonro@nvidia.com Reviewed-by: Mark Zhang <markzhang@nvidia.com> Signed-off-by: Leon Romanovsky <leonro@nvidia.com> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
2021-06-10irqchip: Bulk conversion to generic_handle_domain_irq()Marc Zyngier47-190/+111
Wherever possible, replace constructs that match either generic_handle_irq(irq_find_mapping()) or generic_handle_irq(irq_linear_revmap()) to a single call to generic_handle_domain_irq(). Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> Signed-off-by: Marc Zyngier <maz@kernel.org>
2021-06-10irqchip/nvic: Convert from handle_IRQ() to handle_domain_irq()Marc Zyngier1-3/+1
Given that the nvic driver is fully irqdomain aware, there is no reason for it to use the arch-specific handle_IRQ(), and it can be moved over to handle_domain_irq(). Signed-off-by: Marc Zyngier <maz@kernel.org>
2021-06-10scsi/ibmvscsi: Directly include linux/{of.h,irqdomain.h}Marc Zyngier2-0/+2
A couple of ibmvscsi files are missing the inclusion of linux/of.h and linux/irqdomain.h, relying on transitive inclusion from another file. As we are about to break this dependency, make sure these dependencies are explicit. Signed-off-by: Marc Zyngier <maz@kernel.org>
2021-06-10irqchip/mips-gic: Directly include linux/irqdomain.hMarc Zyngier1-0/+1
This drivers currently obtains linux/irqdomain.h by luck and a chain of bizarre inclusions, which we're about to fix. Let's include the required file directly. Signed-off-by: Marc Zyngier <maz@kernel.org>
2021-06-10watchdog/octeon-wdt: Directly include linux/irqdomain.hMarc Zyngier1-0/+1
This drivers currently obtains linux/irqdomain.h by luck and a chain of bizarre inclusions, which we're about to fix. Let's include the required file directly. Signed-off-by: Marc Zyngier <maz@kernel.org>
2021-06-10mfd: ioc3: Directly include linux/irqdomain.hMarc Zyngier1-0/+1
This driver include linux/irqdomain.h via a bizarre set of indirection, which we are about to break. Directly include the required file. Signed-off-by: Marc Zyngier <maz@kernel.org>
2021-06-10staging: octeon-hcd: Directly include linux/of.hMarc Zyngier1-0/+2
This drivers currently obtains linux/of.h by luck and a chain of bizarre inclusions, which we're about to fix. Let's include the required file directly. Signed-off-by: Marc Zyngier <maz@kernel.org>
Copyright © 1996 – 2026 Jason A. Donenfeld. All Rights Reverse Engineered.