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;
MIME-Version: 1.0
References: <20200630212958.24030-1-mark.tomlinson@alliedtelesis.co.nz>
 <a1dc8f14-187d-a804-45bb-d1fa25ff7b01@broadcom.com> <760595a8cdfeb0156d5180ecaeb2ee4487f50cc7.camel@alliedtelesis.co.nz>
 <86c009a8-05c4-40a3-daef-6d9e848642a3@gmail.com> <db96187e25342cd36133cde64ef742e03325c8c3.camel@alliedtelesis.co.nz>
 <cd40f919-f8d9-cde4-6cc5-f523e4973c3b@gmail.com> <CACRpkdZRQq3EbibSWcKnTp6+iFJACeaytQEX+zR69Y_4LMSkYg@mail.gmail.com>
 <e5d97c2a-95fb-e02d-029a-c19ceb1b166f@gmail.com>
In-Reply-To: <e5d97c2a-95fb-e02d-029a-c19ceb1b166f@gmail.com>
From:   Linus Walleij <linus.walleij@linaro.org>
Date:   Sat, 11 Jul 2020 23:20:45 +0200
Message-ID: <CACRpkda_hYA23mC3qnF_jUuhgU9+JZj1rWv2h3o8e+8oxnth1Q@mail.gmail.com>
Subject: Re: [PATCH] pinctrl: initialise nsp-mux earlier.
To:     Florian Fainelli <f.fainelli@gmail.com>
Cc:     Mark Tomlinson <Mark.Tomlinson@alliedtelesis.co.nz>,
        "ray.jui@broadcom.com" <ray.jui@broadcom.com>,
        "bcm-kernel-feedback-list@broadcom.com" 
        <bcm-kernel-feedback-list@broadcom.com>,
        "linux-gpio@vger.kernel.org" <linux-gpio@vger.kernel.org>,
        "sbranden@broadcom.com" <sbranden@broadcom.com>,
        "rjui@broadcom.com" <rjui@broadcom.com>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Content-Type: text/plain; charset="UTF-8"
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Sat, Jul 11, 2020 at 11:09 PM Florian Fainelli <f.fainelli@gmail.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