From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-4.1 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 2E9FCC433FF for ; Mon, 12 Aug 2019 05:27:20 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 033F82085A for ; Mon, 12 Aug 2019 05:27:20 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1565587640; bh=S5XBc/9t8DA/2fd5dfsHRNt+0Dr0cByHsAw3f9N3BpM=; h=From:To:Cc:Subject:In-Reply-To:References:Date:List-ID:From; b=vuexPAVIAxb5xg5PAlemzNLXJhDi1Vr91aSgqdxcpg+ziQXggkrm+0EPH4oObR0xu Bxfm5uecUwjXGPWPxucMby0xLlvy1O80I1eWXoSJ2E6z3YEMELN6YNmRPMJKnONUAv rgZnd+s2QrxNhLkme4IfwWFPlMmtCTOvsN1Qg/f4= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726780AbfHLF1P (ORCPT ); Mon, 12 Aug 2019 01:27:15 -0400 Received: from mga06.intel.com ([134.134.136.31]:37449 "EHLO mga06.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725819AbfHLF1P (ORCPT ); Mon, 12 Aug 2019 01:27:15 -0400 X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga001.jf.intel.com ([10.7.209.18]) by orsmga104.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 11 Aug 2019 22:27:14 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.64,376,1559545200"; d="scan'208";a="259676344" Received: from pipin.fi.intel.com (HELO pipin) ([10.237.72.175]) by orsmga001.jf.intel.com with ESMTP; 11 Aug 2019 22:27:12 -0700 From: Felipe Balbi To: Yinbo Zhu , Greg Kroah-Hartman , "linux-usb\@vger.kernel.org" , open list Cc: Xiaobo Xie , Jiafei Pan , Ran Wang Subject: RE: [EXT] Re: [PATCH v1] usb: dwc3: remove the call trace of USBx_GFLADJ In-Reply-To: References: <20190729064607.8131-1-yinbo.zhu@nxp.com> <875zn8nt31.fsf@gmail.com> Date: Mon, 12 Aug 2019 08:27:11 +0300 Message-ID: <87h86nvtqo.fsf@gmail.com> MIME-Version: 1.0 Content-Type: text/plain Sender: linux-usb-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-usb@vger.kernel.org Hi, Yinbo Zhu writes: >> > diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c index >> > 98bce85c29d0..a133d8490322 100644 >> > --- a/drivers/usb/dwc3/core.c >> > +++ b/drivers/usb/dwc3/core.c >> > @@ -300,8 +300,7 @@ static void dwc3_frame_length_adjustment(struct >> > dwc3 *dwc) >> > >> > reg = dwc3_readl(dwc->regs, DWC3_GFLADJ); >> > dft = reg & DWC3_GFLADJ_30MHZ_MASK; >> > - if (!dev_WARN_ONCE(dwc->dev, dft == dwc->fladj, >> > - "request value same as default, ignoring\n")) { >> > + if (dft != dwc->fladj) { >> >> if the value isn't different, why do you want to change it? >> >> -- >> Balbi > Hi Balbi, > > I don't change any value. I was remove that call trace. Sure you do. The splat only shows when you request a FLADJ value that's the same as the one already in the register. The reason you see the splat is because your requested value is what's already in the HW. So, again, why are you adding this device tree property if the value is already the correct one? > In addition that GFLADJ_30MHZ value intial value is 0, and it's value > must be 0x20, if not, usb will not work. it's not zero, otherwise the splat wouldn't trigger. You're requesting the value that's already in your register by default. -- balbi