On Wed, Apr 24, 2024 at 06:06:52PM +0530, Aravind Iddamsetty wrote:
>
> On 24/04/24 17:21, Maxime Ripard wrote:
> > On Mon, Apr 22, 2024 at 12:27:53PM +0530, Aravind Iddamsetty wrote:
> >> In scenarios where drm_dev_put is directly called by driver we want to
> >> release devm_drm_dev_init_release
On 25/04/24 18:22, Maxime Ripard wrote:
> On Wed, Apr 24, 2024 at 08:20:32AM -0400, Rodrigo Vivi wrote:
>> On Wed, Apr 24, 2024 at 01:49:16PM +0200, Maxime Ripard wrote:
>>> On Tue, Apr 23, 2024 at 01:42:22PM -0400, Rodrigo Vivi wrote:
On Tue, Apr 23, 2024 at 02:25:06PM +0530, Aravind Iddams
On Wed, Apr 24, 2024 at 08:20:32AM -0400, Rodrigo Vivi wrote:
> On Wed, Apr 24, 2024 at 01:49:16PM +0200, Maxime Ripard wrote:
> > On Tue, Apr 23, 2024 at 01:42:22PM -0400, Rodrigo Vivi wrote:
> > > On Tue, Apr 23, 2024 at 02:25:06PM +0530, Aravind Iddamsetty wrote:
> > > >
> > > > On 23/04/24 02:
On 24/04/24 17:21, Maxime Ripard wrote:
> On Mon, Apr 22, 2024 at 12:27:53PM +0530, Aravind Iddamsetty wrote:
>> In scenarios where drm_dev_put is directly called by driver we want to
>> release devm_drm_dev_init_release action associated with struct
>> drm_device.
>>
>> v2: Directly expose the o
On Wed, Apr 24, 2024 at 01:49:16PM +0200, Maxime Ripard wrote:
> On Tue, Apr 23, 2024 at 01:42:22PM -0400, Rodrigo Vivi wrote:
> > On Tue, Apr 23, 2024 at 02:25:06PM +0530, Aravind Iddamsetty wrote:
> > >
> > > On 23/04/24 02:24, Rodrigo Vivi wrote:
> > > > On Mon, Apr 22, 2024 at 12:27:53PM +0530
On Mon, Apr 22, 2024 at 12:27:53PM +0530, Aravind Iddamsetty wrote:
> In scenarios where drm_dev_put is directly called by driver we want to
> release devm_drm_dev_init_release action associated with struct
> drm_device.
>
> v2: Directly expose the original function, instead of introducing a
> hel
On Tue, Apr 23, 2024 at 01:42:22PM -0400, Rodrigo Vivi wrote:
> On Tue, Apr 23, 2024 at 02:25:06PM +0530, Aravind Iddamsetty wrote:
> >
> > On 23/04/24 02:24, Rodrigo Vivi wrote:
> > > On Mon, Apr 22, 2024 at 12:27:53PM +0530, Aravind Iddamsetty wrote:
> > >> In scenarios where drm_dev_put is dire
On 23/04/24 23:12, Rodrigo Vivi wrote:
> On Tue, Apr 23, 2024 at 02:25:06PM +0530, Aravind Iddamsetty wrote:
>> On 23/04/24 02:24, Rodrigo Vivi wrote:
>>> On Mon, Apr 22, 2024 at 12:27:53PM +0530, Aravind Iddamsetty wrote:
In scenarios where drm_dev_put is directly called by driver we want t
On Tue, Apr 23, 2024 at 02:25:06PM +0530, Aravind Iddamsetty wrote:
>
> On 23/04/24 02:24, Rodrigo Vivi wrote:
> > On Mon, Apr 22, 2024 at 12:27:53PM +0530, Aravind Iddamsetty wrote:
> >> In scenarios where drm_dev_put is directly called by driver we want to
> >> release devm_drm_dev_init_release
On 23/04/24 02:24, Rodrigo Vivi wrote:
> On Mon, Apr 22, 2024 at 12:27:53PM +0530, Aravind Iddamsetty wrote:
>> In scenarios where drm_dev_put is directly called by driver we want to
>> release devm_drm_dev_init_release action associated with struct
>> drm_device.
>>
>> v2: Directly expose the or
On Mon, Apr 22, 2024 at 12:27:53PM +0530, Aravind Iddamsetty wrote:
> In scenarios where drm_dev_put is directly called by driver we want to
> release devm_drm_dev_init_release action associated with struct
> drm_device.
>
> v2: Directly expose the original function, instead of introducing a
> hel
In scenarios where drm_dev_put is directly called by driver we want to
release devm_drm_dev_init_release action associated with struct
drm_device.
v2: Directly expose the original function, instead of introducing a
helper (Rodrigo)
v3: add kernel-doc (Maxime Ripard)
Cc: Maxime Ripard
Cc: Thomas
12 matches
Mail list logo