Re: [PATCH] hpet, allow user controlled mmap for user processes

meter, 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/Docu

Re: [PATCH] hpet, allow user controlled mmap for user processes

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

Re: [alsa-devel] Xonar DG pci sound card driver incomplete

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 inputs/outputs

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 majord...@vger.kern

Re: Undefined Code in .../include/linux.bitops.h

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 th

Re: [PATCH] hpet, allow user controlled mmap for user processes

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 userspa

Re: [PATCH] ALSA: use list_move_tail instead of list_del/list_add_tail

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 Mor

Re: 2.6.23.14 snd_hda_intel problem

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 slot

Re: 2.6.23.14 snd_hda_intel problem

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 m

Re: About dma_sync_single_for_{cpu,device}

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 comple

Re: About dma_sync_single_for_{cpu,device}

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

Re: rngd (was: [PATCH 0/2] Add support for Qualcomm's PRNG)

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

[PATCH] hpet: remove useless check if fixmem32 is NULL

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

[PATCH] hpet: allow user controlled mmap for user processes

FAULT 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 -- driv

Re: [RFC] DMA mapping error check analysis

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 do

Re: [RFC] DMA mapping error check analysis

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 1Unm

Re: SQLite on flash (was: [PATCH 00/16] f2fs: introduce flash-friendly file system)

(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

Re: Device driver memory 'mmap()' function helper cleanup

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) != PAGE_

Re: [PATCH] ALSA: firewire: fix error return code in scs_probe()

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); > - if (!sc

Re: [PATCH v2] ata: increase retry count but shorten duration for Calxeda controller

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* specifi

Re: [PATCH] firewire: introduce fw_driver.probe and .remove methods

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

Re: 3.10.0-rc7: rtc_cmos.o: No linking because of missing CONFIG_HPET

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

Re: remap kernel static memory to user space

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

Re: [PATCH] firewire: Enable physical DMA above 4GB

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 t

Re: [PATCH] firewire: Enable physical DMA above 4GB

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 valu

[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: [PATCH] hwmon: (k10temp) Add support for Fam16h (Kabini)

+- > 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/

Re: [PATCH 11/11] sound/oxygen_io: take msecs_to_jiffies_min into use

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

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, FireWi

Re: [Alsa-devel] add support for syba 7.1 surround sound card

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

Re: [PATCH] firewire: Enable physical DMA above 4GB

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 thought

Re: [PATCH] emu10k1: Fix coccicheck warning

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 + 2

Re: [PATCH] emu10k1: Fix coccicheck warning

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

Re: [PATCH][RESEND] Add a USB audio quirk for the NuForce UDH-100 device.

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 unsubsc

Re: [PATCH][RESEND] Add a USB audio quirk for the NuForce UDH-100 device.

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

Re: snd_bt87x crash with kernel 2.6.24.2 on amd64

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

Re: [PATCH] [alsa-devel] Fix a compile warning under gcc-4.2.3.

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 insertions(

Re: BT8x8 TV Card

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 con

Re: [PATCH] firewire: core: feed /dev/random with devices' GUIDs

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

Re: Comparing linux kernel trees.

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 th

Re: [PATCH] Fix RTC_AIE with CONFIG_HPET_EMULATE_RTC

e > 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 inser

Re: HPET timer broken using 2.6.23.13 / nanosleep() hangs

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: > > am2:/sys/devices/system/clocksource/cl

Re: [PATCH] USB: mark USB drivers as being GPL only

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 patch

Re: [PATCH] USB: mark USB drivers as being GPL only

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

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. Apparently,

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 "do

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: [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 tasklet_hi_*

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

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

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

; > identifier r.i; > 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 > --- > sou

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

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

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

x10 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 ch

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

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

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

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 quirk

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 ca

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

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>: mov0x898(%rbx),%

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 co

Re: [alsa-devel] [PATCH] include/uapi/sound/firewire.h: use "_UAPI" instead of "UAPI"

quot;_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

Re: atomic read and increment question

noman pouigt wrote: > x = 1; > temp = atomic_read_increment(x); atomic_set(&x, 1); temp = atomic_inc_return(&x); > 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, C

Re: [PATCH v2 1/6] SP800-90A Deterministic Random Bit Generator

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, bu

Re: Testing 1 hard disk in 3 different usb enclosures: kernel reports 3 different "numbers of sectors"

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

Re: WaitForMultipleObjects/etc. In Kernel

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

Re: WaitForMultipleObjects/etc. In Kernel

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 nam

Re: [RFC PATCH] char: random: stir the output pools differently when the random_write lenght allows splitting the seed

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(&blocking_pool, buffer, count); > + ret = write_po

Re: [RFC PATCH] char: random: stir the output pools differently when the random_write lenght allows splitting the seed

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

Re: [RFC PATCH] char: random: stir the output pools differently when the random_write lenght allows splitting the seed

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 the

Re: [PATCH] CPU Jitter RNG: inclusion into kernel crypto API and /dev/random

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

Re: [PATCH] CPU Jitter RNG: inclusion into kernel crypto API and /dev/random

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 predictable

Re: [PATCH] CPU Jitter RNG: inclusion into kernel crypto API and /dev/random

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

Re: [PATCH] CPU Jitter RNG: inclusion into kernel crypto API and /dev/random

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

Re: [PATCH 0/2] Add support for Qualcomm's PRNG

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? The

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

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

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 mo

Re: [PATCH] x86: hpet: Don't default CONFIG_HPET_TIMER to be y for X86_64

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

Re: [PATCH 1/1] driver/snd: es18xx driver should use udelay error

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, Cleme

Re: [RFC][3/11][MANUX] Kernel compatibility : syscall numbers

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 0x81.

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

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), >> + NB_SMU_IND_A

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

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 &

Re: firewire: CLOCK_MONOTONIC_RAW exposure

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

Re: firewire: CLOCK_MONOTONIC_RAW exposure

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

Re: debug_dma_assert_idle - snd_hda_intel - cpu touching an active dma mapped cacheline

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 "Cohe

Re: [PATCH v2] x86: hpet: Don't default CONFIG_HPET_TIMER to be y for X86_64

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 hav

Re: [PATCH] arch: ia64: kernel: palinfo.c: Optimization of the Code

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 negat

Re: WaitForMultipleObjects/etc. In Kernel

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 file-d

RE: WaitForMultipleObjects/etc. In Kernel

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 {m

Re: WaitForMultipleObjects/etc. In Kernel

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 permis

Re: [PATCH] x86: Remove hpet vclock support

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). > Let's

  1   2   >