user/sven/linux.git/include/linux/fb.h, branch v5.3.2

fbcon: Call con2fb_map functions directly

2019-06-12T18:30:39Z

These are actually fbcon ioctls which just happen to be exposed through /dev/fb*. They completely ignore which fb_info they're called on, and I think the userspace tool even hardcodes to /dev/fb0. Hence just forward the entire thing to fbcon.c wholesale. Note that this patch drops the fb_lock/unlock on the set side. Since the ioctl can operate on any fb (as passed in through con2fb.framebuffer) this is bogus. Also note that fbcon.c in general never calls fb_lock on anything, so this has been badly broken already. With this the last user of the fbcon notifier callback is gone, and we can garbage collect that too. v2: add missing uaccess.h include (alpha fails to compile otherwise), reported by kbuild. v3: Remember to also drop the #defines (Maarten) v4: Add the static inline to dummy functions. Signed-off-by: Daniel Vetter Reviewed-by: Sam Ravnborg Reviewed-by: Maarten Lankhorst Cc: Maarten Lankhorst Cc: Daniel Vetter Cc: Bartlomiej Zolnierkiewicz Cc: Hans de Goede Cc: Yisheng Xie Cc: "Michał Mirosław" Cc: Peter Rosin Cc: Mikulas Patocka Link: https://patchwork.freedesktop.org/patch/msgid/20190528090304.9388-31-daniel.vetter@ffwll.ch

vgaswitcheroo: call fbcon_remap_all directly

2019-06-12T18:30:30Z

While at it, clean up the interface a bit and push the console locking into fbcon.c. v2: Remove now outdated comment (Lukas). v3: Forgot to add static inline to the dummy function. Acked-by: Lukas Wunner Signed-off-by: Daniel Vetter Reviewed-by: Sam Ravnborg Reviewed-by: Maarten Lankhorst Cc: Lukas Wunner Cc: David Airlie Cc: Daniel Vetter Cc: Maarten Lankhorst Cc: Maxime Ripard Cc: Sean Paul Cc: Bartlomiej Zolnierkiewicz Cc: Hans de Goede Cc: Yisheng Xie Cc: linux-fbdev@vger.kernel.org Link: https://patchwork.freedesktop.org/patch/msgid/20190528090304.9388-30-daniel.vetter@ffwll.ch

fbcon: replace FB_EVENT_MODE_CHANGE/_ALL with direct calls

2019-06-12T18:30:21Z

Create a new wrapper function for this, feels like there's some refactoring room here between the two modes. v2: backlight notifier is also interested in the mode change event, it calls lcd->set_mode, of which there are 3 implementations. Thanks to Maarten for spotting this. So we keep that. We can ditch the differentiation between mode change and all mode changes (because backlight notifier doesn't care), and we can drop the FBINFO_MISC_USEREVENT stuff too, because that's just to prevent recursion between fbmem.c and fbcon.c. While at it flatten the control flow a bit. v3: Need to add a static inline to the dummy function. v4: Add missing #include to sh_mob (Sam). Cc: Sam Ravnborg Signed-off-by: Daniel Vetter Reviewed-by: Sam Ravnborg Reviewed-by: Maarten Lankhorst Acked-by: Daniel Thompson Cc: Maarten Lankhorst Cc: Lee Jones Cc: Daniel Thompson Cc: Jingoo Han Cc: Bartlomiej Zolnierkiewicz Cc: Daniel Vetter Cc: Hans de Goede Cc: Yisheng Xie Cc: "Michał Mirosław" Cc: Peter Rosin Cc: Mikulas Patocka Cc: linux-fbdev@vger.kernel.org Link: https://patchwork.freedesktop.org/patch/msgid/20190528090304.9388-29-daniel.vetter@ffwll.ch

Revert "backlight/fbcon: Add FB_EVENT_CONBLANK"

2019-06-12T18:29:40Z

This reverts commit 994efacdf9a087b52f71e620b58dfa526b0cf928. The justification is that if hw blanking fails (i.e. fbops->fb_blank) fails, then we still want to shut down the backlight. Which is exactly _not_ what fb_blank() does and so rather inconsistent if we end up with different behaviour between fbcon and direct fbdev usage. Given that the entire notifier maze is getting in the way anyway I figured it's simplest to revert this not well justified commit. v2: Add static inline to the dummy version. Cc: Richard Purdie Signed-off-by: Daniel Vetter Reviewed-by: Sam Ravnborg Reviewed-by: Maarten Lankhorst Acked-by: Daniel Thompson Cc: Lee Jones Cc: Daniel Thompson Cc: Jingoo Han Cc: Bartlomiej Zolnierkiewicz Cc: Daniel Vetter Cc: Hans de Goede Cc: Yisheng Xie Cc: linux-fbdev@vger.kernel.org Link: https://patchwork.freedesktop.org/patch/msgid/20190528090304.9388-25-daniel.vetter@ffwll.ch

fbdev: Call fbcon_get_requirement directly

2019-06-12T18:29:22Z

Pretty simple case really. v2: Forgot to remove a break; v3: Add static inline to the dummy versions. Signed-off-by: Daniel Vetter Reviewed-by: Sam Ravnborg Reviewed-by: Maarten Lankhorst Cc: Bartlomiej Zolnierkiewicz Cc: Daniel Vetter Cc: Hans de Goede Cc: "Steven Rostedt (VMware)" Cc: Prarit Bhargava Cc: Kees Cook Cc: Yisheng Xie Cc: "Michał Mirosław" Cc: Peter Rosin Cc: Mikulas Patocka Cc: linux-fbdev@vger.kernel.org Link: https://patchwork.freedesktop.org/patch/msgid/20190528090304.9388-24-daniel.vetter@ffwll.ch

fbcon: Call fbcon_mode_deleted/new_modelist directly

2019-06-12T18:29:16Z

I'm not entirely clear on what new_modelist actually does, it seems exclusively for a sysfs interface. Which in the end does amount to a normal fb_set_par to check the mode, but then takes a different path in both fbmem.c and fbcon.c. I have no idea why these 2 paths are different, but then I also don't really want to find out. So just do the simple conversion to a direct function call. v2: static inline for the dummy versions, I forgot. Signed-off-by: Daniel Vetter Reviewed-by: Sam Ravnborg Reviewed-by: Maarten Lankhorst Cc: Bartlomiej Zolnierkiewicz Cc: Daniel Vetter Cc: Hans de Goede Cc: Mikulas Patocka Cc: Sergey Senozhatsky Cc: Kees Cook Cc: Peter Rosin Cc: Yisheng Xie Cc: "Michał Mirosław" Cc: linux-fbdev@vger.kernel.org Link: https://patchwork.freedesktop.org/patch/msgid/20190528090304.9388-23-daniel.vetter@ffwll.ch

fbdev: directly call fbcon_suspended/resumed

2019-06-12T18:29:10Z

With the sh_mobile notifier removed we can just directly call the fbcon code here. v2: Remove now unused local variable. v3: fixup !CONFIG_FRAMEBUFFER_CONSOLE, noticed by kbuild Signed-off-by: Daniel Vetter Reviewed-by: Sam Ravnborg Reviewed-by: Maarten Lankhorst Cc: Bartlomiej Zolnierkiewicz Cc: Daniel Vetter Cc: Hans de Goede Cc: Greg Kroah-Hartman Cc: Prarit Bhargava Cc: Kees Cook Cc: Konstantin Khorenko Cc: Yisheng Xie Cc: "Michał Mirosław" Cc: Peter Rosin Cc: Mikulas Patocka Cc: linux-fbdev@vger.kernel.org Link: https://patchwork.freedesktop.org/patch/msgid/20190528090304.9388-22-daniel.vetter@ffwll.ch

fbdev: make unregister/unlink functions not fail

2019-06-12T18:28:52Z

Except for driver bugs (which we'll catch with a WARN_ON) this is only to report failures of the new driver taking over the console. There's nothing the outgoing driver can do about that, and no one ever bothered to actually look at these return values. So remove them all. v2: fixup unregister_framebuffer in savagefb, fbtft, ivtvfb, and neofb drivers, reported by kbuild. Signed-off-by: Daniel Vetter Reviewed-by: Sam Ravnborg Reviewed-by: Maarten Lankhorst Cc: Bartlomiej Zolnierkiewicz Cc: Daniel Vetter Cc: "Michał Mirosław" Cc: Peter Rosin Cc: Hans de Goede Cc: Mikulas Patocka Cc: linux-fbdev@vger.kernel.org Link: https://patchwork.freedesktop.org/patch/msgid/20190528090304.9388-19-daniel.vetter@ffwll.ch

fbcon: call fbcon_fb_bind directly

2019-06-12T18:28:45Z

Also remove the error return value. That's all errors for either driver bugs (trying to unbind something that isn't bound), or errors of the new driver that will take over. There's nothing the outgoing driver can do about this anyway, so switch over to void. Signed-off-by: Daniel Vetter Reviewed-by: Sam Ravnborg Reviewed-by: Maarten Lankhorst Cc: Bartlomiej Zolnierkiewicz Cc: Daniel Vetter Cc: Hans de Goede Cc: Sergey Senozhatsky Cc: Peter Rosin Cc: Kees Cook Cc: Konstantin Khorenko Cc: Yisheng Xie Cc: "Michał Mirosław" Cc: Mikulas Patocka Cc: Thomas Zimmermann Cc: linux-fbdev@vger.kernel.org Link: https://patchwork.freedesktop.org/patch/msgid/20190528090304.9388-18-daniel.vetter@ffwll.ch

fbdev: lock_fb_info cannot fail

2019-06-12T18:28:38Z

Ever since commit c47747fde931c02455683bd00ea43eaa62f35b0e Author: Linus Torvalds Date: Wed May 11 14:58:34 2011 -0700 fbmem: make read/write/ioctl use the frame buffer at open time fbdev has gained proper refcounting for the fbinfo attached to any open files, which means that the backing driver (stored in fb_info->fbops) cannot untimely disappear anymore. The only thing that can happen is that the entire device just outright disappears and gets unregistered, but file_fb_info does check for that. Except that it's racy - it only checks once at the start of a file_ops, there's no guarantee that the underlying fbdev won't untimely disappear. Aside: A proper way to fix that race is probably to replicate the srcu trickery we've rolled out in drm. But given that this race has existed since forever it's probably not one we need to fix right away. do_unregister_framebuffer also nowhere clears fb_info->fbops, hence the check in lock_fb_info can't possible catch a disappearing fbdev later on. Long story short: Ever since the above commit the fb_info->fbops checks have essentially become dead code. Remove this all. Aside from the file_ops callbacks, and stuff called from there there's only register/unregister code left. If that goes wrong a driver managed to register/unregister a device instance twice or in the wrong order. That's just a driver bug. v2: - fb_mmap had an open-coded version of the fbinfo->fops check, because it doesn't need the fbinfo->lock. Delete that too. - Use the wrapper function in fb_open/release now, since no difference anymore. Signed-off-by: Daniel Vetter Reviewed-by: Sam Ravnborg Reviewed-by: Maarten Lankhorst Cc: Bartlomiej Zolnierkiewicz Cc: Daniel Vetter Cc: Hans de Goede Cc: Yisheng Xie Cc: Sergey Senozhatsky Cc: "Noralf Trønnes" Cc: Peter Rosin Cc: "Michał Mirosław" Cc: Mikulas Patocka Cc: "Gustavo A. R. Silva" Cc: linux-fbdev@vger.kernel.org Link: https://patchwork.freedesktop.org/patch/msgid/20190528090304.9388-17-daniel.vetter@ffwll.ch