Thread (42 messages) 42 messages, 12 authors, 2010-09-24

RE: [RFC] [PATCH V2 1/2] input: CMA3000 Accelerometer driver

From: Hemanth V <hidden>
Date: 2010-08-16 09:45:32
Also in: linux-omap, lkml

From: "Murphy, Dan" <redacted>
Hemanth
I have a few comments on this patch.

+static ssize_t cma3000_store_attr_mdfftmr(struct device *dev,
+					struct device_attribute *attr,
+					const char *buf, size_t count)
+{
+	struct platform_device *pdev = to_platform_device(dev);
+	struct cma3000_accl_data *data = platform_get_drvdata(pdev);
+	unsigned long val;
+	int error;
+
+	error = strict_strtoul(buf, 0, &val);
+	if (error)
+		return error;
+
+	mutex_lock(&data->mutex);
+	data->pdata.mdfftmr = val;
+
+	disable_irq(data->client->irq);
You should use disable_irq_nosync here.  This may not work properly on SMP.
Can u explain why disable_irq will not work on SMP.
quoted
+	if (val == CMARANGE_2G) {
+		ctrl |= CMA3000_RANGE2G;
+		data->pdata.g_range = CMARANGE_2G;
+	} else if (val == CMARANGE_8G) {
+		ctrl |= CMA3000_RANGE8G;
+		data->pdata.g_range = CMARANGE_8G;
Why are you modifying the platform data?  Why not just keep it in a global or a glocal structure and modify it that way?
If you look carefully, the variable data is indeed a local structure.
quoted
+	} else {
+		error = -EINVAL;
+		goto err_op_failed;
+	}
+
+	g_range = data->pdata.g_range;
+	fuzz_x = data->pdata.fuzz_x;
+	fuzz_y = data->pdata.fuzz_y;
+	fuzz_z = data->pdata.fuzz_z;
Why are you storing these locally and then using them once can't we eliminate these completely and just pass the platform data values into the set
params?
I belive this is already discussed and agreed upon in the previous thread of discussion.
Pl refer the same.
quoted
+
+	disable_irq(data->client->irq);
You should use disable_irq_nosync here.  This may not work properly on SMP.
Same comment as above
quoted
+	cma3000_set(data, CMA3000_CTRL, ctrl, "ctrl");
+
+	input_set_abs_params(data->input_dev, ABS_X, -g_range,
+				g_range, fuzz_x, 0);
+	input_set_abs_params(data->input_dev, ABS_Y, -g_range,
+				g_range, fuzz_y, 0);
+	input_set_abs_params(data->input_dev, ABS_Z, -g_range,
+				g_range, fuzz_z, 0);
Don't necessarily agree with modifying the parameters for the input device on the fly.  Some implementations may be a read once on init and do not
go back and check this.
Its the user space code that can modify the grange if required, so I suppose it will need to check
these values after modifying the range.

+		ret = request_threaded_irq(data->client->irq, NULL,
+					cma3000_thread_irq,
+					irqflags | IRQF_ONESHOT,
+					data->client->name, data);

This is implemented wrong.  You are doing a lot of processing in the IRQ context here.  Especially calls out to a peripheral.  The NULL should be
your handler thread where you do all the device processing.
Are u sure u are referring to threaded irq, all the processing is being done in thread
context. Pl refer documentation for more details on threaded irqs.
Also this implementation only suggests that the HW has the IRQ connected what about devices that the IRQ line was not connected?
This is currently not implemented, since I am not aware of any boards with this configuration. A polling method could be added
in future if the need arises.


Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help