757508d6d7
Convert single bit-field macros to simple masks. The change makes the masks more universal. Multi bit-field macros are changed in the next commit. After both changes, all masks in xhci-caps.h will follow the same format. I plan to introduce this change to all xhci macros. Bit shift operations on a 32-bit signed can be problematic on some architectures. Instead use BIT() macro, which returns a 64-bit unsigned value. This ensures that the shift operation is performed on an unsigned type, which is safer and more portable across different architectures. Using unsigned integers for bit shifts avoids issues related to sign bits and ensures consistent behavior. Switch from 32-bit to 64-bit? As far as I am aware, this does not cause any issues. Performing bitwise operations between 32 and 64 bit values, the smaller operand is promoted to match the size of the larger one, resulting in a 64-bit operation. This promotion extends the 32-bit value to 64 bits, by zero-padding (for unsigned). Will the change to 64-bit slow down the xhci driver? On a 64-bit architecture - No. On a 32-bit architecture, yes? but in my opinion the performance decrease does not outweigh the readability and other benefits of using BIT() macro. Why not use FIELD_GET() and FIELD_PREP()? While they can be used for single bit macros, I prefer to use simple bitwise operation directly. Because, it takes less space, is less overhead and is as clear as if using FIELD_GET() and FIELD_PREP(). Why not use test_bit() macro? Same reason as with FIELD_GET() and FIELD_PREP(). Suggested-by: Sakari Ailus <sakari.ailus@linux.intel.com> Reviewed-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Niklas Neronin <niklas.neronin@linux.intel.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://patch.msgid.link/20251119142417.2820519-23-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> |
||
|---|---|---|
| Documentation | ||
| LICENSES | ||
| arch | ||
| block | ||
| certs | ||
| crypto | ||
| drivers | ||
| fs | ||
| include | ||
| init | ||
| io_uring | ||
| ipc | ||
| kernel | ||
| lib | ||
| mm | ||
| net | ||
| rust | ||
| samples | ||
| scripts | ||
| security | ||
| sound | ||
| tools | ||
| usr | ||
| virt | ||
| .clang-format | ||
| .clippy.toml | ||
| .cocciconfig | ||
| .editorconfig | ||
| .get_maintainer.ignore | ||
| .gitattributes | ||
| .gitignore | ||
| .mailmap | ||
| .pylintrc | ||
| .rustfmt.toml | ||
| COPYING | ||
| CREDITS | ||
| Kbuild | ||
| Kconfig | ||
| MAINTAINERS | ||
| Makefile | ||
| README | ||
README
Linux kernel
============
There are several guides for kernel developers and users. These guides can
be rendered in a number of formats, like HTML and PDF. Please read
Documentation/admin-guide/README.rst first.
In order to build the documentation, use ``make htmldocs`` or
``make pdfdocs``. The formatted documentation can also be read online at:
https://www.kernel.org/doc/html/latest/
There are various text files in the Documentation/ subdirectory,
several of them using the reStructuredText markup notation.
Please read the Documentation/process/changes.rst file, as it contains the
requirements for building and running the kernel, and information about
the problems which may result by upgrading your kernel.