Received: by 2002:a25:d7c1:0:0:0:0:0 with SMTP id o184csp1223218ybg; Fri, 18 Oct 2019 14:06:10 -0700 (PDT) X-Google-Smtp-Source: APXvYqxl7JS9EdK3qpcKWDVuU/K27dEnDDhY4IH+0qc5NbUi2L/5pwHM5etWZIHGhUY+kEwBK2fr X-Received: by 2002:a50:eb4d:: with SMTP id z13mr11807981edp.175.1571432770110; Fri, 18 Oct 2019 14:06:10 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1571432770; cv=none; d=google.com; s=arc-20160816; b=juj/CwAR2vcuCEYWbrvUwgr0JmnYJPTXm8p1CbS47YEVCGl/sNmw1WB5B0QQPFrFp2 i+KBt5/WND7ZZtaYaP/FCVlYeU2EgMl5PQIkDzdm08bVlco2F7QX5lxVvYrQtypFNCZm MAXVFAh6jf/zC3EqUHjBR/1Pq3U4QdO9XjiwrPHIxswY04OLL2HGpIVamvBzOCEZVBl+ HR2Ij/e+ha0PWa10z+gatEGNnvmTUSbzi5lFmt1e7iYXz2M2xZDZHkTVkPGz/nmeWgmH y3MtpogTycq+5B5YI5y0gX0yCSA5meosfBUQcbtYBLBa3ZHFcverosQxYlcNYmzieJjO trwg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=7LE6c39B0ZV7uMc9DL/by1f/o25bDHsy6OjHu4nNBEM=; b=IL1ib7+EpAPC+RwzoKKg9u9hPQqbrR/UvI/QqYfLiBzBafC2EKu8TcDuZLfSntA9Ze kl44+UqYSMyniWVnt8QZOzbvmm87/UMyZWW+6VjFSfkWzn8/Xs0y24dAy4JFqrxCF6yV HYq4+ZgXnTXIbi31ZYXhCNC4u0fNGrsXVGcHXeylQGgpIEBcx/vde632KbyXoiin/98L CZzb6V/BWGKZ7U9QU8xc6PWrq5wVqYujUjUHMjR4LM9dxoie48HJq59pD30VDLjN6HEV 8vpJOa10rA4z07V441bRtpgQWutFc//geMcbfal3aru3FxcCbnFTNBfQcI0YQMyKdBd3 6f+A== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id r19si4397673edy.409.2019.10.18.14.05.46; Fri, 18 Oct 2019 14:06:10 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2408211AbfJQQel (ORCPT + 99 others); Thu, 17 Oct 2019 12:34:41 -0400 Received: from muru.com ([72.249.23.125]:37814 "EHLO muru.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730640AbfJQQel (ORCPT ); Thu, 17 Oct 2019 12:34:41 -0400 Received: from atomide.com (localhost [127.0.0.1]) by muru.com (Postfix) with ESMTPS id C458C804F; Thu, 17 Oct 2019 16:35:10 +0000 (UTC) Date: Thu, 17 Oct 2019 09:34:33 -0700 From: Tony Lindgren To: min.guo@mediatek.com Cc: Bin Liu , Rob Herring , Greg Kroah-Hartman , Mark Rutland , Matthias Brugger , Alan Stern , chunfeng.yun@mediatek.com, linux-usb@vger.kernel.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-mediatek@lists.infradead.org, hdegoede@redhat.com, Yonglong Wu Subject: Re: [PATCH v8 6/6] usb: musb: Add support for MediaTek musb controller Message-ID: <20191017163433.GN5610@atomide.com> References: <20191017094126.29045-1-min.guo@mediatek.com> <20191017094126.29045-7-min.guo@mediatek.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20191017094126.29045-7-min.guo@mediatek.com> User-Agent: Mutt/1.12.1 (2019-06-15) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi, Just few comments for future changes that might help below. * min.guo@mediatek.com [191017 09:42]: > --- /dev/null > +++ b/drivers/usb/musb/mediatek.c > +static int musb_usb_role_sx_set(struct device *dev, enum usb_role role) > +{ > + struct mtk_glue *glue = dev_get_drvdata(dev); > + struct musb *musb = glue->musb; > + u8 devctl = readb(musb->mregs + MUSB_DEVCTL); > + enum usb_role new_role; > + > + if (role == glue->role) > + return 0; > + > + switch (role) { > + case USB_ROLE_HOST: > + musb->xceiv->otg->state = OTG_STATE_A_WAIT_VRISE; > + glue->phy_mode = PHY_MODE_USB_HOST; > + new_role = USB_ROLE_HOST; > + if (glue->role == USB_ROLE_NONE) > + phy_power_on(glue->phy); > + > + devctl |= MUSB_DEVCTL_SESSION; > + musb_writeb(musb->mregs, MUSB_DEVCTL, devctl); > + MUSB_HST_MODE(musb); > + break; > + case USB_ROLE_DEVICE: > + musb->xceiv->otg->state = OTG_STATE_B_IDLE; > + glue->phy_mode = PHY_MODE_USB_DEVICE; > + new_role = USB_ROLE_DEVICE; > + devctl &= ~MUSB_DEVCTL_SESSION; > + musb_writeb(musb->mregs, MUSB_DEVCTL, devctl); > + if (glue->role == USB_ROLE_NONE) > + phy_power_on(glue->phy); > + > + MUSB_DEV_MODE(musb); > + break; > + case USB_ROLE_NONE: > + glue->phy_mode = PHY_MODE_USB_OTG; > + new_role = USB_ROLE_NONE; > + devctl &= ~MUSB_DEVCTL_SESSION; > + musb_writeb(musb->mregs, MUSB_DEVCTL, devctl); > + if (glue->role != USB_ROLE_NONE) > + phy_power_off(glue->phy); > + > + break; > + default: > + dev_err(glue->dev, "Invalid State\n"); > + return -EINVAL; > + } > + > + glue->role = new_role; > + phy_set_mode(glue->phy, glue->phy_mode); > + > + return 0; > +} For the role change, I recently posted a patch "[PATCH 4/7] usb: musb: Add musb_set_host and peripheral and use them for omap2430". That should work for you looking at the code above, so later on you might want to change to use that. Probably best done as a follow-up patch to avoid adding extra dependencies to your series. Please also note that musb core attempts to do things automagically on it's own. So trying to force mode in general does not work reliably. This is because VBUS may not yet have risen for example. The role change is best done based on the USB PHY as then usually musb has already switched to the right mode automatically :) > +static const struct musb_platform_ops mtk_musb_ops = { > + .quirks = MUSB_DMA_INVENTRA, > + .init = mtk_musb_init, > + .get_toggle = mtk_musb_get_toggle, > + .set_toggle = mtk_musb_set_toggle, > + .exit = mtk_musb_exit, > +#ifdef CONFIG_USB_INVENTRA_DMA > + .dma_init = musbhs_dma_controller_create_noirq, > + .dma_exit = musbhs_dma_controller_destroy, > +#endif > + .clearb = mtk_musb_clearb, > + .clearw = mtk_musb_clearw, > + .busctl_offset = mtk_musb_busctl_offset, > + .set_mode = mtk_musb_set_mode, > +}; So you may want to consider getting rid of .set_mode completely and rely on USB PHY calls instead. In some cases you need to use struct phy_companion for set_vbus depending how things are wired. Regards, Tony