t;_UAPI" instead of "UAPI" on the guard macro, and also give a
> comment for "#endif".
>
> Signed-off-by: Chen Gang
Acked-by: Clemens Ladisch
> ---
> include/uapi/sound/firewire.h |6 +++---
> 1 files changed, 3 insertions(+), 3 deletions(-)
>
&g
Stephan Mueller wrote:
> Am Donnerstag, 7. November 2013, 02:03:57 schrieb Nicholas Mc Guire:
>> On Wed, 06 Nov 2013, Stephan Mueller wrote:
>>> Besides, how on earth shall an attacker even gain knowledge about the
>>> state of the CPU or disable CPU mechanisms? Oh, I forgot, your NSA
>>> guy. But
Stephan Mueller wrote:
> Am Mittwoch, 6. November 2013, 08:04:32 schrieb Theodore Ts'o:
>> On Wed, Nov 06, 2013 at 01:51:17PM +0100, Stephan Mueller wrote:
That's unfortunate, since it leaves open the question of whether this
jitter is something that could be at least somewhat
Stephan Mueller wrote:
> Am Samstag, 9. November 2013, 23:04:49 schrieb Clemens Ladisch:
>> Stephan Mueller wrote:
>>> Am Mittwoch, 6. November 2013, 08:04:32 schrieb Theodore Ts'o:
>>>> On Wed, Nov 06, 2013 at 01:51:17PM +0100, Stephan Mueller wrote:
>>>
Stephan Mueller wrote:
> Am Sonntag, 10. November 2013, 17:31:07 schrieb Clemens Ladisch:
>> In the case of CPUs, the jitter you observe in delta
>> times results in part from the complexities of the inner state, and in
>> part from real random noise. The first part is de
Stephan Mueller wrote:
> Am Sonntag, 10. November 2013, 21:28:06 schrieb Clemens Ladisch:
>> Many CPUs allow to disable branch prediction, but this is very vendor
>> specific (try to find MSR documentation). The biggest offender probably
>> is the out-of-order execution
Stephan Mueller wrote:
> Am Mittwoch, 13. November 2013, 12:51:44 schrieb Clemens Ladisch:
>> (And any setting that increases accesses to main memory is likey to
>> introduce more entropy due to clock drift between the processor and the
>> memory bus. Or where do you assume t
Stephan Mueller wrote:
> Am Donnerstag, 14. November 2013, 11:51:03 schrieb Clemens Ladisch:
>> An attacker would not try to detect patterns; he would apply knowledge
>> of the internals.
>
> I do not buy that argument, because if an attacker can detect or deduce
> the
Prarit Bhargava wrote:
> The CONFIG_HPET_MMAP Kconfig option exposes the memory map of the HPET
> registers to userspace. The Kconfig help points out that in some cases this
> can be a security risk as some systems may erroneously configure the map such
> that additional data is exposed to
parameter, hpet_mmap_enable, that is required in order
> to actually have the HPET MMAP exposed.
>
> [v2]: Clemens suggested modifying the Kconfig help text and making the
> default setting configurable.
>
> Signed-off-by: Prarit Bhargava
> Cc: Clemens Ladisch
> +++ b/Documenta
Prarit Bhargava wrote:
> On 03/19/2013 03:43 AM, Clemens Ladisch wrote:
>> Prarit Bhargava wrote:
>>> + int "Enable HPET MMAP access by default"
>>> + default 0
>>
>> This breaks backwards compatibility.
>
> Does backwards compatibility
Takashi Iwai wrote:
> Imre Deak wrote:
>> Use msecs_to_jiffies_min instead of open-coding the same.
>>
>> +++ b/sound/pci/oxygen/oxygen_io.c
>> @@ -108,7 +108,7 @@ static int oxygen_ac97_wait(struct oxygen *chip,
>> unsigned int mask)
>> wait_event_timeout(chip->ac97_waitqueue,
>>
Arnd Bergmann wrote:
> On Wednesday 17 April 2013, Linus Torvalds wrote:
>> Anyway, I'm attaching the untested patch to several drivers. Guys,
>> mind taking a look?
>
> I took a look at the hpet_mmap function, which still contains this check:
>
> if (((vma->vm_end - vma->vm_start) !=
Eduardo Cruz wrote:
> Please, anyone knows how to solve this problem?
>
> 2013/3/20 Eduardo Cruz :
>> I'm trying to remap some kernel static memory to user space using
>> remap_pfn_range.
Well, don't do that.
What is the actual problem you're trying to solve?
Regards,
Clemens
--
To unsubscribe
Rafael Aquini wrote:
> This patch introduces changes to the random_write method so it can split the
> given seed and completely stir the output pools with different halves of it,
> when seed lenght allows us doing so.
>
> - ret = write_pool(_pool, buffer, count);
> + ret =
Stephan Mueller wrote:
> Am Freitag, 10. Januar 2014, 09:13:57 schrieb Clemens Ladisch:
>> Rafael Aquini wrote:
>>> This patch introduces changes to the random_write method so it can
>>> split the given seed and completely stir the output pools with
>>> diff
Stephan Mueller wrote:
> Am Freitag, 10. Januar 2014, 12:37:26 schrieb Clemens Ladisch:
>> Stephan Mueller wrote:
>>> Am Freitag, 10. Januar 2014, 09:13:57 schrieb Clemens Ladisch:
>>>> Rafael Aquini wrote:
>>>>> This patch introduces changes to
noman pouigt wrote:
> x = 1;
> temp = atomic_read_increment(x);
atomic_set(, 1);
temp = atomic_inc_return();
> I looked through the documentation for atomic
> operations but couldn't find out the api
Not everything is fully documented.
Look through include/asm-generic/atomic.h.
Regards,
Stephan Mueller wrote:
> This is a clean-room implementation of the DRBG defined in SP800-90A.
Why? I guess it's for certification?
> +static bool drbg_fips_continuous_test(struct drbg_state *drbg,
> + unsigned char *buf)
> ...
> + ret = memcmp(drbg->prev,
H. Peter Anvin wrote:
> On 10/09/2013 09:03 AM, Theodore Ts'o wrote:
>> You can specify as a command-line argument (-H) to rngd the entropy
>> per bit of input data.
>
> There is no -H option in upstream rngd. It might be in the Debian fork,
> but the Debian fork has serious other problems.
What
Stanimir Varbanov wrote:
> I ran the rngtest with following command line:
>
> # cat /dev/hw_random | rngtest -c 10
> ...
> rngtest: bits received from input: 200032
> rngtest: FIPS 140-2 successes: 99925
> rngtest: FIPS 140-2 failures: 75
> ...
>
> Could you guys comment those results?
Vicentiu Ciorbaru wrote:
> Removed redundant cast of kmalloc return pointer.
> - (icode->gpr_map = (u_int32_t __user *)
> - kcalloc(512 + 256 + 256 + 2 * 1024, sizeof(u_int32_t),
> - GFP_KERNEL)) == NULL ||
> + (icode->gpr_map = kcalloc(512 + 256 + 256 +
Vicentiu Ciorbaru wrote:
> On Sun, Mar 10, 2013 at 6:32 PM, Clemens Ladisch wrote:
>> Vicentiu Ciorbaru wrote:
>>> Removed redundant cast of kmalloc return pointer.
>>
>>> - (icode->gpr_map = (u_int32_t __user *)
>>> - kcalloc
man eyes.
Cc: Randy Dunlap
Signed-off-by: Tomas Winkler
Signed-off-by: Clemens Ladisch
---
drivers/char/hpet.c |2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/char/hpet.c b/drivers/char/hpet.c
index ab8651d..d6568a6 100644
--- a/drivers/char/hpet.c
+++ b/drivers/char/hpe
usage
[v5]: Fixed up Documentation, Kconfig entry, and log message [CL]
Signed-off-by: Prarit Bhargava
Acked-by: Matt Wilson
Signed-off-by: Clemens Ladisch
---
Documentation/kernel-parameters.txt |3 +++
drivers/char/Kconfig| 10 --
drivers/c
Wei Yongjun wrote:
> Fix to return -ENOMEM in the kmalloc() error handling
> case instead of 0, as done elsewhere in this function.
>
> Signed-off-by: Wei Yongjun
Acked-by: Clemens Ladisch
> scs->buffer = kmalloc(HSS1394_MAX_PACKET_SIZE, GFP_KERNEL);
> -
Sergei Shtylyov wrote:
> On 30-05-2013 18:26, Timur Tabi wrote:
>>> +const unsigned long timing[] = { 5, 100, 500};
>
>> You'll save space and time if you also make this array "static",
>> otherwise the compiler will build the array every time this function is
>> called.
>
> No, *const*
Stefan Richter wrote:
> FireWire upper layer drivers are converted from generic
> struct driver.probe() and .remove()
> to bus-specific
> struct fw_driver.probe() and .remove().
Acked-by: Clemens Ladisch
for these:
> sound/firewire/isight.c | 44 ++
good1.2...@gmail.com wrote:
> Summary: add support for syba 7.1 surround sound card
> Keywords: syba via VT1723 Tremor
> Kernel: 3.8.8-203.fc18.x86_64
What are these three lines for?
> add support for syba 7.1 surround sound card
> actually the card only has 6 dmas, so it is really only 5.1
The
David Helstroom wrote:
> Interface 1 does not exist
Then it doesn't need a quirk, does it?
> and Interface 0 should be ignored.
Why?
If the driver doesn't like something in interface 0, that bug should be
fixed.
What is the output of "lsusb -v" for this device?
Regards,
Clemens
--
To
ce where it might have ended up.
Reported-by: Dave Helstroom
Signed-off-by: Clemens Ladisch
---
sound/usb/card.c | 15 +++
1 file changed, 15 insertions(+)
diff --git a/sound/usb/card.c b/sound/usb/card.c
index df2f6d0..34dc3e8 100644
--- a/sound/usb/card.c
+++ b/sound/usb/card.c
Jeffrey Walton wrote:
> http://www.tux.org/lkml/ is a tough read, and Item 4, "I think I found
> a bug, how do I report it?" does not tell me how to report this.
>From that page:
| A bug is when something (in the kernel, presumably) doesn't behave the
| way it should
So just tell us what it is
Network Nut wrote:
> I think that the facility by which a thread can block while waiting for any
> of several synchronization primitives (*mutex*, *semaphore*, *event*,
> *waitable
> timer*)...is not only "nice to have", but fundamental to complex (clean)
> multi-threaded programming.
You mean a
Network Nut wrote:
> As you know, under Windows, synchronization objects such as {event | mutex |
> semaphore | timer}; all have names that are computer-global. Process B can
> open, and use, any {event | mutex | semaphore | timer} that was created by
> process A, as long as Process B knows the
Network Nut wrote:
> 5. I can simulate system-global named mutex using shared-memory for
> underlying state of mutex (POCO NamedMutex)
> 6. I can get named semaphore using POSIX sem_create
>
> It seems that the remaining problem is to get named mutex and named
> semaphore to be accessible by
Network Nut wrote:
>I was looking at POSIX because it allows naming of the primitives.
Linux uses two orthogonal mechanisms for synchronization
primitives and for naming/sharing.
>I need to epoll_wait on inter-process {mutex, event, semaphore}.
Use eventfd.
>I need to reference inter-process
Network Nut wrote:
>> Assuming that you're porting to mainline distributions (and not embedded
>> devices), named SHM segments are accessible (providing the accessing
>> process has correct permissions) under /dev/shm. You just need to make
>> sure that you create the segment with the right
Andy Lutomirski wrote:
> The HPET is so amazingly slow that this is barely a win.
What happens on CPUs where the TSC cannot be used for the clock?
> it scares me a tiny bit to map a piece of crappy hardware where every
> userspace program can poke at it (even if said poking is read-only).
>
Nathaniel Yazdani wrote:
> Using the normal I/O interface to manipulate eventpolls is much neater
> than using epoll-specific syscalls
But it introduces a _second_ API, which is epoll-specific too, and does
not use the standard semantics either.
> while also allowing for greater flexibility
Peter Hurley wrote:
> Quadlet reads to memory above 4GB is painfully slow when serviced
> by the AR DMA context. In addition, the CPU(s) may be locked-up,
> preventing any transfer at all.
Using physical DMA prevents the use of that address space for software
address handlers, so you have adjust
Peter Hurley wrote:
> On Tue, 2013-03-26 at 17:12 +0100, Clemens Ladisch wrote:
>> Peter Hurley wrote:
>>> Write the PhyUpperBound register with the end-of-memory value. If
>>> end-of-memory is beyond the OHCI limit of 0x,
>>> clamp to that
Peter Hurley wrote:
> On Fri, 2013-03-29 at 11:44 +0100, Stefan Richter wrote:
>>> On Mar 26 Peter Hurley wrote:
The FW643e-2 is natively PCIe (not behind a bridge) and supports phys
DMA past 4GB (the datasheet says all 48 bits but I can only test it out
to 10GB).
I
> On 29.6.2013 22:42, Bjarni Ingi Gislason wrote:
>> The file "drivers/rtc/rtc_cmos.c" needs CONFIG_HPET to get linked.
>>
>> rtc-cmos.c:(.text+0x16f214): undefined reference to `hpet_rtc_interrupt'
CONFIG_HPET enables drivers/char/hpet.c and nothing else; it does not
affect the HPET RTC
Rickard Strandqvist wrote:
> From what I know, AND is faster then modulo.
Which is why the compiler does this optimization automatically,
if it can prove that it is correct.
> - if (i != 0 && (i%64) == 0)
> + if (i != 0 && (i&63) == 0)
Did you prove that i cannot be
Jaime T wrote:
> I'd like to use my 1TB Seagate hard disk on my linux box, and I've
> tested it using 3 different usb-sata enclosures.
>
> kernel: [10612.017588] usb 1-1: New USB device found, idVendor=14cd,
> idProduct=6116
> kernel: [10612.017602] usb 1-1: Product: USB Mass Storage Device
>
Feng Tang wrote:
> On many new phone/tablet platforms like Baytrail/Merrifield etc,
> the HPET are either defeatured or has some problem to be used
> as a reliable timer. As these platforms also have X86_64, we
> should not make HPET_TIMER default y for all X86_64.
The help text still says:
| You
Feng Tang wrote:
> On Fri, Mar 28, 2014 at 08:17:16AM +0100, Ingo Molnar wrote:
>> * Feng Tang wrote:
>> - or the kernel should have a quirk to reliably disable it. Why
>>should we crash or misbehave if a driver is built into the
>>kernel?
>
> I thought about this before, HPET doesn't
poma wrote:
> Sound whispers,
???
> WARNING: CPU: 3 PID: 900 at lib/dma-debug.c:593
> debug_dma_assert_idle+0x159/0x1d0()
> snd_hda_intel :00:07.0: DMA-API: cpu touching an active dma mapped
> cacheline [cln=0x03014000]
> ...
> Mapped at:
> [] debug_dma_alloc_coherent+0x22/0x70
Borislav Petkov wrote:
> On Mon, Jul 14, 2014 at 03:23:08PM -0500, Aravind Gopalakrishnan wrote:
>> +if (boot_cpu_data.x86 == 0x15 && boot_cpu_data.x86_model == 0x60) {
>> +pci_bus_write_config_dword(pdev->bus, PCI_DEVFN(0, 0),
>> +
Guenter Roeck wrote:
> On Mon, Jul 14, 2014 at 10:21:51PM +0200, Clemens Ladisch wrote:
>> Borislav Petkov wrote:
>>> On Mon, Jul 14, 2014 at 03:23:08PM -0500, Aravind Gopalakrishnan wrote:
>>>> + if (boot_cpu_data.x86 == 0x15 &
Thomas Gleixner wrote:
> I wonder why firewire exposed CLOCK_MONOTONIC_RAW to user space.
>
> What's the purpose of that? CLOCK_MONOTONIC_RAW is the raw time based
> on the initial frequency setup of the clocksource. That can be quite
> off from the NTP corrected frequency which is exposed by
>
Peter Zijlstra wrote:
> On Wed, Jul 16, 2014 at 01:34:21PM +0200, Clemens Ladisch wrote:
>> Thomas Gleixner wrote:
>>> I wonder why firewire exposed CLOCK_MONOTONIC_RAW to user space.
>>>
>>> What's the purpose of that? CLOCK_MONOTONIC_RAW is the raw time base
Aravind Gopalakrishnan wrote:
> On 7/15/2014 4:03 AM, Guenter Roeck wrote:
>> On 07/15/2014 12:41 AM, Clemens Ladisch wrote:
>>> Guenter Roeck wrote:
>>>> On Mon, Jul 14, 2014 at 10:21:51PM +0200, Clemens Ladisch wrote:
>>>>> Borislav Petkov wrote:
&g
Hans Wennborg wrote:
> Signed-off-by: Hans Wennborg
> ---
> sound/firewire/fireworks/fireworks_proc.c | 4 ++--
> sound/pci/riptide/riptide.c | 4 ++--
The fireworks patch got split.
Regards,
Clemens
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
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
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
> ---
&
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
>>
| 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
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
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
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
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
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
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
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
> ---
>
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
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
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
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
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 +-
&
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
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
(CC'd sqlite-users ML)
Theodore Ts'o wrote:
> On Tue, Oct 09, 2012 at 02:53:26PM -0500, Jooyoung Hwang wrote:
>> I'd like you to refer to the following link as well which is about
>> mobile workload pattern.
>> http://www.cs.cmu.edu/~fuyaoz/courses/15712/report.pdf
>> It's reported that in Android
Stefan Richter wrote:
> On Sep 10 Shuah Khan wrote:
http://linuxdriverproject.org/mediawiki/index.php/DMA_Mapping_Error_Analysis
>>>
File Name # of calls Status
drivers/firewire/core-iso.c 1Unmap Broken
drivers/firewire/ohci.c 1
Andrew Paprocki wrote:
> I started debugging a problem I was having with my sky2 network driver
> under 2.6.23.13. The investigation led me to find that the HPET timer
> wasn't working at all, causing the sky2 driver to not work properly.
> Simple example:
>
>
Eyal Lebedinsky wrote:
> A recent update to 2.6.23.14-64.fc7 lost sound. The boot log now has
> hda-intel: Error creating card!
> HDA Intel: probe of :00:1b.0 failed with error -12
The two lines before:
| usbcore: registered new interface driver snd-usb-audio
| cannot find the
Eyal Lebedinsky wrote:
> My /etc/modprobe.conf now contains:
> alias snd-card-0 snd-hda-intel
> options snd-card-0 index=0
> options snd-hda-intel index=0
> and and I should add
> options snd-usb-audio index=1
> right?
Yes.
> Any idea why has this changed between the two
; which was set in hpet_set_alarm_time().
>
> This patch is against 2.6.24-rc5-mm1.
>
>
> Signed-off-by: Bernhard Walle <[EMAIL PROTECTED]>
Acked-by: Clemens Ladisch <[EMAIL PROTECTED]>
> ---
> arch/x86/kernel/hpet.c |2 +-
> 1 file changed, 1 insertion(
Greg KH wrote:
> Over two years ago, the Linux USB developers stated that they believed
> there was no way to create a USB kernel driver that was not under the
> GPL. This patch moves the USB apis to enforce that decision.
>
> There are no known closed source USB drivers in the wild, so this
Greg KH wrote:
> On Mon, Jan 28, 2008 at 09:13:16AM +0100, Clemens Ladisch wrote:
>> Greg KH wrote:
>> > Over two years ago, the Linux USB developers stated that they believed
>> > there was no way to create a USB kernel driver that was not under the
>> >
Stefan Richter wrote:
> On Aug 12 Clemens Ladisch wrote:
>> Send the GUIDs of newly registered controllers and devices
>> to the /dev/random driver to help seed its pools.
>
> This looks good to me, almost. Isn't the call in fw_card_add redundant?
> The local node's fw_dev
Wei Yongjun wrote:
> Using list_move_tail() instead of list_del() + list_add_tail().
>
> Signed-off-by: Wei Yongjun
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
Shuah Khan wrote:
> I analyzed all calls to dma_map_single() and dma_map_page() in the
> kernel, to see if callers check for mapping errors, before using the
> returned address.
>
> The goal of this analysis is to find drivers that currently do not
> check dma mapping errors, and fix them.
>
> I
r
shared interrupt handler.
Signed-off-by: Clemens Ladisch <[EMAIL PROTECTED]>
--- linux.orig/sound/pci/bt87x.cTue Feb 19 15:03:57 2008 +0100
+++ linux/sound/pci/bt87x.c Wed Feb 20 08:55:18 2008 +0100
@@ -681,15 +681,12 @@ static struct snd_kcontrol_new snd_bt87x
static i
Joshua Roys wrote:
> sound/core/init.c: In function ‘snd_card_disconnect’:
> sound/core/init.c:307: warning: the address of ‘snd_shutdown_f_ops’ will
> always evaluate as ‘true’
>
> Signed-off-by: Joshua Roys <[EMAIL PROTECTED]>
> ---
> sound/core/init.c |1 -
> 1 files changed, 0
Chris Brennan wrote:
> These are the updated pastbin links to my BT8x8 issue. Hopefully these
> are helpful, if you need more information, let me know.
You didn't answer Robert's question.
And you are using the fglrx driver; you'll have to ask ATI whether if
supports video overlays and how to
Karl Beldan wrote:
> To tx a chunk of data from the SoC => network device, we :
> - prepare a buffer with a leading header embedding a pattern,
> - trigger the xfer and wait for an irq
> // The device updates the pattern and then triggers an irq
> - upon irq we check the pattern for the xfer
Karl Beldan wrote:
> On 7/31/12, Clemens Ladisch wrote:
>> Karl Beldan wrote:
>>> To tx a chunk of data from the SoC => network device, we :
>>> - prepare a buffer with a leading header embedding a pattern,
>>> - trigger the xfer and wait for an ir
James Courtier-Dutton wrote:
> I have been given a linux kernel sources tar file.
> It contains a modified version of the linux kernel.
> It is just source files, without any "git" history.
> What I would like to do is compare this with the mainline linux kernel
> git tree, and find the tag from
kernel kernel wrote:
> Requesting guidance on how to implement the missing mic input support
> for this Asus Xonar card. I've downloaded the relevant datasheets but
> am unsure how to proceed.
Rip out the card, and look (or eletrically trace) how the CMI8788's
GPIOs and the CS4245's
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
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
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
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
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
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
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
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
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
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
201 - 300 of 376 matches
Mail list logo
