[RESEND PATCHv2 1/2] drm: Add SDP Error Detection Configuration Register
DP2.0 E11 defines a new register to facilitate SDP error detection by a 128B/132B capable DPRX device. v2: Update the macro name to reflect the DP spec(Harry) Signed-off-by: Arun R Murthy Reviewed-by: Harry Wentland --- include/drm/display/drm_dp.h | 3 +++ 1 file changed, 3 insertions(+) diff --git a/include/drm/display/drm_dp.h b/include/drm/display/drm_dp.h index 632376c291db..358db4a9f167 100644 --- a/include/drm/display/drm_dp.h +++ b/include/drm/display/drm_dp.h @@ -692,6 +692,9 @@ # define DP_FEC_LANE_2_SELECT (2 << 4) # define DP_FEC_LANE_3_SELECT (3 << 4) +#define DP_SDP_ERROR_DETECTION_CONFIGURATION 0x121 /* DP 2.0 E11 */ +#define DP_SDP_CRC16_128B132B_EN BIT(0) + #define DP_AUX_FRAME_SYNC_VALUE0x15c /* eDP 1.4 */ # define DP_AUX_FRAME_SYNC_VALID (1 << 0) -- 2.25.1
[PATCHv3 0/2] DP2.0 SDP CRC16 for 128/132b link layer
*** BLURB HERE *** Arun R Murthy (2): drm: Add SDP Error Detection Configuration Register i915/display/dp: SDP CRC16 for 128b132b link layer .../gpu/drm/i915/display/intel_dp_link_training.c| 12 include/drm/display/drm_dp.h | 3 +++ 2 files changed, 15 insertions(+) -- 2.25.1
Re: [PATCH] drm/edid: fix info leak when failing to get panel id
On Thu, 02 Mar 2023, Johan Hovold wrote:
> Make sure to clear the transfer buffer before fetching the EDID to
> avoid leaking slab data to the logs on errors that leave the buffer
> unchanged.
>
> Fixes: 69c7717c20cc ("drm/edid: Dump the EDID when drm_edid_get_panel_id()
> has an error")
> Cc: sta...@vger.kernel.org# 6.2
> Cc: Douglas Anderson
> Signed-off-by: Johan Hovold
Reviewed-by: Jani Nikula
> ---
> drivers/gpu/drm/drm_edid.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index 3841aba17abd..8707fe72a028 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -2797,7 +2797,7 @@ u32 drm_edid_get_panel_id(struct i2c_adapter *adapter)
>* the EDID then we'll just return 0.
>*/
>
> - base_block = kmalloc(EDID_LENGTH, GFP_KERNEL);
> + base_block = kzalloc(EDID_LENGTH, GFP_KERNEL);
> if (!base_block)
> return 0;
--
Jani Nikula, Intel Open Source Graphics Center
[PATCH 0/2] drm/nouveau: avoid usage of list iterator after loop
This patch set includes two instances where the list iterator variable 'pstate' is implicitly assumed to be valid after the iterator loop. While in pratice that is most likely the case (if 'pstatei'/'args->v0.state' is <= the elements in clk->states), we should explicitly only allow 'pstate' to always point to correct 'nvkm_pstate' structs. That allows catching potential bugs with BUG_ON(!pstate) that otherwise would be completely undetectable. It also helps the greater mission to hopefully move the list iterator variable into the iterating macro directly [1]. Link: https://lore.kernel.org/all/CAHk-=wgRr_D8CB-D9Kg-c=ehreask5sqxpwr9y7k9sa6cwx...@mail.gmail.com/ [1] Signed-off-by: Jakob Koschel --- Jakob Koschel (2): drm/nouveau/device: avoid usage of list iterator after loop drm/nouveau/clk: avoid usage of list iterator after loop drivers/gpu/drm/nouveau/nvkm/engine/device/ctrl.c | 9 ++--- drivers/gpu/drm/nouveau/nvkm/subdev/clk/base.c| 9 ++--- 2 files changed, 12 insertions(+), 6 deletions(-) --- base-commit: c0927a7a5391f7d8e593e5e50ead7505a23cadf9 change-id: 20230301-drm-nouveau-avoid-iter-after-loop-4bff97166efa Best regards, -- Jakob Koschel
Re: [PATCH] drm/mediatek: dsi: fix error codes in mtk_dsi_host_transfer()
Dear Dan,
Thank you for your patch.
On lun., févr. 27, 2023 at 13:08, Dan Carpenter wrote:
> There is a type bug because the return statement:
>
> return ret < 0 ? ret : recv_cnt;
>
> will not return negatives on 64bit systems. The problem is that the
> function returns ssize_t types, while "ret" is int and "recv_cnt" is a
> u32. The negative values are type promoted to u32 and returned as
> positive values instead of negative error codes.
>
> Fixes: 81cc7e51c4f1 ("drm/mediatek: Allow commands to be sent during video
> mode")
> Signed-off-by: Dan Carpenter
Reviewed-by: Mattijs Korpershoek
> ---
> drivers/gpu/drm/mediatek/mtk_dsi.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c
> b/drivers/gpu/drm/mediatek/mtk_dsi.c
> index 7d5250351193..8e99981ca0e1 100644
> --- a/drivers/gpu/drm/mediatek/mtk_dsi.c
> +++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
> @@ -1016,12 +1016,12 @@ static ssize_t mtk_dsi_host_transfer(struct
> mipi_dsi_host *host,
>const struct mipi_dsi_msg *msg)
> {
> struct mtk_dsi *dsi = host_to_dsi(host);
> - u32 recv_cnt, i;
> + ssize_t recv_cnt;
> u8 read_data[16];
> void *src_addr;
> u8 irq_flag = CMD_DONE_INT_FLAG;
> u32 dsi_mode;
> - int ret;
> + int ret, i;
>
> dsi_mode = readl(dsi->regs + DSI_MODE_CTRL);
> if (dsi_mode & MODE) {
> @@ -1070,7 +1070,7 @@ static ssize_t mtk_dsi_host_transfer(struct
> mipi_dsi_host *host,
> if (recv_cnt)
> memcpy(msg->rx_buf, src_addr, recv_cnt);
>
> - DRM_INFO("dsi get %d byte data from the panel address(0x%x)\n",
> + DRM_INFO("dsi get %zd byte data from the panel address(0x%x)\n",
>recv_cnt, *((u8 *)(msg->tx_buf)));
>
> restore_dsi_mode:
> --
> 2.39.1
[PATCH 1/2] drm/nouveau/device: avoid usage of list iterator after loop
If potentially no valid element is found, 'pstate' would contain an
invalid pointer past the iterator loop. To ensure 'pstate' is always
valid, we only set it if the correct element was found. That allows
adding a BUG_ON in case the code works incorrectly, exposing currently
undetectable potential bugs.
Additionally, Linus proposed to avoid any use of the list iterator
variable after the loop, in the attempt to move the list iterator
variable declaration into the marcro to avoid any potential misuse after
the loop [1].
Link:
https://lore.kernel.org/all/CAHk-=wgRr_D8CB-D9Kg-c=ehreask5sqxpwr9y7k9sa6cwx...@mail.gmail.com/
[1]
Signed-off-by: Jakob Koschel
---
drivers/gpu/drm/nouveau/nvkm/engine/device/ctrl.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/device/ctrl.c
b/drivers/gpu/drm/nouveau/nvkm/engine/device/ctrl.c
index ce774579c89d..7c9dd91e98ee 100644
--- a/drivers/gpu/drm/nouveau/nvkm/engine/device/ctrl.c
+++ b/drivers/gpu/drm/nouveau/nvkm/engine/device/ctrl.c
@@ -72,7 +72,7 @@ nvkm_control_mthd_pstate_attr(struct nvkm_control *ctrl, void
*data, u32 size)
} *args = data;
struct nvkm_clk *clk = ctrl->device->clk;
const struct nvkm_domain *domain;
- struct nvkm_pstate *pstate;
+ struct nvkm_pstate *pstate = NULL, *iter;
struct nvkm_cstate *cstate;
int i = 0, j = -1;
u32 lo, hi;
@@ -103,11 +103,14 @@ nvkm_control_mthd_pstate_attr(struct nvkm_control *ctrl,
void *data, u32 size)
return -EINVAL;
if (args->v0.state != NVIF_CONTROL_PSTATE_ATTR_V0_STATE_CURRENT) {
- list_for_each_entry(pstate, &clk->states, head) {
- if (i++ == args->v0.state)
+ list_for_each_entry(iter, &clk->states, head) {
+ if (i++ == args->v0.state) {
+ pstate = iter;
break;
+ }
}
+ BUG_ON(!pstate);
lo = pstate->base.domain[domain->name];
hi = lo;
list_for_each_entry(cstate, &pstate->list, head) {
--
2.34.1
Re: [PATCH] dt-bindings: Fix SPI and I2C bus node names in examples
On Tue, 28 Feb 2023 at 14:54, Rob Herring wrote:
>
> SPI and I2C bus node names are expected to be "spi" or "i2c",
> respectively, with nothing else, a unit-address, or a '-N' index. A
> pattern of 'spi0' or 'i2c0' or similar has crept in. Fix all these
> cases. Mostly scripted with the following commands:
>
> git grep -l '\si2c[0-9] {' Documentation/devicetree/ | xargs sed -i -e
> 's/i2c[0-9] {/i2c {/'
> git grep -l '\sspi[0-9] {' Documentation/devicetree/ | xargs sed -i -e
> 's/spi[0-9] {/spi {/'
>
> With this, a few errors in examples were exposed and fixed.
>
> Signed-off-by: Rob Herring
> ---
> Cc: Miguel Ojeda
> Cc: Krzysztof Kozlowski
> Cc: Benson Leung
> Cc: Guenter Roeck
> Cc: Stephen Boyd
> Cc: Andrzej Hajda
> Cc: Neil Armstrong
> Cc: Robert Foss
> Cc: Thierry Reding
> Cc: Sam Ravnborg
> Cc: MyungJoo Ham
> Cc: Chanwoo Choi
> Cc: Linus Walleij
> Cc: Bartosz Golaszewski
> Cc: Pavel Machek
> Cc: Lee Jones
> Cc: Mauro Carvalho Chehab
> Cc: "David S. Miller"
> Cc: Eric Dumazet
> Cc: Jakub Kicinski
> Cc: Paolo Abeni
> Cc: Wolfgang Grandegger
> Cc: Kalle Valo
> Cc: Sebastian Reichel
> Cc: Mark Brown
> Cc: Greg Kroah-Hartman
> Cc: linux-...@vger.kernel.org
> Cc: dri-devel@lists.freedesktop.org
> Cc: linux-g...@vger.kernel.org
> Cc: linux-...@vger.kernel.org
> Cc: linux-l...@vger.kernel.org
> Cc: linux-me...@vger.kernel.org
> Cc: net...@vger.kernel.org
> Cc: linux-...@vger.kernel.org
> Cc: linux-wirel...@vger.kernel.org
> Cc: linux...@vger.kernel.org
> Cc: alsa-de...@alsa-project.org
> Cc: linux-...@vger.kernel.org
> ---
Reviewed-by: Simon Glass
[PATCH 2/2] drm/nouveau/clk: avoid usage of list iterator after loop
If potentially no valid element is found, 'pstate' would contain an
invalid pointer past the iterator loop. To ensure 'pstate' is always
valid, we only set it if the correct element was found. That allows
adding a BUG_ON in case the code works incorrectly, exposing currently
undetectable potential bugs.
Additionally, Linus proposed to avoid any use of the list iterator
variable after the loop, in the attempt to move the list iterator
variable declaration into the marcro to avoid any potential misuse after
the loop [1].
Link:
https://lore.kernel.org/all/CAHk-=wgRr_D8CB-D9Kg-c=ehreask5sqxpwr9y7k9sa6cwx...@mail.gmail.com/
[1]
Signed-off-by: Jakob Koschel
---
drivers/gpu/drm/nouveau/nvkm/subdev/clk/base.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/clk/base.c
b/drivers/gpu/drm/nouveau/nvkm/subdev/clk/base.c
index da07a2fbef06..871127dfe1d7 100644
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/clk/base.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/clk/base.c
@@ -269,14 +269,17 @@ nvkm_pstate_prog(struct nvkm_clk *clk, int pstatei)
struct nvkm_subdev *subdev = &clk->subdev;
struct nvkm_fb *fb = subdev->device->fb;
struct nvkm_pci *pci = subdev->device->pci;
- struct nvkm_pstate *pstate;
+ struct nvkm_pstate *pstate = NULL, *iter;
int ret, idx = 0;
- list_for_each_entry(pstate, &clk->states, head) {
- if (idx++ == pstatei)
+ list_for_each_entry(iter, &clk->states, head) {
+ if (idx++ == pstatei) {
+ pstate = iter;
break;
+ }
}
+ BUG_ON(!pstate);
nvkm_debug(subdev, "setting performance state %d\n", pstatei);
clk->pstate = pstatei;
--
2.34.1
Re: [PATCH] drm/vram-helper: turn on PRIME import/export
Hi Am 01.03.23 um 23:29 schrieb Simon Ser: We don't populate gem_prime_import_sg_table so only DMA-BUFs exported from our own device can be imported. Still, this is useful to user-space. VRAM helpers don't really offer much flexibility or control in where to place a BO. What happens if the BO is located in device video ram and cannot be used by the other participant? A blank screen? I'd also consider VRAM helpers as deprecated. The remaining few drivers can be converted to SHMEM helpers; except maybe bochs could get its own TTM-based memory management. Best regards Thomas Signed-off-by: Simon Ser Cc: Daniel Vetter Cc: Thomas Zimmermann Cc: Tian Tao Cc: Maxime Ripard Cc: Christian König Cc: Hans de Goede --- include/drm/drm_gem_vram_helper.h | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/include/drm/drm_gem_vram_helper.h b/include/drm/drm_gem_vram_helper.h index d3e8920c0b64..f4aab64411d8 100644 --- a/include/drm/drm_gem_vram_helper.h +++ b/include/drm/drm_gem_vram_helper.h @@ -160,7 +160,9 @@ void drm_gem_vram_simple_display_pipe_cleanup_fb( .debugfs_init = drm_vram_mm_debugfs_init, \ .dumb_create = drm_gem_vram_driver_dumb_create, \ .dumb_map_offset = drm_gem_ttm_dumb_map_offset, \ - .gem_prime_mmap = drm_gem_prime_mmap + .gem_prime_mmap = drm_gem_prime_mmap, \ + .prime_handle_to_fd = drm_gem_prime_handle_to_fd, \ + .prime_fd_to_handle = drm_gem_prime_fd_to_handle /* * VRAM memory manager -- Thomas Zimmermann Graphics Driver Developer SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 Nürnberg, Germany (HRB 36809, AG Nürnberg) Geschäftsführer: Ivo Totev OpenPGP_signature Description: OpenPGP digital signature
