Re: [PATCH v1 9/9] serial: qcom-geni: Enable Serial on SA8255p Qualcomm platforms

[Praveen Talari <quic_ptalari@quicinc.com>]

HI

On 4/14/2025 1:39 PM, Jiri Slaby wrote:
> On 10. 04. 25, 19:40, Praveen Talari wrote:
>> The Qualcomm automotive SA8255p SoC relies on firmware to configure
>> platform resources, including clocks, interconnects and TLMM.
>> The driver requests resources operations over SCMI using power
>> and performance protocols.
>>
>> The SCMI power protocol enables or disables resources like clocks,
>> interconnect paths, and TLMM (GPIOs) using runtime PM framework APIs,
>> such as resume/suspend, to control power states(on/off).
>>
>> The SCMI performance protocol manages UART baud rates, with each baud
>> rate represented by a performance level. The driver uses the
>> dev_pm_opp_set_level() API to request the desired baud rate by
>> specifying the performance level.
>>
>> Signed-off-by: Praveen Talari <quic_ptalari@quicinc.com>
>> ---
>>   drivers/tty/serial/qcom_geni_serial.c | 150 +++++++++++++++++++++++---
>>   1 file changed, 136 insertions(+), 14 deletions(-)
>>
>> diff --git a/drivers/tty/serial/qcom_geni_serial.c 
>> b/drivers/tty/serial/qcom_geni_serial.c
>> index 9649297d4a9e..40b71d4b7590 100644
>> --- a/drivers/tty/serial/qcom_geni_serial.c
>> +++ b/drivers/tty/serial/qcom_geni_serial.c
> ...
>> @@ -1624,8 +1669,27 @@ static int geni_serial_resources_on(struct 
>> uart_port *uport)
>>       return ret;
>>   }
>>   -static int geni_serial_resource_init(struct qcom_geni_serial_port 
>> *port)
>> +static int geni_serial_resource_state(struct uart_port *uport, bool 
>> power_on)
>> +{
>> +    return power_on ? geni_serial_resources_on(uport) : 
>> geni_serial_resources_off(uport);
>> +}
>> +
>> +static int geni_serial_pwr_init(struct uart_port *uport)
>>   {
>> +    struct qcom_geni_serial_port *port = to_dev_port(uport);
>> +    int ret;
>> +
>> +    ret = dev_pm_domain_attach_list(port->se.dev,
>> +                    &port->dev_data->pd_data, &port->pd_list);
>> +    if (ret <= 0)
>> +        return -EINVAL;
>
> Any reason to reroute every (sane) error code into EINVAL?

i opted for EINVAL instead of EBUSY because i don't want the probe to be 
re-executed if the firmware does not support SE.
Let me know if you have any suggestions.

Thanks,

Praveen Talari