mirror of
https://github.com/torvalds/linux.git
synced 2026-07-30 03:01:41 +02:00
Linux kernel source tree
e1d0770035
Alex Elder says: ==================== net: ipa: generalized register definitions This series is quite a bit bigger than what I normally like to send, and I apologize for that. I would like it to get incorporated in its entirety this week if possible, and splitting up the series carries a small risk that wouldn't happen. Each IPA register has a defined offset, and in most cases, a set of masks that define the width and position of fields within the register. Most registers currently use the same offset for all versions of IPA. Usually fields within registers are also the same across many versions. Offsets and fields like this are defined using preprocessor constants. When a register has a different offset for different versions of IPA, an inline function is used to determine its offset. And in places where a field differs between versions, an inline function is used to determine how a value is encoded within the field, depending on IPA version. Starting with IPA version 5.0, the number of IPA endpoints supported is greater than 32. As a consequence, *many* IPA register offsets differ considerably from prior versions. This increase in endpoints also requires a lot of field sizes and/or positions to change (such as those that contain an endpoint ID). Defining these things with constants is no longer simple, and rather than fill the code with one-off functions to define offsets and encode field values, this series puts in place a new way of defining IPA registers and their fields. Note that this series creates this new scheme, but does not add IPA v5.0+ support. An enumerated type will now define a unique ID for each IPA register. Each defined register will have a structure that contains its offset and its name (a printable string). Each version of IPA will have an array of these register structures, indexed by register ID. Some "parameterized" registers are duplicated (this is not new). For example, each endpoint has an INIT_HDR register, and the offset of a given endpoint's INIT_HDR register is dependent on the endpoint number (the parameter). In such cases, the register's "stride" is defined as the distance between two of these registers. If a register contains fields, each field will have a unique ID that's used as an index into an array of field masks defined for the register. The register structure also defines the number of entries in this field array. When a register is to be used in code, its register structure will be fetched using function ipa_reg(). Other functions are then used to determine the register's offset, or to encode a value into one of the register's fields, and so on. Each version of IPA defines the set of registers that are available, including all fields for these registers. The array of defined registers is set up at probe time based on the IPA version, and it is associated with the main IPA structure. ==================== Link: https://lore.kernel.org/r/20220926220931.3261749-1-elder@linaro.org Signed-off-by: Jakub Kicinski <kuba@kernel.org> |
||
|---|---|---|
| arch | ||
| block | ||
| certs | ||
| crypto | ||
| Documentation | ||
| drivers | ||
| fs | ||
| include | ||
| init | ||
| io_uring | ||
| ipc | ||
| kernel | ||
| lib | ||
| LICENSES | ||
| mm | ||
| net | ||
| samples | ||
| scripts | ||
| security | ||
| sound | ||
| tools | ||
| usr | ||
| virt | ||
| .clang-format | ||
| .cocciconfig | ||
| .get_maintainer.ignore | ||
| .gitattributes | ||
| .gitignore | ||
| .mailmap | ||
| COPYING | ||
| CREDITS | ||
| Kbuild | ||
| Kconfig | ||
| MAINTAINERS | ||
| Makefile | ||
| 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 Restructured Text 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.