Am 30.04.24 um 19:38 schrieb Easwar Hariharan:
I2C v7, SMBus 3.2, and I3C 1.1.1 specifications have replaced "master/slave"
with more appropriate terms. Inspired by and following on to Wolfram's
series to fix drivers/i2c/[1], fix the terminology for users of
I2C_ALGOBIT bitbanging interface,
Am 30.04.24 um 19:38 schrieb Easwar Hariharan:
I2C v7, SMBus 3.2, and I3C 1.1.1 specifications have replaced "master/slave"
with more appropriate terms. Inspired by and following on to Wolfram's
series to fix drivers/i2c/[1], fix the terminology for users of
I2C_ALGOBIT bitbanging interface,
== Series Details ==
Series: drm/i915/hdcp: Disable HDCP Line Rekeying for HDCP2.2 on HDMI (rev5)
URL : https://patchwork.freedesktop.org/series/132479/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_14689 -> Patchwork_132479v5
Am 30.04.24 um 19:38 schrieb Easwar Hariharan:
I2C v7, SMBus 3.2, and I3C 1.1.1 specifications have replaced "master/slave"
with more appropriate terms. Inspired by and following on to Wolfram's
series to fix drivers/i2c/[1], fix the terminology for users of
I2C_ALGOBIT bitbanging interface,
On Tue, 30 Apr 2024, Rodrigo Vivi wrote:
> On Tue, Apr 30, 2024 at 01:09:59PM +0300, Jani Nikula wrote:
>> Avoid the implicit dev_priv local variable use, and pass dev_priv
>> explicitly to the EDP_PSR_AUX_CTL register macro.
>>
>> Signed-off-by: Jani Nikula
>
> Two things crossing my mind at
== Series Details ==
Series: drm/i915/psr: implicit dev_priv removal (rev2)
URL : https://patchwork.freedesktop.org/series/133062/
State : warning
== Summary ==
Error: dim checkpatch failed
9f210da2f130 drm/i915: pass dev_priv explicitly to TRANS_EXITLINE
1c570d2b97e7 drm/i915: pass dev_priv
> -Original Message-
> From: Jani Nikula
> Sent: Thursday, May 2, 2024 4:14 PM
> To: Kandpal, Suraj ; intel-gfx@lists.freedesktop.org
> Cc: Shankar, Uma ; Nautiyal, Ankit K
> ; Kandpal, Suraj
> Subject: Re: [PATCH 1/2] drm/i915/hdcp: Move aux assignment after
> connector type check
>
On Tue, 30 Apr 2024, Suraj Kandpal wrote:
> Move assignment of aux after connector type check as port may not
> exist if connector is not DPMST.
>
> Signed-off-by: Suraj Kandpal
> ---
> drivers/gpu/drm/i915/display/intel_dp_hdcp.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
>
== Series Details ==
Series: drm/i915/psr: implicit dev_priv removal (rev2)
URL : https://patchwork.freedesktop.org/series/133062/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_14691 -> Patchwork_133062v2
Summary
---
From: Ville Syrjälä
The name 'HAS_REGION()' suggests we are checking for a single
region, so seem more sensible to pass in the region ID rather
than a bitmask.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/gt/intel_gt.c | 2 +-
drivers/gpu/drm/i915/i915_drv.h| 4
From: Ville Syrjälä
This extra macro level between the region IDs and their bitmasks
just makes it harder to see what is used where. Get rid of the
wrappers.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_pci.c | 6 +++---
From: Ville Syrjälä
HAS_REGION() takes a bitmask, not the region ID. This causes the
GEM_BUG_ON() to assert that the SMEM region is available rather
than the intended LMEM region. No real harm since SMEM is always
available, but also not checking what was intended.
Signed-off-by: Ville Syrjälä
> -Original Message-
> From: Kandpal, Suraj
> Sent: Thursday, May 2, 2024 10:11 AM
> To: intel-gfx@lists.freedesktop.org
> Cc: Borah, Chaitanya Kumar ; Shankar,
> Uma ; Nautiyal, Ankit K
> ; Kandpal, Suraj
> Subject: [PATCH] drm/i915/hdcp: Disable HDCP Line Rekeying for HDCP2.2 on
> HDMI
On Tue, 30 Apr 2024, Rodrigo Vivi wrote:
> On Tue, Apr 30, 2024 at 01:10:11PM +0300, Jani Nikula wrote:
>> Avoid the implicit dev_priv local variable use, and pass dev_priv
>> explicitly to the ALPM_CTL2 register macro.
>>
>> Signed-off-by: Jani Nikula
>> ---
>>
Avoid the implicit dev_priv local variable use, and pass dev_priv
explicitly to the PSR2_SU_STATUS register macro.
v2: Expand from _PSR2_SU_STATUS to PSR2_SU_STATUS (Rodrigo)
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/display/intel_psr.c | 3 ++-
On Tue, 30 Apr 2024, Rodrigo Vivi wrote:
> On Tue, Apr 30, 2024 at 01:10:07PM +0300, Jani Nikula wrote:
>> Avoid the implicit dev_priv local variable use, and pass dev_priv
>> explicitly to the _PSR2_SU_STATUS register macro.
>>
>> Signed-off-by: Jani Nikula
>
> why aren't we going one level up
On Thu, May 02, 2024 at 01:39:25PM +0300, Jani Nikula wrote:
> Avoid the implicit dev_priv local variable use, and pass dev_priv
> explicitly to the PSR2_SU_STATUS register macro.
>
> v2: Expand from _PSR2_SU_STATUS to PSR2_SU_STATUS (Rodrigo)
>
> Signed-off-by: Jani Nikula
Reviewed-by:
On Thu, May 02, 2024 at 03:14:22PM +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> The name 'HAS_REGION()' suggests we are checking for a single
> region, so seem more sensible to pass in the region ID rather
> than a bitmask.
>
> Signed-off-by: Ville Syrjälä
Reviewed-by: Rodrigo Vivi
On Thu, May 02, 2024 at 03:14:23PM +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> This extra macro level between the region IDs and their bitmasks
> just makes it harder to see what is used where. Get rid of the
> wrappers.
>
> Signed-off-by: Ville Syrjälä
Reviewed-by: Rodrigo Vivi
>
On Thu, May 02, 2024 at 03:14:21PM +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> HAS_REGION() takes a bitmask, not the region ID. This causes the
> GEM_BUG_ON() to assert that the SMEM region is available rather
> than the intended LMEM region. No real harm since SMEM is always
>
On Thu, May 02, 2024 at 12:28:33PM +0300, Jani Nikula wrote:
> On Tue, 30 Apr 2024, Rodrigo Vivi wrote:
> > On Tue, Apr 30, 2024 at 01:09:59PM +0300, Jani Nikula wrote:
> >> Avoid the implicit dev_priv local variable use, and pass dev_priv
> >> explicitly to the EDP_PSR_AUX_CTL register macro.
>
With HDMI monitors we bumped up a case where the crtc clock rate
caused a mismatch on state verification. This was due to
assumption that the SW clock rate from PLL structure would match
the calculated counterpart from HW. This is not necessarily always
the case and therefore we would actually
Dave, Sima
This week's small set of fixes for drm-next.
drm-xe-next-fixes-2024-05-02:
Driver Changes:
- Fix for a backmerge going slightly wrong.
- An UAF fix
- Avoid a WA error on LNL.
Thanks,
Thomas
The following changes since commit 4a56c0ed5aa0bcbe1f5f7d755fb1fe1ebf48ae9c:
Merge tag
== Series Details ==
Series: series starting with [1/3] drm/i915: Fix HAS_REGION() usage in
intel_gt_probe_lmem()
URL : https://patchwork.freedesktop.org/series/133135/
State : warning
== Summary ==
Error: dim checkpatch failed
2fb2c0fe26a2 drm/i915: Fix HAS_REGION() usage in
== Series Details ==
Series: series starting with [1/3] drm/i915: Fix HAS_REGION() usage in
intel_gt_probe_lmem()
URL : https://patchwork.freedesktop.org/series/133135/
State : warning
== Summary ==
Error: dim sparse failed
Sparse version: v0.6.2
Fast mode used, each commit won't be checked
== Series Details ==
Series: series starting with [1/3] drm/i915: Fix HAS_REGION() usage in
intel_gt_probe_lmem()
URL : https://patchwork.freedesktop.org/series/133135/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_14692 -> Patchwork_133135v1
== Series Details ==
Series: drm/i915/display: Calculate crtc clock rate based on PLL parameters
URL : https://patchwork.freedesktop.org/series/133137/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_14692 -> Patchwork_133137v1
Hi Dave and Sima,
Please pull the drm-xe-fixes for this week targeting v6.9-rc7.
Two important fixes: one avoiding a use-after-free in the rebind worker
and the other to make display work in ADL-N.
thanks
Lucas De Marchi
drm-xe-fixes-2024-05-02:
- Fix UAF on rebind worker
- Fix ADL-N display
Hi Dave, Sima,
here's the PR for drm-misc-fixes for this week.
Best regards
Thomas
drm-misc-fixes-2024-05-02:
Short summary of fixes pull:
imagination:
- fix page-count macro
nouveau:
- avoid page-table allocation failures
- fix firmware memory allocation
panel:
- ili9341: avoid OF for
tree/branch:
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
branch HEAD: 9c6ecb3cb6e20c4fd7997047213ba0efcf9ada1a Add linux-next specific
files for 20240502
Unverified Error/Warning (likely false positive, please contact us if
interested):
drivers/gpu/drm/amd
On 5/2/2024 3:46 AM, Thomas Zimmermann wrote:
>
>
> Am 30.04.24 um 19:38 schrieb Easwar Hariharan:
>> I2C v7, SMBus 3.2, and I3C 1.1.1 specifications have replaced "master/slave"
>> with more appropriate terms. Inspired by and following on to Wolfram's
>> series to fix drivers/i2c/[1], fix the
Hi,
Failure with f_count reference counting are better contained by
an actual reference counting type, like refcount_t. The first step
is for get_file() to use inc_not_zero to avoid resurrection. I also
found a couple open-coded modifications of f_count that should be using
get_file(). Since long
The correct helper for taking an f_count reference is get_file().
Now that it checks for 0 counts, use it and check results.
Signed-off-by: Kees Cook
---
Cc: Zack Rusin
Cc: Broadcom internal kernel review list
Cc: Maarten Lankhorst
Cc: Maxime Ripard
Cc: Thomas Zimmermann
Cc: David Airlie
The correct helper for taking an f_count reference is get_file(). Use it
and check results.
Signed-off-by: Kees Cook
---
Cc: Jani Nikula
Cc: Joonas Lahtinen
Cc: Rodrigo Vivi
Cc: Tvrtko Ursulin
Cc: David Airlie
Cc: Daniel Vetter
Cc: Andi Shyti
Cc: Lucas De Marchi
Cc: Matt Atwood
Cc:
On Fri, May 03, 2024 at 12:53:56AM +0200, Jann Horn wrote:
> On Fri, May 3, 2024 at 12:34 AM Kees Cook wrote:
> > If f_count reaches 0, calling get_file() should be a failure. Adjust to
> > use atomic_long_inc_not_zero() and return NULL on failure. In the future
> > get_file() can be annotated
On Thu, May 02, 2024 at 04:21:13PM -0700, Kees Cook wrote:
> On Fri, May 03, 2024 at 12:12:28AM +0100, Al Viro wrote:
> > On Thu, May 02, 2024 at 03:52:21PM -0700, Kees Cook wrote:
> >
> > > As for semantics, what do you mean? Detecting dec-below-zero means we
> > > catch underflow, and detected
On Thu, May 02, 2024 at 05:10:18PM -0700, Kees Cook wrote:
> But anyway, there needs to be a general "oops I hit 0"-aware form of
> get_file(), and it seems like it should just be get_file() itself...
... which brings back the question of what's the sane damage mitigation
for that. Adding
== Series Details ==
Series: fs: Do not allow get_file() to resurrect 0 f_count
URL : https://patchwork.freedesktop.org/series/133157/
State : warning
== Summary ==
Error: dim checkpatch failed
05a74d02542d fs: Do not allow get_file() to resurrect 0 f_count
cb506a379959 drm/vmwgfx: Do not
== Series Details ==
Series: fs: Do not allow get_file() to resurrect 0 f_count
URL : https://patchwork.freedesktop.org/series/133157/
State : warning
== Summary ==
Error: dim sparse failed
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.
== Series Details ==
Series: fs: Do not allow get_file() to resurrect 0 f_count
URL : https://patchwork.freedesktop.org/series/133157/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_14698 -> Patchwork_133157v1
Summary
On Fri, May 3, 2024 at 12:34 AM Kees Cook wrote:
> If f_count reaches 0, calling get_file() should be a failure. Adjust to
> use atomic_long_inc_not_zero() and return NULL on failure. In the future
> get_file() can be annotated with __must_check, though that is not
> currently possible.
[...]
>
On Thu, May 02, 2024 at 03:33:40PM -0700, Kees Cook wrote:
> Underflow of f_count needs to be more carefully detected than it
> currently is. The results of get_file() should be checked, but the
> first step is detection. Redefine f_count from atomic_long_t to
> refcount_long_t.
It is
On Fri, May 03, 2024 at 12:41:52AM +0100, Al Viro wrote:
> On Thu, May 02, 2024 at 04:21:13PM -0700, Kees Cook wrote:
> > On Fri, May 03, 2024 at 12:12:28AM +0100, Al Viro wrote:
> > > On Thu, May 02, 2024 at 03:52:21PM -0700, Kees Cook wrote:
> > >
> > > > As for semantics, what do you mean?
If f_count reaches 0, calling get_file() should be a failure. Adjust to
use atomic_long_inc_not_zero() and return NULL on failure. In the future
get_file() can be annotated with __must_check, though that is not
currently possible.
Signed-off-by: Kees Cook
---
Cc: Christian Brauner
Cc: Alexander
Underflow of f_count needs to be more carefully detected than it
currently is. The results of get_file() should be checked, but the
first step is detection. Redefine f_count from atomic_long_t to
refcount_long_t.
Signed-off-by: Kees Cook
---
Cc: Christian Brauner
Cc: Alexander Viro
Cc: Jan
Duplicate the refcount_t types and APIs gain refcount_long_t. This is
needed for larger counters that while currently very unlikely to overflow,
still want to detect and mitigate underflow.
Generate refcount-long.h via direct string replacements. Doing macros
like compat_binfmt_elf doesn't appear
On Thu, May 02, 2024 at 11:42:50PM +0100, Al Viro wrote:
> On Thu, May 02, 2024 at 03:33:40PM -0700, Kees Cook wrote:
> > Underflow of f_count needs to be more carefully detected than it
> > currently is. The results of get_file() should be checked, but the
> > first step is detection. Redefine
On Thu, May 02, 2024 at 03:52:21PM -0700, Kees Cook wrote:
> As for semantics, what do you mean? Detecting dec-below-zero means we
> catch underflow, and detected inc-from-zero means we catch resurrection
> attempts. In both cases we avoid double-free, but we have already lost
> to a potential
On Fri, May 03, 2024 at 12:12:28AM +0100, Al Viro wrote:
> On Thu, May 02, 2024 at 03:52:21PM -0700, Kees Cook wrote:
>
> > As for semantics, what do you mean? Detecting dec-below-zero means we
> > catch underflow, and detected inc-from-zero means we catch resurrection
> > attempts. In both cases
On Fri, May 03, 2024 at 01:14:45AM +0100, Al Viro wrote:
> On Thu, May 02, 2024 at 05:10:18PM -0700, Kees Cook wrote:
>
> > But anyway, there needs to be a general "oops I hit 0"-aware form of
> > get_file(), and it seems like it should just be get_file() itself...
>
> ... which brings back the
Ok, I'm getting tired of seeing these for the USB portion of the tree,
so I went to look for:
On Fri, May 03, 2024 at 04:44:42AM +0800, kernel test robot wrote:
> |-- arc-randconfig-002-20240503
> | `-- drivers-usb-dwc3-core.c:warning:variable-hw_mode-set-but-not-used
This warning (same for
Adding the missed r-b
Reviewed-by: Radhakrishna Sripada
> -Original Message-
> From: Sripada, Radhakrishna
> Sent: Tuesday, April 30, 2024 10:29 AM
> To: intel-gfx@lists.freedesktop.org
> Cc: intel...@lists.freedesktop.org; Vivekanandan, Balasubramani
> ; Taylor, Clinton A
> ; Sousa,
== Series Details ==
Series: drm/i915/hdcp: Disable HDCP Line Rekeying for HDCP2.2 on HDMI (rev6)
URL : https://patchwork.freedesktop.org/series/132479/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_14701 -> Patchwork_132479v6
53 matches
Mail list logo
