summaryrefslogtreecommitdiff
path: root/drivers
AgeCommit message (Collapse)Author
2021-10-15drm/msm/dp: Allow sub-regions to be specified in DTBjorn Andersson
Not all platforms has P0 at an offset of 0x1000 from the base address, so add support for specifying each sub-region in DT. The code falls back to the predefined offsets in the case that only a single reg is specified, in order to support existing DT. Reviewed-by: Stephen Boyd <swboyd@chromium.org> Reviewed-by: Abhinav Kumar <abhinavk@codeaurora.org> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org> Link: https://lore.kernel.org/r/20211001174400.981707-6-bjorn.andersson@linaro.org Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Signed-off-by: Rob Clark <robdclark@chromium.org>
2021-10-15soc: qcom: rpmhpd: Make power_on actually enable the domainBjorn Andersson
The general expectation is that powering on a power-domain should make the power domain deliver some power, and if a specific performance state is needed further requests has to be made. But in contrast with other power-domain implementations (e.g. rpmpd) the RPMh does not have an interface to enable the power, so the driver has to vote for a particular corner (performance level) in rpmh_power_on(). But the corner is never initialized, so a typical request to simply enable the power domain would not actually turn on the hardware. Further more, when no more clients vote for a performance state (i.e. the aggregated vote is 0) the power domain would be turned off. Fix both of these issues by always voting for a corner with non-zero value, when the power domain is enabled. The tracking of the lowest non-zero corner is performed to handle the corner case if there's ever a domain with a non-zero lowest corner, in which case both rpmh_power_on() and rpmh_rpmhpd_set_performance_state() would be allowed to use this lowest corner. Fixes: 279b7e8a62cc ("soc: qcom: rpmhpd: Add RPMh power domain driver") Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org> Reviewed-by: Stephen Boyd <swboyd@chromium.org> Link: https://lore.kernel.org/r/20211005033732.2284447-1-bjorn.andersson@linaro.org
2021-10-15hwmon: (tmp421) ignore non-channel related DT nodesKrzysztof Adamski
In case the DT contains some nodes not describing the input channels, ignore them instead of exiting with error. Signed-off-by: Krzysztof Adamski <krzysztof.adamski@nokia.com> Link: https://lore.kernel.org/r/8e9e332b18dc2cf545f8e8255157e408d356f916.1634206677.git.krzysztof.adamski@nokia.com Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2021-10-15hwmon: (tmp421) support HWMON_T_ENABLEKrzysztof Adamski
Since the recent patches added possibility of disabling sensor channels via DT, it only make sense to allow controlling that from userspace via HWMON_T_ENABLE mechanism. This patches adds support for that. Signed-off-by: Krzysztof Adamski <krzysztof.adamski@nokia.com> Link: https://lore.kernel.org/r/a64c22e7323bd5a083f37aaaca91a745ac1beef3.1634206677.git.krzysztof.adamski@nokia.com Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2021-10-15hwmon: (tmp421) really disable channelsKrzysztof Adamski
Recent patch added possibility to disable selected channels. That would only make sure that the ENODATA is returned for those channels but would not configure the actual hardware. With this patch, the config register is written to make sure the channels are disabled also at hardware level. Signed-off-by: Krzysztof Adamski <krzysztof.adamski@nokia.com> Link: https://lore.kernel.org/r/d451cacdf21bf8eff38a47c055aad8c0c6e8755a.1634206677.git.krzysztof.adamski@nokia.com Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2021-10-15hwmon: (tmp421) support specifying n-factor via DTKrzysztof Adamski
Previous patches added a way to specify some channel specific parameters in DT and n-factor is definitely one of them. This calibration mechanism is board specific as its value depends on the diodes/transistors being connected to the sensor and thus the DT seems like a right fit for that information. It is very similar to the value of shunt resistor that some drivers allows specifying in DT. This patch adds a possibility to set n-factor for each channel via "n-factor" DT property in each channel subnode. Signed-off-by: Krzysztof Adamski <krzysztof.adamski@nokia.com> Link: https://lore.kernel.org/r/69d0bfcc5ba27c67f21d3eabfb100656a14c75b9.1634206677.git.krzysztof.adamski@nokia.com Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2021-10-15hwmon: (tmp421) support disabling channels from DTKrzysztof Adamski
The previous patch introduced per channel subnodes in DT that let us specify some channel specific properties. This built a ground for easily disabling individual channels of the sensor that may not be connected to any external diode and thus are not returning any meaningful data. This patch adds support for parsing the "status" property of channels DT subnodes and makes sure the -ENODATA is returned when disabled channels value is read. Signed-off-by: Krzysztof Adamski <krzysztof.adamski@nokia.com> Link: https://lore.kernel.org/r/a85d623f0792b862870933a875bdf802f4c017f1.1634206677.git.krzysztof.adamski@nokia.com Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2021-10-15hwmon: (tmp421) add support for defining labels from DTKrzysztof Adamski
tmp42x is a multichannel temperature sensor with several external channels. Since those channels can be used to connect diodes placed anywhere in the system, their meaning will vary depending on the project. For this case, the hwmon framework has an idea of labels which allows us to assign the meaning to each channel. The similar concept is already implemented in ina3221 - the label for each channel can be defined via device tree. See commit a9e9dd9c6de5 ("hwmon: (ina3221) Read channel input source info from DT") This patch adds support for similar feature to tmp421. Signed-off-by: Krzysztof Adamski <krzysztof.adamski@nokia.com> Link: https://lore.kernel.org/r/dab0fda6ac0e8d7f163c3762a7fb1e595a4d8159.1634206677.git.krzysztof.adamski@nokia.com Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2021-10-15drm/msm/dp: Store each subblock in the io regionBjorn Andersson
Not all platforms has DP_P0 at offset 0x1000 from the beginning of the DP block. So split the dss_io_data memory region into a set of sub-regions, to make it possible in the next patch to specify each of the sub-regions individually. Reviewed-by: Stephen Boyd <swboyd@chromium.org> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org> Link: https://lore.kernel.org/r/20211001174400.981707-5-bjorn.andersson@linaro.org Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Signed-off-by: Rob Clark <robdclark@chromium.org>
2021-10-15drm/msm/dp: Refactor ioremap wrapperBjorn Andersson
In order to deal with multiple memory ranges in the following commit change the ioremap wrapper to not poke directly into the dss_io_data struct. While at it, devm_ioremap_resource() already prints useful error messages on failure, so omit the unnecessary prints from the caller. Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org> Reviewed-by: Stephen Boyd <swboyd@chromium.org> Link: https://lore.kernel.org/r/20211001174400.981707-4-bjorn.andersson@linaro.org Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Signed-off-by: Rob Clark <robdclark@chromium.org>
2021-10-15drm/msm/dp: Use devres for ioremap()Bjorn Andersson
The non-devres version of ioremap is used, which requires manual cleanup. But the code paths leading here is mixed with other devres users, so rely on this for ioremap as well to simplify the code. Reviewed-by: Abhinav Kumar <abhinavk@codeaurora.org> Reviewed-by: Stephen Boyd <swboyd@chromium.org> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org> Link: https://lore.kernel.org/r/20211001174400.981707-3-bjorn.andersson@linaro.org Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Signed-off-by: Rob Clark <robdclark@chromium.org>
2021-10-15drm/msm: potential error pointer dereference in init()Dan Carpenter
The msm_iommu_new() returns error pointers on failure so check for that to avoid an Oops. Fixes: ccac7ce373c1 ("drm/msm: Refactor address space initialization") Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Reviewed-by: Abhinav Kumar <abhinavk@codeaurora.org> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Link: https://lore.kernel.org/r/20211004103806.GD25015@kili Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Signed-off-by: Rob Clark <robdclark@chromium.org>
2021-10-15drm/msm: Fix potential Oops in a6xx_gmu_rpmh_init()Dan Carpenter
There are two problems here: 1) The "seqptr" is used uninitalized when we free it at the end. 2) The a6xx_gmu_get_mmio() function returns error pointers. It never returns true. Fixes: 64245fc55172 ("drm/msm/a6xx: use AOP-initialized PDC for a650") Fixes: f8fc924e088e ("drm/msm/a6xx: Fix PDC register overlap") Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Link: https://lore.kernel.org/r/20211004134530.GB11689@kili Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Signed-off-by: Rob Clark <robdclark@chromium.org>
2021-10-15drm/msm/dsi: do not enable irq handler before powering up the hostDmitry Baryshkov
The DSI host might be left in some state by the bootloader. If this state generates an IRQ, it might hang the system by holding the interrupt line before the driver sets up the DSI host to the known state. Move the request_irq into msm_dsi_host_init and pass IRQF_NO_AUTOEN to it. Call enable/disable_irq after msm_dsi_host_power_on/_off() functions, so that we can be sure that the interrupt is delivered when the host is in the known state. It is not possible to defer the interrupt enablement to a later point, because drm_panel_prepare might need to communicate with the panel over the DSI link and that requires working interrupt. Fixes: a689554ba6ed ("drm/msm: Initial add DSI connector support") Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Reviewed-by: Abhinav Kumar <abhinavk@codeaurora.org> Link: https://lore.kernel.org/r/20211002010830.647416-1-dmitry.baryshkov@linaro.org Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Signed-off-by: Rob Clark <robdclark@chromium.org>
2021-10-15drm/msm/mdp5: Add configuration for MDP v1.16Vladimir Lypak
MDP version v1.16 is almost identical to v1.15 with most significant difference being presence of second DSI interface. MDP v1.16 is found on SoCs such as MSM8x53, SDM450, SDM632 (All with Adreno 506). Signed-off-by: Vladimir Lypak <vladimir.lypak@gmail.com> Signed-off-by: Sireesh Kodali <sireeshkodali1@gmail.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Link: https://lore.kernel.org/r/20210928131929.18567-4-sireeshkodali1@gmail.com Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Signed-off-by: Rob Clark <robdclark@chromium.org>
2021-10-15drm/msm/dsi: Add phy configuration for MSM8953Vladimir Lypak
Add phy configuration for 14nm dsi phy found on MSM8953 SoC. Only difference from existing configurations are io_start addresses. Signed-off-by: Vladimir Lypak <vladimir.lypak@gmail.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Signed-off-by: Sireesh Kodali <sireeshkodali1@gmail.com> Link: https://lore.kernel.org/r/20210928131929.18567-3-sireeshkodali1@gmail.com Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Signed-off-by: Rob Clark <robdclark@chromium.org>
2021-10-15drm: Use IS_ERR() instead of IS_ERR_OR_NULL()Wang Qing
dev_pm_opp_find_freq_exact never return null but ERR_PTR(),so we should use IS_ERR() to clarify and avoid compilation warnings. Signed-off-by: Wang Qing <wangqing@vivo.com> Link: https://lore.kernel.org/r/1604630714-6163-1-git-send-email-wangqing@vivo.com Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Signed-off-by: Rob Clark <robdclark@chromium.org>
2021-10-15drm: msm: adreno: use DEFINE_DEBUGFS_ATTRIBUTE with debugfs_create_file_unsafe()Deepak R Varma
Using DEFINE_DEBUGFS_ATTRIBUTE macro with debugfs_create_file_unsafe() function in place of the debugfs_create_file() function will make the file operation struct "reset" aware of the file's lifetime. Additional details here: https://lists.archive.carbon60.com/linux/kernel/2369498 Issue reported by Coccinelle script: scripts/coccinelle/api/debugfs/debugfs_simple_attr.cocci Signed-off-by: Deepak R Varma <mh12gx2825@gmail.com> Link: https://lore.kernel.org/r/9ca2c2e4cbd9ebb282b90f742305fd9b481aacc2.1603998014.git.mh12gx2825@gmail.com Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Signed-off-by: Rob Clark <robdclark@chromium.org>
2021-10-15drm/msm: delete conversion from bool value to bool returnBernard
Delete the conversion from bool value to bool function return. Signed-off-by: Bernard Zhao <bernard@vivo.com> Link: https://lore.kernel.org/r/AI*ANACSDfnjQejyeNXUnKoQ.1.1604995827401.Hmail.bernard@vivo.com Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Signed-off-by: Rob Clark <robdclark@chromium.org>
2021-10-15drm/msm/mdp5: Remove redundant null check before ↵Xu Wang
clk_prepare_enable/clk_disable_unprepare Because clk_prepare_enable() and clk_disable_unprepare() already checked NULL clock parameter, so the additional checks are unnecessary, just remove them. Signed-off-by: Xu Wang <vulab@iscas.ac.cn> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Link: https://lore.kernel.org/r/20201231094935.25737-1-vulab@iscas.ac.cn Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Signed-off-by: Rob Clark <robdclark@chromium.org>
2021-10-15drm/msm: dsi: Remove redundant null check before ↵Xu Wang
clk_prepare_enable/clk_disable_unprepare Because clk_prepare_enable() and clk_disable_unprepare() already checked NULL clock parameter, so the additional checks are unnecessary, just remove them. Signed-off-by: Xu Wang <vulab@iscas.ac.cn> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Link: https://lore.kernel.org/r/20201231095616.25973-1-vulab@iscas.ac.cn Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Signed-off-by: Rob Clark <robdclark@chromium.org>
2021-10-15drm/msm/mdp4: Remove redundant null check before ↵Xu Wang
clk_prepare_enable/clk_disable_unprepare Because clk_prepare_enable() and clk_disable_unprepare() already checked NULL clock parameter, so the additional checks are unnecessary, just remove them. Signed-off-by: Xu Wang <vulab@iscas.ac.cn> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Link: https://lore.kernel.org/r/20201231094155.25481-1-vulab@iscas.ac.cn Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Signed-off-by: Rob Clark <robdclark@chromium.org>
2021-10-15drm/msm: fix warning "using plain integer as NULL pointer"Bernard Zhao
Fix sparse warning: drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c:1195:41: warning: Using plain integer as NULL pointer drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c:1348:32: warning: Using plain integer as NULL pointer Signed-off-by: Bernard Zhao <bernard@vivo.com> Link: https://lore.kernel.org/r/20210510031250.5303-1-bernard@vivo.com Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Signed-off-by: Rob Clark <robdclark@chromium.org>
2021-10-15drm/msm: prevent NULL dereference in msm_gpu_crashstate_capture()Tim Gardner
Coverity complains of a possible NULL dereference: CID 120718 (#1 of 1): Dereference null return value (NULL_RETURNS) 23. dereference: Dereferencing a pointer that might be NULL state->bos when calling msm_gpu_crashstate_get_bo. [show details] 301 msm_gpu_crashstate_get_bo(state, submit->bos[i].obj, 302 submit->bos[i].iova, submit->bos[i].flags); Fix this by employing the same state->bos NULL check as is used in the next for loop. Cc: Rob Clark <robdclark@gmail.com> Cc: Sean Paul <sean@poorly.run> Cc: David Airlie <airlied@linux.ie> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: linux-arm-msm@vger.kernel.org Cc: dri-devel@lists.freedesktop.org Cc: freedreno@lists.freedesktop.org Cc: linux-kernel@vger.kernel.org Signed-off-by: Tim Gardner <tim.gardner@canonical.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Link: https://lore.kernel.org/r/20210929162554.14295-1-tim.gardner@canonical.com Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Signed-off-by: Rob Clark <robdclark@chromium.org>
2021-10-15drm/msm/dp: Remove redundant initialization of variable bppColin Ian King
The variable bpp is being initialized with a value that is never read, it is being updated later on in both paths of an if statement. The assignment is redundant and can be removed. Addresses-Coverity: ("Unused value") Signed-off-by: Colin Ian King <colin.king@canonical.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Link: https://lore.kernel.org/r/20210929105458.209895-1-colin.king@canonical.com Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Signed-off-by: Rob Clark <robdclark@chromium.org>
2021-10-15drm/msm/dpu: Remove some nonsenseRob Clark
These aren't used. And if we add use for them later, we should probably do something a bit more structured than string parsing. Signed-off-by: Rob Clark <robdclark@chromium.org> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Link: https://lore.kernel.org/r/20210928162903.1104847-1-robdclark@gmail.com Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Signed-off-by: Rob Clark <robdclark@chromium.org>
2021-10-15drm/msm/dsi: Support NO_CONNECTOR bridgesRob Clark
For now, since we have a mix of bridges which support this flag, which which do *not* support this flag, or work both ways, try it once with NO_CONNECTOR and then fall back to the old way if that doesn't work. Eventually we can drop the fallback path. v2: Add missing drm_connector_attach_encoder() so display actually comes up when the bridge properly handles the NO_CONNECTOR flag Signed-off-by: Rob Clark <robdclark@chromium.org> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Link: https://lore.kernel.org/r/20210920225801.227211-2-robdclark@gmail.com Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Signed-off-by: Rob Clark <robdclark@chromium.org>
2021-10-15drm: msm: hdmi: Constify static structsRikard Falkeborn
The only usage of hdmi_8996_pll_ops is to assign its address to the ops field in the clk_init_data struct, and the only usage of pll_init is to assign its address to the init field in the clk_hw struct, both which are pointers to const. Make them const to allow the compiler to put them in read-only memory. Signed-off-by: Rikard Falkeborn <rikard.falkeborn@gmail.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Link: https://lore.kernel.org/r/20210920212014.40520-1-rikard.falkeborn@gmail.com Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Signed-off-by: Rob Clark <robdclark@chromium.org>
2021-10-15drm/msm/dsi: Use division result from div_u64_rem in 7nm and 14nm PLLMarijn Suijten
div_u64_rem provides the result of the division and additionally the remainder; don't use this function to solely calculate the remainder while calculating the division again with div_u64. A similar improvement was applied earlier to the 10nm pll in 5c191fef4ce2 ("drm/msm/dsi_pll_10nm: Fix dividing the same numbers twice"). Signed-off-by: Marijn Suijten <marijn.suijten@somainline.org> Reviewed-By: AngeloGioacchino Del Regno <angelogioacchino.delregno@somainline.org> Reviewed-by: Abhinav Kumar <abhinavk@codeaurora.org> Reviewed-by: Stephen Boyd <swboyd@chromium.org> Link: https://lore.kernel.org/r/20211011201642.167700-1-marijn.suijten@somainline.org Signed-off-by: Rob Clark <robdclark@chromium.org>
2021-10-15drm/msm: Remove initialization of static variableszhaoxiao
Address the following checkpatch errors: ERROR: do not initialise statics to false FILE: :drivers/gpu/drm/msm/msm_drv.c:21: -static bool reglog = false; FILE: :drivers/gpu/drm/msm/msm_drv.c:31: -bool dumpstate = false; Signed-off-by: zhaoxiao <long870912@gmail.com> Link: https://lore.kernel.org/r/20210906064315.4975-1-long870912@gmail.com Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Signed-off-by: Rob Clark <robdclark@chromium.org>
2021-10-15drm/msm: remove unneeded variableChi Minghao
Fix the following coccicheck REVIEW: ./drivers/gpu/drm/msm/edp/edp_ctrl.c:1245:5-8 Unneeded variable Reported-by: Zeal Robot <zealci@zte.com.cn> Signed-off-by: Chi Minghao <chi.minghao@zte.com.cn> Reviewed-by: Lyude Paul <lyude@redhat.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Link: https://lore.kernel.org/r/20210831115127.18236-1-chi.minghao@zte.com.cn Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Signed-off-by: Rob Clark <robdclark@chromium.org>
2021-10-15drm/msm: Change dpu_crtc_get_vblank_counter to use vsync count.Mark Yacoub
[why] vsync_cnt atomic counter increments for every hw vsync. On the other hand, frame count is a register that increments when the frame gets actually pushed out. We cannnot read this register whenever the timing engine is off, but vblank counter should still return a valid number. This behavior also matches the downstream driver. [How] Read the encoder vsync count instead of the dpu_encoder_phys frame count. Suggested-by: Abhinav Kumar <abhinavk@codeaurora.org> CC: Rob Clark <robdclark@chromium.org> Signed-off-by: Mark Yacoub <markyacoub@chromium.org> Reviewed-by: Abhinav Kumar <abhinavk@codeaurora.org> Link: https://lore.kernel.org/r/20210830181359.124267-1-markyacoub@chromium.org Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Signed-off-by: Rob Clark <robdclark@chromium.org>
2021-10-15drm/msm/dpu: merge struct dpu_irq into struct dpu_hw_intrDmitry Baryshkov
As dpu_core_irq was merged into dpu_hw_intr, merge data structures too, removing the need for a separate data structure. Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Reviewed-by: Abhinav Kumar <abhinavk@codeaurora.org> Link: https://lore.kernel.org/r/20210617222029.463045-4-dmitry.baryshkov@linaro.org Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Signed-off-by: Rob Clark <robdclark@chromium.org>
2021-10-15drm/msm/dpu: don't clear IRQ register twiceDmitry Baryshkov
We already clear the IRQ status register before processing IRQs, so do not clear the register again. Especially do not clear the IRQ status _after_ processing the IRQ as this way we can loose the event. Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Reviewed-by: Abhinav Kumar <abhinavk@codeaurora.org> Link: https://lore.kernel.org/r/20210617222029.463045-3-dmitry.baryshkov@linaro.org Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Signed-off-by: Rob Clark <robdclark@chromium.org>
2021-10-15drm/msm/dpu: squash dpu_core_irq into dpu_hw_interruptsDmitry Baryshkov
With dpu_core_irq being the wrapper around dpu_hw_interrupts, there is little sense in having them separate. Squash them together to remove another layer of abstraction (hw_intr ops). Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Reviewed-by: Abhinav Kumar <abhinavk@codeaurora.org> Link: https://lore.kernel.org/r/20210617222029.463045-2-dmitry.baryshkov@linaro.org Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Signed-off-by: Rob Clark <robdclark@chromium.org>
2021-10-15vfio: Use cdev_device_add() instead of device_create()Jason Gunthorpe
Modernize how vfio is creating the group char dev and sysfs presence. These days drivers with state should use cdev_device_add() and cdev_device_del() to manage the cdev and sysfs lifetime. This API requires the driver to put the struct device and struct cdev inside its state struct (vfio_group), and then use the usual device_initialize()/cdev_device_add()/cdev_device_del() sequence. Split the code to make this possible: - vfio_group_alloc()/vfio_group_release() are pair'd functions to alloc/free the vfio_group. release is done under the struct device kref. - vfio_create_group()/vfio_group_put() are pairs that manage the sysfs/cdev lifetime. Once the uses count is zero the vfio group's userspace presence is destroyed. - The IDR is replaced with an IDA. container_of(inode->i_cdev) is used to get back to the vfio_group during fops open. The IDA assigns unique minor numbers. Reviewed-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Kevin Tian <kevin.tian@intel.com> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com> Link: https://lore.kernel.org/r/5-v3-2fdfe4ca2cc6+18c-vfio_group_cdev_jgg@nvidia.com Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
2021-10-15vfio: Use a refcount_t instead of a kref in the vfio_groupJason Gunthorpe
The next patch adds a struct device to the struct vfio_group, and it is confusing/bad practice to have two krefs in the same struct. This kref is controlling the period when the vfio_group is registered in sysfs, and visible in the internal lookup. Switch it to a refcount_t instead. The refcount_dec_and_mutex_lock() is still required because we need atomicity of the list searches and sysfs presence. Reviewed-by: Liu Yi L <yi.l.liu@intel.com> Reviewed-by: Kevin Tian <kevin.tian@intel.com> Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com> Link: https://lore.kernel.org/r/4-v3-2fdfe4ca2cc6+18c-vfio_group_cdev_jgg@nvidia.com Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
2021-10-15vfio: Don't leak a group reference if the group already existsJason Gunthorpe
If vfio_create_group() searches the group list and returns an already existing group it does not put back the iommu_group reference that the caller passed in. Change the semantic of vfio_create_group() to not move the reference in from the caller, but instead obtain a new reference inside and leave the caller's reference alone. The two callers must now call iommu_group_put(). This is an unlikely race as the only caller that could hit it has already searched the group list before attempting to create the group. Fixes: cba3345cc494 ("vfio: VFIO core") Reviewed-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Kevin Tian <kevin.tian@intel.com> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com> Link: https://lore.kernel.org/r/3-v3-2fdfe4ca2cc6+18c-vfio_group_cdev_jgg@nvidia.com Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
2021-10-15vfio: Do not open code the group list search in vfio_create_group()Jason Gunthorpe
Split vfio_group_get_from_iommu() into __vfio_group_get_from_iommu() so that vfio_create_group() can call it to consolidate this duplicated code. Reviewed-by: Liu Yi L <yi.l.liu@intel.com> Reviewed-by: Kevin Tian <kevin.tian@intel.com> Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com> Link: https://lore.kernel.org/r/2-v3-2fdfe4ca2cc6+18c-vfio_group_cdev_jgg@nvidia.com Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
2021-10-15vfio: Delete vfio_get/put_group from vfio_iommu_group_notifier()Jason Gunthorpe
iommu_group_register_notifier()/iommu_group_unregister_notifier() are built using a blocking_notifier_chain which integrates a rwsem. The notifier function cannot be running outside its registration. When considering how the notifier function interacts with create/destroy of the group there are two fringe cases, the notifier starts before list_add(&vfio.group_list) and the notifier runs after the kref becomes 0. Prior to vfio_create_group() unlocking and returning we have container_users == 0 device_list == empty And this cannot change until the mutex is unlocked. After the kref goes to zero we must also have container_users == 0 device_list == empty Both are required because they are balanced operations and a 0 kref means some caller became unbalanced. Add the missing assertion that container_users must be zero as well. These two facts are important because when checking each operation we see: - IOMMU_GROUP_NOTIFY_ADD_DEVICE Empty device_list avoids the WARN_ON in vfio_group_nb_add_dev() 0 container_users ends the call - IOMMU_GROUP_NOTIFY_BOUND_DRIVER 0 container_users ends the call Finally, we have IOMMU_GROUP_NOTIFY_UNBOUND_DRIVER, which only deletes items from the unbound list. During creation this list is empty, during kref == 0 nothing can read this list, and it will be freed soon. Since the vfio_group_release() doesn't hold the appropriate lock to manipulate the unbound_list and could race with the notifier, move the cleanup to directly before the kfree. This allows deleting all of the deferred group put code. Reviewed-by: Kevin Tian <kevin.tian@intel.com> Reviewed-by: Liu Yi L <yi.l.liu@intel.com> Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com> Link: https://lore.kernel.org/r/1-v3-2fdfe4ca2cc6+18c-vfio_group_cdev_jgg@nvidia.com Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
2021-10-15PCI/portdrv: Remove unused pcie_port_bus_{,un}register() declarationsLukas Wunner
Commit c6c889d932bb ("PCI/portdrv: Remove pcie_port_bus_type link order dependency") removed pcie_port_bus_{,un}register() but erroneously retained their declarations in portdrv.h. Remove them as well. Link: https://lore.kernel.org/r/7fd76b0591c37287ab94d911d8fd9ab9a2afcd16.1627638184.git.lukas@wunner.de Signed-off-by: Lukas Wunner <lukas@wunner.de> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2021-10-15PCI/portdrv: Remove unused resume err_handlerLukas Wunner
Commit 3e41a317ae45 ("PCI/AER: Remove unused aer_error_resume()") removed the resume err_handler from AER. Since no other port service implements the callback, support for it can be removed from portdrv. It can be revived later if need be, preferably by re-using the pcie_port_device_iter() iterator. Link: https://lore.kernel.org/r/25334149b604e005058aeb0fdf51e01f991d5d74.1627638184.git.lukas@wunner.de Signed-off-by: Lukas Wunner <lukas@wunner.de> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Cc: Keith Busch <kbusch@kernel.org>
2021-10-15PCI: pciehp: Ignore Link Down/Up caused by error-induced Hot ResetLukas Wunner
Stuart Hayes reports that an error handled by DPC at a Root Port results in pciehp gratuitously bringing down a subordinate hotplug port: RP -- UP -- DP -- UP -- DP (hotplug) -- EP pciehp brings the slot down because the Link to the Endpoint goes down. That is caused by a Hot Reset being propagated as a result of DPC. Per PCIe Base Spec 5.0, section 6.6.1 "Conventional Reset": For a Switch, the following must cause a hot reset to be sent on all Downstream Ports: [...] * The Data Link Layer of the Upstream Port reporting DL_Down status. In Switches that support Link speeds greater than 5.0 GT/s, the Upstream Port must direct the LTSSM of each Downstream Port to the Hot Reset state, but not hold the LTSSMs in that state. This permits each Downstream Port to begin Link training immediately after its hot reset completes. This behavior is recommended for all Switches. * Receiving a hot reset on the Upstream Port. Once DPC recovers, pcie_do_recovery() walks down the hierarchy and invokes pcie_portdrv_slot_reset() to restore each port's config space. At that point, a hotplug interrupt is signaled per PCIe Base Spec r5.0, section 6.7.3.4 "Software Notification of Hot-Plug Events": If the Port is enabled for edge-triggered interrupt signaling using MSI or MSI-X, an interrupt message must be sent every time the logical AND of the following conditions transitions from FALSE to TRUE: [...] * The Hot-Plug Interrupt Enable bit in the Slot Control register is set to 1b. * At least one hot-plug event status bit in the Slot Status register and its associated enable bit in the Slot Control register are both set to 1b. Prevent pciehp from gratuitously bringing down the slot by clearing the error-induced Data Link Layer State Changed event before restoring config space. Afterwards, check whether the link has unexpectedly failed to retrain and synthesize a DLLSC event if so. Allow each pcie_port_service_driver (one of them being pciehp) to define a slot_reset callback and re-use the existing pm_iter() function to iterate over the callbacks. Thereby, the Endpoint driver remains bound throughout error recovery and may restore the device to working state. Surprise removal during error recovery is detected through a Presence Detect Changed event. The hotplug port is expected to not signal that event as a result of a Hot Reset. The issue isn't DPC-specific, it also occurs when an error is handled by AER through aer_root_reset(). So while the issue was noticed only now, it's been around since 2006 when AER support was first introduced. [bhelgaas: drop PCI_ERROR_RECOVERY Kconfig, split pm_iter() rename to preparatory patch] Link: https://lore.kernel.org/linux-pci/08c046b0-c9f2-3489-eeef-7e7aca435bb9@gmail.com/ Fixes: 6c2b374d7485 ("PCI-Express AER implemetation: AER core and aerdriver") Link: https://lore.kernel.org/r/251f4edcc04c14f873ff1c967bc686169cd07d2d.1627638184.git.lukas@wunner.de Reported-by: Stuart Hayes <stuart.w.hayes@gmail.com> Tested-by: Stuart Hayes <stuart.w.hayes@gmail.com> Signed-off-by: Lukas Wunner <lukas@wunner.de> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Cc: stable@vger.kernel.org # v2.6.19+: ba952824e6c1: PCI/portdrv: Report reset for frozen channel Cc: Keith Busch <kbusch@kernel.org>
2021-10-15PCI/portdrv: Rename pm_iter() to pcie_port_device_iter()Lukas Wunner
Rename pm_iter() to pcie_port_device_iter() and make it visible outside CONFIG_PM and portdrv_core.c so it can be used for pciehp slot reset recovery. [bhelgaas: split into its own patch] Link: https://lore.kernel.org/linux-pci/08c046b0-c9f2-3489-eeef-7e7aca435bb9@gmail.com/ Link: https://lore.kernel.org/r/251f4edcc04c14f873ff1c967bc686169cd07d2d.1627638184.git.lukas@wunner.de Signed-off-by: Lukas Wunner <lukas@wunner.de> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2021-10-15rtc: pcf85063: Always clear EXT_TEST from set_timePhil Elwell
Power-on reset after the insertion of a battery does not always complete successfully, leading to corrupted register content. The EXT_TEST bit will stop the clock from running, but currently the driver will never recover. Safely handle the erroneous state by clearing EXT_TEST as part of the usual set_time method. Signed-off-by: Phil Elwell <phil@raspberrypi.com> Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Link: https://lore.kernel.org/r/20211015111208.1757110-1-phil@raspberrypi.com
2021-10-15rtc: pcf85063: add support for fixed clockAlexander Stein
TQ-Systems' TQMa8Mx module (SoM) uses a pcf85063 as RTC. The default output is 32768Hz. This is to provide the i.MX8M CKIL clock. Once the RTC driver is probed, the clock is disabled and all i.MX8M functionality depending on the 32 KHz clock will halt. In our case the whole system halts and a power cycle is required. Referencing the pcf85063 directly results in a deadlock. The kernel will see, that i.MX8M system clock needs the RTC clock and do probe deferral. But the i.MX8M I2C module never becomes usable without the i.MX8M CKIL clock and thus the RTC's clock will not be probed. So from the kernel's perspective this is a chicken-and-egg problem. Technically everything is fine by not touching anything, since the RTC clock correctly enables the clock on reset (i.e. on battery backup power loss). A workaround for this issue is describing the square wave pin as fixed-clock, which is registered early and basically how this pin is used on the i.MX8M. This addresses the exact same issue as in commit f765e349c3e1 ("rtc: m41t80: add support for fixed clock"). Signed-off-by: Alexander Stein <alexander.stein@ew.tq-group.com> Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> [Fixed return value 0 -> NULL] Link: https://lore.kernel.org/r/20211013074954.997445-1-alexander.stein@ew.tq-group.com
2021-10-15rtc: rv3032: fix error handling in rv3032_clkout_set_rate()Dan Carpenter
Do not call rv3032_exit_eerd() if the enter function fails but don't forget to call the exit when the enter succeeds. Fixes: 2eeaa532acca ("rtc: rv3032: Add a driver for Microcrystal RV-3032") Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Link: https://lore.kernel.org/r/20211012101028.GT2083@kadam
2021-10-15rtc: class: check return value when calling dev_set_name()Yang Yingliang
I got a null-ptr-deref report when doing fault injection test: BUG: kernel NULL pointer dereference, address: 0000000000000000 RIP: 0010:strcmp+0xc/0x20 Call Trace: __devm_rtc_register_device.cold.7+0x16a/0x2df rv3029_probe+0x4b1/0x770 [rtc_rv3029c2] rv3029_i2c_probe+0x141/0x180 [rtc_rv3029c2] i2c_device_probe+0xa07/0xbb0 really_probe+0x285/0xc30 If dev_set_name() fails, dev_name() is null, it causes null-ptr-deref, we need check the return value of dev_set_name(). Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: Yang Yingliang <yangyingliang@huawei.com> Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Link: https://lore.kernel.org/r/20211012041629.2504158-1-yangyingliang@huawei.com
2021-10-15rtc: class: don't call cdev_device_del() when cdev_device_add() failedYang Yingliang
I got a null-ptr-deref report when doing fault injection test: general protection fault, probably for non-canonical address 0xdffffc0000000022: 0000 [#1] SMP KASAN PTI KASAN: null-ptr-deref in range [0x0000000000000110-0x0000000000000117] RIP: 0010:device_del+0x132/0xdc0 Call Trace: cdev_device_del+0x1a/0x80 devm_rtc_unregister_device+0x37/0x80 release_nodes+0xc3/0x3b0 If cdev_device_add() fails, 'dev->p' is not set, it causes null-ptr-deref when calling cdev_device_del(). Registering character device is optional, we don't return error code here, so introduce a new flag 'RTC_NO_CDEV' to indicate if it has character device, cdev_device_del() is called when this bit is not set. Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: Yang Yingliang <yangyingliang@huawei.com> Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Link: https://lore.kernel.org/r/20211011132114.3663509-1-yangyingliang@huawei.com
2021-10-15drm/i915: Clean up PXP Kconfig info.Rodrigo Vivi
During the review I focused on stop the using of the "+" to reference the newer platforms, but I forgot that we are in a process of making things more clear and differentiate graphics and display versions. So, let me to clean up this a bit. Also, we don't need any version mentioned in the config menu entry, only in the help. Cc: Alan Previn <alan.previn.teres.alexis@intel.com> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211015090916.82968-1-rodrigo.vivi@intel.com
generated by cgit (git 2.34.1) at 2025-10-02 08:11:57 +0000