drivers: modem: generalize Quectel BG9X support

[guildeol-stra]

Replace specific reference for Quectel BG95 in Modem Cellular with
BG9x, since the setup code should apply for other members of this
family.

Rename the 'quectel,bg95' DTS binding to 'quectel,bg9x' and add
optional 'mdm-reset-gpios' property.

To avoid confusion, delete the old 'quectel,bg9x' DTS binding and its
implementation.

Fixes #93115

[github-actions]

Hello @guildeol-stra, and thank you very much for your first pull request to the Zephyr project!
Our Continuous Integration pipeline will execute a series of checks on your Pull Request commit messages and code, and you are expected to address any failures by updating the PR. Please take a look at our commit message guidelines to find out how to format your commit messages, and at our contribution workflow to understand how to update your Pull Request. If you haven't already, please make sure to review the project's Contributor Expectations and update (by amending and force-pushing the commits) your pull request if necessary.
If you are stuck or need help please join us on Discord and ask your question there. Additionally, you can escalate the review when applicable. 😊

[guildeol-stra]

Hi, @rerickson1

I think the LTS versions could benefit from this. Can this also be backported?

[rerickson1]

Hi, @rerickson1

I think the LTS versions could benefit from this. Can this also be backported?

Does this issue exist in 3.7?

[guildeol-stra]

Hi, @rerickson1
I think the LTS versions could benefit from this. Can this also be backported?

Does this issue exist in 3.7?

Yes. We use 3.7 as our base version and we first identified the issue there.

[rerickson1]

Hi, @rerickson1
I think the LTS versions could benefit from this. Can this also be backported?

Does this issue exist in 3.7?

Can you please writeup a issue quick so it can be linked to this PR?
This is the official process that should be followed when including a fix like this.

[guildeol-stra]

Hi, @rerickson1
I think the LTS versions could benefit from this. Can this also be backported?

Does this issue exist in 3.7?

Can you please writeup a issue quick so it can be linked to this PR? This is the official process that should be followed when including a fix like this.

Done. Added the link and also amended my commit message because this did not cause a compilation issue, just disabled the config implicitly.

Please let me know if there's anything else needed.

[rerickson1]

Hi, @rerickson1
I think the LTS versions could benefit from this. Can this also be backported?

Does this issue exist in 3.7?

Can you please writeup a issue quick so it can be linked to this PR? This is the official process that should be followed when including a fix like this.

Done. Added the link and also amended my commit message because this did not cause a compilation issue, just disabled the config implicitly.

Please let me know if there's anything else needed.

Looks good. We'll see if its possible to get this bug fix in for 4.2. If not, it will come after.

[bjarki-andreasen]

That was by design :) the bg9x compat is a relic used only by the quectel-bg9x.c driver, modem_cellular (and zephyr in general) requires the devicetree to have specific device compats in the devicetree, like quectel,bg95 (which is why it was added and is used by the modem subsystem)

To elaborate a bit, quectel,bg9x is a malformed devicetree compatible, not a driver :) quectel-bg9x.c and modem_ceullar.c are drivers. These support specific hardware, which is what devicetree compatibles specify. If you have a bg95, or bg96 (something matching the "wildcard" bg9x), that compatible has to be added to zephyr, and the modem_cellular.c driver expanded to support it :)

[rerickson1]

That was by design :) the bg9x compat is a relic used only by the quectel-bg9x.c driver, modem_cellular (and zephyr in general) requires the devicetree to have specific device compats in the devicetree, like quectel,bg95 (which is why it was added and is used by the modem subsystem)

To elaborate a bit, quectel,bg9x is a malformed devicetree compatible, not a driver :) quectel-bg9x.c and modem_ceullar.c are drivers. These support specific hardware, which is what devicetree compatibles specify. If you have a bg95, or bg96 (something matching the "wildcard" bg9x), that compatible has to be added to zephyr, and the modem_cellular.c driver expanded to support it :)

And this is why multiple sets of eyes is best! This isn't really a bug then, right? This should technically be a new feature?

[bjarki-andreasen]

That was by design :) the bg9x compat is a relic used only by the quectel-bg9x.c driver, modem_cellular (and zephyr in general) requires the devicetree to have specific device compats in the devicetree, like quectel,bg95 (which is why it was added and is used by the modem subsystem)
To elaborate a bit, quectel,bg9x is a malformed devicetree compatible, not a driver :) quectel-bg9x.c and modem_ceullar.c are drivers. These support specific hardware, which is what devicetree compatibles specify. If you have a bg95, or bg96 (something matching the "wildcard" bg9x), that compatible has to be added to zephyr, and the modem_cellular.c driver expanded to support it :)

And this is why multiple sets of eyes is best! This isn't really a bug then, right? This should technically be a new feature?

I believe so, but, looking at the commit, without modifications to modem_cellular.c, this PR would still not provide support for the bg9x compat, it would build the driver, but no driver would be instantiated, so maybe there's more to it?

[rerickson1]

The quectel-bg9x.c driver cannot be removed without first deprecating it.
Please see: https://docs.zephyrproject.org/latest/develop/api/api_lifecycle.html

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud