Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.34 as permitted sender) client-ip=23.128.96.34;
Date:   Mon, 23 Oct 2023 19:28:28 -0500
From:   Jeff LaBundy <jeff@labundy.com>
To:     Stephan Gerhold <stephan@gerhold.net>
Cc:     Dmitry Torokhov <dmitry.torokhov@gmail.com>,
        Rob Herring <robh+dt@kernel.org>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
        Conor Dooley <conor+dt@kernel.org>,
        Henrik Rydberg <rydberg@bitmath.org>,
        linux-input@vger.kernel.org, devicetree@vger.kernel.org,
        linux-kernel@vger.kernel.org,
        Christophe JAILLET <christophe.jaillet@wanadoo.fr>,
        Jonathan Albrieux <jonathan.albrieux@gmail.com>
Subject: Re: [PATCH v2 2/2] Input: add Himax HX852x(ES) touchscreen driver
Message-ID: <ZTcPrC+0K1unNPIv@nixie71>
References: <20230930-hx852x-v2-0-c5821947b225@gerhold.net>
 <20230930-hx852x-v2-2-c5821947b225@gerhold.net>
 <ZTVoiklUJaDn5576@nixie71>
 <ZTVuqW7oU5BmPzTS@gerhold.net>
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <ZTVuqW7oU5BmPzTS@gerhold.net>
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?dGUu2+nAphGCY0TliGciEeNwergSZHvZZIHBHD1lUYBb9c2EzkiPbh8hPfu/?=
 =?us-ascii?Q?U5i5jog6TKkDg/8Xzzu86MpIsLOwsY7vzGOtx0UYlic81vEQtCKyQLtX3aoz?=
 =?us-ascii?Q?JbXCO5vn7rZIvYrZGQnTuK5Xm7mGtgvzl1gQ0FBsye4dja1iQsZt1Ty1Owfh?=
 =?us-ascii?Q?q04YE4qcDVodaCTw7Fl9QTZvMUc6ggJT7+Tt9Y/HICXKHvD+wWyenzT3ibXs?=
 =?us-ascii?Q?0lEnS4NNaS+6lwt5kdXMRi2XRT8oiGGKhDxOQg3nF8RMdpPzdcY3D1sXRG25?=
 =?us-ascii?Q?d5l/TNPpcG25U4iQuTWWKyg4L/aj7wCfAHyd1AL++Y1CyUkUHIY6YmvDw2ii?=
 =?us-ascii?Q?MO2JM4QehIx+yJwdsROyWRQKxwzN4nDmO5/gnal9s3hSFPXczzBxTePfkrUp?=
 =?us-ascii?Q?CyJWxGL+/br3UgVCbD8AcUq8QVwz9J9KaYGvo5jemO6R+LxcG6oIJoKths2x?=
 =?us-ascii?Q?94W9Rr38zo5jazkcBoqK2YA9K6/lkdXH3DITk1FPGJi7X7q4r5kpfP60fi2Y?=
 =?us-ascii?Q?lTZGosrvEKBuwvjHSCHjzE3hQpDNfq52GN9/EV2c/xdNPXlZb2B9DRBiRcZV?=
 =?us-ascii?Q?jtdI9DnHpyZ6ibVmeXR/x0xjZn9Pk2Z4zyFRBvc3KBeJ6ymzZ4wyNz5MY1XM?=
 =?us-ascii?Q?MOpK7UaCRZyJ55hsDj09Ma0UG02iwdoMk4H2G+eHrY/JL9Wc8da8W03C+v3T?=
 =?us-ascii?Q?0Goz168gkZM5dcnc9ZDoPK8fH37ARmihBtALUKNVci7Klq1Pf7aDVcNllqmp?=
 =?us-ascii?Q?nnjlV6wk5zjrgbiSZeJ8x3qAuxrq5ETdSMzTENtfi7ocVPdGPORLHtvnJ/SA?=
 =?us-ascii?Q?Fc8ZUxK1dtiWl8hyPQlZ6yXph/249eKdYDDjBJLbNmNymzGYVXb6ZjeDHi0u?=
 =?us-ascii?Q?EorJptL/6OvtUbCY5XYg416GyZx2kiQSkiEUSLLJjIwXkp3KuXHWIPEdAnUn?=
 =?us-ascii?Q?B0dxSr+KiVbs23KU/r9ZnQChhX1LWy1zRnkaL9PRgscy/7fWnVmd65WErPAU?=
 =?us-ascii?Q?n7ckdwQM9/s31F4haDzcGo+mP/Hl4iJLPtft3NY0Q1LeQM1yIylGOU/0ym0Q?=
 =?us-ascii?Q?A86Z8VMJ/hA9enFbErKd1qpHQk+3PVY2FJlXubxNKaUFFXNEtfdRfUnneuc8?=
 =?us-ascii?Q?x6GPZMIvVTqcOTWfieknPgNxx27C3Enge8Q9AgQAmAcAREx2w5//ZVTHDW56?=
 =?us-ascii?Q?K5f8D8O/aGZYs6bj5VXhERQIdcK4KZmtWRVFgrtqPwxXyiCoTg6xJBhAZMvT?=
 =?us-ascii?Q?00TLuGtNHztAj/5YWCaGu04MK9IZ4ws2lnOYe/ThE33cM0GSu5V3UeiQUlIA?=
 =?us-ascii?Q?Sg9C3zcf9YiYkTMRVH7aBLJDC+7ezo5YKUczpK4MsALWCD2GidYo8aGNMpkG?=
 =?us-ascii?Q?/hkhI2TR3N6WzchQJCmbpYMCJNxn74biaCoCWXKArscSUg+IpgIEWfzO/7wa?=
 =?us-ascii?Q?DuC9xrMMO5yEyf5ANkJpSEUfOg3AqU+5nKGDwOQ9uxw4EcRlE66rx/xIa4SL?=
 =?us-ascii?Q?cgIEwOly4y396z+SaFHOx5QOgVTojoizhQW4cnLDiLTcyimWxeGBL/4VghRc?=
 =?us-ascii?Q?fStvtdgdTvfeaGGXcPWjwpdGaLxlYbv6mbGeK1o5?=
X-OriginatorOrg: labundy.com
X-MS-Exchange-CrossTenant-Network-Message-Id: ddaac6c0-948c-4e48-3d1c-08dbd4282868
X-MS-Exchange-CrossTenant-AuthSource: SN4PR0801MB3774.namprd08.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 24 Oct 2023 00:28:34.7482
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 00b69d09-acab-4585-aca7-8fb7c6323e6f
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: XwKI6NOPfZGkpk1Av4oWR0meiKf3UMXtwD/K3zGRGbBs8IP5gV52t1ETOTpM7yZ/XD1l2ibGl77aF+nJhc/HZw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: LV8PR08MB9556
X-Spam-Status: No, score=-0.8 required=5.0 tests=DKIM_SIGNED,DKIM_VALID,
	HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,
	SPF_PASS autolearn=unavailable autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on howler.vger.email
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org
X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (howler.vger.email [0.0.0.0]); Mon, 23 Oct 2023 17:29:22 -0700 (PDT)

Hi Stephan,

On Sun, Oct 22, 2023 at 08:49:13PM +0200, Stephan Gerhold wrote:
> > > +static int hx852x_read_config(struct hx852x *hx)
> > > +{
> > > +	struct device *dev = &hx->client->dev;
> > > +	struct hx852x_config conf;
> > > +	int x_res, y_res;
> > > +	int error;
> > > +
> > > +	error = hx852x_power_on(hx);
> > > +	if (error)
> > > +		return error;
> > > +
> > > +	/* Sensing must be turned on briefly to load the config */
> > > +	error = hx852x_start(hx);
> > > +	if (error)
> > > +		goto err_power_off;
> > > +
> > > +	error = hx852x_stop(hx);
> > > +	if (error)
> > > +		goto err_power_off;
> > > +
> > > +	error = i2c_smbus_write_byte_data(hx->client, HX852X_REG_SRAM_SWITCH,
> > > +					  HX852X_SRAM_SWITCH_TEST_MODE);
> > > +	if (error)
> > > +		goto err_power_off;
> > > +
> > > +	error = i2c_smbus_write_word_data(hx->client, HX852X_REG_SRAM_ADDR,
> > > +					  HX852X_SRAM_ADDR_CONFIG);
> > > +	if (error)
> > > +		goto err_test_mode;
> > > +
> > > +	error = hx852x_i2c_read(hx, HX852X_REG_FLASH_RPLACE, &conf, sizeof(conf));
> > > +	if (error)
> > > +		goto err_test_mode;
> > > +
> > > +	x_res = be16_to_cpu(conf.x_res);
> > > +	y_res = be16_to_cpu(conf.y_res);
> > > +	hx->max_fingers = (conf.max_pt & 0xf0) >> 4;
> > > +	dev_dbg(dev, "x res: %u, y res: %u, max fingers: %u\n",
> > > +		x_res, y_res, hx->max_fingers);
> > > +
> > > +	if (hx->max_fingers > HX852X_MAX_FINGERS) {
> > > +		dev_err(dev, "max supported fingers: %u, found: %u\n",
> > > +			HX852X_MAX_FINGERS, hx->max_fingers);
> > > +		error = -EINVAL;
> > > +		goto err_test_mode;
> > > +	}
> > > +
> > > +	if (x_res && y_res) {
> > > +		input_set_abs_params(hx->input_dev, ABS_MT_POSITION_X, 0, x_res - 1, 0, 0);
> > > +		input_set_abs_params(hx->input_dev, ABS_MT_POSITION_Y, 0, y_res - 1, 0, 0);
> > > +	}
> > > +
> > > +	error = i2c_smbus_write_byte_data(hx->client, HX852X_REG_SRAM_SWITCH, 0);
> > > +	if (error)
> > > +		goto err_power_off;
> > > +
> > > +	return hx852x_power_off(hx);
> > > +
> > > +err_test_mode:
> > > +	i2c_smbus_write_byte_data(hx->client, HX852X_REG_SRAM_SWITCH, 0);
> > > +err_power_off:
> > > +	hx852x_power_off(hx);
> > > +	return error;
> > 
> > Your new version is an improvement, but maybe we can remove duplicate
> > code by introducing some helper variables:
> > 
> > 	int error, error2 = 0, error3;
> > 
> > 	/* ... */
> > 
> > err_test_mode:
> > 	error2 = i2c_smbus_write_byte_data(...);
> > 
> > err_power_off:
> > 	error3 = hx852x_power_off(...);
> > 
> > 	if (error)
> > 		return error;
> > 
> > 	return error2 ? : error3;
> > 
> > In this case we achieve our goal of attempting to return the device to a
> > safe state in both passing and failing cases. In the event of multiple
> > errors, we return the first to occur.
> > 
> 
> Right, this would work as well. Personally I think my solution is
> slightly easier to read though. In your version my eyes somewhat
> "stumble" over the multiple "error" variables and then about the purpose
> of the "? : " construction. This is probably highly subjective. :-)

Agreed, my suggestion is a bit unwieldy, and prone to uninitialized
variable bugs. However, I feel that duplicate code, especially side
by side like this, is also confusing and prone to bugs in case the
sequence must be updated in the future. As a compromise, how about
something closer to my first idea:

err_test_mode:
	error = i2c_smbus_write_byte_data(...) ? : error;

err_power_off:
	return hx852x_power_off(...) ? : error;

This is nice and compact, and ensures that errors returned by the two
functions are reported no matter the flow. The only functional change
is that the _last_ error takes priority; but in practice this does not
really matter. Normally if one I2C write fails, all subsequent writes
will fail with the same return code until the hardware is recovered
somehow.

For the corner case where the code jumps to exit_test_mode with error
equal to -EINVAL, and i2c_smbus_write_byte_data() then fails and changes
error to something like -EIO, I don't think we care. After the HW issue
is fixed and all I2C writes succeed, the developer will then see that
the number of contacts reported by the FW is invalid anyway :)

Side note: the '? :' syntax is just a shortcut that sets error equal
to the return value of i2c_smbus_write_byte_data() if true (failure)
without having to declare a temporary variable. If false (no failure),
error is assigned to itself. It is perfectly legal.

> Do you mind if keep this as-is? I don't have a strong opinion about
> this, but a slight preference for my current solution.

I think any of these three solutions gets the job done; please choose
the one you feel is easiest to read and maintain.

> > > +}

Kind regards,
Jeff LaBundy