* Re: [RFC][PATCH] KVM: Introduce direct MSI message injection for in-kernel irqchips
From: Michael S. Tsirkin @ 2011-10-24 17:23 UTC (permalink / raw)
To: Jan Kiszka; +Cc: Avi Kivity, Marcelo Tosatti, kvm
In-Reply-To: <20111024170508.GB30385@redhat.com>
On Mon, Oct 24, 2011 at 07:05:08PM +0200, Michael S. Tsirkin wrote:
> On Mon, Oct 24, 2011 at 06:10:28PM +0200, Jan Kiszka wrote:
> > On 2011-10-24 18:05, Michael S. Tsirkin wrote:
> > >> This is what I have in mind:
> > >> - devices set PBA bit if MSI message cannot be sent due to mask (*)
> > >> - core checks&clears PBA bit on unmask, injects message if bit was set
> > >> - devices clear PBA bit if message reason is resolved before unmask (*)
> > >
> > > OK, but practically, when exactly does the device clear PBA?
> >
> > Consider a network adapter that signals messages in a RX ring: If the
> > corresponding vector is masked while the guest empties the ring, I
> > strongly assume that the device is supposed to take back the pending bit
> > in that case so that there is no interrupt inject on a later vector
> > unmask operation.
> >
> > Jan
>
> Do you mean virtio here? Do you expect this optimization to give
> a significant performance gain?
It would also be challenging to implement this in
a race free manner. Clearing on interrupt status read
seems straight-forward.
> > --
> > Siemens AG, Corporate Technology, CT T DE IT 1
> > Corporate Competence Center Embedded Linux
^ permalink raw reply
* Re: Samsung 90X3A Fn Keys
From: Tomasz Chmielewski @ 2011-10-24 17:20 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <CAD6YvxT8M6mR-2HuoetQ9BnowJgVSG2YXBRFhg-t1dAoR9TAyA@mail.gmail.com>
>> >> No need for a package, that module just comes with the standard
>> >> kernel. It should autoload as it seems to have proper modaliases
>> >> (dmi*:svn*SAMSUNG...). Doesn't it appear in "lsmod | grep samsung"?
>> >
>> > Nope, nothing there. For reference, I'm running Ubuntu 11.10 64 bit
>> > (and was running 11.04 a week ago, with the same problem).
>> >
>> > $ uname -a
>> > Linux lup0 2.6.38-11-generic #50-Ubuntu SMP Mon Sep 12 21:18:14 UTC
>> > 2011 i686 i686 i386 GNU/Linux
>>
>> Correction: Running Ubuntu 11.04 still (won't upgrade to the POS that
>> 11.10 is after trying it on the desktop).
>
> Then there's no way your brightness will work, unless your laptop
> happens to use ACPI for brightness.
FYI, it looks like samsung-laptop module doesn't like this Samsung laptop, even on the newest kernel (3.1.0):
root@s9:~# modprobe samsung-laptop
FATAL: Error inserting samsung_laptop (/lib/modules/3.1.0-030100-generic/kernel/drivers/platform/x86/samsung-laptop.ko): No such device
BIOS Information
Vendor: Phoenix Technologies Ltd.
Version: 07HL
Release Date: 09/26/2011
Handle 0x0001, DMI type 1, 27 bytes
System Information
Manufacturer: SAMSUNG ELECTRONICS CO., LTD.
Product Name: 90X3A
Version: 0.1
Handle 0x0002, DMI type 2, 15 bytes
Base Board Information
Manufacturer: SAMSUNG ELECTRONICS CO., LTD.
Product Name: 90X3A
Version: FAB1
--
Tomasz Chmielewski
http://wpkg.org
^ permalink raw reply
* [Bug 42168] New: false reporting of GL_MAX_TEXTURE_SIZE for nvidia geforce 9800 gt
From: bugzilla-daemon-CC+yJ3UmIYqDUpFQwHEjaQ @ 2011-10-24 17:20 UTC (permalink / raw)
To: nouveau-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW
https://bugs.freedesktop.org/show_bug.cgi?id=42168
Bug #: 42168
Summary: false reporting of GL_MAX_TEXTURE_SIZE for nvidia
geforce 9800 gt
Classification: Unclassified
Product: Mesa
Version: unspecified
Platform: Other
OS/Version: All
Status: NEW
Severity: normal
Priority: medium
Component: Drivers/DRI/nouveau
AssignedTo: nouveau-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org
ReportedBy: jimmac-Et1tbQHTxzrQT0dZR+AlfA@public.gmane.org
The driver claims to only support GL_MAX_TEXTURE_SIZE=4096 when the hardware
limit seems to be 8192. The limit is used by GNOME 3
(gnome-session-check-accelerated-helper) as a pre check to being able to run
gnome-shell, preventing me from using a 1600x1200 + 2560x1440px monitor setup.
If, however, I attach the secondary monitor after the session starts up, the
hardware seems to be perfectly capable of running the 3D accelerated
environment across both displays with no glitches and artifacts.
This is on Fedora 16 and the card is recognised as "nVidia Corporation G92
[GeForce 9800 GT] (rev a2)"
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
^ permalink raw reply
* [U-Boot] [PATCH V2 0/4] add mmc support for pantheon platform
From: Albert ARIBAUD @ 2011-10-24 17:20 UTC (permalink / raw)
To: u-boot
In-Reply-To: <1317710024-9484-1-git-send-email-leiwen@marvell.com>
Hi Lei Wen,
Le 04/10/2011 08:33, Lei Wen a ?crit :
> This patch seris add the mmc support for the pantheon platform.
> Also give platform like dkb and aspenite a workaround when enabling
> the 8bit mode for accessing the mmc.
>
> Changelog:
> V2: remove magic number, and replace it by macro definition and structure
> respectively.
> remove enable mmc function into seperated patch
>
> Lei Wen (4):
> ARM: pantheon: add mmc definition
> Marvell: dkb: add mmc support
> dkb: make mmc command as default enabled
> mmc: mv_sdhci: fix 8bus width access for 88SV331xV5
This causes a lot of build errors on dkb with ELDK42:
Configuring for dkb board...
In file included from mv_sdhci.c:3:
/home/uboot/src/u-boot-arm/include/sdhci.h:224: warning: 'struct
sdhci_host' declared inside parameter list
/home/uboot/src/u-boot-arm/include/sdhci.h:224: warning: its scope is
only this definition or declaration, which is probably not what you want
/home/uboot/src/u-boot-arm/include/sdhci.h:225: warning: 'struct
sdhci_host' declared inside parameter list
/home/uboot/src/u-boot-arm/include/sdhci.h:226: warning: 'struct
sdhci_host' declared inside parameter list
/home/uboot/src/u-boot-arm/include/sdhci.h:227: warning: 'struct
sdhci_host' declared inside parameter list
/home/uboot/src/u-boot-arm/include/sdhci.h:228: warning: 'struct
sdhci_host' declared inside parameter list
/home/uboot/src/u-boot-arm/include/sdhci.h:229: warning: 'struct
sdhci_host' declared inside parameter list
/home/uboot/src/u-boot-arm/include/sdhci.h: In function 'sdhci_writel':
/home/uboot/src/u-boot-arm/include/sdhci.h:247: warning: passing
argument 1 of 'host->ops->write_l' from incompatible pointer type
/home/uboot/src/u-boot-arm/include/sdhci.h: In function 'sdhci_writew':
/home/uboot/src/u-boot-arm/include/sdhci.h:255: warning: passing
argument 1 of 'host->ops->write_w' from incompatible pointer type
/home/uboot/src/u-boot-arm/include/sdhci.h: In function 'sdhci_writeb':
/home/uboot/src/u-boot-arm/include/sdhci.h:263: warning: passing
argument 1 of 'host->ops->write_b' from incompatible pointer type
/home/uboot/src/u-boot-arm/include/sdhci.h: In function 'sdhci_readl':
/home/uboot/src/u-boot-arm/include/sdhci.h:271: warning: passing
argument 1 of 'host->ops->read_l' from incompatible pointer type
/home/uboot/src/u-boot-arm/include/sdhci.h: In function 'sdhci_readw':
/home/uboot/src/u-boot-arm/include/sdhci.h:279: warning: passing
argument 1 of 'host->ops->read_w' from incompatible pointer type
/home/uboot/src/u-boot-arm/include/sdhci.h: In function 'sdhci_readb':
/home/uboot/src/u-boot-arm/include/sdhci.h:287: warning: passing
argument 1 of 'host->ops->read_b' from incompatible pointer type
mv_sdhci.c: In function 'mv_sdhci_writeb':
mv_sdhci.c:14: error: 'struct sdhci_host' has no member named 'mmc'
mv_sdhci.c:17: warning: implicit declaration of function 'IS_SD'
mv_sdhci.c:18: error: dereferencing pointer to incomplete type
mv_sdhci.c: In function 'mv_sdh_init':
mv_sdhci.c:48: warning: assignment from incompatible pointer type
Amicalement,
--
Albert.
^ permalink raw reply
* Re: kernel.org tarball/patch signature files
From: Valdis.Kletnieks @ 2011-10-24 17:18 UTC (permalink / raw)
To: Greg KH; +Cc: Jari Ruusu, linux-kernel
In-Reply-To: <20111023113727.GA24285@kroah.com>
[-- Attachment #1: Type: text/plain, Size: 602 bytes --]
On Sun, 23 Oct 2011 13:37:27 +0200, Greg KH said:
> If you are really worried about decompressor bugs, then run them in a
> virtual machine/chroot :)
Of more concern than bugs are errors during download. Yes, TCP has a checksum,
which is a CRC that quite frankly sucks when we're talking the amount of data
that kernel.org moves. So there's a non-zero chance you'll get bad data
downloaded. And you really want to do a more effective data check (MD5 or SHA
sum, or a PGP signature) *before* you decompress, in case the corrupted data
causes a spew of gigabytes of trash and fills your filesystem.
[-- Attachment #2: Type: application/pgp-signature, Size: 227 bytes --]
^ permalink raw reply
* Canceled: Yocto Technical Team Meeting
From: Liu, Song @ 2011-10-24 17:18 UTC (permalink / raw)
To: 'McCombe, Kevin', Wold, Saul, Zhang, Jessica,
'deVries, Alex', 'Polk, Jeffrey',
'Hatle, Mark', Purdie, Richard, Li, Susie, Lock, Joshua,
'Bruce Ashfield', Zanussi, Tom, Hart, Darren,
Flanagan, Elizabeth, Stewart, David C,
'Lieu.Ta@windriver.com',
'paul.anderson@windriver.com', Osier-mixon, Jeffrey,
Dmytriyenko, Denys, Kooi, Koen,
'yocto-ab@yoctoproject.org', Erway, Tracey M,
'Daniel Cauchy', Wang, Shane, 'Kridner, Jason',
Yu, Ke, Rifenbark, Scott M, 'Dixon, Brad',
'Jeremy Puhlman', yocto@yoctoproject.org,
'shsift-yocto@yahoo.com'
Cc: 'Ruff, Nithya', 'morvek@mvista.com'
[-- Attachment #1: Type: text/plain, Size: 350 bytes --]
When: Tuesday, October 25, 2011 8:00 AM-9:00 AM (UTC-08:00) Pacific Time (US & Canada).
Where: Bridge Info Enclosed
Note: The GMT offset above does not reflect daylight saving time adjustments.
*~*~*~*~*~*~*~*~*~*
Cancelling the meeting this week due to ELCE travel, please let me know if you have any urgent issue to discuss.
Song
[-- Attachment #2: Type: text/html, Size: 925 bytes --]
[-- Attachment #3: Type: text/calendar, Size: 6020 bytes --]
BEGIN:VCALENDAR
METHOD:CANCEL
PRODID:Microsoft Exchange Server 2010
VERSION:2.0
BEGIN:VTIMEZONE
TZID:Pacific Standard Time
BEGIN:STANDARD
DTSTART:16010101T020000
TZOFFSETFROM:-0700
TZOFFSETTO:-0800
RRULE:FREQ=YEARLY;INTERVAL=1;BYDAY=1SU;BYMONTH=11
END:STANDARD
BEGIN:DAYLIGHT
DTSTART:16010101T020000
TZOFFSETFROM:-0800
TZOFFSETTO:-0700
RRULE:FREQ=YEARLY;INTERVAL=1;BYDAY=2SU;BYMONTH=3
END:DAYLIGHT
END:VTIMEZONE
BEGIN:VEVENT
ORGANIZER;CN="Liu, Song":MAILTO:song.liu@intel.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="'McCombe,
Kevin'":MAILTO:kevin.mccombe@windriver.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="Wold, Saul"
:MAILTO:saul.wold@intel.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="Zhang, Jes
sica":MAILTO:jessica.zhang@intel.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="'deVries,
Alex'":MAILTO:Alex.deVries@windriver.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="'Polk, Jef
frey'":MAILTO:jeff.polk@windriver.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="'Hatle, Ma
rk'":MAILTO:mark.hatle@windriver.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="Purdie, Ri
chard":MAILTO:richard.purdie@intel.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="Li, Susie":
MAILTO:susie.li@intel.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="Lock, Josh
ua":MAILTO:joshua.lock@intel.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN='Bruce Ash
field':MAILTO:bruce.ashfield@windriver.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="Zanussi, T
om":MAILTO:tom.zanussi@intel.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="Hart, Darr
en":MAILTO:darren.hart@intel.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="Flanagan,
Elizabeth":MAILTO:elizabeth.flanagan@intel.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="Stewart, D
avid C":MAILTO:david.c.stewart@intel.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN='Lieu.Ta@w
indriver.com':MAILTO:Lieu.Ta@windriver.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN='paul.ande
rson@windriver.com':MAILTO:paul.anderson@windriver.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="Osier-mixo
n, Jeffrey":MAILTO:jeffrey.osier-mixon@intel.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="Dmytriyenk
o, Denys":MAILTO:denys@ti.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="Kooi, Koen"
:MAILTO:k-kooi@ti.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN='yocto-ab@
yoctoproject.org':MAILTO:yocto-ab@yoctoproject.org
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="Erway, Tra
cey M":MAILTO:tracey.m.erway@intel.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN='Daniel Ca
uchy':MAILTO:dcauchy@mvista.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="Wang, Shan
e":MAILTO:shane.wang@intel.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="'Kridner,
Jason'":MAILTO:jdk@ti.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="Yu, Ke":MAI
LTO:ke.yu@intel.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="Rifenbark,
Scott M":MAILTO:scott.m.rifenbark@intel.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="'Dixon, Br
ad'":MAILTO:Brad_Dixon@mentor.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN='Jeremy Pu
hlman':MAILTO:jpuhlman@gmail.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=yocto@yoct
oproject.org:MAILTO:yocto@yoctoproject.org
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN='shsift-yo
cto@yahoo.com':MAILTO:shsift-yocto@yahoo.com
ATTENDEE;ROLE=OPT-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN='morvek@mv
ista.com':MAILTO:morvek@mvista.com
ATTENDEE;ROLE=OPT-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="'Ruff, Nit
hya'":MAILTO:Nithya.Ruff@windriver.com
ATTENDEE;ROLE=OPT-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="Moeller, T
horsten":MAILTO:thorsten.moeller@intel.com
ATTENDEE;ROLE=OPT-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="Saxena, Ra
hul":MAILTO:rahul.saxena@intel.com
ATTENDEE;ROLE=OPT-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="'Ranslam,
Rob'":MAILTO:Rob.Ranslam@windriver.com
ATTENDEE;ROLE=OPT-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN='Anders Da
rander':MAILTO:anders@chargestorm.se
ATTENDEE;ROLE=OPT-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="Bodke, Kis
hore K":MAILTO:kishore.k.bodke@intel.com
DESCRIPTION;LANGUAGE=en-US:When: Tuesday\, October 25\, 2011 8:00 AM-9:00 A
M (UTC-08:00) Pacific Time (US & Canada).\nWhere: Bridge Info Enclosed\n\n
Note: The GMT offset above does not reflect daylight saving time adjustmen
ts.\n\n*~*~*~*~*~*~*~*~*~*\n\nCancelling the meeting this week due to ELCE
travel\, please let me know if you have any urgent issue to discuss.\n\nS
ong\n\n\n
SUMMARY;LANGUAGE=en-US:Canceled: Yocto Technical Team Meeting
DTSTART;TZID=Pacific Standard Time:20111025T080000
DTEND;TZID=Pacific Standard Time:20111025T090000
UID:040000008200E00074C5B7101A82E00800000000006E22EF285CCC01000000000000000
010000000E6FE366D8B14A84589F18D6054E85224
RECURRENCE-ID;TZID=Pacific Standard Time:20111025T080000
CLASS:PUBLIC
PRIORITY:1
DTSTAMP:20111024T171804Z
TRANSP:OPAQUE
STATUS:CANCELLED
SEQUENCE:6
LOCATION;LANGUAGE=en-US:Bridge Info Enclosed
X-MICROSOFT-CDO-APPT-SEQUENCE:6
X-MICROSOFT-CDO-OWNERAPPTID:1406175195
X-MICROSOFT-CDO-BUSYSTATUS:FREE
X-MICROSOFT-CDO-INTENDEDSTATUS:FREE
X-MICROSOFT-CDO-ALLDAYEVENT:FALSE
X-MICROSOFT-CDO-IMPORTANCE:2
X-MICROSOFT-CDO-INSTTYPE:3
X-MICROSOFT-DISALLOW-COUNTER:FALSE
END:VEVENT
END:VCALENDAR
^ permalink raw reply
* [Buildroot] [RFC] Slides "Using Buildroot for real projects"
From: Thomas Petazzoni @ 2011-10-24 17:17 UTC (permalink / raw)
To: buildroot
In-Reply-To: <201110241842.06558.yann.morin.1998@anciens.enib.fr>
Le Mon, 24 Oct 2011 18:42:06 +0200,
"Yann E. MORIN" <yann.morin.1998@anciens.enib.fr> a ?crit :
> The problem is that /bin/sh might be whatever. With a POSIX-conformant
> /bin/sh (eg. dash), this is true. With bash, it is not. Alas, many
> systems still have bash as /bin/sh.
>
> $ ls -l /bin/sh
> lrwxrwxrwx 1 root root 4 May 17 23:53 /bin/sh -> bash
> $ echo "bli\nbla"
> bli\nbla
> $ /bin/bash
> $ echo "bli\nbla"
> bli\nbla
> $ exit
> $ /bin/dash
> $ echo "bli\nbla"
> bli
> bla
>
> The answer it to use printf [0].
>
> I now use printf as much as I can. printf is in POSIX and does not suffer
> from all the discrepancies there are in the many echo implementations.
Ah, nice to know. Thanks!
For the moment, I've been using echo, knowing that its behavior is not
consistent across systems. But indeed printf is much better.
Thanks!
Thomas
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply
* Re: [PATCH 2/2] i2c/nomadik: runtime PM support
From: Linus Walleij @ 2011-10-24 17:17 UTC (permalink / raw)
To: Magnus Damm
Cc: Jonas Aaberg, Linus Walleij, Ben Dooks,
linux-i2c-u79uwXL29TY76Z2rM5mHXA, Rafael J. Wysocki,
Russell King - ARM Linux
In-Reply-To: <CANqRtoRw5+1yrEuphdYT+wq2ooHTojj00i5yGLPMWomUBPSP1Q-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Mon, Oct 24, 2011 at 4:32 PM, Magnus Damm <magnus.damm-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> On Fri, Oct 21, 2011 at 8:19 PM, Linus Walleij <linus.walleij@linaro.org> wrote:
>
>> Currently we have something similar for the AMBA
>> bus here, since it actually has code in place to grab
>> the block clock on probe() and its own runtime PM
>> callbacks. Since the bus driver holds the actual reference
>> to the clock, we have to call down into the bus callbacks
>> from the platform runtime PM implementation since our
>> implementation takes precedence. I guess this is expected
>> way of doing it?
>
> I'm not sure actually. We should sit down together and discuss this
> over an afternoon - hopefully together with Rafael. I could probably
> find time during next week in Orlando if you're around.
OK sounds like a plan, I'll bring our code and we'll atleast try
to understand each others' thinking!
Med vänlig hälsning
Linus Walleij
^ permalink raw reply
* [PATCH] x86: Fix compilation bug in kprobes' twobyte_is_boostable
From: Josh Stone @ 2011-10-24 17:15 UTC (permalink / raw)
To: Linus Torvalds
Cc: Josh Stone, linux-kernel, Thomas Gleixner, Ingo Molnar,
H. Peter Anvin, x86, Srikar Dronamraju, Masami Hiramatsu,
Jakub Jelinek
In-Reply-To: <CA+55aFzxf1XMvMBrHzbrUKunWrPZx0Q=2=DyWv9HDpQ3Zc40ZQ@mail.gmail.com>
When compiling an i386_defconfig kernel with gcc-4.6.1-9.fc15.i686, I
noticed a warning about the asm operand for test_bit in kprobes'
can_boost. I discovered that this caused only the first long of
twobyte_is_boostable[] to be output.
Jakub filed and fixed gcc PR50571 to correct the warning and this output
issue. But to solve it for less current gcc, we can make kprobes'
twobyte_is_boostable[] non-const, and it won't be optimized out.
Before:
CC arch/x86/kernel/kprobes.o
In file included from include/linux/bitops.h:22:0,
from include/linux/kernel.h:17,
from [...]/arch/x86/include/asm/percpu.h:44,
from [...]/arch/x86/include/asm/current.h:5,
from [...]/arch/x86/include/asm/processor.h:15,
from [...]/arch/x86/include/asm/atomic.h:6,
from include/linux/atomic.h:4,
from include/linux/mutex.h:18,
from include/linux/notifier.h:13,
from include/linux/kprobes.h:34,
from arch/x86/kernel/kprobes.c:43:
[...]/arch/x86/include/asm/bitops.h: In function ‘can_boost.part.1’:
[...]/arch/x86/include/asm/bitops.h:319:2: warning: use of memory input
without lvalue in asm operand 1 is deprecated [enabled by default]
$ objdump -rd arch/x86/kernel/kprobes.o | grep -A1 -w bt
551: 0f a3 05 00 00 00 00 bt %eax,0x0
554: R_386_32 .rodata.cst4
$ objdump -s -j .rodata.cst4 -j .data arch/x86/kernel/kprobes.o
arch/x86/kernel/kprobes.o: file format elf32-i386
Contents of section .data:
0000 48000000 00000000 00000000 00000000 H...............
Contents of section .rodata.cst4:
0000 4c030000 L...
Only a single long of twobyte_is_boostable[] is in the object file.
After, without the const on twobyte_is_boostable:
$ objdump -rd arch/x86/kernel/kprobes.o | grep -A1 -w bt
551: 0f a3 05 20 00 00 00 bt %eax,0x20
554: R_386_32 .data
$ objdump -s -j .rodata.cst4 -j .data arch/x86/kernel/kprobes.o
arch/x86/kernel/kprobes.o: file format elf32-i386
Contents of section .data:
0000 48000000 00000000 00000000 00000000 H...............
0010 00000000 00000000 00000000 00000000 ................
0020 4c030000 0f000200 ffff0000 ffcff0c0 L...............
0030 0000ffff 3bbbfff8 03ff2ebb 26bb2e77 ....;.......&..w
Now all 32 bytes are output into .data instead.
Signed-off-by: Josh Stone <jistone@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
Cc: Jakub Jelinek <jakub@redhat.com>
---
arch/x86/kernel/kprobes.c | 4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/arch/x86/kernel/kprobes.c b/arch/x86/kernel/kprobes.c
index f1a6244..794bc95 100644
--- a/arch/x86/kernel/kprobes.c
+++ b/arch/x86/kernel/kprobes.c
@@ -75,8 +75,10 @@ DEFINE_PER_CPU(struct kprobe_ctlblk, kprobe_ctlblk);
/*
* Undefined/reserved opcodes, conditional jump, Opcode Extension
* Groups, and some special opcodes can not boost.
+ * This is non-const to keep gcc from statically optimizing it out, as
+ * variable_test_bit makes gcc think only *(unsigned long*) is used.
*/
-static const u32 twobyte_is_boostable[256 / 32] = {
+static u32 twobyte_is_boostable[256 / 32] = {
/* 0 1 2 3 4 5 6 7 8 9 a b c d e f */
/* ---------------------------------------------- */
W(0x00, 0, 0, 1, 1, 0, 0, 1, 0, 1, 1, 0, 0, 0, 0, 0, 0) | /* 00 */
--
1.7.6.4
^ permalink raw reply related
* [U-Boot] [PATCH 2/3] nds32: cache: define ARCH_DMA_MINALIGN for DMA buffer alignment
From: Anton Staaf @ 2011-10-24 17:16 UTC (permalink / raw)
To: u-boot
In-Reply-To: <1319449593-2427-2-git-send-email-macpaul@andestech.com>
On Mon, Oct 24, 2011 at 2:46 AM, Macpaul Lin <macpaul@andestech.com> wrote:
> Add ARCH_DMA_MINALIGN definition to asm/cache.h
>
> Signed-off-by: Macpaul Lin <macpaul@andestech.com>
Acked-by: Anton Staaf <robotboy@chromium.org>
> ---
> ?arch/nds32/include/asm/cache.h | ? 11 +++++++++++
> ?1 files changed, 11 insertions(+), 0 deletions(-)
>
> diff --git a/arch/nds32/include/asm/cache.h b/arch/nds32/include/asm/cache.h
> index d769196..fc22c7b 100644
> --- a/arch/nds32/include/asm/cache.h
> +++ b/arch/nds32/include/asm/cache.h
> @@ -51,4 +51,15 @@ DEFINE_GET_SYS_REG(DCM_CFG);
> ?#define DCM_CFG_OFF_DSZ ? ? ? ?6 ? ? ? /* D-cache line size */
> ?#define DCM_CFG_MSK_DSZ ? ? ? ?(0x7UL << DCM_CFG_OFF_DSZ)
>
> +/*
> + * The current upper bound for NDS32 L1 data cache line sizes is 32 bytes.
> + * We use that value for aligning DMA buffers unless the board config has
> + * specified an alternate cache line size.
> + */
> +#ifdef CONFIG_SYS_CACHELINE_SIZE
> +#define ARCH_DMA_MINALIGN ? ? ?CONFIG_SYS_CACHELINE_SIZE
> +#else
> +#define ARCH_DMA_MINALIGN ? ? ?32
> +#endif
> +
> ?#endif /* _ASM_CACHE_H */
> --
> 1.7.3.5
>
>
^ permalink raw reply
* Re: [PATCH 1/2] drm/ttm: add a way to bo_wait for either the last read or last write
From: Marek Olšák @ 2011-10-24 17:10 UTC (permalink / raw)
To: Thomas Hellstrom; +Cc: dri-devel
In-Reply-To: <4EA57AA4.6040600@shipmail.org>
Hi Thomas,
I have made no progress so far due to lack of time.
Would you mind if I fixed the most important things first, which are:
- sync objects are not ordered, (A)
- every sync object must have its corresponding sync_obj_arg, (B)
and if I fixed (C) some time later.
I planned on moving the two sync objects from ttm into radeon and not
using ttm_bo_wait from radeon (i.e. pretty much reimplementing what it
does), but it looks more complicated to me than I had originally
thought.
Marek
On Mon, Oct 24, 2011 at 4:48 PM, Thomas Hellstrom <thomas@shipmail.org> wrote:
>
> Marek,
> Any progress on this. The merge window is about to open soon I guess and we
> need a fix by then.
>
> /Thomas
^ permalink raw reply
* Re: [Qemu-devel] [PATCH v2 3/4] Add cap reduction support to enable use as SUID
From: Blue Swirl @ 2011-10-24 17:10 UTC (permalink / raw)
To: Corey Bryant; +Cc: rmarwah, aliguori, qemu-devel
In-Reply-To: <4EA5729C.60509@linux.vnet.ibm.com>
On Mon, Oct 24, 2011 at 14:13, Corey Bryant <coreyb@linux.vnet.ibm.com> wrote:
>
>
> On 10/23/2011 09:22 AM, Blue Swirl wrote:
>>
>> On Fri, Oct 21, 2011 at 15:07, Corey Bryant<coreyb@linux.vnet.ibm.com>
>> wrote:
>>>
>>> The ideal way to use qemu-bridge-helper is to give it an fscap of using:
>>>
>>> setcap cap_net_admin=ep qemu-bridge-helper
>>>
>>> Unfortunately, most distros still do not have a mechanism to package
>>> files
>>> with fscaps applied. This means they'll have to SUID the
>>> qemu-bridge-helper
>>> binary.
>>>
>>> To improve security, use libcap to reduce our capability set to just
>>> cap_net_admin, then reduce privileges down to the calling user. This is
>>> hopefully close to equivalent to fscap support from a security
>>> perspective.
>>>
>>> Signed-off-by: Anthony Liguori<aliguori@us.ibm.com>
>>> Signed-off-by: Richa Marwaha<rmarwah@linux.vnet.ibm.com>
>>> Signed-off-by: Corey Bryant<coreyb@linux.vnet.ibm.com>
>>> ---
>>> configure | 34 ++++++++++++++++++++++++++++++++++
>>> qemu-bridge-helper.c | 39 +++++++++++++++++++++++++++++++++++++++
>>> 2 files changed, 73 insertions(+), 0 deletions(-)
>>>
>>> diff --git a/configure b/configure
>>> index 6c8b659..fed66b0 100755
>>> --- a/configure
>>> +++ b/configure
>>> @@ -128,6 +128,7 @@ vnc_thread="no"
>>> xen=""
>>> xen_ctrl_version=""
>>> linux_aio=""
>>> +cap=""
>>> attr=""
>>> xfs=""
>>>
>>> @@ -653,6 +654,10 @@ for opt do
>>> ;;
>>> --enable-kvm) kvm="yes"
>>> ;;
>>> + --disable-cap) cap="no"
>>> + ;;
>>> + --enable-cap) cap="yes"
>>> + ;;
>>> --disable-spice) spice="no"
>>> ;;
>>> --enable-spice) spice="yes"
>>> @@ -1032,6 +1037,8 @@ echo " --disable-vde disable support
>>> for vde network"
>>> echo " --enable-vde enable support for vde network"
>>> echo " --disable-linux-aio disable Linux AIO support"
>>> echo " --enable-linux-aio enable Linux AIO support"
>>> +echo " --disable-cap disable libcap-ng support"
>>> +echo " --enable-cap enable libcap-ng support"
>>> echo " --disable-attr disables attr and xattr support"
>>> echo " --enable-attr enable attr and xattr support"
>>> echo " --disable-blobs disable installing provided firmware
>>> blobs"
>>> @@ -1638,6 +1645,29 @@ EOF
>>> fi
>>>
>>> ##########################################
>>> +# libcap-ng library probe
>>> +if test "$cap" != "no" ; then
>>> + cap_libs="-lcap-ng"
>>> + cat> $TMPC<< EOF
>>> +#include<cap-ng.h>
>>> +int main(void)
>>> +{
>>> + capng_capability_to_name(CAPNG_EFFECTIVE);
>>> + return 0;
>>> +}
>>> +EOF
>>> + if compile_prog "" "$cap_libs" ; then
>>> + cap=yes
>>> + libs_tools="$cap_libs $libs_tools"
>>> + else
>>> + if test "$cap" = "yes" ; then
>>> + feature_not_found "cap"
>>> + fi
>>> + cap=no
>>> + fi
>>> +fi
>>> +
>>> +##########################################
>>> # Sound support libraries probe
>>>
>>> audio_drv_probe()
>>> @@ -2735,6 +2765,7 @@ echo "fdatasync $fdatasync"
>>> echo "madvise $madvise"
>>> echo "posix_madvise $posix_madvise"
>>> echo "uuid support $uuid"
>>> +echo "libcap-ng support $cap"
>>> echo "vhost-net support $vhost_net"
>>> echo "Trace backend $trace_backend"
>>> echo "Trace output file $trace_file-<pid>"
>>> @@ -2846,6 +2877,9 @@ fi
>>> if test "$vde" = "yes" ; then
>>> echo "CONFIG_VDE=y">> $config_host_mak
>>> fi
>>> +if test "$cap" = "yes" ; then
>>> + echo "CONFIG_LIBCAP=y">> $config_host_mak
>>> +fi
>>> for card in $audio_card_list; do
>>> def=CONFIG_`echo $card | tr '[:lower:]' '[:upper:]'`
>>> echo "$def=y">> $config_host_mak
>>> diff --git a/qemu-bridge-helper.c b/qemu-bridge-helper.c
>>> index db257d5..b1562eb 100644
>>> --- a/qemu-bridge-helper.c
>>> +++ b/qemu-bridge-helper.c
>>> @@ -33,6 +33,10 @@
>>>
>>> #include "net/tap-linux.h"
>>>
>>> +#ifdef CONFIG_LIBCAP
>>> +#include<cap-ng.h>
>>> +#endif
>>> +
>>> #define MAX_ACLS (128)
>>> #define DEFAULT_ACL_FILE CONFIG_QEMU_CONFDIR "/bridge.conf"
>>>
>>> @@ -185,6 +189,27 @@ static int send_fd(int c, int fd)
>>> return sendmsg(c,&msg, 0);
>>> }
>>>
>>> +#ifdef CONFIG_LIBCAP
>>> +static int drop_privileges(void)
>>> +{
>>> + /* clear all capabilities */
>>> + capng_clear(CAPNG_SELECT_BOTH);
>>> +
>>> + if (capng_update(CAPNG_ADD, CAPNG_EFFECTIVE | CAPNG_PERMITTED,
>>> + CAP_NET_ADMIN)< 0) {
>>> + return -1;
>>> + }
>>> +
>>> + /* change to calling user's real uid and gid, retaining supplemental
>>> + * groups and CAP_NET_ADMIN */
>>> + if (capng_change_id(getuid(), getgid(), CAPNG_CLEAR_BOUNDING)) {
>>> + return -1;
>>> + }
>>> +
>>> + return 0;
>>> +}
>>> +#endif
>>> +
>>> int main(int argc, char **argv)
>>> {
>>> struct ifreq ifr;
>>> @@ -198,6 +223,20 @@ int main(int argc, char **argv)
>>> int acl_count = 0;
>>> int i, access_allowed, access_denied;
>>>
>>> + /* if we're run from an suid binary, immediately drop privileges
>>> preserving
>>> + * cap_net_admin -- exit immediately if libcap not configured */
>>> + if (geteuid() == 0&& getuid() != geteuid()) {
>>> +#ifdef CONFIG_LIBCAP
>>> + if (drop_privileges() == -1) {
>>> + fprintf(stderr, "failed to drop privileges\n");
>>> + return 1;
>>> + }
>>> +#else
>>> + fprintf(stderr, "failed to drop privileges\n");
>>
>> This makes the tool useless without CONFIG_LIBCAP. Wouldn't it be
>> possible to use setfsuid() instead for Linux?
>>
>> Some fork+setuid helper could be used for other Unix and for the lame
>> OSes without any file system DAC capabilities, a different syntax that
>> does not rely on underlying FS may need to be introduced. Again, I
>> don't know if the tool is even interesting for non-Linux.
>>
>
> I just want to make sure that there is no chance that the helper is run as
> root beyond this point. Are you saying to seteuid(getuid) and
> setfsuid(root)? I'm not sure that would drop the privileges enough.
Without capabilities, we can't drop root privileges because bridge
setup would fail otherwise, but we could use setfsuid(getuid()) and
setfsgid(getgid()) during file access so permission checks work.
Perhaps non-Linux could use seteuid() etc. instead.
>>> + return 1;
>>> +#endif
>>> + }
>>> +
>>> /* parse arguments */
>>> if (argc< 3 || argc> 4) {
>>> fprintf(stderr, "Usage: %s [--use-vnet] BRIDGE FD\n", argv[0]);
>>> --
>>> 1.7.3.4
>>>
>>>
>>>
>>
>
> --
> Regards,
> Corey
>
>
^ permalink raw reply
* Re: "Benchmarks"
From: Kent Overstreet @ 2011-10-24 17:10 UTC (permalink / raw)
To: Brad Campbell; +Cc: linux-bcache-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <4EA20E4E.8050402-+nnirC7rrGZibQn6LdNjmg@public.gmane.org>
Cool!
The thing I'd be really curious about is what the benchmarks would
look like if you were using only the SSD, no bcache.
How happy are you with it?
On Fri, Oct 21, 2011 at 8:29 PM, Brad Campbell
<lists2009-+nnirC7rrGZibQn6LdNjmg@public.gmane.org> wrote:
> I use the term loosely.
>
> This is with the raw drive being a Maxtor MaxlineII 250GB 7200RPM SATA unit.
> It's about a 2004 vintage with over 30,000 hours on it. Slow and steady.
>
> The Cache device is an OCZ Vertex Plus 120GB Unit. Not all that fast or
> clever. The Cache has writeback enabled and is formatted with -w512 so that
> direct IO worked as previously discussed.
>
> The benchmark is conducted inside an XP VM running under KVM. The device is
> a qcow2 backing file formatted NTFS. I ran the test multiple times without
> the cache until the numbers stabilised (the backing file was being expanded
> as required)
>
> http://www.fnarfbargle.com/private/111022_bcache/Without_Cache.png
> http://www.fnarfbargle.com/private/111022_bcache/With_Cache.png
>
> As expected a significant improvement in random small I/O. The VM is far
> more responsive with the cache.
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-bcache" in
> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: [PATCH/WIP 00/11] read_directory() rewrite to support struct pathspec
From: Junio C Hamano @ 2011-10-24 17:10 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy; +Cc: git
In-Reply-To: <1319438176-7304-1-git-send-email-pclouds@gmail.com>
Nguyễn Thái Ngọc Duy <pclouds@gmail.com> writes:
> This is the first time "make test" fully passes (*) for me, so it's
> probably good enough for human eyes.
Nice way to describe the done-ness of the series. Looking forward to read
it through ;-)
Thanks.
^ permalink raw reply
* [PATCH v2 1/6] mfd: TPS65910: Handle non-existent devices
From: Kyle Manna @ 2011-10-24 17:05 UTC (permalink / raw)
To: linux-kernel, Samuel Ortiz
Cc: Jorge Eduardo Candelaria, Mark Brown, Liam Girdwood, Kyle Manna
In-Reply-To: <1319475964-10841-1-git-send-email-kyle.manna@fuel7.com>
Attempt to read the first register of the device, if there is no
device return -ENODEV
Signed-off-by: Kyle Manna <kyle.manna@fuel7.com>
---
drivers/mfd/tps65910.c | 20 ++++++++++++++------
1 files changed, 14 insertions(+), 6 deletions(-)
diff --git a/drivers/mfd/tps65910.c b/drivers/mfd/tps65910.c
index 6f5b8cf..03fb4a7 100644
--- a/drivers/mfd/tps65910.c
+++ b/drivers/mfd/tps65910.c
@@ -138,6 +138,7 @@ static int tps65910_i2c_probe(struct i2c_client *i2c,
struct tps65910_board *pmic_plat_data;
struct tps65910_platform_data *init_data;
int ret = 0;
+ char buff;
pmic_plat_data = dev_get_platdata(&i2c->dev);
if (!pmic_plat_data)
@@ -161,11 +162,17 @@ static int tps65910_i2c_probe(struct i2c_client *i2c,
tps65910->write = tps65910_i2c_write;
mutex_init(&tps65910->io_mutex);
- ret = mfd_add_devices(tps65910->dev, -1,
- tps65910s, ARRAY_SIZE(tps65910s),
- NULL, 0);
- if (ret < 0)
+ /* Check that the device is actually there */
+ ret = tps65910_i2c_read(tps65910, 0x0, 1, &buff);
+ if (ret < 0) {
+ ret = -ENODEV;
goto err;
+ }
+
+ ret = mfd_add_devices(tps65910->dev, -1, tps65910s,
+ ARRAY_SIZE(tps65910s), NULL, 0);
+ if (ret < 0)
+ goto err2;
init_data->irq = pmic_plat_data->irq;
init_data->irq_base = pmic_plat_data->irq;
@@ -174,13 +181,14 @@ static int tps65910_i2c_probe(struct i2c_client *i2c,
ret = tps65910_irq_init(tps65910, init_data->irq, init_data);
if (ret < 0)
- goto err;
+ goto err2;
kfree(init_data);
return ret;
-err:
+err2:
mfd_remove_devices(tps65910->dev);
+err:
kfree(tps65910);
kfree(init_data);
return ret;
--
1.7.5.4
^ permalink raw reply related
* Re: [PATCH] usb: fix unaligned access
From: Sascha Hauer @ 2011-10-24 17:07 UTC (permalink / raw)
To: Antony Pavlov; +Cc: barebox
In-Reply-To: <CAA4bVAGRrH4bwozuWfV9Ck4c=vPfRE4oOPLzWFU2u8--8avkLw@mail.gmail.com>
On Mon, Oct 24, 2011 at 07:14:04PM +0400, Antony Pavlov wrote:
> On 23 October 2011 13:29, Fabian van der Werf <fvanderwerf@gmail.com> wrote:
> >>
> >> Looks like a valid patch, I wonder that this never was a problem before.
> >> ARM should break here aswell I think. What architecture are you using?
> >>
> >
> > I am working with a pandaboard (arm cortex a9). The pandaboard has a
> > usb ethernet controller, so I need usb to boot over tftp. I guess that
> > most arm configurations don't need usb for booting, and in that case
> > you won't run into this problem.
>
> I have DUB-E100 USB Ethernet (ID 2001:3c05) connected to Toshiba AC100
> (NVidia Tegra2 --- Cortex A9); tftp works fine without usb unaligned
> access patch.
Works for me aswell, though the access definitely is unaligned.
Sascha
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
^ permalink raw reply
* [PATCH v2 2/6] mfd: TPS65910: Add I2C slave address macros
From: Kyle Manna @ 2011-10-24 17:06 UTC (permalink / raw)
To: linux-kernel, Samuel Ortiz
Cc: Jorge Eduardo Candelaria, Mark Brown, Liam Girdwood, Kyle Manna
In-Reply-To: <1319475964-10841-1-git-send-email-kyle.manna@fuel7.com>
Add I2C slave addresses to the header file so that platform definitions
can use them.
Signed-off-by: Kyle Manna <kyle.manna@fuel7.com>
---
include/linux/mfd/tps65910.h | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/include/linux/mfd/tps65910.h b/include/linux/mfd/tps65910.h
index 82b4c88..399d80a 100644
--- a/include/linux/mfd/tps65910.h
+++ b/include/linux/mfd/tps65910.h
@@ -21,6 +21,10 @@
#define TPS65910 0
#define TPS65911 1
+/* I2C Slave Address 7-bit */
+#define TPS65910_I2C_ID0 0x12 /* Smart Reflex */
+#define TPS65910_I2C_ID1 0x2D /* general-purpose control */
+
/* TPS regulator type list */
#define REGULATOR_LDO 0
#define REGULATOR_DCDC 1
--
1.7.5.4
^ permalink raw reply related
* [PATCH v2 4/6] mfd: TPS65910: Move linux/gpio.h include to header
From: Kyle Manna @ 2011-10-24 17:06 UTC (permalink / raw)
To: linux-kernel, Samuel Ortiz
Cc: Jorge Eduardo Candelaria, Mark Brown, Liam Girdwood, Kyle Manna
In-Reply-To: <1319475964-10841-1-git-send-email-kyle.manna@fuel7.com>
The tps65910.h file depends on linux/gpio.h. Move the include from the
source file to the tps65910.h header file.
Signed-off-by: Kyle Manna <kyle.manna@fuel7.com>
---
drivers/mfd/tps65910.c | 1 -
include/linux/mfd/tps65910.h | 3 +++
2 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/drivers/mfd/tps65910.c b/drivers/mfd/tps65910.c
index f4654d5..36bc08c 100644
--- a/drivers/mfd/tps65910.c
+++ b/drivers/mfd/tps65910.c
@@ -18,7 +18,6 @@
#include <linux/init.h>
#include <linux/slab.h>
#include <linux/i2c.h>
-#include <linux/gpio.h>
#include <linux/mfd/core.h>
#include <linux/mfd/tps65910.h>
diff --git a/include/linux/mfd/tps65910.h b/include/linux/mfd/tps65910.h
index 399d80a..503ded3 100644
--- a/include/linux/mfd/tps65910.h
+++ b/include/linux/mfd/tps65910.h
@@ -17,6 +17,9 @@
#ifndef __LINUX_MFD_TPS65910_H
#define __LINUX_MFD_TPS65910_H
+#include <linux/gpio.h>
+#include <linux/regulator/machine.h>
+
/* TPS chip id list */
#define TPS65910 0
#define TPS65911 1
--
1.7.5.4
^ permalink raw reply related
* [PATCH v2 5/6] mfd: TPS65910: Move regulator defs to header
From: Kyle Manna @ 2011-10-24 17:06 UTC (permalink / raw)
To: linux-kernel, Samuel Ortiz
Cc: Jorge Eduardo Candelaria, Mark Brown, Liam Girdwood, Kyle Manna
In-Reply-To: <1319475964-10841-1-git-send-email-kyle.manna@fuel7.com>
Move the regulator defintions to the header so that platform board file
can use them to configure specific regulators.
Signed-off-by: Kyle Manna <kyle.manna@fuel7.com>
---
drivers/regulator/tps65910-regulator.c | 24 ------------------------
include/linux/mfd/tps65910.h | 25 +++++++++++++++++++++++++
2 files changed, 25 insertions(+), 24 deletions(-)
diff --git a/drivers/regulator/tps65910-regulator.c b/drivers/regulator/tps65910-regulator.c
index 66d2d60..44b4f22 100644
--- a/drivers/regulator/tps65910-regulator.c
+++ b/drivers/regulator/tps65910-regulator.c
@@ -25,30 +25,6 @@
#include <linux/gpio.h>
#include <linux/mfd/tps65910.h>
-#define TPS65910_REG_VRTC 0
-#define TPS65910_REG_VIO 1
-#define TPS65910_REG_VDD1 2
-#define TPS65910_REG_VDD2 3
-#define TPS65910_REG_VDD3 4
-#define TPS65910_REG_VDIG1 5
-#define TPS65910_REG_VDIG2 6
-#define TPS65910_REG_VPLL 7
-#define TPS65910_REG_VDAC 8
-#define TPS65910_REG_VAUX1 9
-#define TPS65910_REG_VAUX2 10
-#define TPS65910_REG_VAUX33 11
-#define TPS65910_REG_VMMC 12
-
-#define TPS65911_REG_VDDCTRL 4
-#define TPS65911_REG_LDO1 5
-#define TPS65911_REG_LDO2 6
-#define TPS65911_REG_LDO3 7
-#define TPS65911_REG_LDO4 8
-#define TPS65911_REG_LDO5 9
-#define TPS65911_REG_LDO6 10
-#define TPS65911_REG_LDO7 11
-#define TPS65911_REG_LDO8 12
-
#define TPS65910_SUPPLY_STATE_ENABLED 0x1
/* supported VIO voltages in milivolts */
diff --git a/include/linux/mfd/tps65910.h b/include/linux/mfd/tps65910.h
index 503ded3..84108bb 100644
--- a/include/linux/mfd/tps65910.h
+++ b/include/linux/mfd/tps65910.h
@@ -746,6 +746,31 @@
#define TPS65910_GPIO_STS BIT(1)
#define TPS65910_GPIO_SET BIT(0)
+/* Regulator Index Definitions */
+#define TPS65910_REG_VRTC 0
+#define TPS65910_REG_VIO 1
+#define TPS65910_REG_VDD1 2
+#define TPS65910_REG_VDD2 3
+#define TPS65910_REG_VDD3 4
+#define TPS65910_REG_VDIG1 5
+#define TPS65910_REG_VDIG2 6
+#define TPS65910_REG_VPLL 7
+#define TPS65910_REG_VDAC 8
+#define TPS65910_REG_VAUX1 9
+#define TPS65910_REG_VAUX2 10
+#define TPS65910_REG_VAUX33 11
+#define TPS65910_REG_VMMC 12
+
+#define TPS65911_REG_VDDCTRL 4
+#define TPS65911_REG_LDO1 5
+#define TPS65911_REG_LDO2 6
+#define TPS65911_REG_LDO3 7
+#define TPS65911_REG_LDO4 8
+#define TPS65911_REG_LDO5 9
+#define TPS65911_REG_LDO6 10
+#define TPS65911_REG_LDO7 11
+#define TPS65911_REG_LDO8 12
+
/**
* struct tps65910_board
* Board platform data may be used to initialize regulators.
--
1.7.5.4
^ permalink raw reply related
* Re: kdump: crash_kexec()-smp_send_stop() race in panic
From: Eric W. Biederman @ 2011-10-24 17:07 UTC (permalink / raw)
To: Américo Wang
Cc: heiko.carstens, kexec, linux-kernel, schwidefsky, akpm, holzheu,
Vivek Goyal
In-Reply-To: <CAM_iQpVktWsgOFCWoT47dQ1YdSTnnbTZAAKNYEEX=5wWzhHMzg@mail.gmail.com>
Américo Wang <xiyou.wangcong@gmail.com> writes:
> On Mon, Oct 24, 2011 at 11:14 PM, Eric W. Biederman
> <ebiederm@xmission.com> wrote:
>> Michael Holzheu <holzheu@linux.vnet.ibm.com> writes:
>>
>>> Hello Vivek,
>>>
>>> In our tests we ran into the following scenario:
>>>
>>> Two CPUs have called panic at the same time. The first CPU called
>>> crash_kexec() and the second CPU called smp_send_stop() in panic()
>>> before crash_kexec() finished on the first CPU. So the second CPU
>>> stopped the first CPU and therefore kdump failed.
>>>
>>> 1st CPU:
>>> panic()->crash_kexec()->mutex_trylock(&kexec_mutex)-> do kdump
>>>
>>> 2nd CPU:
>>> panic()->crash_kexec()->kexec_mutex already held by 1st CPU
>>> ->smp_send_stop()-> stop CPU 1 (stop kdump)
>>>
>>> How should we fix this problem? One possibility could be to do
>>> smp_send_stop() before we call crash_kexec().
>>>
>>> What do you think?
>>
>> smp_send_stop is insufficiently reliable to be used before crash_kexec.
>>
>> My first reaction would be to test oops_in_progress and wait until
>> oops_in_progress == 1 before calling smp_send_stop.
>>
>
> +1
>
> One of my colleague mentioned the same problem with me inside
> RH, given the fact that the race condition window is small, it would
> not be easy to reproduce this scenario.
As for reproducing it I have a hunch you could hack up something
horrible with smp_call_function and kprobes.
On a little more reflection we can't wait until oops_in_progress goes
to 1 before calling smp_send_stop. Because if crash_kexec is not
involved nothing we will never call smp_send_stop.
So my second thought is to introduce another atomic variable
panic_in_progress, visible only in panic. The cpu that sets
increments panic_in_progress can call smp_send_stop. The rest of
the cpus can just go into a busy wait. That should stop nasty
fights about who is going to come out of smp_send_stop first.
Eric
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply
* ceph on btrfs [was Re: ceph on non-btrfs file systems]
From: Sage Weil @ 2011-10-24 17:06 UTC (permalink / raw)
To: Christian Brunner; +Cc: ceph-devel, linux-btrfs
In-Reply-To: <CAO47_-9jp===DT=scpe=U8BnPnUCAVz7xUWVCC9AMVmx67CdaA@mail.gmail.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 6878 bytes --]
[adding linux-btrfs to cc]
Josef, Chris, any ideas on the below issues?
On Mon, 24 Oct 2011, Christian Brunner wrote:
> Thanks for explaining this. I don't have any objections against btrfs
> as a osd filesystem. Even the fact that there is no btrfs-fsck doesn't
> scare me, since I can use the ceph replication to recover a lost
> btrfs-filesystem. The only problem I have is, that btrfs is not stable
> on our side and I wonder what you are doing to make it work. (Maybe
> it's related to the load pattern of using ceph as a backend store for
> qemu).
>
> Here is a list of the btrfs problems I'm having:
>
> - When I run ceph with the default configuration (btrfs snaps enabled)
> I can see a rapid increase in Disk-I/O after a few hours of uptime.
> Btrfs-cleaner is using more and more time in
> btrfs_clean_old_snapshots().
In theory, there shouldn't be any significant difference between taking a
snapshot and removing it a few commits later, and the prior root refs that
btrfs holds on to internally until the new commit is complete. That's
clearly not quite the case, though.
In any case, we're going to try to reproduce this issue in our
environment.
> - When I run ceph with btrfs snaps disabled, the situation is getting
> slightly better. I can run an OSD for about 3 days without problems,
> but then again the load increases. This time, I can see that the
> ceph-osd (blkdev_issue_flush) and btrfs-endio-wri are doing more work
> than usual.
FYI in this scenario you're exposed to the same journal replay issues that
ext4 and XFS are. The btrfs workload that ceph is generating will also
not be all that special, though, so this problem shouldn't be unique to
ceph.
> Another thing is that I'm seeing a WARNING: at fs/btrfs/inode.c:2114
> from time to time. Maybe it's related to the performance issues, but
> seems to be able to verify this.
I haven't seen this yet with the latest stuff from Josef, but others have.
Josef, is there any information we can provide to help track it down?
> It's really sad to see, that ceph performance and stability is
> suffering that much from the underlying filesystems and that this
> hasn't changed over the last months.
We don't have anyone internally working on btrfs at the moment, and are
still struggling to hire experienced kernel/fs people. Josef has been
very helpful with tracking these issues down, but he hass responsibilities
beyond just the Ceph related issues. Progress is slow, but we are
working on it!
sage
>
> Kind regards,
> Christian
>
> 2011/10/24 Sage Weil <sage@newdream.net>:
> > Although running on ext4, xfs, or whatever other non-btrfs you want mostly
> > works, there are a few important remaining issues:
> >
> > 1- ext4 limits total xattrs for 4KB. This can cause problems in some
> > cases, as Ceph uses xattrs extensively. Most of the time we don't hit
> > this. We do hit the limit with radosgw pretty easily, though, and may
> > also hit it in exceptional cases where the OSD cluster is very unhealthy.
> >
> > There is a large xattr patch for ext4 from the Lustre folks that has been
> > floating around for (I think) years. Maybe as interest grows in running
> > Ceph on ext4 this can move upstream.
> >
> > Previously we were being forgiving about large setxattr failures on ext3,
> > but we found that was leading to corruption in certain cases (because we
> > couldn't set our internal metadata), so the next release will assert/crash
> > in that case (fail-stop instead of fail-maybe-eventually-corrupt).
> >
> > XFS does not have an xattr size limit and thus does have this problem.
> >
> > 2- The other problem is with OSD journal replay of non-idempotent
> > transactions. On non-btrfs backends, the Ceph OSDs use a write-ahead
> > journal. After restart, the OSD does not know exactly which transactions
> > in the journal may have already been committed to disk, and may reapply a
> > transaction again during replay. For most operations (write, delete,
> > truncate) this is fine.
> >
> > Some operations, though, are non-idempotent. The simplest example is
> > CLONE, which copies (efficiently, on btrfs) data from one object to
> > another. If the source object is modified, the osd restarts, and then
> > the clone is replayed, the target will get incorrect (newer) data. For
> > example,
> >
> > 1- clone A -> B
> > 2- modify A
> > <osd crash, replay from 1>
> >
> > B will get new instead of old contents.
> >
> > (This doesn't happen on btrfs because the snapshots allow us to replay
> > from a known consistent point in time.)
> >
> > For things like clone, skipping the operation of the target exists almost
> > works, except for cases like
> >
> > 1- clone A -> B
> > 2- modify A
> > ...
> > 3- delete B
> > <osd crash, replay from 1>
> >
> > (Although in that example who cares if B had bad data; it was removed
> > anyway.) The larger problem, though, is that that doesn't always work;
> > CLONERANGE copies a range of a file from A to B, where B may already
> > exist.
> >
> > In practice, the higher level interfaces don't make full use of the
> > low-level interface, so it's possible some solution exists that careful
> > avoids the problem with a partial solution in the lower layer. This makes
> > me nervous, though, as it is easy to break.
> >
> > Another possibility:
> >
> > - on non-btrfs, we set a xattr on every modified object with the
> > op_seq, the unique sequence number for the transaction.
> > - for any (potentially) non-idempotent operation, we fsync() before
> > continuing to the next transaction, to ensure that xattr hits disk.
> > - on replay, we skip a transaction if the xattr indicates we already
> > performed this transaction.
> >
> > Because every 'transaction' only modifies on a single object (file),
> > this ought to work. It'll make things like clone slow, but let's face it:
> > they're already slow on non-btrfs file systems because they actually copy
> > the data (instead of duplicating the extent refs in btrfs). And it should
> > make the full ObjectStore iterface safe, without upper layers having to
> > worry about the kinds and orders of transactions they perform.
> >
> > Other ideas?
> >
> > This issue is tracked at http://tracker.newdream.net/issues/213.
> >
> > sage
> >
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
> >
> --
> To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
>
^ permalink raw reply
* Re: kdump: crash_kexec()-smp_send_stop() race in panic
From: Eric W. Biederman @ 2011-10-24 17:07 UTC (permalink / raw)
To: Américo Wang
Cc: holzheu, Vivek Goyal, akpm, schwidefsky, heiko.carstens, kexec,
linux-kernel
In-Reply-To: <CAM_iQpVktWsgOFCWoT47dQ1YdSTnnbTZAAKNYEEX=5wWzhHMzg@mail.gmail.com>
Américo Wang <xiyou.wangcong@gmail.com> writes:
> On Mon, Oct 24, 2011 at 11:14 PM, Eric W. Biederman
> <ebiederm@xmission.com> wrote:
>> Michael Holzheu <holzheu@linux.vnet.ibm.com> writes:
>>
>>> Hello Vivek,
>>>
>>> In our tests we ran into the following scenario:
>>>
>>> Two CPUs have called panic at the same time. The first CPU called
>>> crash_kexec() and the second CPU called smp_send_stop() in panic()
>>> before crash_kexec() finished on the first CPU. So the second CPU
>>> stopped the first CPU and therefore kdump failed.
>>>
>>> 1st CPU:
>>> panic()->crash_kexec()->mutex_trylock(&kexec_mutex)-> do kdump
>>>
>>> 2nd CPU:
>>> panic()->crash_kexec()->kexec_mutex already held by 1st CPU
>>> ->smp_send_stop()-> stop CPU 1 (stop kdump)
>>>
>>> How should we fix this problem? One possibility could be to do
>>> smp_send_stop() before we call crash_kexec().
>>>
>>> What do you think?
>>
>> smp_send_stop is insufficiently reliable to be used before crash_kexec.
>>
>> My first reaction would be to test oops_in_progress and wait until
>> oops_in_progress == 1 before calling smp_send_stop.
>>
>
> +1
>
> One of my colleague mentioned the same problem with me inside
> RH, given the fact that the race condition window is small, it would
> not be easy to reproduce this scenario.
As for reproducing it I have a hunch you could hack up something
horrible with smp_call_function and kprobes.
On a little more reflection we can't wait until oops_in_progress goes
to 1 before calling smp_send_stop. Because if crash_kexec is not
involved nothing we will never call smp_send_stop.
So my second thought is to introduce another atomic variable
panic_in_progress, visible only in panic. The cpu that sets
increments panic_in_progress can call smp_send_stop. The rest of
the cpus can just go into a busy wait. That should stop nasty
fights about who is going to come out of smp_send_stop first.
Eric
^ permalink raw reply
* [PATCH v2 6/6] mfd: TPS65910: Create an array for reg init data
From: Kyle Manna @ 2011-10-24 17:06 UTC (permalink / raw)
To: linux-kernel, Samuel Ortiz
Cc: Jorge Eduardo Candelaria, Mark Brown, Liam Girdwood, Kyle Manna
In-Reply-To: <1319475964-10841-1-git-send-email-kyle.manna@fuel7.com>
Create an array of fixed size for the platform to pass regulator
initalization data through.
Passing an array of pointers to init data also allows more flexible
definition of init data as well as prevents reading past the end of the
array should the platform define an incorrectly sized array.
Signed-off-by: Kyle Manna <kyle.manna@fuel7.com>
---
drivers/regulator/tps65910-regulator.c | 13 ++++++++++---
include/linux/mfd/tps65910.h | 5 ++++-
2 files changed, 14 insertions(+), 4 deletions(-)
diff --git a/drivers/regulator/tps65910-regulator.c b/drivers/regulator/tps65910-regulator.c
index 44b4f22..a620e25 100644
--- a/drivers/regulator/tps65910-regulator.c
+++ b/drivers/regulator/tps65910-regulator.c
@@ -861,8 +861,6 @@ static __devinit int tps65910_probe(struct platform_device *pdev)
if (!pmic_plat_data)
return -EINVAL;
- reg_data = pmic_plat_data->tps65910_pmic_init_data;
-
pmic = kzalloc(sizeof(*pmic), GFP_KERNEL);
if (!pmic)
return -ENOMEM;
@@ -913,7 +911,16 @@ static __devinit int tps65910_probe(struct platform_device *pdev)
goto err_free_info;
}
- for (i = 0; i < pmic->num_regulators; i++, info++, reg_data++) {
+ for (i = 0; i < pmic->num_regulators && i < TPS65910_NUM_REGS;
+ i++, info++) {
+
+ reg_data = pmic_plat_data->tps65910_pmic_init_data[i];
+
+ /* Regulator API handles empty constraints but not NULL
+ * constraints */
+ if (!reg_data)
+ continue;
+
/* Register the regulators */
pmic->info[i] = info;
diff --git a/include/linux/mfd/tps65910.h b/include/linux/mfd/tps65910.h
index 84108bb..207b8b2 100644
--- a/include/linux/mfd/tps65910.h
+++ b/include/linux/mfd/tps65910.h
@@ -771,6 +771,9 @@
#define TPS65911_REG_LDO7 11
#define TPS65911_REG_LDO8 12
+/* Max number of TPS65910/11 regulators */
+#define TPS65910_NUM_REGS 13
+
/**
* struct tps65910_board
* Board platform data may be used to initialize regulators.
@@ -782,7 +785,7 @@ struct tps65910_board {
int irq_base;
int vmbch_threshold;
int vmbch2_threshold;
- struct regulator_init_data *tps65910_pmic_init_data;
+ struct regulator_init_data *tps65910_pmic_init_data[TPS65910_NUM_REGS];
};
/**
--
1.7.5.4
^ permalink raw reply related
* [PATCH v2 3/6] mfd: TPS65910: Fix typo that clobbers genirq
From: Kyle Manna @ 2011-10-24 17:06 UTC (permalink / raw)
To: linux-kernel, Samuel Ortiz
Cc: Jorge Eduardo Candelaria, Mark Brown, Liam Girdwood, Kyle Manna
In-Reply-To: <1319475964-10841-1-git-send-email-kyle.manna@fuel7.com>
Fix a typo that clobbers other interrupts in an unobvious way.
Signed-off-by: Kyle Manna <kyle.manna@fuel7.com>
---
drivers/mfd/tps65910.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/mfd/tps65910.c b/drivers/mfd/tps65910.c
index 03fb4a7..f4654d5 100644
--- a/drivers/mfd/tps65910.c
+++ b/drivers/mfd/tps65910.c
@@ -175,7 +175,7 @@ static int tps65910_i2c_probe(struct i2c_client *i2c,
goto err2;
init_data->irq = pmic_plat_data->irq;
- init_data->irq_base = pmic_plat_data->irq;
+ init_data->irq_base = pmic_plat_data->irq_base;
tps65910_gpio_init(tps65910, pmic_plat_data->gpio_base);
--
1.7.5.4
^ permalink raw reply related
* [PATCH v2 0/6] mfd: TPS65910: Bug fixes and enhancements
From: Kyle Manna @ 2011-10-24 17:05 UTC (permalink / raw)
To: linux-kernel, Samuel Ortiz
Cc: Jorge Eduardo Candelaria, Mark Brown, Liam Girdwood, Kyle Manna
This series of patches fixes a number of small problems with the TPS65910 that
were discovered on a custom board.
Additionally, the last patch enhances the platform to driver interface.
Changes from v1 based on feedback from Mark Brown:
* Drop the patch #5 from pervious series. It worked around a bug created by
another patch.
* Rework patch #6 completely.
[1] https://lkml.org/lkml/2011/10/19/182
[2] https://lkml.org/lkml/2011/10/19/191
Kyle Manna (6):
mfd: TPS65910: Handle non-existent devices
mfd: TPS65910: Add I2C slave address macros
mfd: TPS65910: Fix typo that clobbers genirq
mfd: TPS65910: Move linux/gpio.h include to header
mfd: TPS65910: Move regulator defs to header
mfd: TPS65910: Create an array for reg init data
drivers/mfd/tps65910.c | 23 +++++++++++++-------
drivers/regulator/tps65910-regulator.c | 37 ++++++++-----------------------
include/linux/mfd/tps65910.h | 37 +++++++++++++++++++++++++++++++-
3 files changed, 61 insertions(+), 36 deletions(-)
--
1.7.5.4
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.