Maybe subject could be "Ignore debugfs failures, fix indentation, fix
logical error"?
Quoting Abhinav Kumar (2021-03-04 17:31:52)
> Fix the warnings reported by kbot across MSM DP driver.
Which warnings? Can you include them? Or at least list the three things
that are being fixed in this patch?
Fix the warnings reported by kbot across MSM DP driver.
Reported-by: kernel test robot
Reported-by: Dan Carpenter
Signed-off-by: Abhinav Kumar
---
drivers/gpu/drm/msm/dp/dp_debug.c | 33 +
drivers/gpu/drm/msm/dp/dp_hpd.c | 4 ++--
On Thu, Mar 4, 2021 at 7:48 AM Robin Murphy wrote:
>
> On 2021-03-01 08:42, Christoph Hellwig wrote:
> > Signed-off-by: Christoph Hellwig
>
> Moreso than the previous patch, where the feature is at least relatively
> generic (note that there's a bunch of in-flight development around
>
On 3/4/21 4:53 PM, Daniel Lezcano wrote:
Hi Lukasz,
thanks for commenting this patch,
On 04/03/2021 14:47, Lukasz Luba wrote:
Hi Daniel,
On 3/4/21 12:50 PM, Daniel Lezcano wrote:
Currently the default behavior is to manually having the devfreq
backend to register themselves as a devfreq
On 04/03/2021 16:06, Chanwoo Choi wrote:
> Hi Daniel,
>
> As Lukasz's comment, actually some devfreq devices like memory bus
> might not affect the thermal critically. In the mainline,
> there are four types devfreq as following:
> 1. GPU
> 2. UFS Storage
> 3. DMC (Memory Controller)
> 4. Memory
Hi Lukasz,
thanks for commenting this patch,
On 04/03/2021 14:47, Lukasz Luba wrote:
> Hi Daniel,
>
> On 3/4/21 12:50 PM, Daniel Lezcano wrote:
>> Currently the default behavior is to manually having the devfreq
>> backend to register themselves as a devfreq cooling device.
>>
>> There are no
On 2021-03-01 08:42, Christoph Hellwig wrote:
Signed-off-by: Christoph Hellwig
Moreso than the previous patch, where the feature is at least relatively
generic (note that there's a bunch of in-flight development around
DOMAIN_ATTR_NESTING), I'm really not convinced that it's beneficial to
Hi Daniel,
On 3/4/21 12:50 PM, Daniel Lezcano wrote:
Currently the default behavior is to manually having the devfreq
backend to register themselves as a devfreq cooling device.
There are no so many and actually it makes more sense to register the
devfreq device when adding it.
Consequently,
Currently the default behavior is to manually having the devfreq
backend to register themselves as a devfreq cooling device.
There are no so many and actually it makes more sense to register the
devfreq device when adding it.
Consequently, every devfreq becomes a cooling device like cpufreq is.
On 2021-03-01 08:42, Christoph Hellwig wrote:
Use explicit methods for setting and querying the information instead.
Now that everyone's using iommu-dma, is there any point in bouncing this
through the drivers at all? Seems like it would make more sense for the
x86 drivers to reflect their
Hi Daniel,
As Lukasz's comment, actually some devfreq devices like memory bus
might not affect the thermal critically. In the mainline,
there are four types devfreq as following:
1. GPU
2. UFS Storage
3. DMC (Memory Controller)
4. Memory bus like AMBA AXI
I think that you can specify this
On Mon, Mar 01, 2021 at 09:42:40AM +0100, Christoph Hellwig wrote:
> Diffstat:
> arch/powerpc/include/asm/fsl_pamu_stash.h | 12
> drivers/gpu/drm/msm/adreno/adreno_gpu.c |2
> drivers/iommu/amd/iommu.c | 23
> drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 85
Fix a warning, pointing to an early deference of a variable before
check. This bug was introduced in the following commit.
commit 4259ff7ae509
("drm/msm/dpu: add support for pcc color block in dpu driver")
Reported-by: kernel test robot
Reported-by: Dan Carpenter
Signed-off-by: Kalyan Thota
13 matches
Mail list logo
