On Thu, Mar 7, 2019 at 12:32 PM William Breathitt Gray
[off-list ref] wrote:

quoted

+/*
+ * take mutex
+ * call ftm_clear_write_protection
+ * update settings
+ * call ftm_set_write_protection
+ * release mutex
+ */

Jonathan mentioned it before in the previous review, and I think I agree
too, that this comment block is superfluous: the context of this code is
simple enough that the function call order is naturally obvious (i.e.
write protection must be cleared before settings are modified).

The only important thing to mention here is that the mutex must be held
before the write protection state is modified so a comment along the
following lines should suffice:

/* hold mutex before modifying write protection state */

I think that keeping the more verbose comments is better. You directly see
what operations are needed, and is a good reminder, especially if you
are not familiar with the driver.
I'll use your comment on the next version if you insist (see below for
why new versoion).

quoted

+static void ftm_quaddec_disable(struct ftm_quaddec *ftm)
+{
+     ftm_write(ftm, FTM_MODE, 0);
+}

The ftm_quaddec_disable function is only used for cleanup when the
driver is being removed. Is disabling the FTM counter on removal
actually something we need to do?

It might provide some power-saving, so I would keep that function.

While it's true that the register will keep updating, since the driver
is no longer loaded, we don't care about that register value. Once we
take control of the hardware again (by reloading our driver or via a new
one), we reinitialize the counter and set the count value back to 0
anyway -- so whatever value the register had no longer matters.

Indeed the previous values at start do not matter. It's there just to
shut down the device properly.
This discussion made me verify again the specs and in its current form
the disable doesn't even work at all :
 - That register should be written with write protection disabled (duh!)
 - It doesn't even stop the FTM from running, the clock must be
disabled for that.

So I'll probably provide a fix for that (in some days/weeks).

quoted

+
+enum ftm_quaddec_count_function {
+     FTM_QUADDEC_COUNT_ENCODER_MODE_1,
+};

The FlexTimer Module supports more than just a quadrature counter mode
doesn't it?

We should keep this initial patch simple since we are still introducing
the Counter subsystem, but it'll be nice to add support in the future
for the other counter modes such as single-edge capture.

yes it provides more features, those are in a backlog ;). I would
prefer if this simple version(I mean, with the disable/shutdown fixed)
of the driver could be merged already before extending support.

quoted

+
+static struct counter_signal ftm_quaddec_signals[] = {
+     {
+             .id = 0,
+             .name = "Channel 1 Quadrature A"
+     },
+     {
+             .id = 1,
+             .name = "Channel 1 Quadrature B"
+     }
+};

If possible, these names should match the FTM datasheet naming
convention. The reason is to make it easier for users to match the
input signals described in the datasheet with the Signal data provided
by the Generic Counter interface.

I think the FTM datasheet describes these signals as "Phase A" and
"Phase B", so perhaps "Channel 1 Phase A" and "Channel 1 Phase B" may be
more appropriate names in this case.

I'll verify those,

quoted

+static int ftm_quaddec_remove(struct platform_device *pdev)
+{
+     struct ftm_quaddec *ftm = platform_get_drvdata(pdev);
+
+     counter_unregister(&ftm->counter);
+
+     ftm_quaddec_disable(ftm);
+
+     return 0;
+}

If the ftm_quaddec_disable is not necessary, then we can eliminate the
ftm_quaddec_remove function as well by replacing the counter_register
call with a devm_counter_register call.

yes, but as stated before, I would keep it for potential energy saving.

Thanks for your feedback :)

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