linux-kernel - Re: [PATCH 1/3] usb: dwc2: override PHY input signals with usb role switch support

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]

Message-ID: <7497c0ed-bac6-969e-8198-c40a41e874e3@st.com>
Date:   Thu, 23 Jul 2020 09:15:17 +0200
From:   Amelie DELAUNAY <amelie.delaunay@...com>
To:     Martin Blumenstingl <martin.blumenstingl@...glemail.com>,
        "balbi@...nel.org" <balbi@...nel.org>
CC:     Alexandre TORGUE <alexandre.torgue@...com>,
        "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
        Fabrice GASNIER <fabrice.gasnier@...com>,
        "gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>,
        "hminas@...opsys.com" <hminas@...opsys.com>,
        "linux-arm-kernel@...ts.infradead.org" 
        <linux-arm-kernel@...ts.infradead.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-stm32@...md-mailman.stormreply.com" 
        <linux-stm32@...md-mailman.stormreply.com>,
        "linux-usb@...r.kernel.org" <linux-usb@...r.kernel.org>,
        "mcoquelin.stm32@...il.com" <mcoquelin.stm32@...il.com>,
        "robh+dt@...nel.org" <robh+dt@...nel.org>
Subject: Re: [PATCH 1/3] usb: dwc2: override PHY input signals with usb role
 switch support

Hi Felipe,
Hi Martin,

I saw the issue reported ([balbi-usb:testing/next 2/17] 
drivers/usb/dwc2/drd.c:80:38: error: no member named 'test_mode' in 
'struct dwc2_hsotg'). I prepare a V2 fixing it + adressing Martin's 
comments.

Regards,
Amelie

On 7/19/20 9:56 PM, Martin Blumenstingl wrote:
> Hello Amelie,
> 
> sorry for the late reply
> 
> On Wed, Jul 8, 2020 at 6:00 PM Amelie DELAUNAY <amelie.delaunay@...com> 
> wrote:
> [...]
>> Could you please test with:
>>
>> static int dwc2_drd_role_sw_set(struct device *dev, enum usb_role role)
>> {
>>         struct dwc2_hsotg *hsotg = dev_get_drvdata(dev);
>>         unsigned long flags;
>>         int already = 0;
>>
>>         /* Skip session not in line with dr_mode */
>>         if ((role == USB_ROLE_DEVICE && hsotg->dr_mode == USB_DR_MODE_HOST) ||
>>             (role == USB_ROLE_HOST && hsotg->dr_mode == USB_DR_MODE_PERIPHERAL))
>>                 return -EINVAL;
>>
>>         /* Skip session if core is in test mode */
>>         if (role == USB_ROLE_NONE && hsotg->test_mode) {
>>                 dev_dbg(hsotg->dev, "Core is in test mode\n");
>>                 return -EBUSY;
>>         }
>>
>>         spin_lock_irqsave(&hsotg->lock, flags);
>>
>>         if (role == USB_ROLE_HOST) {
>>                 already = dwc2_ovr_avalid(hsotg, true);
>>         } else if (role == USB_ROLE_DEVICE) {
>>                 already = dwc2_ovr_bvalid(hsotg, true);
>>                 /* This clear DCTL.SFTDISCON bit */
>>                 dwc2_hsotg_core_connect(hsotg);
>>         } else {
>>                 if (dwc2_is_device_mode(hsotg)) {
>>                     if (!dwc2_ovr_bvalid(hsotg, false))
>>                         /* This set DCTL.SFTDISCON bit */
>>                         dwc2_hsotg_core_disconnect(hsotg);
>>                 } else {
>>                         dwc2_ovr_avalid(hsotg, false);
>>                 }
>>         }
>>
>>         spin_unlock_irqrestore(&hsotg->lock, flags);
>>
>>         if (!already &&
>>             role != USB_ROLE_NONE && hsotg->dr_mode == USB_DR_MODE_OTG)
>>                 /* This will raise a Connector ID Status Change Interrupt */
>>                 dwc2_force_mode(hsotg, role == USB_ROLE_HOST);
>>
>>         dev_dbg(hsotg->dev, "%s-session valid\n",
>>                 role == USB_ROLE_NONE ? "No" :
>>                 role == USB_ROLE_HOST ? "A" : "B");
>>
>>         return 0;
>> }
>>
>>
>> dwc2_force_mode is called outside the spin_lock_irqsave so the kernel
>> should not complain. I've tested on my setup and the behavior seems the
>> same.
> this one is looking good - the previous kernel warnings are now gone!
> thank you very much
> 
> 
> Best regards,
> Martin