aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2023-10-19Merge branch 'mptcp-fixes-for-v6-6'Jakub Kicinski3-15/+43
Mat Martineau says: ==================== mptcp: Fixes for v6.6 Patch 1 corrects the logic for MP_JOIN tests where 0 RSTs are expected. Patch 2 ensures MPTCP packets are not incorrectly coalesced in the TCP backlog queue. Patch 3 avoids a zero-window probe and associated WARN_ON_ONCE() in an expected MPTCP reinjection scenario. Patches 4 & 5 allow an initial MPTCP subflow to be closed cleanly instead of always sending RST. Associated selftest is updated. ==================== Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski <[email protected]>
2023-10-19selftests: mptcp: join: no RST when rm subflow/addrMatthieu Baerts1-0/+13
Recently, we noticed that some RST were wrongly generated when removing the initial subflow. This patch makes sure RST are not sent when removing any subflows or any addresses. Fixes: c2b2ae3925b6 ("mptcp: handle correctly disconnect() failures") Cc: [email protected] Acked-by: Paolo Abeni <[email protected]> Signed-off-by: Matthieu Baerts <[email protected]> Signed-off-by: Mat Martineau <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski <[email protected]>
2023-10-19mptcp: avoid sending RST when closing the initial subflowGeliang Tang1-6/+22
When closing the first subflow, the MPTCP protocol unconditionally calls tcp_disconnect(), which in turn generates a reset if the subflow is established. That is unexpected and different from what MPTCP does with MPJ subflows, where resets are generated only on FASTCLOSE and other edge scenarios. We can't reuse for the first subflow the same code in place for MPJ subflows, as MPTCP clean them up completely via a tcp_close() call, while must keep the first subflow socket alive for later re-usage, due to implementation constraints. This patch adds a new helper __mptcp_subflow_disconnect() that encapsulates, a logic similar to tcp_close, issuing a reset only when the MPTCP_CF_FASTCLOSE flag is set, and performing a clean shutdown otherwise. Fixes: c2b2ae3925b6 ("mptcp: handle correctly disconnect() failures") Cc: [email protected] Reviewed-by: Matthieu Baerts <[email protected]> Co-developed-by: Paolo Abeni <[email protected]> Signed-off-by: Paolo Abeni <[email protected]> Signed-off-by: Geliang Tang <[email protected]> Signed-off-by: Mat Martineau <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski <[email protected]>
2023-10-19mptcp: more conservative check for zero probesPaolo Abeni1-7/+1
Christoph reported that the MPTCP protocol can find the subflow-level write queue unexpectedly not empty while crafting a zero-window probe, hitting a warning: ------------[ cut here ]------------ WARNING: CPU: 0 PID: 188 at net/mptcp/protocol.c:1312 mptcp_sendmsg_frag+0xc06/0xe70 Modules linked in: CPU: 0 PID: 188 Comm: kworker/0:2 Not tainted 6.6.0-rc2-g1176aa719d7a #47 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.11.0-2.el7 04/01/2014 Workqueue: events mptcp_worker RIP: 0010:mptcp_sendmsg_frag+0xc06/0xe70 net/mptcp/protocol.c:1312 RAX: 47d0530de347ff6a RBX: 47d0530de347ff6b RCX: ffff8881015d3c00 RDX: ffff8881015d3c00 RSI: 47d0530de347ff6b RDI: 47d0530de347ff6b RBP: 47d0530de347ff6b R08: ffffffff8243c6a8 R09: ffffffff82042d9c R10: 0000000000000002 R11: ffffffff82056850 R12: ffff88812a13d580 R13: 0000000000000001 R14: ffff88812b375e50 R15: ffff88812bbf3200 FS: 0000000000000000(0000) GS:ffff88813bc00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000695118 CR3: 0000000115dfc001 CR4: 0000000000170ef0 Call Trace: <TASK> __subflow_push_pending+0xa4/0x420 net/mptcp/protocol.c:1545 __mptcp_push_pending+0x128/0x3b0 net/mptcp/protocol.c:1614 mptcp_release_cb+0x218/0x5b0 net/mptcp/protocol.c:3391 release_sock+0xf6/0x100 net/core/sock.c:3521 mptcp_worker+0x6e8/0x8f0 net/mptcp/protocol.c:2746 process_scheduled_works+0x341/0x690 kernel/workqueue.c:2630 worker_thread+0x3a7/0x610 kernel/workqueue.c:2784 kthread+0x143/0x180 kernel/kthread.c:388 ret_from_fork+0x4d/0x60 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1b/0x30 arch/x86/entry/entry_64.S:304 </TASK> The root cause of the issue is that expectations are wrong: e.g. due to MPTCP-level re-injection we can hit the critical condition. Explicitly avoid the zero-window probe when the subflow write queue is not empty and drop the related warnings. Reported-by: Christoph Paasch <[email protected]> Closes: https://github.com/multipath-tcp/mptcp_net-next/issues/444 Fixes: f70cad1085d1 ("mptcp: stop relying on tcp_tx_skb_cache") Cc: [email protected] Reviewed-by: Mat Martineau <[email protected]> Signed-off-by: Paolo Abeni <[email protected]> Signed-off-by: Mat Martineau <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski <[email protected]>
2023-10-19tcp: check mptcp-level constraints for backlog coalescingPaolo Abeni1-0/+1
The MPTCP protocol can acquire the subflow-level socket lock and cause the tcp backlog usage. When inserting new skbs into the backlog, the stack will try to coalesce them. Currently, we have no check in place to ensure that such coalescing will respect the MPTCP-level DSS, and that may cause data stream corruption, as reported by Christoph. Address the issue by adding the relevant admission check for coalescing in tcp_add_backlog(). Note the issue is not easy to reproduce, as the MPTCP protocol tries hard to avoid acquiring the subflow-level socket lock. Fixes: 648ef4b88673 ("mptcp: Implement MPTCP receive path") Cc: [email protected] Reported-by: Christoph Paasch <[email protected]> Closes: https://github.com/multipath-tcp/mptcp_net-next/issues/420 Reviewed-by: Mat Martineau <[email protected]> Signed-off-by: Paolo Abeni <[email protected]> Signed-off-by: Mat Martineau <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski <[email protected]>
2023-10-19selftests: mptcp: join: correctly check for no RSTMatthieu Baerts1-2/+6
The commit mentioned below was more tolerant with the number of RST seen during a test because in some uncontrollable situations, multiple RST can be generated. But it was not taking into account the case where no RST are expected: this validation was then no longer reporting issues for the 0 RST case because it is not possible to have less than 0 RST in the counter. This patch fixes the issue by adding a specific condition. Fixes: 6bf41020b72b ("selftests: mptcp: update and extend fastclose test-cases") Cc: [email protected] Reviewed-by: Mat Martineau <[email protected]> Signed-off-by: Matthieu Baerts <[email protected]> Signed-off-by: Mat Martineau <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski <[email protected]>
2023-10-19net: ti: icssg-prueth: Fix r30 CMDs bitmasksMD Danish Anwar1-2/+2
The bitmasks for EMAC_PORT_DISABLE and EMAC_PORT_FORWARD r30 commands are wrong in the driver. Update the bitmasks of these commands to the correct ones as used by the ICSSG firmware. These bitmasks are backwards compatible and work with any ICSSG firmware version. Fixes: e9b4ece7d74b ("net: ti: icssg-prueth: Add Firmware config and classification APIs.") Signed-off-by: MD Danish Anwar <[email protected]> Reviewed-by: Andrew Lunn <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski <[email protected]>
2023-10-19Merge tag 'for-6.6-rc6-tag' of ↵Linus Torvalds1-1/+1
git://git.kernel.org/pub/scm/linux/kernel/git/kdave/linux Pull btrfs fix from David Sterba: "Fix a bug in chunk size decision that could lead to suboptimal placement and filling patterns" * tag 'for-6.6-rc6-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/kdave/linux: btrfs: fix stripe length calculation for non-zoned data chunk allocation
2023-10-19rust: docs: fix logo replacementMiguel Ojeda1-8/+7
The static files placement by `rustdoc` changed in Rust 1.67.0 [1], but the custom code we have to replace the logo in the generated HTML files did not get updated. Thus update it to have the Linux logo again in the output. Hopefully `rustdoc` will eventually support a custom logo from a local file [2], so that we do not need to maintain this hack on our side. Link: https://github.com/rust-lang/rust/pull/101702 [1] Link: https://github.com/rust-lang/rfcs/pull/3226 [2] Fixes: 3ed03f4da06e ("rust: upgrade to Rust 1.68.2") Cc: [email protected] Tested-by: Benno Lossin <[email protected]> Reviewed-by: Andreas Hindborg <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Miguel Ojeda <[email protected]>
2023-10-19kbuild: remove old Rust docs output pathMiguel Ojeda1-1/+1
The Rust code documentation output path moved from `rust/doc` to `Documentation/output/rust/rustdoc`. The `make cleandocs` target takes care of cleaning it now since it is integrated with the rest of the documentation. Thus remove the old reference. Fixes: 48fadf440075 ("docs: Move rustdoc output, cross-reference it") Reviewed-by: Benno Lossin <[email protected]> Reviewed-by: Alice Ryhl <[email protected]> Reviewed-by: Andreas Hindborg <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Miguel Ojeda <[email protected]>
2023-10-19docs: rust: update Rust docs output pathMiguel Ojeda1-1/+1
The Rust code documentation output path moved from `rust/doc` to `Documentation/output/rust/rustdoc`, thus update the old reference. Fixes: 48fadf440075 ("docs: Move rustdoc output, cross-reference it") Reviewed-by: Benno Lossin <[email protected]> Reviewed-by: Alice Ryhl <[email protected]> Reviewed-by: Andreas Hindborg <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Miguel Ojeda <[email protected]>
2023-10-19s390/pci: fix iommu bitmap allocationNiklas Schnelle1-2/+13
Since the fixed commits both zdev->iommu_bitmap and zdev->lazy_bitmap are allocated as vzalloc(zdev->iommu_pages / 8). The problem is that zdev->iommu_bitmap is a pointer to unsigned long but the above only yields an allocation that is a multiple of sizeof(unsigned long) which is 8 on s390x if the number of IOMMU pages is a multiple of 64. This in turn is the case only if the effective IOMMU aperture is a multiple of 64 * 4K = 256K. This is usually the case and so didn't cause visible issues since both the virt_to_phys(high_memory) reduced limit and hardware limits use nice numbers. Under KVM, and in particular with QEMU limiting the IOMMU aperture to the vfio DMA limit (default 65535), it is possible for the reported aperture not to be a multiple of 256K however. In this case we end up with an iommu_bitmap whose allocation is not a multiple of 8 causing bitmap operations to access it out of bounds. Sadly we can't just fix this in the obvious way and use bitmap_zalloc() because for large RAM systems (tested on 8 TiB) the zdev->iommu_bitmap grows too large for kmalloc(). So add our own bitmap_vzalloc() wrapper. This might be a candidate for common code, but this area of code will be replaced by the upcoming conversion to use the common code DMA API on s390 so just add a local routine. Fixes: 224593215525 ("s390/pci: use virtual memory for iommu bitmap") Fixes: 13954fd6913a ("s390/pci_dma: improve lazy flush for unmap") Cc: [email protected] Reviewed-by: Matthew Rosato <[email protected]> Signed-off-by: Niklas Schnelle <[email protected]> Signed-off-by: Vasily Gorbik <[email protected]>
2023-10-19fanotify: limit reporting of event with non-decodeable file handlesAmir Goldstein1-8/+17
Commit a95aef69a740 ("fanotify: support reporting non-decodeable file handles") merged in v6.5-rc1, added the ability to use an fanotify group with FAN_REPORT_FID mode to watch filesystems that do not support nfs export, but do know how to encode non-decodeable file handles, with the newly introduced AT_HANDLE_FID flag. At the time that this commit was merged, there were no filesystems in-tree with those traits. Commit 16aac5ad1fa9 ("ovl: support encoding non-decodable file handles"), merged in v6.6-rc1, added this trait to overlayfs, thus allowing fanotify watching of overlayfs with FAN_REPORT_FID mode. In retrospect, allowing an fanotify filesystem/mount mark on such filesystem in FAN_REPORT_FID mode will result in getting events with file handles, without the ability to resolve the filesystem objects from those file handles (i.e. no open_by_handle_at() support). For v6.6, the safer option would be to allow this mode for inode marks only, where the caller has the opportunity to use name_to_handle_at() at the time of setting the mark. In the future we can revise this decision. Fixes: a95aef69a740 ("fanotify: support reporting non-decodeable file handles") Signed-off-by: Amir Goldstein <[email protected]> Signed-off-by: Jan Kara <[email protected]> Message-Id: <[email protected]>
2023-10-19Merge branch 'net-fix-bugs-in-device-netns-move-and-rename'Paolo Abeni4-15/+141
Jakub Kicinski says: ==================== net: fix bugs in device netns-move and rename Daniel reported issues with the uevents generated during netdev namespace move, if the netdev is getting renamed at the same time. While the issue that he actually cares about is not fixed here, there is a bunch of seemingly obvious other bugs in this code. Fix the purely networking bugs while the discussion around the uevent fix is still ongoing. ==================== Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Paolo Abeni <[email protected]>
2023-10-19selftests: net: add very basic test for netdev names and namespacesJakub Kicinski2-0/+88
Add selftest for fixes around naming netdevs and namespaces. Signed-off-by: Jakub Kicinski <[email protected]> Reviewed-by: Przemek Kitszel <[email protected]> Signed-off-by: Paolo Abeni <[email protected]>
2023-10-19net: move altnames together with the netdeviceJakub Kicinski1-4/+9
The altname nodes are currently not moved to the new netns when netdevice itself moves: [ ~]# ip netns add test [ ~]# ip -netns test link add name eth0 type dummy [ ~]# ip -netns test link property add dev eth0 altname some-name [ ~]# ip -netns test link show dev some-name 2: eth0: <BROADCAST,NOARP> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000 link/ether 1e:67:ed:19:3d:24 brd ff:ff:ff:ff:ff:ff altname some-name [ ~]# ip -netns test link set dev eth0 netns 1 [ ~]# ip link ... 3: eth0: <BROADCAST,NOARP> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000 link/ether 02:40:88:62:ec:b8 brd ff:ff:ff:ff:ff:ff altname some-name [ ~]# ip li show dev some-name Device "some-name" does not exist. Remove them from the hash table when device is unlisted and add back when listed again. Fixes: 36fbf1e52bd3 ("net: rtnetlink: add linkprop commands to add and delete alternative ifnames") Reviewed-by: Jiri Pirko <[email protected]> Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Paolo Abeni <[email protected]>
2023-10-19net: avoid UAF on deleted altnameJakub Kicinski1-1/+6
Altnames are accessed under RCU (dev_get_by_name_rcu()) but freed by kfree() with no synchronization point. Each node has one or two allocations (node and a variable-size name, sometimes the name is netdev->name). Adding rcu_heads here is a bit tedious. Besides most code which unlists the names already has rcu barriers - so take the simpler approach of adding synchronize_rcu(). Note that the one on the unregistration path (which matters more) is removed by the next fix. Fixes: ff92741270bf ("net: introduce name_node struct to be used in hashlist") Reviewed-by: Jiri Pirko <[email protected]> Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Paolo Abeni <[email protected]>
2023-10-19net: check for altname conflicts when changing netdev's netnsJakub Kicinski2-1/+11
It's currently possible to create an altname conflicting with an altname or real name of another device by creating it in another netns and moving it over: [ ~]$ ip link add dev eth0 type dummy [ ~]$ ip netns add test [ ~]$ ip -netns test link add dev ethX netns test type dummy [ ~]$ ip -netns test link property add dev ethX altname eth0 [ ~]$ ip -netns test link set dev ethX netns 1 [ ~]$ ip link ... 3: eth0: <BROADCAST,NOARP> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000 link/ether 02:40:88:62:ec:b8 brd ff:ff:ff:ff:ff:ff ... 5: ethX: <BROADCAST,NOARP> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000 link/ether 26:b7:28:78:38:0f brd ff:ff:ff:ff:ff:ff altname eth0 Create a macro for walking the altnames, this hopefully makes it clearer that the list we walk contains only altnames. Which is otherwise not entirely intuitive. Fixes: 36fbf1e52bd3 ("net: rtnetlink: add linkprop commands to add and delete alternative ifnames") Reviewed-by: Jiri Pirko <[email protected]> Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Paolo Abeni <[email protected]>
2023-10-19net: fix ifname in netlink ntf during netns moveJakub Kicinski1-13/+31
dev_get_valid_name() overwrites the netdev's name on success. This makes it hard to use in prepare-commit-like fashion, where we do validation first, and "commit" to the change later. Factor out a helper which lets us save the new name to a buffer. Use it to fix the problem of notification on netns move having incorrect name: 5: eth0: <BROADCAST,NOARP> mtu 1500 qdisc noop state DOWN group default link/ether be:4d:58:f9:d5:40 brd ff:ff:ff:ff:ff:ff 6: eth1: <BROADCAST,NOARP> mtu 1500 qdisc noop state DOWN group default link/ether 1e:4a:34:36:e3:cd brd ff:ff:ff:ff:ff:ff [ ~]# ip link set dev eth0 netns 1 name eth1 ip monitor inside netns: Deleted inet eth0 Deleted inet6 eth0 Deleted 5: eth1: <BROADCAST,NOARP> mtu 1500 qdisc noop state DOWN group default link/ether be:4d:58:f9:d5:40 brd ff:ff:ff:ff:ff:ff new-netnsid 0 new-ifindex 7 Name is reported as eth1 in old netns for ifindex 5, already renamed. Fixes: d90310243fd7 ("net: device name allocation cleanups") Signed-off-by: Jakub Kicinski <[email protected]> Reviewed-by: Jiri Pirko <[email protected]> Signed-off-by: Paolo Abeni <[email protected]>
2023-10-19drm/ast: Move register constants to ast_reg.hThomas Zimmermann2-81/+101
Improve readability by putting all register constants into a separate header file. No functional changes. Signed-off-by: Thomas Zimmermann <[email protected]> Reviewed-by: Jocelyn Falempe <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-10-19drm/ast: Rename AST_IO_MISC_PORT_READ to AST_IO_VGAMR_RThomas Zimmermann2-2/+2
Rename AST_IO_MISC_PORT_READ to AST_IO_VGAMR_R to align naming in the driver with documentation. No functional changes. Signed-off-by: Thomas Zimmermann <[email protected]> Reviewed-by: Jocelyn Falempe <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-10-19drm/ast: Rename AST_IO_INPUT_STATUS1_READ to AST_IO_VGAIR1_RThomas Zimmermann2-4/+4
Rename AST_IO_INPUT_STATUS1_READ to AST_IO_VGAIR1_R to align naming in the driver with documentation. No functional changes. Signed-off-by: Thomas Zimmermann <[email protected]> Reviewed-by: Jocelyn Falempe <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-10-19drm/ast: Rename AST_IO_CRTC_PORT to AST_IO_VGACRIThomas Zimmermann8-162/+162
Rename AST_IO_CRTC_PORT to AST_IO_VGACRI to align naming in the driver with documentation. No functional changes. Signed-off-by: Thomas Zimmermann <[email protected]> Reviewed-by: Jocelyn Falempe <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-10-19drm/ast: Rename AST_IO_GR_PORT to AST_IO_VGAGRIThomas Zimmermann2-2/+2
Rename AST_IO_GR_PORT to AST_IO_VGAGRI to align naming in the driver with documentation. No functional changes. Signed-off-by: Thomas Zimmermann <[email protected]> Reviewed-by: Jocelyn Falempe <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-10-19drm/ast: Rename AST_IO_DAC_DATA to AST_IO_VGAPDRThomas Zimmermann2-4/+4
Rename AST_IO_DAC_DATA to AST_IO_VGAPDR to align naming in the driver with documentation. No functional changes. Signed-off-by: Thomas Zimmermann <[email protected]> Reviewed-by: Jocelyn Falempe <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-10-19drm/ast: Rename AST_IO_DAC_INDEX_WRITE to AST_IO_VGADWRThomas Zimmermann2-2/+2
Rename AST_IO_DAC_INDEX_WRITE to AST_IO_VGADWR to align naming in the driver with documentation. No functional changes. Signed-off-by: Thomas Zimmermann <[email protected]> Reviewed-by: Jocelyn Falempe <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-10-19drm/ast: Rename AST_IO_DAC_INDEX_READ to AST_IO_VGADRRThomas Zimmermann1-1/+1
Rename AST_IO_DAC_INDEX_READ to AST_IO_VGADRR to align naming in the driver with documentation. No functional changes. Signed-off-by: Thomas Zimmermann <[email protected]> Reviewed-by: Jocelyn Falempe <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-10-19drm/ast: Rename AST_IO_SEQ_PORT to AST_IO_VGASRIThomas Zimmermann2-12/+12
Rename AST_IO_VGA_SEQ_PORT to AST_IO_VGASRI to align naming in the driver with documentation. No functional changes. Signed-off-by: Thomas Zimmermann <[email protected]> Reviewed-by: Jocelyn Falempe <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-10-19drm/ast: Rename AST_IO_VGA_ENABLE_PORT to AST_IO_VGAERThomas Zimmermann2-3/+3
Rename AST_IO_VGA_ENABLE_PORT to AST_IO_VGAER to align naming in the driver with documentation. No functional changes. Signed-off-by: Thomas Zimmermann <[email protected]> Reviewed-by: Jocelyn Falempe <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-10-19drm/ast: Rename AST_IO_MISC_PORT_WRITE to AST_IO_VGAMR_WThomas Zimmermann3-4/+4
Rename AST_IO_MISC_PORT_WRITE to AST_IO_VGAMR_W to align naming in the driver with documentation. No functional changes. Signed-off-by: Thomas Zimmermann <[email protected]> Reviewed-by: Jocelyn Falempe <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-10-19drm/ast: Rename AST_IO_AR_PORT_WRITE to AST_IO_VGAARI_WThomas Zimmermann2-6/+6
Rename AST_IO_AR_PORT_WRITE to AST_IO_VGAARI_W to align naming in the driver with documentation. No functional changes. Signed-off-by: Thomas Zimmermann <[email protected]> Reviewed-by: Jocelyn Falempe <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-10-19fbdev/vt8623fb: Initialize fb_ops to fbdev I/O-memory helpersThomas Zimmermann2-0/+3
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 <[email protected]> Acked-by: Javier Martinez Canillas <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-10-19fbdev/viafb: Initialize fb_ops to fbdev I/O-memory helpersThomas Zimmermann2-0/+3
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 <[email protected]> Acked-by: Javier Martinez Canillas <[email protected]> Cc: Florian Tobias Schandinat <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-10-19fbdev/vga16fb: Initialize fb_ops to fbdev I/O-memory helpersThomas Zimmermann2-0/+3
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 <[email protected]> Acked-by: Javier Martinez Canillas <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-10-19fbdev/vermilionfb: Initialize fb_ops to fbdev I/O-memory helpersThomas Zimmermann2-6/+3
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 <[email protected]> Acked-by: Javier Martinez Canillas <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-10-19fbdev/tridentfb: Initialize fb_ops to fbdev I/O-memory helpersThomas Zimmermann2-0/+3
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 <[email protected]> Acked-by: Javier Martinez Canillas <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-10-19fbdev/tgafb: Initialize fb_ops to fbdev I/O-memory helpersThomas Zimmermann2-1/+4
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 <[email protected]> Acked-by: Javier Martinez Canillas <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-10-19fbdev/tdfxfb: Initialize fb_ops to fbdev I/O-memory helpersThomas Zimmermann2-4/+5
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 <[email protected]> Acked-by: Javier Martinez Canillas <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-10-19fbdev/sunxvr500: Initialize fb_ops to fbdev I/O-memory helpersThomas Zimmermann2-0/+3
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 <[email protected]> Acked-by: Javier Martinez Canillas <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-10-19fbdev/stifb: Initialize fb_ops to fbdev I/O-memory helpersThomas Zimmermann2-0/+3
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 <[email protected]> Acked-by: Javier Martinez Canillas <[email protected]> Cc: "James E.J. Bottomley" <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-10-19fbdev/sm712fb: Initialize fb_ops to fbdev I/O-memory helpersThomas Zimmermann2-3/+2
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 <[email protected]> Acked-by: Javier Martinez Canillas <[email protected]> Cc: Sudip Mukherjee <[email protected]> Cc: Teddy Wang <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-10-19fbdev/sm501fb: Initialize fb_ops to fbdev I/O-memory helpersThomas Zimmermann2-0/+5
Initialize each 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 <[email protected]> Acked-by: Javier Martinez Canillas <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-10-19fbdev/sisfb: Initialize fb_ops to fbdev I/O-memory helpersThomas Zimmermann2-2/+5
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 <[email protected]> Acked-by: Javier Martinez Canillas <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-10-19fbdev/savagefb: Initialize fb_ops to fbdev I/O-memory helpersThomas Zimmermann2-4/+5
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 <[email protected]> Acked-by: Javier Martinez Canillas <[email protected]> Cc: Antonino Daplas <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-10-19fbdev/sa1100fb: Initialize fb_ops to fbdev I/O-memory helpersThomas Zimmermann2-6/+3
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 <[email protected]> Acked-by: Javier Martinez Canillas <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-10-19fbdev/s3fb: Initialize fb_ops to fbdev I/O-memory helpersThomas Zimmermann2-0/+3
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 <[email protected]> Acked-by: Javier Martinez Canillas <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-10-19fbdev/s1d13xxxfb: Initialize fb_ops to fbdev I/O-memory helpersThomas Zimmermann2-9/+17
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. To simplify the conversion, provide a dedicated fb_ops instance for accelerated devices. No functional changes. Signed-off-by: Thomas Zimmermann <[email protected]> Acked-by: Javier Martinez Canillas <[email protected]> Cc: Kristoffer Ericson <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-10-19fbdev/rivafb: Initialize fb_ops to fbdev I/O-memory helpersThomas Zimmermann2-1/+4
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 <[email protected]> Acked-by: Javier Martinez Canillas <[email protected]> Cc: Antonino Daplas <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-10-19fbdev/radeon: Initialize fb_ops to fbdev I/O-memory helpersThomas Zimmermann2-1/+4
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 <[email protected]> Acked-by: Javier Martinez Canillas <[email protected]> Cc: Benjamin Herrenschmidt <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-10-19fbdev/pvr2fb: Initialize fb_ops to fbdev I/O-memory helpersThomas Zimmermann2-6/+9
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 <[email protected]> Acked-by: Javier Martinez Canillas <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]