Skip to content

Conversation

robertperkel
Copy link
Contributor

Added new driver for MTCH9010 liquid leak detector along with test patterns.

@robertperkel
Copy link
Contributor Author

If possible, could we add this for v4.2

Comment on lines 338 to 340
gpio_pin_set_dt(&config->enableUARTLine, GPIO_OUTPUT_LOW);
} else {
gpio_pin_set_dt(&config->enableUARTLine, GPIO_OUTPUT_HIGH);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

copy-paste error from previous block

Copy link
Contributor Author

@robertperkel robertperkel Jun 18, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah, I see. UART EN is active LOW. Clarified intention in comments

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

no the issue is basically the same thing @msalau commented on. You want to be controlling enableCFGLine here, not enableUARTLine??

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks - I think I see the issue now

@robertperkel robertperkel force-pushed the add_mtch9010_rel_v1 branch 3 times, most recently from cf24bb0 to e4ac4a3 Compare June 19, 2025 04:08
@robertperkel robertperkel requested a review from kartben June 19, 2025 04:15
@robertperkel
Copy link
Contributor Author

@kartben I'm looking at the twister failures, and it doesn't seem related to my PR, as I don't utilize with the file system. Can you confirm or rerun/ignore that twister error?

@robertperkel robertperkel requested a review from msalau June 19, 2025 04:16
@kartben
Copy link
Contributor

kartben commented Jun 19, 2025

@kartben I'm looking at the twister failures, and it doesn't seem related to my PR, as I don't utilize with the file system. Can you confirm or rerun/ignore that twister error?

yep, had nothing to do with you, and fixed now :)

data->last_heartbeat = k_uptime_get();

/* Wait for boot-up */
k_msleep(CONFIG_MTCH9010_BOOT_TIME_MS);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just highlighting that this will delay boot up process for all.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Unfortunately, things stop working when I remove this delay. I have some theories, but for now, I'd like to keep this.

LOG_INST_DBG(config->log, "UART setup not enabled");

#ifdef CONFIG_MTCH9010_LOCK_ON_STARTUP
BUILD_ASSERT(true, "MTCH9010_LOCK_ON_STARTUP cannot be set without UART enabled");
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Location of this BUILD_ASSERT() is somewhat strange to me. It is not a part of the initialization routine. I think it should be closer to MTCH9010_DEFINE() and be checked at build time.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Moved assertion to define section 👍

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please do not resolve comments. This is for the reviewers to do

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

My bad - thanks for letting me know

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The BUILD_ASSERT keeps causing issues, and since this is an optional feature anyway, I've removed the BUILD_ASSERT.

@robertperkel robertperkel force-pushed the add_mtch9010_rel_v1 branch 3 times, most recently from 511c14e to 3b46797 Compare June 19, 2025 19:17
@robertperkel robertperkel requested a review from msalau June 19, 2025 19:50
@robertperkel
Copy link
Contributor Author

Looks like everything is good to go on our side 👍 Local test bench is functioning as expected

@robertperkel
Copy link
Contributor Author

Hi @msalau @kartben ,
Since the feature freeze date for v4.2 is this Friday, could you let me know any remaining changes and/or approve the PR?

Additionally - do I need to notify anyone of this for v4.2, or is it automatic?

Thanks for your feedback!
Robert

@kartben kartben added this to the v4.2.0 milestone Jun 23, 2025
@kartben
Copy link
Contributor

kartben commented Jun 23, 2025

Hi @msalau @kartben , Since the feature freeze date for v4.2 is this Friday, could you let me know any remaining changes and/or approve the PR?

Additionally - do I need to notify anyone of this for v4.2, or is it automatic?

Thanks for your feedback! Robert

I am marking it as tentative for 4.2 but my guess is that it will be tight as it is quite a significant PR and it will take time for reviewers to go through it. Thanks!

@JarmouniA
Copy link
Contributor

Sonar Qube issue needs attention
https://sonarcloud.io/project/issues?sinceLeakPeriod=true&issueStatuses=OPEN%2CCONFIRMED&pullRequest=91812&id=zephyrproject-rtos_zephyr&open=AZhIWhdx99fIPT0PFtnv

In general, you should not be validating the value of DT properties that have enum/range in binding, bcz it's done during DT parsing.

@robertperkel robertperkel force-pushed the add_mtch9010_rel_v1 branch 5 times, most recently from 1386716 to b73a750 Compare August 20, 2025 20:15
Copy link

@robertperkel
Copy link
Contributor Author

SonarQube now passing

@robertperkel
Copy link
Contributor Author

@msalau @kartben @MaureenHelm

All of the requested changes have been made - can you review and approve, so we can close this PR?

@robertperkel
Copy link
Contributor Author

@msalau @kartben @MaureenHelm Can you re-review the PR for 4.3?

@robertperkel
Copy link
Contributor Author

Do I need to do anything else for it to be merged, or is it automatic?

@kartben
Copy link
Contributor

kartben commented Oct 17, 2025

Do I need to do anything else for it to be merged, or is it automatic?

You're all set. It will be merged shortly :)

@kartben kartben closed this Oct 17, 2025
@kartben kartben reopened this Oct 17, 2025
@kartben
Copy link
Contributor

kartben commented Oct 17, 2025

I am triggering a fresh CI run since the last one was pretty old, just in case

@zephyrbot zephyrbot added area: Boards/SoCs area: Tests Issues related to a particular existing or missing test area: Devicetree Bindings labels Oct 17, 2025
@zephyrbot zephyrbot requested a review from nashif October 17, 2025 16:54
@robertperkel
Copy link
Contributor Author

Looks like Twister build prep is failing - I don't think that's on my side?

@kartben
Copy link
Contributor

kartben commented Oct 17, 2025

Looks like Twister build prep is failing - I don't think that's on my side?

ah :| you actually need to rebase on main, please. It won't dismiss your existing approvals :)

Added support for MTCH9010 and applied edits from reviewers.

Signed-off-by: Robert Perkel <[email protected]>
Added testsuite to verify MTCH9010 sensor driver

Signed-off-by: Robert Perkel <[email protected]>
Copy link

@cfriedt cfriedt merged commit 228f0a4 into zephyrproject-rtos:main Oct 18, 2025
26 checks passed
@robertperkel robertperkel deleted the add_mtch9010_rel_v1 branch October 18, 2025 01:10
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

area: Boards/SoCs area: Devicetree Bindings area: Sensors Sensors area: Tests Issues related to a particular existing or missing test

Projects

None yet

Development

Successfully merging this pull request may close these issues.

7 participants