linux-kernel - Re: [PATCH v16 7/9] usb: dwc3: qcom: Refactor IRQ handling in glue driver

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

Date: Mon, 25 Mar 2024 18:45:07 +0530
From: Krishna Kurapati PSSNV <quic_kriskura@...cinc.com>
To: Johan Hovold <johan@...nel.org>
CC: Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
        Rob Herring
	<robh+dt@...nel.org>,
        Bjorn Andersson <andersson@...nel.org>,
        Wesley Cheng
	<quic_wcheng@...cinc.com>,
        Konrad Dybcio <konrad.dybcio@...aro.org>,
        "Greg
 Kroah-Hartman" <gregkh@...uxfoundation.org>,
        Conor Dooley
	<conor+dt@...nel.org>,
        Thinh Nguyen <Thinh.Nguyen@...opsys.com>,
        Felipe Balbi
	<balbi@...nel.org>, <devicetree@...r.kernel.org>,
        <linux-arm-msm@...r.kernel.org>, <linux-usb@...r.kernel.org>,
        <linux-kernel@...r.kernel.org>, <quic_ppratap@...cinc.com>,
        <quic_jackp@...cinc.com>
Subject: Re: [PATCH v16 7/9] usb: dwc3: qcom: Refactor IRQ handling in glue
 driver



On 3/25/2024 6:18 PM, Johan Hovold wrote:
> On Thu, Mar 07, 2024 at 11:50:50AM +0530, Krishna Kurapati wrote:
>> On multiport supported controllers, each port has its own DP/DM
>> and SS (if super speed capable) interrupts. As per the bindings,
>> their interrupt names differ from standard ones having "_x" added
>> as suffix (x indicates port number). Identify from the interrupt
>> names whether the controller is a multiport controller or not.
>> Refactor dwc3_qcom_setup_irq() call to parse multiport interrupts
>> along with non-multiport ones accordingly..
>>
>> Signed-off-by: Krishna Kurapati <quic_kriskura@...cinc.com>
>> ---
>>   drivers/usb/dwc3/dwc3-qcom.c | 146 +++++++++++++++++++++++++++--------
>>   1 file changed, 112 insertions(+), 34 deletions(-)
> 
> This is much better. Just a couple of nits below.
> 
>> +static int dwc3_qcom_find_num_ports(struct platform_device *pdev)
>> +{
>> +	const char *irq_name;
>> +	int port_index;
>> +	int irq;
>> +
>> +	irq = platform_get_irq_byname_optional(pdev, "qusb2_phy");
>> +	if (irq > 0)
>> +		return 1;
>> +
>> +	irq = platform_get_irq_byname_optional(pdev, "dp_hs_phy_irq");
>> +	if (irq > 0)
>> +		return 1;
>> +
>> +	for (port_index = 0; port_index < DWC3_MAX_PORTS; port_index++) {
>> +		irq_name = devm_kasprintf(&pdev->dev, GFP_KERNEL, "dp_hs_phy_%d", port_index + 1);
> 
> Please use a stack allocated buffer for these strings as we don't need
> them any more after this function returns.
> 

Sure. Will replace this with "char irq_name[14]".

>> +		if (!irq_name)
>> +			return -ENOMEM;
>> +
>> +		irq = platform_get_irq_byname_optional(pdev, irq_name);
>> +		if (irq <= 0)
>> +			return port_index;
>> +	}
>> +
>> +	return port_index;
> 
> I think explicitly returning DWC3_MAX_PORTS here would be more readable.
> 

Will make this change.

>> +}
>> +
>> +static int dwc3_qcom_setup_irq(struct platform_device *pdev)
>> +{
>> +	struct dwc3_qcom *qcom = platform_get_drvdata(pdev);
>> +	bool is_multiport;
>> +	int ret;
>> +	int i;
>> +
>> +	qcom->num_ports = dwc3_qcom_find_num_ports(pdev);
>> +	if (qcom->num_ports < 0)
>> +		return -ENOMEM;
> 
> Just return 'ret' directly.

Sure, will init ret to -ENOMEM and return ret here.

> 
>> +
>> +	is_multiport = (qcom->num_ports > 1) ? true : false;
> 
> And no need for the ternary operator:
ACK.

> 
> 	is_multiport = (qcom->num_ports > 1);
> 
>> +
>> +	for (i = 0; i < qcom->num_ports; i++) {
>> +		ret = dwc3_qcom_setup_port_irq(pdev, i, is_multiport);
>>   		if (ret)
>>   			return ret;
>> -		qcom->ss_phy_irq = irq;
>>   	}
>>   
>>   	return 0;
> 
> With that fixed:
> 
> Reviewed-by: Johan Hovold <johan+linaro@...nel.org>

Thanks for the review

Regards,
Krishna,