mirror of
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/
synced 2026-10-28 20:03:05 +00:00
No description
- C 96.8%
- Assembly 0.9%
- Rust 0.7%
- Shell 0.6%
- Python 0.5%
- Other 0.3%
7ea79f5366Merge series from Jonas Gorski <jonas.gorski@gmail.com>: This series aims at cleaning up the current multi CS parts and removing the CS limit per controller that was introduced with the multi CS support. To do this, store the assigned chip selects per device in spi_device::num_chipselects, which allows us to use that instead of SPI_CS_CNT_MAX for most loops, as well as remove the check for SPI_INVALID_CS for any chip select. This should hopefully make it obvious that SPI_CS_CNT_MAX only limits accesses to arrays indexed by the number of chip selects of a device, not the controller, and we can remove the check for spi_controller::num_chipselects being less than SPI_CS_CNT_MAX in device registration (which was the wrong place to do that anyway). After having done that, we can reduce SPI_CS_CNT_MAX again to 4 without breaking devices on higher CS lines. Finally, rename SPI_CS_CNT_MAX to SPI_DEVICE_CNT_MAX to make it more clear that this limit only applies to devices, not controllers. There are still more issues left, but these can be addressed in future submissions: * The code allows multi-cs devices for any controller, as long as the device does not set parallel-memories. * No current spi controller driver handles logical chip selects other than the first one, and always use it, regardless what cs_index_mask says. * While most spi controllers should be able to handle devices that have multiple cs that just get enabled selectively, but not at the same time, there is no way to tell that to the core (ties into the above). * There is no parallel memories/multi cs flag for devices, so any implementing driver needs to check the device tree node, making it impossible to register these kind of devices via platform code. |
History
|
|
|---|---|---|
| arch | ||
| block | ||
| certs | ||
| crypto | ||
| Documentation | ||
| drivers | ||
| fs | ||
| include | ||
| init | ||
| io_uring | ||
| ipc | ||
| kernel | ||
| lib | ||
| LICENSES | ||
| 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 | ||
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.