linux-kernel - Re: [Patch 0/1]drm_irq: Introducing the irq

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CAKMK7uFMAx=+ziO5bS6cr+f1x2b5GHCOFsFFTkPJOXOZsF+USw@mail.gmail.com>
Date:	Thu, 11 Oct 2012 17:18:00 +0200
From:	Daniel Vetter <daniel@...ll.ch>
To:	Rob Clark <robdclark@...il.com>
Cc:	Laurent Pinchart <laurent.pinchart@...asonboard.com>,
	"Shi, Yang A" <yang.a.shi@...el.com>,
	"'linux-kernel@...r.kernel.org' (linux-kernel@...r.kernel.org)" 
	<linux-kernel@...r.kernel.org>, dri-devel@...ts.freedesktop.org,
	"alexander.deucher@....com" <alexander.deucher@....com>,
	"airlied@...hat.com" <airlied@...hat.com>,
	"Liu, Chuansheng" <chuansheng.liu@...el.com>
Subject: Re: [Patch 0/1]drm_irq: Introducing the irq_thread support

On Thu, Oct 11, 2012 at 3:19 PM, Rob Clark <robdclark@...il.com> wrote:
>> Should the documenation be updated to mark those functions as deprecated for
>> new drivers and explain how to handle IRQ (un)registration manually ?

They're not deprecated, since for most drivers they're good enough.
Maybe just make it clear that they're optional (and whoever's the
first might need to do some refactoring to make things simpler for
fancy irq handling).

> It might be nice to provide the driver an option to give it's own
> install/uninstall irq fxn ptrs.. this way we can keep
> drm_irq_install/uninstall().  In particular, the uninstall fxn still
> does some useful cleanup like wake up anyone waiting for vblank events
> which would still be needed by drivers registering irq in their own
> special way.  And the irq pre/post-install stuff is still a bit nice
> to keep.

If a driver needs its own irq setup/teardown magic, I'd prefer if we
simply extract the useful parts of the common code into a little
helper that drivers can call, and don't add new&fancy callbacks and
interface. At least not without really good reasons.

/me has seen enough midlayer awesomeness in drm land already

Cheers, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/