[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CACRpkda_hYA23mC3qnF_jUuhgU9+JZj1rWv2h3o8e+8oxnth1Q@mail.gmail.com>
Date: Sat, 11 Jul 2020 23:20:45 +0200
From: Linus Walleij <linus.walleij@...aro.org>
To: Florian Fainelli <f.fainelli@...il.com>
Cc: Mark Tomlinson <Mark.Tomlinson@...iedtelesis.co.nz>,
"ray.jui@...adcom.com" <ray.jui@...adcom.com>,
"bcm-kernel-feedback-list@...adcom.com"
<bcm-kernel-feedback-list@...adcom.com>,
"linux-gpio@...r.kernel.org" <linux-gpio@...r.kernel.org>,
"sbranden@...adcom.com" <sbranden@...adcom.com>,
"rjui@...adcom.com" <rjui@...adcom.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] pinctrl: initialise nsp-mux earlier.
On Sat, Jul 11, 2020 at 11:09 PM Florian Fainelli <f.fainelli@...il.com> wrote:
> On 7/11/2020 2:07 PM, Linus Walleij wrote:
> > I never got an updated patch. My last message was:
> >
> >>> so you mean something like this?
> >>>
> >>> if (err == -EPROBE_DEFER)
> >>> dev_info(dev, "deferring probe\n")
> >>> else
> >>> dev_err(dev, "... failed to register\n")
> >>
> >> Yes exactly.
> >
> > Patches welcome :D
>
> Not sure how useful the dev_info(dev, "deferring probe\n") is nowadays
> given that the device driver core will show which devices are on the
> probe deferral list, maybe we can turn this into a dev_dbg() instead?
Oh right. Yeah that sounds right, then we can see that it's the
GPIO core bailing and deferring it when we turn on debug.
Yours,
Linus Walleij
Powered by blists - more mailing lists