Re: [PATCH] firewire-ohci: work around oversized DMA reads on JMicron controllers

g 0x10 padding bytes at > the end of descriptor buffer pages, which should be harmless to do > unconditionally for controllers in case others have the same behavior. > > Signed-off-by: Hector Martin <mar...@marcan.st> Reviewed-by: Clemens Ladisch <clem...@ladisch.de> > ---

Re: [PATCH] firewire-ohci: work around oversized DMA reads on JMicron controllers

g 0x10 padding bytes at > the end of descriptor buffer pages, which should be harmless to do > unconditionally for controllers in case others have the same behavior. > > Signed-off-by: Hector Martin Reviewed-by: Clemens Ladisch > --- > drivers/firewire/ohci.c | 8 +++- > 1 file

Re: [alsa-devel] [PATCH] opl3: Fix a possible sleep-in-atomic bug in snd_opl3_find_patch

Jia-Ju Bai wrote: > The driver may sleep under a spinlock, and the function call path is: > snd_opl3_note_on (acquire the spinlock) > snd_opl3_find_patch > kzalloc(GFP_KERNEL) --> may sleep This call path is not possible because create_patch is not set. Regards, Clemens

Re: [alsa-devel] [PATCH] opl3: Fix a possible sleep-in-atomic bug in snd_opl3_find_patch

Jia-Ju Bai wrote: > The driver may sleep under a spinlock, and the function call path is: > snd_opl3_note_on (acquire the spinlock) > snd_opl3_find_patch > kzalloc(GFP_KERNEL) --> may sleep This call path is not possible because create_patch is not set. Regards, Clemens

Re: [alsa-devel] [PATCH] ALSA: oxygen: Xonar DG(X): make model_xonar_dg const

Bhumika Goyal wrote: > Make this const as it not modified anywhere. It is only used during a > copy operation. Also, add const to the declaration in header. > > Signed-off-by: Bhumika Goyal <bhumi...@gmail.com> Acked-by: Clemens Ladisch <clem...@ladisch.de> > --- >

Re: [alsa-devel] [PATCH] ALSA: oxygen: Xonar DG(X): make model_xonar_dg const

Bhumika Goyal wrote: > Make this const as it not modified anywhere. It is only used during a > copy operation. Also, add const to the declaration in header. > > Signed-off-by: Bhumika Goyal Acked-by: Clemens Ladisch > --- > sound/pci/oxygen/xonar_dg.h | 2 +- &

Re: [PATCH] hwmon: (k10temp) Add support for family 17h

Guenter Roeck wrote: > On Tue, Sep 05, 2017 at 04:12:07PM +0200, Clemens Ladisch wrote: >> Guenter Roeck wrote: >>> What we should do then, as we did for coretemp, would be to collect the >>> various >>> temperature offsets (and temperature limits, for

Re: [PATCH] hwmon: (k10temp) Add support for family 17h

Guenter Roeck wrote: > On Tue, Sep 05, 2017 at 04:12:07PM +0200, Clemens Ladisch wrote: >> Guenter Roeck wrote: >>> What we should do then, as we did for coretemp, would be to collect the >>> various >>> temperature offsets (and temperature limits, for

Re: [PATCH] hwmon: (k10temp) Add support for family 17h

Guenter Roeck wrote: > On 09/04/2017 11:47 PM, Clemens Ladisch wrote: >> Guenter Roeck wrote: >>> Some of this is guesswork, but afaics it is working. No idea if there >>> is a better way to determine the temperature offset. >> >> The reported value is

Re: [PATCH] hwmon: (k10temp) Add support for family 17h

Guenter Roeck wrote: > On 09/04/2017 11:47 PM, Clemens Ladisch wrote: >> Guenter Roeck wrote: >>> Some of this is guesswork, but afaics it is working. No idea if there >>> is a better way to determine the temperature offset. >> >> The reported value is

Re: [alsa-devel] [PATCH RESEND1 00/12] ALSA: vsnd: Add Xen para-virtualized frontend driver

Oleksandr Andrushchenko wrote: >>> We understand that emulated interrupt on the frontend side is completely not >>> acceptable Allow me to expand on that: Proper synchronization requires that the exact position is communicated, not estimated. Just because the nominal rate of the stream is known

Re: [alsa-devel] [PATCH RESEND1 00/12] ALSA: vsnd: Add Xen para-virtualized frontend driver

Oleksandr Andrushchenko wrote: >>> We understand that emulated interrupt on the frontend side is completely not >>> acceptable Allow me to expand on that: Proper synchronization requires that the exact position is communicated, not estimated. Just because the nominal rate of the stream is known

Re: [PATCH] hwmon: (k10temp) Add support for family 17h

Guenter Roeck wrote: > Add support for temperature sensors on Family 17h (Ryzen) processors. > > Signed-off-by: Guenter Roeck > --- > Some of this is guesswork, but afaics it is working. No idea if there > is a better way to determine the temperature offset. The reported

Re: [PATCH] hwmon: (k10temp) Add support for family 17h

Guenter Roeck wrote: > Add support for temperature sensors on Family 17h (Ryzen) processors. > > Signed-off-by: Guenter Roeck > --- > Some of this is guesswork, but afaics it is working. No idea if there > is a better way to determine the temperature offset. The reported value is not an absolute

Re: [alsa-devel] [PATCH] ALSA: USB-MIDI: Use common error handling code in __snd_usbmidi_create()

SF Markus Elfring wrote: > Add jump targets so that a bit of exception handling can be better reused > at the end of this function. > > This issue was detected by using the Coccinelle software. > > Signed-off-by: Markus Elfring <elfr...@users.sourceforge.net> Acked-b

Re: [alsa-devel] [PATCH] ALSA: USB-MIDI: Use common error handling code in __snd_usbmidi_create()

SF Markus Elfring wrote: > Add jump targets so that a bit of exception handling can be better reused > at the end of this function. > > This issue was detected by using the Coccinelle software. > > Signed-off-by: Markus Elfring Acked-by: Clemens Ladisch > --- >

Re: [alsa-devel] [PATCH 08/11] ALSA: vsnd: Add timer for period interrupt emulation

Oleksandr Andrushchenko wrote: > On 08/07/2017 04:11 PM, Clemens Ladisch wrote: >> How does that interface work? > > For the buffer received in .copy_user/.copy_kernel we send > a request to the backend and get response back (async) when it has copied > the bytes into HW/mix

Re: [alsa-devel] [PATCH 08/11] ALSA: vsnd: Add timer for period interrupt emulation

Oleksandr Andrushchenko wrote: > On 08/07/2017 04:11 PM, Clemens Ladisch wrote: >> How does that interface work? > > For the buffer received in .copy_user/.copy_kernel we send > a request to the backend and get response back (async) when it has copied > the bytes into HW/mix

Re: [alsa-devel] [PATCH 08/11] ALSA: vsnd: Add timer for period interrupt emulation

Oleksandr Andrushchenko wrote: > On 08/07/2017 01:27 PM, Clemens Ladisch wrote: >> You have to implement period interrupts (and the .pointer callback) >> based on when the samples are actually moved from/to the backend. > > Do you think I can implement this in a slightly dif

Re: [alsa-devel] [PATCH 08/11] ALSA: vsnd: Add timer for period interrupt emulation

Oleksandr Andrushchenko wrote: > On 08/07/2017 01:27 PM, Clemens Ladisch wrote: >> You have to implement period interrupts (and the .pointer callback) >> based on when the samples are actually moved from/to the backend. > > Do you think I can implement this in a slightly dif

Re: [alsa-devel] [PATCH 08/11] ALSA: vsnd: Add timer for period interrupt emulation

Oleksandr Andrushchenko wrote: > Front sound driver has no real interrupts, so > playback/capture period passed interrupt needs to be emulated: > this is done via timer. Add required timer operations, > this is based on sound/drivers/dummy.c. A 'real' sound card use the interrupt to synchronize

Re: [alsa-devel] [PATCH 08/11] ALSA: vsnd: Add timer for period interrupt emulation

Oleksandr Andrushchenko wrote: > Front sound driver has no real interrupts, so > playback/capture period passed interrupt needs to be emulated: > this is done via timer. Add required timer operations, > this is based on sound/drivers/dummy.c. A 'real' sound card use the interrupt to synchronize

Re: [PATCH 18/18] ALSA: opl4: Move inline before return type

Joe Perches wrote: > Make the code like the rest of the kernel. > > Signed-off-by: Joe Perches <j...@perches.com> Acked-by: Clemens Ladisch <clem...@ladisch.de> > --- > sound/drivers/opl4/opl4_lib.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) >

Re: [PATCH 18/18] ALSA: opl4: Move inline before return type

Joe Perches wrote: > Make the code like the rest of the kernel. > > Signed-off-by: Joe Perches Acked-by: Clemens Ladisch > --- > sound/drivers/opl4/opl4_lib.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/sound/drivers/opl4/opl4_lib.c b/sound

Re: HPET enabled in BIOS, not presented as available_clocksource -- config, kernel code, &/or BIOS?

Randy Dunlap wrote: > On 05/12/17 19:30, PGNet Dev wrote: >> dmesg | grep -i hpet >> [8.491738] hpet_acpi_add: no address or irqs in _CRS > > Above line marks a big failure. > ^^^ > >> Disassembling the firmware acpi tables >>

Re: HPET enabled in BIOS, not presented as available_clocksource -- config, kernel code, &/or BIOS?

Randy Dunlap wrote: > On 05/12/17 19:30, PGNet Dev wrote: >> dmesg | grep -i hpet >> [8.491738] hpet_acpi_add: no address or irqs in _CRS > > Above line marks a big failure. > ^^^ > >> Disassembling the firmware acpi tables >>

Re: [PATCH v2] usb: core: Warn if an URB's transfer_buffer is on stack

Florian Fainelli wrote: > We see a large number of fixes to several drivers to remove the usage of > on-stack buffers feeding into USB transfer functions. Make it easier to spot > the offenders by adding a warning in usb_hcd_map_urb_for_dma() checking that > urb->transfer_buffer is not a stack

Re: [PATCH v2] usb: core: Warn if an URB's transfer_buffer is on stack

Florian Fainelli wrote: > We see a large number of fixes to several drivers to remove the usage of > on-stack buffers feeding into USB transfer functions. Make it easier to spot > the offenders by adding a warning in usb_hcd_map_urb_for_dma() checking that > urb->transfer_buffer is not a stack

Re: [PATCH v2 5/6] hpet: removing unused variable m in hpet_interrupt

Corentin Labbe wrote: > This patch fix the following warning: > drivers/char/hpet.c:146:17: attention : variable ‘m’ set but not used > [-Wunused-but-set-variable] > by removing the unused variable m in hpet_interrupt This patch might silence the warning, but it leaves the bug that actually

Re: [PATCH v2 5/6] hpet: removing unused variable m in hpet_interrupt

Corentin Labbe wrote: > This patch fix the following warning: > drivers/char/hpet.c:146:17: attention : variable ‘m’ set but not used > [-Wunused-but-set-variable] > by removing the unused variable m in hpet_interrupt This patch might silence the warning, but it leaves the bug that actually

Re: [PATCH] ALSA: oxygen - Fix snd_oxygen module not loading for some (new?) Xonar DG SI cards.

Eugene Ganeev wrote: > My Xonar DG SI card is showing up in lspci but no module is loaded for > it. > > The patch just adds a new value with card's PCI ID to oxygen_ids array. Is the hardware identical? Do all the inputs and outputs work? > Signed-off-by: Eugene Ganeev >

Re: [PATCH] ALSA: oxygen - Fix snd_oxygen module not loading for some (new?) Xonar DG SI cards.

Eugene Ganeev wrote: > My Xonar DG SI card is showing up in lspci but no module is loaded for > it. > > The patch just adds a new value with card's PCI ID to oxygen_ids array. Is the hardware identical? Do all the inputs and outputs work? > Signed-off-by: Eugene Ganeev > --- >

Re: [PATCH 2/6] hpet: remove unused writeq/readq function definitions

Corentin Labbe wrote: > On Mon, Mar 27, 2017 at 07:49:34AM +0800, kbuild test robot wrote: >>drivers//char/hpet.c: In function 'hpet_timer_set_irq': drivers//char/hpet.c:207:7: error: implicit declaration of function 'readq' [-Werror=implicit-function-declaration] > > Wrongly

Re: [PATCH 2/6] hpet: remove unused writeq/readq function definitions

Corentin Labbe wrote: > On Mon, Mar 27, 2017 at 07:49:34AM +0800, kbuild test robot wrote: >>drivers//char/hpet.c: In function 'hpet_timer_set_irq': drivers//char/hpet.c:207:7: error: implicit declaration of function 'readq' [-Werror=implicit-function-declaration] > > Wrongly

Re: [PATCH v1] hpet: Make cmd parameter of hpet_ioctl_common() unsigned

:77:28: note: expanded from macro '_IOR' > ^ > include/uapi/asm-generic/ioctl.h:66:2: note: expanded from macro '_IOC' > (((dir) << _IOC_DIRSHIFT) | \ > > Signed-off-by: Matthias Kaehlcke <m...@chromium.org> Acked-by: Clemens La

Re: [PATCH v1] hpet: Make cmd parameter of hpet_ioctl_common() unsigned

:77:28: note: expanded from macro '_IOR' > ^ > include/uapi/asm-generic/ioctl.h:66:2: note: expanded from macro '_IOC' > (((dir) << _IOC_DIRSHIFT) | \ > > Signed-off-by: Matthias Kaehlcke Acked-by: Clemens Ladisch > --- > dri

Re: [alsa-devel] [RFC] [ALSA][CONTROL] Added 2 ioctls for reading/writing values of multiple controls in one go (at once)

Satendra Singh Thakur wrote: > -Added an ioctl to read values of multiple elements at once > -Added an ioctl to write values of multiple elements at once > -In the absence of above ioctls user needs to call N ioctls to > read/write value of N elements which requires N context switches And why

Re: [alsa-devel] [RFC] [ALSA][CONTROL] Added 2 ioctls for reading/writing values of multiple controls in one go (at once)

Satendra Singh Thakur wrote: > -Added an ioctl to read values of multiple elements at once > -Added an ioctl to write values of multiple elements at once > -In the absence of above ioctls user needs to call N ioctls to > read/write value of N elements which requires N context switches And why

Re: [alsa-devel] [PATCH 6/7] dmasound_core: Move two assignments for the variable "ret" in state_open()

SF Markus Elfring wrote: > A local variable was set to an error code in two cases before a concrete > error situation was detected. And why would that be a problem? http://yarchive.net/comp/linux/error_jumps.html > - ret = -EBUSY; > - if (state.busy) > + if (state.busy) { > +

Re: [alsa-devel] [PATCH 6/7] dmasound_core: Move two assignments for the variable "ret" in state_open()

SF Markus Elfring wrote: > A local variable was set to an error code in two cases before a concrete > error situation was detected. And why would that be a problem? http://yarchive.net/comp/linux/error_jumps.html > - ret = -EBUSY; > - if (state.busy) > + if (state.busy) { > +

Re: [alsa-devel] [PATCH v2 1/2] ALSA: usb-audio: more tolerant packetsize

l packetsize. > > Signed-off-by: Andreas Pape <ap...@de.adit-jv.com> > Signed-off-by: Jiada Wang <jiada_w...@mentor.com> Acked-by: Clemens Ladisch <clem...@ladisch.de> > --- a/sound/usb/endpoint.c > +++ b/sound/usb/endpoint.c > @@ -632,8 +632,8 @@ static int dat

Re: [alsa-devel] [PATCH v2 1/2] ALSA: usb-audio: more tolerant packetsize

l packetsize. > > Signed-off-by: Andreas Pape > Signed-off-by: Jiada Wang Acked-by: Clemens Ladisch > --- a/sound/usb/endpoint.c > +++ b/sound/usb/endpoint.c > @@ -632,8 +632,8 @@ static int data_ep_set_params(struct snd_usb_endpoint *ep, > ep->

Re: [alsa-devel] [PATCH 1/3 v1] ALSA: usb-audio: more tolerant packetsize

Jiada Wang wrote: > On 11/30/2016 11:41 PM, Clemens Ladisch wrote: >> Jiada Wang wrote: >>> since commit 57e6dae1087bbaa6b33d3dd8a8e90b63888939a3 the expected >>> packetsize is always limited to >>> nominal + 25%. It was discovered, that some devices >> &

Re: [alsa-devel] [PATCH 1/3 v1] ALSA: usb-audio: more tolerant packetsize

Jiada Wang wrote: > On 11/30/2016 11:41 PM, Clemens Ladisch wrote: >> Jiada Wang wrote: >>> since commit 57e6dae1087bbaa6b33d3dd8a8e90b63888939a3 the expected >>> packetsize is always limited to >>> nominal + 25%. It was discovered, that some devices >> &

Re: [alsa-devel] [PATCH 1/3 v1] ALSA: usb-audio: more tolerant packetsize

Takashi Iwai wrote: > Clemens Ladisch wrote: >> Takashi Iwai wrote: >>> [...] >>> In the commit mentioned above, we changed the logic to take +25% >>> frequency as the basis, and it my *reduce* if ep->maxpacksize is lower >>> than that. >&

Re: [alsa-devel] [PATCH 1/3 v1] ALSA: usb-audio: more tolerant packetsize

Takashi Iwai wrote: > Clemens Ladisch wrote: >> Takashi Iwai wrote: >>> [...] >>> In the commit mentioned above, we changed the logic to take +25% >>> frequency as the basis, and it my *reduce* if ep->maxpacksize is lower >>> than that. >&

Re: [alsa-devel] [PATCH 1/3 v1] ALSA: usb-audio: more tolerant packetsize

Takashi Iwai wrote: > Clemens Ladisch wrote: >> Jiada Wang wrote: >>> since commit 57e6dae1087bbaa6b33d3dd8a8e90b63888939a3 the expected >>> packetsize is always limited to >>> nominal + 25%. It was discovered, that some devices >> >> Which d

Re: [alsa-devel] [PATCH 1/3 v1] ALSA: usb-audio: more tolerant packetsize

Takashi Iwai wrote: > Clemens Ladisch wrote: >> Jiada Wang wrote: >>> since commit 57e6dae1087bbaa6b33d3dd8a8e90b63888939a3 the expected >>> packetsize is always limited to >>> nominal + 25%. It was discovered, that some devices >> >> Which d

Re: [alsa-devel] [PATCH 1/3 v1] ALSA: usb-audio: more tolerant packetsize

Jiada Wang wrote: > since commit 57e6dae1087bbaa6b33d3dd8a8e90b63888939a3 the expected packetsize > is always limited to > nominal + 25%. It was discovered, that some devices Which devices? > have a much higher jitter in used packetsizes than 25% How high? (Please note that the USB

Re: [alsa-devel] [PATCH 1/3 v1] ALSA: usb-audio: more tolerant packetsize

Jiada Wang wrote: > since commit 57e6dae1087bbaa6b33d3dd8a8e90b63888939a3 the expected packetsize > is always limited to > nominal + 25%. It was discovered, that some devices Which devices? > have a much higher jitter in used packetsizes than 25% How high? (Please note that the USB

Re: Multiple problems with the Linux kernel on an AMD desktop

Rogério Brito wrote: > [ 130.007219] evbug: Event. Dev: input6, Type: 0, Code: 0, Value: 0 The evbug module is intended for debugging; it dumps all input events into syslog. If you do not want these messages, do not load this module. (If it is loaded automatically, you have an actual bug.)

Re: Multiple problems with the Linux kernel on an AMD desktop

Rogério Brito wrote: > [ 130.007219] evbug: Event. Dev: input6, Type: 0, Code: 0, Value: 0 The evbug module is intended for debugging; it dumps all input events into syslog. If you do not want these messages, do not load this module. (If it is loaded automatically, you have an actual bug.)

Re: Multiple problems with the Linux kernel on an AMD desktop

Rogério Brito wrote: > * I have never been able to boot this computer of mine without the option > irqpoll---otherwise, I get the nobody cared message. The "nobody cared" message indicates that there were too many interrupts that no driver felt responsible for, so the kernel has disabled that

Re: Multiple problems with the Linux kernel on an AMD desktop

Rogério Brito wrote: > * I have never been able to boot this computer of mine without the option > irqpoll---otherwise, I get the nobody cared message. The "nobody cared" message indicates that there were too many interrupts that no driver felt responsible for, so the kernel has disabled that

Re: [PATCH v2 2/4] samples: move timers example code from Documentation

Jonathan Corbet <cor...@lwn.net> > Signed-off-by: Shuah Khan <shua...@osg.samsung.com> Acked-by: Clemens Ladisch <clem...@ladisch.de>

Re: [PATCH v2 2/4] samples: move timers example code from Documentation

d-by: Jonathan Corbet > Signed-off-by: Shuah Khan Acked-by: Clemens Ladisch

Re: [alsa-devel] [PATCH] ALSA: usb: constify snd_pcm_ops structures

> struct snd_pcm_ops e; > @@ > e@i@p > > @depends on !bad disable optional_qualifier@ > identifier r.i; > @@ > static > +const > struct snd_pcm_ops i = { ... }; > // > > Signed-off-by: Julia Lawall <julia.law...@lip6.fr> Acked-by: Clemens Ladisch

Re: [alsa-devel] [PATCH] ALSA: usb: constify snd_pcm_ops structures

> struct snd_pcm_ops e; > @@ > e@i@p > > @depends on !bad disable optional_qualifier@ > identifier r.i; > @@ > static > +const > struct snd_pcm_ops i = { ... }; > // > > Signed-off-by: Julia Lawall Acked-by: Clemens Ladisch > --- > sound/usb/6fi

Re: [alsa-devel] [PATCH 0/6] constify snd_pcm_ops structures

Julia Lawall wrote: > Constify snd_pcm_ops structures. For 3/5/6: Acked-by: Clemens Ladisch <clem...@ladisch.de>

Re: [alsa-devel] [PATCH 0/6] constify snd_pcm_ops structures

Julia Lawall wrote: > Constify snd_pcm_ops structures. For 3/5/6: Acked-by: Clemens Ladisch

Re: [PATCH v2 0/3] USB Audio Gadget refactoring

Peter Chen wrote: > On Tue, Aug 16, 2016 at 11:32:55AM +0200, Clemens Ladisch wrote: >> Windows does not have UAC2 support. > > Thanks, before windows7 or all windows versions have no UAC2 support? So far, no version has it. Regards, Clemens

Re: [PATCH v2 0/3] USB Audio Gadget refactoring

Peter Chen wrote: > On Tue, Aug 16, 2016 at 11:32:55AM +0200, Clemens Ladisch wrote: >> Windows does not have UAC2 support. > > Thanks, before windows7 or all windows versions have no UAC2 support? So far, no version has it. Regards, Clemens

Re: [PATCH v2 0/3] USB Audio Gadget refactoring

Peter Chen wrote: > I find UAC2 (UAC1 is ok) support is not well with the latest mainline > kernel w/o your patch set. The windows7 can't install the driver > successfully Windows does not have UAC2 support. > and the playback shows underrun (using local codec) > using Linux host. > # arecord

Re: [PATCH v2 0/3] USB Audio Gadget refactoring

Peter Chen wrote: > I find UAC2 (UAC1 is ok) support is not well with the latest mainline > kernel w/o your patch set. The windows7 can't install the driver > successfully Windows does not have UAC2 support. > and the playback shows underrun (using local codec) > using Linux host. > # arecord

Re: [RFC PATCH 0/5] USB Audio Gadget refactoring

Ruslan Bilovol wrote: > On Fri, Jul 15, 2016 at 10:43 AM, Clemens Ladisch <clem...@ladisch.de> wrote: >>>> On Tue, May 24, 2016 at 2:50 AM, Ruslan Bilovol >>>> <ruslan.bilo...@gmail.com> wrote: >>>>> it may break current usecase for some people

Re: [RFC PATCH 0/5] USB Audio Gadget refactoring

Ruslan Bilovol wrote: > On Fri, Jul 15, 2016 at 10:43 AM, Clemens Ladisch wrote: >>>> On Tue, May 24, 2016 at 2:50 AM, Ruslan Bilovol >>>> wrote: >>>>> it may break current usecase for some people >> >> And what are the benefits tha

Re: [RFC PATCH 0/5] USB Audio Gadget refactoring

>> On Tue, May 24, 2016 at 2:50 AM, Ruslan Bilovol >> wrote: >>> it may break current usecase for some people And what are the benefits that justify breaking the kernel API? Regards, Clemens

Re: [RFC PATCH 0/5] USB Audio Gadget refactoring

>> On Tue, May 24, 2016 at 2:50 AM, Ruslan Bilovol >> wrote: >>> it may break current usecase for some people And what are the benefits that justify breaking the kernel API? Regards, Clemens

Re: [PATCH] usb: core: Do not use sizeof on pointer type

Vaishali Thakkar wrote: > When sizeof is applied to a pointer typed expression, it gives > the size of the pointer. And why would that be wrong in this case? > +++ b/drivers/usb/core/hcd.c > @@ -1386,7 +1386,7 @@ static int hcd_alloc_coherent(struct usb_bus *bus, > return -EFAULT;

Re: [PATCH] usb: core: Do not use sizeof on pointer type

Vaishali Thakkar wrote: > When sizeof is applied to a pointer typed expression, it gives > the size of the pointer. And why would that be wrong in this case? > +++ b/drivers/usb/core/hcd.c > @@ -1386,7 +1386,7 @@ static int hcd_alloc_coherent(struct usb_bus *bus, > return -EFAULT;

Re: [alsa-devel] linux-4.6-rc4/sound/pci/ens1370.c:1551: possible bad expression ?

David Binderman wrote: > [linux-4.6-rc4/sound/pci/ens1370.c:1551]: (style) Expression '(X & 0xf)>= > 0x4' is always false. What tool generated this message? > Source code is > > if ((ensoniq->ctrl & ES_1371_GPIO_OUTM)>= 4) > val = 1; This message is wrong; it is certainly

Re: [alsa-devel] linux-4.6-rc4/sound/pci/ens1370.c:1551: possible bad expression ?

David Binderman wrote: > [linux-4.6-rc4/sound/pci/ens1370.c:1551]: (style) Expression '(X & 0xf)>= > 0x4' is always false. What tool generated this message? > Source code is > > if ((ensoniq->ctrl & ES_1371_GPIO_OUTM)>= 4) > val = 1; This message is wrong; it is certainly

Re: [PATCH v2 06/14] USB: ch341: reinitialize chip on reconfiguration

Grigori Goronzy wrote: > Changing the LCR register after initialization does not seem to be > reliable on all chips (particularly not on CH341A). Restructure > initialization and configuration to always reinit the chip on > configuration changes instead and pass the LCR register value directly >

Re: [PATCH v2 06/14] USB: ch341: reinitialize chip on reconfiguration

Grigori Goronzy wrote: > Changing the LCR register after initialization does not seem to be > reliable on all chips (particularly not on CH341A). Restructure > initialization and configuration to always reinit the chip on > configuration changes instead and pass the LCR register value directly >

Re: [PATCH] usb: gadget: f_midi: Fixed a bug when buflen was smaller than wMaxPacketSize

Felipe Ferreri Tonello wrote: > On 11/03/16 23:07, Michal Nazarewicz wrote: >> I’m also wondering whether it would be beneficial to get rid of buflen >> all together and use wMaxPacketSie for in endpoints as well? Is that >> feasible? > > Yes, we could just remove the buflen parameter. > > The

Re: [PATCH] usb: gadget: f_midi: Fixed a bug when buflen was smaller than wMaxPacketSize

Felipe Ferreri Tonello wrote: > On 11/03/16 23:07, Michal Nazarewicz wrote: >> I’m also wondering whether it would be beneficial to get rid of buflen >> all together and use wMaxPacketSie for in endpoints as well? Is that >> feasible? > > Yes, we could just remove the buflen parameter. > > The

Re: [PATCH] usb: gadget: f_midi: Fixed a bug when buflen was smaller than wMaxPacketSize

Steve Calfee wrote: > On Wed, Mar 9, 2016 at 11:39 AM, Felipe F. Tonello > wrote: >> [...] >> This patch fixes this problem by setting the minimum usb_request's buffer >> size >> for the OUT endpoint as its wMaxPacketSize. >> >> --- a/drivers/usb/gadget/function/f_midi.c

Re: [PATCH] usb: gadget: f_midi: Fixed a bug when buflen was smaller than wMaxPacketSize

Steve Calfee wrote: > On Wed, Mar 9, 2016 at 11:39 AM, Felipe F. Tonello > wrote: >> [...] >> This patch fixes this problem by setting the minimum usb_request's buffer >> size >> for the OUT endpoint as its wMaxPacketSize. >> >> --- a/drivers/usb/gadget/function/f_midi.c >> +++

Re: [PATCH 1/5] usb: gadget: f_midi: refactor state machine

Felipe Ferreri Tonello wrote: > On March 4, 2016 8:07:40 AM GMT+00:00, Clemens Ladisch <clem...@ladisch.de> > wrote: >> Felipe Ferreri Tonello wrote: >>> On 03/03/16 11:38, Clemens Ladisch wrote: >>>> But in what way was the old state machine not "pr

Re: [PATCH 1/5] usb: gadget: f_midi: refactor state machine

Felipe Ferreri Tonello wrote: > On March 4, 2016 8:07:40 AM GMT+00:00, Clemens Ladisch > wrote: >> Felipe Ferreri Tonello wrote: >>> On 03/03/16 11:38, Clemens Ladisch wrote: >>>> But in what way was the old state machine not "proper"? >&g

Re: [PATCH 1/5] usb: gadget: f_midi: refactor state machine

Felipe Ferreri Tonello wrote: > On 03/03/16 11:38, Clemens Ladisch wrote: >> But in what way was the old state machine not "proper"? > > Because it didn't reflect all the correct and possible MIDI states The whole point of the one-byte real-time messages is that they

Re: [PATCH 1/5] usb: gadget: f_midi: refactor state machine

Felipe Ferreri Tonello wrote: > On 03/03/16 11:38, Clemens Ladisch wrote: >> But in what way was the old state machine not "proper"? > > Because it didn't reflect all the correct and possible MIDI states The whole point of the one-byte real-time messages is that they

Re: [PATCH 1/5] usb: gadget: f_midi: refactor state machine

Felipe Ferreri Tonello wrote: > On 02/03/16 21:09, Clemens Ladisch wrote: >> Felipe F. Tonello wrote: >>> This refactor results in a cleaner state machine code >> >> It increases the number of states, and now juggles two state variables. >> I cannot agree to it

Re: [PATCH 1/5] usb: gadget: f_midi: refactor state machine

Felipe Ferreri Tonello wrote: > On 02/03/16 21:09, Clemens Ladisch wrote: >> Felipe F. Tonello wrote: >>> This refactor results in a cleaner state machine code >> >> It increases the number of states, and now juggles two state variables. >> I cannot agree to it

Re: [PATCH 1/5] usb: gadget: f_midi: refactor state machine

Felipe F. Tonello wrote: > This refactor results in a cleaner state machine code It increases the number of states, and now juggles two state variables. I cannot agree to it being cleaner. > and as a result fixed a bug when packaging a USB-MIDI packet right after > a non-conformant MIDI byte

Re: [PATCH 1/5] usb: gadget: f_midi: refactor state machine

Felipe F. Tonello wrote: > This refactor results in a cleaner state machine code It increases the number of states, and now juggles two state variables. I cannot agree to it being cleaner. > and as a result fixed a bug when packaging a USB-MIDI packet right after > a non-conformant MIDI byte

Re: [PATCH v7 0/5] usb: usbtmc: Add support for missing functions in USBTMC-USB488 spec

Dave Penkler wrote: > Implement support for the USB488 defined READ_STATUS_BYTE ioctl (1/5) > and SRQ notifications with fasync (2/5) and poll/select (3/5) in order > to be able to synchronize with variable duration instrument > operations. > > Add convenience ioctl to return all device

Re: [PATCH v7 0/5] usb: usbtmc: Add support for missing functions in USBTMC-USB488 spec

Dave Penkler wrote: > Implement support for the USB488 defined READ_STATUS_BYTE ioctl (1/5) > and SRQ notifications with fasync (2/5) and poll/select (3/5) in order > to be able to synchronize with variable duration instrument > operations. > > Add convenience ioctl to return all device

Re: [PATCH 1/2] usb: gadget: f_midi: refactor state machine

Felipe Ferreri Tonello wrote: >> Running status is feature. > >What do you mean by that? That this behavior is intended, and required. > I don't qualify writing a *wrong* MIDI-USB >packet because of a previous MIDI message as a feature. The MIDI Specification qualifies Running Status as a

Re: [PATCH 1/2] usb: gadget: f_midi: refactor state machine

Felipe Ferreri Tonello wrote: >> Running status is feature. > >What do you mean by that? That this behavior is intended, and required. > I don't qualify writing a *wrong* MIDI-USB >packet because of a previous MIDI message as a feature. The MIDI Specification qualifies Running Status as a

Re: [PATCH 1/2] usb: gadget: f_midi: refactor state machine

Felipe F. Tonello wrote: > This refactor includes the following: > * Cleaner state machine code; It does not correctly handle system real time messages inserted between the status and data bytes of other messages. > * Reset state if MIDI message parsed is non-conformant; Why? In a byte

Re: [PATCH 1/2] usb: gadget: f_midi: refactor state machine

Felipe F. Tonello wrote: > This refactor includes the following: > * Cleaner state machine code; It does not correctly handle system real time messages inserted between the status and data bytes of other messages. > * Reset state if MIDI message parsed is non-conformant; Why? In a byte

Re: [PATCH] ALSA: usb-audio: constify usb_protocol_ops structures

Julia Lawall wrote: > The usb_protocol_ops structures are never modified, so declare them as > const. > > Done with the help of Coccinelle. > > Signed-off-by: Julia Lawall Acked-by: Clemens Ladisch > --- > sound/usb/midi.c | 25 + > 1

Re: [PATCH] ALSA: usb-audio: constify usb_protocol_ops structures

Julia Lawall wrote: > The usb_protocol_ops structures are never modified, so declare them as > const. > > Done with the help of Coccinelle. > > Signed-off-by: Julia Lawall <julia.law...@lip6.fr> Acked-by: Clemens Ladisch <clem...@ladisch.de> &g

Re: Ques: [kernel/time/*] Is there any disadvantage in using usleep_range for more than 20ms delay ?

Aniroop Mathur wrote: > As in the kernel documentation, it is mentioned to use msleep for > 10ms+ delay, I am confused whether there would be any disadvantage in > using usleep_range for higher delays values because normally drivers > have variety of delays used (2, 10, 20, 40, 100, 500 ms). > >

Re: Ques: [kernel/time/*] Is there any disadvantage in using usleep_range for more than 20ms delay ?

Aniroop Mathur wrote: > As in the kernel documentation, it is mentioned to use msleep for > 10ms+ delay, I am confused whether there would be any disadvantage in > using usleep_range for higher delays values because normally drivers > have variety of delays used (2, 10, 20, 40, 100, 500 ms). > >

Re: [PATCH] Documentation: email-clients.txt

Sanidhya Solanki wrote: > Claws Mail (GUI) > > -Works. Some people use this successfully for patches. > +Tested and Works as of December 2015. Some people use this successfully > +for patches. "Some people" still doesn't include you: > -Thunderbird is an Outlook clone that likes to mangle text,

Re: [PATCH] Documentation: email-clients.txt

Sanidhya Solanki wrote: > Claws Mail (GUI) > > -Works. Some people use this successfully for patches. > +Tested and Works as of December 2015. Some people use this successfully > +for patches. "Some people" still doesn't include you: > -Thunderbird is an Outlook clone that likes to mangle text,

Re: A new, fast and "unbreakable" encryption algorithm

Ismail Kizir wrote: > What means "did not look random"? A plaintext consisting of repeated bytes (zero, or other values) eventually makes your algorithm go into a loop, which results in repeated bytes. > On the pictures, there is also an example of "full 0"(it appears red, > but it is full 0

Re: A new, fast and "unbreakable" encryption algorithm

Ismail Kizir wrote: > What means "did not look random"? A plaintext consisting of repeated bytes (zero, or other values) eventually makes your algorithm go into a loop, which results in repeated bytes. > On the pictures, there is also an example of "full 0"(it appears red, > but it is full 0

  1   2   3   4   >