On 19/10/2022 18:06, Guenter Roeck wrote:
On Tue, Oct 18, 2022 at 06:34:29PM +0100, Ahmad Khalifa wrote:
* Finally, adds the NCT6779 device support as a replica of NCT6778
NCT6799 / NCT6798 ?
Reading the device sensors is quite accurate for the first 2-3 sensors,
but further up the index, it needs more work as it's not the same map
as the 6778.
6798 ?
Correct, those were typos. Adding the 6799 based on closest number.
What would be the best approach to enable support for those boards?
First, as I think you suggested as well, this needs to be (at least)
two patches, one to add support for the new chip using existing methods,
and another to enable accesses through ACPI.
Second, I don't have access to the chip datasheet. Historically it is
unlikely that the chip is indeed a clone/replica of NCT6798.
The comment above suggests that the chip is indeed not the same,
so this will have to be resolved before anything can be accepted.
Ok, I'll focus on figuring out the registers for the connected sensors
or finding a datasheet.
Since the actual methods are the same, what is the benefit of keeping
wmi access methods around ?
In theory, ACPI access is faster because WMI is an extra translation
layer on top, but at the same time nct6775 doesn't have to worry about
finding the right device or registering with ACPI.
Did you mean to skip the WMI path, skip the WMBD control method and go
straight for the read/write methods themselves? That's possible.
The tricky bit would be narrowing down which PNP0C14 device has those
methods and then trying not to compete with the other WMI/EC drivers for
Asus sensors (too many: asus-wmi-sensors, asus_atk0110, asus-ec-sensors)
I know the _UID for the board I have, but this probably shouldn't rely
on _UIDs and have to cover all 50 boards that are already there.
Let me have a look at this.
Last but not least, please run your patches through checkpatch.
Couple of additional comments inline.
Thanks, I didn't know that was there.
--
Regards,
Ahmad
