Hi Daniel.
On Mon, Mar 23, 2020 at 03:49:02PM +0100, Daniel Vetter wrote:
> We have lots of these. And the cleanup code tends to be of dubious
> quality. The biggest wrong pattern is that developers use devm_, which
> ties the release action to the underlying struct device, whereas
> all the
We have lots of these. And the cleanup code tends to be of dubious
quality. The biggest wrong pattern is that developers use devm_, which
ties the release action to the underlying struct device, whereas
all the userspace visible stuff attached to a drm_device can long
outlive that one (e.g. after
On Wed, Mar 11, 2020 at 10:14:03AM +0100, Thomas Zimmermann wrote:
>
>
> Am 02.03.20 um 23:25 schrieb Daniel Vetter:
> <...>
> > +
> > +int __drmm_add_action(struct drm_device *dev,
> > + drmres_release_t action,
> > + void *data, const char *name)
> > +{
> > +
On Wed, Mar 11, 2020 at 10:07:13AM +0100, Thomas Zimmermann wrote:
> Hi Daniel
>
> Am 02.03.20 um 23:25 schrieb Daniel Vetter:
> > We have lots of these. And the cleanup code tends to be of dubious
> > quality. The biggest wrong pattern is that developers use devm_, which
> > ties the release
Am 11.03.20 um 10:07 schrieb Thomas Zimmermann:
> Hi Daniel
>
> Am 02.03.20 um 23:25 schrieb Daniel Vetter:
>> We have lots of these. And the cleanup code tends to be of dubious
>> quality. The biggest wrong pattern is that developers use devm_, which
>> ties the release action to the
Am 02.03.20 um 23:25 schrieb Daniel Vetter:
<...>
> +
> +int __drmm_add_action(struct drm_device *dev,
> + drmres_release_t action,
> + void *data, const char *name)
> +{
> + struct drmres *dr;
> + void **void_ptr;
> +
> + dr = alloc_dr(action,
Hi Daniel
Am 02.03.20 um 23:25 schrieb Daniel Vetter:
> We have lots of these. And the cleanup code tends to be of dubious
> quality. The biggest wrong pattern is that developers use devm_, which
> ties the release action to the underlying struct device, whereas
> all the userspace visible stuff
On Tue, Mar 03, 2020 at 11:04:06AM +0300, Dan Carpenter wrote:
> Hi Daniel,
>
> I love your patch! Perhaps something to improve:
>
> url:
> https://github.com/0day-ci/linux/commits/Daniel-Vetter/drm_device-managed-resources-v4/20200303-071023
> base:
Hi Daniel,
I love your patch! Perhaps something to improve:
url:
https://github.com/0day-ci/linux/commits/Daniel-Vetter/drm_device-managed-resources-v4/20200303-071023
base: git://anongit.freedesktop.org/drm/drm-tip drm-tip
If you fix the issue, kindly add following tag
Reported-by:
We have lots of these. And the cleanup code tends to be of dubious
quality. The biggest wrong pattern is that developers use devm_, which
ties the release action to the underlying struct device, whereas
all the userspace visible stuff attached to a drm_device can long
outlive that one (e.g. after
Hi Daniel / Jani.
> On Mon, Mar 02, 2020 at 11:22:34AM +0200, Jani Nikula wrote:
> > On Sat, 29 Feb 2020, Daniel Vetter wrote:
> > > On Sat, Feb 29, 2020 at 12:17 PM Sam Ravnborg wrote:
> > >> The header-check infrastructure was dropped again - see:
> > >>
On Mon, Mar 02, 2020 at 11:22:34AM +0200, Jani Nikula wrote:
> On Sat, 29 Feb 2020, Daniel Vetter wrote:
> > On Sat, Feb 29, 2020 at 12:17 PM Sam Ravnborg wrote:
> >> The header-check infrastructure was dropped again - see:
> >> fcbb8461fd2376ba3782b5b8bd440c929b8e4980
> >
> > Uh I'm disappoint
On Mon, Mar 02, 2020 at 11:22:34AM +0200, Jani Nikula wrote:
> On Sat, 29 Feb 2020, Daniel Vetter wrote:
> > On Sat, Feb 29, 2020 at 12:17 PM Sam Ravnborg wrote:
> >> > > > + /**
> >> > > > + * @managed:
> >> > > > + *
> >> > > > + * Managed resources linked to the lifetime of
On Sat, 29 Feb 2020, Daniel Vetter wrote:
> On Sat, Feb 29, 2020 at 12:17 PM Sam Ravnborg wrote:
>> The header-check infrastructure was dropped again - see:
>> fcbb8461fd2376ba3782b5b8bd440c929b8e4980
>
> Uh I'm disappoint :-/
To say the least. I thought it was a good *opt-in* feature for
On Sat, Feb 29, 2020 at 12:17 PM Sam Ravnborg wrote:
> > > > + *
> > > > + * Based on drivers/base/devres.c
> > > > + */
> > > > +
> > > > +#include
> > > > +
> > > > +#include
> > > > +#include
> > > > +#include
> > > > +
> > > > +#include
> > > > +#include
> > >
> > > It is good practice
Hi Daniel.
> > > diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
> > > index 9fcd6ab3c154..3e5627d6eba6 100644
> > > --- a/drivers/gpu/drm/drm_drv.c
> > > +++ b/drivers/gpu/drm/drm_drv.c
> > > @@ -629,6 +629,9 @@ int drm_dev_init(struct drm_device *dev,
> > > dev->dev =
On Fri, Feb 28, 2020 at 11:45 PM Sam Ravnborg wrote:
>
> Hi Daniel.
>
> Some nitpicks / bikeshedding below.
>
> Sam
>
> On Thu, Feb 27, 2020 at 07:14:34PM +0100, Daniel Vetter wrote:
> > We have lots of these. And the cleanup code tends to be of dubious
> > quality. The biggest wrong
Hi Daniel.
Some nitpicks / bikeshedding below.
Sam
On Thu, Feb 27, 2020 at 07:14:34PM +0100, Daniel Vetter wrote:
> We have lots of these. And the cleanup code tends to be of dubious
> quality. The biggest wrong pattern is that developers use devm_, which
> ties the release action to
We have lots of these. And the cleanup code tends to be of dubious
quality. The biggest wrong pattern is that developers use devm_, which
ties the release action to the underlying struct device, whereas
all the userspace visible stuff attached to a drm_device can long
outlive that one (e.g. after
On 26.02.2020 11:21, Daniel Vetter wrote:
> On Wed, Feb 26, 2020 at 10:21:17AM +0100, Andrzej Hajda wrote:
>> On 25.02.2020 16:03, Daniel Vetter wrote:
>>> On Tue, Feb 25, 2020 at 11:27 AM Andrzej Hajda wrote:
Hi Daniel,
The patchset looks interesting.
On
On Wed, Feb 26, 2020 at 10:21:17AM +0100, Andrzej Hajda wrote:
> On 25.02.2020 16:03, Daniel Vetter wrote:
> > On Tue, Feb 25, 2020 at 11:27 AM Andrzej Hajda wrote:
> >> Hi Daniel,
> >>
> >>
> >> The patchset looks interesting.
> >>
> >>
> >> On 21.02.2020 22:02, Daniel Vetter wrote:
> >>> We
On 25.02.2020 16:03, Daniel Vetter wrote:
> On Tue, Feb 25, 2020 at 11:27 AM Andrzej Hajda wrote:
>> Hi Daniel,
>>
>>
>> The patchset looks interesting.
>>
>>
>> On 21.02.2020 22:02, Daniel Vetter wrote:
>>> We have lots of these. And the cleanup code tends to be of dubious
>>> quality. The
On Tue, Feb 25, 2020 at 11:27 AM Andrzej Hajda wrote:
>
> Hi Daniel,
>
>
> The patchset looks interesting.
>
>
> On 21.02.2020 22:02, Daniel Vetter wrote:
> > We have lots of these. And the cleanup code tends to be of dubious
> > quality. The biggest wrong pattern is that developers use devm_,
Hi Daniel,
The patchset looks interesting.
On 21.02.2020 22:02, Daniel Vetter wrote:
> We have lots of these. And the cleanup code tends to be of dubious
> quality. The biggest wrong pattern is that developers use devm_, which
> ties the release action to the underlying struct device, whereas
We have lots of these. And the cleanup code tends to be of dubious
quality. The biggest wrong pattern is that developers use devm_, which
ties the release action to the underlying struct device, whereas
all the userspace visible stuff attached to a drm_device can long
outlive that one (e.g. after
25 matches
Mail list logo
