<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/drivers/video/fbdev/via, branch linux-6.9.y</title>
<subtitle>Hosts the 0x221E linux distro kernel.</subtitle>
<id>https://universe.0xinfinity.dev/distro/kernel/atom?h=linux-6.9.y</id>
<link rel='self' href='https://universe.0xinfinity.dev/distro/kernel/atom?h=linux-6.9.y'/>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/'/>
<updated>2024-03-15T09:05:35Z</updated>
<entry>
<title>fbdev: viafb: fix typo in hw_bitblt_1 and hw_bitblt_2</title>
<updated>2024-03-15T09:05:35Z</updated>
<author>
<name>Aleksandr Burakov</name>
<email>a.burakov@rosalinux.ru</email>
</author>
<published>2024-03-01T11:35:43Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=bc87bb342f106a0402186bcb588fcbe945dced4b'/>
<id>urn:sha1:bc87bb342f106a0402186bcb588fcbe945dced4b</id>
<content type='text'>
There are some actions with value 'tmp' but 'dst_addr' is checked instead.
It is obvious that a copy-paste error was made here and the value
of variable 'tmp' should be checked here.

Found by Linux Verification Center (linuxtesting.org) with SVACE.

Signed-off-by: Aleksandr Burakov &lt;a.burakov@rosalinux.ru&gt;
Signed-off-by: Helge Deller &lt;deller@gmx.de&gt;
</content>
</entry>
<entry>
<title>fbdev: remove I2C_CLASS_DDC support</title>
<updated>2024-01-18T20:10:41Z</updated>
<author>
<name>Heiner Kallweit</name>
<email>hkallweit1@gmail.com</email>
</author>
<published>2023-11-23T09:40:25Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=754bd2fffc913e523d1b9e686e8b1fd3a70d8f7e'/>
<id>urn:sha1:754bd2fffc913e523d1b9e686e8b1fd3a70d8f7e</id>
<content type='text'>
After removal of the legacy EEPROM driver and I2C_CLASS_DDC support in
olpc_dcon there's no i2c client driver left supporting I2C_CLASS_DDC.
Class-based device auto-detection is a legacy mechanism and shouldn't
be used in new code. So we can remove this class completely now.

Acked-by: Helge Deller &lt;deller@gmx.de&gt;
Acked-by: Thomas Zimmermann &lt;tzimmermann@suse.de&gt;
Signed-off-by: Heiner Kallweit &lt;hkallweit1@gmail.com&gt;
Signed-off-by: Wolfram Sang &lt;wsa@kernel.org&gt;
</content>
</entry>
<entry>
<title>fbdev: viafb: use new array-copying-wrapper</title>
<updated>2023-11-07T13:42:34Z</updated>
<author>
<name>Philipp Stanner</name>
<email>pstanner@redhat.com</email>
</author>
<published>2023-11-02T19:24:03Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=3e91a38de1dce97b385d732a5f444264ea8fbd92'/>
<id>urn:sha1:3e91a38de1dce97b385d732a5f444264ea8fbd92</id>
<content type='text'>
viafbdev.c utilizes memdup_user() to copy an array from userspace.

There is a new wrapper, specifically designed for copying arrays. Use
this one instead.

Suggested-by: Dave Airlie &lt;airlied@redhat.com&gt;
Signed-off-by: Philipp Stanner &lt;pstanner@redhat.com&gt;
Signed-off-by: Helge Deller &lt;deller@gmx.de&gt;
</content>
</entry>
<entry>
<title>fbdev/viafb: Initialize fb_ops to fbdev I/O-memory helpers</title>
<updated>2023-10-19T10:57:18Z</updated>
<author>
<name>Thomas Zimmermann</name>
<email>tzimmermann@suse.de</email>
</author>
<published>2023-09-27T07:27:18Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=fb159df356d82db2ddb8658802bd1749480c0194'/>
<id>urn:sha1:fb159df356d82db2ddb8658802bd1749480c0194</id>
<content type='text'>
Initialize the instance of struct fb_ops with fbdev initializer
macros for framebuffers in I/O address space. Set the read/write,
draw and mmap callbacks to the correct implementation and avoid
implicit defaults. Also select the necessary I/O helpers in Kconfig.

Fbdev drivers sometimes rely on the callbacks being NULL for a
default implementation to be invoked; hence requiring the I/O
helpers to be built in any case. Setting all callbacks in all
drivers explicitly will allow to make the I/O helpers optional.
This benefits systems that do not use these functions.

No functional changes.

Signed-off-by: Thomas Zimmermann &lt;tzimmermann@suse.de&gt;
Acked-by: Javier Martinez Canillas &lt;javierm@redhat.com&gt;
Cc: Florian Tobias Schandinat &lt;FlorianSchandinat@gmx.de&gt;
Link: https://patchwork.freedesktop.org/patch/msgid/20230927074722.6197-46-tzimmermann@suse.de
</content>
</entry>
<entry>
<title>fbdev: Remove FBINFO_DEFAULT from framebuffer_alloc()'ed structs</title>
<updated>2023-07-24T14:50:38Z</updated>
<author>
<name>Thomas Zimmermann</name>
<email>tzimmermann@suse.de</email>
</author>
<published>2023-07-15T18:51:47Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=b3e148d730b7255dfcfb080c8633146e44b83b0c'/>
<id>urn:sha1:b3e148d730b7255dfcfb080c8633146e44b83b0c</id>
<content type='text'>
The flag FBINFO_DEFAULT is 0 and has no effect, as struct fbinfo.flags
has been allocated to zero by framebuffer_alloc(). So do not set it.

Flags should signal differences from the default values. After cleaning
up all occurrences of FBINFO_DEFAULT, the token will be removed.

v4:
	* clarify commit message (Geert, Dan)
v2:
	* fix commit message (Miguel)

Signed-off-by: Thomas Zimmermann &lt;tzimmermann@suse.de&gt;
Acked-by: Sam Ravnborg &lt;sam@ravnborg.org&gt;
Cc: Helge Deller &lt;deller@gmx.de&gt;
Cc: Nicolas Ferre &lt;nicolas.ferre@microchip.com&gt;
Cc: Benjamin Herrenschmidt &lt;benh@kernel.crashing.org&gt;
Cc: Ferenc Bakonyi &lt;fero@drama.obuda.kando.hu&gt;
Cc: "K. Y. Srinivasan" &lt;kys@microsoft.com&gt;
Cc: Haiyang Zhang &lt;haiyangz@microsoft.com&gt;
Cc: Wei Liu &lt;wei.liu@kernel.org&gt;
Cc: Dexuan Cui &lt;decui@microsoft.com&gt;
Cc: Antonino Daplas &lt;adaplas@gmail.com&gt;
Cc: Maik Broemme &lt;mbroemme@libmpq.org&gt;
Cc: Michael Ellerman &lt;mpe@ellerman.id.au&gt;
Cc: Nicholas Piggin &lt;npiggin@gmail.com&gt;
Cc: Christophe Leroy &lt;christophe.leroy@csgroup.eu&gt;
Cc: Kristoffer Ericson &lt;kristoffer.ericson@gmail.com&gt;
Cc: Hans de Goede &lt;hdegoede@redhat.com&gt;
Cc: Steve Glendinning &lt;steve.glendinning@shawell.net&gt;
Cc: Bernie Thompson &lt;bernie@plugable.com&gt;
Cc: Florian Tobias Schandinat &lt;FlorianSchandinat@gmx.de&gt;
Link: https://patchwork.freedesktop.org/patch/msgid/20230715185343.7193-6-tzimmermann@suse.de
</content>
</entry>
<entry>
<title>fbdev/media: Use GPIO descriptors for VIA GPIO</title>
<updated>2023-06-19T07:02:51Z</updated>
<author>
<name>Linus Walleij</name>
<email>linus.walleij@linaro.org</email>
</author>
<published>2023-06-13T06:33:14Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=d4313a68ec913f2705b337e2d332813a72cb2de9'/>
<id>urn:sha1:d4313a68ec913f2705b337e2d332813a72cb2de9</id>
<content type='text'>
The VIA fbdev exposes a custom GPIO chip for its GPIOs, these
are in turn looked up the camera driver using a custom API.

Drop the custom API, provide a look-up table and convert to
GPIO descriptors. Note proper polarity on the RESET line.

Cc: Jonathan Corbet &lt;corbet@lwn.net&gt;
Signed-off-by: Linus Walleij &lt;linus.walleij@linaro.org&gt;
Signed-off-by: Helge Deller &lt;deller@gmx.de&gt;
</content>
</entry>
<entry>
<title>fbdev: via: Convert to platform remove callback returning void</title>
<updated>2023-04-24T09:48:33Z</updated>
<author>
<name>Uwe Kleine-König</name>
<email>u.kleine-koenig@pengutronix.de</email>
</author>
<published>2023-03-18T23:54:24Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=87b1e9a57445e4ee38cf1c03c203c82d5dda6aa3'/>
<id>urn:sha1:87b1e9a57445e4ee38cf1c03c203c82d5dda6aa3</id>
<content type='text'>
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is (mostly) ignored
and this typically results in resource leaks. To improve here there is a
quest to make the remove callback return void. In the first step of this
quest all drivers are converted to .remove_new() which already returns
void.

Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.

Signed-off-by: Uwe Kleine-König &lt;u.kleine-koenig@pengutronix.de&gt;
Signed-off-by: Helge Deller &lt;deller@gmx.de&gt;
</content>
</entry>
<entry>
<title>fbdev: via: Fix error in via_core_init()</title>
<updated>2022-12-14T19:01:50Z</updated>
<author>
<name>Shang XiaoJing</name>
<email>shangxiaojing@huawei.com</email>
</author>
<published>2022-11-14T01:08:52Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=5886b130de953cfb8826f7771ec8640a79934a7f'/>
<id>urn:sha1:5886b130de953cfb8826f7771ec8640a79934a7f</id>
<content type='text'>
via_core_init() won't exit the driver when pci_register_driver() failed.
Exit the viafb-i2c and the viafb-gpio in failed path to prevent error.

VIA Graphics Integration Chipset framebuffer 2.4 initializing
Error: Driver 'viafb-i2c' is already registered, aborting...
Error: Driver 'viafb-gpio' is already registered, aborting...

Fixes: 7582eb9be85f ("viafb: Turn GPIO and i2c into proper platform devices")
Signed-off-by: Shang XiaoJing &lt;shangxiaojing@huawei.com&gt;
Signed-off-by: Helge Deller &lt;deller@gmx.de&gt;
</content>
</entry>
<entry>
<title>fbdev: Add support for the nomodeset kernel parameter</title>
<updated>2022-11-16T12:26:25Z</updated>
<author>
<name>Thomas Zimmermann</name>
<email>tzimmermann@suse.de</email>
</author>
<published>2022-11-11T13:30:24Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=0ba2fa8cbd29278a180ac90bd66b2c0bbdeacc89'/>
<id>urn:sha1:0ba2fa8cbd29278a180ac90bd66b2c0bbdeacc89</id>
<content type='text'>
Support the kernel's nomodeset parameter for all PCI-based fbdev
drivers that use aperture helpers to remove other, hardware-agnostic
graphics drivers.

The parameter is a simple way of using the firmware-provided scanout
buffer if the hardware's native driver is broken. The same effect
could be achieved with per-driver options, but the importance of the
graphics output for many users makes a single, unified approach
worthwhile.

With nomodeset specified, the fbdev driver module will not load. This
unifies behavior with similar DRM drivers. In DRM helpers, modules
first check the nomodeset parameter before registering the PCI
driver. As fbdev has no such module helpers, we have to modify each
driver individually.

The name 'nomodeset' is slightly misleading, but has been chosen for
historical reasons. Several drivers implemented it before it became a
general option for DRM. So keeping the existing name was preferred over
introducing a new one.

v2:
	* print a warning if a driver does not init (Helge)
	* wrap video_firmware_drivers_only() in helper

Signed-off-by: Thomas Zimmermann &lt;tzimmermann@suse.de&gt;
Reviewed-by: Javier Martinez Canillas &lt;javierm@redhat.com&gt;
Link: https://patchwork.freedesktop.org/patch/msgid/20221111133024.9897-3-tzimmermann@suse.de
</content>
</entry>
<entry>
<title>fbdev: Remove conflicting devices on PCI bus</title>
<updated>2022-07-19T11:19:11Z</updated>
<author>
<name>Thomas Zimmermann</name>
<email>tzimmermann@suse.de</email>
</author>
<published>2022-07-18T07:23:17Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=145eed48de278007f646b908fd70ac59d24ed81a'/>
<id>urn:sha1:145eed48de278007f646b908fd70ac59d24ed81a</id>
<content type='text'>
Remove firmware devices on the PCI bus, by calling
aperture_remove_conflicting_pci_devices() in the probe function of
each related fbdev driver. iSo far, most of these drivers did not
remove conflicting VESA or EFI devices, or outride failed for
resource conflicts (i.e., matroxfb.) This must have been broken
for quite some time.

Signed-off-by: Thomas Zimmermann &lt;tzimmermann@suse.de&gt;
Reviewed-by: Javier Martinez Canillas &lt;javierm@redhat.com&gt;
Link: https://patchwork.freedesktop.org/patch/msgid/20220718072322.8927-7-tzimmermann@suse.de
</content>
</entry>
</feed>
