dts: Move vendor-specific dtsi to dedicated folder

[decsny]

Move all the vendor-specific dtsi files that were in dts/common to a new folder under dts/ designated for vendor-specific files, since they are not common at all, except for one vendor.

Change MAINTAINERS.yml to reflect the moving of the files.

The purpose of this change is mainly so that I don't have to keep adding files-exclude entries to the DT maintainer area, since DT maintainers do not want to review these vendor files changes.

[nordicjm]

This is a breaking change for all out of tree users

[decsny]

This is a breaking change for all out of tree users

So do you not want to do it? Since it's mostly an aesthetic change I'm not gonna push for it. Although I don't think it's the most horrible thing to break, the error will just be like "file not found" from the preprocessor and not hard to fix

Personally though I think the fact that the common/ part of the path was being used is not great, it makes those files too coupled to the directory structure. It wasn't even necessary, you can include those files without the common/ part of the path already, which is already done in many places in tree for these files, and I didn't have to change those, so I think these in tree files needed to be changed anyways and out of trees should do the same

[nordicjm]

This is a breaking change for all out of tree users

So do you not want to do it? Since it's mostly an aesthetic change I'm not gonna push for it. Although I don't think it's the most horrible thing to break, the error will just be like "file not found" from the preprocessor and not hard to fix

Personally though I think the fact that the common/ part of the path was being used is not great, it makes those files too coupled to the directory structure. It wasn't even necessary, you can include those files without the common/ part of the path already, which is already done in many places.

Fine for doing it, makes things neater, but this is a breaking change with no deprecation so https://docs.zephyrproject.org/latest/develop/api/api_lifecycle.html#introducing-breaking-api-changes sort of applies (plus needs something in migration guide)

[decsny]

This is a breaking change for all out of tree users

So do you not want to do it? Since it's mostly an aesthetic change I'm not gonna push for it. Although I don't think it's the most horrible thing to break, the error will just be like "file not found" from the preprocessor and not hard to fix
Personally though I think the fact that the common/ part of the path was being used is not great, it makes those files too coupled to the directory structure. It wasn't even necessary, you can include those files without the common/ part of the path already, which is already done in many places.

Fine for doing it, makes things neater, but this is a breaking change with no deprecation so https://docs.zephyrproject.org/latest/develop/api/api_lifecycle.html#introducing-breaking-api-changes sort of applies (plus needs something in migration guide)

I'm going to be honest, my judgement says that removing one of the two ways to reference some specific files in an #include directive does not need to go through API lifecycle , but I can agree with putting it in migration guide. I am open to opinions from release team about the former . @kartben

Also I think if we wanted to have a deprecation phase for allowing the common/ prefix then that would require having the file in two places which is IMO much worse than a tiny build error

[mbolivar]

With my maintainer hat on, I can see this is a reasonable cleanup. But with my user hat on, I hate the senseless churn. I agree with @decsny that we haven't ever settled the question that DTSI is API, but we also haven't definitively said it's "not API" and from a user's perspective it sure walks and quacks like an API.

Is the benefit gained by the cleanup really worth breaking all these users' boards without even so much as a deprecation? It feels to me like the effort required to write and test a script that has a preprocessor warning and then includes the new location could be measured in a few hours, and it would definitely save way more than a few hours of total user time, so I think it's reasonable to ask for.

[decsny]

With my maintainer hat on, I can see this is a reasonable cleanup. But with my user hat on, I hate the senseless churn. I agree with @decsny that we haven't ever settled the question that DTSI is API, but we also haven't definitively said it's "not API" and from a user's perspective it sure walks and quacks like an API.

Is the benefit gained by the cleanup really worth breaking all these users' boards without even so much as a deprecation? It feels to me like the effort required to write and test a script that has a preprocessor warning and then includes the new location could be measured in a few hours, and it would definitely save way more than a few hours of total user time, so I think it's reasonable to ask for.

Personally, I think it's reasonable to just make the change. Updating Zephyr versions unfortunately always comes with a mega amount of hassles in my experience (I have had to do a few version updates of a fork), and speaking from experience, one #include directive having a "not found" error is extremely trivial in the grand scheme of doing a version update for a board. Especially now that we have the migration guide which is exactly for situations like this. I didn't have the migration guide when I had to update the version of a fork in the past a few times, would have been nice to have something like that.

[nordicjm]

needs to go to 4.2 migration guide

[rruuaanng]

Looks good. Although there are quite a few files to move, I think it's worth it.

[mbolivar]

@decsny looks like there are some conflicts to resolve