Re: [RFC 08/11] gpiolib: cdev: Add hardware timestamp clock type
From: Kent Gibson <warthog618@gmail.com>
Date: 2021-08-03 22:38:46
Also in:
linux-doc, linux-gpio, linux-tegra, lkml
On Tue, Aug 03, 2021 at 03:41:56PM -0700, Dipen Patel wrote:
On 7/30/21 11:05 PM, Kent Gibson wrote:quoted
On Thu, Jul 29, 2021 at 08:07:15PM -0700, Dipen Patel wrote:quoted
On 7/1/21 7:24 AM, Kent Gibson wrote:<snip>quoted
quoted
quoted
ret = gpiod_direction_output(desc, val); if (ret) return ret;@@ -1152,6 +1186,13 @@ static long linereq_set_config_unlocked(struct linereq *lr, polarity_change); if (ret) return ret; + + /* Check if new config sets hardware assisted clock */ + if (flags & GPIO_V2_LINE_FLAG_EVENT_CLOCK_HARDWARE) { + ret = gpiod_hw_timestamp_control(desc, true); + if (ret) + return ret; + } }The error code here can come from the pinctrl timestamp_control(), so it should be sanitised before being returned to userspace.I do not understand what do you mean by sanitise. I just followed what gpiod_direction_output did just above which also returns ret from gpio driver code similar to timestamp_control API.In this context, sanitise means convert any kernel internal error codes to their userspace equivalent before returning them to userspace. Fair enough with the gpiod_direction_output() comparison. I was thinking of a patch Andy recently submitted[1] to sanitise gpiod_request(), which can sometimes return EPROBE_DEFER. But I guess we can wait until we find a case of a driver returning an internal error code and add a sanitiser then.Make sense, I will add sanity checkquoted
But I said don't bother yet. And you need to know what errors to sanitise before you sanitise them - unless you want to run through all the possibilities that can be returned to userspace. Cheers, Kent.