fbdev: mxc_hdmi: hotplug: lock fb_info before modification

[malsyned]

When an HDMI hotplug interrupt occurs, it schedules hotplug_worker(), which indirectly makes one or more calls to fb_videomode_to_var() that modify the fb_info struct associated with the HDMI connection. These can occur concurrently with the handling of an FBIOPUT_VSCREENINFO ioctl which also reads, modifies, and writes the same fields of fb_info, leading to race conditions.

This patch holds the fb_info lock in mxc_hdmi_cable_connected() while calling mxc_hdmi_set_mode(), eliminating those race conditions.

All of the hogplug handler's calls to fb_videomode_to_var() happen either directly or indirectly from mxc_hdmi_set_mode(), which is called from only one place, in mxc_hdmi_cable_connected(). That seems like the most convenient, least invasive, easiest to get right place to take and release the fb_info lock.

[Oquirella]

Which problems do the race conditions give?

[malsyned]

Sometimes after an fbset I'm seeing this hotplug interrupt fire even though the display hasn't been disconnected and reconnected. It looks like a simulated disconnect/reconnect, since the kernel debug messages are almost exactly 1s apart:

2023-10-30T22:22:51,475334+00:00 mxc_hdmi 20e0000.hdmi_video: Hotplug interrupt received
2023-10-30T22:22:51,504619+00:00 mxc_hdmi 20e0000.hdmi_video: EVENT=plugout
2023-10-30T22:22:51,504974+00:00 mxc_hdmi 20e0000.hdmi_video: Hotplug interrupt received
2023-10-30T22:22:51,544717+00:00 mxc_hdmi 20e0000.hdmi_video: EVENT=plugin

So if the resolution is changed twice back-to-back, sometimes this race condition can happen. In my case, it's happening because I have an ExecStartPre=fbset ... for my weston.service, and then Weston's fbdev driver issues a second resolution change right afterward to triple the size of the virtual display as off-screen buffer.