[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] 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

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: 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

[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: 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: [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: 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: 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: [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: 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: [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: 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: [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: [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: 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: 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: [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] 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] 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: [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 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: > 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: 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: 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: [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 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: 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: 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: [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] 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: [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 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: [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: [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: 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 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] 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

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 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 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 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 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 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] 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: [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

>> 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 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: > 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: [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 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] 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: [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: 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: [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

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

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: >> 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 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: [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] 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 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] 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 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 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: [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 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: > 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] 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: 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: [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: [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: [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: > 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: [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: [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 42/59] sysctl: Remove sys_sysctl support from the hpet timer driver.

Biederman <[EMAIL PROTECTED]> Acked-by: Clemens Ladisch <[EMAIL PROTECTED]> > --- > drivers/char/hpet.c |4 ++-- > 1 files changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/char/hpet.c b/drivers/char/hpet.c > index 20dc3be..81be1db 100644 > --- a

Re: [RFC PATCH 0/6] Convert all tasklets to workqueues

Ingo Molnar wrote: so how about the following, different approach: anyone who has a tasklet in any performance-sensitive codepath, please yell now. ALSA uses quite a few tasklets in the framework and in several drivers. Since we care very much about low latency, many places use

Re: MOTU Fastlane USB MIDI interface

David Griffith wrote: Does anyone here have or can borrow a MOTU Fastlane USB MIDI interface? I'm having a nasty time trying to nail down what's going wrong. It seems that for kernels 2.6.17 and earlier, MIDI works fine through this interface. After that, it doesn't. What do you mean with

Re: MOTU Fastlane USB MIDI interface

David Griffith wrote: Checking further, I've never been able to get midi to work with kernels 2.6.18 and later. Please try "amidi -d -p virtual" and playing a .mid file to this port with aplaymidi. Regards, Clemens - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

Re: MOTU Fastlane USB MIDI interface

David Griffith wrote: > On Thu, 16 Aug 2007, Clemens Ladisch wrote: > > Please try "amidi -d -p virtual" and playing a .mid file to this port with > > aplaymidi. > > $ aplaymidi -p "virtual" castle2.mid > Invalid port virtual - No such file or di

Re: MOTU Fastlane USB MIDI interface

David Griffith wrote: > On Fri, 17 Aug 2007, Clemens Ladisch wrote: > > David Griffith wrote: > > > On Thu, 16 Aug 2007, Clemens Ladisch wrote: > > > > Please try "amidi -d -p virtual" and playing a .mid file to this port > > > > with &g

Re: MOTU Fastlane USB MIDI interface

David Griffith wrote: On Mon, 20 Aug 2007, Clemens Ladisch wrote: David Griffith wrote: > $ aplaymidi -p 20:0 casablan.mid > > Nothing is written to the Fastlane. No lights. Nothing. Please run "amidi -d -p virtual" and then play to the virtual port created by amidi, to s

Re: "double" hpet clocksource && hard freeze [bisected]

Luck, Tony wrote: [...] Given that the hang went away when you applied the earlier patch, I conclude that the drivers/char/hpet.c code is the one that got selected when you had two "hpet" entries ... and that there is something wrong with that code that doesn't work right on x86_64.

Re: drivers/usb/misc/emi*.c have the biggest data objects in the whole tree

Denys Vlasenko wrote: Hi Tapio, You are the author of these files. Are you still maintaining them? His newer email address that I found with Google is dead, too. These two object files hold the biggest data objects in the whole Linux kernel Basically, these are big arrays of the

Re: alsa problem

Donn Washburn wrote: > I am not on the list Indeed you are not on the alsa-devel list. > It works some times What works? And why would that be a problem? Regards, Clemens -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to

[PATCH] vt: make the default color configurable

parameter for that, and document the entire bunch. Any hacker who thinks that a command prompt on a "black screen with white font" is not supicious enough can now use the kernel parameter vt.color=10 to get a nice, evil green. Signed-off-by: Clemens Ladisch --- Documentation/kernel-para

Re: [alsa-devel] [RFC] revoke(2) and generic handling of things like remove_proc_entry()

Al Viro wrote: > BTW, snd_card_disconnect() doesn't do anything to existing mappings; smells > like a bug, and there we do have ones with non-trivial ->mmap(). Could > ALSA folks comment? I don't know of any hotplug sound driver that maps memory from a device. All hotplug buses (PCIe, USB,

Re: Is __ffs64 supposed to be zero based?

Ben Greear wrote: > Similarly named methods elsewhere seem to indicate it is supposed to be > ones-based counting (ie, bit (1<<0) would be considred 'bit 1'. ffs() is defined to use one-based counting: __ffs() uses zero-based

<    1   2   3   4   >