Re: [PATCH v5 7/7] usb: gadget: f_midi: pre-allocate IN requests

Felipe Ferreri Tonello wrote: > One thing to consider is that the ALSA rawmidi device buffer is > sequential and our USB request buffer is not. This means that our 32 > (qlen) * 256 (buflen) = 8KB of data is non-linear. Some requests might > have 3 or 4 bytes (average size of a normal MIDI

Re: [PATCH v5 7/7] usb: gadget: f_midi: pre-allocate IN requests

Felipe Ferreri Tonello wrote: > On 13/11/15 08:55, Clemens Ladisch wrote: >> Felipe F. Tonello wrote: >>> +static void f_midi_transmit(struct f_midi *midi) >>> +{ >>> +... >>> + len = kfifo_peek(>in_req_fifo, ); >>

Re: [PATCH v5 7/7] usb: gadget: f_midi: pre-allocate IN requests

Felipe Ferreri Tonello wrote: > One thing to consider is that the ALSA rawmidi device buffer is > sequential and our USB request buffer is not. This means that our 32 > (qlen) * 256 (buflen) = 8KB of data is non-linear. Some requests might > have 3 or 4 bytes (average size of a normal MIDI

Re: [PATCH v5 7/7] usb: gadget: f_midi: pre-allocate IN requests

Felipe Ferreri Tonello wrote: > On 13/11/15 08:55, Clemens Ladisch wrote: >> Felipe F. Tonello wrote: >>> +static void f_midi_transmit(struct f_midi *midi) >>> +{ >>> +... >>> + len = kfifo_peek(>in_req_fifo, ); >>

Re: [kernel-hardening] [PATCH 0/2] introduce post-init read-only memory

Mathias Krause wrote: > [...] > So, prior extending the usage of the __read_only annotation some > toolchain support is needed. Maybe a gcc plugin that'll warn/error on > code that writes to such a variable but is not __init itself. Or mark them as "const". This would require the initialization

Re: [kernel-hardening] [PATCH 0/2] introduce post-init read-only memory

Mathias Krause wrote: > [...] > So, prior extending the usage of the __read_only annotation some > toolchain support is needed. Maybe a gcc plugin that'll warn/error on > code that writes to such a variable but is not __init itself. Or mark them as "const". This would require the initialization

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

Ismail Kizir wrote: > The essential logic of the algorithm is using the key as a "jump > table" which is dynamically updated with every "jump" we make. Sounds like RC4. Please tell us how you are avoiding the weaknesses that make RC4 insecure. > Briefly, to decypher a ciphertext, a cracker

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

Ismail Kizir wrote: > The essential logic of the algorithm is using the key as a "jump > table" which is dynamically updated with every "jump" we make. Sounds like RC4. Please tell us how you are avoiding the weaknesses that make RC4 insecure. > Briefly, to decypher a ciphertext, a cracker

Re: [PATCH] Sound: Usb: Misc: ua101: replace le16_to_cpu() with usb_endpoint_maxp()

/kernel/git/tiwai/sound.git This does not belong into the commit message. > Signed-off-by: Cheah Kok Cheong Otherwise: Acked-by: Clemens Ladisch > --- > sound/usb/misc/ua101.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/sound/usb/misc/ua101.c

Re: [PATCH] Sound: Usb: Misc: ua101: replace le16_to_cpu() with usb_endpoint_maxp()

/kernel/git/tiwai/sound.git This does not belong into the commit message. > Signed-off-by: Cheah Kok Cheong <thrus...@gmail.com> Otherwise: Acked-by: Clemens Ladisch <clem...@ladisch.de> > --- > sound/usb/misc/ua101.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletio

Re: [PATCH v5 7/7] usb: gadget: f_midi: pre-allocate IN requests

Felipe F. Tonello wrote: > This patch introduces pre-allocation of IN endpoint USB requests. This > improves on latency (requires no usb request allocation on transmit) and avoid > several potential probles on allocating too many usb requests (which involves > DMA pool allocation problems). > >

Re: [PATCH v5 6/7] usb: gadget: f_midi: set altsettings only for MIDIStreaming interface

Felipe F. Tonello wrote: > This avoids duplication of USB requests for OUT endpoint and > re-enabling endpoints. > ... > /* For Control Device interface we do nothing */ > - if (intf == 0) > + if (intf != midi->ms_id) > return 0; The comment now is misleading.

Re: [PATCH v5 6/7] usb: gadget: f_midi: set altsettings only for MIDIStreaming interface

Felipe Ferreri Tonello wrote: > On 10/11/15 18:43, Sergei Shtylyov wrote: >> On 11/10/2015 08:52 PM, Felipe F. Tonello wrote: >>> @@ -75,6 +75,7 @@ struct f_midi { >>> struct usb_ep*in_ep, *out_ep; >>> struct snd_card*card; >>> struct snd_rawmidi*rmidi; >>> +

Re: [PATCH v5 6/7] usb: gadget: f_midi: set altsettings only for MIDIStreaming interface

Felipe Ferreri Tonello wrote: > On 10/11/15 18:43, Sergei Shtylyov wrote: >> On 11/10/2015 08:52 PM, Felipe F. Tonello wrote: >>> @@ -75,6 +75,7 @@ struct f_midi { >>> struct usb_ep*in_ep, *out_ep; >>> struct snd_card*card; >>> struct snd_rawmidi*rmidi; >>> +

Re: [PATCH v5 6/7] usb: gadget: f_midi: set altsettings only for MIDIStreaming interface

Felipe F. Tonello wrote: > This avoids duplication of USB requests for OUT endpoint and > re-enabling endpoints. > ... > /* For Control Device interface we do nothing */ > - if (intf == 0) > + if (intf != midi->ms_id) > return 0; The comment now is misleading.

Re: [PATCH v5 7/7] usb: gadget: f_midi: pre-allocate IN requests

Felipe F. Tonello wrote: > This patch introduces pre-allocation of IN endpoint USB requests. This > improves on latency (requires no usb request allocation on transmit) and avoid > several potential probles on allocating too many usb requests (which involves > DMA pool allocation problems). > >

Re: [PATCH] hpet: Delete an unnecessary check before unregister_sysctl_table()

using the Coccinelle software. > > Signed-off-by: Markus Elfring Acked-by: Clemens Ladisch > --- > drivers/char/hpet.c | 3 +-- > 1 file changed, 1 insertion(+), 2 deletions(-) > > diff --git a/drivers/char/hpet.c b/drivers/char/hpet.c > index 240b6cf..fe511e9 100644 >

Re: [PATCH] hpet: Delete an unnecessary check before unregister_sysctl_table()

eeded. > > This issue was detected by using the Coccinelle software. > > Signed-off-by: Markus Elfring <elfr...@users.sourceforge.net> Acked-by: Clemens Ladisch <clem...@ladisch.de> > --- > drivers/char/hpet.c | 3 +-- > 1 file changed, 1 insertion(+), 2 deletions(-) >

Re: character driver - poll() timeout

Muni Sekhar wrote: > On Tue, Oct 27, 2015 at 8:48 PM, Clemens Ladisch wrote: >> Muni Sekhar wrote: >>> I need to find out when exactly driver's poll callback returned timeout. >> >> Your poll callback _cannot_ return a timeout. >> >> Why do you think

Re: character driver - poll() timeout

Muni Sekhar wrote: > On Tue, Oct 27, 2015 at 8:48 PM, Clemens Ladisch <clem...@ladisch.de> wrote: >> Muni Sekhar wrote: >>> I need to find out when exactly driver's poll callback returned timeout. >> >> Your poll callback _cannot_ return a timeout. >> >

Re: character driver - poll() timeout

Muni Sekhar wrote: > On Tue, Oct 27, 2015 at 1:41 PM, Clemens Ladisch wrote: >> Muni Sekhar wrote: >>> Is it possible to print the timeout value in character driver poll() API? >> >> No. Your driver's poll callback never waits. >> >> Why do you think y

Re: character driver - poll() timeout

Muni Sekhar wrote: > Is it possible to print the timeout value in character driver poll() API? No. Your driver's poll callback never waits. Why do you think you need this value? Regards, Clemens -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a

Re: character driver - poll() timeout

Muni Sekhar wrote: > Is it possible to print the timeout value in character driver poll() API? No. Your driver's poll callback never waits. Why do you think you need this value? Regards, Clemens -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a

Re: character driver - poll() timeout

Muni Sekhar wrote: > On Tue, Oct 27, 2015 at 1:41 PM, Clemens Ladisch <clem...@ladisch.de> wrote: >> Muni Sekhar wrote: >>> Is it possible to print the timeout value in character driver poll() API? >> >> No. Your driver's poll callback never waits. >&g

Re: [PATCH v3 1/4] usb: gadget: f_midi: free usb request when done

Felipe Tonello wrote: > On Mon, Oct 12, 2015 at 11:16 AM, Clemens Ladisch wrote: >> Felipe Tonello wrote: >>> I believe that is the best way to implement. Create multiple requests >>> until the ALSA substreams buffer are empty and free the request on >>> comp

Re: [PATCH v3 1/4] usb: gadget: f_midi: free usb request when done

Felipe Tonello wrote: > On Fri, Oct 9, 2015 at 10:23 AM, Clemens Ladisch wrote: >> Felipe Tonello wrote: >>> } else if (ep == midi->in_ep) { >>> - /* Our transmit completed. See if there's more to go. >>> -

Re: [PATCH v3 1/4] usb: gadget: f_midi: free usb request when done

Felipe Tonello wrote: > On Fri, Oct 9, 2015 at 10:23 AM, Clemens Ladisch <clem...@ladisch.de> wrote: >> Felipe Tonello wrote: >>> } else if (ep == midi->in_ep) { >>> - /* Our transmit

Re: [PATCH v3 1/4] usb: gadget: f_midi: free usb request when done

Felipe Tonello wrote: > On Mon, Oct 12, 2015 at 11:16 AM, Clemens Ladisch <clem...@ladisch.de> wrote: >> Felipe Tonello wrote: >>> I believe that is the best way to implement. Create multiple requests >>> until the ALSA substreams buffer are empty and free the r

Re: [PATCH v3 1/4] usb: gadget: f_midi: free usb request when done

Felipe Balbi wrote: > Clemens Ladisch writes: >> Felipe Tonello wrote: >>> req->actual == req->length means that there is no data left to enqueue, >> >> This condition is not checked in the patch. >> >>> so free the request. >>> &g

Re: [PATCH v3 1/4] usb: gadget: f_midi: free usb request when done

Felipe Balbi wrote: > Clemens Ladisch <clem...@ladisch.de> writes: >> Felipe Tonello wrote: >>> req->actual == req->length means that there is no data left to enqueue, >> >> This condition is not checked in the patch. >> >>> so free

Re: [PATCH v3 1/4] usb: gadget: f_midi: free usb request when done

Felipe Tonello wrote: > req->actual == req->length means that there is no data left to enqueue, This condition is not checked in the patch. > so free the request. > > Signed-off-by: Felipe F. Tonello > --- > drivers/usb/gadget/function/f_midi.c | 5 ++--- > 1 file changed, 2 insertions(+), 3

Re: [PATCH v3 1/4] usb: gadget: f_midi: free usb request when done

Felipe Tonello wrote: > req->actual == req->length means that there is no data left to enqueue, This condition is not checked in the patch. > so free the request. > > Signed-off-by: Felipe F. Tonello > --- > drivers/usb/gadget/function/f_midi.c | 5 ++--- > 1 file

Re: [PATCH v2 2/3] usb: gadget: f_midi: free usb request when done

Peter Chen wrote: > I can't make my aplaymidi to receive data > # aplaymidi > open /dev/snd/seq failed: No such file or directory modprobe snd-seq There are mechanisms to load it automatically, but your embedded system might not bother about any of them. Or CONFIG_SND_SEQUENCER isn't enabled

Re: [PATCH v2 2/3] usb: gadget: f_midi: free usb request when done

Peter Chen wrote: > I can't make my aplaymidi to receive data > # aplaymidi > open /dev/snd/seq failed: No such file or directory modprobe snd-seq There are mechanisms to load it automatically, but your embedded system might not bother about any of them. Or CONFIG_SND_SEQUENCER isn't enabled

Re: tools: usbip: detach: avoid calling strlen() at each iteration

Aaro Koskinen wrote: > On Tue, Sep 15, 2015 at 09:27:20PM +0100, Eric Curtin wrote: >> -for (unsigned int i = 0; i < strlen(port); i++) >> +unsigned int port_len = strlen(port); >> + >> +for (unsigned int i = 0; i < port_len; i++) > > port is read only in this function, so maybe just

Re: tools: usbip: detach: avoid calling strlen() at each iteration

Aaro Koskinen wrote: > On Tue, Sep 15, 2015 at 09:27:20PM +0100, Eric Curtin wrote: >> -for (unsigned int i = 0; i < strlen(port); i++) >> +unsigned int port_len = strlen(port); >> + >> +for (unsigned int i = 0; i < port_len; i++) > > port is read only in this function, so maybe just

Re: Possible Bug Found with Xonar Stx Driver

nick wrote: > After running the latest version of Linus's tree I am noticed way more > buffering What exactly do you mean with the word "buffering"? > when playing music with my Xonar STX card when building kernels then > under the Ubuntu kernel version of 3.19.16. Sounds like a change in the

Re: Possible Bug Found with Xonar Stx Driver

nick wrote: After running the latest version of Linus's tree I am noticed way more buffering What exactly do you mean with the word buffering? when playing music with my Xonar STX card when building kernels then under the Ubuntu kernel version of 3.19.16. Sounds like a change in the disk

Re: [PATCH v2] add stealth mode

valdis.kletni...@vt.edu wrote: > On Thu, 02 Jul 2015 10:56:01 +0200, Matteo Croce said: >> Add option to disable any reply not related to a listening socket > > 2) You *do* realize that this isn't anywhere near sufficient in order > to actually make your machine "invisible", right? (Hint: What

Re: [PATCH v2] add stealth mode

valdis.kletni...@vt.edu wrote: On Thu, 02 Jul 2015 10:56:01 +0200, Matteo Croce said: Add option to disable any reply not related to a listening socket 2) You *do* realize that this isn't anywhere near sufficient in order to actually make your machine invisible, right? (Hint: What *other*

Re: [Question] Usage of ENOTSUPP error code

Masahiro Yamada wrote: > I noticed many drivers return -ENOTSUPP on error. > > I assume ENOTSUPP is defined in include/linux/errno.h > as follows: > > /* Defined for the NFSv3 protocol */ > ... > #define ENOTSUPP 524 /* Operation is not supported */ > > If so, should ENOTSUPP be only used for

Re: [Question] Usage of ENOTSUPP error code

Masahiro Yamada wrote: I noticed many drivers return -ENOTSUPP on error. I assume ENOTSUPP is defined in include/linux/errno.h as follows: /* Defined for the NFSv3 protocol */ ... #define ENOTSUPP 524 /* Operation is not supported */ If so, should ENOTSUPP be only used for NFS-related

Re: RFC: kernel coding style: prefer array to [0] ?

Joe Perches wrote: > It seems most in-kernel uses are 'array' rather than '[0]' > > Most of the time, using array is simpler to read than [0]. > > Exceptions exists when addresses for consecutive members are > used like func([0], [1]); I use '[0]' when I want to get a pointer to a single object

Re: RFC: kernel coding style: prefer array to array[0] ?

Joe Perches wrote: It seems most in-kernel uses are 'array' rather than 'array[0]' Most of the time, using array is simpler to read than array[0]. Exceptions exists when addresses for consecutive members are used like func(array[0], array[1]); I use 'array[0]' when I want to get a pointer

Re: [BUG] ohci_enable() fails during resume

Lukasz Stelmach wrote: > A bit, suddenly by desktop PC started to fail to resume. [...] > The failing code is somewhere around line 2400 of > drivers/firewire/ohci.c (the latest mainline). >0x003f <+31>: callq 0xb037 >0x0044 <+36>: mov

Re: [BUG] ohci_enable() fails during resume

Lukasz Stelmach wrote: A bit, suddenly by desktop PC started to fail to resume. [...] The failing code is somewhere around line 2400 of drivers/firewire/ohci.c (the latest mainline). 0x003f +31: callq 0xb037 copy_config_rom 0x0044 +36: mov

Re: Question about cacheline aligned memory for DMA transfers

Johannes Thoma wrote: > Does kmalloc return only memory that is cache line aligned? Yes. > do all architectures handle cache line misalign ed dma accesses > correctly? x86 does. Most other architectures do not have DMA-coherent caches. Regards, Clemens -- To unsubscribe from this list: send

Re: Question about cacheline aligned memory for DMA transfers

Johannes Thoma wrote: Does kmalloc return only memory that is cache line aligned? Yes. do all architectures handle cache line misalign ed dma accesses correctly? x86 does. Most other architectures do not have DMA-coherent caches. Regards, Clemens -- To unsubscribe from this list: send the

Re: [PATCH 2/2] firewire: add a parameter to force the speed of the devices.

Laurent Vivier wrote: > I was trying to use my old iPod mini firewire (first generation) with > a new firewire card I put in my PC (VIA Technologies, Inc. VT6306/7/8), > but the iPod was not mounted and failed with the following error: > reading config rom failed: no ack > It appears that the

Re: [PATCH 2/2] firewire: add a parameter to force the speed of the devices.

Laurent Vivier wrote: I was trying to use my old iPod mini firewire (first generation) with a new firewire card I put in my PC (VIA Technologies, Inc. VT6306/7/8), but the iPod was not mounted and failed with the following error: reading config rom failed: no ack It appears that the

Re: timerfd waking up before timer really expires

Lucas De Marchi wrote: > I was debugging my application and noticed that a timerfd event was being > triggered *before* the timer expires. > > I reduced the scope of the program to test a single timerfd and measure the > difference in the result of clock_gettime() between two reads. > >

Re: timerfd waking up before timer really expires

Lucas De Marchi wrote: I was debugging my application and noticed that a timerfd event was being triggered *before* the timer expires. I reduced the scope of the program to test a single timerfd and measure the difference in the result of clock_gettime() between two reads. loop_time_fd

Re: file name changes between reboots : /sys/class/hwmon/hwmon[0->1]/temp1_input

Toralf Förster wrote: > I'm wondering where to blame a nagging issue with these file names : > > # ls -l /sys/class/hwmon/hwmon?/temp?_input > -r--r--r-- 1 root root 4096 Jan 30 13:57 /sys/class/hwmon/hwmon1/temp1_input > -r--r--r-- 1 root root 4096 Jan 30 13:57 /sys/class/hwmon/hwmon2/temp1_input

Re: file name changes between reboots : /sys/class/hwmon/hwmon[0-1]/temp1_input

Toralf Förster wrote: I'm wondering where to blame a nagging issue with these file names : # ls -l /sys/class/hwmon/hwmon?/temp?_input -r--r--r-- 1 root root 4096 Jan 30 13:57 /sys/class/hwmon/hwmon1/temp1_input -r--r--r-- 1 root root 4096 Jan 30 13:57 /sys/class/hwmon/hwmon2/temp1_input

[PATCH] staging/fwserial: use correct vendor/version IDs

The driver was using the vendor ID 0xd00d1e from the FireWire core. However, this ID was not registered, and invalid. Instead, use the vendor/version IDs that now are officially assigned to firewire-serial: https://ieee1394.wiki.kernel.org/index.php/IEEE_OUI_Assignments Signed-off-by: Clemens

[PATCH] staging/fwserial: use correct vendor/version IDs

The driver was using the vendor ID 0xd00d1e from the FireWire core. However, this ID was not registered, and invalid. Instead, use the vendor/version IDs that now are officially assigned to firewire-serial: https://ieee1394.wiki.kernel.org/index.php/IEEE_OUI_Assignments Signed-off-by: Clemens

Re: [PATCH] media; firewire: Remove no longer needed fix me comment in firedtv-ci.c for the function,fdtv_ca_ioctl

Nicholas Krause wrote: > Removes the no longer fix me comment for if we need to set the tuner status > with > the line, avc_tuner_status(fdtv, ). This line is needed in order to set > the > tuner status after we have through the switch statement checking what fdtv > function > we need to call

Re: [alsa-devel] [PATCH v2] ALSA: usb-audio: Add support for Akai MPC Element USB MIDI controller

Paul Bonser wrote: > On 01/08/2015 03:56 PM, Clemens Ladisch wrote: >> Paul Bonser wrote: >>> The Akai MPC Element incorrectly reports its bInterfaceClass as 255, but >>> otherwise implements the USB MIDI spec correctly. >>> >>> This adds a

Re: [PATCH] media; firewire: Remove no longer needed fix me comment in firedtv-ci.c for the function,fdtv_ca_ioctl

Nicholas Krause wrote: Removes the no longer fix me comment for if we need to set the tuner status with the line, avc_tuner_status(fdtv, stat). This line is needed in order to set the tuner status after we have through the switch statement checking what fdtv function we need to call to

Re: [alsa-devel] [PATCH v2] ALSA: usb-audio: Add support for Akai MPC Element USB MIDI controller

Paul Bonser wrote: On 01/08/2015 03:56 PM, Clemens Ladisch wrote: Paul Bonser wrote: The Akai MPC Element incorrectly reports its bInterfaceClass as 255, but otherwise implements the USB MIDI spec correctly. This adds a quirks-table.h entry which allows the device to be recognized

Re: [alsa-devel] [PATCH v2] ALSA: usb-audio: Add support for Akai MPC Element USB MIDI controller

Paul Bonser wrote: > The Akai MPC Element incorrectly reports its bInterfaceClass as 255, but > otherwise implements the USB MIDI spec correctly. > > This adds a quirks-table.h entry which allows the device to be > recognized as a standard USB MIDI device. > > Signed-off-by: Paul Bonser > --- >

Re: Questions about IOMMU & PCIe switch

Raimonds Cicans wrote: > https://github.com/ljalves/linux_media/issues/66 If the TBS driver works, why don't you use it? The WARNING from the kernel log indicates a hardware bug in the PCIe bridge. Do you have the same card, and do you also get this warning with kernel 3.16? I/O virtualization

Re: [alsa-devel] [PATCH v2] ALSA: usb-audio: Add support for Akai MPC Element USB MIDI controller

Paul Bonser wrote: The Akai MPC Element incorrectly reports its bInterfaceClass as 255, but otherwise implements the USB MIDI spec correctly. This adds a quirks-table.h entry which allows the device to be recognized as a standard USB MIDI device. Signed-off-by: Paul Bonser

Re: Questions about IOMMU PCIe switch

Raimonds Cicans wrote: https://github.com/ljalves/linux_media/issues/66 If the TBS driver works, why don't you use it? The WARNING from the kernel log indicates a hardware bug in the PCIe bridge. Do you have the same card, and do you also get this warning with kernel 3.16? I/O virtualization

Re: Questions about IOMMU & PCIe switch

Raimonds Cicans wrote: > We have two kinds of PCIe cards: > A1 - based on chip B > A2 - based on same chip B but behind PCIe switch > > Card A1 work flawlessly in any configuration, > but card A2 work flawlessly only if system > lack IOMMU or have disabled IOMMU In theory, such a switch should be

Re: Questions about IOMMU PCIe switch

Raimonds Cicans wrote: We have two kinds of PCIe cards: A1 - based on chip B A2 - based on same chip B but behind PCIe switch Card A1 work flawlessly in any configuration, but card A2 work flawlessly only if system lack IOMMU or have disabled IOMMU In theory, such a switch should be

Re: Using kernel filesystems as userland libraries

Nicolas George wrote: > With the libraries present in e2fsprogs, it is possible to open a plain file > (or any other reasonable storage) as an EXT2 filesystem and manipulate files > inside it. > > Is it possible to use the implementations in the kernel to do the same thing > with any supported

Re: Using kernel filesystems as userland libraries

Nicolas George wrote: With the libraries present in e2fsprogs, it is possible to open a plain file (or any other reasonable storage) as an EXT2 filesystem and manipulate files inside it. Is it possible to use the implementations in the kernel to do the same thing with any supported normal

Re: [PATCH RFC v1b] firewire: cdev: prevent kernel stack leaking into ioctl arguments

Stefan Richter wrote: > This fix simply always null-initializes the entire ioctl argument buffer > regardless of the actual length of expected user input. That is, a > runtime overhead of memset(..., 40) is added to each firewirew-cdev > ioctl() call. This part of the stack is most likely to be

Re: [PATCH RFC v1b] firewire: cdev: prevent kernel stack leaking into ioctl arguments

Stefan Richter wrote: This fix simply always null-initializes the entire ioctl argument buffer regardless of the actual length of expected user input. That is, a runtime overhead of memset(..., 40) is added to each firewirew-cdev ioctl() call. This part of the stack is most likely to be

Re: [PATCH] sparc64: Add preprocessor symbols for PAGE_* pgprot_t values.

ppen to work. >> >> To prevent potential breakage when another #ifdef check is added or when >> sparc64 implements another PAGE_ value, make such #ifdef checks work by >> adding preprocessor symbols on top of the PAGE_* variables. >> >> Signed-off-by: Clemens Ladisch >

Re: [PATCH] sparc64: Add preprocessor symbols for PAGE_* pgprot_t values.

when another #ifdef check is added or when sparc64 implements another PAGE_ value, make such #ifdef checks work by adding preprocessor symbols on top of the PAGE_* variables. Signed-off-by: Clemens Ladisch clem...@ladisch.de This change actually doesn't have any effect, and doesn't matter, so

[PATCH] sparc64: Add preprocessor symbols for PAGE_* pgprot_t values.

is added or when sparc64 implements another PAGE_ value, make such #ifdef checks work by adding preprocessor symbols on top of the PAGE_* variables. Signed-off-by: Clemens Ladisch --- arch/sparc/include/asm/pgtable_64.h |4 1 file changed, 4 insertions(+) diff --git a/arch/sparc/include

[PATCH] sparc64: Add preprocessor symbols for PAGE_* pgprot_t values.

is added or when sparc64 implements another PAGE_ value, make such #ifdef checks work by adding preprocessor symbols on top of the PAGE_* variables. Signed-off-by: Clemens Ladisch clem...@ladisch.de --- arch/sparc/include/asm/pgtable_64.h |4 1 file changed, 4 insertions(+) diff --git

Re: [PATCH 00/11] Add AXD Audio Processing IP driver

Qais Yousef wrote: > AXD Audio Processing IP performs audio decoding, encoding, mixing, > equalisation, > synchronisation and playback. What exactly do you mean with "synchronisation" and "playback"? > It doesn't fit in alsa subsystem but I Cced them to confirm. ... because those two words

Re: [PATCH 00/11] Add AXD Audio Processing IP driver

Qais Yousef wrote: AXD Audio Processing IP performs audio decoding, encoding, mixing, equalisation, synchronisation and playback. What exactly do you mean with synchronisation and playback? It doesn't fit in alsa subsystem but I Cced them to confirm. ... because those two words sound like

Re: [PATCH 1/1] snd-usb-audio: Add support for Steinberg UR22 USB interface

4 & tested with > mpg123 > Patch applied to 3.13 Ubuntu kernel works well enough for daily use. > > Signed-off-by: Vlad Catoi Acked-by: Clemens Ladisch > --- > sound/usb/quirks-table.h | 30 ++ > 1 file changed, 30 insertions(+) > >

Re: [PATCH 1/1] snd-usb-audio: Add support for Steinberg UR22 USB interface

Ubuntu kernel works well enough for daily use. Signed-off-by: Vlad Catoi vladca...@gmail.com Acked-by: Clemens Ladisch clem...@ladisch.de --- sound/usb/quirks-table.h | 30 ++ 1 file changed, 30 insertions(+) diff --git a/sound/usb/quirks-table.h b/sound/usb

Re: reboot housekeeping, lack thereof, is messing with me

Gene Heskett wrote: > To whomever is in charge of the supposedly volatile LCK.. files in > /var/lock: Whoever that may be, it's not the kernel. > Its my understanding that these files should be volatile when they > represent a USB usage, because a USB device can be unplugged instantly and > at

Re: reboot housekeeping, lack thereof, is messing with me

Gene Heskett wrote: To whomever is in charge of the supposedly volatile LCK.. files in /var/lock: Whoever that may be, it's not the kernel. Its my understanding that these files should be volatile when they represent a USB usage, because a USB device can be unplugged instantly and at any

Re: [alsa-devel] Workable vintage driver support mechanism? (Re: [PATCH v3] ES938 support for ES18xx driver)

Andreas Mohr wrote: > I think I have an idea which might be useful to accept: > for every piece of sufficiently "vintage" submission, > people would be tasked with offering (or somehow ensuring) > a sufficiently closely time-related cleanup in other places. The problem that such a new driver

Re: [alsa-devel] Workable vintage driver support mechanism? (Re: [PATCH v3] ES938 support for ES18xx driver)

Andreas Mohr wrote: I think I have an idea which might be useful to accept: for every piece of sufficiently vintage submission, people would be tasked with offering (or somehow ensuring) a sufficiently closely time-related cleanup in other places. The problem that such a new driver imposes is

Re: What are the official opinions of the developers about develop currently code in binary, hexadecimal and assembly code?

françai s wrote: > The official opinions of the developers "The developers" is not a uniform group that could hold a coherent opinion, let alone an "official" one. > is currently necessary develop code in binary, hexadecimal and > assembly code? It is usually not the preferred form for making

Re: What are the official opinions of the developers about develop currently code in binary, hexadecimal and assembly code?

françai s wrote: The official opinions of the developers The developers is not a uniform group that could hold a coherent opinion, let alone an official one. is currently necessary develop code in binary, hexadecimal and assembly code? It is usually not the preferred form for making

Re: [PATCH] x86_64: Add memcpy32_toio to write to PCI MMIO

Subhransu S. Prusty wrote: > This is needed because the hardware Which hardware? Every x86-64 CPU ever built by AMD, Intel, and VIA? > does not support 64-bit moveq insructions while writing to PCI MMIO. > +#ifndef CONFIG_X86_64 > +#define MEMCPY_TOIO memcpy_toio > +#else > +#define

Re: [PATCH] x86_64: Add memcpy32_toio to write to PCI MMIO

Subhransu S. Prusty wrote: This is needed because the hardware Which hardware? Every x86-64 CPU ever built by AMD, Intel, and VIA? does not support 64-bit moveq insructions while writing to PCI MMIO. +#ifndef CONFIG_X86_64 +#define MEMCPY_TOIO memcpy_toio +#else +#define MEMCPY_TOIO

Re: Compat sysinfo syscall (kernel/sys.c) relying on undefined behavior?

Scotty Bauer wrote: > In the compat version of sysinfo, kernel/sys.c we see the following: > > /* Check to see if any memory value is too large for 32-bit and scale > * down if needed > */ > if ((s.totalram >> 32) || (s.totalswap >> 32)) { This code is supposed to check if any

Re: Compat sysinfo syscall (kernel/sys.c) relying on undefined behavior?

Scotty Bauer wrote: In the compat version of sysinfo, kernel/sys.c we see the following: /* Check to see if any memory value is too large for 32-bit and scale * down if needed */ if ((s.totalram 32) || (s.totalswap 32)) { This code is supposed to check if any of the

Re: [PATCH 1/2] SOUND: kill gameport bits

Takashi Iwai wrote: > did anyone test the patch at all...? Appears to work. The ymfpci gameport seems to be somewhat unreliable: analog.c: 100 out of 17347 reads (0%) on pci:06:06.1/gameport0 failed analog.c: 122 out of reads (10%) on pci:06:07.0/gameport0 failed There is still

Re: [PATCH 1/2] SOUND: kill gameport bits

Takashi Iwai wrote: did anyone test the patch at all...? Appears to work. The ymfpci gameport seems to be somewhat unreliable: analog.c: 100 out of 17347 reads (0%) on pci:06:06.1/gameport0 failed analog.c: 122 out of reads (10%) on pci:06:07.0/gameport0 failed There is still

Re: [alsa-devel] /proc/asound/card0/oss_mixer stack corruption

low in snd_info_get_line() snd_info_get_line() documents that its last parameter must be one less than the buffer size, but this API design guarantees that (literally) every caller gets it wrong. Just change this parameter to have its obvious meaning. Reported-by: Tommi Rantala Cc: # v2.2.26+ Signed

Re: [alsa-devel] /proc/asound/card0/oss_mixer stack corruption

: sta...@vger.kernel.org # v2.2.26+ Signed-off-by: Clemens Ladisch clem...@ladisch.de --- sound/core/info.c |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) --- a/sound/core/info.c +++ b/sound/core/info.c @@ -684,7 +684,7 @@ int snd_info_card_free(struct snd_card *card

Re: [PATCH 1/2] SOUND: kill gameport bits

Dmitry Torokhov wrote: > Gameport support hasn't been working well ever since cpufreq became > mainstream Back in the gameport-mainstream days, we did not have a usable high- resolution timer API. But why can't we use something like getrawmonotonic() now? (Yes, I'm volunteering ...) > and it

Re: [PATCH 1/2] SOUND: kill gameport bits

Dmitry Torokhov wrote: Gameport support hasn't been working well ever since cpufreq became mainstream Back in the gameport-mainstream days, we did not have a usable high- resolution timer API. But why can't we use something like getrawmonotonic() now? (Yes, I'm volunteering ...) and it

Re: [PATCH] usb: use kcalloc instead of kzalloc

Arjun Sreedharan wrote: > kcalloc has protection from integer overflows > which could arise from the multiplication of > number of elements and size. You are implying that such an overflow could arise in this code. This is false. > @@ -380,8 +380,7 @@ static int usb_parse_interface(struct device

Re: [PATCH] usb: use kcalloc instead of kzalloc

Arjun Sreedharan wrote: kcalloc has protection from integer overflows which could arise from the multiplication of number of elements and size. You are implying that such an overflow could arise in this code. This is false. @@ -380,8 +380,7 @@ static int usb_parse_interface(struct device

Re: [PATCH V3] hwmon, k10temp: Add support for F15h M60h

| 2 +- > drivers/hwmon/Kconfig | 4 ++-- > drivers/hwmon/k10temp.c | 35 --- > 3 files changed, 35 insertions(+), 6 deletions(-) Acked-by: Clemens Ladisch -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

Re: [PATCH V3] hwmon, k10temp: Add support for F15h M60h

++-- drivers/hwmon/k10temp.c | 35 --- 3 files changed, 35 insertions(+), 6 deletions(-) Acked-by: Clemens Ladisch clem...@ladisch.de -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More

Re: [PATCH V2] hwmon, k10temp: Add support for F15h M60h

Guenter Roeck wrote:> On Thu, Aug 14, 2014 at 11:54:22AM -0500, Aravind Gopalakrishnan wrote: >> This patch adds temperature monitoring support for F15h M60h processor. >> - Add new pci device id for the relevant processor >> - The functionality of REG_REPORTED_TEMPERATURE is moved to >>

Re: [PATCH V2] hwmon, k10temp: Add support for F15h M60h

t;- So, use this to get CUR_TEMP value >- Since we need an indirect register access, protect this with > a mutex lock > - Add Kconfig, Doc entries to indicate support for this processor. > > Signed-off-by: Aravind Gopalakrishnan Acked-by: Clemens Ladisch > --- &

<    1   2   3   4   >