Use new return type vm_fault_t for fault handler. For
now, this is just documenting that the function returns
a VM_FAULT value rather than an errno. Once all instances
are converted, vm_fault_t will become a distinct type.
Reference id -> 1c8f422059ae ("mm: change return type to
vm_fault_t")
Signed-off-by: Souptick Joarder <[email protected]>
---
drivers/gpu/drm/qxl/qxl_ttm.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/qxl/qxl_ttm.c b/drivers/gpu/drm/qxl/qxl_ttm.c
index 59cd74c..0b482b1 100644
--- a/drivers/gpu/drm/qxl/qxl_ttm.c
+++ b/drivers/gpu/drm/qxl/qxl_ttm.c
@@ -105,16 +105,16 @@ static void qxl_ttm_global_fini(struct qxl_device *qdev)
static struct vm_operations_struct qxl_ttm_vm_ops;
static const struct vm_operations_struct *ttm_vm_ops;
-static int qxl_ttm_fault(struct vm_fault *vmf)
+static vm_fault_t qxl_ttm_fault(struct vm_fault *vmf)
{
struct ttm_buffer_object *bo;
- int r;
+ vm_fault_t ret;
bo = (struct ttm_buffer_object *)vmf->vma->vm_private_data;
if (bo == NULL)
return VM_FAULT_NOPAGE;
- r = ttm_vm_ops->fault(vmf);
- return r;
+ ret = ttm_vm_ops->fault(vmf);
+ return ret;
}
int qxl_mmap(struct file *filp, struct vm_area_struct *vma)
--
1.9.1
On Tue, Apr 17, 2018 at 07:08:44PM +0530, Souptick Joarder wrote:
> Use new return type vm_fault_t for fault handler. For
> now, this is just documenting that the function returns
> a VM_FAULT value rather than an errno. Once all instances
> are converted, vm_fault_t will become a distinct type.
>
> Reference id -> 1c8f422059ae ("mm: change return type to
> vm_fault_t")
Hmm, that commit isn't yet in drm-misc-next.
Will drm-misc-next merge with 4.17-rcX soon?
cheers,
Gerd
On Mon, Apr 23, 2018 at 12:49:24PM +0200, Gerd Hoffmann wrote:
> On Tue, Apr 17, 2018 at 07:08:44PM +0530, Souptick Joarder wrote:
> > Use new return type vm_fault_t for fault handler. For
> > now, this is just documenting that the function returns
> > a VM_FAULT value rather than an errno. Once all instances
> > are converted, vm_fault_t will become a distinct type.
> >
> > Reference id -> 1c8f422059ae ("mm: change return type to
> > vm_fault_t")
>
> Hmm, that commit isn't yet in drm-misc-next.
> Will drm-misc-next merge with 4.17-rcX soon?
For backmerge requests you need to cc/ping the drm-misc maintainers.
Adding them. I think the hold-up also was that Dave was on vacations
still.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
On Tue, Apr 24, 2018 at 02:11:51PM +0200, Daniel Vetter wrote:
> On Mon, Apr 23, 2018 at 12:49:24PM +0200, Gerd Hoffmann wrote:
> > On Tue, Apr 17, 2018 at 07:08:44PM +0530, Souptick Joarder wrote:
> > > Use new return type vm_fault_t for fault handler. For
> > > now, this is just documenting that the function returns
> > > a VM_FAULT value rather than an errno. Once all instances
> > > are converted, vm_fault_t will become a distinct type.
> > >
> > > Reference id -> 1c8f422059ae ("mm: change return type to
> > > vm_fault_t")
> >
> > Hmm, that commit isn't yet in drm-misc-next.
> > Will drm-misc-next merge with 4.17-rcX soon?
>
> For backmerge requests you need to cc/ping the drm-misc maintainers.
> Adding them. I think the hold-up also was that Dave was on vacations
> still.
Ah, ok.
So my expectation that a backmerge happens anyway after -rc1/2 is in
line with reality, it is just to be delayed this time. I'll stay
tuned ;)
cheers,
Gerd
Hi Gerd /Daniel,
On Tue, Apr 24, 2018 at 6:05 PM, Gerd Hoffmann <[email protected]> wrote:
> On Tue, Apr 24, 2018 at 02:11:51PM +0200, Daniel Vetter wrote:
>> On Mon, Apr 23, 2018 at 12:49:24PM +0200, Gerd Hoffmann wrote:
>> > On Tue, Apr 17, 2018 at 07:08:44PM +0530, Souptick Joarder wrote:
>> > > Use new return type vm_fault_t for fault handler. For
>> > > now, this is just documenting that the function returns
>> > > a VM_FAULT value rather than an errno. Once all instances
>> > > are converted, vm_fault_t will become a distinct type.
>> > >
>> > > Reference id -> 1c8f422059ae ("mm: change return type to
>> > > vm_fault_t")
>> >
>> > Hmm, that commit isn't yet in drm-misc-next.
>> > Will drm-misc-next merge with 4.17-rcX soon?
>>
>> For backmerge requests you need to cc/ping the drm-misc maintainers.
>> Adding them. I think the hold-up also was that Dave was on vacations
>> still.
>
> Ah, ok.
>
> So my expectation that a backmerge happens anyway after -rc1/2 is in
> line with reality, it is just to be delayed this time. I'll stay
> tuned ;)
Is this patch already merged in drm-misc-next tree ?
Hi,
> > So my expectation that a backmerge happens anyway after -rc1/2 is in
> > line with reality, it is just to be delayed this time. I'll stay
> > tuned ;)
>
> Is this patch already merged in drm-misc-next tree ?
Pushed now.
cheers,
Gerd
On Mon, May 14, 2018 at 2:32 PM, Gerd Hoffmann <[email protected]> wrote:
> Hi,
>
>> > So my expectation that a backmerge happens anyway after -rc1/2 is in
>> > line with reality, it is just to be delayed this time. I'll stay
>> > tuned ;)
>>
>> Is this patch already merged in drm-misc-next tree ?
>
> Pushed now.
>
Thanks Gerd :)