linux-kernel - Re: [PATCH v10] staging: fbtft: add tearing signal detect

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20210128151306.GG2696@kadam>
Date:   Thu, 28 Jan 2021 18:13:07 +0300
From:   Dan Carpenter <dan.carpenter@...cle.com>
To:     Kari Argillander <kari.argillander@...il.com>
Cc:     Carlis <zhangxuezhi3@...il.com>, devel@...verdev.osuosl.org,
        linux-fbdev@...r.kernel.org, mh12gx2825@...il.com,
        gregkh@...uxfoundation.org, oliver.graute@...oconnector.com,
        linux-kernel@...r.kernel.org, dri-devel@...ts.freedesktop.org,
        sbrivio@...hat.com, colin.king@...onical.com,
        zhangxuezhi1@...ong.com
Subject: Re: [PATCH v10] staging: fbtft: add tearing signal detect

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