linux-kernel - [RFC PATCH 0/1] add ccove PMIC i2c address for Microsoft Surface 3

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-Id: <20211017161523.43801-1-kitakar@gmail.com>
Date:   Mon, 18 Oct 2021 01:15:22 +0900
From:   Tsuchiya Yuto <kitakar@...il.com>
To:     unlisted-recipients:; (no To-header on input)
Cc:     Hans de Goede <hdegoede@...hat.com>,
        Tsuchiya Yuto <kitakar@...il.com>,
        "Rafael J. Wysocki" <rafael@...nel.org>,
        Len Brown <lenb@...nel.org>, Andy Shevchenko <andy@...nel.org>,
        Mika Westerberg <mika.westerberg@...ux.intel.com>,
        linux-acpi@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: [RFC PATCH 0/1] add ccove PMIC i2c address for Microsoft Surface 3

Hi all,

Firstly, I'm still not used to Linux patch sending flow. Sorry in advance
if there is some weirdness :-) but I did my best.

I need to use the function intel_soc_pmic_exec_mipi_pmic_seq_element()
with atomisp Image Signal Processing driver on Microsoft Surface 3
(Cherry Trail).

However, it currently fails with the message I added to the commit
message below. I wondered why. The driver intel_pmic_chtcrc does define
the i2c address.

It later turned out that the intel_pmic_bytcrc driver is used on surface3
instead, where the i2c address is not defined. So, I added the address
with the patch I'm sending as RFC in this mail. It's working well.

The question is that, should Surface 3 (Cherry Trail) really use the
intel_pmic_bytcrc driver?

As I wrote in the commit message, the _HRV value of the PMIC is 0x02,
although the _DDN entry describes it as "CRYSTAL COVE+ AIC". So, maybe,
it should rather use intel_pmic_chtcrc? Does anyone know the other
instances where the _HRV value is 0x02 although it's based on Cherry
Trail SoC ?

So, I also tried using the intel_pmic_chtcrc driver instead, with the
following (temporary) change [drivers/mfd/intel_soc_pmic_core.c]:

+	hrv = 0x03;
+
	switch (hrv) {
	case BYT_CRC_HRV:
		config = &intel_soc_pmic_config_byt_crc;
		break;
	case CHT_CRC_HRV:
		config = &intel_soc_pmic_config_cht_crc;
		break;
	default:
		dev_warn(dev, "Unknown hardware rev %llu, assuming BYT\n", hrv);
		config = &intel_soc_pmic_config_byt_crc;
	}

and the function intel_soc_pmic_exec_mipi_pmic_seq_element() worked well
just like with the intel_pmic_bytcrc driver.

I don't mind which driver is used on surface3 for now, considering that
the atomisp driver is working with both PMIC drivers. But I'd like to
hear from maintainers which is better :)

Tested on surface3 with v5.15-rc5.

Regards,
Tsuchiya Yuto

Tsuchiya Yuto (1):
  ACPI / PMIC: Add i2c address to intel_pmic_bytcrc driver

 drivers/acpi/pmic/intel_pmic_bytcrc.c | 1 +
 1 file changed, 1 insertion(+)

-- 
2.33.1