Received: by 2002:a25:e74b:0:0:0:0:0 with SMTP id e72csp1114549ybh; Thu, 23 Jul 2020 00:16:25 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzsPZbvHFZfHgJSbwNktLp78BtKZWI5sNtPV4Fx5/Z65FKx4ugMILLgPvtyzEITNg3m8iDS X-Received: by 2002:a17:906:3a9b:: with SMTP id y27mr3089157ejd.38.1595488585275; Thu, 23 Jul 2020 00:16:25 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1595488585; cv=none; d=google.com; s=arc-20160816; b=ULQ/AYMMq5/LHD4xblPNVfFOfcmAZ4o4HCsBiM52ulGVTE1xnxpFo6oLSmP1X0WmKw vK3LcEhdp3Y/DfV6OcraVCeERdL+iw7M18Pbo7HNZR2LHKbCk0U6sZdcXFupI4vYIMKh xFAXjIaqJOk+gXeRYAB+THDhNcLEKVlvgIBKTuW+sK6CZ+xA1AAFEjE8VmUVMYuMs0KT IctwVXdVfFSB12FXhPB9NDDmj2IK876LRnRXNzq6V6Hi3udboZL8dbhRciUIj+PFHqUQ SOx9IhhAXf7CUGRsSObHtKU9F3H1VYwW0KLom72PoBM4jJXhKvED90yN/Dz9ILn8d+hE NtgQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject:dkim-signature; bh=yqcfY/padsjVsHSiHABJVoYRhWwTvp1SMriQZY8ccyU=; b=yhpo88QeqaJDDu0sP3r/GV10/ODhnllFOasGRUD22eRdGaZ/hlmpJ5RwNyyn6W1u4N YWkyOeT2VwRAFoKdp7+EumZQV3156JToFEjT6pyZ1ZoeeleKOmDINkXZ+UQkHCFsLjmz rkCOvv2UDpWbjiZAHmB0UMMQPohbc6dK1ifYtQ3Mqf3fooAlR+93r2UcZlVRqyEkwRIg b3+hJ6OWKGrYfCdOlYWb0TmTSwEzmtuZ616dGifO8DnYU9bpp6hb/RzzsdLlzhDPU7rC TwWzKbWJEtnoCOEQxFnCsBBdoRSMd7FU2r/dY0vp9RvQ2C6lgjmNW82VlOQ09tn1YXGm N2Uw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@st.com header.s=STMicroelectronics header.b=At0Pl150; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=st.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id b21si1445268ejz.710.2020.07.23.00.16.02; Thu, 23 Jul 2020 00:16:25 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@st.com header.s=STMicroelectronics header.b=At0Pl150; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=st.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726558AbgGWHPk (ORCPT + 99 others); Thu, 23 Jul 2020 03:15:40 -0400 Received: from mx08-00178001.pphosted.com ([91.207.212.93]:59684 "EHLO mx07-00178001.pphosted.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1725536AbgGWHPk (ORCPT ); Thu, 23 Jul 2020 03:15:40 -0400 Received: from pps.filterd (m0046661.ppops.net [127.0.0.1]) by mx07-00178001.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 06N7DD7m014051; Thu, 23 Jul 2020 09:15:20 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=st.com; h=subject : to : cc : references : from : message-id : date : mime-version : in-reply-to : content-type : content-transfer-encoding; s=STMicroelectronics; bh=yqcfY/padsjVsHSiHABJVoYRhWwTvp1SMriQZY8ccyU=; b=At0Pl150HlvjCdBUER0ftWuQuekxfi0EwklT75x/bePqYqO4iWqKjxuNsDn7aFrOZpLe 42WJqY4eJEJYzCCfh/TdisUjXbq47ICeBRdrfFAg1n3vrswF9wFc/L6+9l7FjlYtbXQt ozlUIOEaCMZYqIrJm2Hkl+fcCAUERTXyqFjbBOcq/0GLgFxwvX8H7yVXfR6PxmwRFprp eNlqkDES+OBWBOHik1XACNAmvweFWNWXHS8ed4YVhMeDS/KSfUhK60bbf0KJWTXQs8CG btG6mEnaLZj84V88bkHov2UkcUEiRRfWtd1swOyWMnDoc2ka7q39STFgU6Gh1OKqTcVS 7A== Received: from beta.dmz-eu.st.com (beta.dmz-eu.st.com [164.129.1.35]) by mx07-00178001.pphosted.com with ESMTP id 32bsah95dp-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 23 Jul 2020 09:15:20 +0200 Received: from euls16034.sgp.st.com (euls16034.sgp.st.com [10.75.44.20]) by beta.dmz-eu.st.com (STMicroelectronics) with ESMTP id 4B13610002A; Thu, 23 Jul 2020 09:15:19 +0200 (CEST) Received: from Webmail-eu.st.com (sfhdag3node2.st.com [10.75.127.8]) by euls16034.sgp.st.com (STMicroelectronics) with ESMTP id 32E0621FEA9; Thu, 23 Jul 2020 09:15:19 +0200 (CEST) Received: from lmecxl0995.lme.st.com (10.75.127.51) by SFHDAG3NODE2.st.com (10.75.127.8) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Thu, 23 Jul 2020 09:15:18 +0200 Subject: Re: [PATCH 1/3] usb: dwc2: override PHY input signals with usb role switch support To: Martin Blumenstingl , "balbi@kernel.org" CC: Alexandre TORGUE , "devicetree@vger.kernel.org" , Fabrice GASNIER , "gregkh@linuxfoundation.org" , "hminas@synopsys.com" , "linux-arm-kernel@lists.infradead.org" , "linux-kernel@vger.kernel.org" , "linux-stm32@st-md-mailman.stormreply.com" , "linux-usb@vger.kernel.org" , "mcoquelin.stm32@gmail.com" , "robh+dt@kernel.org" References: <20200616140717.28465-2-amelie.delaunay@st.com> <20200704174219.612060-1-martin.blumenstingl@googlemail.com> <05a81997-5ddb-ea81-7a89-8078b8a2b610@st.com> From: Amelie DELAUNAY Message-ID: <7497c0ed-bac6-969e-8198-c40a41e874e3@st.com> Date: Thu, 23 Jul 2020 09:15:17 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8"; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Originating-IP: [10.75.127.51] X-ClientProxiedBy: SFHDAG8NODE1.st.com (10.75.127.22) To SFHDAG3NODE2.st.com (10.75.127.8) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235,18.0.687 definitions=2020-07-23_02:2020-07-22,2020-07-23 signatures=0 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 > 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