79e6b0e0f6
As of today <zephyr/zephyr.h> is 100% equivalent to <zephyr/kernel.h>. This patch proposes to then include <zephyr/kernel.h> instead of <zephyr/zephyr.h> since it is more clear that you are including the Kernel APIs and (probably) nothing else. <zephyr/zephyr.h> sounds like a catch-all header that may be confusing. Most applications need to include a bunch of other things to compile, e.g. driver headers or subsystem headers like BT, logging, etc. The idea of a catch-all header in Zephyr is probably not feasible anyway. Reason is that Zephyr is not a library, like it could be for example `libpython`. Zephyr provides many utilities nowadays: a kernel, drivers, subsystems, etc and things will likely grow. A catch-all header would be massive, difficult to keep up-to-date. It is also likely that an application will only build a small subset. Note that subsystem-level headers may use a catch-all approach to make things easier, though. NOTE: This patch is **NOT** removing the header, just removing its usage in-tree. I'd advocate for its deprecation (add a #warning on it), but I understand many people will have concerns. Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no> |
||
|---|---|---|
| .. | ||
| src | ||
| CMakeLists.txt | ||
| README.txt | ||
| prj.conf | ||
| testcase.yaml | ||
README.txt
SDHC API Test ################## This test is designed to verify the functionality of a device implementing the SD host controller API. It requires that an SD card be present on the SD bus to pass. The test has the following phases: * Reset test: Verify the SDHC can successfully reset the host controller state. This primarily tests that the driver returns zero for this call, although if the reset left the SDHC in a bad state subsequent tests may fail. * Host props: Get host properties structure from SDHC. This verifies that the API returns a valid host property structure (at a minimum, the driver must initialize all fields of the structure to zero.) * Set_IO test: Verify that the SDHC will reject clock frequencies outside of the frequency range it claims to support via sdhc_get_host_props. * Card presence test. Verify that the SDHC detects card presence. * Request test: Make a request to read the card interface condition, and verify that valid data is returned. Note that this test does not verify the tuning or card busy api, as the SD specification is state based, and testing these portions of the SDHC would require implementing a large portion of the SD subsystem in this test.