linux-kernel - Re: [PATCH v8 6/9] usb: dwc3: qcom: Add multiport controller support for qcom wrapper

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 for Android: free password hash cracker in your pocket

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

Date:   Sat, 20 May 2023 23:18:52 +0530
From:   Krishna Kurapati PSSNV <quic_kriskura@...cinc.com>
To:     Johan Hovold <johan@...nel.org>,
        Bjorn Andersson <andersson@...nel.org>
CC:     Bjorn Andersson <andersson@...nel.org>,
        Thinh Nguyen <Thinh.Nguyen@...opsys.com>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Philipp Zabel <p.zabel@...gutronix.de>,
        Andy Gross <agross@...nel.org>,
        Konrad Dybcio <konrad.dybcio@...aro.org>,
        Rob Herring <robh+dt@...nel.org>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
        Felipe Balbi <balbi@...nel.org>, <linux-usb@...r.kernel.org>,
        <linux-kernel@...r.kernel.org>, <linux-arm-msm@...r.kernel.org>,
        <devicetree@...r.kernel.org>, <quic_pkondeti@...cinc.com>,
        <quic_ppratap@...cinc.com>, <quic_wcheng@...cinc.com>,
        <quic_jackp@...cinc.com>, <quic_harshq@...cinc.com>,
        <ahalaney@...hat.com>
Subject: Re: [PATCH v8 6/9] usb: dwc3: qcom: Add multiport controller support
 for qcom wrapper



On 5/17/2023 10:07 PM, Johan Hovold wrote:
> On Tue, May 16, 2023 at 07:49:14AM +0530, Krishna Kurapati PSSNV wrote:
>>
>>
>> On 5/16/2023 3:57 AM, Bjorn Andersson wrote:
>>> On Sun, May 14, 2023 at 11:19:14AM +0530, Krishna Kurapati wrote:
> 
>>>> -#define PWR_EVNT_IRQ_STAT_REG			0x58
>>>> +#define PWR_EVNT_IRQ1_STAT_REG			0x58
>>>> +#define PWR_EVNT_IRQ2_STAT_REG			0x1dc
>>>> +#define PWR_EVNT_IRQ3_STAT_REG			0x228
>>>> +#define PWR_EVNT_IRQ4_STAT_REG			0x238
>>>>    #define PWR_EVNT_LPM_IN_L2_MASK			BIT(4)
>>>>    #define PWR_EVNT_LPM_OUT_L2_MASK		BIT(5)
>>>>    
>>>> @@ -93,6 +96,13 @@ struct dwc3_qcom {
>>>>    	struct icc_path		*icc_path_apps;
>>>>    };
>>>>    
>>>> +static u32 pwr_evnt_irq_stat_reg_offset[4] = {
>>>> +			PWR_EVNT_IRQ1_STAT_REG,
>>>> +			PWR_EVNT_IRQ2_STAT_REG,
>>>> +			PWR_EVNT_IRQ3_STAT_REG,
>>>> +			PWR_EVNT_IRQ4_STAT_REG,
>>>
>>> Seems to be excessive indentation of these...
>>>
>>> Can you also please confirm that these should be counted starting at 1 -
>>> given that you otherwise talk about port0..N-1?
> 
>>     I am fine with either way. Since this just denoted 4 different ports,
>> I named them starting with 1. Either ways, we will run through array
>> from (0-3), so we must be fine.
> 
> Actually, the USB ports are indexed from 1, so the above naming may or
> may not be correct depending on how they are defined.
> 
Ok, will rename them as PWR_EVNT_IRQx_STAT_REG  (x = 0,1,2,3)

>>>> +};
>>>> +
>>>>    static inline void dwc3_qcom_setbits(void __iomem *base, u32 offset, u32 val)
>>>>    {
>>>>    	u32 reg;
>>>> @@ -413,13 +423,16 @@ static int dwc3_qcom_suspend(struct dwc3_qcom *qcom, bool wakeup)
>>>>    {
>>>>    	u32 val;
>>>>    	int i, ret;
>>>> +	struct dwc3 *dwc = platform_get_drvdata(qcom->dwc3);
>>>>    
>>>>    	if (qcom->is_suspended)
>>>>    		return 0;
>>>>    
>>>> -	val = readl(qcom->qscratch_base + PWR_EVNT_IRQ_STAT_REG);
>>>> -	if (!(val & PWR_EVNT_LPM_IN_L2_MASK))
>>>> -		dev_err(qcom->dev, "HS-PHY not in L2\n");
>>>> +	for (i = 0; i < dwc->num_usb2_ports; i++) {
>>>
>>> In the event that the dwc3 core fails to acquire or enable e.g. clocks
>>> its drvdata will be NULL. If you then hit a runtime pm transition in the
>>> dwc3-qcom glue you will dereference NULL here. (You can force this issue
>>> by e.g. returning -EINVAL from dwc3_clk_enable()).
>>>
>>> So if you're peaking into qcom->dwc3 you need to handle the fact that
>>> dwc might be NULL, here and in resume below.
>>>
>> Thanks for catching this. You are right, there were instances where the
>> we saw probe for dwc3 being deferred while the probe for dwc3-qcom was
>> still successful [1]. In this case, if the dwc3 probe never happened and
>> system tries to enter suspend, we might hit a NULL pointer dereference.
> 
> I don't think we should be adding more of these layering violations. A
> parent device driver has no business messing with the driver data for a
> child device which may or may not even have probed yet.
> 
> I added a FIXME elsewhere in the driver about fixing up the current
> instances that have already snuck in (which in some sense is even worse
> by accessing driver data of a grandchild device).
> 
> We really need to try sort this mess out and how to properly handle the
> interactions between these layers (e.g. glue, dwc3 core and xhci). This
> will likely involve adding callbacks from the child to the parent, for
> example, when the child is suspending.
> 

Hi Johan,

  I agree with you, but in this case I believe there is no other way we 
can find the number of ports present. Unless its a dt property which 
parent driver can access the child's of node and get the details. Like 
done in v4 [1]. But it would be adding redundant data into DT as pointed 
out by Rob and Krzysztof and so we removed these properties.

Also, since this is a read only operation being done and no 
modifications are being done to driver data of child, is it still not 
acceptable as both dwc3-qcom and core are tightly coupled entities.

[1]: 
https://lore.kernel.org/all/20230115114146.12628-2-quic_kriskura@quicinc.com/

Regards,
Krishna,