On Wed, Nov 23, 2016 at 05:17:35PM +0100, Wolfgang Wilhelm wrote: > Thankyou very much for the really fast answer. > > I don't get any error messages and I can communicate with > the driver for the second device via ioctrl and write functions, > i.e. write registers and read registers via the RBUF ioctrl function, > only the read function for the second device does not work, > i.e. no data is obtained from the mcs6_read function for the > second device. Hm, let me go look at the driver again, maybe something's odd with it. > Thankyou for your hint using libusb, I will have a look on it. > > Our USB device has three endpoints, two with 64 kb packet size > for reading and writing registers (I know this is not standard > for high speed) and one with 512 kb packet size for reading data. > Do you think the problem could arise from this deviation > from the USB standard? No, it should be fine, the USB standard only care about endpoint sizes, not logical "packet" sizes, right? > Of course we would be happy if our driver could be merged into > the Linux kernel. If you can use libusb, I'd strongly recommend using that and not a kernel driver at all, as we don't like adding kernel drivers where they are not needed. > Our device uses the same vendor/product id's as a > "D-Link DSB-R100 USB FM radio" dsbr100, that has a built-in > driver in some Linux distributions, so that dsbr100 must be > blacklisted in /etc/modprobe.d/fbdev-blacklist.conf for > using our driver. Does your device work like the USB FM radio device? Why is the same vendor/device id being used here? They are supposed to be unique for different types of devices. > Which security problems do you see in the code? No checking that the values given to you by userspace are actually valid and within "sane" ranges :) thanks, greg k-h -- 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
