<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux/drivers/video/fbdev/nvidia, branch v6.3</title>
<subtitle>Mirror of https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/
</subtitle>
<id>https://git.shady.money/linux/atom?h=v6.3</id>
<link rel='self' href='https://git.shady.money/linux/atom?h=v6.3'/>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/'/>
<updated>2023-03-16T15:18:16Z</updated>
<entry>
<title>fbdev: nvidia: Fix potential divide by zero</title>
<updated>2023-03-16T15:18:16Z</updated>
<author>
<name>Wei Chen</name>
<email>harperchen1110@gmail.com</email>
</author>
<published>2023-03-15T07:18:31Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=92e2a00f2987483e1f9253625828622edd442e61'/>
<id>urn:sha1:92e2a00f2987483e1f9253625828622edd442e61</id>
<content type='text'>
variable var-&gt;pixclock can be set by user. In case it
equals to zero, divide by zero would occur in nvidiafb_set_par.

Similar crashes have happened in other fbdev drivers. There
is no check and modification on var-&gt;pixclock along the call
chain to nvidia_check_var and nvidiafb_set_par. We believe it
could also be triggered in driver nvidia from user site.

Signed-off-by: Wei Chen &lt;harperchen1110@gmail.com&gt;
Signed-off-by: Helge Deller &lt;deller@gmx.de&gt;
</content>
</entry>
<entry>
<title>nvidiafb: detect the hardware support before removing console.</title>
<updated>2023-02-06T22:42:29Z</updated>
<author>
<name>Dave Airlie</name>
<email>airlied@redhat.com</email>
</author>
<published>2023-02-05T21:05:28Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=04119ab1a49fc41cb70f0472be5455af268fa260'/>
<id>urn:sha1:04119ab1a49fc41cb70f0472be5455af268fa260</id>
<content type='text'>
This driver removed the console, but hasn't yet decided if it could
take over the console yet. Instead of doing that, probe the hw for
support and then remove the console afterwards.

Link: https://bugzilla.kernel.org/show_bug.cgi?id=216859
Fixes: 145eed48de27 ("fbdev: Remove conflicting devices on PCI bus")
Reported-by: Zeno Davatz &lt;zdavatz@gmail.com&gt;
Tested-by: Zeno Davatz &lt;zdavatz@gmail.com&gt;
Tested-by: Thomas Zimmermann &lt;tzimmermann@suse.de&gt;
Reviewed-by: Thomas Zimmermann &lt;tzimmermann@suse.de&gt;
Signed-off-by: Dave Airlie &lt;airlied@redhat.com&gt;
Link: https://patchwork.freedesktop.org/patch/msgid/20230205210751.3842103-1-airlied@gmail.com
</content>
</entry>
<entry>
<title>fbdev: nvidia: Use backlight helper</title>
<updated>2023-01-09T08:57:51Z</updated>
<author>
<name>Stephen Kitt</name>
<email>steve@sk2.org</email>
</author>
<published>2022-06-07T19:23:33Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=1cc17590ddfec590d7301f5e4cf6183ea19afa25'/>
<id>urn:sha1:1cc17590ddfec590d7301f5e4cf6183ea19afa25</id>
<content type='text'>
Instead of retrieving the backlight brightness in struct
backlight_properties manually, and then checking whether the backlight
should be on at all, use backlight_get_brightness() which does all
this and insulates this from future changes.

Signed-off-by: Stephen Kitt &lt;steve@sk2.org&gt;
Cc: Antonino Daplas &lt;adaplas@gmail.com&gt;
Cc: Helge Deller &lt;deller@gmx.de&gt;
Cc: linux-fbdev@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Reviewed-by: Daniel Thompson &lt;daniel.thompson@linaro.org&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://git.shady.money/linux/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://git.shady.money/linux/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>
<entry>
<title>video: fbdev: nvidiafb: Use strscpy() to prevent buffer overflow</title>
<updated>2022-01-29T21:24:25Z</updated>
<author>
<name>Tim Gardner</name>
<email>tim.gardner@canonical.com</email>
</author>
<published>2021-09-27T15:45:02Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=37a1a2e6eeeb101285cd34e12e48a881524701aa'/>
<id>urn:sha1:37a1a2e6eeeb101285cd34e12e48a881524701aa</id>
<content type='text'>
Coverity complains of a possible buffer overflow. However,
given the 'static' scope of nvidia_setup_i2c_bus() it looks
like that can't happen after examiniing the call sites.

CID 19036 (#1 of 1): Copy into fixed size buffer (STRING_OVERFLOW)
1. fixed_size_dest: You might overrun the 48-character fixed-size string
  chan-&gt;adapter.name by copying name without checking the length.
2. parameter_as_source: Note: This defect has an elevated risk because the
  source argument is a parameter of the current function.
 89        strcpy(chan-&gt;adapter.name, name);

Fix this warning by using strscpy() which will silence the warning and
prevent any future buffer overflows should the names used to identify the
channel become much longer.

Cc: Antonino Daplas &lt;adaplas@gmail.com&gt;
Cc: linux-fbdev@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Tim Gardner &lt;tim.gardner@canonical.com&gt;
Signed-off-by: Helge Deller &lt;deller@gmx.de&gt;
</content>
</entry>
<entry>
<title>video: fbdev: nvidia: Fix set but not used warnings</title>
<updated>2020-11-30T19:21:54Z</updated>
<author>
<name>Sam Ravnborg</name>
<email>sam@ravnborg.org</email>
</author>
<published>2020-11-28T22:41:06Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=025ae8255d3390e5d22c42f380e60080366272fc'/>
<id>urn:sha1:025ae8255d3390e5d22c42f380e60080366272fc</id>
<content type='text'>
Fix warnings by deleting unused code. The register reads are
kept as it is unknown if there are any hidden side-effects.

v2:
  - Update subject (Lee)

Signed-off-by: Sam Ravnborg &lt;sam@ravnborg.org&gt;
Acked-by: Thomas Zimmermann &lt;tzimmermann@suse.de&gt;
Cc: Antonino Daplas &lt;adaplas@gmail.com&gt;
Cc: linux-fbdev@vger.kernel.org
Cc: Lee Jones &lt;lee.jones@linaro.org&gt;
Link: https://patchwork.freedesktop.org/patch/msgid/20201128224114.1033617-21-sam@ravnborg.org
</content>
</entry>
<entry>
<title>fbdev: nvidia: use for_each_child_of_node() macro</title>
<updated>2020-10-16T21:43:41Z</updated>
<author>
<name>Qinglang Miao</name>
<email>miaoqinglang@huawei.com</email>
</author>
<published>2020-09-16T06:21:23Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=3da1781ea458f658e6089c1cc471016a72fb81cf'/>
<id>urn:sha1:3da1781ea458f658e6089c1cc471016a72fb81cf</id>
<content type='text'>
Use for_each_child_of_node() macro instead of open coding it.

Signed-off-by: Qinglang Miao &lt;miaoqinglang@huawei.com&gt;
Signed-off-by: Sam Ravnborg &lt;sam@ravnborg.org&gt;
Link: https://patchwork.freedesktop.org/patch/msgid/20200916062123.190636-1-miaoqinglang@huawei.com
</content>
</entry>
<entry>
<title>Merge drm/drm-next into drm-misc-next</title>
<updated>2020-09-14T16:11:40Z</updated>
<author>
<name>Maxime Ripard</name>
<email>maxime@cerno.tech</email>
</author>
<published>2020-09-14T16:11:40Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=00af6729b52ede86a08173c8d5f2c8cd9fa3390d'/>
<id>urn:sha1:00af6729b52ede86a08173c8d5f2c8cd9fa3390d</id>
<content type='text'>
Paul Cercueil needs some patches in -rc5 to apply new patches for ingenic
properly.

Signed-off-by: Maxime Ripard &lt;maxime@cerno.tech&gt;
</content>
</entry>
<entry>
<title>fbdev: nvidia: use generic power management</title>
<updated>2020-09-08T11:33:14Z</updated>
<author>
<name>Vaibhav Gupta</name>
<email>vaibhavgupta40@gmail.com</email>
</author>
<published>2020-08-19T18:56:48Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=6d111187588cddc4d0fd84007756f396cdb2de85'/>
<id>urn:sha1:6d111187588cddc4d0fd84007756f396cdb2de85</id>
<content type='text'>
Drivers should do only device-specific jobs. But in general, drivers using
legacy PCI PM framework for .suspend()/.resume() have to manage many PCI
PM-related tasks themselves which can be done by PCI Core itself. This
brings extra load on the driver and it directly calls PCI helper functions
to handle them.

Switch to the new generic framework by updating function signatures and
define a "struct dev_pm_ops" variable to bind PM callbacks. Also, remove
unnecessary calls to the PCI Helper functions along with the legacy
.suspend &amp; .resume bindings.

Now,
- nvidiafb_suspend() had a "pm_message_t" type parameter as per legacy
  PCI PM framework that got deprecated in generic.
- Rename the callback as nvidiafb_suspend_late() and preserve the
  parameter.
- Define 3 new callbacks as:
        * nvidiafb_suspend()
        * nvidiafb_freeze()
        * nvidiafb_hibernate()
  which in turn call nvidiafb_suspend_late() by passing appropriate value
  for "pm_message_t" type parameter.
- Bind the callbacks in "struct dev_pm_ops" type variable
  "nvidiafb_pm_ops".

Signed-off-by: Vaibhav Gupta &lt;vaibhavgupta40@gmail.com&gt;
Cc: Bjorn Helgaas &lt;helgaas@kernel.org&gt;
Cc: Bjorn Helgaas &lt;bhelgaas@google.com&gt;
Cc: Bjorn Helgaas &lt;bjorn@helgaas.com&gt;
Cc: Vaibhav Gupta &lt;vaibhav.varodek@gmail.com&gt;
Cc: Sam Ravnborg &lt;sam@ravnborg.org&gt;
Cc: Paul Mackerras &lt;paulus@samba.org&gt;
Cc: Russell King &lt;linux@armlinux.org.uk&gt;
Cc: Andres Salomon &lt;dilinger@queued.net&gt;
CC: Antonino Daplas &lt;adaplas@gmail.com&gt;
Cc: Shuah Khan &lt;skhan@linuxfoundation.org&gt;
Signed-off-by: Bartlomiej Zolnierkiewicz &lt;b.zolnierkie@samsung.com&gt;
Link: https://patchwork.freedesktop.org/patch/msgid/20200819185654.151170-7-vaibhavgupta40@gmail.com
</content>
</entry>
</feed>
