Re: [PATCH 1/2 ] cdc_ncm: Handle multicast Ethernet traffic
There is nothing wrong with it, but there was no way cdc_ncm driver
could use it, as it currently overwrites the struct net_device_ops, so
the usbnet function set_rx_mode was not ever getting called.
This patch restores the right behavior, so that usbnet's set _rx_mode
gets called again for cdn_ncm devices. The second patch (the one with
the wrong subject) hooks into set_rx_mode to accept multicast traffic
when asked to do so.
Regards.
On 29/06/18 22:37, Oliver Neukum wrote:
> On Fr, 2018-06-29 at 16:45 +0200, Miguel Rodríguez Pérez wrote:
>> Subject: [PATCH 1/2] Hook into usbnet_change_mtu respecting usbnet
>> driver_info
>>
>> Change the way cdc_ncm_change_mtu hooks into the netdev_ops
>> structure so that changes into usbnet driver_info operations
>> can be respected. Without this, is was not possible to hook
>> into usbnet_set_rx_mode.
>
> Hi,
>
> what is wrong with the existing hook?
>
> static void __handle_set_rx_mode(struct usbnet *dev)
> {
> if (dev->driver_info->set_rx_mode)
> (dev->driver_info->set_rx_mode)(dev);
>
> clear_bit(EVENT_SET_RX_MODE, &dev->flags);
> }
>
> If you cannot use it, I would prefer you to actually fix that.
>
> Regards
> Oliver
>
--
Miguel Rodríguez Pérez
Laboratorio de Redes
EE Telecomunicación – Universidade de Vigo
--
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
[PATCH 1/2 ] cdc_ncm: Handle multicast Ethernet traffic
There is nothing wrong with it, but there was no way cdc_ncm driver
could use it, as it currently overwrites the struct net_device_ops, so
the usbnet function set_rx_mode was not ever getting called.
This patch restores the right behavior, so that usbnet's set _rx_mode
gets called again for cdn_ncm devices. The second patch (the one with
the wrong subject) hooks into set_rx_mode to accept multicast traffic
when asked to do so.
Regards.
On 29/06/18 22:37, Oliver Neukum wrote:
> On Fr, 2018-06-29 at 16:45 +0200, Miguel Rodríguez Pérez wrote:
>> Subject: [PATCH 1/2] Hook into usbnet_change_mtu respecting usbnet
>> driver_info
>>
>> Change the way cdc_ncm_change_mtu hooks into the netdev_ops
>> structure so that changes into usbnet driver_info operations
>> can be respected. Without this, is was not possible to hook
>> into usbnet_set_rx_mode.
>
> Hi,
>
> what is wrong with the existing hook?
>
> static void __handle_set_rx_mode(struct usbnet *dev)
> {
> if (dev->driver_info->set_rx_mode)
> (dev->driver_info->set_rx_mode)(dev);
>
> clear_bit(EVENT_SET_RX_MODE, &dev->flags);
> }
>
> If you cannot use it, I would prefer you to actually fix that.
>
> Regards
> Oliver
>
--
Miguel Rodríguez Pérez
Laboratorio de Redes
EE Telecomunicación – Universidade de Vigo
--
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
Zero Packets in Isochronous Transfer Reception
Hello,
My code is a userspace application using libusb for now, but this
seems the best place to ask.
I repurposed some USB audio class device code. At this point I've only
changed the descriptor to report as vendor class so nothing else grabs
the device. I can receive and play PCM audio from the device, but
there is popping and clicking. The program I am using is attached; it
is written in Python. The data is saved to RAM and then written to
disk.
The device does not implement the synchronization aspect of the USB
audio class and when it registers as a microphone a normal userland
can read it properly.
During testing I think I noticed behavior related to my issue - for
some reason there will be long runs of zero returned or no data
returned. Usually this happens when a single transfer is scheduled.
Many transfers in a row tend to report the data properly, but from the
audible results I get it seems that runs of zeros still seem to slip
in.
The problem seems more noticeable when using the Python libusb
bindings but it still exists when using libusb directly. Can anyone
suggest what to look into?
Thanks in advance,
R0b0t1
---
#!/usr/bin/env python3
import usb, numpy as np
import array, wave
def main():
ds = [d for d in
usb.core.find(find_all=True, idVendor=0x, idProduct=0x)]
d = ds[0]
d.set_configuration(1)
d.set_interface_altsetting(interface=1, alternate_setting=1)
f = wave.open('out.wav', 'wb')
f.setnchannels(2)
f.setsampwidth(2)
f.setframerate(48000)
t = array.array('B', [])
try:
while True:
t += d.read(0x81, 200 * 1)
finally:
print('Saved.')
f.writeframes(t)
f.close()
if __name__ == '__main__':
main()
--
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
