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:
signature.asc
Description: PGP signature
