Linux IIO development
 help / color / mirror / Atom feed
From: <Dharma.B@microchip.com>
To: <wbg@kernel.org>
Cc: <kamel.bouhara@bootlin.com>,
	<linux-arm-kernel@lists.infradead.org>,
	<linux-iio@vger.kernel.org>, <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v2] counter: microchip-tcb-capture: Add watch validation support
Date: Tue, 20 May 2025 14:23:11 +0000	[thread overview]
Message-ID: <8335a35f-e111-4a53-83ac-e671d570dace@microchip.com> (raw)
In-Reply-To: <aCxtaya-1SXkPiob@ishi>

On 20/05/25 5:24 pm, William Breathitt Gray wrote:
> On Tue, May 20, 2025 at 09:36:42AM +0530, Dharma Balasubiramani wrote:
>> The Timer Counter Block (TCB) exposes several kinds of events to the
>> Counter framework, but not every event is meaningful on every hardware
>> channel. Add a `watch_validate()` callback so userspace may register only
>> the combinations actually supported:
>>
>> * Channel 0 (COUNTER_MCHP_EVCHN_CV, COUNTER_MCHP_EVCHN_RA)
>>     - COUNTER_EVENT_CAPTURE
>>     - COUNTER_EVENT_CHANGE_OF_STATE
>>     - COUNTER_EVENT_OVERFLOW
>>
>> * Channel 1 (COUNTER_MCHP_EVCHN_RB)
>>     - COUNTER_EVENT_CAPTURE
>>
>> * Channel 2 (COUNTER_MCHP_EVCHN_RC)
>>     - COUNTER_EVENT_THRESHOLD
>>
>> Any other request is rejected with `-EINVAL`, preventing undefined
>> behaviour in userspace.
> 

Hi William,

> Hi Dharma
> 
> The requesting an invalid watch configuration wouldn't necessarily lead
> to undefined beaviour in userspace -- at least as far as the Counter
> character device interface is concerned. What would happen is that the
> requested event is never pushed to that particular channel, so userspace
> is left watching for an event that never arrives for that particular
> watch: not an ideal situation, but not undefined.

Got it, Thanks. (I'll rephrase the commit message in the next revision)

> 
>>
>> Signed-off-by: Dharma Balasubiramani <dharma.b@microchip.com>
>> ---
>> Tested the code on target (sam9x60_curiosity) using the following commands
>>
>> valid ones:
>> ./counter_watch_events -d -wevt_change_of_state,chan=0
>> ./counter_watch_events -d -wevt_ovf,chan=0
>> ./counter_watch_events -d -wevt_capture,chan=0
>> ./counter_watch_events -d -wevt_capture,chan=1
>> ./counter_watch_events -d -wevt_threshold,chan=2
>>
>> invalid ones:
>> ./counter_watch_events -d -wevt_threshold,chan=0
>> ./counter_watch_events -d -wevt_threshold,chan=1
>> Error adding watches[0]: Invalid argument
>> ---
>> Changes in v2:
>> - Include COUNTER_MCHP_EVCHN_CV as well for the sake of completeness.
>> - Adjust the code to ensure channel limitations.
>> - Drop sorting in this patch, will be taken care seperately.
>> - Link to v1: https://lore.kernel.org/r/20250515-counter-tcb-v1-1-e547061ed80f@microchip.com
> 
> Thank you for the changes. I have a minor adjustment suggestion below
> that I believe makes the code look a little nicer.
> 
>> ---
>>   drivers/counter/microchip-tcb-capture.c | 24 +++++++++++++++++++++++-
>>   1 file changed, 23 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/counter/microchip-tcb-capture.c b/drivers/counter/microchip-tcb-capture.c
>> index 1de3c50b9804..fe817f4f1edc 100644
>> --- a/drivers/counter/microchip-tcb-capture.c
>> +++ b/drivers/counter/microchip-tcb-capture.c
>> @@ -337,6 +337,27 @@ static struct counter_comp mchp_tc_count_ext[] = {
>>   	COUNTER_COMP_COMPARE(mchp_tc_count_compare_read, mchp_tc_count_compare_write),
>>   };
>>
>> +static int mchp_tc_watch_validate(struct counter_device *counter,
>> +				  const struct counter_watch *watch)
>> +{
>> +	if (watch->channel == COUNTER_MCHP_EVCHN_CV || watch->channel == COUNTER_MCHP_EVCHN_RA) {
>> +		switch (watch->event) {
>> +		case COUNTER_EVENT_CHANGE_OF_STATE:
>> +		case COUNTER_EVENT_OVERFLOW:
>> +		case COUNTER_EVENT_CAPTURE:
>> +			return 0;
>> +		default:
>> +			return -EINVAL;
>> +		}
>> +	} else if (watch->channel == COUNTER_MCHP_EVCHN_RB) {
>> +		return (watch->event == COUNTER_EVENT_CAPTURE) ? 0 : -EINVAL;
>> +	} else if (watch->channel == COUNTER_MCHP_EVCHN_RC) {
>> +		return (watch->event == COUNTER_EVENT_THRESHOLD) ? 0 : -EINVAL;
>> +	} else {
>> +		return -EINVAL;
>> +	}
> 
> You can use the early returns to avoid the else statements, and some
> other additional cleanups can be done as well:
> 
>      if (watch->channel == COUNTER_MCHP_EVCHN_CV || watch->channel == COUNTER_MCHP_EVCHN_RA)
>      	switch (watch->event) {
>      	case COUNTER_EVENT_CHANGE_OF_STATE:
>      	case COUNTER_EVENT_OVERFLOW:
>      	case COUNTER_EVENT_CAPTURE:
>      		return 0;
>      	default:
>      		return -EINVAL;
>      	}
>      
>      if (watch->channel == COUNTER_MCHP_EVCHN_RB && watch->event == COUNTER_EVENT_CAPTURE)
>      	return 0;
>      
>      if (watch->channel == COUNTER_MCHP_EVCHN_RC && watch->event == COUNTER_EVENT_THRESHOLD)
>      	return 0;
>      
>      return -EINVAL;
> 
> I think something like that looks a bit closer to the Linux kernel style
> present in the other drivers, so that we're all consistent.

Thanks, I will stick to it.

> 
> William Breathitt Gray


-- 
With Best Regards,
Dharma B.

      reply	other threads:[~2025-05-20 14:23 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <F_LcZtjhYzQUlCmEka_20DiefdWFYYoq-u3JOct5ctrcMrJfTi3APjAWNAK97Mpluwkqgr9rQ-35KzO0Uuifow==@protonmail.internalid>
2025-05-20  4:06 ` [PATCH v2] counter: microchip-tcb-capture: Add watch validation support Dharma Balasubiramani
2025-05-20 11:54   ` William Breathitt Gray
2025-05-20 14:23     ` Dharma.B [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=8335a35f-e111-4a53-83ac-e671d570dace@microchip.com \
    --to=dharma.b@microchip.com \
    --cc=kamel.bouhara@bootlin.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-iio@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=wbg@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox