On Thu, Oct 11, 2012 at 04:57:11AM +0900, Greg KH wrote: > On Wed, Oct 10, 2012 at 03:05:09PM +0200, Jarkko Huijts wrote: > > On Tue, 2012-10-09 at 07:59 -0700, Greg KH wrote: > > > On Tue, Oct 09, 2012 at 12:21:56PM +0200, Jarkko Huijts wrote: > > > > I have e-mailed FTDI's support to ask whether the assumptions described > > > > above are true and whether there is no register to read the actual > > > > amount of data in the hardware buffer(s). Their website states you need > > > > to sign an NDA to get the register descriptions, but with some luck that > > > > isn't needed. > > > > OK, no luck. I got a reply that pretty much said "please sign this NDA" > > and since I'm not a lawyer, I'm not sure whether the conditions would > > allow me to use their datasheet for GPL code. > > > > > Your function looks good, care to add it to the file and create a patch > > > so that I can apply it properly to the kernel tree? > > > > Sure. I've made a patch for the latest stable (v3.6.1) using git. Let me > > know if anything if not OK. > > > > Note: The code shown in this thread was for v2.6.38. Two new types of > > FTDI device are supported in v3.6.1. I've updated my code in the same as > > ftdi_tiocmget(). > > The patch looks great, thanks so much for doing this. I'll queue it up > after 3.7-rc1 is released by Linus (which should be in a few days). Sorry for not commenting on this sooner (been travelling). Thanks for the patch Jarkko. Your solution is nice, but I think it could implemented in a slightly better way. For starters, the subdrivers really shouldn't be poking around in the generic driver's implementation details unless really necessary. Rather we should export the generic chars_in_buffer so that other drivers may implement similar functionality, should their protocols support it. Secondly, you're more or less copying the tiocmget implementation rather then reusing the current implementation (with buffer allocation and device-dependent status-format handling). Finally, there's a small optimisation that could be made from only checking the hardware buffers when we now that the software buffers are actually empty (rather than unconditionally submitting the control urb). I took the liberty to implement the above based on your solution. I'll respond to this mail with a patch series that also includes some minor clean ups and a fixes. Greg, my series subsumes Jarkko's patch, but if preferred I could rebase my changes on top of it instead. Thanks, Johan -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
