kernel/linux.git/Documentation/admin-guide/devices.txt, branch v6.12.91

Documentation: devices.txt: Update ttyUL major number allocation details

2023-11-25T07:23:16+00:00

Describe when uartlite driver uses static/dynamic allocation for major number based on maximum number of uartlite serial ports. Signed-off-by: Manikanta Guntupalli Link: https://lore.kernel.org/r/20231116134003.3762725-2-manikanta.guntupalli@amd.com Signed-off-by: Greg Kroah-Hartman

Documentation: devices.txt: Fix minors for ttyCPM*

2023-08-22T13:31:40+00:00

ttyCPM* devices belong to CPM_UART driver at the first place and that driver provides 6 ports. Fixes: e29c3f81eb89 ("Documentation: devices.txt: reconcile serial/ucc_uart minor numers") Cc: Randy Dunlap Signed-off-by: Christophe Leroy Reviewed-by: Randy Dunlap Link: https://lore.kernel.org/r/27d7124cf86157e2a27c2b039e769041994d3f22.1691992627.git.christophe.leroy@csgroup.eu Signed-off-by: Greg Kroah-Hartman

Documentation: devices.txt: Remove ttySIOC*

2023-08-22T13:31:40+00:00

IOC3 serial driver was removed, remove associated devices from documentation. Fixes: 9c860e4cf708 ("tty/serial: remove the ioc3_serial driver") Cc: Christoph Hellwig Signed-off-by: Christophe Leroy Link: https://lore.kernel.org/r/f13b5c64f8cb6d8f2357d7be14397676b27ac2a2.1691992627.git.christophe.leroy@csgroup.eu Signed-off-by: Greg Kroah-Hartman

Documentation: devices.txt: Remove ttyIOC*

2023-08-22T13:31:40+00:00

IOC4 serial driver was removed, remove associated devices from documentation. Fixes: a017ef17cfd8 ("tty/serial: remove the ioc4_serial driver") Cc: Christoph Hellwig Signed-off-by: Christophe Leroy Link: https://lore.kernel.org/r/b5deb1222eb92017f0efe5b5cae127ac11983b3d.1691992627.git.christophe.leroy@csgroup.eu Signed-off-by: Greg Kroah-Hartman

Documentation: devices.txt: reconcile serial/ucc_uart minor numers

2023-07-25T17:29:23+00:00

Reconcile devices.txt with serial/ucc_uart.c regarding device number assignments. ucc_uart.c supports 4 ports and uses minor devnums 46-49, so update devices.txt with that info. Then update ucc_uart.c's reference to the location of the devices.txt list in the kernel source tree. Fixes: d7584ed2b994 ("[POWERPC] qe-uart: add support for Freescale QUICCEngine UART") Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Randy Dunlap Cc: Timur Tabi Cc: Kumar Gala Cc: linuxppc-dev@lists.ozlabs.org Cc: Greg Kroah-Hartman Cc: Jiri Slaby Cc: linux-serial@vger.kernel.org Cc: Jonathan Corbet Cc: linux-doc@vger.kernel.org Link: https://lore.kernel.org/r/20230724063341.28198-1-rdunlap@infradead.org Signed-off-by: Greg Kroah-Hartman

drivers/accel: define kconfig and register a new major

2022-11-22T11:13:51+00:00

Add a new Kconfig for the accel subsystem. The Kconfig currently contains only the basic CONFIG_DRM_ACCEL option that will be used to decide whether to compile the accel registration code. Therefore, the kconfig option is defined as bool. The accel code will be compiled as part of drm.ko and will be called directly from the DRM core code. The reason we compile it as part of drm.ko and not as a separate module is because of cyclic dependency between drm.ko and the separate module (if it would have existed). This is due to the fact that DRM core code calls accel functions and vice-versa. The accelerator devices will be exposed to the user space with a new, dedicated major number - 261. The accel init function registers the new major number as a char device and create corresponding sysfs and debugfs root entries, similar to what is done in DRM init function. I added a new header called drm_accel.h to include/drm/, that will hold the prototypes of the drm_accel.c functions. In case CONFIG_DRM_ACCEL is set to 'N', that header will contain empty inline implementations of those functions, to allow DRM core code to compile successfully without dependency on CONFIG_DRM_ACCEL. I Updated the MAINTAINERS file accordingly with the newly added folder and I have taken the liberty to appropriate the dri-devel mailing list and the dri-devel IRC channel for the accel subsystem. Signed-off-by: Oded Gabbay Reviewed-by: Greg Kroah-Hartman Reviewed-by: Jeffrey Hugo Reviewed-by: Dave Airlie Acked-by: Thomas Zimmermann Acked-by: Jacek Lawrynowicz Tested-by: Jacek Lawrynowicz Reviewed-by: Melissa Wen

net: wan: remove support for COSA and SRP synchronous serial boards

2022-04-27T11:22:56+00:00

Looks like all the changes to this driver had been automated churn since git era begun. The driver is using virt_to_bus() so it should be updated to a proper DMA API or removed. Given the latest "news" entry on the website is from 1999 I'm opting for the latter. I'm marking the allocated char device major number as [REMOVED], I reckon we can't reuse it in case some SW out there assumes its COSA? Signed-off-by: Jakub Kicinski Signed-off-by: David S. Miller

Documentation, arch: Remove leftovers from raw device

2021-12-17T13:07:52+00:00

Raw device interface was removed so remove all references to configs related to it. Fixes: 603e4922f1c8 ("remove the raw driver") Signed-off-by: Alexandre Ghiti Acked-by: Arnd Bergmann [arch/arm/configs] Signed-off-by: Arnd Bergmann

docs: Fix infiniband uverbs minor number

2021-07-30T13:05:50+00:00

Starting from the beginning of infiniband subsystem, the uverbs char devices start from 192 as a minor number, see commit bc38a6abdd5a ("[PATCH] IB uverbs: core implementation"). This patch updates the admin guide documentation to reflect it. Fixes: 9d85025b0418 ("docs-rst: create an user's manual book") Link: https://lore.kernel.org/r/bad03e6bcde45550c01e12908a6fe7dfa4770703.1627477347.git.leonro@nvidia.com Signed-off-by: Leon Romanovsky Signed-off-by: Jason Gunthorpe

drivers/char: remove /dev/kmem for good

2021-05-07T07:26:34+00:00

Patch series "drivers/char: remove /dev/kmem for good". Exploring /dev/kmem and /dev/mem in the context of memory hot(un)plug and memory ballooning, I started questioning the existence of /dev/kmem. Comparing it with the /proc/kcore implementation, it does not seem to be able to deal with things like a) Pages unmapped from the direct mapping (e.g., to be used by secretmem) -> kern_addr_valid(). virt_addr_valid() is not sufficient. b) Special cases like gart aperture memory that is not to be touched -> mem_pfn_is_ram() Unless I am missing something, it's at least broken in some cases and might fault/crash the machine. Looks like its existence has been questioned before in 2005 and 2010 [1], after ~11 additional years, it might make sense to revive the discussion. CONFIG_DEVKMEM is only enabled in a single defconfig (on purpose or by mistake?). All distributions disable it: in Ubuntu it has been disabled for more than 10 years, in Debian since 2.6.31, in Fedora at least starting with FC3, in RHEL starting with RHEL4, in SUSE starting from 15sp2, and OpenSUSE has it disabled as well. 1) /dev/kmem was popular for rootkits [2] before it got disabled basically everywhere. Ubuntu documents [3] "There is no modern user of /dev/kmem any more beyond attackers using it to load kernel rootkits.". RHEL documents in a BZ [5] "it served no practical purpose other than to serve as a potential security problem or to enable binary module drivers to access structures/functions they shouldn't be touching" 2) /proc/kcore is a decent interface to have a controlled way to read kernel memory for debugging puposes. (will need some extensions to deal with memory offlining/unplug, memory ballooning, and poisoned pages, though) 3) It might be useful for corner case debugging [1]. KDB/KGDB might be a better fit, especially, to write random memory; harder to shoot yourself into the foot. 4) "Kernel Memory Editor" [4] hasn't seen any updates since 2000 and seems to be incompatible with 64bit [1]. For educational purposes, /proc/kcore might be used to monitor value updates -- or older kernels can be used. 5) It's broken on arm64, and therefore, completely disabled there. Looks like it's essentially unused and has been replaced by better suited interfaces for individual tasks (/proc/kcore, KDB/KGDB). Let's just remove it. [1] https://lwn.net/Articles/147901/ [2] https://www.linuxjournal.com/article/10505 [3] https://wiki.ubuntu.com/Security/Features#A.2Fdev.2Fkmem_disabled [4] https://sourceforge.net/projects/kme/ [5] https://bugzilla.redhat.com/show_bug.cgi?id=154796 Link: https://lkml.kernel.org/r/20210324102351.6932-1-david@redhat.com Link: https://lkml.kernel.org/r/20210324102351.6932-2-david@redhat.com Signed-off-by: David Hildenbrand Acked-by: Michal Hocko Acked-by: Kees Cook Cc: Linus Torvalds Cc: Greg Kroah-Hartman Cc: "Alexander A. Klimov" Cc: Alexander Viro Cc: Alexandre Belloni Cc: Andrew Lunn Cc: Andrey Zhizhikin Cc: Arnd Bergmann Cc: Benjamin Herrenschmidt Cc: Brian Cain Cc: Christian Borntraeger Cc: Christophe Leroy Cc: Chris Zankel Cc: Corentin Labbe Cc: "David S. Miller" Cc: "Eric W. Biederman" Cc: Geert Uytterhoeven Cc: Gerald Schaefer Cc: Greentime Hu Cc: Gregory Clement Cc: Heiko Carstens Cc: Helge Deller Cc: Hillf Danton Cc: huang ying Cc: Ingo Molnar Cc: Ivan Kokshaysky Cc: "James E.J. Bottomley" Cc: James Troup Cc: Jiaxun Yang Cc: Jonas Bonn Cc: Jonathan Corbet Cc: Kairui Song Cc: Krzysztof Kozlowski Cc: Kuninori Morimoto Cc: Liviu Dudau Cc: Lorenzo Pieralisi Cc: Luc Van Oostenryck Cc: Luis Chamberlain Cc: Matthew Wilcox Cc: Matt Turner Cc: Max Filippov Cc: Michael Ellerman Cc: Mike Rapoport Cc: Mikulas Patocka Cc: Minchan Kim Cc: Niklas Schnelle Cc: Oleksiy Avramchenko Cc: openrisc@lists.librecores.org Cc: Palmer Dabbelt Cc: Paul Mackerras Cc: "Pavel Machek (CIP)" Cc: Pavel Machek Cc: "Peter Zijlstra (Intel)" Cc: Pierre Morel Cc: Randy Dunlap Cc: Richard Henderson Cc: Rich Felker Cc: Robert Richter Cc: Rob Herring Cc: Russell King Cc: Sam Ravnborg Cc: Sebastian Andrzej Siewior Cc: Sebastian Hesselbarth Cc: sparclinux@vger.kernel.org Cc: Stafford Horne Cc: Stefan Kristiansson Cc: Steven Rostedt Cc: Sudeep Holla Cc: Theodore Dubois Cc: Thomas Bogendoerfer Cc: Thomas Gleixner Cc: Vasily Gorbik Cc: Viresh Kumar Cc: William Cohen Cc: Xiaoming Ni Cc: Yoshinori Sato Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds