linux-kernel - Re: [PATCH] platform/x86: amd: Add ISP platform info

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-prev] [day] [month] [year] [list]

Message-ID: <e6dc530d-b7dd-43f6-8dcd-f9188000d279@redhat.com>
Date: Thu, 6 Mar 2025 15:52:36 +0100
From: Hans de Goede <hdegoede@...hat.com>
To: Mario Limonciello <mario.limonciello@....com>,
 "Nirujogi, Pratap" <pnirujog@....com>,
 Pratap Nirujogi <pratap.nirujogi@....com>, ilpo.jarvinen@...ux.intel.com
Cc: platform-driver-x86@...r.kernel.org, linux-kernel@...r.kernel.org,
 benjamin.chan@....com, bin.du@....com, king.li@....com,
 gjorgji.rosikopulos@....com, dominic.antony@....com
Subject: Re: [PATCH] platform/x86: amd: Add ISP platform info

Hi Mario,

On 5-Mar-25 4:42 PM, Mario Limonciello wrote:
> On 3/5/2025 09:26, Hans de Goede wrote:

<snip>

>> Thanks.
>>
>> So looking at this there are ACPI devices for the sensors, which
>> unfortunately lack a _CRS with an I2CSerialBusV2 resource pointing
>> to the ISP childdevice as bus-controller. So that i2c-client
>> instantiating would be instant.
>>
>> +Cc Mario
>>
>> Mario any chance that for the next (or the next-next) generation of
>> AMD devices we can get the ACPI tables fixed to properly describe
>> the sensors as having an I2cSerialBusV2 resource, just like how e.g.
>> I2C touchpads / touchscreens have this ?  I suspect this will benefit
>> Windows too. Likewise any enable GPIOs for the sensor really also
>> should be proper ACPi Gpio resources in the ACPI device describing
>> the sensor.
> 
> Due to the architecture of how the ISP is accessed "through" the GPU, I'm not sure it's viable and furthermore if it actually changes anything for Windows.  But the ISP team and BIOS team can certainly discuss it for future designs.

There could be an ACPI child device under the ACPI device / fwnode
for the GPU which models the ISP, this could have its own _HID
to allow the ISP driver to find it. If the I2C adapter part of
the ISP driver then sets the fwnode of the adapter to that child
fwnode, it can be used as the I2C controller reference in
I2cSerialBusV2 resources for the sensors.

This is how I2C devices generally are handled / enumerated under
ACPI and I don't really see why future AMD designs could not
follow how this is all supposed to work under ACPI instead of
having drivers need to manually instantiate the i2c-client.

This also allows putting things like the sensor i2c-address
(and GPIOs) in ACPI instead of having to hardcode this all in
the drivers.

And as mentioned before I think this would benefit the windows
drivers too, for similar reasons (not needing to hardcode
things like i2c-address and GPIOs which really belongs in
the ACPI tables).

Regards,

Hans