-
Notifications
You must be signed in to change notification settings - Fork 846
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
Add support for MAX31875 #2635
base: main
Are you sure you want to change the base?
Add support for MAX31875 #2635
Conversation
7165f8f
to
4e669bc
Compare
Why the new PR? Should we close #2600? |
I've created this separate PR that introduces an alternative method to add driver support for the MAX31875. This involves using the existing MAX31827 driver to support the MAX31875. |
4e669bc
to
31e479a
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.
I think most of the complexity could go away with a chi_info struture where you have things like different register masks per device. Then accessing it in the code would be for example: st->info->cfg_reg
.
Anyways, i think we can support this new device in the existing driver so I'll close the other PR
|
||
maintainers: | ||
- Daniel Matyas <daniel.matyas@analog.com> | ||
- John Erasmus Mari Geronimo <johnerasmusmari.geronimo@analog.com> |
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.
You should mention this change in the commit message. You'll likely be asked why if we can have a fallback device for this one (one of the devices that the driver already supports). So you should also mention in the commit message why that is not possible.
Also speaking about the commit message, you're only stating the obvious there :). Give a small description of the HW.
4b56b21
to
1a82903
Compare
V2
|
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.
Ok, the chip info structure grew quite a bit but IMHO, it's still better than all the if() else stuff we had before.
Take my inputs and send this upstream.
drivers/hwmon/max31827.c
Outdated
long (*from_16_bit_to_m_dgr)(unsigned int x); | ||
unsigned int (*from_m_dgr_to_16_bit)(long x); | ||
int (*shutdown)(struct max31827_state *st, unsigned int *cnv_rate); | ||
int (*wakeup)(struct max31827_state *st, unsigned int cnv_rate); |
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.
Ok, I did not realized at all that this would need so much fields. That said, I think you can make this much better. See some examples below and then see what you can do...
drivers/hwmon/max31827.c
Outdated
*val = !!uval; | ||
uval = max31827_field_get(st->chip_info->shutdown_mask, | ||
uval); | ||
*val = st->chip_info->is_enabled(uval); |
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.
For example... In here, you already have an is_enabled()
callback per chip. Hence, just implement it in a different way per chip so that you don't really need config_reg
or shutdown_mask
per chip_info. Do you see my point? And if the function is pretty much the same for all the variants and you'r worried about code repetition, just implement a core function that accepts a config_reg
and a shutdown_mask
and build on top of it. Example:
bool __max31827_is_enabled(struct max31827_state *st, unsigned int reg, unsigned int mask)
{
//core generic implementation
}
// This is the per chip callback
bool maxxxxx_is_enabled(struct max31827_state *st, unsigned int reg, unsigned int mask)
{
return __max31827_is_enabled(st, MAXXXXX_REG_CFGm MAXXXX_SHUTDOWN_MASK)
}
See the idea? You might be able to reduce the number of fields significantly...
drivers/hwmon/max31827.c
Outdated
@@ -234,7 +372,7 @@ static int max31827_read(struct device *dev, enum hwmon_sensor_types type, | |||
*/ | |||
|
|||
ret = regmap_update_bits(st->regmap, | |||
MAX31827_CONFIGURATION_REG, | |||
st->chip_info->config_reg, |
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.
Hmm, I see you still need config_reg
in a lot other places but the above point still stands. You could also negate the enable state in proper variant callback (which is the only thing you're doing now in the is_enabled() function which is a bit odd)
Think about it and see if we can reduce the number of fields somehow.
drivers/hwmon/max31827.c
Outdated
@@ -503,15 +641,19 @@ static int max31827_init_client(struct max31827_state *st, | |||
fwnode = dev_fwnode(dev); | |||
|
|||
st->enable = true; | |||
res |= MAX31827_DEVICE_ENABLE(1); | |||
res |= st->chip_info->device_enable(1); |
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.
maybe an init_client callback per chip (in the same way I explained above) would also reduce things a bit...
…_info Introduced chip_info structure to replace enum chips Signed-off-by: John Erasmus Mari Geronimo <johnerasmusmari.geronimo@analog.com>
Add max31875 to dt-bindings of max31827 MAX31875 is low-power I2C temperature sensor similar to MAX31827 Signed-off-by: John Erasmus Mari Geronimo <johnerasmusmari.geronimo@analog.com>
1a82903
to
89c000e
Compare
Add support for MAX31875 Low-Power I2C Temperature Sensor in MAX31827 driver Signed-off-by: John Erasmus Mari Geronimo <johnerasmusmari.geronimo@analog.com>
89c000e
to
ca0fff8
Compare
V3
|
PR Description
PR Type
PR Checklist