On Fri, Aug 06, 2021 at 10:35:10PM -0700, Dipen Patel wrote:

On 8/6/21 9:51 PM, Kent Gibson wrote:

quoted

On Fri, Aug 06, 2021 at 09:52:54PM -0700, Dipen Patel wrote:

quoted

On 8/6/21 8:07 PM, Kent Gibson wrote:

quoted

On Fri, Aug 06, 2021 at 07:41:09PM -0700, Dipen Patel wrote:

quoted

On 7/31/21 8:43 AM, Kent Gibson wrote:

quoted

On Wed, Jul 28, 2021 at 04:59:08PM -0700, Dipen Patel wrote:

quoted

Thanks Kent for the review comment. My responses inline.

<snip>

quoted

quoted

quoted

2. Does hte handler solution create race between two handlers? i.e. edge_irq_handler and

hte_handler, for the worst case scenario as below?

No.  If hardware timestamp is selected then no irq is requested from the
irq subsystem for that line - only from the hte subsystem instead.
So there will be no edge_irq_handler call for that line, so no possible race.

That is not possible for certain providers, for example the one I am dealing

with which requires GPIO line to be requested as input and IRQ needs to

be enabled on them.

So, for your hte subsystem to work, the consumer has to also request
a line from the irq subsystem?

Yes

quoted

  That makes sense to you?

Its not me, its peculiarity of the hardware that I am dealing with.

My point is that the peculiarities of the hardware should be hidden from
the hte API user, especially if it is only necessary for some hardware.

quoted

Have hte do that, rather than the consumer.

Sure, for cdev it would mean to duplicate (most of) the edge* or line_create

code in HTE.

And your current way every other hte user will have to duplicate the
gpiolib-cdev code....

For such hardware, my initial doubt remains the same about

the worst case scenario between two handlers, but perhaps that's

implementation details for hte to handle.

Indeed.

Cheers,
Kent.

quoted

And another reason it makes sense to integrate this with irq...

Alright, will explore this route as well. I remember both Thierry[1] and

Marc[2] raised some doubts (time to revive that discussion).


[1]: https://lore.kernel.org/lkml/YFm9r%2FtFkzVlYDEp@orome.fritz.box/ (local)

[2]: https://lore.kernel.org/lkml/87h7l1k9yi.wl-maz@kernel.org/ (local)

quoted

Cheers,
Kent.