Hi,
I'm having a bit of trouble with the mcf_qspi driver. It seems there is
a problem with read transfers greater than four bytes - EINVAL is
returned as an error from any ioctl call with length > 4, but it doesn't
seem like that should be true. In the driver I have from the January
snapshot, here is the relevant code segment:
case QSPIIOCS_READDATA:
read_data = (struct qspi_read_data *)arg;
error = access_ok(VERIFY_READ, read_data,
sizeof(struct qspi_read_data));
if (!error) {
ret = error;
break;
}
if (read_data->length >
sizeof(read_data->buf)) {
ret = -EINVAL;
break;
}
#if LINUX_VERSION_CODE < KERNEL_VERSION(2,4,0)
memcpy_fromfs(&dev->read_data, read_data,
sizeof(struct qspi_read_data));
#else
copy_from_user(&dev->read_data, read_data,
sizeof(struct qspi_read_data));
#endif
break;
Specifically, the problem code is the "if (read_data->length >
sizeof(read_data->buf))" check, which I believe is checking the buffer
length passed in the qspi_read_data by the user with the size of a
pointer - hence the four bytes. Doing a quick Google found this
reference by Wilson:
http://mailman.uclinux.org/pipermail/uclinux-dev/2006-May/038629.html
where he's added a comment for this check.
Am I confused, or is this check really feasible? And more interestingly
for Linux, isn't there really a missing copy from user to kernel space
here, of the user-supplied buffer?
What I'm doing (for now) is simply commenting out this check, because I
don't see how it can be made with the given information, and because for
uClinux, the (alleged) missing buffer copy is not really necessary
anyways. Is this wise?
This approach seems to work, anyways, except for a different
limitation. Specifically, if more than sixteen bytes are transfered,
the chip selects are toggled, which is problematic for devices such as
Ramtron (www.ramtron.com) FRAM devices that support large transfers,
defined by a command and variable length data fields. Anyone working on
this, or am I on my own here?
Thanks!
-Bob
_______________________________________________
uClinux-dev mailing list
[email protected]
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by [email protected]
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev
