Re: Handling Signal1 in microchip-tcb-capture

[William Breathitt Gray <william.gray@linaro.org>]

[-- Attachment #1.1: Type: text/plain, Size: 1517 bytes --]

On Tue, Oct 18, 2022 at 10:01:49AM +0200, Kamel Bouhara wrote:
> On Mon, Oct 17, 2022 at 05:57:59PM -0400, William Breathitt Gray wrote:
> > It might be nice to expose the channel 1 revolution value as Count1 at
> > some point in the future. However, channel 1 seems unrelated to the
> > current issue we're dicussing so we can avoid it for now.
> 
> OK do you suggest to read both count values in the same mchp_tc_count_read() ?

Yes, you can differentiate between the requested Count by checking
count->id. So for id 0 return the channel 0 value, and for id 1 return
the channel 1 value.

> > By the way, I suspect there are race conditions present in
> > mcho_tc_count_function_write() that could be resolved by adding a lock
> > to the mchp_tc_data structure and acquiring it before accessing the
> > device state and registers. It's unrelated to the Signal1 issues so I
> > haven't looked any further into it, but it's something you might want to
> > investigate to make sure you don't get weird behavior from the driver.
> >
> 
> You mean between function_write() and action_write() ?

Those are the callbacks that stood out immediately. For example, it's
possible that these functions are called concurrently, resulting in a
race where qdec_mode is initially evaluated as true but changes to false
before action_write() completes; or similarly, the regmap operations in
function_write() could be clobbered by if another call is happening at
the same time.

William Breathitt Gray

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

[-- Attachment #2: Type: text/plain, Size: 176 bytes --]

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel