Re: [PATCH 1/2] platform_device: add devres function region-reqs

[kernel test robot]

Hi Philipp,

kernel test robot noticed the following build warnings:

[auto build test WARNING on drm-misc/drm-misc-next]
[also build test WARNING on driver-core/driver-core-testing 
driver-core/driver-core-next driver-core/driver-core-linus linus/master v6.7 
next-20240105]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]

url:
https://github.com/intel-lab-lkp/linux/commits/Philipp-Stanner/platform_device-add-devres-function-region-reqs/20240106-012526
base:   git://anongit.freedesktop.org/drm/drm-misc drm-misc-next
patch link:
https://lore.kernel.org/r/20240105172218.42457-3-pstanner%40redhat.com
patch subject: [PATCH 1/2] platform_device: add devres function region-reqs
config: x86_64-randconfig-101-20240106 
(https://download.01.org/0day-ci/archive/20240108/202401081547.vbj4fkaw-...@intel.com/config)
compiler: gcc-7 (Ubuntu 7.5.0-6ubuntu2) 7.5.0
reproduce (this is a W=1 build): 
(https://download.01.org/0day-ci/archive/20240108/202401081547.vbj4fkaw-...@intel.com/reproduce)

If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot 
| Closes: 
https://lore.kernel.org/oe-kbuild-all/202401081547.vbj4fkaw-...@intel.com/

All warnings (new ones prefixed by >>):

>> drivers/base/platform.c:101: warning: expecting prototype for 
>> devm_platform_get_and_resource(). Prototype was for 
>> devm_platform_get_resource() instead


vim +101 drivers/base/platform.c

84  
85  /**
86   * devm_platform_get_and_resource - get and request a resource
87   *
88   * @pdev: the platform device to get the resource from
89   * @type: resource type (either IORESOURCE_MEM or IORESOURCE_IO)
90   * @num: resource index
91   * @name: name to be associated with the request
92   *
93   * Return: a pointer to the resource on success, an ERR_PTR on failure.
94   *
95   * Gets a resource and requests it. Use this instead of
96   * devm_platform_ioremap_resource() only if you have to create several 
single
97   * mappings with devm_ioremap().
98   */
99  struct resource *devm_platform_get_resource(struct platform_device 
*pdev,
   100  unsigned int type, unsigned int num, const char *name)
 > 101  {
   102  struct resource *res;
   103  
   104  res = platform_get_resource(pdev, type, num);
   105  if (!res)
   106  return ERR_PTR(-EINVAL);
   107  
   108  if (type & IORESOURCE_MEM)
   109  res = devm_request_mem_region(>dev, res->start, 
res->end, name);
   110  else if (type & IORESOURCE_IO)
   111  res = devm_request_region(>dev, res->start, 
res->end, name);
   112  else
   113  return ERR_PTR(-EINVAL);
   114  
   115  if (!res)
   116  return ERR_PTR(-EBUSY);
   117  
   118  return res;
   119  }
   120  EXPORT_SYMBOL_GPL(devm_platform_get_resource);
   121  

-- 
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki

Re: [PATCH 1/1] Refactor radeon driver to use drm_gem_create_map_offset() instead of its custom implementation for associating GEM object with a fake offset. Since, we already have a generic implement

[Christian König]

Am 06.01.24 um 15:14 schrieb Dipam Turkar:

Signed-off-by: Dipam Turkar 
---
  drivers/gpu/drm/radeon/radeon_drv.c |  2 +-
  drivers/gpu/drm/radeon/radeon_gem.c | 24 ++--
  2 files changed, 3 insertions(+), 23 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon_drv.c 
b/drivers/gpu/drm/radeon/radeon_drv.c
index fa531493b111..f590ed65ffba 100644
--- a/drivers/gpu/drm/radeon/radeon_drv.c
+++ b/drivers/gpu/drm/radeon/radeon_drv.c
@@ -578,7 +578,7 @@ static const struct drm_driver kms_driver = {
.ioctls = radeon_ioctls_kms,
.num_ioctls = ARRAY_SIZE(radeon_ioctls_kms),
.dumb_create = radeon_mode_dumb_create,
-   .dumb_map_offset = radeon_mode_dumb_mmap,
+   .dumb_map_offset = drm_gem_dumb_map_offset,
.fops = _driver_kms_fops,
  
  	.gem_prime_import_sg_table = radeon_gem_prime_import_sg_table,

diff --git a/drivers/gpu/drm/radeon/radeon_gem.c 
b/drivers/gpu/drm/radeon/radeon_gem.c
index 358d19242f4b..99794c550d2c 100644
--- a/drivers/gpu/drm/radeon/radeon_gem.c
+++ b/drivers/gpu/drm/radeon/radeon_gem.c
@@ -31,6 +31,7 @@
  
  #include 

  #include 
+#include 
  #include 
  #include 
  
@@ -480,33 +481,12 @@ int radeon_gem_set_domain_ioctl(struct drm_device *dev, void *data,

return r;
  }
  
-int radeon_mode_dumb_mmap(struct drm_file *filp,

- struct drm_device *dev,
- uint32_t handle, uint64_t *offset_p)
-{
-   struct drm_gem_object *gobj;
-   struct radeon_bo *robj;
-
-   gobj = drm_gem_object_lookup(filp, handle);
-   if (gobj == NULL) {
-   return -ENOENT;
-   }
-   robj = gem_to_radeon_bo(gobj);
-   if (radeon_ttm_tt_has_userptr(robj->rdev, robj->tbo.ttm)) {


Well apart from the obvious typos, the missing commit message and the 
mangled subject line this also removes this important check for userptrs 
here.


This in turn is a complete no-go since it can lead to kernel crashes.

Regards,
Christian.


-   drm_gem_object_put(gobj);
-   return -EPERM;
-   }
-   *offset_p = radeon_bo_mmap_offset(robj);
-   drm_gem_object_put(gobj);
-   return 0;
-}
-
  int radeon_gem_mmap_ioctl(struct drm_device *dev, void *data,
  struct drm_file *filp)
  {
struct drm_radeon_gem_mmap *args = data;
  
-	return radeon_mode_dumb_mmap(filp, dev, args->handle, >addr_ptr);

+   return drm_gem_dumb_map_offset(filp, dev, args->handle, 
>addr_ptr);
  }
  
  int radeon_gem_busy_ioctl(struct drm_device *dev, void *data,

Re: [PATCH 0/4] KVM: Honor guest memory types for virtio GPU devices

[Yan Zhao]

On Fri, Jan 05, 2024 at 03:55:51PM -0400, Jason Gunthorpe wrote:
> On Fri, Jan 05, 2024 at 05:12:37PM +0800, Yan Zhao wrote:
> > This series allow user space to notify KVM of noncoherent DMA status so as
> > to let KVM honor guest memory types in specified memory slot ranges.
> > 
> > Motivation
> > ===
> > A virtio GPU device may want to configure GPU hardware to work in
> > noncoherent mode, i.e. some of its DMAs do not snoop CPU caches.
> 
> Does this mean some DMA reads do not snoop the caches or does it
> include DMA writes not synchronizing the caches too?
Both DMA reads and writes are not snooped.
The virtio host side will mmap the buffer to WC (pgprot_writecombine)
for CPU access and program the device to access the buffer in uncached
way.
Meanwhile, virtio host side will construct a memslot in KVM with the PTR
returned from the mmap, and notify virtio guest side to mmap the same buffer in
guest page table with PAT=WC, too.

> 
> > This is generally for performance consideration.
> > In certain platform, GFX performance can improve 20+% with DMAs going to
> > noncoherent path.
> > 
> > This noncoherent DMA mode works in below sequence:
> > 1. Host backend driver programs hardware not to snoop memory of target
> >DMA buffer.
> > 2. Host backend driver indicates guest frontend driver to program guest PAT
> >to WC for target DMA buffer.
> > 3. Guest frontend driver writes to the DMA buffer without clflush stuffs.
> > 4. Hardware does noncoherent DMA to the target buffer.
> > 
> > In this noncoherent DMA mode, both guest and hardware regard a DMA buffer
> > as not cached. So, if KVM forces the effective memory type of this DMA
> > buffer to be WB, hardware DMA may read incorrect data and cause misc
> > failures.
> 
> I don't know all the details, but a big concern would be that the
> caches remain fully coherent with the underlying memory at any point
> where kvm decides to revoke the page from the VM.
Ah, you mean, for page migration, the content of the page may not be copied
correctly, right?

Currently in x86, we have 2 ways to let KVM honor guest memory types:
1. through KVM memslot flag introduced in this series, for virtio GPUs, in
   memslot granularity.
2. through increasing noncoherent dma count, as what's done in VFIO, for
   Intel GPU passthrough, for all guest memory.

This page migration issue should not be the case for virtio GPU, as both host
and guest are synced to use the same memory type and actually the pages
are not anonymous pages.
For GPU pass-through, though host mmaps with WB, it's still fine for guest to
use WC because page migration on pages of VMs with pass-through device is not
allowed.

But I agree, this should be a case if user space sets the memslot flag to honor
guest memory type to memslots for guest system RAM where non-enlightened guest
components may cause guest and host to access with different memory types.
Or simply when the guest is a malicious one.

> If you allow an incoherence of cache != physical then it opens a
> security attack where the observed content of memory can change when
> it should not.

In this case, will this security attack impact other guests?

> 
> ARM64 has issues like this and due to that ARM has to have explict,
> expensive, cache flushing at certain points.
>

Re: [PATCH] drm/mediatek/dp: Add the HDCP feature for DisplayPort

[胡俊光]

Re: [PATCH 2/2] drm/sched: Return an error code only as a constant in drm_sched_init()

[Luben Tuikov]

On 2023-12-26 10:58, Markus Elfring wrote:
> From: Markus Elfring 
> Date: Tue, 26 Dec 2023 16:37:37 +0100
> 
> Return an error code without storing it in an intermediate variable.
> 
> Signed-off-by: Markus Elfring 

Thank you Markus for this patch.

Reviewed-by: Luben Tuikov 

Pushed to drm-misc-next.
-- 
Regards,
Luben

> ---
>  drivers/gpu/drm/scheduler/sched_main.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/scheduler/sched_main.c 
> b/drivers/gpu/drm/scheduler/sched_main.c
> index b99d4e9ff109..1abbcdf38430 100644
> --- a/drivers/gpu/drm/scheduler/sched_main.c
> +++ b/drivers/gpu/drm/scheduler/sched_main.c
> @@ -1249,7 +1249,7 @@ int drm_sched_init(struct drm_gpu_scheduler *sched,
>  long timeout, struct workqueue_struct *timeout_wq,
>  atomic_t *score, const char *name, struct device *dev)
>  {
> - int i, ret;
> + int i;
> 
>   sched->ops = ops;
>   sched->credit_limit = credit_limit;
> @@ -1285,7 +1285,7 @@ int drm_sched_init(struct drm_gpu_scheduler *sched,
> 
>   sched->own_submit_wq = true;
>   }
> - ret = -ENOMEM;
> +
>   sched->sched_rq = kmalloc_array(num_rqs, sizeof(*sched->sched_rq),
>   GFP_KERNEL | __GFP_ZERO);
>   if (!sched->sched_rq)
> @@ -1321,7 +1321,7 @@ int drm_sched_init(struct drm_gpu_scheduler *sched,
>   if (sched->own_submit_wq)
>   destroy_workqueue(sched->submit_wq);
>   drm_err(sched, "%s: Failed to setup GPU scheduler--out of memory\n", 
> __func__);
> - return ret;
> + return -ENOMEM;
>  }
>  EXPORT_SYMBOL(drm_sched_init);
> 
> --
> 2.43.0
> 


OpenPGP_0x4C15479431A334AF.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: [PATCH 1/2] drm/sched: One function call less in drm_sched_init() after error detection

[Luben Tuikov]

On 2023-12-26 10:56, Markus Elfring wrote:
> From: Markus Elfring 
> Date: Tue, 26 Dec 2023 16:30:25 +0100
> 
> The kfree() function was called in one case by the
> drm_sched_init() function during error handling
> even if the passed data structure member contained a null pointer.
> This issue was detected by using the Coccinelle software.
> 
> Thus adjust a jump target.
> 
> Signed-off-by: Markus Elfring 

Thank you Markus for this patch.

Reviewed-by: Luben Tuikov 

Pushed to drm-misc-next.
-- 
Regards,
Luben

> ---
>  drivers/gpu/drm/scheduler/sched_main.c | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/scheduler/sched_main.c 
> b/drivers/gpu/drm/scheduler/sched_main.c
> index 550492a7a031..b99d4e9ff109 100644
> --- a/drivers/gpu/drm/scheduler/sched_main.c
> +++ b/drivers/gpu/drm/scheduler/sched_main.c
> @@ -1289,7 +1289,7 @@ int drm_sched_init(struct drm_gpu_scheduler *sched,
>   sched->sched_rq = kmalloc_array(num_rqs, sizeof(*sched->sched_rq),
>   GFP_KERNEL | __GFP_ZERO);
>   if (!sched->sched_rq)
> - goto Out_free;
> + goto Out_check_own;
>   sched->num_rqs = num_rqs;
>   for (i = DRM_SCHED_PRIORITY_KERNEL; i < sched->num_rqs; i++) {
>   sched->sched_rq[i] = kzalloc(sizeof(*sched->sched_rq[i]), 
> GFP_KERNEL);
> @@ -1314,9 +1314,10 @@ int drm_sched_init(struct drm_gpu_scheduler *sched,
>  Out_unroll:
>   for (--i ; i >= DRM_SCHED_PRIORITY_KERNEL; i--)
>   kfree(sched->sched_rq[i]);
> -Out_free:
> +
>   kfree(sched->sched_rq);
>   sched->sched_rq = NULL;
> +Out_check_own:
>   if (sched->own_submit_wq)
>   destroy_workqueue(sched->submit_wq);
>   drm_err(sched, "%s: Failed to setup GPU scheduler--out of memory\n", 
> __func__);
> --
> 2.43.0
> 


OpenPGP_0x4C15479431A334AF.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: [bug report] drm/amdgpu/vpe: enable vpe dpm

[SHANMUGAM, SRINIVASAN]

[Public]

+ Srinath, Tim

Get Outlook for Android

From: SHANMUGAM, SRINIVASAN
Sent: Saturday, January 6, 2024 10:06:33 AM
To: Dan Carpenter ; Lee, Peyton 
Cc: dri-devel@lists.freedesktop.org ; 
amd-...@lists.freedesktop.org 
Subject: RE: [bug report] drm/amdgpu/vpe: enable vpe dpm

Hi Dan Carpenter,

This was fixed in 
https://patchwork.freedesktop.org/patch/573477/?series=128249=1

Thank you!

Regards,
Srini

-Original Message-
From: amd-gfx  On Behalf Of Dan Carpenter
Sent: Friday, January 5, 2024 7:04 PM
To: Lee, Peyton 
Cc: dri-devel@lists.freedesktop.org; amd-...@lists.freedesktop.org
Subject: [bug report] drm/amdgpu/vpe: enable vpe dpm

Hello Peyton Lee,

The patch 5f82a0c90cca: "drm/amdgpu/vpe: enable vpe dpm" from Dec 12,
2023 (linux-next), leads to the following Smatch static checker
warning:

drivers/gpu/drm/amd/amdgpu/amdgpu_vpe.c:62 vpe_u1_8_from_fraction() warn: 
unsigned 'numerator' is never less than zero.
drivers/gpu/drm/amd/amdgpu/amdgpu_vpe.c:63 vpe_u1_8_from_fraction() warn: 
unsigned 'denominator' is never less than zero.

drivers/gpu/drm/amd/amdgpu/amdgpu_vpe.c
60 static uint16_t vpe_u1_8_from_fraction(uint16_t numerator, uint16_t 
denominator)
61 {
--> 62 bool arg1_negative = numerator < 0;
63 bool arg2_negative = denominator < 0;

uint16_t can't be negative.

64
65 uint16_t arg1_value = (uint16_t)(arg1_negative ? -numerator : 
numerator);
66 uint16_t arg2_value = (uint16_t)(arg2_negative ? -denominator : 
denominator);
67
68 uint16_t remainder;
69

regards,
dan carpenter

RE: [PATCH] drm/amd/display: Fix assignment of integer to fixed point pbn_div

[Lin, Wayne]

[Public]

Thanks, Imre Deak!

Reviewed-by: Wayne Lin 

> -Original Message-
> From: Imre Deak 
> Sent: Friday, January 5, 2024 5:56 PM
> To: dri-devel@lists.freedesktop.org
> Cc: Lin, Wayne ; amd-...@lists.freedesktop.org; Dave
> Airlie 
> Subject: [PATCH] drm/amd/display: Fix assignment of integer to fixed point
> pbn_div
>
> Fix the merge conflict resolution in
>
> commit 13feae00ee99e0fc8b6f1748fc4c70281a7d6939
> Merge: eb284f4b37817 3c064aea46d07
> Author: Dave Airlie 
> Date:   Fri Jan 5 13:19:40 2024 +1000
>
> Merge remote-tracking branch 'drm/drm-next' into drm-tip
>
> # Conflicts:
> #   drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> #   drivers/gpu/drm/i915/display/intel_dmc.c
>
> @@@ -6916,7 -7007,8 +7009,7 @@@ static int
> dm_encoder_helper_atomic_che
> if (IS_ERR(mst_state))
> return PTR_ERR(mst_state);
>
>  -  if (!mst_state->pbn_div.full)
>  -  mst_state->pbn_div.full =
> dfixed_const(dm_mst_get_pbn_divider(aconnector->mst_root->dc_link));
>  +  mst_state->pbn_div = dm_mst_get_pbn_divider(aconnector->mst_root-
> >dc_link);
>
> resulting from the following two changes:
>
> commit 191dc43935d1ece82bc6c9653463b3b1cd8198fb
> Author: Imre Deak 
> Date:   Thu Nov 16 15:18:31 2023 +0200
>
> drm/dp_mst: Store the MST PBN divider value in fixed point format
>
> commit 9cdef4f720376ef0fb0febce1ed2377c19e531f9
> Author: Wayne Lin 
> Date:   Mon Dec 4 10:09:33 2023 +0800
>
> drm/amd/display: pbn_div need be updated for hotplug event
>
> Cc: Wayne Lin 
> Cc: amd-...@lists.freedesktop.org
> Cc: dri-devel@lists.freedesktop.org
> Cc: Dave Airlie 
> Signed-off-by: Imre Deak 
> ---
>  drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> index 5d82bac1a51ab..f9714dd6fe8ed 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> @@ -7009,7 +7009,7 @@ static int dm_encoder_helper_atomic_check(struct
> drm_encoder *encoder,
>   if (IS_ERR(mst_state))
>   return PTR_ERR(mst_state);
>
> - mst_state->pbn_div = dm_mst_get_pbn_divider(aconnector-
> >mst_root->dc_link);
> + mst_state->pbn_div.full =
> dfixed_const(dm_mst_get_pbn_divider(aconnector->mst_root->dc_link));
>
>   if (!state->duplicated) {
>   int max_bpc = conn_state->max_requested_bpc;
> --
> 2.39.2

linux-next: manual merge of the drm tree with Linus' tree

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the drm tree got a conflict in:

  drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c

between commit:

  9cdef4f72037 ("drm/amd/display: pbn_div need be updated for hotplug event")

from Linus' tree and commit:

  191dc43935d1 ("drm/dp_mst: Store the MST PBN divider value in fixed point 
format")

from the drm tree.

I fixed it up (I think, see below) and can carry the fix as
necessary. This is now fixed as far as linux-next is concerned, but any
non trivial conflicts should be mentioned to your upstream maintainer
when your tree is submitted for merging.  You may also want to consider
cooperating with the maintainer of the conflicting tree to minimise any
particularly complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index 73dd4bc870dc,54861136dafd..
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@@ -6916,7 -7007,8 +7009,7 @@@ static int dm_encoder_helper_atomic_che
if (IS_ERR(mst_state))
return PTR_ERR(mst_state);
  
-   mst_state->pbn_div = 
dm_mst_get_pbn_divider(aconnector->mst_root->dc_link);
 -  if (!mst_state->pbn_div.full)
 -  mst_state->pbn_div.full = 
dfixed_const(dm_mst_get_pbn_divider(aconnector->mst_root->dc_link));
++  mst_state->pbn_div.full = 
dfixed_const(dm_mst_get_pbn_divider(aconnector->mst_root->dc_link));
  
if (!state->duplicated) {
int max_bpc = conn_state->max_requested_bpc;


pgp9lNCMbLHEz.pgp
Description: OpenPGP digital signature

Re: [PATCH v4 8/8] drm/panel: nt35510: support FRIDA FRD400B25025-A-CTK

[Linus Walleij]

On Sat, Jan 6, 2024 at 12:07 PM Dario Binacchi
 wrote:

> After submitting v4, I tested the driver under different conditions,
> i. e. without enabling display support in
> U-Boot (I also implemented a version for U-Boot, which I will send
> only after this series is merged into
> the Linux kernel). In that condition I encountered an issue with the reset 
> pin.
>
> The minimal fix, would be this:
>
> diff --git a/drivers/gpu/drm/panel/panel-novatek-nt35510.c
> b/drivers/gpu/drm/panel/panel-novatek-nt35510.c
> index c85dd0d0829d..89ba99763468 100644
> --- a/drivers/gpu/drm/panel/panel-novatek-nt35510.c
> +++ b/drivers/gpu/drm/panel/panel-novatek-nt35510.c
> @@ -1133,7 +1133,7 @@ static int nt35510_probe(struct mipi_dsi_device *dsi)
> if (ret)
> return ret;
>
> -   nt->reset_gpio = devm_gpiod_get_optional(dev, "reset", GPIOD_ASIS);
> +   nt->reset_gpio = devm_gpiod_get_optional(dev, "reset", 
> GPIOD_OUT_HIGH);


This is fine, because we later on toggle reset in nt35510_power_on(),
this just asserts the reset signal already in probe.

I don't see why this would make a difference though?

Is it to make the reset delete artifacts from the screen?

Just explain it in the commit message.

It is a bit confusing when I look at your DTS patch:

https://lore.kernel.org/linux-arm-kernel/20240104084206.721824-7-dario.binac...@amarulasolutions.com/

this doesn't even contain a reset GPIO, so nothing will happen
at all?

> I then tried modifying the device tree instead of the nt35510 driver.
> In the end, I arrived
> at this patch that leaves me with some doubts, especially regarding
> the strict option.
>
> diff --git 
> a/arch/arm/boot/dts/st/stm32f769-disco-mb1225-revb03-mb1166-reva09.dts
> b/arch/arm/boot/dts/st/stm32f769-disco-mb1225-revb03-m>
> index 014cac192375..32ed420a6cbf 100644
> --- a/arch/arm/boot/dts/st/stm32f769-disco-mb1225-revb03-mb1166-reva09.dts
> +++ b/arch/arm/boot/dts/st/stm32f769-disco-mb1225-revb03-mb1166-reva09.dts
> @@ -13,6 +13,17 @@  {
> compatible = "frida,frd400b25025", "novatek,nt35510";
> vddi-supply = <_3v3>;
> vdd-supply = <_3v3>;
> +   pinctrl-0 = <_reset>;
> +   pinctrl-names = "default";
> /delete-property/backlight;
> /delete-property/power-supply;
>  };
> +
> + {
> +   panel_reset: panel-reset {
> +   pins1 {
> +   pinmux = ;
> +   output-high;

But this achieves the *opposite* of what you do in the
other patch. This sets the reset line de-asserted since it is
active low.

Did you add the reset line to your device tree and forgot to
set it as GPIO_ACTIVE_LOW perhaps?

> --- a/drivers/pinctrl/stm32/pinctrl-stm32.c
> +++ b/drivers/pinctrl/stm32/pinctrl-stm32.c
> @@ -895,7 +895,6 @@ static const struct pinmux_ops stm32_pmx_ops = {
> .set_mux= stm32_pmx_set_mux,
> .gpio_set_direction = stm32_pmx_gpio_set_direction,
> .request= stm32_pmx_request,
> -   .strict = true,

To be honest this is what I use a lot of the time, with non-strict
pin control you can set up default GPIO values using the pin control
device tree, and it's really simple and easy to read like that since e.g.
in this case you set it from the panel device node which is what
is also consuming the GPIO, so very logical. So I
would certainly remove this .strict setting, but maybe Alexandre
et al have a strong opinion about it.

> Another option to fix my use case without introducing regressions
> could be to add a
> new property to the device tree that suggests whether to call
> devm_gpiod_get_optional()
> with the GPIOD_ASIS or GPIOD_OUT_HIGH parameter.
>
> What is your opinion?

It's fine either way, but just use GPIOD_OUT_HIGH and I can test
it on my system as well, I think it's fine.

Yours,
Linus Walleij

Re: [PATCH 1/1] Refactor radeon driver to use drm_gem_create_map_offset() instead of its custom implementation for associating GEM object with a fake offset. Since, we already have a generic implement

[kernel test robot]

Hi Dipam,

kernel test robot noticed the following build errors:

[auto build test ERROR on drm-misc/drm-misc-next]
[also build test ERROR on linus/master v6.7-rc8 next-20240105]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]

url:
https://github.com/intel-lab-lkp/linux/commits/Dipam-Turkar/Refactor-radeon-driver-to-use-drm_gem_create_map_offset-instead-of-its-custom-implementation-for-associating-GEM-object-/20240106-221755
base:   git://anongit.freedesktop.org/drm/drm-misc drm-misc-next
patch link:
https://lore.kernel.org/r/20240106141422.10734-1-dipamt1729%40gmail.com
patch subject: [PATCH 1/1] Refactor radeon driver to use 
drm_gem_create_map_offset() instead of its custom implementation for 
associating GEM object with a fake offset. Since, we already have a generic 
implementation, we don't need the custom function and it is better to 
standardize the code.
config: x86_64-allmodconfig 
(https://download.01.org/0day-ci/archive/20240108/202401080333.6psotuik-...@intel.com/config)
compiler: ClangBuiltLinux clang version 17.0.6 
(https://github.com/llvm/llvm-project 6009708b4367171ccdbf4b5905cb6a803753fe18)
reproduce (this is a W=1 build): 
(https://download.01.org/0day-ci/archive/20240108/202401080333.6psotuik-...@intel.com/reproduce)

If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot 
| Closes: 
https://lore.kernel.org/oe-kbuild-all/202401080333.6psotuik-...@intel.com/

All errors (new ones prefixed by >>):

>> drivers/gpu/drm/radeon/radeon_gem.c:34:10: fatal error: 'drm/dem_gem.h' file 
>> not found
  34 | #include 
 |  ^~~
   1 error generated.


vim +34 drivers/gpu/drm/radeon/radeon_gem.c

31  
32  #include 
33  #include 
  > 34  #include 
35  #include 
36  #include 
37  

-- 
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki

Re: [PATCH 1/1] Refactor radeon driver to use drm_gem_create_map_offset() instead of its custom implementation for associating GEM object with a fake offset. Since, we already have a generic implement

[kernel test robot]

Hi Dipam,

kernel test robot noticed the following build errors:

[auto build test ERROR on drm-misc/drm-misc-next]
[also build test ERROR on linus/master v6.7-rc8 next-20240105]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]

url:
https://github.com/intel-lab-lkp/linux/commits/Dipam-Turkar/Refactor-radeon-driver-to-use-drm_gem_create_map_offset-instead-of-its-custom-implementation-for-associating-GEM-object-/20240106-221755
base:   git://anongit.freedesktop.org/drm/drm-misc drm-misc-next
patch link:
https://lore.kernel.org/r/20240106141422.10734-1-dipamt1729%40gmail.com
patch subject: [PATCH 1/1] Refactor radeon driver to use 
drm_gem_create_map_offset() instead of its custom implementation for 
associating GEM object with a fake offset. Since, we already have a generic 
implementation, we don't need the custom function and it is better to 
standardize the code.
config: s390-allmodconfig 
(https://download.01.org/0day-ci/archive/20240108/202401080151.jsivh6p0-...@intel.com/config)
compiler: s390-linux-gcc (GCC) 13.2.0
reproduce (this is a W=1 build): 
(https://download.01.org/0day-ci/archive/20240108/202401080151.jsivh6p0-...@intel.com/reproduce)

If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot 
| Closes: 
https://lore.kernel.org/oe-kbuild-all/202401080151.jsivh6p0-...@intel.com/

All errors (new ones prefixed by >>):

>> drivers/gpu/drm/radeon/radeon_gem.c:34:10: fatal error: drm/dem_gem.h: No 
>> such file or directory
  34 | #include 
 |  ^~~
   compilation terminated.


vim +34 drivers/gpu/drm/radeon/radeon_gem.c

31  
32  #include 
33  #include 
  > 34  #include 
35  #include 
36  #include 
37  

-- 
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki

[PATCH v2] drm/amdkfd: fixes for HMM mem allocation

[Dafna Hirschfeld]

Fix err return value and reset pgmap->type after checking it.

Fixes: c83dee9b6394 ("drm/amdkfd: add SPM support for SVM")
Reviewed-by: Felix Kuehling 
Signed-off-by: Dafna Hirschfeld 
---
v2: remove unrelated DOC fix and add 'Fixes' tag.

 drivers/gpu/drm/amd/amdkfd/kfd_migrate.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_migrate.c 
b/drivers/gpu/drm/amd/amdkfd/kfd_migrate.c
index 6c25dab051d5..b8680e0753ca 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_migrate.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_migrate.c
@@ -1021,7 +1021,7 @@ int kgd2kfd_init_zone_device(struct amdgpu_device *adev)
} else {
res = devm_request_free_mem_region(adev->dev, _resource, 
size);
if (IS_ERR(res))
-   return -ENOMEM;
+   return PTR_ERR(res);
pgmap->range.start = res->start;
pgmap->range.end = res->end;
pgmap->type = MEMORY_DEVICE_PRIVATE;
@@ -1037,10 +1037,10 @@ int kgd2kfd_init_zone_device(struct amdgpu_device *adev)
r = devm_memremap_pages(adev->dev, pgmap);
if (IS_ERR(r)) {
pr_err("failed to register HMM device memory\n");
-   /* Disable SVM support capability */
-   pgmap->type = 0;
if (pgmap->type == MEMORY_DEVICE_PRIVATE)
devm_release_mem_region(adev->dev, res->start, 
resource_size(res));
+   /* Disable SVM support capability */
+   pgmap->type = 0;
return PTR_ERR(r);
}
 
-- 
2.34.1

Re: [PATCH 1/3] dt-bindings: display: panel: Add Himax HX83112A

[Krzysztof Kozlowski]

On 05/01/2024 15:29, Luca Weiss wrote:
> Himax HX83112A is a display driver IC used to drive LCD DSI panels.
> Describe it.
> 
> Signed-off-by: Luca Weiss 
> ---
>  .../bindings/display/panel/himax,hx83112a.yaml | 75 
> ++
>  1 file changed, 75 insertions(+)
> 

Reviewed-by: Krzysztof Kozlowski 

Best regards,
Krzysztof

Re: [PATCH V2 1/2] dt-bindings: phy: add binding for the i.MX8MP HDMI PHY

[Krzysztof Kozlowski]

On 06/01/2024 23:19, Adam Ford wrote:
> From: Lucas Stach 
> 
> Add a DT binding for the HDMI PHY found on the i.MX8MP SoC.
> 
> Signed-off-by: Lucas Stach 


> +
> +  reg:
> +maxItems: 1
> +
> +  "#clock-cells":
> +const: 0
> +
> +  clocks:
> +minItems: 2

If there is going to be new version/resend:

drop, maxItems is enough

Anyway:

Reviewed-by: Krzysztof Kozlowski 


> +maxItems: 2
> +


Best regards,
Krzysztof