Kumar Gala

Been thinking about where do we keep the association of API and driver compatible. I'm thinking a new YAML file that describes the driver features. The idea here is to...

> ``` > > ``` > > > > > > The apis are simply the __subsystem struct i2c_driver_api structs with the _driver_api removed. This is how gen_defines > knows...

> Note regarding bindings `api` field: I think our goal should be to align with [dt-schema](https://github.com/devicetree-org/dt-schema), so the more we customize our own flavor of bindings, the more difficult it...

> Okay, so we will have a dts/bindings for hardware, and device/bindings or similar for software, both sharing the compatible property to bind them together, since the software and hardware...

> Is this an issue I should undertake in this PR? And if so, can we agree on the schema so i can implement it? > I propose zephyr/bindings so...

@tejlmand would love your input on this and how we might integrate this week the build system (Kconfig, Cmake) from a consistency point of view, as well if we could...

Add links to some discussion PRs around the topic of file metadata: https://github.com/zephyrproject-rtos/zephyr/issues/49431 https://github.com/zephyrproject-rtos/zephyr/issues/38725#issuecomment-1055570100

a few questions: * How do we associate this information with the file(s), kconfig symbols, and devicetree compatible? * How do we ensure this information is set and consistent with...

Hmm, curious about if we think a compatible w/o vendor means, no model. For example: `compatible = "ns16550";` seems like model being `ns16550` would be reasonable. @mbolivar-nordic @MaureenHelm thoughts?

> @galak do you really mean to say "no model"? I'm confused because your example seems to be saying the opposite: compatible without vendor means the compatible is the model,...