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
Introduce Charging Subsystem #56666
Introduce Charging Subsystem #56666
Conversation
@@ -0,0 +1,8 @@ | |||
# SPDX-License-Identifier: Apache-2.0 | |||
|
|||
cmake_minimum_required(VERSION 3.20.0) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
please add tests into a separate commit to ease review
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
sure, I can split it into two commits:
- Introduces the driver
- Adds tests
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
#56666 (comment)
I don't want to mess up the existing comments by splitting up the commits. I'll split it up once this comment is resolved.
7ea3e77
to
1484160
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Needs compliance fixes but I like it
I mean to add... just like the fuel gauge API... this could use with a notification mechanism for status changes. I believe many of the fuel gauge and charger ICs have a gpio line that can be hooked on to for catching interrupts to trigger event handling for things like charger status changes, fuel gauge level sets and such. That can be done in subsequent work but it would be great to see a plan for it done soon for both of these APIs. |
Perhaps I wasn't clear enough when I spoke during the meeting @rriveramcrus, my mistake. I have not followed the development of this PR nor I know charging in general, so if I gave the impression of giving my acquiescence then it was the wrong impression. I just don't have an opinion one way or the other due to lack of knowledge in the area.
It is however common practice to implement a driver from at least two different vendors to ensure that we cover the hardware diversity as best as possible. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the followup, one leftover file and one comment still open about the parameter handling, repeating here: I think that comment is relevant, though it also applies to the fuel gauge APIs so I see why you did it like that, I'll work with @aaronemassey separately on having that one fixed, I don't think it should stay in the current form.
include/zephyr/drivers/charger.h
Outdated
static inline int z_impl_charger_get_prop(const struct device *dev, | ||
struct charger_get_property *prop) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hey I think this is still an open point and I agree with Gerard that this should take a (dev, prop, &val)
as an argument, having the property embedding the value is very weird, looks like an ioctl or something. I see that this mimics the fuel gauge APIs though so I understnad the motivation, I'll talk with @aaronemassey about reviewing that one as well as I think it should get the same modifications.
Apologies for throwing you off track, but in the end this is a good chance to review both APIs and get them cleaned and coherent.
Thanks @rriveramcrus, I think my last concern is with how the get/set arguments are defined, basically @gmarull comment at 1afad57#r1205212874. I had a good chat with @aaronemassey since that's in the fuel gauge api as well and if anything the two should be aligned. |
Likewise chatted with Aaron yesterday. The recommended changes work for me, ack. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks, few more comments but I like how the get/set are organized now, @gmarull can you take a look at how the subsystem API is defined now?
Add initial charger driver API with the most basic of native_posix driver tests. Signed-off-by: Ricardo Rivera-Matos <rriveram@opensource.cirrus.com>
Adds a sample sbs charger driver and basics tests. Signed-off-by: Ricardo Rivera-Matos <rriveram@opensource.cirrus.com>
Adds a short stub doc as a placeholder for future documentation in the charger API. Signed-off-by: Ricardo Rivera-Matos <rriveram@opensource.cirrus.com>
@gmarull bump, it's been a week since the get/set changes were pushed up. |
I have lost track of this extremely lengthy discussion going back and forward between suggested solutions.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hi @rriveramcrus!
Congratulations on getting your very first Zephyr pull request merged 🎉🥳. This is a fantastic achievement, and we're thrilled to have you as part of our community!
To celebrate this milestone and showcase your contribution, we'd love to award you the Zephyr Technical Contributor badge. If you're interested, please claim your badge by filling out this form: Claim Your Zephyr Badge.
Thank you for your valuable input, and we look forward to seeing more of your contributions in the future! 🪁
Introduce a Battery Charging API #56635