| Message ID | 94a33cf0a587e803bcadcf80e8152eac9b196f34.1575022735.git.jani.nikula@intel.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | video, drm, etc: constify fbops in struct fb_info | expand |
On Fri, Nov 29, 2019 at 12:29:44PM +0200, Jani Nikula wrote: > Now that the fbops member of struct fb_info is const, we can start > making the ops const as well. > > Cc: Miguel Ojeda Sandonis <miguel.ojeda.sandonis@gmail.com> > Cc: Robin van der Gracht <robin@protonic.nl> > Signed-off-by: Jani Nikula <jani.nikula@intel.com> > --- > drivers/auxdisplay/cfag12864bfb.c | 2 +- > drivers/auxdisplay/ht16k33.c | 2 +- > 2 files changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/auxdisplay/cfag12864bfb.c b/drivers/auxdisplay/cfag12864bfb.c > index 4074886b7bc8..2002291ab338 100644 > --- a/drivers/auxdisplay/cfag12864bfb.c > +++ b/drivers/auxdisplay/cfag12864bfb.c Oh, another display subsystem? Intriguing ... Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> > @@ -57,7 +57,7 @@ static int cfag12864bfb_mmap(struct fb_info *info, struct vm_area_struct *vma) > return vm_map_pages_zero(vma, &pages, 1); > } > > -static struct fb_ops cfag12864bfb_ops = { > +static const struct fb_ops cfag12864bfb_ops = { > .owner = THIS_MODULE, > .fb_read = fb_sys_read, > .fb_write = fb_sys_write, > diff --git a/drivers/auxdisplay/ht16k33.c b/drivers/auxdisplay/ht16k33.c > index a2fcde582e2a..d951d54b26f5 100644 > --- a/drivers/auxdisplay/ht16k33.c > +++ b/drivers/auxdisplay/ht16k33.c > @@ -228,7 +228,7 @@ static int ht16k33_mmap(struct fb_info *info, struct vm_area_struct *vma) > return vm_map_pages_zero(vma, &pages, 1); > } > > -static struct fb_ops ht16k33_fb_ops = { > +static const struct fb_ops ht16k33_fb_ops = { > .owner = THIS_MODULE, > .fb_read = fb_sys_read, > .fb_write = fb_sys_write, > -- > 2.20.1 > > _______________________________________________ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel
On Fri, Nov 29, 2019 at 4:24 PM Daniel Vetter <daniel@ffwll.ch> wrote: > > Oh, another display subsystem? Intriguing ... > > Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> It is intended for displays that are not intended as the usual/main display, e.g. very small LCDs :) Reviewed-by: Miguel Ojeda <miguel.ojeda.sandonis@gmail.com> Cheers, Miguel
On Fri, Nov 29, 2019 at 09:16:42PM +0100, Miguel Ojeda wrote: > On Fri, Nov 29, 2019 at 4:24 PM Daniel Vetter <daniel@ffwll.ch> wrote: > > > > Oh, another display subsystem? Intriguing ... > > > > Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> > > It is intended for displays that are not intended as the usual/main > display, e.g. very small LCDs :) Well we do have very small lcd display drivers in drm, and before that in fbdev. And you have a fbdev framebuffer driver in there, which looks a bit misplaced ... Afaiui you also have some even tinier lcd drivers where you don't address pixels, but just directly upload text, and those obviously don't fit into drm/fbdev world. But anything where you can address pixels very much does. -Daniel > > Reviewed-by: Miguel Ojeda <miguel.ojeda.sandonis@gmail.com> > > Cheers, > Miguel
On Fri, Nov 29, 2019 at 9:30 PM Daniel Vetter <daniel@ffwll.ch> wrote: > > Well we do have very small lcd display drivers in drm, and before that in > fbdev. And you have a fbdev framebuffer driver in there, which looks a bit > misplaced ... > > Afaiui you also have some even tinier lcd drivers where you don't address > pixels, but just directly upload text, and those obviously don't fit into > drm/fbdev world. But anything where you can address pixels very much does. > -Daniel The first driver in the category used fb.h. At the time (~13 years ago) it was decided that the drivers should go into a different category/folder instead and then the other were added. In any case, I am removing the original ones since I cannot test them anymore and there are likely no user. The only other fb user could be relocated if Robin agrees. Cheers, Miguel
On 2019-11-29 11:29, Jani Nikula wrote: > Now that the fbops member of struct fb_info is const, we can start > making the ops const as well. > > Cc: Miguel Ojeda Sandonis <miguel.ojeda.sandonis@gmail.com> > Cc: Robin van der Gracht <robin@protonic.nl> > Signed-off-by: Jani Nikula <jani.nikula@intel.com> > --- > drivers/auxdisplay/cfag12864bfb.c | 2 +- > drivers/auxdisplay/ht16k33.c | 2 +- > 2 files changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/auxdisplay/cfag12864bfb.c > b/drivers/auxdisplay/cfag12864bfb.c > index 4074886b7bc8..2002291ab338 100644 > --- a/drivers/auxdisplay/cfag12864bfb.c > +++ b/drivers/auxdisplay/cfag12864bfb.c > @@ -57,7 +57,7 @@ static int cfag12864bfb_mmap(struct fb_info *info, > struct vm_area_struct *vma) > return vm_map_pages_zero(vma, &pages, 1); > } > > -static struct fb_ops cfag12864bfb_ops = { > +static const struct fb_ops cfag12864bfb_ops = { > .owner = THIS_MODULE, > .fb_read = fb_sys_read, > .fb_write = fb_sys_write, > diff --git a/drivers/auxdisplay/ht16k33.c > b/drivers/auxdisplay/ht16k33.c > index a2fcde582e2a..d951d54b26f5 100644 > --- a/drivers/auxdisplay/ht16k33.c > +++ b/drivers/auxdisplay/ht16k33.c > @@ -228,7 +228,7 @@ static int ht16k33_mmap(struct fb_info *info, > struct vm_area_struct *vma) > return vm_map_pages_zero(vma, &pages, 1); > } > > -static struct fb_ops ht16k33_fb_ops = { > +static const struct fb_ops ht16k33_fb_ops = { > .owner = THIS_MODULE, > .fb_read = fb_sys_read, > .fb_write = fb_sys_write, Acked-by: Robin van der Gracht <robin@protonic.nl>
On 2019-11-29 21:59, Miguel Ojeda wrote: > On Fri, Nov 29, 2019 at 9:30 PM Daniel Vetter <daniel@ffwll.ch> wrote: >> >> Well we do have very small lcd display drivers in drm, and before that >> in >> fbdev. And you have a fbdev framebuffer driver in there, which looks a >> bit >> misplaced ... >> >> Afaiui you also have some even tinier lcd drivers where you don't >> address >> pixels, but just directly upload text, and those obviously don't fit >> into >> drm/fbdev world. But anything where you can address pixels very much >> does. >> -Daniel > > The first driver in the category used fb.h. At the time (~13 years > ago) it was decided that the drivers should go into a different > category/folder instead and then the other were added. > > In any case, I am removing the original ones since I cannot test them > anymore and there are likely no user. The only other fb user could be > relocated if Robin agrees. The ht16k33 driver registers a framebuffer, backlight and input device. Not sure if it's OK to let a driver under fbdev register all of those, but relocating it is fine by me. Robin
diff --git a/drivers/auxdisplay/cfag12864bfb.c b/drivers/auxdisplay/cfag12864bfb.c index 4074886b7bc8..2002291ab338 100644 --- a/drivers/auxdisplay/cfag12864bfb.c +++ b/drivers/auxdisplay/cfag12864bfb.c @@ -57,7 +57,7 @@ static int cfag12864bfb_mmap(struct fb_info *info, struct vm_area_struct *vma) return vm_map_pages_zero(vma, &pages, 1); } -static struct fb_ops cfag12864bfb_ops = { +static const struct fb_ops cfag12864bfb_ops = { .owner = THIS_MODULE, .fb_read = fb_sys_read, .fb_write = fb_sys_write, diff --git a/drivers/auxdisplay/ht16k33.c b/drivers/auxdisplay/ht16k33.c index a2fcde582e2a..d951d54b26f5 100644 --- a/drivers/auxdisplay/ht16k33.c +++ b/drivers/auxdisplay/ht16k33.c @@ -228,7 +228,7 @@ static int ht16k33_mmap(struct fb_info *info, struct vm_area_struct *vma) return vm_map_pages_zero(vma, &pages, 1); } -static struct fb_ops ht16k33_fb_ops = { +static const struct fb_ops ht16k33_fb_ops = { .owner = THIS_MODULE, .fb_read = fb_sys_read, .fb_write = fb_sys_write,
Now that the fbops member of struct fb_info is const, we can start making the ops const as well. Cc: Miguel Ojeda Sandonis <miguel.ojeda.sandonis@gmail.com> Cc: Robin van der Gracht <robin@protonic.nl> Signed-off-by: Jani Nikula <jani.nikula@intel.com> --- drivers/auxdisplay/cfag12864bfb.c | 2 +- drivers/auxdisplay/ht16k33.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-)