Now that the driver core allows for struct class to be in read-only
memory, move the xillybus_class structure to be declared at build time
placing it into read-only memory, instead of having to be dynamically
allocated at load time.
Cc: Eli Billauer <eli.billauer@gmail.com>
Cc: Arnd Bergmann <arnd@arndb.de>
Suggested-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Ivan Orlov <ivan.orlov0322@gmail.com>
Acked-by: Eli Billauer <eli.billauer@gmail.com>
Link: https://lore.kernel.org/r/20230620143751.578239-18-gregkh@linuxfoundation.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The module pointer in class_create() never actually did anything, and it
shouldn't have been requred to be set as a parameter even if it did
something. So just remove it and fix up all callers of the function in
the kernel tree at the same time.
Cc: "Rafael J. Wysocki" <rafael@kernel.org>
Acked-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Link: https://lore.kernel.org/r/20230313181843.1207845-4-gregkh@linuxfoundation.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
@unit_mutex protects @unit from being freed, so obviously it should be
released after @unit is used, and not before.
This is a follow-up to commit 282a4b7181 ("char: xillybus: Prevent
use-after-free due to race condition") which ensures, among others, the
protection of @private_data after @unit_mutex has been released.
Reported-by: Hyunwoo Kim <imv4bel@gmail.com>
Signed-off-by: Eli Billauer <eli.billauer@gmail.com>
Link: https://lore.kernel.org/r/20221117071825.3942-1-eli.billauer@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To move the list iterator variable into the list_for_each_entry_*()
macro in the future it should be avoided to use the list iterator
variable after the loop body.
To *never* use the list iterator variable after the loop it was
concluded to use a separate iterator variable instead of a
found boolean [1].
This removes the need to use a found variable and simply checking if
the variable was set, can determine if the break/goto was hit.
Link: https://lore.kernel.org/all/CAHk-=wgRr_D8CB-D9Kg-c=EHreAsk5SqXPwr9Y7k9sA6cWXJ6w@mail.gmail.com/
Acked-by: Eli Billauer <eli.billauer@gmail.com>
Signed-off-by: Jakob Koschel <jakobkoschel@gmail.com>
Link: https://lore.kernel.org/r/20220324070939.59297-1-jakobkoschel@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
MODULE_VERSION is useless for in-kernel drivers, so these are removed from
files in drivers/char/xillybus/
Reported-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Eli Billauer <eli.billauer@gmail.com>
Link: https://lore.kernel.org/r/20210528092242.51104-2-eli.billauer@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This patch is a preparation for adding another related driver, XillyUSB.
In order to share some code between the existing Xillybus driver and the
one to be added, some functions are moved to xillybus_class.c
XILLYBUS_CLASS is added to Kconfig and is common to all drivers in this
group. The relation with the existing XILLYBUS symbol is "select" rather
than "depends on" XILLYBUS_CLASS, or else "make olddefconfig" will silently
turn off XILLYBUS, which is currently enabled in several distributions.
XILLYBUS_CLASS doesn't depend on anything else, hence using it with
"select" poses no risk for a broken configuration.
After the future addition of the XillyUSB module, the tree of symbols
will be as follows:
XILLYBUS_CLASS --+-- XILLYBUS --+-- XILLYBUS_PCIE
| |
| +-- XILLYBUS_OF
|
+-- XILLYUSB
XILLYBUS is for drivers based upon memory registers + DMA-based interfaces,
and it's combined with XILLYBUS_PCIE and/or XILLYBUS_OF.
XILLYUSB is for the USB variant only.
Or a more detailed, bottom-up outline:
* CONFIG_XILLYBUS_PCIE -> xillybus_pcie.c: Functions related to PCIe.
* CONFIG_XILLYBUS_OF -> xillybus_of.c: Functions related to Xillybus as a
peripheral on an FPGA / Processor combo chip.
* CONFIG_XILLYBUS -> xillybus_core.c: Functions that are common to the two
above, mainly access to the peripheral with memory-mapped registers and
DMA.
* CONFIG_XILLYUSB -> xillyusb.c: The driver for the USB variant, accesses
the peripheral through the USB framework.
* CONFIG_XILLYBUS_CLASS -> xillybus_class.c: The new module, which contains
the class and API parts that would otherwise appear both in
xillybus_core.c and xillyusb.c. Contains utility functions for the two
latter.
And since I'm at it, comments on the module names are added in the
Kconfig's help part.
The functions are exported with the non-GPL EXPORT_SYMBOL (a matter of
taste).
Signed-off-by: Eli Billauer <eli.billauer@gmail.com>
Link: https://lore.kernel.org/r/20210526100311.56327-2-eli.billauer@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
