Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Wed, 15 Jun 2022 14:51:01 +0300
From:   Andy Shevchenko <andriy.shevchenko@linux.intel.com>
To:     Hans de Goede <hdegoede@redhat.com>
Cc:     Vinod Koul <vkoul@kernel.org>,
        Stephan Gerhold <stephan@gerhold.net>,
        linux-phy@lists.infradead.org, linux-kernel@vger.kernel.org,
        Kishon Vijay Abraham I <kishon@ti.com>,
        Ferry Toth <ftoth@exalondelft.nl>
Subject: Re: [PATCH v1 1/1] phy: ti: tusb1210: Don't check for write errors
 when powering on
Message-ID: <YqnHpXvZJEfhX21/@smile.fi.intel.com>
References: <20220613160848.82746-1-andriy.shevchenko@linux.intel.com>
 <bd21d5c6-ed5f-dd8c-f0bf-73f54ca8ee58@redhat.com>
 <YqiGocQ+vr9KjUHK@smile.fi.intel.com>
 <390cf16c-f07c-ebfc-08ad-25b242548953@redhat.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <390cf16c-f07c-ebfc-08ad-25b242548953@redhat.com>
Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo
Precedence: bulk

On Tue, Jun 14, 2022 at 05:49:22PM +0200, Hans de Goede wrote:
> On 6/14/22 15:01, Andy Shevchenko wrote:
> > On Tue, Jun 14, 2022 at 01:23:21PM +0200, Hans de Goede wrote:
> >> On 6/13/22 18:08, Andy Shevchenko wrote:

...

> > [   35.126397] tusb1210 dwc3.0.auto.ulpi: GPIO lookup for consumer reset
> > [   35.126418] tusb1210 dwc3.0.auto.ulpi: using ACPI for GPIO lookup
> > [   35.126455] tusb1210 dwc3.0.auto.ulpi: using lookup tables for GPIO lookup
> > [   35.126465] tusb1210 dwc3.0.auto.ulpi: No GPIO consumer reset found
> > [   35.126476] tusb1210 dwc3.0.auto.ulpi: GPIO lookup for consumer cs
> > [   35.126485] tusb1210 dwc3.0.auto.ulpi: using ACPI for GPIO lookup
> > [   35.126538] tusb1210 dwc3.0.auto.ulpi: using lookup tables for GPIO lookup
> > [   35.126548] tusb1210 dwc3.0.auto.ulpi: No GPIO consumer cs found
> > [   40.534107] tusb1210 dwc3.0.auto.ulpi: error -110 writing val 0x41 to reg 0x80
> > 
> > (I put 5000 ms there to be sure)
> > 
> >> I'm fine with going with this workaround patch to fix things.
> 
> Ok, so I guess we should just apply this workaround patch to make
> the error non fatal. Still would be good to dig a little deeper one
> of these days and see what is going on here...

Can you give a formal tag?

-- 
With Best Regards,
Andy Shevchenko