On Mon, Mar 02, 2020 at 11:25:44PM +0100, Daniel Vetter wrote:
> I also did a full review of all callers, and only the xen driver
> forgot to call drm_dev_put in the failure path. Fix that up too.
So ~40 callers - phew..
>
> v2: I noticed that xen has a drm_driver.release hook, and uses
> drm_de
Hi Daniel.
On Mon, Mar 02, 2020 at 11:26:03PM +0100, Daniel Vetter wrote:
> We might want to look into pushing this down into drm_mm_init, but
> that would mean rolling out return codes to a pile of functions
> unfortunately. So let's leave that for now.
>
> Signed-off-by: Daniel Vetter
We are
On Mon, Mar 02, 2020 at 11:26:04PM +0100, Daniel Vetter wrote:
> Nothing special here, except that this is the first time that we
> automatically clean up something that's initialized with an explicit
> driver call. But the cleanup was done at the very of the release
the very what?
> sequence for
On Mon, Mar 02, 2020 at 11:26:05PM +0100, Daniel Vetter wrote:
> It has become empty. Given the few users I figured not much point
> splitting this up.
>
> v2: Rebase over i915 changes.
>
> Signed-off-by: Daniel Vetter
Acked-by: Sam Ravnborg
> ---
> drivers/gpu/drm/cirrus/cirrus.c
On Mon, Mar 02, 2020 at 11:26:15PM +0100, Daniel Vetter wrote:
> It's right above the drm_dev_put().
>
> This is made possible by a preceeding patch which added a drmm_
> cleanup action to drm_mode_config_init(), hence all we need to do to
> ensure that drm_mode_config_cleanup() is run on final dr
On Mon, Mar 02, 2020 at 11:26:17PM +0100, Daniel Vetter wrote:
> It's (almost, there's some iommu stuff without significance) right
> above the drm_dev_put().
>
> This is made possible by a preceeding patch which added a drmm_
> cleanup action to drm_mode_config_init(), hence all we need to do to
drm_dp_mst_port_add_connector() directly calls the
drm_connector_register() now and
drm_dp_mst_topology_mgr_cbs.register_connector callback is not getting
called anymore.
Hence remove all drm_dp_mst_topology_mgr_cbs.register_connector
callbacks.
This is the preparatory step for removing the
drm_d
drm_dp_mst_topology_mgr_cbs.register_connector callbacks are identical
amongst every driver and don't do anything other than calling
drm_connector_register().
drm_dp_mst_topology_mgr_cbs.destroy_connector callbacks are identical
amongst every driver and don't do anything other than cleaning up the
Now drm_dp_mst_topology_cbs.register_connector callback is not getting
used anymore hence remove it.
Signed-off-by: Pankaj Bharadiya
Suggested-by: Emil Velikov
Suggested-by: Lyude Paul
---
include/drm/drm_dp_mst_helper.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/include/drm/drm_dp_mst
drm_dp_mst_topology_mgr_cbs.destroy_connector callbacks are identical
amongst every driver and don't do anything other than cleaning up the
connector (drm_connector_unregister()/drm_connector_put()) except for
amdgpu_dm driver where some amdgpu_dm specific code in there which I
an not sure if it sh
drm_dp_mst_topology_mgr_cbs.register_connector callbacks are literally
identical amongst every driver and don't do anything other than
calling drm_connector_register(). Hence call drm_connector_register()
directly instead of a callback.
This is the preparatory step for removing the
drm_dp_mst_topo
drm_dp_mst_topology_mgr_cbs.destroy_connector callbacks are identical
amongst every driver and don't do anything other than cleaning up the
connector((drm_connector_unregister()/drm_connector_put())) except for
amdgpu_dm driver where some amdgpu_dm specific code in there.
This connector cleaning u
On Mon, Mar 02, 2020 at 11:26:18PM +0100, Daniel Vetter wrote:
> It's right above the drm_dev_put().
>
> This is made possible by a preceeding patch which added a drmm_
> cleanup action to drm_mode_config_init(), hence all we need to do to
> ensure that drm_mode_config_cleanup() is run on final dr
On Mon, Mar 02, 2020 at 11:26:20PM +0100, Daniel Vetter wrote:
> It's right above the drm_dev_put().
>
> This is made possible by a preceeding patch which added a drmm_
> cleanup action to drm_mode_config_init(), hence all we need to do to
> ensure that drm_mode_config_cleanup() is run on final dr
On Mon, Mar 02, 2020 at 11:26:26PM +0100, Daniel Vetter wrote:
> Allows us to drop the drm_driver.release callback.
>
> This is made possible by a preceeding patch which added a drmm_
> cleanup action to drm_mode_config_init(), hence all we need to do to
> ensure that drm_mode_config_cleanup() is
Pull the drm_pci_agp_init() underneath the legacy ifdeffry alongside its
only caller.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/drm_pci.c | 24
1 file changed, 12 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/drm_pci.c b/drivers/gpu/drm/drm_pci.c
ind
Hi Daniel.
On Mon, Mar 02, 2020 at 11:26:31PM +0100, Daniel Vetter wrote:
> All collected together to provide a consistent story in one patch,
> instead of the somewhat bumpy refactor-evolution leading to this.
>
> Also some thoughts on what the next steps could be:
>
> - Create a macro called d
Hi Chris.
On Sat, Mar 07, 2020 at 09:37:02AM +, Chris Wilson wrote:
> Pull the drm_pci_agp_init() underneath the legacy ifdeffry alongside its
> only caller.
>
> Signed-off-by: Chris Wilson
I dunno this code - but patch is obviously correct.
This diff is a bit weird as it shows that another
Hi Icenowy,
On 5/3/20 19:35, Icenowy Zheng wrote:
>
>
> 于 2020年3月6日 GMT+08:00 上午2:29:33, Vasily Khoruzhick 写到:
>> On Thu, Mar 5, 2020 at 7:28 AM Enric Balletbo i Serra
>> wrote:
>>>
>>> Hi Vasily,
>>
>> CC: Icenowy and Ondrej
>>>
>>> Would you mind to check which firmware version is running th
Add support for Visionox panel driver.
Signed-off-by: Harigovindan P
---
Changes in v2:
- Dropping redundant space in Kconfig(Sam Ravnborg).
- Changing structure for include files(Sam Ravnborg).
- Removing backlight related code and functions(Sam Ravnborg).
- Remo
On Fri, Mar 06, 2020 at 08:11:07PM +0800, Nicolas Boichat wrote:
> On Fri, Mar 6, 2020 at 8:07 PM Ondřej Jirman wrote:
>
> What about the values at 0x2c?
i2cdump 0 0x28
0 1 2 3 4 5 6 7 8 9 a b c d e f0123456789abcdef
00: aa aa 88 76 ac 00 00 00 00 00 00 00 00 80 05 05
Current dts files with 'vop' nodes are manually verified.
In order to automate this process rockchip-vop.txt
has to be converted to yaml. Also included are new
properties needed for the latest Rockchip Socs.
Added properties:
assigned-clocks
assigned-clock-rates
power-domains
rockchip,grf
Hi Liviu,
On 3/5/20 6:42 PM, Liviu Dudau wrote:
> On Wed, Mar 04, 2020 at 02:54:12PM +, Vincenzo Frascino wrote:
>> komeda_rt_pm_suspend() and komeda_rt_pm_resume() are compiled only when
>> CONFIG_PM is enabled. Having it disabled triggers the following warning
>> at compile time:
>>
>> linux
在 2020-03-06星期五的 09:46 +0100，Enric Balletbo i Serra写道：
> Hi Ondrej,
>
> On 5/3/20 20:35, Ondřej Jirman wrote:
> > Hi,
> >
> > On Thu, Mar 05, 2020 at 10:29:33AM -0800, Vasily Khoruzhick wrote:
> > > On Thu, Mar 5, 2020 at 7:28 AM Enric Balletbo i Serra
> > > wrote:
> > > > Hi Vasily,
> > >
> >
Hi Ondrej,
On 5/3/20 20:35, Ondřej Jirman wrote:
> Hi,
>
> On Thu, Mar 05, 2020 at 10:29:33AM -0800, Vasily Khoruzhick wrote:
>> On Thu, Mar 5, 2020 at 7:28 AM Enric Balletbo i Serra
>> wrote:
>>>
>>> Hi Vasily,
>>
>> CC: Icenowy and Ondrej
>>>
>>> Would you mind to check which firmware version
Fix kernel doc comments to avoid warnings when compiling with W=1.
Signed-off-by: Benjamin Gaignard
---
drivers/gpu/drm/drm_vm.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/drm_vm.c b/drivers/gpu/drm/drm_vm.c
index 64619fe90046..aa88911bbc
MSM Mobile Display Subsytem(MDSS) encapsulates sub-blocks
like DPU display controller, DSI etc. Add YAML schema
for the device tree bindings for the same.
Signed-off-by: Krishna Manikandan
---
.../bindings/display/msm/dpu-sc7180.yaml | 269 +++
.../bindings/display/msm/dpu-
On Fri, Mar 06, 2020 at 04:53:46PM +0800, Icenowy Zheng wrote:
> 在 2020-03-06星期五的 09:46 +0100，Enric Balletbo i Serra写道：
> > Hi Ondrej,
> >
> > On 5/3/20 20:35, Ondřej Jirman wrote:
> > > Hi,
> > >
> > > On Thu, Mar 05, 2020 at 10:29:33AM -0800, Vasily Khoruzhick wrote:
> > > > On Thu, Mar 5, 2020
Adding support for visionox rm69299 panel driver and adding bindings for the
same panel.
Harigovindan P (2):
dt-bindings: display: add visionox rm69299 panel variant
drm/panel: add support for rm69299 visionox panel driver
.../display/panel/visionox,rm69299.yaml | 85 +
drivers/g
Hello,
syzbot found the following crash on:
HEAD commit:63623fd4 Merge tag 'for-linus' of git://git.kernel.org/pub..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=11653ac3e0
kernel config: https://syzkaller.appspot.com/x/.config?x=9833e26bab355358
das
Hi Stephen,
On 5/3/20 22:01, Stephen Boyd wrote:
> Quoting Enric Balletbo i Serra (2020-03-02 03:01:26)
>> From: Matthias Brugger
>>
>> There is no strong reason for this to use CLK_OF_DECLARE instead of
>> being a platform driver.
>
> Cool.
>
>> Plus, this driver provides clocks but also
>> a
Add bindings for visionox rm69299 panel.
Signed-off-by: Harigovindan P
---
Changes in v2:
- Removed unwanted properties from description.
- Creating source files without execute permissions(Rob Herring).
Changes in v3:
- Changing txt file into yaml
Changes in v4:
Fix kernel doc comments to avoid warnings when compiling with W=1.
Signed-off-by: Benjamin Gaignard
---
drivers/gpu/drm/drm_lock.c | 11 +--
1 file changed, 5 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/drm_lock.c b/drivers/gpu/drm/drm_lock.c
index 2c79e8199e3c..f16eefbf2
From: Nicolas Boichat
Add documentation for DT properties supported by the ANX7688 HDMI-DP
converter.
Signed-off-by: Nicolas Boichat
Signed-off-by: Hsin-Yi Wang
Signed-off-by: Enric Balletbo i Serra
---
Changes in v3:
- Adapt the bridge bindings for the multi-function device.
Changes in v2:
From: Randy Dunlap
DRM_RCAR_CMM depends on DRM_RCAR_DU. Since the following Kconfig
symbols do not depend on DRM_RCAR_DU, the menu presentation is
broken for these and following non-R-Car Kconfig symbols.
Use an if/endif block to make all of these symbols depend on
DRM_RCAR_DU (and remove the se
From: Fabrizio Castro
Add binding for the idk-2121wr LVDS panel from Advantech.
Some panel-specific documentation can be found here:
https://buy.advantech.eu/Displays/Embedded-LCD-Kits-High-Brightness/model-IDK-2121WR-K2FHA2E.htm
Signed-off-by: Fabrizio Castro
Signed-off-by: Lad Prabhakar
---
On 2020-02-04 23:52, Doug Anderson wrote:
Hi,
On Tue, Feb 4, 2020 at 6:15 AM Harigovindan P
wrote:
Updating bindings of dsi and dpu by adding and removing certain
properties.
Signed-off-by: Harigovindan P
---
Changes in v1:
- Adding "ahb" clock as a required property.
- Ad
On Fri, Mar 06, 2020 at 09:46:51AM +0100, Enric Balletbo i Serra wrote:
> Hi Ondrej,
>
> On 5/3/20 20:35, Ondřej Jirman wrote:
> > Hi,
> >
> > On Thu, Mar 05, 2020 at 10:29:33AM -0800, Vasily Khoruzhick wrote:
> >> On Thu, Mar 5, 2020 at 7:28 AM Enric Balletbo i Serra
> >> wrote:
> >>>
> >>> Hi
Hi James,
On 3/6/20 4:14 AM, james qian wang (Arm Technology China) wrote:
> On Fri, Mar 06, 2020 at 02:42:55AM +0800, Liviu Dudau wrote:
>> On Wed, Mar 04, 2020 at 02:54:12PM +, Vincenzo Frascino wrote:
>>> komeda_rt_pm_suspend() and komeda_rt_pm_resume() are compiled only when
>>> CONFIG_PM
Fix kernel doc comments to avoid warnings when compiling with W=1.
Signed-off-by: Benjamin Gaignard
---
version 2:
- Since it is legacy interface do not fix the description but
replace /** by /* to remove kerneldoc validation warnings
drivers/gpu/drm/drm_context.c | 28 ++-
On 3/6/20 6:28 AM, Laurent Pinchart wrote:
> Hi Randy,
>
> On Thu, Mar 05, 2020 at 07:17:49PM -0800, Randy Dunlap wrote:
>> From: Randy Dunlap
>>
>> DRM_RCAR_CMM depends on DRM_RCAR_DU. Since the following Kconfig
>> symbols do not depend on DRM_RCAR_DU, the menu presentation is
>> broken for the
Fix kernel doc comments to avoid warnings when compiling with W=1.
Signed-off-by: Benjamin Gaignard
---
drivers/gpu/drm/drm_bufs.c | 20 ++--
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/drm_bufs.c b/drivers/gpu/drm/drm_bufs.c
index 19297e58b232
From: Nicolas Boichat
This driver adds support for the ANX7688 HDMI to DP converter block of the
ANX7688 multi-function device.
For our use case, the only reason the Linux kernel driver is necessary is
to reject resolutions that require more bandwidth than what is available
on the DP side. DP ba
hi andrzej,
I had a doubt In the tc358764 driver,VP_CTRL, VP_CTRL_VSDELAY(15) is
hardcoded to 15, but this has to be dynamic based on the resolution of
panel used?
Please see the reply inline.
On Tue, Mar 3, 2020 at 8:39 PM Andrzej Hajda wrote:
>
> On 27.02.2020 15:03, Vinay Simha BN wrote:
> >
Series has my r-b :)
On Fri, Mar 06, 2020 at 12:13:41PM +0800, Nicolas Boichat wrote:
> Hi!
>
> Follow-up on the v4: https://patchwork.kernel.org/cover/11369777/, some
> of the core patches got merged already (thanks Rob!).
>
> The main purpose of this series is to upstream the dts change and th
On 6/3/20 13:03, Ondřej Jirman wrote:
> On Fri, Mar 06, 2020 at 09:46:51AM +0100, Enric Balletbo i Serra wrote:
>> Hi Ondrej,
>>
>> On 5/3/20 20:35, Ondřej Jirman wrote:
>>> Hi,
>>>
>>> On Thu, Mar 05, 2020 at 10:29:33AM -0800, Vasily Khoruzhick wrote:
On Thu, Mar 5, 2020 at 7:28 AM Enric Ba
On Fri, Mar 6, 2020 at 9:32 AM Kees Cook wrote:
>
> Variables declared in a switch statement before any case statements
> cannot be automatically initialized with compiler instrumentation (as
> they are not part of any execution flow). With GCC's proposed automatic
> stack variable initialization
On Fri, Mar 6, 2020 at 9:36 AM Nick Desaulniers wrote:
>
> On Fri, Mar 6, 2020 at 9:32 AM Kees Cook wrote:
> >
> > Variables declared in a switch statement before any case statements
> > cannot be automatically initialized with compiler instrumentation (as
> > they are not part of any execution f
Hi Krishna.
Thanks for these bindings files.
On Fri, Mar 06, 2020 at 05:06:00PM +0530, Krishna Manikandan wrote:
> MSM Mobile Display Subsytem(MDSS) encapsulates sub-blocks
> like DPU display controller, DSI etc. Add YAML schema
> for the device tree bindings for the same.
>
> Signed-off-by: Kri
Hi,
On 3/6/20 11:41 AM, Daniel Vetter wrote:
On Thu, Mar 05, 2020 at 03:22:38PM +0100, Hans de Goede wrote:
Hi,
On 3/5/20 11:55 AM, Gustavo A. R. Silva wrote:
The current codebase makes use of the zero-length array language
extension to the C90 standard, but the preferred mechanism to declare
Hi,
On 3/7/20 12:46 AM, Lyude Paul wrote:
AMD's patch series for adding DSC support to the MST helpers
unfortunately introduced a few regressions into the kernel that I didn't
get around to fixing until just now. I would have reverted the changes
earlier, but seeing as that would have reverted a
Hi Lyude,
On 3/7/20 12:54 AM, Lyude Paul wrote:
On Wed, 2020-02-26 at 18:52 +0100, Hans de Goede wrote:
Hi,
On 2/26/20 5:05 PM, Alex Deucher wrote:
On Wed, Feb 26, 2020 at 10:43 AM Hans de Goede
wrote:
Hi,
On 2/26/20 4:29 PM, Alex Deucher wrote:
On Wed, Feb 26, 2020 at 10:16 AM Hans de Go
Save all information to start a task which can be exported to user
for debug usage. Dump file data format is specified in lima_dump.h
v2:
Add include header to address build robot complain.
Signed-off-by: Qiang Yu
---
drivers/gpu/drm/lima/lima_device.c | 13 +++
drivers/gpu/drm/lima/lima_devic
track lima task start which can be combined with
dma_fence_signal to identify task execution time.
example command to record:
trace-cmd record -i \
-e "lima:lima_task_submit" -e "lima:lima_task_run" \
-e "*fence:*fence_signaled" -e "drm:drm_vblank_event" \
-e "drm:drm_vblank_event_queued" s
coder_init/20200306-045931
base:47466dcf84ee66a973ea7d2fca7e582fe9328932
config: i386-randconfig-h001-20200307 (attached as .config)
compiler: gcc-7 (Debian 7.5.0-5) 7.5.0
reproduce:
# save the attached .config to linux build tree
make ARCH=i386
If you fix the issue, kindly add fol
Hi Ville,
On Mon, Mar 2, 2020 at 9:34 PM Ville Syrjala
wrote:
> .mode = {
> /* The internal pixel clock of the NT35510 is 20 MHz */
> - .clock = 2000,
> + .clock = 23581,
I double checked this with the datasheet NT35510 Application Note V0
Hi Ville!
On Mon, Mar 2, 2020 at 9:35 PM Ville Syrjala
wrote:
> From: Ville Syrjälä
>
> The currently listed dotclocks disagree with the currently
> listed vrefresh rates. Change the dotclocks to match the vrefresh.
>
> Someone tell me which (if either) of the dotclock or vreresh is
> correct?
On Mon, Mar 2, 2020 at 9:35 PM Ville Syrjala
wrote:
> From: Ville Syrjälä
>
> The currently listed dotclocks disagree with the currently
> listed vrefresh rates. Change the dotclocks to match the vrefresh.
>
> Someone tell me which (if either) of the dotclock or vreresh is
> correct?
>
> Cc: Lin
From: Leon He
There are two errors in the dmabuf-heap selftest:
1. The 'char name[5]' was not initialized to zero, which will cause
strcmp(name, "vgem") failed in check_vgem().
2. The return value of test_alloc_errors() should be reversed, other-
wise the while loop in main() will be broken
On Fri, 06 Mar 2020 21:41:13 -0800
> syzbot found the following crash on:
>
> HEAD commit:63623fd4 Merge tag 'for-linus' of git://git.kernel.org/pub..
> git tree: upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=11653ac3e0
> kernel config: https://syzkaller.app
Hi Emil,
Maybe here is your missing comments
I ’m really sorry, sometimes I forget to use plain text by gmail,
never make the same mistake again.
Emil Velikov 于2020年3月3日周二 上午2:29写道：
>
> Hi Kevin,
>
> There's a few small suggestions, although overall the driver looks a lot
> better.
>
> On Thu, 2
Emil Velikov 于2020年3月7日周六 上午1:14写道：
>
> On Thu, 5 Mar 2020 at 13:15, tang pengchuan wrote:
> > On Tue, Mar 3, 2020 at 2:29 AM Emil Velikov
> > wrote:
>
> >> Have you seen a case where the 0 or default case are reached? AFAICT they
> >> will
> >> never trigger. So one might as well use:
> >>
>
drivers-to-drm_simple_encoder_init/20200306-045931
base:47466dcf84ee66a973ea7d2fca7e582fe9328932
config: x86_64-randconfig-h002-20200307 (attached as .config)
compiler: gcc-7 (Debian 7.5.0-5) 7.5.0
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64
If y
coder_init/20200306-045931
base:47466dcf84ee66a973ea7d2fca7e582fe9328932
config: i386-randconfig-h002-20200307 (attached as .config)
compiler: gcc-7 (Debian 7.5.0-5) 7.5.0
reproduce:
# save the attached .config to linux build tree
make ARCH=i386
If you fix the issue, kindly add fol
Hi Kevin
> > > +
> > > +ifdef CONFIG_ARM64
> > > +KBUILD_CFLAGS += -mstrict-align
> >
> >
> > There are many other drivers that do not use readl/writel for register
> > access,
> > yet none has this workaround... Even those that they are exclusively ARM64.
> >
> > Have you tried that it's not a b
Hi Peter.
On Thu, Mar 05, 2020 at 01:07:07PM +, Peter Rosin wrote:
> This reverts commit 0f9cdd743f7f8d470fff51b11250f02fc554cf1b.
>
> The interface of the panel is LVDS, not parallel.
> The color depth is RGB888, not RGB565.
> The panel has additional features, making it not so simple.
> Th
Hi Thomas.
On Fri, Mar 06, 2020 at 04:18:52PM +0100, Thomas Zimmermann wrote:
> Hi Laurent
>
> Am 06.03.20 um 15:22 schrieb Laurent Pinchart:
> > Hi Thomas,
> >
> > Thank you for the patch.
> >
> > On Thu, Mar 05, 2020 at 04:59:28PM +0100, Thomas Zimmermann wrote:
> >> A call to drm_simple_enco
Hi Sam,
On Sat, Mar 07, 2020 at 09:08:13PM +0100, Sam Ravnborg wrote:
> On Fri, Mar 06, 2020 at 04:18:52PM +0100, Thomas Zimmermann wrote:
> > Am 06.03.20 um 15:22 schrieb Laurent Pinchart:
> > > On Thu, Mar 05, 2020 at 04:59:28PM +0100, Thomas Zimmermann wrote:
> > >> A call to drm_simple_encoder
Hi Laurent.
On Sat, Mar 07, 2020 at 10:34:45PM +0200, Laurent Pinchart wrote:
> Hi Sam,
>
> On Sat, Mar 07, 2020 at 09:08:13PM +0100, Sam Ravnborg wrote:
> > On Fri, Mar 06, 2020 at 04:18:52PM +0100, Thomas Zimmermann wrote:
> > > Am 06.03.20 um 15:22 schrieb Laurent Pinchart:
> > > > On Thu, Mar
On 05/03/2020 16:59, Thomas Zimmermann wrote:
> The mediatak driver uses empty implementations for its encoders. Replace
> the code with the generic simple encoder.
>
> Signed-off-by: Thomas Zimmermann
Reviewed-by: Matthias Brugger
> ---
> drivers/gpu/drm/mediatek/mtk_dpi.c | 14 +++---
https://bugzilla.kernel.org/show_bug.cgi?id=206781
Bug ID: 206781
Summary: GM104 (GeForce 840m) with many errors "fifo:
SCHED_ERROR 20"
Product: Drivers
Version: 2.5
Kernel Version: 5.4
Hardware: All
OS:
https://bugzilla.kernel.org/show_bug.cgi?id=206781
Ilia Mirkin (imir...@alum.mit.edu) changed:
What|Removed |Added
CC||imir...@alum.mit.edu
Hi
[This is an automated email]
This commit has been processed because it contains a "Fixes:" tag
fixing commit: ee5e5e7a5e0f ("drm/i915: Add HDCP framework + base
implementation").
The bot has tested the following trees: v5.5.8, v5.4.24, v4.19.108.
v5.5.8: Build failed! Errors:
drivers/gp
Hi
[This is an automated email]
This commit has been processed because it contains a "Fixes:" tag
fixing commit: ee5e5e7a5e0f ("drm/i915: Add HDCP framework + base
implementation").
The bot has tested the following trees: v5.5.8, v5.4.24, v4.19.108.
v5.5.8: Failed to apply! Possible dependenci
Update my email address to @kernel.org
Signed-off-by: Chun-Kuang Hu
---
MAINTAINERS | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 38fe2f3f7b6f..dceaeebce52a 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -5607,7 +5607,7 @@ F:include/ua
75 matches
Mail list logo
