Re: [PATCH v2 2/2] hwmon: Add driver for Texas Instruments TMP464 sensor chip

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 2/11/22 02:11, Agathe Porte wrote:
Hi Guenter,

Le 11/02/2022 à 06:16, Guenter Roeck a écrit :
On 2/9/22 07:53, Agathe Porte wrote:
Add support for Texas Instruments TMP464 temperature sensor IC.

TI's TMP464 is an I2C temperature sensor chip. This chip is
similar to TI's TMP421 chip, but with 16bit-wide registers (instead
of 8bit-wide registers). The chip have one local sensor and four
remote sensors.

Signed-off-by: Agathe Porte <agathe.porte@xxxxxxxxx>
Acked-by: Krzysztof Adamski <krzysztof.adamski@xxxxxxxxx>

First, please _never_ send a new version of a patch or patch series
as response to an older version. I almost missed this version of the series.

I should have sent it without In-reply-to to the ML?

I have used the following example from git send-email --help as reference, but I was probably wrong:


Please see Documentation/process/submitting-patches.rst,
"Explicit In-Reply-To headers".

          So for example when --thread and --no-chain-reply-to are specified, the second and
           subsequent patches will be replies to the first one like in the illustration below
           where [PATCH v2 0/3] is in reply to [PATCH 0/2]:

               [PATCH 0/2] Here is what I did...
                 [PATCH 1/2] Clean up and tests
                 [PATCH 2/2] Implementation
                 [PATCH v2 0/3] Here is a reroll
                   [PATCH v2 1/3] Clean up
                   [PATCH v2 2/3] New tests
                   [PATCH v2 3/3] Implementation


Second, I really dislike continuing this driver without all the attibutes
making it valuable as hwmon driver, and I really want to drop local caching
and use regmap instead. I can not get a TMP464 (they appear to be sold out
until 2023 everywhere I checked, and I can not even get a sample from TI
either). However, I ordered and - according to Fedex - should get an
evaluation board for TMP468 tomorrow. Before we keep going back and
forth, I'd prefer to use that chip to add support for all attributes (or
in other words take the driver from here). Would that be ok with you ?
This looks fine for me, as long as copyright is kept if you plan to reuse what I have proposed here. I have asked a colleague in the hardware team to unsolder a few of them from dismissed boards since they are hard to find due to the component shortage. I will ask you a delivery address using my personal email with a proper GPG key when I will be in possession of the chips. Would that be OK to you?

Sounds good.


Additional comment inline.

Since you are planning on taking over this driver I think I will not propose a v3 driver. However I will try to fix the comments in our local version as a learning opportunity. Please Cc me and Krzysztof when posting your implementation so that we can backport it in our system.

Sure, will do.

Thanks,
Guenter



[Index of Archives]     [LM Sensors]     [Linux Sound]     [ALSA Users]     [ALSA Devel]     [Linux Audio Users]     [Linux Media]     [Kernel]     [Gimp]     [Yosemite News]     [Linux Media]

  Powered by Linux