Re: [PATCH v3 8/9] platform/x86: int3472: Add handshake pin support

[Hans de Goede <hdegoede@redhat.com>]

Hi Andy,

On 16-Apr-25 8:16 PM, Andy Shevchenko wrote:
> On Wed, Apr 16, 2025 at 02:40:36PM +0200, Hans de Goede wrote:
>> New Intel Meteor Lake based laptops with IPU6 cameras have a new type 0x12
>> pin defined in the INT3472 sensor companion device which describes
>> the sensor's GPIOs.
>>
>> This pin is primarily used on designs with a Lattice FPGA chip which is
>> capable of running the sensor independently of the main CPU for features
>> like presence detection. This pin needs to be driven high to make the FPGA
>> run the power-on sequence of the sensor. After driving the pin high,
>> the FPGA "firmware" needs 25ms to complete the power-on sequence.
>>
>> Add support for this modelling the handshake pin as a GPIO driven "dvdd"
>> regulator with a 25 ms enable time. This model was chosen because:
>>
>> 1. Sensor chips don't have a handshake pin, so we need to abstract this
>>    in some way which does not require modification to the sensor drivers,
>>    sensor drivers using the bulk-regulator API to get avdd + vddio + dvdd
>>    is normal. So this will work to get the right value set to the handshake
>>    pin without requiring sensor driver modifications.
>>
>> 2. Sensors typically wait only a small time for the sensor to power-on
>>    after de-asserting reset. Not the 25ms the Lattice chip requires.
>>    Using the regulator framework's enable_time allows hiding the need for
>>    this delay from the sensor drivers.
> 
> ...
> 
>>  			if (ret)
>>  				err_msg = "Failed to map regulator to sensor\n";
>>  
>> +			break;
> 
>> +			if (ret)
>> +				err_msg = "Failed to map regulator to sensor\n";
>> +
>>  			break;
> 
> As discussed this might be changed to have the same format string with supplied
> name as a parameter.

That does not work well, since this just stores a string to pass to
dev_err_probe() later.

So instead I've just gone with 2 unique errors for v4.

> 
> Reviewed-by: Andy Shevchenko <andy@kernel.org>

Thank you.

Regards,

Hans