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
> ---
>
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
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
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
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
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(+)
>
>
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
>
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
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
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
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
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
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
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
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
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
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.
>
>
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
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->
d-by: Jonathan Corbet
> Signed-off-by: Shuah Khan
Acked-by: Clemens Ladisch
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.)
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
> ---
>
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
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
>>
> 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
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
Julia Lawall wrote:
> Constify snd_pcm_ops structures.
For 3/5/6:
Acked-by: Clemens Ladisch
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
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
: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
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
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
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.
>&
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
>>
&
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) {
> +
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
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
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.
>>> -
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
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
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
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
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
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
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,
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).
>
>
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;
>>> +
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.
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).
>
>
/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
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
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
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, );
>>
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
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
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
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
>> +++
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
>
>> 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
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
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
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
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
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
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
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
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
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
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;
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
>
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
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
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
+-
> 3 files changed, 5 insertions(+), 3 deletions(-)
Acked-by: Clemens Ladisch
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Li, Zhen-Hua wrote:
> udelay with more than 2 may cause __bad_udelay.
> Use mdelay for instead.
>
> #ifdef AVOID_POPS
> /* Avoid pops */
> -udelay(10);
> + mudelay(100);
This will not compile. Please test with AVOID_POPS enabled.
Regards,
Emmanuel Colbus wrote:
> I have a question regarding vector 0x80.
>
> As I mentionned earlier, my OS's internals are very different from
> Linux's, thus I have had a need for a few new syscalls. Since I wanted
> to avoid any collision with Linux
... you could just use another vector, such as
301 - 376 of 376 matches
Mail list logo
