On Thu, Apr 08, 2021 at 12:38:52PM +0200, Daniel Vetter wrote:
> On Mon, Mar 29, 2021 at 09:23:35PM +0300, Imre Deak wrote:
> > Hi Stephen,
> >
> > thanks for the report.
> >
> > On Mon, Mar 29, 2021 at 09:01:17AM +1100, Stephen Rothwell wrote:
> > > H
Hi Stephen,
thanks for the report.
On Mon, Mar 29, 2021 at 09:01:17AM +1100, Stephen Rothwell wrote:
> Hi all,
>
> On Fri, 26 Mar 2021 19:58:38 +1100 Stephen Rothwell
> wrote:
> >
> > After merging the drm-intel-fixes tree, today's linux-next build
> > (htmldocs) produced this warning:
> >
>
Hi,
On Thu, Mar 11, 2021 at 09:32:04AM +0800, Xing Zhengjun wrote:
> On 3/4/2021 8:55 AM, Imre Deak wrote:
> > Hi Oliver,
> >
> > On Wed, Mar 03, 2021 at 01:55:17PM +0800, kernel test robot wrote:
> > >
> > > Greeting,
> > >
> > &g
ch.
> v4:
> * Revert Wa_14010685332 system list in comments to how it was before
> * Add back HAS_PCH_SPLIT() check before calling ibx_irq_reset()
>
> Cc: Matt Roper
> Signed-off-by: Tejas Upadhyay
> Signed-off-by: Lyude Paul
Thanks, looks ok to me:
Reviewed-by: Imre Deak
n
On Tue, Feb 16, 2021 at 09:53:36PM -0500, Lyude Paul wrote:
> From: Tejas Upadhyay
>
> For Legacy S3 suspend/resume GEN9 BC needs to enable and
> setup TGP PCH.
>
> v2:
> * Move Wa_14010685332 into it's own function - vsyrjala
> * Add TODO comment about figuring out if we can move this workaroun
On Tue, Feb 16, 2021 at 09:36:01PM -0500, Lyude Paul wrote:
> On Tue, 2021-02-16 at 20:08 +0200, Imre Deak wrote:
> > Hi,
> >
> > thanks for respinning this patchset, some comments below.
> >
> > On Fri, Feb 12, 2021 at 01:50:53PM -0500, Lyude Paul
Hi,
thanks for respinning this patchset, some comments below.
On Fri, Feb 12, 2021 at 01:50:53PM -0500, Lyude Paul wrote:
> From: Tejas Upadhyay
>
> For Legacy S3 suspend/resume GEN9 BC needs to enable and
> setup TGP PCH.
>
> v2:
> * Move Wa_14010685332 into it's own function - vsyrjala
> * A
linux-next. What is the plan here?
the export is used by the upstream
commit 882554042d138dbc6fb1a43017d0b9c3b38ee5f5
Author: Imre Deak
Date: Mon Jan 25 19:36:36 2021 +0200
drm/i915: Fix the MST PBN divider calculation
which I can also see now applied to 5.10.15:
commit 0fe98e455784a6c11e
On Fri, Aug 21, 2020 at 01:43:39PM -0400, Lyude Paul wrote:
> [...]
> > The wording is a bit unclear, but as I understand the Standard only
> > calls for the above:
> >
> > """
> > A DP upstream device shall read the capability from DPCD Addresses 00080h
> > through 00083h. A DP Branch device wit
On Wed, Aug 19, 2020 at 05:34:15PM -0400, Lyude Paul wrote:
> (adding Ville and Imre to the cc here, they might be interested to know about
> this, comments down below)
>
> On Wed, 2020-08-19 at 11:15 -0400, Sean Paul wrote:
> > On Tue, Aug 11, 2020 at 04:04:50PM -0400, Lyude Paul wrote:
> > > We'
On Thu, Aug 20, 2020 at 12:27:03PM +1000, Sam McNally wrote:
> > > [...]
> > > diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
> > > b/drivers/gpu/drm/drm_dp_mst_topology.c
> > > index 1ac874e4e7a1..73a2299c2faa 100644
> > > --- a/drivers/gpu/drm/drm_dp_mst_topology.c
> > > +++ b/drivers/gpu/dr
On Wed, Jul 29, 2020 at 04:15:28PM +1000, Sam McNally wrote:
> As of commit d8bd15b37d32 ("drm/dp_mst: Fix the DDC I2C device
> registration of an MST port"), DP MST DDC I2C devices are consistently
> parented to the underlying DRM device, making it challenging to
> associate the ddc i2c device wit
s so we can estimate the full_pbn
> value as best we can.
I guess when the connector gets unplugged full_pbn would also get reset
but pruning all modes in that case is ok.
>
> Cc: Manasi Navare
> Cc: Jani Nikula
> Cc: Ville Syrjala
> Cc: Cooper Chiou
> Co-developed-by
in drm_connector_mode_valid()
> if we have no callbacks
> * Drop leftover hunk in drm_modes.h around enum drm_mode_status
>
> Signed-off-by: Lyude Paul
> Cc: Lee Shawn C
Some nits below, but looks good in either way:
Reviewed-and-tested-by: Imre Deak
> ---
> drivers/gpu/dr
On Wed, Jul 08, 2020 at 01:25:14PM -0400, Lyude Paul wrote:
>
> JFYI - found an issue with this patch that wouldn't have shown up on i915,
> info
> down below:
>
> On Wed, 2020-07-08 at 01:40 +0300, Imre Deak wrote:
> > Sorry for the delay, the review as I prom
On Tue, May 26, 2020 at 02:23:10PM -0400, Lyude Paul wrote:
> From: Lee Shawn C
>
> So far, max dot clock rate for MST mode rely on physcial
> bandwidth limitation. It would caused compatibility issue
> if source display resolution exceed MST hub output ability.
>
> For example, source DUT had D
call this with ctx set to a valid context,
> + * and &drm_mode_config.connection_mutex will always be locked with
> + * the ctx parameter set to @ctx. This allows for taking additional
> + * locks as required.
> + *
> + * Even though additional locks may b
Commit-ID: d9349850e188b8b59e5322fda17ff389a1c0cd7d
Gitweb: https://git.kernel.org/tip/d9349850e188b8b59e5322fda17ff389a1c0cd7d
Author: Imre Deak
AuthorDate: Fri, 24 May 2019 23:15:09 +0300
Committer: Ingo Molnar
CommitDate: Mon, 3 Jun 2019 12:32:56 +0200
locking/lockdep: Fix merging
Commit-ID: 8c8889d8eaf4501ae4aaf870b6f8f55db5d5109a
Gitweb: https://git.kernel.org/tip/8c8889d8eaf4501ae4aaf870b6f8f55db5d5109a
Author: Imre Deak
AuthorDate: Fri, 24 May 2019 23:15:08 +0300
Committer: Ingo Molnar
CommitDate: Mon, 3 Jun 2019 12:32:29 +0200
locking/lockdep: Fix OOO
ew possibility to merge
hlocks in that case, so add a WARN if merging still happens then.
v2:
- Clarify the commit log and use mutex_lock() instead of mutex_trylock()
in the example sequences for simplicity.
v3: (Peter)
- Sanitize counting the merge in reacquire_held_locks().
- Optimize calcula
t upstream tree.
- Sanitize overflow check and hlock_references() helper.
Cc: Ville Syrjälä
Cc: Peter Zijlstra
Cc: Ingo Molnar
Cc: Will Deacon
Signed-off-by: Imre Deak
---
kernel/locking/lockdep.c | 22 --
1 file changed, 12 insertions(+), 10 deletions(-)
diff --git a
On Mon, May 27, 2019 at 06:06:18PM +0200, Peter Zijlstra wrote:
> On Mon, May 27, 2019 at 05:14:38PM +0200, Peter Zijlstra wrote:
> > On Fri, May 24, 2019 at 11:15:09PM +0300, Imre Deak wrote:
> > > diff --git a/kernel/locking/lockdep.c b/kernel/locking/lockdep.c
> &
On Mon, May 27, 2019 at 05:14:38PM +0200, Peter Zijlstra wrote:
> On Fri, May 24, 2019 at 11:15:09PM +0300, Imre Deak wrote:
> > diff --git a/kernel/locking/lockdep.c b/kernel/locking/lockdep.c
> > index 967352d32af1..9e2a4ab6c731 100644
> > --- a/kernel/locking/lockdep.c
>
On Mon, May 27, 2019 at 05:02:51PM +0200, Peter Zijlstra wrote:
> On Fri, May 24, 2019 at 11:15:08PM +0300, Imre Deak wrote:
> >
> > ww_mutex_lock(&ww_lock_a, &ww_ctx);
> >
> > mutex_lock(&lock_c);
> >
> > ww_mutex_lock(&
o 4 (representing all the instances for ww_ctx and
ww_lock_[abc]).
Fix this by updating the references during merging correctly taking into
account that we can have non-zero references (both for the hlock that we
merge into another hlock or for the hlock we are merging into).
Cc: Ville Syrjälä
Cc: Pet
ew possibility to merge
hlocks in that case, so add a WARN if merging still happens then.
v2:
- Clarify the commit log and use mutex_lock() instead of mutex_trylock()
in the example sequences for simplicity.
Cc: Ville Syrjälä
Cc: Peter Zijlstra
Cc: Ingo Molnar
Cc: Will Deacon
Signed-off-by: Imre D
as it should've
updated it to 4 (representing all the instances for ww_ctx and
ww_lock_[abc]).
Fix this by updating the references during merging correctly taking into
account that we can have non-zero references (both for the hlock that we
merge into another hlock or for the hlock we are
c);
ww_acquire_fini(&ww_ctx);
Fix this by taking the decrement due to merging into account during lock
release and hlock class re-setting. It can't happen during lock
downgrading since there won't be a new possibility to merge hlocks in
that case, so add a WARN if it happens.
d-off-by: Lyude Paul
> Fixes: 0e32b39ceed6 ("drm/i915: add DP 1.2 MST support (v0.7)")
> Cc: Todd Previte
> Cc: Dave Airlie
> Cc: Jani Nikula
> Cc: Joonas Lahtinen
> Cc: Rodrigo Vivi
> Cc: intel-...@lists.freedesktop.org
> Cc: # v3.17+
Not knowing enough abou
On Mon, Apr 23, 2018 at 08:01:28PM +0300, Imre Deak wrote:
> On Thu, Apr 19, 2018 at 01:05:39PM +0200, Thomas Gleixner wrote:
> > On Thu, 19 Apr 2018, Imre Deak wrote:
> > > Hi,
> > >
> > > while checking bug [1], I noticed that jiffies based timing loops
On Thu, Apr 19, 2018 at 01:05:39PM +0200, Thomas Gleixner wrote:
> On Thu, 19 Apr 2018, Imre Deak wrote:
> > Hi,
> >
> > while checking bug [1], I noticed that jiffies based timing loops like
> >
> > expire = jiffies + timeout + 1;
> >
Hi,
while checking bug [1], I noticed that jiffies based timing loops like
expire = jiffies + timeout + 1;
while (!time_after(jiffies, expire))
do_something;
can last shorter than expected (that is less than timeout). This happens
at least on an Intel Geminilake s
On Sun, Feb 11, 2018 at 10:38:28AM +0100, Lukas Wunner wrote:
> [...]
> i915, malidp and msm "solved" this issue by not stopping the poll worker
> on runtime suspend. But this results in the GPU bouncing back and forth
> between D0 and D3 continuously. That's a total no-go for GPUs which
> runtim
On Fri, Dec 08, 2017 at 10:31:30AM +, Daniel Drake wrote:
> Hi,
>
> Adding intel-gfx list in case i915 developers can help. Updated summary below.
>
> On Thu, Dec 7, 2017 at 2:14 AM, Chris Chiu wrote:
> > On Wed, Dec 6, 2017 at 9:34 PM, Rafael J. Wysocki wrote:
> > > On Wed, Dec 6, 2017 at
Hi Thomas et al,
would it be ok to merge patch [1] - which contains changes in the
iosf_mbi code - via the drm-tip tree? It's part of patchset [2] from
Hans.
Thanks,
Imre
[1]
https://lists.freedesktop.org/archives/intel-gfx/2017-August/135991.html
[2]
https://lists.freedesktop.org/archives/intel
let me
> > > know.
> > >
> > > --
> > >
> > > From: Imre Deak
> > >
> > > commit 4d071c3238987325b9e50e33051a40d1cce311cc upstream.
> > >
> > > Some drivers - like i915 - may not support the system susp
On Tue, Jan 31, 2017 at 01:12:05PM +0100, Rafael J. Wysocki wrote:
> On 1/31/2017 1:02 PM, Imre Deak wrote:
> >On Tue, Jan 31, 2017 at 12:39:35PM +0100, Rafael J. Wysocki wrote:
> >>On 1/31/2017 11:58 AM, Imre Deak wrote:
> >>>Hi Rafael,
> >>Hi,
> >&g
On Tue, Jan 31, 2017 at 12:39:35PM +0100, Rafael J. Wysocki wrote:
> On 1/31/2017 11:58 AM, Imre Deak wrote:
> >Hi Rafael,
>
> Hi,
>
> >On Mon, Jan 30, 2017 at 11:44:37PM +0100, Rafael J. Wysocki wrote:
> >>On 1/24/2017 2:33 AM, Sedat Dilek wrote:
> >>
Hi Rafael,
On Mon, Jan 30, 2017 at 11:44:37PM +0100, Rafael J. Wysocki wrote:
> On 1/24/2017 2:33 AM, Sedat Dilek wrote:
> >On Fri, Dec 30, 2016 at 3:02 PM, Rafael J. Wysocki wrote:
> >>On Fri, Dec 30, 2016 at 12:40 PM, Sedat Dilek wrote:
> >>>Hi,
> >>>
> >>>I have already reported this issue in
Fix the following checkpatch.pl warning:
WARNING: struct net_device_ops should normally be const
+static struct net_device_ops gdm_netdev_ops = {
Signed-off-by: Imre Deak
---
drivers/staging/gdm724x/gdm_lte.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging
On to, 2016-08-18 at 17:58 +0200, Peter Zijlstra wrote:
> On Thu, Aug 11, 2016 at 11:01:27AM -0400, Waiman Long wrote:
> > The following is the updated patch that should fix the build error
> > in
> > non-x86 platform.
> >
>
> This patch was whitespace challenged, but I think I munged it
> proper
On Fri, 2016-07-22 at 12:26 -0700, Davidlohr Bueso wrote:
> On Fri, 22 Jul 2016, Imre Deak wrote:
>
> > On Fri, 2016-07-22 at 11:03 -0700, Davidlohr Bueso wrote:
> > > On Fri, 22 Jul 2016, Waiman Long wrote:
> > >
> > > > I think making mutex
On Fri, 2016-07-22 at 11:03 -0700, Davidlohr Bueso wrote:
> On Fri, 22 Jul 2016, Waiman Long wrote:
>
> > I think making mutex_trylock() fail maybe a bit too far. Do we
> > really
> > have any real workload that cause starvation problem because of
> > that.
> > Code that does mutex_trylock() in
On to, 2016-07-21 at 15:29 -0700, Jason Low wrote:
> On Wed, 2016-07-20 at 14:37 -0400, Waiman Long wrote:
> > On 07/20/2016 12:39 AM, Jason Low wrote:
> > > On Tue, 2016-07-19 at 16:04 -0700, Jason Low wrote:
> > > > Hi Imre,
> > > >
> > > > Here is a patch which prevents a thread from spending t
On ti, 2016-07-19 at 21:39 -0700, Jason Low wrote:
> On Tue, 2016-07-19 at 16:04 -0700, Jason Low wrote:
> > Hi Imre,
> >
> > Here is a patch which prevents a thread from spending too much "time"
> > waiting for a mutex in the !CONFIG_MUTEX_SPIN_ON_OWNER case.
> >
> > Would you like to try this o
On ma, 2016-07-18 at 10:47 -0700, Jason Low wrote:
> On Mon, 2016-07-18 at 19:15 +0200, Peter Zijlstra wrote:
> > On Mon, Jul 18, 2016 at 07:16:47PM +0300, Imre Deak wrote:
> > > Currently a thread sleeping on a mutex wait queue can be delayed
> > > indefinitely by othe
n FIFO order.
CC: Peter Zijlstra
CC: Ingo Molnar
CC: Chris Wilson
CC: Daniel Vetter
CC: Ville Syrjälä
Reference: https://bugs.freedesktop.org/show_bug.cgi?id=96701
Signed-off-by: Imre Deak
---
include/linux/mutex.h | 5 +
kernel/locking/mutex.c | 33 +
2 file
On to, 2015-12-03 at 14:47 +, Mark Brown wrote:
> Hi Dave,
>
> Today's linux-next merge of the drm tree got a conflict in
> drivers/gpu/drm/i915/i915_drv.h and
> drivers/gpu/drm/i915/i915_debugfs.c between
> commit ac9b8236551d ("drm/i915: Introduce a gmbus power domain") from
> the
> drm-inte
On ti, 2015-06-23 at 13:42 +0300, Mikko Rapeli wrote:
> Hi Imre,
>
> On Mon, Jun 22, 2015 at 04:43:50PM +0300, Imre Deak wrote:
> >
> > To summarize, since we extended the range of platforms to apply the
> > workaround in
> > commit ab3be73fa7b43f4c3648ce29b5fd6
> https://lkml.org/lkml/2015/6/17/327 . That message contains a link to a
> patch I cobbled together for yet another ThinkPad hitting this, but with
> PCI_SUBVENDOR_ID_IBM involved.
To summarize, since we extended the range of platforms to apply the
workaround in
commit ab3be73fa7b43f4c3648ce2
The two patches that fix this issue is already reviewed and waiting to
be merged:
http://lists.freedesktop.org/archives/intel-gfx/2015-April/064993.html
On Wed, 2015-04-29 at 10:31 -0700, Tyler Baker wrote:
> Hi,
>
> Today's linux-next (next-20150429) fails to boot to a minimal
> buildroot based
g why there are
two distinct lockdep reports and that this issue is independent of
fb/fbcon. (Peter Hurley)
v3:
- clarify further the third paragraph
v4:
- rebased on v4 of patch 1/3
Signed-off-by: Imre Deak
Reviewed-by: Daniel Vetter
---
drivers/tty/vt/vt.c | 61 +++
On Thu, 2015-03-26 at 22:01 +0100, Greg Kroah-Hartman wrote:
> On Thu, Mar 26, 2015 at 12:59:05PM -0700, Jesse Barnes wrote:
> > On 12/16/2014 09:42 AM, Daniel Vetter wrote:
> > > On Tue, Dec 16, 2014 at 6:15 PM, Peter Hurley
> > > wrote:
> > >>
Bjørn reported that his machine hang during hibernation and eventually
bisected the problem to the following commit:
commit da2bc1b9db3351addd293e5b82757efe1f77ed1d
Author: Imre Deak
Date: Thu Oct 23 19:23:26 2014 +0300
drm/i915: add poweroff_late handler
The problem seems to be that
On Fri, 2015-02-27 at 14:15 +0200, David Weinehall wrote:
> On Thu, Feb 26, 2015 at 09:01:27PM +0100, Daniel Vetter wrote:
> > On Thu, Feb 26, 2015 at 08:50:48PM +0200, Imre Deak wrote:
>
> [snip]
> > >
> > > The problem seems to be that after the kernel puts
On to, 2015-02-26 at 10:34 +0100, Bjørn Mork wrote:
> Imre Deak writes:
>
> >> That patch fixes the problem, with only pci_set_power_state commented
> >> out. Do you still want me to try with pci_disable_device() commented
> >> out as well?
> >
> >
On ti, 2015-02-24 at 20:00 +0100, Bjørn Mork wrote:
> Imre Deak writes:
>
> > The poweroff handlers undo the actions of the thaw handlers. As the
> > original commit stated saving the registers is not needed there, but
> > it's also not a big overhead and there shou
On ti, 2015-02-24 at 15:58 +0100, Bjørn Mork wrote:
> This fixes a bug where hibernation completes, but the system
> fails to power off after the image has been saved.
>
> Bisection lead to commit da2bc1b9db33 ("drm/i915: add poweroff_late
> handler") which added a .poweroff_late hook pointing to
On to, 2015-02-19 at 15:42 +, Dave Gordon wrote:
> On 19/02/15 11:08, Deak, Imre wrote:
> > On Thu, 2015-02-19 at 10:47 +, Dave Gordon wrote:
> >> On 18/02/15 16:24, Imre Deak wrote:
> >>> On ke, 2015-02-18 at 17:39 +0200, Jani Nikula wrote:
> >>>
On Thu, 2015-02-19 at 10:47 +, Dave Gordon wrote:
> On 18/02/15 16:24, Imre Deak wrote:
> > On ke, 2015-02-18 at 17:39 +0200, Jani Nikula wrote:
> >> On Tue, 17 Feb 2015, Klaus Ethgen wrote:
> >>> After solving the conflicts, I applied the revert (see attachment
without creating an account? I would really like to not create
> another account. I still have that many from systems that forced me to
> create an account for just one bug report.
Yes, you need an account to file a freedesktop bug. This would be really
great to keep records, but if this isn't
On ke, 2015-02-18 at 17:39 +0200, Jani Nikula wrote:
> On Tue, 17 Feb 2015, Klaus Ethgen wrote:
> > After solving the conflicts, I applied the revert (see attachment) to
> > v3.18.7. I think it should also apply to the current head. With that
> > patch, suspend is working again on that version.
>
] RSP
[0.428007] ---[ end trace 73a740f3f01d4332 ]---
[0.432017] Kernel panic - not syncing: Attempted to kill init!
exitcode=0x000b
Signed-off-by: Imre Deak
---
arch/x86/xen/time.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/arch/x86/xen/time.c b/arch/x86/xen/time.c
index f
On Tue, 2014-12-16 at 10:00 -0500, Peter Hurley wrote:
> On 12/16/2014 09:38 AM, Imre Deak wrote:
> > On Tue, 2014-12-16 at 07:50 -0500, Peter Hurley wrote:
> >> On 12/16/2014 05:23 AM, Imre Deak wrote:
> >>> On Tue, 2014-12-16 at 08:53 +0100, Daniel Vetter wrote:
>
On Tue, 2014-12-16 at 07:50 -0500, Peter Hurley wrote:
> On 12/16/2014 05:23 AM, Imre Deak wrote:
> > On Tue, 2014-12-16 at 08:53 +0100, Daniel Vetter wrote:
> >> On Tue, Dec 16, 2014 at 12:16:01AM +0200, Imre Deak wrote:
> >>> Currently there is a lock order proble
On Tue, 2014-12-16 at 08:53 +0100, Daniel Vetter wrote:
> On Tue, Dec 16, 2014 at 12:16:01AM +0200, Imre Deak wrote:
> > Currently there is a lock order problem between the console lock and the
> > kernfs s_active lock of the console driver's bind sysfs entry. When
> >
g why there are
two distinct lockdep reports and that this issue is independent of
fb/fbcon. (Peter Hurley)
v3:
- clarify further the third paragraph
v4:
- rebased on v4 of patch 1/3
Reference: https://bugs.freedesktop.org/show_bug.cgi?id=70523
Signe
g a system console driver too, needed by i915 to
unregister vgacon. Update commit description accordingly. (Daniel)
Signed-off-by: Imre Deak
---
drivers/tty/vt/vt.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/tty/vt/vt.c b/drivers/tty/vt/vt.c
index f3fbbbc..9c0
Currently vt_bind and vt_unbind access at least the con_driver object
and registered_con_driver array without holding the console lock. Fix
this by locking around the whole function in each case.
Signed-off-by: Imre Deak
Reviewed-by: Peter Hurley
---
drivers/tty/vt/vt.c | 11 +--
1
tem or non-system, but that's
already guaranteed by the (csw == conswitchp) check. So I'll send a new
version removing the con_driver->flag check.
--Imre
> -Daniel
>
>
> On Sat, Dec 13, 2014 at 10:14 PM, Imre Deak wrote:
> > System console drivers (without the CON_D
g why there are
two distinct lockdep reports and that this issue is independent of
fb/fbcon. (Peter Hurley)
v3:
- clarify further the third paragraph
Reference: https://bugs.freedesktop.org/show_bug.cgi?id=70523
Signed-off-by: Imre Deak
---
drivers/tty/vt/vt.c | 61 +++
reason for deferring the sysfs entry
removal
- add a third paragraph to the commit message explaining why there are
two distinct lockdep reports and that this issue is independent of
fb/fbcon. (Peter Hurley)
Reference: https://bugs.freedesktop.org/show_bug.cgi?id=70523
Signed-off-by: Imre Deak
eword the third paragraph to clarify how the fix works (Peter Hurley)
Signed-off-by: Imre Deak
---
drivers/tty/vt/vt.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/tty/vt/vt.c b/drivers/tty/vt/vt.c
index b33b00b..1862e89 100644
--- a/drivers/tty/vt/vt.c
+++ b/driv
On Fri, 2014-12-12 at 17:45 -0500, Peter Hurley wrote:
> [ +cc Daniel because of the i915 lockdep report ]
>
> On 12/12/2014 05:03 PM, Imre Deak wrote:
> > On Fri, 2014-12-12 at 16:03 -0500, Peter Hurley wrote:
> >> On 12/12/2014 03:29 PM, Imre Deak wrote:
> >>&
On Fri, 2014-12-12 at 16:03 -0500, Peter Hurley wrote:
> On 12/12/2014 03:29 PM, Imre Deak wrote:
> > Hi Peter,
> >
> > thanks for your review.
> >
> > On Fri, 2014-12-12 at 13:32 -0500, Peter Hurley wrote:
> >> Hi Imre,
> >>
> >> On 12
On Fri, 2014-12-12 at 22:29 +0200, Imre Deak wrote:
> Hi Peter,
>
> thanks for your review.
>
> On Fri, 2014-12-12 at 13:32 -0500, Peter Hurley wrote:
> > Hi Imre,
> >
> > On 12/12/2014 11:38 AM, Imre Deak wrote:
> > > Currently there is a lock orde
Hi Peter,
thanks for your review.
On Fri, 2014-12-12 at 13:32 -0500, Peter Hurley wrote:
> Hi Imre,
>
> On 12/12/2014 11:38 AM, Imre Deak wrote:
> > Currently there is a lock order problem between the console lock and the
> > kernfs s_active lock of the console driver
Currently vt_bind and vt_unbind access at least the con_driver object
and registered_con_driver array without holding the console lock. Fix
this by locking around the whole function in each case.
Signed-off-by: Imre Deak
---
drivers/tty/vt/vt.c | 11 +--
1 file changed, 5 insertions
system console driver.
Fix this by checking for CON_DRIVER_FLAG_MODULE to refuse unregistering
a system console driver and relying on the existing con_is_bound() check
earlier in the function to refuse unregistering a busy console driver.
Signed-off-by: Imre Deak
---
drivers/tty/vt/vt.c | 2 +-
sponding
device with a minor index that's still in use.
Reference: https://bugs.freedesktop.org/show_bug.cgi?id=70523
Signed-off-by: Imre Deak
---
drivers/tty/vt/vt.c | 51 +--
1 file changed, 41 insertions(+), 10 deletions(-)
diff --git a/d
On Wed, 2014-12-03 at 10:22 +0100, Daniel Vetter wrote:
> On Tue, Dec 02, 2014 at 08:54:13AM -0800, John Stultz wrote:
> > On Tue, Dec 2, 2014 at 8:35 AM, Chris Wilson
> > wrote:
> > > On Tue, Dec 02, 2014 at 04:36:22PM +0100, Daniel Vetter wrote:
> > >> +static inline unsigned long nsecs_to_jiff
ditionally, it's guaranteed that error
is non-zero
v3:
- split out this fix into a separate patch (Rafael)
- add code comment on why BUG_ON() is used (Rafael)
Signed-off-by: Imre Deak
---
kernel/power/hibernate.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git
re to
reinitialize them during resume.
v3 (added to patchset):
- split out this fix into a separate patch (Rafael)
Signed-off-by: Imre Deak
---
drivers/base/power/main.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/base/power/main.c b/drivers/base/power/main.c
index 4497319..97
On Fri, 2014-10-24 at 16:04 +0200, Rafael J. Wysocki wrote:
> On Friday, October 24, 2014 10:59:09 AM Imre Deak wrote:
> > Atm, if one of the dev_pm_ops::freeze callbacks fails during the QUIESCE
> > phase we don't rollback things correctly calling the thaw and complete
>
ing resume.
v2:
- call dpm_resume_end() unconditionally, it's guaranteed that error
is non-zero
Signed-off-by: Imre Deak
---
drivers/base/power/main.c | 2 ++
kernel/power/hibernate.c | 3 ++-
2 files changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/base/power/main.c b/dri
ing resume.
Signed-off-by: Imre Deak
---
drivers/base/power/main.c | 2 ++
kernel/power/hibernate.c | 4 +++-
2 files changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/base/power/main.c b/drivers/base/power/main.c
index 4497319..9717d5f 100644
--- a/drivers/base/power/main.c
+++ b/dr
We can call this function for a dummy console that doesn't support
setting the font mapping, which will result in a null ptr BUG. So check
for this case and return error for consoles w/o font mapping support.
Reference: https://bugzilla.kernel.org/show_bug.cgi?id=59321
Signed-off-by: Imre
Should fix:
> Message-ID: <1409382202.5141.36.ca...@marge.simpson.net>
>
> Reported-by: Mike Galbraith
> Signed-off-by: Dave Airlie
Daniel reviewed this already, but Jani asked me to take a look, so:
Acked-by: Imre Deak
One thing for the future is to move ibx_digital_port_con
On Thu, 2014-07-31 at 23:47 +0200, Ian Kumlien wrote:
> On tor, 2014-07-31 at 14:39 +0300, Imre Deak wrote:
> > On Wed, 2014-07-30 at 22:52 +0200, Ian Kumlien wrote:
> > > Sorry for the delay, it's been damned hot - vacation is over and
> > > overtime has been all
On Wed, 2014-07-30 at 22:52 +0200, Ian Kumlien wrote:
> Sorry for the delay, it's been damned hot - vacation is over and
> overtime has been all the rage at work...
No problem, thanks for the feedback.
> On fre, 2014-07-25 at 12:28 +0300, Imre Deak wrote:
> > On Thu, 2014-
On Thu, 2014-07-24 at 01:33 +0200, Ian Kumlien wrote:
> Try four, now including CC lists for the intel driver...
Could you give a try to the 2 patches at:
https://patchwork.kernel.org/patch/4437061/
If these don't fix the issue, could you send a full dmesg log with the
drm.debug=14 kernel option
On Tue, 2014-06-10 at 12:35 -0700, Steven Noonan wrote:
> On Wed, Apr 16, 2014 at 3:03 PM, Steven Noonan wrote:
> > On Wed, Apr 16, 2014 at 2:46 PM, Jani Nikula
> > wrote:
> >> On Tue, 15 Apr 2014, Imre Deak wrote:
> >>> On Tue, 2014-04-15 at 21:43 +0200
e while
> fiddling with the vgacon code.
>
> Signed-off-by: Daniel Vetter
Reviewed-by: Imre Deak
> ---
> drivers/gpu/drm/i915/i915_dma.c | 4
> drivers/gpu/drm/i915/i915_gem_gtt.c | 9 -
> 2 files changed, 8 insertions(+), 5 deletions(-)
>
> d
On Tue, 2014-04-15 at 21:43 +0200, Daniel Vetter wrote:
> On Mon, Apr 14, 2014 at 11:56:03AM -0700, Steven Noonan wrote:
> > On Mon, Apr 14, 2014 at 11:35:05AM -0700, Keith Packard wrote:
> > > Steven Noonan writes:
> > >
> > > > Was using my machine normally, then my mouse cursor vanished. After
> [...]
> Shortlog:
> Al Viro (6):
> make prepend_name() work correctly when called with negative
*buflen
A proper attribution for the above fix would have been nice. Tracking
down the bug was the main thing after all:
https://lkml.org/lkml/2014/3/12/620
--Imre
--
To unsubscribe from this
gt; 89 1f 4c 89 57 08
4c 89 4f 10 4c 89 47 18 48 8d 7f 20 73 d4
RIP [] memmove+0x4a/0x1a0
RSP
CR2: c90f5000
Signed-off-by: Imre Deak
---
fs/dcache.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/fs/dcache.c b/fs/dcache.c
index 265e0ce..ca02c13 100644
--
On Sun, 2014-03-23 at 04:36 +, Al Viro wrote:
> On Thu, Mar 13, 2014 at 01:29:46AM +0200, Imre Deak wrote:
> > During dentry path lookups we can end up corrupting memory if the
> > destination path buffer is too small. This is because prepend_path()
> > and prepend() adj
Airlie
> Cc: dri-de...@lists.freedesktop.org
> Cc: linux-kernel@vger.kernel.org
> Signed-off-by: G, Pallavi
> Signed-off-by: Sagar Kamble
Looks ok:
Reviewed-by: Imre Deak
> ---
> drivers/gpu/drm/i915/i915_reg.h | 4 +++
> drivers/gpu/drm/i915/intel_displa
Airlie
> Cc: dri-de...@lists.freedesktop.org
> Cc: linux-kernel@vger.kernel.org
> Signed-off-by: G, Pallavi
> Signed-off-by: Sagar Kamble
Looks ok:
Reviewed-by: Imre Deak
> ---
> drivers/gpu/drm/i915/i915_reg.h | 4 +++
> drivers/gpu/drm/i915/intel_displa
05 40 38 fe 74 41 48 83 ea 20 48 83 ea 20
4c 8b 1e 4c 8b 56 08 4c 8b 4e 10 4c 8b 46 18 48 8d 76 20 <4c> 89 1f 4c 89 57 08
4c 89 4f 10 4c 89 47 18 48 8d 7f 20 73 d4
RIP [] memmove+0x4a/0x1a0
RSP
CR2: c90f5000
---[ end trace cc7a046285294005 ]---
Signed-off-by: Imre Deak
-
1 - 100 of 164 matches
Mail list logo
