Potential kernel bug in L4T 32.6.1 (failure to update return value)?

In the source for drivers/iio/accel/hid-sensor-accel-3d.c, the following code exists to assign a timestamp but fails to set ‘ret = 0’ after setting accel_state->timestamp.

/* Capture samples in local storage */
static int accel_3d_capture_sample(struct hid_sensor_hub_device *hsdev,
				unsigned usage_id,
				size_t raw_len, char *raw_data,
				void *priv)
{
	struct iio_dev *indio_dev = platform_get_drvdata(priv);
	struct accel_3d_state *accel_state = iio_priv(indio_dev);
	int offset;
	int ret = -EINVAL;

	switch (usage_id) {
	case HID_USAGE_SENSOR_ACCEL_X_AXIS:
	case HID_USAGE_SENSOR_ACCEL_Y_AXIS:
	case HID_USAGE_SENSOR_ACCEL_Z_AXIS:
		offset = usage_id - HID_USAGE_SENSOR_ACCEL_X_AXIS;
		accel_state->accel_val[CHANNEL_SCAN_INDEX_X + offset] =
						*(u32 *)raw_data;
		ret = 0;
	break;
	case HID_USAGE_SENSOR_TIME_TIMESTAMP:
		accel_state->timestamp =
			hid_sensor_convert_timestamp(
					&accel_state->common_attributes,
					*(int64_t *)raw_data);
	break;
	default:
		break;
	}

	return ret;
}

A similar construct exists in drivers/iio/gyro/hid-sensor-gyro-3d.c which sets ‘ret’:

	case HID_USAGE_SENSOR_TIME_TIMESTAMP:	// usec->nsec
		gyro_state->timestamp = (*(int64_t *)raw_data)*1000;
		ret = 0;
	break;

hello john.kane,

may I know what’s the failure without ret=0 for HID_USAGE_SENSOR_TIME_TIMESTAMP?
thanks

I don’t know if this is directly causing a failure, I noticed it when reviewing the kernel code.