Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

drivers: sensor: ltc4162: Add ltc4162 step-down charger support #35317

Closed

Conversation

Navin-Sankar
Copy link
Member

Add supports for LTC4162 step-down battery charger driver support with sample application

Signed-off-by: Navin Sankar Velliangiri navin@linumiz.com

@github-actions github-actions bot added area: API Changes to public APIs area: Devicetree area: Devicetree Binding PR modifies or adds a Device Tree binding area: Documentation area: Samples Samples area: Tests Issues related to a particular existing or missing test labels May 17, 2021
@Navin-Sankar Navin-Sankar force-pushed the ltc4162-charger branch 2 times, most recently from f312456 to 7ac9592 Compare May 17, 2021 05:12
@zephyrbot zephyrbot added the area: Sensors Sensors label May 17, 2021
@zephyrbot zephyrbot requested a review from avisconti May 17, 2021 13:16
@Navin-Sankar
Copy link
Member Author

@mbolivar-nordic @avisconti @MaureenHelm requesting for review.

@Navin-Sankar
Copy link
Member Author

@carlescufi as mentioned in this issue, consumed sensor driver API to handle the battery charging attributes.

@Navin-Sankar
Copy link
Member Author

The PR has been opened for more than a one & half month now, can I get some update?

@parthitce
Copy link
Member

@MaureenHelm @carlescufi @mbolivar-nordic Can this be tagged for 2.7?

Copy link
Contributor

@mbolivar-nordic mbolivar-nordic left a comment

Choose a reason for hiding this comment

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

Hi, I found an issue with the binding. I saw a couple of other things too, but I did not review the driver in detail.

bat_short_fault = 1
};

/* Individual Bits are mutually exclusive */
Copy link
Contributor

Choose a reason for hiding this comment

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

Same here; just use BIT().

Copy link
Contributor

@mbolivar-nordic mbolivar-nordic left a comment

Choose a reason for hiding this comment

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

Ah, one more thing, sorry.

@carlescufi
Copy link
Member

@mbolivar-nordic could you please re-review?
@Navin-Sankar could you please rebase?

@carlescufi carlescufi requested a review from gmarull August 16, 2021 17:57
Copy link
Member

@gmarull gmarull left a comment

Choose a reason for hiding this comment

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

I've done a quick review, please check comments.

Comment on lines 53 to 78
enum charger_status {
CHARGER_STATUS_CHARGING,
CHARGER_STATUS_DISCHARGING,
CHARGER_STATUS_NOT_CHARGING,
CHARGER_STATUS_UNKNOWN,
CHARGER_STATUS_FULL,
};

/**
* @brief What algorithm is charger using
*/
enum charge_type {
CHARGER_CHARGE_TYPE_NONE,
CHARGER_CHARGE_TYPE_TRICKLE,
CHARGER_CHARGE_TYPE_FAST,
};

/**
* @brief Charger health
*/
enum charger_health {
CHARGER_HEALTH_UNKNOWN,
CHARGER_HEALTH_GOOD,
CHARGER_HEALTH_DEAD,
CHARGER_HEALTH_UNSPEC_FAILURE,
};
Copy link
Member

Choose a reason for hiding this comment

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

I'm not sure if these should be driver specific (private), @MaureenHelm ?

Comment on lines 238 to 253
const struct device *dev = DEVICE_DT_GET_ANY(adi_ltc4162);

if (dev == NULL) {
printk("Failed to get device\n");
return;
}
Copy link
Member

Choose a reason for hiding this comment

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

DEVICE_DT_GET_ONE can be used to obtain a build failure. cc: @mbolivar-nordic we should likely settle on DEVICE_DT_GET_ONE :-)

Copy link
Contributor

Choose a reason for hiding this comment

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

@mbolivar-nordic we should likely settle on DEVICE_DT_GET_ONE :-)

agree to disagree I guess :)

Copy link
Contributor

Choose a reason for hiding this comment

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

agree to disagree I guess :)

To amplify on my comment for the sake of this particular PR:

As I have already discussed with @gmarull elsewhere, the DEVICE_DT_GET_ONE build error message is very confusing and doesn't really indicate the problem.

Deferring the error to runtime with DEVICE_DT_GET_ANY isn't as good as getting a build error in some ways, but it's also better in others, because you get an error message you can understand.

Different people will value these two tradeoffs differently, and that's fine. I don't think there is a one-size-fits-all answer to which macro to use, and think the author of a sample -- in this case @Navin-Sankar -- should be allowed to decide what works for them.

Copy link
Member Author

Choose a reason for hiding this comment

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

using DEVICE_DT_GET_ANY macro to get the device

@github-actions github-actions bot closed this Aug 23, 2022
@Navin-Sankar Navin-Sankar reopened this Aug 23, 2022
@zephyrbot zephyrbot requested a review from teburd August 23, 2022 05:27
@github-actions github-actions bot closed this Sep 7, 2022
@parthitce parthitce removed the Stale label Sep 7, 2022
@parthitce parthitce reopened this Sep 7, 2022
@github-actions
Copy link

github-actions bot commented Nov 7, 2022

This pull request has been marked as stale because it has been open (more than) 60 days with no activity. Remove the stale label or add a comment saying that you would like to have the label removed otherwise this pull request will automatically be closed in 14 days. Note, that you can always re-open a closed pull request at any time.

@github-actions github-actions bot added the Stale label Nov 7, 2022
@github-actions github-actions bot closed this Nov 22, 2022
@Navin-Sankar Navin-Sankar reopened this Nov 22, 2022
@github-actions github-actions bot closed this Dec 7, 2022
Navin Sankar Velliangiri added 2 commits January 17, 2023 11:58
Add sensor channels useful for battery charger.

Signed-off-by: Navin Sankar Velliangiri <navin@linumiz.com>
Implementation of LTC4162 step-down battery charger support.

Signed-off-by: Navin Sankar Velliangiri <navin@linumiz.com>
@Navin-Sankar
Copy link
Member Author

@MaureenHelm Rebased to main, please revisit.

@carlescufi
Copy link
Member

@mbolivar-nordic @gmarull please revisit
@parthitce @avisconti @teburd could you please review?

@github-actions github-actions bot removed the Stale label Jan 18, 2023
@mbolivar-nordic mbolivar-nordic dismissed their stale review January 18, 2023 15:54

not working on bindings anymore

@github-actions
Copy link

This pull request has been marked as stale because it has been open (more than) 60 days with no activity. Remove the stale label or add a comment saying that you would like to have the label removed otherwise this pull request will automatically be closed in 14 days. Note, that you can always re-open a closed pull request at any time.

@github-actions github-actions bot added the Stale label Mar 20, 2023
@github-actions github-actions bot closed this Apr 3, 2023
@Navin-Sankar Navin-Sankar reopened this Apr 3, 2023
@zephyrbot zephyrbot requested a review from yperess April 3, 2023 14:12
@github-actions github-actions bot removed the Stale label Apr 17, 2023
@github-actions
Copy link

This pull request has been marked as stale because it has been open (more than) 60 days with no activity. Remove the stale label or add a comment saying that you would like to have the label removed otherwise this pull request will automatically be closed in 14 days. Note, that you can always re-open a closed pull request at any time.

@github-actions github-actions bot added the Stale label Jun 16, 2023
@github-actions github-actions bot closed this Jun 30, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area: API Changes to public APIs area: Devicetree Binding PR modifies or adds a Device Tree binding area: Devicetree area: Documentation area: Samples Samples area: Sensors Sensors area: Tests Issues related to a particular existing or missing test Stale
Projects
None yet
Development

Successfully merging this pull request may close these issues.

8 participants