* New location of powerpc git tree
From: Benjamin Herrenschmidt @ 2011-11-06 23:29 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Stephen Rothwell
Hi folks !
I've moved the powerpc git tree back to kernel.org. The URL should be
back to normal for users:
git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc.git
I've only uploaded the next and merge branches for now (merge is stale
btw, it's just there to avoid breaking scripts).
Note: Ignore the "linux-powerpc.git" tree that's next to that one, it's
a mistake and I haven't manage to delete it just yet...
Cheers,
Ben.
^ permalink raw reply
* Re: linux-next: failing to fetch the acpi tree
From: Len Brown @ 2011-11-06 23:26 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linux-next, linux-kernel
In-Reply-To: <20111107095429.28cb33a8ec512a2bd7690dba@canb.auug.org.au>
> I am still fetching from git://github.com/lenb/linux.git#acpi, is that correct?
Hi Stephen,
wow -- what was fast, I just nuked that branch about 30 minutes ago:-)
Please delete my github tree from your linux-next script
and start using this one:
git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux.git next
This "next" branch will be the consolidation of what used to be
acpi-test
idle-test
tools
and whatever other power management trees I used to have for linux-next.
BTW. At this instant the new branch is empty, while I do my own testing.
thanks,
-Len
^ permalink raw reply
* Re: useradd changes to dbus, base-passwd
From: Scott Garman @ 2011-11-06 23:16 UTC (permalink / raw)
To: Eric Bénard; +Cc: Patches and discussions about the oe-core layer
In-Reply-To: <4EB6EE8E.4000401@eukrea.com>
On 11/06/2011 12:31 PM, Eric Bénard wrote:
> Hi Scott,
>
> Le 26/10/2011 18:52, Scott Garman a écrit :
>> Grepping through our classes, it looks like I can detect the nativesdk
>> within
>> useradd.bbclass by checking for bb.data.inherits_class('nativesdk', d).
>>
>> I've filed a bug for this and will develop a patch to ensure useradd is
>> becomes a no-op for nativesdk builds:
>>
>> http://bugzilla.pokylinux.org/show_bug.cgi?id=1702
>>
> here is a patch tentative which allowed me to compile meta-toolchain-qte.
> Is that the right way to solve the problem (in which case I'll submit
> the patch with comment & sob)?
Hi Eric,
This looks good, thank you! Two questions though:
When I was testing my own variation of this fix out, I found that
testing bb.data.inherits_class('nativesdk', d) did not work as I
expected. It returned false for a recipe I was testing with that used
BBCLASSEXTEND = "native nativesdk". So instead I was checking if PN
ended with -nativesdk. Are you certain the inherits_class test works?
My second question is why the autotools_do_install is needed for the
nativesdk case?
Thanks,
Scott
--
Scott Garman
Embedded Linux Engineer - Yocto Project
Intel Open Source Technology Center
^ permalink raw reply
* Re: [PATCH] ext4: fix NULL pointer dereference from orig_data in fill_super and remount.
From: Srivatsa S. Bhat @ 2011-11-06 23:20 UTC (permalink / raw)
To: NamJae Jeon; +Cc: tytso, linux-kernel, linux-ext4
In-Reply-To: <CAKYAXd87ry6D4xsBwkXC4at6kDZgHu=_Qa+0kdhEsN=RSMk1ag@mail.gmail.com>
On 11/07/2011 04:43 AM, NamJae Jeon wrote:
> 2011/11/7 Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>:
>> On 11/06/2011 08:49 PM, Namjae Jeon wrote:
>>> Fix NULL pointer dereference from orig_data in fill_super and remount.
>>>
>>> Signed-off-by: Namjae Jeon <linkinjeon@gmail.com>
>>> ---
>>> fs/ext4/super.c | 12 ++++++++++--
>>> 1 files changed, 10 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/fs/ext4/super.c b/fs/ext4/super.c
>>> index 9953d80..3770d3f 100644
>>> --- a/fs/ext4/super.c
>>> +++ b/fs/ext4/super.c
>>> @@ -3102,7 +3102,6 @@ static int ext4_fill_super(struct super_block *sb, void *data, int silent)
>>> __releases(kernel_lock)
>>> __acquires(kernel_lock)
>>> {
>>> - char *orig_data = kstrdup(data, GFP_KERNEL);
>>> struct buffer_head *bh;
>>> struct ext4_super_block *es = NULL;
>>> struct ext4_sb_info *sbi;
>>> @@ -3124,6 +3123,10 @@ static int ext4_fill_super(struct super_block *sb, void *data, int silent)
>>> int err;
>>> unsigned int journal_ioprio = DEFAULT_JOURNAL_IOPRIO;
>>> ext4_group_t first_not_zeroed;
>>> +
>>> + char *orig_data = kstrdup(data, GFP_KERNEL);
>>> + if (!orig_data)
>>> + return ret;
>>>
>>> sbi = kzalloc(sizeof(*sbi), GFP_KERNEL);
>>> if (!sbi)
>>> @@ -4398,6 +4401,10 @@ static int ext4_remount(struct super_block *sb, int *flags, char *data)
>>> int i;
>>> #endif
>>> char *orig_data = kstrdup(data, GFP_KERNEL);
>>> + if (!orig_data) {
>>> + err = -ENOMEM;
>>> + goto failed_alloc_orig;
>>
>> I didn't quite get why 'failed_alloc_orig' is needed here.
>> Why can't we just return -ENOMEM? Anyway we haven't yet
>> clobbered any opts at this point, right?
>>
>> See my comments below.
>>
>>> + }
>>>
>>> /* Store the original options */
>>> lock_super(sb);
>>> @@ -4562,6 +4569,8 @@ static int ext4_remount(struct super_block *sb, int *flags, char *data)
>>> return 0;
>>>
>>> restore_opts:
>>> + kfree(orig_data);
>>> +failed_alloc_orig:
>>> sb->s_flags = old_sb_flags;
>>> sbi->s_mount_opt = old_opts.s_mount_opt;
>>> sbi->s_mount_opt2 = old_opts.s_mount_opt2;
>>
>> This would put garbage values in sb->... and sbi->... when we jump
>> to 'failed_alloc_orig' upon 'orig_data' allocation failure, because
>> the old_* variables were still uninitialized at that point.
>>
>>> @@ -4580,7 +4589,6 @@ restore_opts:
>>> }
>>> #endif
>>> unlock_super(sb);
>>> - kfree(orig_data);
>>> return err;
>>> }
>>>
>>
>> Thanks,
>> Srivatsa S. Bhat
> Hi.
> Thanks for your review. It's my mistake.
> I will post patch v2 after modifing again.
Sure. And please CC linux-ext4@vger.kernel.org for ext4 related patches.
Thanks,
Srivatsa S. Bhat
^ permalink raw reply
* Re: [Qemu-devel] [PATCH] KVM: Add wrapper script around QEMU to test kernels
From: Ted Ts'o @ 2011-11-06 23:19 UTC (permalink / raw)
To: Pekka Enberg
Cc: Alexander Graf, kvm@vger.kernel.org list, qemu-devel Developers,
linux-kernel@vger.kernel.org List, Blue Swirl, Avi Kivity,
Américo Wang, Ingo Molnar, Linus Torvalds
In-Reply-To: <CAOJsxLG6kyq-RoQiBj0B_tThvOy1AxJf6XB2VfQFQJkwQ5cHcQ@mail.gmail.com>
On Sun, Nov 06, 2011 at 08:58:20PM +0200, Pekka Enberg wrote:
> > Ted, I'm confused. Making backwards incompatible ABI changes has never
> > been on the table. Why are you bringing it up?
>
> And btw, KVM tool is not a random userspace project - it was designed
> to live in tools/kvm from the beginning. I've explained the technical
> rationale for sharing kernel code here:
>
> https://lkml.org/lkml/2011/11/4/150
>
> Please also see Ingo's original rant that started the project:
>
> http://thread.gmane.org/gmane.linux.kernel/962051/focus=962620
Because I don't buy any of these arguments. We have the same kernel
developers working on xfs and xfsprogs, ext4 and e2fsprogs, btrfs and
btrfsprogs, and we don't have those userspace projects in the kernel
source tree.
The only excuse I can see is a hope to make random changes to the
kernel and userspace tools without having to worry about compatibility
problems, which is an argument I've seen with perf (that you have to
use the same version of perf as the kernel version, which to me is bad
software engineering). And that's why I pointed out that you can't do
that with KVM, since we have out-of-tree userspace users, namely
qemu-kvm.
The rest of the arguments are arguments for a new effort, which is
fine --- but not an excuse for putting in the kernel source tree.
- Ted
^ permalink raw reply
* Re: [Qemu-devel] [PATCH] KVM: Add wrapper script around QEMU to test kernels
From: Ted Ts'o @ 2011-11-06 23:19 UTC (permalink / raw)
To: Pekka Enberg
Cc: Anthony Liguori, Avi Kivity, kvm@vger.kernel.org list,
linux-kernel@vger.kernel.org List, qemu-devel Developers,
Alexander Graf, Blue Swirl, Américo Wang, Ingo Molnar,
Linus Torvalds
In-Reply-To: <CAOJsxLG6kyq-RoQiBj0B_tThvOy1AxJf6XB2VfQFQJkwQ5cHcQ@mail.gmail.com>
On Sun, Nov 06, 2011 at 08:58:20PM +0200, Pekka Enberg wrote:
> > Ted, I'm confused. Making backwards incompatible ABI changes has never
> > been on the table. Why are you bringing it up?
>
> And btw, KVM tool is not a random userspace project - it was designed
> to live in tools/kvm from the beginning. I've explained the technical
> rationale for sharing kernel code here:
>
> https://lkml.org/lkml/2011/11/4/150
>
> Please also see Ingo's original rant that started the project:
>
> http://thread.gmane.org/gmane.linux.kernel/962051/focus=962620
Because I don't buy any of these arguments. We have the same kernel
developers working on xfs and xfsprogs, ext4 and e2fsprogs, btrfs and
btrfsprogs, and we don't have those userspace projects in the kernel
source tree.
The only excuse I can see is a hope to make random changes to the
kernel and userspace tools without having to worry about compatibility
problems, which is an argument I've seen with perf (that you have to
use the same version of perf as the kernel version, which to me is bad
software engineering). And that's why I pointed out that you can't do
that with KVM, since we have out-of-tree userspace users, namely
qemu-kvm.
The rest of the arguments are arguments for a new effort, which is
fine --- but not an excuse for putting in the kernel source tree.
- Ted
^ permalink raw reply
* G35 does not work after Xorg upgrade: Server 1.10.4 / intel module version = 2.15.901
From: Marc MERLIN @ 2011-11-06 22:38 UTC (permalink / raw)
To: intel-gfx
[-- Attachment #1: Type: text/plain, Size: 2412 bytes --]
I had it working for years with an older X/ubuntu and after upgrading
to Oneiric, Xorg says (EE) No devices detected
Relevant bits:
- kernel 3.0.1
- lspci
00:02.0 VGA compatible controller: Intel Corporation 82G35 Express Integrated Graphics Controller (rev 03)
04:00.0 Multimedia video controller: Internext Compression Inc iTVC15 MPEG-2 Encoder (rev 01)
- Xorg -verbose 3 -logverbose 3 says
X.Org X Server 1.10.4
Release Date: 2011-08-19
(--) PCI:*(0:0:2:0) 8086:2982:1043:8276 rev 3, Mem @ 0xfe800000/1048576,
0xd0000000/268435456, I/O @ 0x0000cc00/8
(--) PCI: (0:0:2:1) 8086:2983:1043:8276 rev 3, Mem @ 0xfe900000/1048576
(--) PCI: (0:4:0:0) 4444:0803:0070:4000 rev 1, Mem @ 0xf8000000/67108864
(II) Loading /usr/lib/xorg/modules/drivers/intel_drv.so
compiled for 1.10.2.902, module version = 2.15.901
Module class: X.Org Video Driver
ABI class: X.Org Video Driver, version 10.0
(II) intel: Driver for Intel Integrated Graphics Chipsets: i810,
i810-dc100, i810e, i815, i830M, 845G, 854, 852GM/855GM, 865G, 915G,
E7221 (i915), 915GM, 945G, 945GM, 945GME, Pineview GM, Pineview G,
965G, G35, 965Q, 946GZ, 965GM, 965GME/GLE, G33, Q35, Q33, GM45,
4 Series, G45/G43, Q45/Q43, G41, B43, B43, Clarkdale, Arrandale,
(...)
(EE) No devices detected.
lsmod says:
i915 299595 0
drm_kms_helper 23798 1 i915
drm 151068 2 i915,drm_kms_helper
fb 45826 2 i915,drm_kms_helper
cfbcopyarea 2745 1 i915
video 10546 1 i915
cfbimgblt 1860 1 i915
cfbfillrect 2545 1 i915
i2c_algo_bit 4040 3 i915,bttv,ivtv
intel_agp 8717 1 i915
intel_gtt 11246 3 i915,intel_agp
button 4102 1 i915
[drm] Initialized drm 1.1.0 20060810
pci 0000:00:02.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
pci 0000:00:02.0: setting latency timer to 64
[drm] Supports vblank timestamp caching Rev 1 (10.10.2010).
[drm] Driver supports precise vblank timestamp query.
[drm] Initialized i915 1.6.0 20080730 for 0000:00:02.0 on minor 0
Any idea what I'm missing?
Thanks,
Marc
--
"A mouse is a device used to point at the xterm you want to type in" - A.S.R.
Microsoft is to operating systems ....
.... what McDonalds is to gourmet cooking
Home page: http://marc.merlins.org/
[-- Attachment #2: Xorg.0.log --]
[-- Type: text/plain, Size: 6906 bytes --]
[ 2921.743]
X.Org X Server 1.10.4
Release Date: 2011-08-19
[ 2921.743] X Protocol Version 11, Revision 0
[ 2921.743] Build Operating System: Linux 2.6.24-29-server i686 Ubuntu
[ 2921.743] Current Operating System: Linux myth 3.0.1core2-volpreempt-noide-hm64-20110620 #1 SMP Thu Aug 11 10:57:21 PDT 2011 i686
[ 2921.743] Kernel command line: root=/dev/sda1 ro usbcore.autosuspend=1 snd_ac97_codec.power_save=1 acpi_irq_balance=0 nmi_watchdog=0 vga=1 nosplash
[ 2921.743] Build Date: 19 October 2011 05:09:41AM
[ 2921.743] xorg-server 2:1.10.4-1ubuntu4.2 (For technical support please see http://www.ubuntu.com/support)
[ 2921.743] Current version of pixman: 0.22.2
[ 2921.743] Before reporting problems, check http://wiki.x.org
to make sure that you have the latest version.
[ 2921.744] Markers: (--) probed, (**) from config file, (==) default setting,
(++) from command line, (!!) notice, (II) informational,
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
[ 2921.744] (==) Log file: "/var/log/Xorg.0.log", Time: Sun Nov 6 14:31:45 2011
[ 2921.744] (==) Using config file: "/etc/X11/xorg.conf"
[ 2921.744] (==) Using system config directory "/usr/share/X11/xorg.conf.d"
[ 2921.744] (==) ServerLayout "Default Layout"
[ 2921.744] (**) |-->Screen "Default Screen" (0)
[ 2921.744] (**) | |-->Monitor "<default monitor>"
[ 2921.745] (**) | |-->Device "Intel G35"
[ 2921.745] (==) No monitor specified for screen "Default Screen".
Using a default monitor configuration.
[ 2921.745] (**) |-->Input Device "Generic Keyboard"
[ 2921.745] (**) |-->Input Device "Generic Mouse"
[ 2921.745] (**) Option "AllowMouseOpenFail" "true"
[ 2921.745] (==) Automatically adding devices
[ 2921.745] (==) Automatically enabling devices
[ 2921.745] (WW) The directory "/usr/share/fonts/X11/cyrillic" does not exist.
[ 2921.745] Entry deleted from font path.
[ 2921.745] (==) FontPath set to:
/usr/share/fonts/X11/misc,
/usr/share/fonts/X11/100dpi/:unscaled,
/usr/share/fonts/X11/75dpi/:unscaled,
/usr/share/fonts/X11/Type1,
/usr/share/fonts/X11/100dpi,
/usr/share/fonts/X11/75dpi,
/var/lib/defoma/x-ttcidfont-conf.d/dirs/TrueType,
built-ins
[ 2921.745] (==) ModulePath set to "/usr/lib/i386-linux-gnu/xorg/extra-modules,/usr/lib/xorg/extra-modules,/usr/lib/xorg/modules"
[ 2921.745] (WW) Hotplugging is on, devices using drivers 'kbd', 'mouse' or 'vmmouse' will be disabled.
[ 2921.745] (WW) Disabling Generic Keyboard
[ 2921.745] (WW) Disabling Generic Mouse
[ 2921.745] (II) Loader magic: 0x823ada0
[ 2921.745] (II) Module ABI versions:
[ 2921.745] X.Org ANSI C Emulation: 0.4
[ 2921.745] X.Org Video Driver: 10.0
[ 2921.745] X.Org XInput driver : 12.3
[ 2921.745] X.Org Server Extension : 5.0
[ 2921.747] (--) PCI:*(0:0:2:0) 8086:2982:1043:8276 rev 3, Mem @ 0xfe800000/1048576, 0xd0000000/268435456, I/O @ 0x0000cc00/8
[ 2921.747] (--) PCI: (0:0:2:1) 8086:2983:1043:8276 rev 3, Mem @ 0xfe900000/1048576
[ 2921.747] (--) PCI: (0:4:0:0) 4444:0803:0070:4000 rev 1, Mem @ 0xf8000000/67108864
[ 2921.747] (II) Open ACPI successful (/var/run/acpid.socket)
[ 2921.747] (II) LoadModule: "extmod"
[ 2921.747] (II) Loading /usr/lib/xorg/modules/extensions/libextmod.so
[ 2921.747] (II) Module extmod: vendor="X.Org Foundation"
[ 2921.747] compiled for 1.10.4, module version = 1.0.0
[ 2921.748] Module class: X.Org Server Extension
[ 2921.748] ABI class: X.Org Server Extension, version 5.0
[ 2921.748] (II) Loading extension MIT-SCREEN-SAVER
[ 2921.748] (II) Loading extension XFree86-VidModeExtension
[ 2921.748] (II) Loading extension XFree86-DGA
[ 2921.748] (II) Loading extension DPMS
[ 2921.748] (II) Loading extension XVideo
[ 2921.748] (II) Loading extension XVideo-MotionCompensation
[ 2921.748] (II) Loading extension X-Resource
[ 2921.748] (II) LoadModule: "dbe"
[ 2921.748] (II) Loading /usr/lib/xorg/modules/extensions/libdbe.so
[ 2921.748] (II) Module dbe: vendor="X.Org Foundation"
[ 2921.748] compiled for 1.10.4, module version = 1.0.0
[ 2921.748] Module class: X.Org Server Extension
[ 2921.748] ABI class: X.Org Server Extension, version 5.0
[ 2921.748] (II) Loading extension DOUBLE-BUFFER
[ 2921.748] (II) LoadModule: "glx"
[ 2921.749] (II) Loading /usr/lib/xorg/modules/extensions/libglx.so
[ 2921.749] (II) Module glx: vendor="X.Org Foundation"
[ 2921.749] compiled for 1.10.4, module version = 1.0.0
[ 2921.749] ABI class: X.Org Server Extension, version 5.0
[ 2921.749] (==) AIGLX enabled
[ 2921.749] (II) Loading extension GLX
[ 2921.749] (II) LoadModule: "record"
[ 2921.749] (II) Loading /usr/lib/xorg/modules/extensions/librecord.so
[ 2921.749] (II) Module record: vendor="X.Org Foundation"
[ 2921.749] compiled for 1.10.4, module version = 1.13.0
[ 2921.749] Module class: X.Org Server Extension
[ 2921.749] ABI class: X.Org Server Extension, version 5.0
[ 2921.749] (II) Loading extension RECORD
[ 2921.749] (II) LoadModule: "dri"
[ 2921.750] (II) Loading /usr/lib/xorg/modules/extensions/libdri.so
[ 2921.750] (II) Module dri: vendor="X.Org Foundation"
[ 2921.750] compiled for 1.10.4, module version = 1.0.0
[ 2921.750] ABI class: X.Org Server Extension, version 5.0
[ 2921.750] (II) Loading extension XFree86-DRI
[ 2921.750] (II) LoadModule: "dri2"
[ 2921.750] (II) Loading /usr/lib/xorg/modules/extensions/libdri2.so
[ 2921.750] (II) Module dri2: vendor="X.Org Foundation"
[ 2921.750] compiled for 1.10.4, module version = 1.2.0
[ 2921.750] ABI class: X.Org Server Extension, version 5.0
[ 2921.750] (II) Loading extension DRI2
[ 2921.750] (II) LoadModule: "intel"
[ 2921.750] (II) Loading /usr/lib/xorg/modules/drivers/intel_drv.so
[ 2921.750] (II) Module intel: vendor="X.Org Foundation"
[ 2921.750] compiled for 1.10.2.902, module version = 2.15.901
[ 2921.750] Module class: X.Org Video Driver
[ 2921.750] ABI class: X.Org Video Driver, version 10.0
[ 2921.750] (II) intel: Driver for Intel Integrated Graphics Chipsets: i810,
i810-dc100, i810e, i815, i830M, 845G, 854, 852GM/855GM, 865G, 915G,
E7221 (i915), 915GM, 945G, 945GM, 945GME, Pineview GM, Pineview G,
965G, G35, 965Q, 946GZ, 965GM, 965GME/GLE, G33, Q35, Q33, GM45,
4 Series, G45/G43, Q45/Q43, G41, B43, B43, Clarkdale, Arrandale,
Sandybridge Desktop (GT1), Sandybridge Desktop (GT2),
Sandybridge Desktop (GT2+), Sandybridge Mobile (GT1),
Sandybridge Mobile (GT2), Sandybridge Mobile (GT2+),
Sandybridge Server, Ivybridge Mobile (GT1), Ivybridge Mobile (GT2),
Ivybridge Desktop (GT1), Ivybridge Desktop (GT2), Ivybridge Server
[ 2921.751] (--) using VT number 8
[ 2921.755] (EE) No devices detected.
[ 2921.755]
Fatal server error:
[ 2921.755] no screens found
[ 2921.755]
Please consult the The X.Org Foundation support
at http://wiki.x.org
for help.
[ 2921.755] Please also check the log file at "/var/log/Xorg.0.log" for additional information.
[ 2921.755]
[-- Attachment #3: xorg.conf --]
[-- Type: text/plain, Size: 3113 bytes --]
# xorg.conf (X.Org X Window System server configuration file)
#
# This file was generated by dexconf, the Debian X Configuration tool, using
# values from the debconf database.
#
# Edit this file with caution, and see the xorg.conf manual page.
# (Type "man xorg.conf" at the shell prompt.)
#
# This file is automatically updated on xserver-xorg package upgrades *only*
# if it has not been modified since the last upgrade of the xserver-xorg
# package.
#
# If you have edited this file but would like it to be automatically updated
# again, run the following command:
# sudo dpkg-reconfigure -phigh xserver-xorg
#Section "Module"
# Load "glx"
# Load "GLcore"
# Load "dri"
## Load "v4l"
#EndSection
Section "ServerFlags"
Option "AllowMouseOpenFail" "true"
EndSection
Section "Device"
Identifier "Intel G35"
Boardname "Intel DG35EC"
Busid "PCI:0:2:0"
Driver "intel"
Screen 0
Vendorname "Intel"
EndSection
Section "Monitor"
Identifier "Aquos"
Vendorname "Sharp Aquos 52"
Modelname "LCD Panel 1920x1080"
VertRefresh 60
#VertRefresh 50.0 - 75.0
HorizSync 30.0 - 120
#Modeline "1080p" 148.50 1920 2448 2492 2640 1080 1084 1089 1125 +hsync +vsync
ModeLine "1080p" 148.5 1920 1960 2016 2200 1080 1082 1088 1125
#Option "DDC" "no"
Option "DPMS" "true"
# all this shit looks ignored, I had to force -dpi 100 in gdm.conf
#DisplaySize 1102 620
Option "UseEdidDpi" "false"
Option "DPI" "100 x 100"
Option "PreferredMode" "1080p"
Gamma 1.0
EndSection
Section "Screen"
Identifier "Default Screen"
Monitor "TDMS-1"
Device "Intel G35"
Defaultdepth 24
SubSection "Display"
Depth 24
Modes "1080p" "1920x1080"
EndSubSection
Option "UseEdidFreqs" "false"
Option "ModeValidation" "NoMaxPClkCheck"
Option "ModeValidation" "AllowNon60HzDFPModes"
Option "ModeValidation" "NoVesaModes"
Option "ModeValidation" "NoXServerModes"
Option "ModeValidation" "NoPredefinedModes"
Option "ModeValidation" "NoEdidDFPMaxSizeCheck"
Option "ModeValidation" "NoDFPNativeResolutionCheck"
EndSection
Section "ServerLayout"
Identifier "Default Layout"
screen 0 "Default Screen" 0 0
InputDevice "Generic Keyboard" "CoreKeyboard"
InputDevice "Generic Mouse" "AlwaysCore"
EndSection
Section "InputDevice"
Identifier "Generic Keyboard"
Driver "kbd"
Option "XkbRules" "xorg"
Option "XkbModel" "pc105"
Option "XkbLayout" "us"
EndSection
Section "InputDevice"
Identifier "Generic Mouse"
Driver "mouse"
Option "CorePointer"
EndSection
Section "DRI"
Mode 0666
EndSection
[-- Attachment #4: Type: text/plain, Size: 159 bytes --]
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply
* [PATCH] rtl8192e: Don't copy huge struct by value (and make it const).
From: Jesper Juhl @ 2011-11-06 23:21 UTC (permalink / raw)
To: devel, linux-kernel
Cc: Andrea Merello, Mike McCormack, Larry Finger, Greg Kroah-Hartman,
netdev
rtllib_is_shortslot() takes one argument - a struct that's more than a
kilobyte large. It should take a pointer instead of copying such a
huge struct - and the argument might as well be declared 'const' now
that we are at it, since it is not modified. This patch makes these
changes.
Signed-off-by: Jesper Juhl <jj@chaosbits.net>
---
drivers/staging/rtl8192e/rtllib.h | 2 +-
drivers/staging/rtl8192e/rtllib_softmac.c | 4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/rtl8192e/rtllib.h b/drivers/staging/rtl8192e/rtllib.h
index de25975..3a52120 100644
--- a/drivers/staging/rtl8192e/rtllib.h
+++ b/drivers/staging/rtl8192e/rtllib.h
@@ -2804,7 +2804,7 @@ extern int rtllib_wx_set_gen_ie(struct rtllib_device *ieee, u8 *ie, size_t len);
/* rtllib_softmac.c */
extern short rtllib_is_54g(struct rtllib_network *net);
-extern short rtllib_is_shortslot(struct rtllib_network net);
+extern short rtllib_is_shortslot(const struct rtllib_network *net);
extern int rtllib_rx_frame_softmac(struct rtllib_device *ieee,
struct sk_buff *skb,
struct rtllib_rx_stats *rx_stats, u16 type,
diff --git a/drivers/staging/rtl8192e/rtllib_softmac.c b/drivers/staging/rtl8192e/rtllib_softmac.c
index b508685..fa774cf 100644
--- a/drivers/staging/rtl8192e/rtllib_softmac.c
+++ b/drivers/staging/rtl8192e/rtllib_softmac.c
@@ -28,9 +28,9 @@ short rtllib_is_54g(struct rtllib_network *net)
return (net->rates_ex_len > 0) || (net->rates_len > 4);
}
-short rtllib_is_shortslot(struct rtllib_network net)
+short rtllib_is_shortslot(const struct rtllib_network *net)
{
- return net.capability & WLAN_CAPABILITY_SHORT_SLOT_TIME;
+ return net->capability & WLAN_CAPABILITY_SHORT_SLOT_TIME;
}
/* returns the total length needed for pleacing the RATE MFIE
--
1.7.7.2
--
Jesper Juhl <jj@chaosbits.net> http://www.chaosbits.net/
Don't top-post http://www.catb.org/jargon/html/T/top-post.html
Plain text mails only, please.
^ permalink raw reply related
* [PATCH] regulator: Use regmap_read/write(), regmap_update_bits functions directly
From: jhbird.choi at samsung.com @ 2011-11-06 23:16 UTC (permalink / raw)
To: linux-arm-kernel
From: Jonghwan Choi <jhbird.choi@samsung.com>
Current driver had the regmapcalls within the bodies of the driver specific read/write fuctions.
This patch removes the original read/write functions and makes the call sites use regmap directly.
Signed-off-by: Jonghwan Choi <jhbird.choi@samsung.com>
---
drivers/regulator/tps65023-regulator.c | 87 ++++++++++++--------------------
1 files changed, 32 insertions(+), 55 deletions(-)
diff --git a/drivers/regulator/tps65023-regulator.c b/drivers/regulator/tps65023-regulator.c
index 9fb4c7b..e0bcd75 100644
--- a/drivers/regulator/tps65023-regulator.c
+++ b/drivers/regulator/tps65023-regulator.c
@@ -152,48 +152,21 @@ struct tps_driver_data {
u8 core_regulator;
};
-static int tps_65023_set_bits(struct tps_pmic *tps, u8 reg, u8 mask)
-{
- return regmap_update_bits(tps->regmap, reg, mask, mask);
-}
-
-static int tps_65023_clear_bits(struct tps_pmic *tps, u8 reg, u8 mask)
-{
- return regmap_update_bits(tps->regmap, reg, mask, 0);
-}
-
-static int tps_65023_reg_read(struct tps_pmic *tps, u8 reg)
-{
- unsigned int val;
- int ret;
-
- ret = regmap_read(tps->regmap, reg, &val);
-
- if (ret != 0)
- return ret;
- else
- return val;
-}
-
-static int tps_65023_reg_write(struct tps_pmic *tps, u8 reg, u8 val)
-{
- return regmap_write(tps->regmap, reg, val);
-}
-
static int tps65023_dcdc_is_enabled(struct regulator_dev *dev)
{
struct tps_pmic *tps = rdev_get_drvdata(dev);
int data, dcdc = rdev_get_id(dev);
+ int ret;
u8 shift;
if (dcdc < TPS65023_DCDC_1 || dcdc > TPS65023_DCDC_3)
return -EINVAL;
shift = TPS65023_NUM_REGULATOR - dcdc;
- data = tps_65023_reg_read(tps, TPS65023_REG_REG_CTRL);
+ ret = regmap_read(tps->regmap, TPS65023_REG_REG_CTRL, &data);
- if (data < 0)
- return data;
+ if (ret != 0)
+ return ret;
else
return (data & 1<<shift) ? 1 : 0;
}
@@ -202,16 +175,17 @@ static int tps65023_ldo_is_enabled(struct regulator_dev *dev)
{
struct tps_pmic *tps = rdev_get_drvdata(dev);
int data, ldo = rdev_get_id(dev);
+ int ret;
u8 shift;
if (ldo < TPS65023_LDO_1 || ldo > TPS65023_LDO_2)
return -EINVAL;
shift = (ldo == TPS65023_LDO_1 ? 1 : 2);
- data = tps_65023_reg_read(tps, TPS65023_REG_REG_CTRL);
+ ret = regmap_read(tps->regmap, TPS65023_REG_REG_CTRL, &data);
- if (data < 0)
- return data;
+ if (ret != 0)
+ return ret;
else
return (data & 1<<shift) ? 1 : 0;
}
@@ -226,7 +200,7 @@ static int tps65023_dcdc_enable(struct regulator_dev *dev)
return -EINVAL;
shift = TPS65023_NUM_REGULATOR - dcdc;
- return tps_65023_set_bits(tps, TPS65023_REG_REG_CTRL, 1 << shift);
+ return regmap_update_bits(tps->regmap, TPS65023_REG_REG_CTRL, 1 << shift, 1 << shift);
}
static int tps65023_dcdc_disable(struct regulator_dev *dev)
@@ -239,7 +213,7 @@ static int tps65023_dcdc_disable(struct regulator_dev *dev)
return -EINVAL;
shift = TPS65023_NUM_REGULATOR - dcdc;
- return tps_65023_clear_bits(tps, TPS65023_REG_REG_CTRL, 1 << shift);
+ return regmap_update_bits(tps->regmap, TPS65023_REG_REG_CTRL, 1 << shift, 0);
}
static int tps65023_ldo_enable(struct regulator_dev *dev)
@@ -252,7 +226,7 @@ static int tps65023_ldo_enable(struct regulator_dev *dev)
return -EINVAL;
shift = (ldo == TPS65023_LDO_1 ? 1 : 2);
- return tps_65023_set_bits(tps, TPS65023_REG_REG_CTRL, 1 << shift);
+ return regmap_update_bits(tps->regmap, TPS65023_REG_REG_CTRL, 1 << shift, 1 << shift);
}
static int tps65023_ldo_disable(struct regulator_dev *dev)
@@ -265,21 +239,22 @@ static int tps65023_ldo_disable(struct regulator_dev *dev)
return -EINVAL;
shift = (ldo == TPS65023_LDO_1 ? 1 : 2);
- return tps_65023_clear_bits(tps, TPS65023_REG_REG_CTRL, 1 << shift);
+ return regmap_update_bits(tps->regmap, TPS65023_REG_REG_CTRL, 1 << shift, 0);
}
static int tps65023_dcdc_get_voltage(struct regulator_dev *dev)
{
struct tps_pmic *tps = rdev_get_drvdata(dev);
+ int ret;
int data, dcdc = rdev_get_id(dev);
if (dcdc < TPS65023_DCDC_1 || dcdc > TPS65023_DCDC_3)
return -EINVAL;
if (dcdc == tps->core_regulator) {
- data = tps_65023_reg_read(tps, TPS65023_REG_DEF_CORE);
- if (data < 0)
- return data;
+ ret = regmap_read(tps->regmap, TPS65023_REG_DEF_CORE, &data);
+ if (ret != 0)
+ return ret;
data &= (tps->info[dcdc]->table_len - 1);
return tps->info[dcdc]->table[data] * 1000;
} else
@@ -318,13 +293,13 @@ static int tps65023_dcdc_set_voltage(struct regulator_dev *dev,
if (vsel == tps->info[dcdc]->table_len)
goto failed;
- ret = tps_65023_reg_write(tps, TPS65023_REG_DEF_CORE, vsel);
+ ret = regmap_write(tps->regmap, TPS65023_REG_DEF_CORE, vsel);
/* Tell the chip that we have changed the value in DEFCORE
* and its time to update the core voltage
*/
- tps_65023_set_bits(tps, TPS65023_REG_CON_CTRL2,
- TPS65023_REG_CTRL2_GO);
+ regmap_update_bits(tps->regmap, TPS65023_REG_CON_CTRL2,
+ TPS65023_REG_CTRL2_GO, TPS65023_REG_CTRL2_GO);
return ret;
@@ -336,13 +311,14 @@ static int tps65023_ldo_get_voltage(struct regulator_dev *dev)
{
struct tps_pmic *tps = rdev_get_drvdata(dev);
int data, ldo = rdev_get_id(dev);
+ int ret;
if (ldo < TPS65023_LDO_1 || ldo > TPS65023_LDO_2)
return -EINVAL;
- data = tps_65023_reg_read(tps, TPS65023_REG_LDO_CTRL);
- if (data < 0)
- return data;
+ ret = regmap_read(tps->regmap, TPS65023_REG_LDO_CTRL, &data);
+ if (ret != 0)
+ return ret;
data >>= (TPS65023_LDO_CTRL_LDOx_SHIFT(ldo - TPS65023_LDO_1));
data &= (tps->info[ldo]->table_len - 1);
@@ -354,6 +330,7 @@ static int tps65023_ldo_set_voltage(struct regulator_dev *dev,
{
struct tps_pmic *tps = rdev_get_drvdata(dev);
int data, vsel, ldo = rdev_get_id(dev);
+ int ret;
if (ldo < TPS65023_LDO_1 || ldo > TPS65023_LDO_2)
return -EINVAL;
@@ -377,13 +354,13 @@ static int tps65023_ldo_set_voltage(struct regulator_dev *dev,
*selector = vsel;
- data = tps_65023_reg_read(tps, TPS65023_REG_LDO_CTRL);
- if (data < 0)
- return data;
+ ret = regmap_read(tps->regmap, TPS65023_REG_LDO_CTRL, &data);
+ if (ret != 0)
+ return ret;
data &= TPS65023_LDO_CTRL_LDOx_MASK(ldo - TPS65023_LDO_1);
data |= (vsel << (TPS65023_LDO_CTRL_LDOx_SHIFT(ldo - TPS65023_LDO_1)));
- return tps_65023_reg_write(tps, TPS65023_REG_LDO_CTRL, data);
+ return regmap_write(tps->regmap, TPS65023_REG_LDO_CTRL, data);
}
static int tps65023_dcdc_list_voltage(struct regulator_dev *dev,
@@ -511,12 +488,12 @@ static int __devinit tps_65023_probe(struct i2c_client *client,
i2c_set_clientdata(client, tps);
/* Enable setting output voltage by I2C */
- tps_65023_clear_bits(tps, TPS65023_REG_CON_CTRL2,
- TPS65023_REG_CTRL2_CORE_ADJ);
+ regmap_update_bits(tps->regmap, TPS65023_REG_CON_CTRL2,
+ TPS65023_REG_CTRL2_CORE_ADJ, TPS65023_REG_CTRL2_CORE_ADJ);
/* Enable setting output voltage by I2C */
- tps_65023_clear_bits(tps, TPS65023_REG_CON_CTRL2,
- TPS65023_REG_CTRL2_CORE_ADJ);
+ regmap_update_bits(tps->regmap, TPS65023_REG_CON_CTRL2,
+ TPS65023_REG_CTRL2_CORE_ADJ, TPS65023_REG_CTRL2_CORE_ADJ);
return 0;
--
1.7.1
^ permalink raw reply related
* Re: [PATCH 1/1] useradd.bbclass: fix how RDEPENDS is setup
From: Scott Garman @ 2011-11-06 23:07 UTC (permalink / raw)
To: openembedded-core
In-Reply-To: <1320611116.3041.2.camel@lenovo.internal.reciva.com>
On 11/06/2011 12:25 PM, Phil Blundell wrote:
> On Sun, 2011-11-06 at 11:31 -0800, Scott Garman wrote:
>> Fix bug where only packages named PN included base-passwd in
>> RDEPENDS. Also remove shadow requirement, since some targets
>> do not use shadow and file ownership can be changed with only
>> passwd/group entries.
>>
>> This fixes [YOCTO #1727]
>
> Don't you need shadow or some equivalent to provide /sbin/useradd so
> that the postinsts work for on-target installs? Removing shadow from
> RDEPENDS does sound like a good plan for the no-package-management case,
> but I'm not sure it's safe otherwise.
Of course you're right. Thank you for pointing this out. I will spin a
v2 of the patchset.
Scott
--
Scott Garman
Embedded Linux Engineer - Yocto Project
Intel Open Source Technology Center
^ permalink raw reply
* Re: [PATCH] ext4: fix NULL pointer dereference from orig_data in fill_super and remount.
From: NamJae Jeon @ 2011-11-06 23:13 UTC (permalink / raw)
To: Srivatsa S. Bhat; +Cc: tytso, linux-kernel
In-Reply-To: <4EB6EF07.1070102@linux.vnet.ibm.com>
2011/11/7 Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>:
> On 11/06/2011 08:49 PM, Namjae Jeon wrote:
>> Fix NULL pointer dereference from orig_data in fill_super and remount.
>>
>> Signed-off-by: Namjae Jeon <linkinjeon@gmail.com>
>> ---
>> fs/ext4/super.c | 12 ++++++++++--
>> 1 files changed, 10 insertions(+), 2 deletions(-)
>>
>> diff --git a/fs/ext4/super.c b/fs/ext4/super.c
>> index 9953d80..3770d3f 100644
>> --- a/fs/ext4/super.c
>> +++ b/fs/ext4/super.c
>> @@ -3102,7 +3102,6 @@ static int ext4_fill_super(struct super_block *sb, void *data, int silent)
>> __releases(kernel_lock)
>> __acquires(kernel_lock)
>> {
>> - char *orig_data = kstrdup(data, GFP_KERNEL);
>> struct buffer_head *bh;
>> struct ext4_super_block *es = NULL;
>> struct ext4_sb_info *sbi;
>> @@ -3124,6 +3123,10 @@ static int ext4_fill_super(struct super_block *sb, void *data, int silent)
>> int err;
>> unsigned int journal_ioprio = DEFAULT_JOURNAL_IOPRIO;
>> ext4_group_t first_not_zeroed;
>> +
>> + char *orig_data = kstrdup(data, GFP_KERNEL);
>> + if (!orig_data)
>> + return ret;
>>
>> sbi = kzalloc(sizeof(*sbi), GFP_KERNEL);
>> if (!sbi)
>> @@ -4398,6 +4401,10 @@ static int ext4_remount(struct super_block *sb, int *flags, char *data)
>> int i;
>> #endif
>> char *orig_data = kstrdup(data, GFP_KERNEL);
>> + if (!orig_data) {
>> + err = -ENOMEM;
>> + goto failed_alloc_orig;
>
> I didn't quite get why 'failed_alloc_orig' is needed here.
> Why can't we just return -ENOMEM? Anyway we haven't yet
> clobbered any opts at this point, right?
>
> See my comments below.
>
>> + }
>>
>> /* Store the original options */
>> lock_super(sb);
>> @@ -4562,6 +4569,8 @@ static int ext4_remount(struct super_block *sb, int *flags, char *data)
>> return 0;
>>
>> restore_opts:
>> + kfree(orig_data);
>> +failed_alloc_orig:
>> sb->s_flags = old_sb_flags;
>> sbi->s_mount_opt = old_opts.s_mount_opt;
>> sbi->s_mount_opt2 = old_opts.s_mount_opt2;
>
> This would put garbage values in sb->... and sbi->... when we jump
> to 'failed_alloc_orig' upon 'orig_data' allocation failure, because
> the old_* variables were still uninitialized at that point.
>
>> @@ -4580,7 +4589,6 @@ restore_opts:
>> }
>> #endif
>> unlock_super(sb);
>> - kfree(orig_data);
>> return err;
>> }
>>
>
> Thanks,
> Srivatsa S. Bhat
Hi.
Thanks for your review. It's my mistake.
I will post patch v2 after modifing again.
>
>
^ permalink raw reply
* orion/kirkwood and device tree
From: Michael Walle @ 2011-11-06 23:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.LFD.2.02.1111041000060.3307@xanadu.home>
Am Freitag 04 November 2011, 15:01:43 schrieb Nicolas Pitre:
> On Thu, 3 Nov 2011, Michael Walle wrote:
> > yeah i had it there and it should be definitely put back to
> > kirkwood.dtsi. the reason i've put it into lschv2.dts atm is that there
> > is the clock property for every device, which may be different for
> > different platforms.
>
> The clock property should be a separate entity from the actual devices.
yes of course. the patches above are currently wip. i've only moved the
property from the platform_data to the dt device entry.
> In fact, that would be a good idea for Kirkwood and friends to move to
> the struck clk API.
yeah i saw that other platforms used that api.
--
michael
^ permalink raw reply
* linux-next: build failure after merge of the origin tree
From: Stephen Rothwell @ 2011-11-06 23:12 UTC (permalink / raw)
To: Linus Torvalds
Cc: linux-next, linux-kernel, Greg Rose, Jeff Kirsher, David Miller,
netdev
[-- Attachment #1: Type: text/plain, Size: 864 bytes --]
Hi Linus,
Starting with the origin tree, today's linux-next build (powerpc
ppc64_defconfig) failed like this:
drivers/net/ethernet/intel/ixgbe/ixgbe_main.c: In function 'ixgbe_set_interrupt_capability':
drivers/net/ethernet/intel/ixgbe/ixgbe_main.c:4724:3: error: implicit declaration of function 'ixgbe_disable_sriov'
drivers/net/ethernet/intel/ixgbe/ixgbe_main.c: In function 'ixgbe_remove':
drivers/net/ethernet/intel/ixgbe/ixgbe_main.c:7773:3: error: implicit declaration of function 'ixgbe_check_vf_assignment'
Caused by commit 9487dc844054 ("ixgbe: Fix compiler warnings") which hid
the declarations of ixgbe_disable_sriov() and ixgbe_check_vf_assignment()
when CONFIG_PCI_IOV is not defined.
I have reverted that commit for today.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* linux-next: build failure after merge of the origin tree
From: Stephen Rothwell @ 2011-11-06 23:12 UTC (permalink / raw)
To: Linus Torvalds
Cc: linux-next, linux-kernel, Greg Rose, Jeff Kirsher, David Miller,
netdev
[-- Attachment #1: Type: text/plain, Size: 864 bytes --]
Hi Linus,
Starting with the origin tree, today's linux-next build (powerpc
ppc64_defconfig) failed like this:
drivers/net/ethernet/intel/ixgbe/ixgbe_main.c: In function 'ixgbe_set_interrupt_capability':
drivers/net/ethernet/intel/ixgbe/ixgbe_main.c:4724:3: error: implicit declaration of function 'ixgbe_disable_sriov'
drivers/net/ethernet/intel/ixgbe/ixgbe_main.c: In function 'ixgbe_remove':
drivers/net/ethernet/intel/ixgbe/ixgbe_main.c:7773:3: error: implicit declaration of function 'ixgbe_check_vf_assignment'
Caused by commit 9487dc844054 ("ixgbe: Fix compiler warnings") which hid
the declarations of ixgbe_disable_sriov() and ixgbe_check_vf_assignment()
when CONFIG_PCI_IOV is not defined.
I have reverted that commit for today.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: Linux Route Cache performance tests
From: Eric Dumazet @ 2011-11-06 23:08 UTC (permalink / raw)
To: Paweł Staszewski; +Cc: Linux Network Development list
In-Reply-To: <4EB702D3.1090703@itcare.pl>
Le dimanche 06 novembre 2011 à 22:57 +0100, Paweł Staszewski a écrit :
> W dniu 2011-11-06 22:26, Eric Dumazet pisze:
> > Le dimanche 06 novembre 2011 à 21:25 +0100, Paweł Staszewski a écrit :
> >> Yes with this is a little problem i think with kernel 3.1 because
> >> dmesg | egrep '(rhash)|(route)'
> >> [ 0.000000] Command line: root=/dev/md2 rhash_entries=2097152
> >> [ 0.000000] Kernel command line: root=/dev/md2 rhash_entries=2097152
> >> [ 4.697294] IP route cache hash table entries: 524288 (order: 10,
> >> 4194304 bytes)
> >>
> >>
> > Dont tell me you _still_ use a 32bit kernel ?
> no it is 64bit :)
> Linux localhost 3.1.0 #16 SMP Sun Nov 6 18:09:48 CET 2011 x86_64 Intel(R)
> :)
>
> > If so, you need to tweak alloc_large_system_hash() to use vmalloc,
> > because you hit MAX_ORDER (10) page allocations.
> funny then :)
> Maybee i turned off too many kernel features
> > But considering LOWMEM is about 700 Mbytes, you wont be able to create a
> > lot of route cache entries.
> >
> > Come on, do us a favor, and enter new era of computing.
OK, then your kernel is not CONFIG_NUMA enabled
It seems strange given you probably have a NUMA machine (24 cpus)
If so, your choices are :
1) enable CONFIG_NUMA. Really this is a must given the workload of your
machine.
2) Or : you need to add "hashdist=1" on boot params
and patch your kernel with following patch :
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index 9dd443d..07f86e0 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -5362,7 +5362,6 @@ int percpu_pagelist_fraction_sysctl_handler(ctl_table *table, int write,
int hashdist = HASHDIST_DEFAULT;
-#ifdef CONFIG_NUMA
static int __init set_hashdist(char *str)
{
if (!str)
@@ -5371,7 +5370,6 @@ static int __init set_hashdist(char *str)
return 1;
}
__setup("hashdist=", set_hashdist);
-#endif
/*
* allocate a large system hash table from bootmem
^ permalink raw reply related
* [U-Boot] [PATCH] add a git mailrc file for maintainers
From: Mike Frysinger @ 2011-11-06 23:07 UTC (permalink / raw)
To: u-boot
This should make sending out e-mails to the right people easier.
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
---
doc/git-mailrc | 100 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 100 insertions(+), 0 deletions(-)
create mode 100644 doc/git-mailrc
diff --git a/doc/git-mailrc b/doc/git-mailrc
new file mode 100644
index 0000000..2b4e590
--- /dev/null
+++ b/doc/git-mailrc
@@ -0,0 +1,100 @@
+# To use this file, run in your u-boot tree:
+# git config sendemail.aliasesfile doc/git-mailrc
+# git config sendemail.aliasfiletype mutt
+#
+# Then when sending patches, you can use:
+# git send-email --to u-boot --cc i2c ...
+
+alias uboot u-boot at lists.denx.de
+alias u-boot uboot
+
+# Maintainer aliases. Use the same alias here as patchwork to keep
+# things simple and easy to look up/coordinate.
+alias aaribaud Albert Aribaud <albert.u.boot@aribaud.net>
+alias afleming Andy Fleming <afleming@freescale.com>
+alias ag Anatolij Gustschin <agust@denx.de>
+alias gruss Graeme Russ <graeme.russ@gmail.com>
+alias hs Heiko Schocher <hs@denx.de>
+alias iwamatsu Nobuhiro Iwamatsu <iwamatsu@nigauri.org>
+alias jasonjin Jason Jin <jason.jin@freescale.com>
+alias kimphill Kim Phillips <kim.phillips@freescale.com>
+alias kumar Kumar Gala <kumar.gala@freescale.com>
+alias macpaul Macpaul Lin <macpaul@andestech.com>
+alias marex Marek Vasut <marek.vasut@gmail.com>
+alias monstr Michal Simek <monstr@monstr.eu>
+alias prafulla Prafulla Wadaskar <prafulla@marvell.com>
+alias rbohmer Remy Bohmer <linux@bohmer.net>
+alias reinhardm Reinhard Meyer <u-boot@emk-elektronik.de>
+alias sbabic Stefano Babic <sbabic@denx.de>
+alias scottwood Scott Wood <scottwood@freescale.com>
+alias smcnutt Scott McNutt <smcnutt@psyent.com>
+alias stroese Stefan Roese <sr@denx.de>
+alias vapier Mike Frysinger <vapier@gentoo.org>
+alias wd Wolfgang Denk <wd@denx.de>
+
+# Architecture aliases
+alias arch arm, avr32, bfin, m68k, microblaze, mips, nds32, nios2, powerpc, sandbox, superh, sparc, x86
+alias arches arch
+
+alias arm uboot, aaribaud
+alias at91 uboot, reinhardm
+alias davinci omap
+alias imx uboot, sbabic
+alias kirkwood uboot, prafulla
+alias omap uboot, Sandeep Paulraj <s-paulraj@ti.com>
+alias pxa uboot, marex
+alias s3c samsung
+alias s5pc samsung
+alias samsung uboot,
+alias tegra uboot, Simon Glass <sjg@chromium.org>, Tom Warren <twarren@nvidia.com>, Stephen Warren <swarren@nvidia.com>
+alias tegra2 tegra
+
+alias avr32 uboot, reinhardm
+
+alias bfin uboot, vapier
+alias blackfin bfin
+
+alias m68k uboot, jasonjin
+alias coldfire m68k
+
+alias microblaze uboot, monstr
+alias mb microblaze
+
+alias mips uboot, Shinya Kuribayashi <skuribay@pobox.com>
+
+alias nds32 uboot, macpaul
+
+alias nios uboot, Thomas Chou <thomas@wytron.com.tw>, smcnutt
+alias nios2 nios
+
+alias powerpc uboot, afleming, kimphill, kumar, stroese, wd
+alias ppc powerpc
+alias mpc5xxx uboot, wd
+alias mpc8xx uboot, wd
+alias mpc82xx uboot, wd
+alias mpc83xx uboot, kimphill
+alias mpc85xx uboot, afleming, kumar
+alias mpc86xx uboot, afleming, kumar
+alias ppc4xx uboot, stroese
+alias ppc7xx uboot, wd
+alias ppc74xx uboot, wd
+
+alias sandbox Simon Glass <sjg@chromium.org>
+alias sb sandbox
+
+alias sparc uboot, Daniel Hellstrom <daniel@gaisler.com>
+
+alias superh uboot, iwamatsu
+alias sh superh
+
+alias x86 uboot, gruss
+
+# Subsystem aliases
+alias cfi uboot, stroese
+alias fdt uboot, Jerry Van Baren <vanbaren@cideas.com>
+alias i2c uboot, hs
+alias mmc uboot, afleming
+alias nand uboot, scottwood
+alias net uboot, wd
+alias usb uboot, rbohmer
+alias video uboot, ag
--
1.7.6.1
^ permalink raw reply related
* Re: [PATCH] xfstests: 075 112 redirect stderr of fsx to /dev/null too
From: Dave Chinner @ 2011-11-06 23:06 UTC (permalink / raw)
To: Eryu Guan; +Cc: xfs
In-Reply-To: <1319941555-4405-1-git-send-email-guaneryu@gmail.com>
On Sun, Oct 30, 2011 at 10:25:55AM +0800, Eryu Guan wrote:
> In commit c18bf42de9d5d5fa05025754df1ff63f2147bd12 a warning message
> will be printed to stderr if filesystem doesn't support fallocate(2).
> The warning message will fail these tests though fsx returns SUCCESS.
>
> FSTYP -- ext3
> PLATFORM -- Linux/i686 debian-dev 3.1.0+
> MKFS_OPTIONS -- /dev/sda3
> MOUNT_OPTIONS -- -o acl,user_xattr /dev/sda3 /mnt/sda3
>
> 075 12s ... - output mismatch (see 075.out.bad)
> --- 075.out 2011-10-28 21:35:41.872573530 +0800
> +++ 075.out.bad 2011-10-30 10:31:02.607058029 +0800
> @@ -4,6 +4,9 @@
> -----------------------------------------------
> fsx.0 : -d -N numops -S 0
> -----------------------------------------------
> +fsx: main: filesystem does not support fallocate, disabling
> +: Operation not supported
>
> So redirect stderr of fsx to /dev/null too.
>
> Signed-off-by: Eryu Guan <guaneryu@gmail.com>
> ---
> 075 | 2 +-
> 112 | 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/075 b/075
> index 0f0a6ed..87d273f 100755
> --- a/075
> +++ b/075
> @@ -77,7 +77,7 @@ _do_test()
>
> # This cd and use of -P gets full debug on $here (not TEST_DEV)
> cd $out
> - if ! $here/ltp/fsx $_param -P $here $seq.$_n >/dev/null
> + if ! $here/ltp/fsx $_param -P $here $seq.$_n &>/dev/null
> then
> echo " fsx ($_param) failed, $? - compare $seq.$_n.{good,bad,fsxlog}"
> mv $out/$seq.$_n $here/$seq.$_n.full
> diff --git a/112 b/112
> index 557350a..763b17a 100755
> --- a/112
> +++ b/112
> @@ -77,7 +77,7 @@ _do_test()
>
> # This cd and use of -P gets full debug on $here (not TEST_DEV)
> cd $out
> - if ! $here/ltp/fsx $_param -P $here $seq.$_n >/dev/null
> + if ! $here/ltp/fsx $_param -P $here $seq.$_n &>/dev/null
> then
> echo " fsx ($_param) returned $? - see $seq.$_n.full"
> mv $seq.$_n.fsxlog $here/$seq.$_n.full
If this hasn't been committed, the correct fix is to pass the "-q"
option to fsx to tell it not to emit these messages. We still really
want any other output to stderr to cause a test failure....
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
^ permalink raw reply
* [GIT PULL] Ceph updates part 2
From: Sage Weil @ 2011-11-06 23:05 UTC (permalink / raw)
To: torvalds; +Cc: ceph-devel, linux-kernel
Hi Linus,
Please pull this second set of Ceph updates from
git://git.kernel.org/pub/scm/linux/kernel/git/sage/ceph-client.git for-linus
There are two sparse cleanup patches I missed before, and a second set of
patches that reenable some of Ceph usage of the dcache that build on the
d_prune dentry_operation that was merged this week.
I also finally got the tree back on kernel.org. (You'll find the same
commits on github, where most of the development work will remain.)
Thanks!
sage
H Hartley Sweeten (2):
ceph/mds_client.c: quiet sparse noise
ceph/super.c: quiet sparse noise
Sage Weil (2):
ceph: clear parent D_COMPLETE flag when on dentry prune
ceph: use new D_COMPLETE dentry flag
fs/ceph/caps.c | 8 ++---
fs/ceph/dir.c | 87 ++++++++++++++++++++++++++++++++++++++++++++-----
fs/ceph/inode.c | 8 ++--
fs/ceph/mds_client.c | 10 +++---
fs/ceph/super.c | 4 +-
fs/ceph/super.h | 23 ++++++++++++-
6 files changed, 113 insertions(+), 27 deletions(-)
^ permalink raw reply
* Re: [RFC, RFT] Use ZFS embedding area
From: Seth Goldberg @ 2011-11-06 22:59 UTC (permalink / raw)
To: The development of GNU GRUB
In-Reply-To: <4EB6F7DB.30408@gmail.com>
Hi,
Aside from a typo ("curently" -> "currently"), it looks great! I vote for a commit :).
--S
On Nov 6, 2011, at 1:10 PM, Vladimir 'φ-coder/phcoder' Serbinenko wrote:
> Attached patch makes it possible to install GRUB into ZFS partition or
> whole-disk ZFS sanely. May be dangerous so I recommend a VM and/or backup.
>
> --
> Regards
> Vladimir 'φ-coder/phcoder' Serbinenko
>
> <zfsembed.diff>_______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/grub-devel
^ permalink raw reply
* linux-next: failing to fetch the sysctl tree
From: Stephen Rothwell @ 2011-11-06 22:58 UTC (permalink / raw)
To: Eric W. Biederman; +Cc: linux-next, linux-kernel
[-- Attachment #1: Type: text/plain, Size: 390 bytes --]
Hi Eric,
Fetching the sysctl tree produces this error:
fatal: Couldn't find remote ref refs/heads/master
And indeed the sysctl tree on git.kernel.org is completely empty (i.e.
there are no commits). Maybe you should remove it and recreate it as a
fork of Linus' tree.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [patch 0/8] Samsung Laptop driver patches - resend
From: Corentin Chary @ 2011-11-06 22:54 UTC (permalink / raw)
To: Greg KH; +Cc: Matthew Garrett, platform-driver-x86, linux-kernel, greg
In-Reply-To: <20110920161743.GA32737@kroah.com>
On Tue, Sep 20, 2011 at 6:17 PM, Greg KH <gregkh@suse.de> wrote:
> Hi Matthew,
>
> Here is a resend of the samsung-laptop patches, with the correct
> authorship info in it. Sorry about the last batch, 'quilt mail' strips
> them off when sending them out, despite the information being in the
> original patch.
>
> The patches are against Linus's current tree, but should apply just fine
> to linux-next as well.
>
> If there are any problems with them, please let me know.
>
> Oh, and if anyone wants to take over maintainership of this driver,
> please let me know. I no longer have the hardware to be able to test
> any changes for it, which is why this took so long to get pushed out to
> you.
>
> thanks,
>
> greg k-h
Hi Greg,
Just got a 90X3A from Intel and I'll try to take a look at samsung-laptop
since some features are missing (keyboard backlight for example).
Do you have any doc on the vendor "interface" (other than just reading
the code :) ) ?
Thanks,
--
Corentin Chary
http://xf.iksaif.net
^ permalink raw reply
* linux-next: failing to fetch the acpi tree
From: Stephen Rothwell @ 2011-11-06 22:54 UTC (permalink / raw)
To: Len Brown; +Cc: linux-next, linux-kernel
[-- Attachment #1: Type: text/plain, Size: 301 bytes --]
Hi Len,
Fetching the acpi tree, produces this error:
fatal: Couldn't find remote ref refs/heads/acpi
I am still fetching from git://github.com/lenb/linux.git#acpi, is that
correct?
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* [PATCH v2] staging/gma500: Convert pci_table entries to PCI_DEVICE (if PCI_ANY_ID is used)
From: Peter Huewe @ 2011-11-06 22:50 UTC (permalink / raw)
To: Greg Kroah-Hartman; +Cc: devel, linux-kernel, Alan Cox, Peter Huewe
In-Reply-To: <1320613964-22916-1-git-send-email-peterhuewe@gmx.de>
This patch converts pci_table entries to use the PCI_DEVICE macro,
if .subvendor and .subdevice are set to PCI_ANY_ID,
and thus improves readability.
And while at it changed the hardcoded 0x8086 to PCI_VENDOR_ID_INTEL
Signed-off-by: Peter Huewe <peterhuewe@gmx.de>
---
v2:
Moved
KernelVersion: Staging-20111106
below the dashes.
drivers/staging/gma500/psb_drv.c | 52 +++++++++++++++++++-------------------
1 files changed, 26 insertions(+), 26 deletions(-)
diff --git a/drivers/staging/gma500/psb_drv.c b/drivers/staging/gma500/psb_drv.c
index dc676c2..f5eebcb 100644
--- a/drivers/staging/gma500/psb_drv.c
+++ b/drivers/staging/gma500/psb_drv.c
@@ -50,37 +50,37 @@ module_param_named(trap_pagefaults, drm_psb_trap_pagefaults, int, 0600);
static DEFINE_PCI_DEVICE_TABLE(pciidlist) = {
- { 0x8086, 0x8108, PCI_ANY_ID, PCI_ANY_ID, 0, 0, (long) &psb_chip_ops },
- { 0x8086, 0x8109, PCI_ANY_ID, PCI_ANY_ID, 0, 0, (long) &psb_chip_ops },
+ { PCI_DEVICE(PCI_VENDOR_ID_INTEL, 0x8108), 0, 0, (long) &psb_chip_ops },
+ { PCI_DEVICE(PCI_VENDOR_ID_INTEL, 0x8109), 0, 0, (long) &psb_chip_ops },
#if defined(CONFIG_DRM_PSB_MRST)
- { 0x8086, 0x4100, PCI_ANY_ID, PCI_ANY_ID, 0, 0, (long) &mrst_chip_ops},
- { 0x8086, 0x4101, PCI_ANY_ID, PCI_ANY_ID, 0, 0, (long) &mrst_chip_ops},
- { 0x8086, 0x4102, PCI_ANY_ID, PCI_ANY_ID, 0, 0, (long) &mrst_chip_ops},
- { 0x8086, 0x4103, PCI_ANY_ID, PCI_ANY_ID, 0, 0, (long) &mrst_chip_ops},
- { 0x8086, 0x4104, PCI_ANY_ID, PCI_ANY_ID, 0, 0, (long) &mrst_chip_ops},
- { 0x8086, 0x4105, PCI_ANY_ID, PCI_ANY_ID, 0, 0, (long) &mrst_chip_ops},
- { 0x8086, 0x4106, PCI_ANY_ID, PCI_ANY_ID, 0, 0, (long) &mrst_chip_ops},
- { 0x8086, 0x4107, PCI_ANY_ID, PCI_ANY_ID, 0, 0, (long) &mrst_chip_ops},
+ { PCI_DEVICE(PCI_VENDOR_ID_INTEL, 0x4100), 0, 0, (long) &mrst_chip_ops},
+ { PCI_DEVICE(PCI_VENDOR_ID_INTEL, 0x4101), 0, 0, (long) &mrst_chip_ops},
+ { PCI_DEVICE(PCI_VENDOR_ID_INTEL, 0x4102), 0, 0, (long) &mrst_chip_ops},
+ { PCI_DEVICE(PCI_VENDOR_ID_INTEL, 0x4103), 0, 0, (long) &mrst_chip_ops},
+ { PCI_DEVICE(PCI_VENDOR_ID_INTEL, 0x4104), 0, 0, (long) &mrst_chip_ops},
+ { PCI_DEVICE(PCI_VENDOR_ID_INTEL, 0x4105), 0, 0, (long) &mrst_chip_ops},
+ { PCI_DEVICE(PCI_VENDOR_ID_INTEL, 0x4106), 0, 0, (long) &mrst_chip_ops},
+ { PCI_DEVICE(PCI_VENDOR_ID_INTEL, 0x4107), 0, 0, (long) &mrst_chip_ops},
#endif
#if defined(CONFIG_DRM_PSB_MFLD)
- { 0x8086, 0x0130, PCI_ANY_ID, PCI_ANY_ID, 0, 0, (long) &mdfld_chip_ops},
- { 0x8086, 0x0131, PCI_ANY_ID, PCI_ANY_ID, 0, 0, (long) &mdfld_chip_ops},
- { 0x8086, 0x0132, PCI_ANY_ID, PCI_ANY_ID, 0, 0, (long) &mdfld_chip_ops},
- { 0x8086, 0x0133, PCI_ANY_ID, PCI_ANY_ID, 0, 0, (long) &mdfld_chip_ops},
- { 0x8086, 0x0134, PCI_ANY_ID, PCI_ANY_ID, 0, 0, (long) &mdfld_chip_ops},
- { 0x8086, 0x0135, PCI_ANY_ID, PCI_ANY_ID, 0, 0, (long) &mdfld_chip_ops},
- { 0x8086, 0x0136, PCI_ANY_ID, PCI_ANY_ID, 0, 0, (long) &mdfld_chip_ops},
- { 0x8086, 0x0137, PCI_ANY_ID, PCI_ANY_ID, 0, 0, (long) &mdfld_chip_ops},
+ { PCI_DEVICE(PCI_VENDOR_ID_INTEL, 0x0130), 0, 0, (long) &mdfld_chip_ops},
+ { PCI_DEVICE(PCI_VENDOR_ID_INTEL, 0x0131), 0, 0, (long) &mdfld_chip_ops},
+ { PCI_DEVICE(PCI_VENDOR_ID_INTEL, 0x0132), 0, 0, (long) &mdfld_chip_ops},
+ { PCI_DEVICE(PCI_VENDOR_ID_INTEL, 0x0133), 0, 0, (long) &mdfld_chip_ops},
+ { PCI_DEVICE(PCI_VENDOR_ID_INTEL, 0x0134), 0, 0, (long) &mdfld_chip_ops},
+ { PCI_DEVICE(PCI_VENDOR_ID_INTEL, 0x0135), 0, 0, (long) &mdfld_chip_ops},
+ { PCI_DEVICE(PCI_VENDOR_ID_INTEL, 0x0136), 0, 0, (long) &mdfld_chip_ops},
+ { PCI_DEVICE(PCI_VENDOR_ID_INTEL, 0x0137), 0, 0, (long) &mdfld_chip_ops},
#endif
#if defined(CONFIG_DRM_PSB_CDV)
- { 0x8086, 0x0be0, PCI_ANY_ID, PCI_ANY_ID, 0, 0, (long) &cdv_chip_ops},
- { 0x8086, 0x0be1, PCI_ANY_ID, PCI_ANY_ID, 0, 0, (long) &cdv_chip_ops},
- { 0x8086, 0x0be2, PCI_ANY_ID, PCI_ANY_ID, 0, 0, (long) &cdv_chip_ops},
- { 0x8086, 0x0be3, PCI_ANY_ID, PCI_ANY_ID, 0, 0, (long) &cdv_chip_ops},
- { 0x8086, 0x0be4, PCI_ANY_ID, PCI_ANY_ID, 0, 0, (long) &cdv_chip_ops},
- { 0x8086, 0x0be5, PCI_ANY_ID, PCI_ANY_ID, 0, 0, (long) &cdv_chip_ops},
- { 0x8086, 0x0be6, PCI_ANY_ID, PCI_ANY_ID, 0, 0, (long) &cdv_chip_ops},
- { 0x8086, 0x0be7, PCI_ANY_ID, PCI_ANY_ID, 0, 0, (long) &cdv_chip_ops},
+ { PCI_DEVICE(PCI_VENDOR_ID_INTEL, 0x0be0), 0, 0, (long) &cdv_chip_ops},
+ { PCI_DEVICE(PCI_VENDOR_ID_INTEL, 0x0be1), 0, 0, (long) &cdv_chip_ops},
+ { PCI_DEVICE(PCI_VENDOR_ID_INTEL, 0x0be2), 0, 0, (long) &cdv_chip_ops},
+ { PCI_DEVICE(PCI_VENDOR_ID_INTEL, 0x0be3), 0, 0, (long) &cdv_chip_ops},
+ { PCI_DEVICE(PCI_VENDOR_ID_INTEL, 0x0be4), 0, 0, (long) &cdv_chip_ops},
+ { PCI_DEVICE(PCI_VENDOR_ID_INTEL, 0x0be5), 0, 0, (long) &cdv_chip_ops},
+ { PCI_DEVICE(PCI_VENDOR_ID_INTEL, 0x0be6), 0, 0, (long) &cdv_chip_ops},
+ { PCI_DEVICE(PCI_VENDOR_ID_INTEL, 0x0be7), 0, 0, (long) &cdv_chip_ops},
#endif
{ 0, 0, 0}
};
--
1.7.3.4
^ permalink raw reply related
* [PATCH v2] staging/comedi/addi: Convert pci_table entries to PCI_DEVICE (if PCI_ANY_ID is used)
From: Peter Huewe @ 2011-11-06 22:48 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: devel, linux-kernel, Ian Abbott, Mori Hess, u.kleine-koenig,
Peter Huewe
In-Reply-To: <1320618283-17235-1-git-send-email-peterhuewe@gmx.de>
This patch converts pci_table entries to use the PCI_DEVICE macro,
if .subvendor and .subdevice are set to PCI_ANY_ID,
and thus improves readablity.
Since the driver_data field isn't used anywhere we can also drop the
assignments for class, class_mask and driver_data.
Moreover the hardcoded 0x15B8 was replaced by the more readable
PCI_VENDOR_ID_ADDIDATA
Signed-off-by: Peter Huewe <peterhuewe@gmx.de>
---
Remark:
The other APCIXXXX_BOARD_VENDOR_ID defines could also be replaced by either
PCI_VENDOR_ID_ADDIDATA or PCI_VENDOR_ID_ADDIDATA_OLD
but I'd rather do this in a separate patch.
v2:
Moved
KernelVersion: Staging-20111106
below the dashes.
.../staging/comedi/drivers/addi-data/addi_common.c | 137 ++++++++++----------
1 files changed, 68 insertions(+), 69 deletions(-)
diff --git a/drivers/staging/comedi/drivers/addi-data/addi_common.c b/drivers/staging/comedi/drivers/addi-data/addi_common.c
index 6fb7594..ca5bd9b8 100644
--- a/drivers/staging/comedi/drivers/addi-data/addi_common.c
+++ b/drivers/staging/comedi/drivers/addi-data/addi_common.c
@@ -145,78 +145,77 @@ void fpu_end(void)
static DEFINE_PCI_DEVICE_TABLE(addi_apci_tbl) = {
#ifdef CONFIG_APCI_3120
- {APCI3120_BOARD_VENDOR_ID, 0x818D, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0},
+ {PCI_DEVICE(APCI3120_BOARD_VENDOR_ID, 0x818D)},
#endif
#ifdef CONFIG_APCI_1032
- {APCI1032_BOARD_VENDOR_ID, 0x1003, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0},
+ {PCI_DEVICE(APCI1032_BOARD_VENDOR_ID, 0x1003)},
#endif
#ifdef CONFIG_APCI_1516
- {APCI1516_BOARD_VENDOR_ID, 0x1001, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0},
+ {PCI_DEVICE(APCI1516_BOARD_VENDOR_ID, 0x1001)},
#endif
#ifdef CONFIG_APCI_2016
- {APCI2016_BOARD_VENDOR_ID, 0x1002, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0},
+ {PCI_DEVICE(APCI2016_BOARD_VENDOR_ID, 0x1002)},
#endif
#ifdef CONFIG_APCI_2032
- {APCI2032_BOARD_VENDOR_ID, 0x1004, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0},
+ {PCI_DEVICE(APCI2032_BOARD_VENDOR_ID, 0x1004)},
#endif
#ifdef CONFIG_APCI_2200
- {APCI2200_BOARD_VENDOR_ID, 0x1005, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0},
+ {PCI_DEVICE(APCI2200_BOARD_VENDOR_ID, 0x1005)},
#endif
#ifdef CONFIG_APCI_1564
- {APCI1564_BOARD_VENDOR_ID, 0x1006, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0},
+ {PCI_DEVICE(APCI1564_BOARD_VENDOR_ID, 0x1006)},
#endif
#ifdef CONFIG_APCI_1500
- {APCI1500_BOARD_VENDOR_ID, 0x80fc, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0},
+ {PCI_DEVICE(APCI1500_BOARD_VENDOR_ID, 0x80fc)},
#endif
#ifdef CONFIG_APCI_3001
- {APCI3120_BOARD_VENDOR_ID, 0x828D, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0},
+ {PCI_DEVICE(APCI3120_BOARD_VENDOR_ID, 0x828D)},
#endif
#ifdef CONFIG_APCI_3501
- {APCI3501_BOARD_VENDOR_ID, 0x3001, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0},
+ {PCI_DEVICE(APCI3501_BOARD_VENDOR_ID, 0x3001)},
#endif
#ifdef CONFIG_APCI_035
- {APCI035_BOARD_VENDOR_ID, 0x0300, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0},
+ {PCI_DEVICE(APCI035_BOARD_VENDOR_ID, 0x0300)},
#endif
#ifdef CONFIG_APCI_3200
- {APCI3200_BOARD_VENDOR_ID, 0x3000, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0},
+ {PCI_DEVICE(APCI3200_BOARD_VENDOR_ID, 0x3000)},
#endif
#ifdef CONFIG_APCI_3300
- {APCI3200_BOARD_VENDOR_ID, 0x3007, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0},
+ {PCI_DEVICE(APCI3200_BOARD_VENDOR_ID, 0x3007)},
#endif
#ifdef CONFIG_APCI_1710
- {APCI1710_BOARD_VENDOR_ID, APCI1710_BOARD_DEVICE_ID,
- PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0},
+ {PCI_DEVICE(APCI1710_BOARD_VENDOR_ID, APCI1710_BOARD_DEVICE_ID)},
#endif
#ifdef CONFIG_APCI_16XX
- {0x15B8, 0x1009, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0},
- {0x15B8, 0x100A, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0},
+ {PCI_DEVICE(PCI_VENDOR_ID_ADDIDATA, 0x1009)},
+ {PCI_DEVICE(PCI_VENDOR_ID_ADDIDATA, 0x100A)},
#endif
#ifdef CONFIG_APCI_3XXX
- {0x15B8, 0x3010, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0},
- {0x15B8, 0x300F, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0},
- {0x15B8, 0x300E, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0},
- {0x15B8, 0x3013, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0},
- {0x15B8, 0x3014, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0},
- {0x15B8, 0x3015, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0},
- {0x15B8, 0x3016, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0},
- {0x15B8, 0x3017, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0},
- {0x15B8, 0x3018, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0},
- {0x15B8, 0x3019, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0},
- {0x15B8, 0x301A, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0},
- {0x15B8, 0x301B, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0},
- {0x15B8, 0x301C, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0},
- {0x15B8, 0x301D, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0},
- {0x15B8, 0x301E, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0},
- {0x15B8, 0x301F, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0},
- {0x15B8, 0x3020, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0},
- {0x15B8, 0x3021, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0},
- {0x15B8, 0x3022, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0},
- {0x15B8, 0x3023, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0},
- {0x15B8, 0x300B, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0},
- {0x15B8, 0x3002, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0},
- {0x15B8, 0x3003, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0},
- {0x15B8, 0x3004, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0},
- {0x15B8, 0x3024, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0},
+ {PCI_DEVICE(PCI_VENDOR_ID_ADDIDATA, 0x3010)},
+ {PCI_DEVICE(PCI_VENDOR_ID_ADDIDATA, 0x300F)},
+ {PCI_DEVICE(PCI_VENDOR_ID_ADDIDATA, 0x300E)},
+ {PCI_DEVICE(PCI_VENDOR_ID_ADDIDATA, 0x3013)},
+ {PCI_DEVICE(PCI_VENDOR_ID_ADDIDATA, 0x3014)},
+ {PCI_DEVICE(PCI_VENDOR_ID_ADDIDATA, 0x3015)},
+ {PCI_DEVICE(PCI_VENDOR_ID_ADDIDATA, 0x3016)},
+ {PCI_DEVICE(PCI_VENDOR_ID_ADDIDATA, 0x3017)},
+ {PCI_DEVICE(PCI_VENDOR_ID_ADDIDATA, 0x3018)},
+ {PCI_DEVICE(PCI_VENDOR_ID_ADDIDATA, 0x3019)},
+ {PCI_DEVICE(PCI_VENDOR_ID_ADDIDATA, 0x301A)},
+ {PCI_DEVICE(PCI_VENDOR_ID_ADDIDATA, 0x301B)},
+ {PCI_DEVICE(PCI_VENDOR_ID_ADDIDATA, 0x301C)},
+ {PCI_DEVICE(PCI_VENDOR_ID_ADDIDATA, 0x301D)},
+ {PCI_DEVICE(PCI_VENDOR_ID_ADDIDATA, 0x301E)},
+ {PCI_DEVICE(PCI_VENDOR_ID_ADDIDATA, 0x301F)},
+ {PCI_DEVICE(PCI_VENDOR_ID_ADDIDATA, 0x3020)},
+ {PCI_DEVICE(PCI_VENDOR_ID_ADDIDATA, 0x3021)},
+ {PCI_DEVICE(PCI_VENDOR_ID_ADDIDATA, 0x3022)},
+ {PCI_DEVICE(PCI_VENDOR_ID_ADDIDATA, 0x3023)},
+ {PCI_DEVICE(PCI_VENDOR_ID_ADDIDATA, 0x300B)},
+ {PCI_DEVICE(PCI_VENDOR_ID_ADDIDATA, 0x3002)},
+ {PCI_DEVICE(PCI_VENDOR_ID_ADDIDATA, 0x3003)},
+ {PCI_DEVICE(PCI_VENDOR_ID_ADDIDATA, 0x3004)},
+ {PCI_DEVICE(PCI_VENDOR_ID_ADDIDATA, 0x3024)},
#endif
{0}
};
@@ -1019,7 +1018,7 @@ static const struct addi_board boardtypes[] = {
#endif
#ifdef CONFIG_APCI_16XX
{"apci1648",
- 0x15B8,
+ PCI_VENDOR_ID_ADDIDATA,
0x1009,
128,
0,
@@ -1075,7 +1074,7 @@ static const struct addi_board boardtypes[] = {
i_APCI16XX_InsnBitsWriteTTLIO},
{"apci1696",
- 0x15B8,
+ PCI_VENDOR_ID_ADDIDATA,
0x100A,
128,
0,
@@ -1132,7 +1131,7 @@ static const struct addi_board boardtypes[] = {
#endif
#ifdef CONFIG_APCI_3XXX
{"apci3000-16",
- 0x15B8,
+ PCI_VENDOR_ID_ADDIDATA,
0x3010,
256,
256,
@@ -1188,7 +1187,7 @@ static const struct addi_board boardtypes[] = {
i_APCI3XXX_InsnWriteTTLIO},
{"apci3000-8",
- 0x15B8,
+ PCI_VENDOR_ID_ADDIDATA,
0x300F,
256,
256,
@@ -1244,7 +1243,7 @@ static const struct addi_board boardtypes[] = {
i_APCI3XXX_InsnWriteTTLIO},
{"apci3000-4",
- 0x15B8,
+ PCI_VENDOR_ID_ADDIDATA,
0x300E,
256,
256,
@@ -1300,7 +1299,7 @@ static const struct addi_board boardtypes[] = {
i_APCI3XXX_InsnWriteTTLIO},
{"apci3006-16",
- 0x15B8,
+ PCI_VENDOR_ID_ADDIDATA,
0x3013,
256,
256,
@@ -1356,7 +1355,7 @@ static const struct addi_board boardtypes[] = {
i_APCI3XXX_InsnWriteTTLIO},
{"apci3006-8",
- 0x15B8,
+ PCI_VENDOR_ID_ADDIDATA,
0x3014,
256,
256,
@@ -1412,7 +1411,7 @@ static const struct addi_board boardtypes[] = {
i_APCI3XXX_InsnWriteTTLIO},
{"apci3006-4",
- 0x15B8,
+ PCI_VENDOR_ID_ADDIDATA,
0x3015,
256,
256,
@@ -1468,7 +1467,7 @@ static const struct addi_board boardtypes[] = {
i_APCI3XXX_InsnWriteTTLIO},
{"apci3010-16",
- 0x15B8,
+ PCI_VENDOR_ID_ADDIDATA,
0x3016,
256,
256,
@@ -1524,7 +1523,7 @@ static const struct addi_board boardtypes[] = {
i_APCI3XXX_InsnWriteTTLIO},
{"apci3010-8",
- 0x15B8,
+ PCI_VENDOR_ID_ADDIDATA,
0x3017,
256,
256,
@@ -1580,7 +1579,7 @@ static const struct addi_board boardtypes[] = {
i_APCI3XXX_InsnWriteTTLIO},
{"apci3010-4",
- 0x15B8,
+ PCI_VENDOR_ID_ADDIDATA,
0x3018,
256,
256,
@@ -1636,7 +1635,7 @@ static const struct addi_board boardtypes[] = {
i_APCI3XXX_InsnWriteTTLIO},
{"apci3016-16",
- 0x15B8,
+ PCI_VENDOR_ID_ADDIDATA,
0x3019,
256,
256,
@@ -1692,7 +1691,7 @@ static const struct addi_board boardtypes[] = {
i_APCI3XXX_InsnWriteTTLIO},
{"apci3016-8",
- 0x15B8,
+ PCI_VENDOR_ID_ADDIDATA,
0x301A,
256,
256,
@@ -1748,7 +1747,7 @@ static const struct addi_board boardtypes[] = {
i_APCI3XXX_InsnWriteTTLIO},
{"apci3016-4",
- 0x15B8,
+ PCI_VENDOR_ID_ADDIDATA,
0x301B,
256,
256,
@@ -1804,7 +1803,7 @@ static const struct addi_board boardtypes[] = {
i_APCI3XXX_InsnWriteTTLIO},
{"apci3100-16-4",
- 0x15B8,
+ PCI_VENDOR_ID_ADDIDATA,
0x301C,
256,
256,
@@ -1860,7 +1859,7 @@ static const struct addi_board boardtypes[] = {
i_APCI3XXX_InsnWriteTTLIO},
{"apci3100-8-4",
- 0x15B8,
+ PCI_VENDOR_ID_ADDIDATA,
0x301D,
256,
256,
@@ -1916,7 +1915,7 @@ static const struct addi_board boardtypes[] = {
i_APCI3XXX_InsnWriteTTLIO},
{"apci3106-16-4",
- 0x15B8,
+ PCI_VENDOR_ID_ADDIDATA,
0x301E,
256,
256,
@@ -1972,7 +1971,7 @@ static const struct addi_board boardtypes[] = {
i_APCI3XXX_InsnWriteTTLIO},
{"apci3106-8-4",
- 0x15B8,
+ PCI_VENDOR_ID_ADDIDATA,
0x301F,
256,
256,
@@ -2028,7 +2027,7 @@ static const struct addi_board boardtypes[] = {
i_APCI3XXX_InsnWriteTTLIO},
{"apci3110-16-4",
- 0x15B8,
+ PCI_VENDOR_ID_ADDIDATA,
0x3020,
256,
256,
@@ -2084,7 +2083,7 @@ static const struct addi_board boardtypes[] = {
i_APCI3XXX_InsnWriteTTLIO},
{"apci3110-8-4",
- 0x15B8,
+ PCI_VENDOR_ID_ADDIDATA,
0x3021,
256,
256,
@@ -2140,7 +2139,7 @@ static const struct addi_board boardtypes[] = {
i_APCI3XXX_InsnWriteTTLIO},
{"apci3116-16-4",
- 0x15B8,
+ PCI_VENDOR_ID_ADDIDATA,
0x3022,
256,
256,
@@ -2196,7 +2195,7 @@ static const struct addi_board boardtypes[] = {
i_APCI3XXX_InsnWriteTTLIO},
{"apci3116-8-4",
- 0x15B8,
+ PCI_VENDOR_ID_ADDIDATA,
0x3023,
256,
256,
@@ -2252,7 +2251,7 @@ static const struct addi_board boardtypes[] = {
i_APCI3XXX_InsnWriteTTLIO},
{"apci3003",
- 0x15B8,
+ PCI_VENDOR_ID_ADDIDATA,
0x300B,
256,
256,
@@ -2307,7 +2306,7 @@ static const struct addi_board boardtypes[] = {
NULL},
{"apci3002-16",
- 0x15B8,
+ PCI_VENDOR_ID_ADDIDATA,
0x3002,
256,
256,
@@ -2362,7 +2361,7 @@ static const struct addi_board boardtypes[] = {
NULL},
{"apci3002-8",
- 0x15B8,
+ PCI_VENDOR_ID_ADDIDATA,
0x3003,
256,
256,
@@ -2417,7 +2416,7 @@ static const struct addi_board boardtypes[] = {
NULL},
{"apci3002-4",
- 0x15B8,
+ PCI_VENDOR_ID_ADDIDATA,
0x3004,
256,
256,
@@ -2472,7 +2471,7 @@ static const struct addi_board boardtypes[] = {
NULL},
{"apci3500",
- 0x15B8,
+ PCI_VENDOR_ID_ADDIDATA,
0x3024,
256,
256,
--
1.7.3.4
^ permalink raw reply related
* [lm-sensors] [PATCH v2] Add support for new attributes to
From: Guenter Roeck @ 2011-11-06 22:46 UTC (permalink / raw)
To: lm-sensors
Add support for new sysfs attributes to libsensors and to the sensors command.
v2: Use defines for array sizes. Some of the resulting arrays are larger than necessary,
but that is better than missing an array size update if the number of attributes
changes.
--
Index: doc/libsensors-API.txt
=================================--- doc/libsensors-API.txt (revision 5996)
+++ doc/libsensors-API.txt (working copy)
@@ -7,6 +7,16 @@
given new feature.
0x431 lm-sensors 3.3.0 to 3.3.1
+* Added support for new sysfs attributes
+ enum sensors_subfeature_type SENSORS_SUBFEATURE_IN_AVERAGE
+ enum sensors_subfeature_type SENSORS_SUBFEATURE_IN_LOWEST
+ enum sensors_subfeature_type SENSORS_SUBFEATURE_IN_HIGHEST
+ enum sensors_subfeature_type SENSORS_SUBFEATURE_TEMP_AVERAGE
+ enum sensors_subfeature_type SENSORS_SUBFEATURE_TEMP_LOWEST
+ enum sensors_subfeature_type SENSORS_SUBFEATURE_TEMP_HIGHEST
+ enum sensors_subfeature_type SENSORS_SUBFEATURE_CURR_AVERAGE
+ enum sensors_subfeature_type SENSORS_SUBFEATURE_CURR_LOWEST
+ enum sensors_subfeature_type SENSORS_SUBFEATURE_CURR_HIGHEST
* Added support for intrusion detection
enum sensors_feature_type SENSORS_FEATURE_INTRUSION
enum sensors_subfeature_type SENSORS_SUBFEATURE_INTRUSION_ALARM
Index: lib/sensors.h
=================================--- lib/sensors.h (revision 5996)
+++ lib/sensors.h (working copy)
@@ -157,6 +157,9 @@
SENSORS_SUBFEATURE_IN_MAX,
SENSORS_SUBFEATURE_IN_LCRIT,
SENSORS_SUBFEATURE_IN_CRIT,
+ SENSORS_SUBFEATURE_IN_AVERAGE,
+ SENSORS_SUBFEATURE_IN_LOWEST,
+ SENSORS_SUBFEATURE_IN_HIGHEST,
SENSORS_SUBFEATURE_IN_ALARM = (SENSORS_FEATURE_IN << 8) | 0x80,
SENSORS_SUBFEATURE_IN_MIN_ALARM,
SENSORS_SUBFEATURE_IN_MAX_ALARM,
@@ -181,6 +184,9 @@
SENSORS_SUBFEATURE_TEMP_LCRIT,
SENSORS_SUBFEATURE_TEMP_EMERGENCY,
SENSORS_SUBFEATURE_TEMP_EMERGENCY_HYST,
+ SENSORS_SUBFEATURE_TEMP_AVERAGE,
+ SENSORS_SUBFEATURE_TEMP_LOWEST,
+ SENSORS_SUBFEATURE_TEMP_HIGHEST,
SENSORS_SUBFEATURE_TEMP_ALARM = (SENSORS_FEATURE_TEMP << 8) | 0x80,
SENSORS_SUBFEATURE_TEMP_MAX_ALARM,
SENSORS_SUBFEATURE_TEMP_MIN_ALARM,
@@ -215,6 +221,9 @@
SENSORS_SUBFEATURE_CURR_MAX,
SENSORS_SUBFEATURE_CURR_LCRIT,
SENSORS_SUBFEATURE_CURR_CRIT,
+ SENSORS_SUBFEATURE_CURR_AVERAGE,
+ SENSORS_SUBFEATURE_CURR_LOWEST,
+ SENSORS_SUBFEATURE_CURR_HIGHEST,
SENSORS_SUBFEATURE_CURR_ALARM = (SENSORS_FEATURE_CURR << 8) | 0x80,
SENSORS_SUBFEATURE_CURR_MIN_ALARM,
SENSORS_SUBFEATURE_CURR_MAX_ALARM,
Index: lib/sysfs.c
=================================--- lib/sysfs.c (revision 5996)
+++ lib/sysfs.c (working copy)
@@ -233,6 +233,9 @@
{ "lcrit", SENSORS_SUBFEATURE_TEMP_LCRIT },
{ "emergency", SENSORS_SUBFEATURE_TEMP_EMERGENCY },
{ "emergency_hyst", SENSORS_SUBFEATURE_TEMP_EMERGENCY_HYST },
+ { "average", SENSORS_SUBFEATURE_TEMP_AVERAGE },
+ { "lowest", SENSORS_SUBFEATURE_TEMP_LOWEST },
+ { "highest", SENSORS_SUBFEATURE_TEMP_HIGHEST },
{ "alarm", SENSORS_SUBFEATURE_TEMP_ALARM },
{ "min_alarm", SENSORS_SUBFEATURE_TEMP_MIN_ALARM },
{ "max_alarm", SENSORS_SUBFEATURE_TEMP_MAX_ALARM },
@@ -252,6 +255,9 @@
{ "max", SENSORS_SUBFEATURE_IN_MAX },
{ "lcrit", SENSORS_SUBFEATURE_IN_LCRIT },
{ "crit", SENSORS_SUBFEATURE_IN_CRIT },
+ { "average", SENSORS_SUBFEATURE_IN_AVERAGE },
+ { "lowest", SENSORS_SUBFEATURE_IN_LOWEST },
+ { "highest", SENSORS_SUBFEATURE_IN_HIGHEST },
{ "alarm", SENSORS_SUBFEATURE_IN_ALARM },
{ "min_alarm", SENSORS_SUBFEATURE_IN_MIN_ALARM },
{ "max_alarm", SENSORS_SUBFEATURE_IN_MAX_ALARM },
@@ -302,6 +308,9 @@
{ "max", SENSORS_SUBFEATURE_CURR_MAX },
{ "lcrit", SENSORS_SUBFEATURE_CURR_LCRIT },
{ "crit", SENSORS_SUBFEATURE_CURR_CRIT },
+ { "average", SENSORS_SUBFEATURE_CURR_AVERAGE },
+ { "lowest", SENSORS_SUBFEATURE_CURR_LOWEST },
+ { "highest", SENSORS_SUBFEATURE_CURR_HIGHEST },
{ "alarm", SENSORS_SUBFEATURE_CURR_ALARM },
{ "min_alarm", SENSORS_SUBFEATURE_CURR_MIN_ALARM },
{ "max_alarm", SENSORS_SUBFEATURE_CURR_MAX_ALARM },
Index: prog/sensors/chips.c
=================================--- prog/sensors/chips.c (revision 5996)
+++ prog/sensors/chips.c (working copy)
@@ -280,15 +280,26 @@
{ SENSORS_SUBFEATURE_TEMP_CRIT, temp_crit_sensors, 0, "crit" },
{ SENSORS_SUBFEATURE_TEMP_EMERGENCY, temp_emergency_sensors, 0,
"emerg" },
+ { SENSORS_SUBFEATURE_TEMP_AVERAGE, NULL, 0, "avg" },
+ { SENSORS_SUBFEATURE_TEMP_LOWEST, NULL, 0, "lowest" },
+ { SENSORS_SUBFEATURE_TEMP_HIGHEST, NULL, 0, "highest" },
{ -1, NULL, 0, NULL }
};
+#define NUM_TEMP_ALARMS 6
+#define NUM_TEMP_SENSORS (ARRAY_SIZE(temp_sensors) \
+ + ARRAY_SIZE(temp_max_sensors) \
+ + ARRAY_SIZE(temp_crit_sensors) \
+ + ARRAY_SIZE(temp_emergency_sensors) \
+ - NUM_TEMP_ALARMS)
+
+
static void print_chip_temp(const sensors_chip_name *name,
const sensors_feature *feature,
int label_size)
{
- struct sensor_subfeature_data sensors[8];
- struct sensor_subfeature_data alarms[5];
+ struct sensor_subfeature_data sensors[NUM_TEMP_SENSORS];
+ struct sensor_subfeature_data alarms[NUM_TEMP_ALARMS];
int sensor_count, alarm_count;
const sensors_subfeature *sf;
double val;
@@ -365,17 +376,23 @@
{ SENSORS_SUBFEATURE_IN_MIN, NULL, 0, "min" },
{ SENSORS_SUBFEATURE_IN_MAX, NULL, 0, "max" },
{ SENSORS_SUBFEATURE_IN_CRIT, NULL, 0, "crit max" },
+ { SENSORS_SUBFEATURE_IN_AVERAGE, NULL, 0, "avg" },
+ { SENSORS_SUBFEATURE_IN_LOWEST, NULL, 0, "lowest" },
+ { SENSORS_SUBFEATURE_IN_HIGHEST, NULL, 0, "highest" },
{ -1, NULL, 0, NULL }
};
+#define NUM_IN_ALARMS 5
+#define NUM_IN_SENSORS (ARRAY_SIZE(voltage_sensors) - NUM_IN_ALARMS)
+
static void print_chip_in(const sensors_chip_name *name,
const sensors_feature *feature,
int label_size)
{
const sensors_subfeature *sf;
char *label;
- struct sensor_subfeature_data sensors[4];
- struct sensor_subfeature_data alarms[4];
+ struct sensor_subfeature_data sensors[NUM_IN_SENSORS];
+ struct sensor_subfeature_data alarms[NUM_IN_ALARMS];
int sensor_count, alarm_count;
double val;
@@ -504,6 +521,7 @@
};
static const struct sensor_subfeature_list power_inst_sensors[] = {
+ { SENSORS_SUBFEATURE_POWER_AVERAGE, NULL, 0, "avg" },
{ SENSORS_SUBFEATURE_POWER_INPUT_LOWEST, NULL, 0, "lowest" },
{ SENSORS_SUBFEATURE_POWER_INPUT_HIGHEST, NULL, 0, "highest" },
{ -1, NULL, 0, NULL }
@@ -517,14 +535,20 @@
{ -1, NULL, 0, NULL }
};
+#define NUM_POWER_ALARMS 4
+#define NUM_POWER_SENSORS (ARRAY_SIZE(power_common_sensors) \
+ + ARRAY_SIZE(power_inst_sensors) \
+ + ARRAY_SIZE(power_avg_sensors) \
+ - NUM_POWER_ALARMS)
+
static void print_chip_power(const sensors_chip_name *name,
const sensors_feature *feature,
int label_size)
{
double val;
const sensors_subfeature *sf;
- struct sensor_subfeature_data sensors[6];
- struct sensor_subfeature_data alarms[3];
+ struct sensor_subfeature_data sensors[NUM_POWER_SENSORS];
+ struct sensor_subfeature_data alarms[NUM_POWER_ALARMS];
int sensor_count, alarm_count;
char *label;
const char *unit;
@@ -653,9 +677,15 @@
{ SENSORS_SUBFEATURE_CURR_MIN, NULL, 0, "min" },
{ SENSORS_SUBFEATURE_CURR_MAX, NULL, 0, "max" },
{ SENSORS_SUBFEATURE_CURR_CRIT, NULL, 0, "crit max" },
+ { SENSORS_SUBFEATURE_CURR_AVERAGE, NULL, 0, "avg" },
+ { SENSORS_SUBFEATURE_CURR_LOWEST, NULL, 0, "lowest" },
+ { SENSORS_SUBFEATURE_CURR_HIGHEST, NULL, 0, "highest" },
{ -1, NULL, 0, NULL }
};
+#define NUM_CURR_ALARM 5
+#define NUM_CURR_SENSORS (ARRAY_SIZE(current_sensors) - NUM_CURR_ALARM)
+
static void print_chip_curr(const sensors_chip_name *name,
const sensors_feature *feature,
int label_size)
@@ -663,8 +693,8 @@
const sensors_subfeature *sf;
double val;
char *label;
- struct sensor_subfeature_data sensors[4];
- struct sensor_subfeature_data alarms[4];
+ struct sensor_subfeature_data sensors[NUM_CURR_SENSORS];
+ struct sensor_subfeature_data alarms[NUM_CURR_ALARM];
int sensor_count, alarm_count;
if (!(label = sensors_get_label(name, feature))) {
Index: CHANGES
=================================--- CHANGES (revision 5996)
+++ CHANGES (working copy)
@@ -2,6 +2,10 @@
-----------------------
SVN HEAD
+ libsensors: Added support for new sysfs attributes
+ sensors: Added support for new sysfs attributes
+ For power sensors, display both instantaneous and average data
+ if available
sensors-detect: Stop calling for PIIX5 SMBus testers
Improve filtering of fake DMI data
Print DMI system/product version if available
_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
^ 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.