On Fri, 24 Apr 2020, Guru Das Srinagesh wrote:
> On Fri, Apr 24, 2020 at 07:43:03AM +0100, Lee Jones wrote:
> > A great deal of mailing lists contain numerous protections against
> > things like flooding and spamming. One of those protections is a
> > check for "Too many recipients to the message
On Mon, 2020-04-27 at 07:57 +0200, Sam Ravnborg wrote:
> Hi Joe.
Hi Sam.
> On Sun, Apr 26, 2020 at 10:40:52PM -0700, Joe Perches wrote:
> > .yaml files can contain maintainer/author addresses and it seems
> > unlikely or unnecessary that individual MAINTAINER file section
> > entries for each .ya
Hi Joe.
On Sun, Apr 26, 2020 at 10:40:52PM -0700, Joe Perches wrote:
> .yaml files can contain maintainer/author addresses and it seems
> unlikely or unnecessary that individual MAINTAINER file section
> entries for each .yaml file will be created.
>
> So dd the email addresses found in .yaml fil
.yaml files can contain maintainer/author addresses and it seems
unlikely or unnecessary that individual MAINTAINER file section
entries for each .yaml file will be created.
So dd the email addresses found in .yaml files to the default
get_maintainer output.
The email addresses are marked with "(
btw: the debugging macros in atom.c are not good.
It could be something like the below as the output logging is
at best poorly formatted due to the many individual printks
without KERN_ that are emitted on separate lines.
#define ATOM_DEBUG
should probably be commented out.
The debugging macro
On Sun, 2020-04-26 at 15:18 +0200, Christian König wrote:
> Am 26.04.20 um 15:12 schrieb Bernard Zhao:
> > Maybe no need to check ws before kmalloc, kmalloc will check
> > itself, kmalloc`s logic is if ptr is NULL, kmalloc will just
> > return
> >
> > Signed-off-by: Bernard Zhao
>
> Reviewed-by:
Hi
[This is an automated email]
This commit has been processed because it contains a -stable tag.
The stable tag indicates that it's relevant for the following trees: all
The bot has tested the following trees: v5.6.7, v5.4.35, v4.19.118, v4.14.177,
v4.9.220, v4.4.220.
v5.6.7: Build OK!
v5.4.3
Am 26.04.20 um 15:12 schrieb Bernard Zhao:
Maybe no need to check ws before kmalloc, kmalloc will check
itself, kmalloc`s logic is if ptr is NULL, kmalloc will just
return
Signed-off-by: Bernard Zhao
Reviewed-by: Christian König
I'm wondering why the automated scripts haven't found that one
Remove no need devm_kfree in probe.
The change is to make the code a bit more readable
Signed-off-by: Bernard Zhao
---
drivers/gpu/drm/exynos/exynos_drm_dpi.c | 10 +++---
1 file changed, 3 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_dpi.c
b/drivers/gpu/drm
As suggested by the TODO list for the kernel DRM subsystem, replace
the deprecated functions that take/drop modeset locks with new helpers.
Signed-off-by: Michal Orzel
---
drivers/gpu/drm/drm_mode_object.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu
Fix the following gcc warning:
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c:958:30: warning: variable
‘topology’ set but not used [-Wunused-but-set-variable]
struct msm_display_topology topology;
^~~~
Reported-by: Hulk Robot
Signed-off-by: Jason Yan
---
drive
Quoting Douglas Anderson (2020-04-23 09:25:43)
> The ti-sn65dsi86 MIPI DSI to eDP bridge chip has 4 pins on it that can
> be used as GPIOs in a system. Each pin can be configured as input,
> output, or a special function for the bridge chip. These are:
> - GPIO1: SUSPEND Input
> - GPIO2: DSIA VSY
On 4/18/20 9:39 AM, Caicai wrote:
> When a qxl resource is released, the list that needs to be released is
> fetched from the linked list ring and cleared. When you empty the list,
> instead of trying to determine whether the ttm buffer object for each
> qxl in the list is locked, you release the q
A test with the command below gives this error:
arch/arm64/boot/dts/rockchip/px30-evb.dt.yaml: gpu@ff40:
'#cooling-cells', 'power-domains'
do not match any of the regexes: 'pinctrl-[0-9]+'
With the conversion to yaml it also filters things
in a node that are used by other drivers like
'#cooli
The burst length is configured in VIU_OSD1_FIFO_CTRL_STAT[31] and
VIU_OSD1_FIFO_CTRL_STAT[11:10]. The public S905D3 datasheet describes
this as:
- 0x0 = up to 24 per burst
- 0x1 = up to 32 per burst
- 0x2 = up to 48 per burst
- 0x3 = up to 64 per burst
- 0x4 = up to 96 per burst
- 0x5 = up to 128 p
The '==' expression itself is bool, no need to convert it to bool again.
This fixes the following coccicheck warning:
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c:7230:16-21: WARNING:
conversion to bool not needed here
Signed-off-by: Jason Yan
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdg
The '==' expression itself is bool, no need to convert it to bool again.
This fixes the following coccicheck warning:
drivers/gpu/drm/amd/powerplay/navi10_ppt.c:698:47-52: WARNING:
conversion to bool not needed here
Signed-off-by: Jason Yan
---
drivers/gpu/drm/amd/powerplay/navi10_ppt.c | 2 +-
Maybe keep pointer which points to global const string data
in const type is better, make sure not change const data.
Signed-off-by: Bernard Zhao
---
drivers/gpu/drm/exynos/exynos_drm_dsi.c | 2 +-
drivers/gpu/drm/exynos/exynos_drm_mic.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
On Fri, Apr 24, 2020 at 06:54:41PM +0200, Markus Elfring wrote:
> > The corresponding system resources were not released then.
>
> How do you think about a wording variant like the following?
>
Markus, I think my commit comments is a sufficiently clear description
for this patch. Someone has told
25.04.2020 20:02, Sam Ravnborg пишет:
> Hi Dmitry
>
> On Sat, Apr 18, 2020 at 08:07:03PM +0300, Dmitry Osipenko wrote:
>> Currently Tegra DRM driver manually manages display panel, but this
>> management could be moved out into DRM core if we'll wrap panel into
>> DRM bridge. This patch wraps RGB
Hi, YueHaibing:
YueHaibing 於 2020年4月20日 週一 下午10:04寫道:
>
> WARNING: unmet direct dependencies detected for MTK_MMSYS
> Depends on [n]: (ARCH_MEDIATEK [=y] || COMPILE_TEST [=n]) &&
> COMMON_CLK_MT8173_MMSYS [=n]
> Selected by [y]:
> - DRM_MEDIATEK [=y] && HAS_IOMEM [=y] && DRM [=y] && (ARCH_
Hi, Anand:
Anand K Mistry 於 2020年4月20日 週一 下午2:09寫道:
>
> If dma_map_sg() merges pages when creating the mapping, only the first
> entries will have a valid sg_dma_address() and sg_dma_len(), followed by
> entries with sg_dma_len() == 0.
>
> Signed-off-by: Anand K Mistry
> ---
> drivers/gpu/drm/m
On Fri, Apr 24, 2020 at 05:33:42PM +0200, Maxime Ripard wrote:
> The BCM2711, supported by ARCH_BCM2835, also has a controller by the
> brcmstb driver so let's allow it to be compiled on that platform.
>
> Cc: Kamal Dasu
> Cc: Wolfram Sang
> Cc: bcm-kernel-feedback-l...@broadcom.com
> Cc: linux-
23 matches
Mail list logo