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;
Date:   Thu, 28 Jan 2021 18:13:07 +0300
From:   Dan Carpenter <dan.carpenter@oracle.com>
To:     Kari Argillander <kari.argillander@gmail.com>
Cc:     Carlis <zhangxuezhi3@gmail.com>, devel@driverdev.osuosl.org,
        linux-fbdev@vger.kernel.org, mh12gx2825@gmail.com,
        gregkh@linuxfoundation.org, oliver.graute@kococonnector.com,
        linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org,
        sbrivio@redhat.com, colin.king@canonical.com,
        zhangxuezhi1@yulong.com
Subject: Re: [PATCH v10] staging: fbtft: add tearing signal detect
Message-ID: <20210128151306.GG2696@kadam>
References: <1611754972-151016-1-git-send-email-zhangxuezhi3@gmail.com>
 <20210127223222.3lavtl3roc4cabso@kari-VirtualBox>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20210127223222.3lavtl3roc4cabso@kari-VirtualBox>
User-Agent: Mutt/1.9.4 (2018-02-28)
Precedence: bulk

On Thu, Jan 28, 2021 at 12:32:22AM +0200, Kari Argillander wrote:
> On Wed, Jan 27, 2021 at 09:42:52PM +0800, Carlis wrote:
> > @@ -82,6 +111,33 @@ enum st7789v_command {
> >   */
> >  static int init_display(struct fbtft_par *par)
> >  {
> > +	int rc;
> > +	struct device *dev = par->info->device;
> > +
> > +	par->gpio.te = devm_gpiod_get_index_optional(dev, "te", 0, GPIOD_IN);
> > +	if (IS_ERR(par->gpio.te)) {
> > +		rc = PTR_ERR(par->gpio.te);
> > +		dev_err(par->info->device, "Failed to request te gpio: %d\n", rc);
> > +		return rc;
> > +	}
> 
> You request with optinal and you still want to error out? We could just
> continue and not care about that error. User will be happier if device
> still works somehow.
> 

Carlis tried that approach in previous versions.  See the discussion
about -EPROBEi_DEFER.

That's not the right way to think about it anyway.  It's optional but
the user *chose* to enable it so if an error occurs then it's still an
error and should be treated like an error.  The user should fix the
error or disable the feature if they want to continue.

There are lots of places in the kernel where the error handling could
be written to try continue but in a crippled state.  It's not the right
approach.  Over engineering like that just leads to bugs.

regards,
dan carpenter