Mocking components for linux should allow some method to "pretend" its related toa real physical "on chip" device or sane defaults. (IDFGH-14769)

[i400s]

Is your feature request related to a problem?

Setting up some testing for a mcp9808 component on "device" linux using gpio mocks my program failed to compile with an error related to GPIO_IS_VALID_GPIO(gpio_num) which my program used to validate the input of a function.

Compiling using mocks but "on chip" for the "esp32c6" worked with no issues.

Compiling using mocks but "on host" for "linux" failed.

Eventually I worked out that the issue was with what gets pulled in from soc.caps.h

Values such as SOC_GPIO_VALID_GPIO_MASK are used to create test functions such as GPIO_IS_VALID_GPIO but when the device is "linux" those values are not set.

As a workaround I just removed the code that checked for a valid GPIO using the macro within gpio.h, that pulled other macro values from soc.caps.h, and replaced it with a test using GPIO_NUM_MAX from the gpio_num.h file.

Describe the solution you'd like.

Ideally there should be both sane defaults for a generic "linux" device but also some method of being able to say "I am compiling for the linux device but it should use the defaults from the "esp32c6" (or other) device.

I'm very new to the concept of mocks, but am finding them great for testing real world events/data that might not be easily generated using a physical device. A classic example would be to return temperature values from a device without requiring the device sample real world temperatures. Or to test a device is accessible, and what might happen should the device suddenly disconnect from say the i2c bus.

If I'm testing that my gpio attached component code works then it should be possible to use the standard esp-idf gpio macro's for validation. As I'm testing my code in a generic manner then things such as if a GPIO is valid should have generic, but sane, macros. This could be making assumptions that mocked "linux gpio" (SOC_GPIO_PIN_COUNT) can be any number from 0 to 63 and that -1=Not connected. But, if I was testing a program that would eventually run on a esp32c6 then it should use the values from the esp32c6 soc.caps.h (#define SOC_GPIO_PIN_COUNT 31).

Or as above, but a requirement is that a chip must be set for mocks when compiling for "linux" with no "generic" defaults.

I guess something at the project level such as set(MOCK_CHIP esp32c6) could be used to specify that values should mimic the esp32c6 chip. This would mean that during the cmake generation that soc.caps.h would be pulled from the esp32c6 directory in a similar manner that the mocks are created within the build directory.

Describe alternatives you've considered.

No response

Additional context.

No response