Re: UAC2 gadget not recognized on Windows 10
On Wed, Jun 20, 2018 at 11:19 AM Jassi Brar wrote: > > On Wed, Jun 20, 2018 at 8:32 PM, jonsm...@gmail.com > wrote: > > > > > > > > On Wed, Jun 20, 2018 at 9:36 AM Jassi Brar wrote: > >> > >> On Tue, Feb 13, 2018 at 3:02 PM, Robert Bielik > >> wrote: > >> >> Enabling SOF interrupts will be a big pain :-) Well, enabling the > >> >> interrupt itself is a no-brainer, but it'll cause terrible CPU overload. > >> > > >> > Oh, I see. Hmm... would it be possible to allow upper levels to config > >> > this dynamically ? I.e. for the ALSA subsystem there is no need for the > >> > SOF timestamps, whereas for my proposal they would be needed. > >> > > >> > And what kind of CPU overhead are we talking about ? The IRQs shouldn't > >> > come more often than every 125 us, and all that is needed is to take a > >> > timestamp value But I'm probably overlooking a lot of stuff... > >> > > >> I believe we could control data rate precisely enough for the > >> feeedback ep to be needed only for compatibility with Windows (Linux > >> is already tested to work fine, MacOS is reported to have worked when > >> the code was upstreamed.). > > > > > > Right now Windows 10 (all I have checked) refuses to even connect to a > > Linux based UAC2 device. It appears to be complaining that no endpoint > > supporting USB_ENDPOINT_USAGE_FEEDBACK mode is implement. My five minutes > > of poking in the spec implies that implementing this is required for an > > endpoint doing USB_ENDPOINT_SYNC_ASYNC. Maybe this is something that can > > be faked to the point of allowing Windows to connect to the UAC2 gadget > > driver? > > > Thats what I meant. > > > The Windows error you get is: > > "The driver could not find a feedback endpoint for an asynchronous data OUT > > endpoint on device \Device\." > > > For OUT, there might be some hoops to jump. Honestly it's been years > since I read the spec and got the code to work. I find it tempting to > look into Windows 10 as well, but I can't commit to a timeline. For my application there is no recording HW on the gadget. Maybe a quick way to fix this would be to make a flag to say that the gadget is output only? And then change the descriptors around? That would also help with my specific hardware case where the USB controller only supports ISOCHRONOUS in a single direction. Limitation of an Allwinner chip. > > Cheers! -- Jon Smirl jonsm...@gmail.com -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Allocation failure of USB URB in interrupt
this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- Jon Smirl jonsm...@gmail.com -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Plug and play for a tty line disciple networking device
On Wed, Mar 20, 2013 at 7:26 PM, Greg KH gre...@linuxfoundation.org wrote: On Tue, Mar 19, 2013 at 11:30:05AM -0400, jonsm...@gmail.com wrote: How can you achieve plug and play for a ft2232 based USB serial device implementing 802.15.4 networking? The device has a 802.15.4 SOC with a UART attached to a ft2232. With firmware loaded the only thing it can do is talk the 802.15.4 tty line discipline, it is not a general purpose serial port. Right now the device works by plugging it in and it appears as a generic USB serial device like ttyUSB0. You then run a user space app which sets the line discipline, holds the port open and attaches it to the 6lowpan implementation in the networking code. But doing that is inconvenient and users needs to be trained to do it. Much simpler if we could just plug the device in and it worked. We can add a EEPROM to the ft2232 to give it a unique USB ID. Is it possible to make a kernel driver that see this ID, sets the line discipline and wires the serial port directly into the networking code? Yes, you can do that. Is there an existing driver in the kernel that does this? So far all of the ones I've checked still need a user space app. greg k-h -- Jon Smirl jonsm...@gmail.com -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Plug and play for a tty line disciple networking device
On Wed, Mar 20, 2013 at 8:14 PM, Greg KH gre...@linuxfoundation.org wrote: On Wed, Mar 20, 2013 at 08:04:29PM -0400, jonsm...@gmail.com wrote: On Wed, Mar 20, 2013 at 7:26 PM, Greg KH gre...@linuxfoundation.org wrote: On Tue, Mar 19, 2013 at 11:30:05AM -0400, jonsm...@gmail.com wrote: How can you achieve plug and play for a ft2232 based USB serial device implementing 802.15.4 networking? The device has a 802.15.4 SOC with a UART attached to a ft2232. With firmware loaded the only thing it can do is talk the 802.15.4 tty line discipline, it is not a general purpose serial port. Right now the device works by plugging it in and it appears as a generic USB serial device like ttyUSB0. You then run a user space app which sets the line discipline, holds the port open and attaches it to the 6lowpan implementation in the networking code. But doing that is inconvenient and users needs to be trained to do it. Much simpler if we could just plug the device in and it worked. We can add a EEPROM to the ft2232 to give it a unique USB ID. Is it possible to make a kernel driver that see this ID, sets the line discipline and wires the serial port directly into the networking code? Yes, you can do that. Is there an existing driver in the kernel that does this? So far all of the ones I've checked still need a user space app. Look at the bluetooth drivers, they have their own line dicipline I think. Bluetooth drivers use line discipline on UARTs. On USB they have their own set of Bluetooth descriptors. CAN over serial has a line discipline but it needs a user space app. greg k-h -- Jon Smirl jonsm...@gmail.com -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Plug and play for a tty line disciple networking device
On Wed, Mar 20, 2013 at 8:25 PM, Marcel Holtmann mar...@holtmann.org wrote: Hi Greg, How can you achieve plug and play for a ft2232 based USB serial device implementing 802.15.4 networking? The device has a 802.15.4 SOC with a UART attached to a ft2232. With firmware loaded the only thing it can do is talk the 802.15.4 tty line discipline, it is not a general purpose serial port. Right now the device works by plugging it in and it appears as a generic USB serial device like ttyUSB0. You then run a user space app which sets the line discipline, holds the port open and attaches it to the 6lowpan implementation in the networking code. But doing that is inconvenient and users needs to be trained to do it. Much simpler if we could just plug the device in and it worked. We can add a EEPROM to the ft2232 to give it a unique USB ID. Is it possible to make a kernel driver that see this ID, sets the line discipline and wires the serial port directly into the networking code? Yes, you can do that. Is there an existing driver in the kernel that does this? So far all of the ones I've checked still need a user space app. Look at the bluetooth drivers, they have their own line dicipline I think. yes we do. And we also have a userspace tool (hciattach) to setup the line discipline. However the automatic setup can be easily automated with a simple udev rule. Doesn't hciattach have to hang around as a process holding the tty device open? Regards Marcel -- Jon Smirl jonsm...@gmail.com -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Plug and play for a tty line disciple networking device
On Wed, Mar 20, 2013 at 8:38 PM, Greg KH gre...@linuxfoundation.org wrote: On Wed, Mar 20, 2013 at 08:25:15PM -0400, jonsm...@gmail.com wrote: On Wed, Mar 20, 2013 at 8:14 PM, Greg KH gre...@linuxfoundation.org wrote: On Wed, Mar 20, 2013 at 08:04:29PM -0400, jonsm...@gmail.com wrote: On Wed, Mar 20, 2013 at 7:26 PM, Greg KH gre...@linuxfoundation.org wrote: On Tue, Mar 19, 2013 at 11:30:05AM -0400, jonsm...@gmail.com wrote: How can you achieve plug and play for a ft2232 based USB serial device implementing 802.15.4 networking? The device has a 802.15.4 SOC with a UART attached to a ft2232. With firmware loaded the only thing it can do is talk the 802.15.4 tty line discipline, it is not a general purpose serial port. Right now the device works by plugging it in and it appears as a generic USB serial device like ttyUSB0. You then run a user space app which sets the line discipline, holds the port open and attaches it to the 6lowpan implementation in the networking code. But doing that is inconvenient and users needs to be trained to do it. Much simpler if we could just plug the device in and it worked. We can add a EEPROM to the ft2232 to give it a unique USB ID. Is it possible to make a kernel driver that see this ID, sets the line discipline and wires the serial port directly into the networking code? Yes, you can do that. Is there an existing driver in the kernel that does this? So far all of the ones I've checked still need a user space app. Look at the bluetooth drivers, they have their own line dicipline I think. Bluetooth drivers use line discipline on UARTs. On USB they have their own set of Bluetooth descriptors. CAN over serial has a line discipline but it needs a user space app. In your driver, just attach the line discipline directly to the tty device you create. You will not be using the normal usb-serial logic at all if you do this, but you should be fine, right? USB serial port is based on the FT2232 so we've been using that driver. Modifying that driver was my plan for doing this. I was hoping that there was a more generic way to achieve the same effect. It works this way because of ancient history. We used to have dial up terminal sessions into time share unix. Then you'd run a SLIP app to convert the terminal session into a TCP/IP session. The assumption in that scenario is that there is a useful terminal session on the serial connection. In our case the only thing the connection does is talk talk the line discipline. I know how to do it like hciattach. We already have izattach. I'm just trying to get rid of this pointless app that nobody understands why it is there. greg k-h -- Jon Smirl jonsm...@gmail.com -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Plug and play for a tty line disciple networking device
On Wed, Mar 20, 2013 at 8:56 PM, Greg KH gre...@linuxfoundation.org wrote: On Wed, Mar 20, 2013 at 08:49:50PM -0400, jonsm...@gmail.com wrote: On Wed, Mar 20, 2013 at 8:38 PM, Greg KH gre...@linuxfoundation.org wrote: On Wed, Mar 20, 2013 at 08:25:15PM -0400, jonsm...@gmail.com wrote: On Wed, Mar 20, 2013 at 8:14 PM, Greg KH gre...@linuxfoundation.org wrote: On Wed, Mar 20, 2013 at 08:04:29PM -0400, jonsm...@gmail.com wrote: On Wed, Mar 20, 2013 at 7:26 PM, Greg KH gre...@linuxfoundation.org wrote: On Tue, Mar 19, 2013 at 11:30:05AM -0400, jonsm...@gmail.com wrote: How can you achieve plug and play for a ft2232 based USB serial device implementing 802.15.4 networking? The device has a 802.15.4 SOC with a UART attached to a ft2232. With firmware loaded the only thing it can do is talk the 802.15.4 tty line discipline, it is not a general purpose serial port. Right now the device works by plugging it in and it appears as a generic USB serial device like ttyUSB0. You then run a user space app which sets the line discipline, holds the port open and attaches it to the 6lowpan implementation in the networking code. But doing that is inconvenient and users needs to be trained to do it. Much simpler if we could just plug the device in and it worked. We can add a EEPROM to the ft2232 to give it a unique USB ID. Is it possible to make a kernel driver that see this ID, sets the line discipline and wires the serial port directly into the networking code? Yes, you can do that. Is there an existing driver in the kernel that does this? So far all of the ones I've checked still need a user space app. Look at the bluetooth drivers, they have their own line dicipline I think. Bluetooth drivers use line discipline on UARTs. On USB they have their own set of Bluetooth descriptors. CAN over serial has a line discipline but it needs a user space app. In your driver, just attach the line discipline directly to the tty device you create. You will not be using the normal usb-serial logic at all if you do this, but you should be fine, right? USB serial port is based on the FT2232 so we've been using that driver. Modifying that driver was my plan for doing this. I was hoping that there was a more generic way to achieve the same effect. No, sorry, stick with doing this from userspace, it's a simple one-line udev rule, right? It is fairly simple to do from user space. But you have to find and install the pointless user space app and then get it pointed at the correct tty. That app is a hold over from the ancient days. When you killed it the serial line would drop the line discipline and revert back to a terminal session. What you really want is for devices in this class is to not create a user space tty device at all. They should just make a net-device. But there is no way to suppress the creation of the user space tty device. So we get two both devices and the xx-attach app. greg k-h -- Jon Smirl jonsm...@gmail.com -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Plug and play for a tty line disciple networking device
On Wed, Mar 20, 2013 at 9:19 PM, Alan Ott a...@signal11.us wrote: On 03/20/2013 09:12 PM, jonsm...@gmail.com wrote: On Wed, Mar 20, 2013 at 8:56 PM, Greg KH gre...@linuxfoundation.org wrote: On Wed, Mar 20, 2013 at 08:49:50PM -0400, jonsm...@gmail.com wrote: On Wed, Mar 20, 2013 at 8:38 PM, Greg KH gre...@linuxfoundation.org wrote: On Wed, Mar 20, 2013 at 08:25:15PM -0400, jonsm...@gmail.com wrote: On Wed, Mar 20, 2013 at 8:14 PM, Greg KH gre...@linuxfoundation.org wrote: On Wed, Mar 20, 2013 at 08:04:29PM -0400, jonsm...@gmail.com wrote: On Wed, Mar 20, 2013 at 7:26 PM, Greg KH gre...@linuxfoundation.org wrote: On Tue, Mar 19, 2013 at 11:30:05AM -0400, jonsm...@gmail.com wrote: How can you achieve plug and play for a ft2232 based USB serial device implementing 802.15.4 networking? The device has a 802.15.4 SOC with a UART attached to a ft2232. With firmware loaded the only thing it can do is talk the 802.15.4 tty line discipline, it is not a general purpose serial port. Right now the device works by plugging it in and it appears as a generic USB serial device like ttyUSB0. You then run a user space app which sets the line discipline, holds the port open and attaches it to the 6lowpan implementation in the networking code. But doing that is inconvenient and users needs to be trained to do it. Much simpler if we could just plug the device in and it worked. We can add a EEPROM to the ft2232 to give it a unique USB ID. Is it possible to make a kernel driver that see this ID, sets the line discipline and wires the serial port directly into the networking code? Yes, you can do that. Is there an existing driver in the kernel that does this? So far all of the ones I've checked still need a user space app. Look at the bluetooth drivers, they have their own line dicipline I think. Bluetooth drivers use line discipline on UARTs. On USB they have their own set of Bluetooth descriptors. CAN over serial has a line discipline but it needs a user space app. In your driver, just attach the line discipline directly to the tty device you create. You will not be using the normal usb-serial logic at all if you do this, but you should be fine, right? USB serial port is based on the FT2232 so we've been using that driver. Modifying that driver was my plan for doing this. I was hoping that there was a more generic way to achieve the same effect. No, sorry, stick with doing this from userspace, it's a simple one-line udev rule, right? It is fairly simple to do from user space. But you have to find and install the pointless user space app and then get it pointed at the correct tty. The udev rule would handle calling izattach automatically. That app is a hold over from the ancient days. When you killed it the serial line would drop the line discipline and revert back to a terminal session. What you really want is for devices in this class is to not create a user space tty device at all. They should just make a net-device. But there is no way to suppress the creation of the user space tty device. So we get two both devices and the xx-attach app. The udev rule would run when the device gets attached and would call izattach without any need for user interaction. The user would never even need to know what /dev/ttyUSBx ever got assigned to it. We can just leave everything the way it is, but I hit this same problem on another project a few years ago. There's just no generic solution in the kernel for handling serially connected networking hardware without having a pointless user space app. Maybe we could make a generic pointless app and get rid of hciattach, canattach, izattach, etc. The generic app would get the line discipline as part of the udev rule. Even better - put the generic xx-attach code inside udev so we don't have pointless processes hanging around. This is all the code does-- see device appear open device set line discipline hold device exclusively open ... wait for device to disappear exit. Alan. -- Jon Smirl jonsm...@gmail.com -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Plug and play for a tty line disciple networking device
On Wed, Mar 20, 2013 at 9:33 PM, Alan Ott a...@signal11.us wrote: On 03/20/2013 09:28 PM, jonsm...@gmail.com wrote: On Wed, Mar 20, 2013 at 9:19 PM, Alan Ott a...@signal11.us wrote: On 03/20/2013 09:12 PM, jonsm...@gmail.com wrote: On Wed, Mar 20, 2013 at 8:56 PM, Greg KH gre...@linuxfoundation.org wrote: On Wed, Mar 20, 2013 at 08:49:50PM -0400, jonsm...@gmail.com wrote: On Wed, Mar 20, 2013 at 8:38 PM, Greg KH gre...@linuxfoundation.org wrote: On Wed, Mar 20, 2013 at 08:25:15PM -0400, jonsm...@gmail.com wrote: On Wed, Mar 20, 2013 at 8:14 PM, Greg KH gre...@linuxfoundation.org wrote: On Wed, Mar 20, 2013 at 08:04:29PM -0400, jonsm...@gmail.com wrote: On Wed, Mar 20, 2013 at 7:26 PM, Greg KH gre...@linuxfoundation.org wrote: On Tue, Mar 19, 2013 at 11:30:05AM -0400, jonsm...@gmail.com wrote: How can you achieve plug and play for a ft2232 based USB serial device implementing 802.15.4 networking? The device has a 802.15.4 SOC with a UART attached to a ft2232. With firmware loaded the only thing it can do is talk the 802.15.4 tty line discipline, it is not a general purpose serial port. Right now the device works by plugging it in and it appears as a generic USB serial device like ttyUSB0. You then run a user space app which sets the line discipline, holds the port open and attaches it to the 6lowpan implementation in the networking code. But doing that is inconvenient and users needs to be trained to do it. Much simpler if we could just plug the device in and it worked. We can add a EEPROM to the ft2232 to give it a unique USB ID. Is it possible to make a kernel driver that see this ID, sets the line discipline and wires the serial port directly into the networking code? Yes, you can do that. Is there an existing driver in the kernel that does this? So far all of the ones I've checked still need a user space app. Look at the bluetooth drivers, they have their own line dicipline I think. Bluetooth drivers use line discipline on UARTs. On USB they have their own set of Bluetooth descriptors. CAN over serial has a line discipline but it needs a user space app. In your driver, just attach the line discipline directly to the tty device you create. You will not be using the normal usb-serial logic at all if you do this, but you should be fine, right? USB serial port is based on the FT2232 so we've been using that driver. Modifying that driver was my plan for doing this. I was hoping that there was a more generic way to achieve the same effect. No, sorry, stick with doing this from userspace, it's a simple one-line udev rule, right? It is fairly simple to do from user space. But you have to find and install the pointless user space app and then get it pointed at the correct tty. The udev rule would handle calling izattach automatically. That app is a hold over from the ancient days. When you killed it the serial line would drop the line discipline and revert back to a terminal session. What you really want is for devices in this class is to not create a user space tty device at all. They should just make a net-device. But there is no way to suppress the creation of the user space tty device. So we get two both devices and the xx-attach app. The udev rule would run when the device gets attached and would call izattach without any need for user interaction. The user would never even need to know what /dev/ttyUSBx ever got assigned to it. We can just leave everything the way it is, but I hit this same problem on another project a few years ago. There's just no generic solution in the kernel for handling serially connected networking hardware without having a pointless user space app. Maybe we could make a generic pointless app and get rid of hciattach, canattach, izattach, etc. The generic app would get the line discipline as part of the udev rule. Even better - put the generic xx-attach code inside udev so we don't have pointless processes hanging around. Actually, you could use stty for that in the udev rule. You'd have to use the line discipline number instead of the name, but those are part of the userspace ABI, so they won't change. stty won't keep the port locked. Just have to trust people not to mess with it. -- Jon Smirl jonsm...@gmail.com -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Plug and play for a tty line disciple networking device
For an in-kernel solution serial-core would be to modified with a create parameter that says don't make a user space device. Then when the line discipline is registered on a hidden device make it automatically active. FTDI driver USB ID array would get a parameter for line discipline. If parameter is non-zero create the device in hidden mode and set the line disciple. Probably easier to just make new hardware with a real USB implementation on the chip. Like the CC2531. But then I'd have to program an 8051. -- Jon Smirl jonsm...@gmail.com -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
