March 2020 - Linux-stable-mirror

[PATCH AUTOSEL 5.5 01/28] thunderbolt: Fix error code in tb_port_is_width_supported()

by Sasha Levin

From: Dan Carpenter <dan.carpenter(a)oracle.com> [ Upstream commit e9d0e7511fda92a6511904996dd0aa57b6d7687a ] This function is type bool, and it's supposed to return true on success. Unfortunately, this path takes negative error codes and casts them to bool (true) so it's treated as success instead of failure. Fixes: 91c0c12080d0 ("thunderbolt: Add support for lane bonding") Signed-off-by: Dan Carpenter <dan.carpenter(a)oracle.com> Signed-off-by: Mika Westerberg <mika.westerberg(a)linux.intel.com> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- drivers/thunderbolt/switch.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/thunderbolt/switch.c b/drivers/thunderbolt/switch.c index 43bfeb8866141..f0f77da6ca26d 100644 --- a/drivers/thunderbolt/switch.c +++ b/drivers/thunderbolt/switch.c @@ -848,7 +848,7 @@ static bool tb_port_is_width_supported(struct tb_port *port, int width) ret = tb_port_read(port, &phy, TB_CFG_PORT, port->cap_phy + LANE_ADP_CS_0, 1); if (ret) - return ret; + return false; widths = (phy & LANE_ADP_CS_0_SUPPORTED_WIDTH_MASK) >> LANE_ADP_CS_0_SUPPORTED_WIDTH_SHIFT; -- 2.20.1

5 years, 1 month

4
32
0 0

Re: [PATCH] kernel/taskstats: fix wrong nla type for {cgroup,task}stats policy

by Johannes Berg

On Thu, 2020-03-26 at 13:08 -0700, Andrew Morton wrote: > > After our server is upgraded to a newer kernel, we found that it > > continuesly print a warning in the kernel message. The warning is, > > [832984.946322] netlink: 'irmas.lc': attribute type 1 has an invalid length. > > > > irmas.lc is one of our container monitor daemons, and it will use > > CGROUPSTATS_CMD_GET to get the cgroupstats, that is similar with > > tools/accounting/getdelays.c. We can also produce this warning with > > getdelays. For example, after running bellow command > > $ ./getdelays -C /sys/fs/cgroup/memory > > then you can find a warning in dmesg, > > [61607.229318] netlink: 'getdelays': attribute type 1 has an invalid length. > > > > This warning is introduced in commit 6e237d099fac ("netlink: Relax attr > > validation for fixed length types"), which is used to check whether > > attributes using types NLA_U* and NLA_S* have an exact length. > > > > Regarding this issue, the root cause is cgroupstats_cmd_get_policy defines > > a wrong type as NLA_U32, while it should be NLA_NESTED an its minimal > > length is NLA_HDRLEN. That is similar to taskstats_cmd_get_policy. > > > > As this behavior change really breaks our application, we'd better > > cc stable as well. Can you explain how it breaks the application? I mean, it's really only printing a message to the kernel log in this case? At least that's what you're describing. I think you may be describing it wrong, because an NLA_NESTED is allowed to be *empty* (but otherwise must have at least 4 bytes just like an NLA_U32). That said, I'm not even sure I agree that this fix is right? See below. > Is it correct to say that although the code has always been incorrect, > but only kernels after 6e237d099fac need this change? If so, I'll add > Fixes:6e237d099fac to guide the -stable backporting. That doesn't really seem right - 6e237d099fac *relaxed* the checks. If anything then it ought to point to 28033ae4e0f5 which may have actually returned an error; but again, need to understand better what really the issue is. > > diff --git a/kernel/taskstats.c b/kernel/taskstats.c > > index e2ac0e3..b90a520 100644 > > --- a/kernel/taskstats.c > > +++ b/kernel/taskstats.c > > @@ -35,8 +35,8 @@ > > static struct genl_family family; > > > > static const struct nla_policy taskstats_cmd_get_policy[TASKSTATS_CMD_ATTR_MAX+1] = { > > - [TASKSTATS_CMD_ATTR_PID] = { .type = NLA_U32 }, > > - [TASKSTATS_CMD_ATTR_TGID] = { .type = NLA_U32 }, > > + [TASKSTATS_CMD_ATTR_PID] = { .type = NLA_NESTED }, > > + [TASKSTATS_CMD_ATTR_TGID] = { .type = NLA_NESTED }, I'm not sure where this is coming from - the kernel evidently uses them as nested attributes in *outgoing* data (see mk_reply()), but as NLA_U32 in *incoming* data, (see cmd_attr_pid() and cmd_attr_tgid()). I would generally recommend not doing such a thing as it's messy, but we do have quite a few such instances cases. In all those cases must the policy list the incoming policy since that's what the kernel uses to validate the attributes. IOW, this part of the change seems _wrong_. > > * Make sure they are always aligned. > > */ > > static const struct nla_policy cgroupstats_cmd_get_policy[TASKSTATS_CMD_ATTR_MAX+1] = { > > - [CGROUPSTATS_CMD_ATTR_FD] = { .type = NLA_U32 }, > > + [CGROUPSTATS_CMD_ATTR_FD] = { .type = NLA_NESTED }, > > }; And same here, actually. johannes

5 years, 1 month

2
1
0 0

Re: [PATCH] kernel/taskstats: fix wrong nla type for {cgroup,task}stats policy

by Johannes Berg

On Thu, 2020-03-26 at 13:08 -0700, Andrew Morton wrote: > (cc's added) > > On Wed, 25 Mar 2020 22:50:42 -0400 Yafang Shao <laoar.shao(a)gmail.com> wrote: > > > After our server is upgraded to a newer kernel, we found that it > > continuesly print a warning in the kernel message. The warning is, > > [832984.946322] netlink: 'irmas.lc': attribute type 1 has an invalid length. > > > > irmas.lc is one of our container monitor daemons, and it will use > > CGROUPSTATS_CMD_GET to get the cgroupstats, that is similar with > > tools/accounting/getdelays.c. We can also produce this warning with > > getdelays. For example, after running bellow command > > $ ./getdelays -C /sys/fs/cgroup/memory > > then you can find a warning in dmesg, > > [61607.229318] netlink: 'getdelays': attribute type 1 has an invalid length. And looking at this ... well, that code is completely wrong? E.g. rc = send_cmd(nl_sd, id, mypid, TASKSTATS_CMD_GET, cmd_type, &tid, sizeof(__u32)); (cmd_type is one of TASKSTATS_CMD_ATTR_TGID, TASKSTATS_CMD_ATTR_PID) or it might do rc = send_cmd(nl_sd, id, mypid, CGROUPSTATS_CMD_GET, CGROUPSTATS_CMD_ATTR_FD, &cfd, sizeof(__u32)); so clearly it wants to produce a u32 attribute. But then static int send_cmd(int sd, __u16 nlmsg_type, __u32 nlmsg_pid, __u8 genl_cmd, __u16 nla_type, void *nla_data, int nla_len) { ... na = (struct nlattr *) GENLMSG_DATA(&msg); // this is still fine na->nla_type = nla_type; // this is also fine na->nla_len = nla_len + 1 + NLA_HDRLEN; // but this??? the nla_len of a netlink attribute should just be // the len ... what's NLA_HDRLEN doing here? this isn't nested // here we end up just reserving 1+NLA_HDRLEN too much space memcpy(NLA_DATA(na), nla_data, nla_len); // but then it anyway only fills the first nla_len bytes, which // is just like a regular attribute. msg.n.nlmsg_len += NLMSG_ALIGN(na->nla_len); // note that this is also wrong - it should be // += NLA_ALIGN(NLA_HDRLEN + nla_len) So really I think what happened here is precisely what we wanted - David's kernel patch caught the broken userspace tool. johannes

5 years, 1 month

3
3
0 0

[PATCH v4 2/7] ima: Evaluate error in init_ima()

by Roberto Sassu

Evaluate error in init_ima() before register_blocking_lsm_notifier() and return if not zero. Cc: stable(a)vger.kernel.org # 5.3.x Fixes: b16942455193 ("ima: use the lsm policy update notifier") Signed-off-by: Roberto Sassu <roberto.sassu(a)huawei.com> --- security/integrity/ima/ima_main.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/security/integrity/ima/ima_main.c b/security/integrity/ima/ima_main.c index 9d0abedeae77..f96f151294e6 100644 --- a/security/integrity/ima/ima_main.c +++ b/security/integrity/ima/ima_main.c @@ -792,6 +792,9 @@ static int __init init_ima(void) error = ima_init(); } + if (error) + return error; + error = register_blocking_lsm_notifier(&ima_lsm_policy_notifier); if (error) pr_warn("Couldn't register LSM notifier, error %d\n", error); -- 2.17.1

5 years, 1 month

2
1
0 0

[PATCH for-rc 1/2] IB/hfi1: Fix memory leaks in sysfs registration and unregistration

by Dennis Dalessandro

From: Kaike Wan <kaike.wan(a)intel.com> When the hfi1 driver is unloaded, kmemleak will report the following issue: unreferenced object 0xffff8888461a4c08 (size 8): comm "kworker/0:0", pid 5, jiffies 4298601264 (age 2047.134s) hex dump (first 8 bytes): 73 64 6d 61 30 00 ff ff sdma0... backtrace: [<00000000311a6ef5>] kvasprintf+0x62/0xd0 [<00000000ade94d9f>] kobject_set_name_vargs+0x1c/0x90 [<0000000060657dbb>] kobject_init_and_add+0x5d/0xb0 [<00000000346fe72b>] 0xffffffffa0c5ecba [<000000006cfc5819>] 0xffffffffa0c866b9 [<0000000031c65580>] 0xffffffffa0c38e87 [<00000000e9739b3f>] local_pci_probe+0x41/0x80 [<000000006c69911d>] work_for_cpu_fn+0x16/0x20 [<00000000601267b5>] process_one_work+0x171/0x380 [<0000000049a0eefa>] worker_thread+0x1d1/0x3f0 [<00000000909cf2b9>] kthread+0xf8/0x130 [<0000000058f5f874>] ret_from_fork+0x35/0x40 This patch fixes the issue by: - Releasing dd->per_sdma[i].kobject in hfi1_unregister_sysfs(). - This will fix the memory leak. - Calling kobject_put() to unwind operations only for those entries in dd->per_sdma[] whose operations have succeeded (including the current one that has just failed) in hfi1_verbs_register_sysfs(). Fixes: 0cb2aa690c7e ("IB/hfi1: Add sysfs interface for affinity setup") Cc: <stable(a)vger.kernel.org> Reviewed-by: Mike Marciniszyn <mike.marciniszyn(a)intel.com> Signed-off-by: Kaike Wan <kaike.wan(a)intel.com> Signed-off-by: Dennis Dalessandro <dennis.dalessandro(a)intel.com> --- drivers/infiniband/hw/hfi1/sysfs.c | 13 +++++++++++-- 1 file changed, 11 insertions(+), 2 deletions(-) diff --git a/drivers/infiniband/hw/hfi1/sysfs.c b/drivers/infiniband/hw/hfi1/sysfs.c index 90f62c4..f1bcecf 100644 --- a/drivers/infiniband/hw/hfi1/sysfs.c +++ b/drivers/infiniband/hw/hfi1/sysfs.c @@ -853,8 +853,13 @@ int hfi1_verbs_register_sysfs(struct hfi1_devdata *dd) return 0; bail: - for (i = 0; i < dd->num_sdma; i++) - kobject_del(&dd->per_sdma[i].kobj); + /* + * The function kobject_put() will call kobject_del() if the kobject + * has been added successfully. The sysfs files created under the + * kobject directory will also be removed during the process. + */ + for (; i >= 0; i--) + kobject_put(&dd->per_sdma[i].kobj); return ret; } @@ -867,6 +872,10 @@ void hfi1_verbs_unregister_sysfs(struct hfi1_devdata *dd) struct hfi1_pportdata *ppd; int i; + /* Unwind operations in hfi1_verbs_register_sysfs() */ + for (i = 0; i < dd->num_sdma; i++) + kobject_put(&dd->per_sdma[i].kobj); + for (i = 0; i < dd->num_pports; i++) { ppd = &dd->pport[i];

5 years, 1 month

3
6
0 0

[PATCH AUTOSEL 4.4 1/4] ALSA: hda/realtek: Fix pop noise on ALC225

by Sasha Levin

From: Kai-Heng Feng <kai.heng.feng(a)canonical.com> [ Upstream commit 3b36b13d5e69d6f51ff1c55d1b404a74646c9757 ] Commit 317d9313925c ("ALSA: hda/realtek - Set default power save node to 0") makes the ALC225 have pop noise on S3 resume and cold boot. So partially revert this commit for ALC225 to fix the regression. Fixes: 317d9313925c ("ALSA: hda/realtek - Set default power save node to 0") BugLink: https://bugs.launchpad.net/bugs/1866357 Signed-off-by: Kai-Heng Feng <kai.heng.feng(a)canonical.com> Link: https://lore.kernel.org/r/20200311061328.17614-1-kai.heng.feng@canonical.com Signed-off-by: Takashi Iwai <tiwai(a)suse.de> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- sound/pci/hda/patch_realtek.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c index 55bae9e6de27d..76cf438aa339c 100644 --- a/sound/pci/hda/patch_realtek.c +++ b/sound/pci/hda/patch_realtek.c @@ -6333,6 +6333,8 @@ static int patch_alc269(struct hda_codec *codec) alc_update_coef_idx(codec, 0x36, 1 << 13, 1 << 5); /* Switch pcbeep path to Line in path*/ break; case 0x10ec0225: + codec->power_save_node = 1; + /* fall through */ case 0x10ec0295: case 0x10ec0299: spec->codec_variant = ALC269_TYPE_ALC225; -- 2.20.1

5 years, 1 month

1
3
0 0

[PATCH AUTOSEL 4.9 1/7] ALSA: hda/realtek: Fix pop noise on ALC225

by Sasha Levin

From: Kai-Heng Feng <kai.heng.feng(a)canonical.com> [ Upstream commit 3b36b13d5e69d6f51ff1c55d1b404a74646c9757 ] Commit 317d9313925c ("ALSA: hda/realtek - Set default power save node to 0") makes the ALC225 have pop noise on S3 resume and cold boot. So partially revert this commit for ALC225 to fix the regression. Fixes: 317d9313925c ("ALSA: hda/realtek - Set default power save node to 0") BugLink: https://bugs.launchpad.net/bugs/1866357 Signed-off-by: Kai-Heng Feng <kai.heng.feng(a)canonical.com> Link: https://lore.kernel.org/r/20200311061328.17614-1-kai.heng.feng@canonical.com Signed-off-by: Takashi Iwai <tiwai(a)suse.de> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- sound/pci/hda/patch_realtek.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c index a64612db1f155..d7b33c9c9f40b 100644 --- a/sound/pci/hda/patch_realtek.c +++ b/sound/pci/hda/patch_realtek.c @@ -6410,6 +6410,8 @@ static int patch_alc269(struct hda_codec *codec) spec->gen.mixer_nid = 0; break; case 0x10ec0225: + codec->power_save_node = 1; + /* fall through */ case 0x10ec0295: spec->codec_variant = ALC269_TYPE_ALC225; break; -- 2.20.1

5 years, 1 month

1
6
0 0

[PATCH AUTOSEL 4.14 01/10] drm/bridge: dw-hdmi: fix AVI frame colorimetry

by Sasha Levin

From: Jernej Skrabec <jernej.skrabec(a)siol.net> [ Upstream commit e8dca30f7118461d47e1c3510d0e31b277439151 ] CTA-861-F explicitly states that for RGB colorspace colorimetry should be set to "none". Fix that. Acked-by: Laurent Pinchart <laurent.pinchart(a)ideasonboard.com> Fixes: def23aa7e982 ("drm: bridge: dw-hdmi: Switch to V4L bus format and encodings") Signed-off-by: Jernej Skrabec <jernej.skrabec(a)siol.net> Link: https://patchwork.freedesktop.org/patch/msgid/20200304232512.51616-2-jernej… Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 46 +++++++++++++---------- 1 file changed, 26 insertions(+), 20 deletions(-) diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c index cc1094f901255..96cf64d0ee824 100644 --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c @@ -1348,28 +1348,34 @@ static void hdmi_config_AVI(struct dw_hdmi *hdmi, struct drm_display_mode *mode) frame.colorspace = HDMI_COLORSPACE_RGB; /* Set up colorimetry */ - switch (hdmi->hdmi_data.enc_out_encoding) { - case V4L2_YCBCR_ENC_601: - if (hdmi->hdmi_data.enc_in_encoding == V4L2_YCBCR_ENC_XV601) - frame.colorimetry = HDMI_COLORIMETRY_EXTENDED; - else + if (!hdmi_bus_fmt_is_rgb(hdmi->hdmi_data.enc_out_bus_format)) { + switch (hdmi->hdmi_data.enc_out_encoding) { + case V4L2_YCBCR_ENC_601: + if (hdmi->hdmi_data.enc_in_encoding == V4L2_YCBCR_ENC_XV601) + frame.colorimetry = HDMI_COLORIMETRY_EXTENDED; + else + frame.colorimetry = HDMI_COLORIMETRY_ITU_601; + frame.extended_colorimetry = + HDMI_EXTENDED_COLORIMETRY_XV_YCC_601; + break; + case V4L2_YCBCR_ENC_709: + if (hdmi->hdmi_data.enc_in_encoding == V4L2_YCBCR_ENC_XV709) + frame.colorimetry = HDMI_COLORIMETRY_EXTENDED; + else + frame.colorimetry = HDMI_COLORIMETRY_ITU_709; + frame.extended_colorimetry = + HDMI_EXTENDED_COLORIMETRY_XV_YCC_709; + break; + default: /* Carries no data */ frame.colorimetry = HDMI_COLORIMETRY_ITU_601; + frame.extended_colorimetry = + HDMI_EXTENDED_COLORIMETRY_XV_YCC_601; + break; + } + } else { + frame.colorimetry = HDMI_COLORIMETRY_NONE; frame.extended_colorimetry = - HDMI_EXTENDED_COLORIMETRY_XV_YCC_601; - break; - case V4L2_YCBCR_ENC_709: - if (hdmi->hdmi_data.enc_in_encoding == V4L2_YCBCR_ENC_XV709) - frame.colorimetry = HDMI_COLORIMETRY_EXTENDED; - else - frame.colorimetry = HDMI_COLORIMETRY_ITU_709; - frame.extended_colorimetry = - HDMI_EXTENDED_COLORIMETRY_XV_YCC_709; - break; - default: /* Carries no data */ - frame.colorimetry = HDMI_COLORIMETRY_ITU_601; - frame.extended_colorimetry = - HDMI_EXTENDED_COLORIMETRY_XV_YCC_601; - break; + HDMI_EXTENDED_COLORIMETRY_XV_YCC_601; } frame.scan_mode = HDMI_SCAN_MODE_NONE; -- 2.20.1

5 years, 1 month

1
9
0 0

[PATCH AUTOSEL 4.19 01/15] drm/bridge: dw-hdmi: fix AVI frame colorimetry

by Sasha Levin

From: Jernej Skrabec <jernej.skrabec(a)siol.net> [ Upstream commit e8dca30f7118461d47e1c3510d0e31b277439151 ] CTA-861-F explicitly states that for RGB colorspace colorimetry should be set to "none". Fix that. Acked-by: Laurent Pinchart <laurent.pinchart(a)ideasonboard.com> Fixes: def23aa7e982 ("drm: bridge: dw-hdmi: Switch to V4L bus format and encodings") Signed-off-by: Jernej Skrabec <jernej.skrabec(a)siol.net> Link: https://patchwork.freedesktop.org/patch/msgid/20200304232512.51616-2-jernej… Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 46 +++++++++++++---------- 1 file changed, 26 insertions(+), 20 deletions(-) diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c index 2a0a1654d3ce5..6930452a712a8 100644 --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c @@ -1364,28 +1364,34 @@ static void hdmi_config_AVI(struct dw_hdmi *hdmi, struct drm_display_mode *mode) frame.colorspace = HDMI_COLORSPACE_RGB; /* Set up colorimetry */ - switch (hdmi->hdmi_data.enc_out_encoding) { - case V4L2_YCBCR_ENC_601: - if (hdmi->hdmi_data.enc_in_encoding == V4L2_YCBCR_ENC_XV601) - frame.colorimetry = HDMI_COLORIMETRY_EXTENDED; - else + if (!hdmi_bus_fmt_is_rgb(hdmi->hdmi_data.enc_out_bus_format)) { + switch (hdmi->hdmi_data.enc_out_encoding) { + case V4L2_YCBCR_ENC_601: + if (hdmi->hdmi_data.enc_in_encoding == V4L2_YCBCR_ENC_XV601) + frame.colorimetry = HDMI_COLORIMETRY_EXTENDED; + else + frame.colorimetry = HDMI_COLORIMETRY_ITU_601; + frame.extended_colorimetry = + HDMI_EXTENDED_COLORIMETRY_XV_YCC_601; + break; + case V4L2_YCBCR_ENC_709: + if (hdmi->hdmi_data.enc_in_encoding == V4L2_YCBCR_ENC_XV709) + frame.colorimetry = HDMI_COLORIMETRY_EXTENDED; + else + frame.colorimetry = HDMI_COLORIMETRY_ITU_709; + frame.extended_colorimetry = + HDMI_EXTENDED_COLORIMETRY_XV_YCC_709; + break; + default: /* Carries no data */ frame.colorimetry = HDMI_COLORIMETRY_ITU_601; + frame.extended_colorimetry = + HDMI_EXTENDED_COLORIMETRY_XV_YCC_601; + break; + } + } else { + frame.colorimetry = HDMI_COLORIMETRY_NONE; frame.extended_colorimetry = - HDMI_EXTENDED_COLORIMETRY_XV_YCC_601; - break; - case V4L2_YCBCR_ENC_709: - if (hdmi->hdmi_data.enc_in_encoding == V4L2_YCBCR_ENC_XV709) - frame.colorimetry = HDMI_COLORIMETRY_EXTENDED; - else - frame.colorimetry = HDMI_COLORIMETRY_ITU_709; - frame.extended_colorimetry = - HDMI_EXTENDED_COLORIMETRY_XV_YCC_709; - break; - default: /* Carries no data */ - frame.colorimetry = HDMI_COLORIMETRY_ITU_601; - frame.extended_colorimetry = - HDMI_EXTENDED_COLORIMETRY_XV_YCC_601; - break; + HDMI_EXTENDED_COLORIMETRY_XV_YCC_601; } frame.scan_mode = HDMI_SCAN_MODE_NONE; -- 2.20.1

5 years, 1 month

1
14
0 0

[PATCH AUTOSEL 5.4 01/19] drm/bridge: dw-hdmi: fix AVI frame colorimetry

by Sasha Levin

From: Jernej Skrabec <jernej.skrabec(a)siol.net> [ Upstream commit e8dca30f7118461d47e1c3510d0e31b277439151 ] CTA-861-F explicitly states that for RGB colorspace colorimetry should be set to "none". Fix that. Acked-by: Laurent Pinchart <laurent.pinchart(a)ideasonboard.com> Fixes: def23aa7e982 ("drm: bridge: dw-hdmi: Switch to V4L bus format and encodings") Signed-off-by: Jernej Skrabec <jernej.skrabec(a)siol.net> Link: https://patchwork.freedesktop.org/patch/msgid/20200304232512.51616-2-jernej… Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 46 +++++++++++++---------- 1 file changed, 26 insertions(+), 20 deletions(-) diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c index 1326f2c734bf8..41bf4aaff21c4 100644 --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c @@ -1576,28 +1576,34 @@ static void hdmi_config_AVI(struct dw_hdmi *hdmi, struct drm_display_mode *mode) frame.colorspace = HDMI_COLORSPACE_RGB; /* Set up colorimetry */ - switch (hdmi->hdmi_data.enc_out_encoding) { - case V4L2_YCBCR_ENC_601: - if (hdmi->hdmi_data.enc_in_encoding == V4L2_YCBCR_ENC_XV601) - frame.colorimetry = HDMI_COLORIMETRY_EXTENDED; - else + if (!hdmi_bus_fmt_is_rgb(hdmi->hdmi_data.enc_out_bus_format)) { + switch (hdmi->hdmi_data.enc_out_encoding) { + case V4L2_YCBCR_ENC_601: + if (hdmi->hdmi_data.enc_in_encoding == V4L2_YCBCR_ENC_XV601) + frame.colorimetry = HDMI_COLORIMETRY_EXTENDED; + else + frame.colorimetry = HDMI_COLORIMETRY_ITU_601; + frame.extended_colorimetry = + HDMI_EXTENDED_COLORIMETRY_XV_YCC_601; + break; + case V4L2_YCBCR_ENC_709: + if (hdmi->hdmi_data.enc_in_encoding == V4L2_YCBCR_ENC_XV709) + frame.colorimetry = HDMI_COLORIMETRY_EXTENDED; + else + frame.colorimetry = HDMI_COLORIMETRY_ITU_709; + frame.extended_colorimetry = + HDMI_EXTENDED_COLORIMETRY_XV_YCC_709; + break; + default: /* Carries no data */ frame.colorimetry = HDMI_COLORIMETRY_ITU_601; + frame.extended_colorimetry = + HDMI_EXTENDED_COLORIMETRY_XV_YCC_601; + break; + } + } else { + frame.colorimetry = HDMI_COLORIMETRY_NONE; frame.extended_colorimetry = - HDMI_EXTENDED_COLORIMETRY_XV_YCC_601; - break; - case V4L2_YCBCR_ENC_709: - if (hdmi->hdmi_data.enc_in_encoding == V4L2_YCBCR_ENC_XV709) - frame.colorimetry = HDMI_COLORIMETRY_EXTENDED; - else - frame.colorimetry = HDMI_COLORIMETRY_ITU_709; - frame.extended_colorimetry = - HDMI_EXTENDED_COLORIMETRY_XV_YCC_709; - break; - default: /* Carries no data */ - frame.colorimetry = HDMI_COLORIMETRY_ITU_601; - frame.extended_colorimetry = - HDMI_EXTENDED_COLORIMETRY_XV_YCC_601; - break; + HDMI_EXTENDED_COLORIMETRY_XV_YCC_601; } frame.scan_mode = HDMI_SCAN_MODE_NONE; -- 2.20.1

5 years, 1 month

1
18
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror March 2020