> -----Original Message----- > From: Guenter Roeck <groeck7@xxxxxxxxx> On Behalf Of Guenter Roeck > Sent: Friday, October 27, 2023 5:52 PM > To: Matyas, Daniel <Daniel.Matyas@xxxxxxxxxx> > Cc: Jean Delvare <jdelvare@xxxxxxxx>; Jonathan Corbet > <corbet@xxxxxxx>; linux-hwmon@xxxxxxxxxxxxxxx; linux- > doc@xxxxxxxxxxxxxxx; linux-kernel@xxxxxxxxxxxxxxx > Subject: Re: [PATCH v5 2/4] hwmon: max31827: Add support for > max31828 and max31829 > > [External] > > On 10/27/23 06:00, Matyas, Daniel wrote: > [ ... ] > > >> I also don't understand why that would be chip specific. I don't see > >> anything along that line in the datasheet. > >> > >> Ah, wait ... I guess that is supposed to reflect the chip default. > >> I don't see why the chip default makes a difference - a well defined > >> default must be set either way. Again, there is no guarantee that the > >> chip is in its default state when the driver is loaded. > > > > The well defined default was set in v4, but I deleted it, because the > default value in hex for max31827 and max31828 alarm polarity, and > max31827 fault queue is 0x0. I had 2 #defines for these values, but you > said: > > " Since MAX31827_ALRM_POL_LOW is 0, this code doesn't really do > anything and just pollutes the code." > > > > So, I thought I should remove it altogether, since res is set to 0 in the > beginning and the default value of these chips (i.e. 0) is implicitly set. > > > >> > >> Also, why are the default values added in this patch and not in the > >> previous patch ? > >> > > > > In v4 these default values were set in the previous patch. > > > > I asked you (or meant to ask you) to stop overwriting 0 with 0 in a > variable. I didn't mean to ask you (if I did) to stop writing the default value > into the chip. Sorry if I did; if so, that was a misunderstanding. > > Guenter Well, writing the default value into res, would just overwrite 0 with 0. Should I still do it? Daniel
