* [PATCH 1/3] Add virtioblk_id tool to extract drive serial numbers
From: Ryan Harper @ 2010-06-03 19:07 UTC (permalink / raw)
To: linux-hotplug
Use the 'VBID' virtio-blk ioctl to extract drive serial numbers
to be used for building disk/by-id symlinks. After extracting
the serial number of the device it prints out the minimum info
needed in a similar format to `scsi_id --export` so that the
persistent-storage rules can process the serial information.
This program depends on the virtio-blk serial device patches posted
here[1] being applied to qemu and linux-kernel.
Here is what the output looks like:
% ./virtioblk_id /dev/vdb
ID_VIRTIO=1
ID_TYPE=disk
ID_VIRTIO_SERIAL=QM00001
1. http://lists.gnu.org/archive/html/qemu-devel/2010-03/msg01869.html
Signed-off-by: Ryan Harper <ryanh@us.ibm.com>
---
Makefile.am | 7 +++
| 81 ++++++++++++++++++++++++++++++++++++
2 files changed, 88 insertions(+), 0 deletions(-)
create mode 100644 extras/virtioblk_id/virtioblk_id.c
diff --git a/Makefile.am b/Makefile.am
index b0eeaf1..d2d3036 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -250,6 +250,13 @@ extras_path_id_path_id_LDADD = libudev/libudev-private.la
libexec_PROGRAMS += extras/path_id/path_id
# ------------------------------------------------------------------------------
+# virtioblk_id - virtioblk inquery to extract disk serial numbers
+# ------------------------------------------------------------------------------
+extras_virtioblk_id_virtioblk_id_SOURCES = extras/virtioblk_id/virtioblk_id.c
+extras_virtioblk_id_virtioblk_id_LDADD = libudev/libudev-private.la
+libexec_PROGRAMS += extras/virtioblk_id/virtioblk_id
+
+# ------------------------------------------------------------------------------
# fstab_import - import /etc/fstab entry for block device
# ------------------------------------------------------------------------------
extras_fstab_import_fstab_import_SOURCES = extras/fstab_import/fstab_import.c
--git a/extras/virtioblk_id/virtioblk_id.c b/extras/virtioblk_id/virtioblk_id.c
new file mode 100644
index 0000000..81afd03
--- /dev/null
+++ b/extras/virtioblk_id/virtioblk_id.c
@@ -0,0 +1,81 @@
+/*
+ * extract disk serial from virtio-blk devices
+ * and print enough values to allow udev to create disk/by-id/ symlinks
+ *
+ * Copyright IBM, Corp. 2010
+ *
+ * Authors:
+ * John Cooper <john.cooper@redhat.com>
+ * Ryan Harper <ryanh@us.ibm.com>
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2. See
+ * the COPYING file in the top-level directory.
+ */
+
+#include <stdio.h>
+#include <strings.h>
+#include <sys/types.h>
+#include <fcntl.h>
+#include <linux/hdreg.h>
+#include <getopt.h>
+
+#define IOCTL_CMD "VBID"
+
+int main(int argc, char **argv)
+{
+ int fd, rv;
+ const char *device;
+ char buf[255];
+
+ int opt_debug = 0;
+ static const char *option_string = "d";
+ static struct option options[] = {
+ {"debug", 0, NULL, 'd'},
+ {"help", 0, NULL, 'h'},
+ {0, 0, NULL, 0}
+ };
+
+ while (1) {
+ int option;
+ option = getopt_long(argc, argv, "dh", options, NULL);
+ if (option = -1)
+ break;
+ switch (option) {
+ case 'd':
+ opt_debug = 1;
+ break;
+ case 'h':
+ printf("Usage: virtioblk_id [--debug] [--help] <device>\n"
+ " --debug print debugging information\n"
+ " --help print this help text\n\n");
+ default:
+ rv = 1;
+ goto exit;
+ }
+ }
+
+ device = argv[optind];
+ if (device = NULL) {
+ fprintf(stderr, "no device specified\n");
+ rv = 1;
+ goto exit;
+ }
+
+
+ bzero(buf, sizeof (buf));
+ if ((fd = open(device, O_RDONLY)) < 0) {
+ if (opt_debug = 1)
+ perror("open");
+ } else if ((rv = ioctl(fd, IOCTL_CMD, buf)) < 0) {
+ if (opt_debug = 1)
+ perror("ioctl");
+ } else {
+ printf("ID_VIRTIO=1\n");
+ printf("ID_TYPE=disk\n");
+ printf("ID_VIRTIO_SERIAL=%s\n", buf);
+ rv = 0;
+ }
+
+ exit:
+ return rv;
+}
--
1.6.3.3
^ permalink raw reply related
* [PATCH 0/3] Add virtio-blk support to persistent-storage rules
From: Ryan Harper @ 2010-06-03 19:07 UTC (permalink / raw)
To: linux-hotplug; +Cc: John Cooper, Rusty Russell, Ryan Harper, qemu-devel
This patch series provides updates to udev to allow the creation symlinks for
virtio-blk devices, specifically disk/by-id and disk/by-path. This is most
useful for virtio-blk devices that do not yet have any filesystem for which a
UUID can be extracted (disk/by-uuid). These patches (save the path_id fix)
require an updated[1] qemu (on the host) and virtio-blk (in the guest) to
generate the by-id path; however if the guest or host qemu isn't capable
then no action is taken.
1. http://lists.gnu.org/archive/html/qemu-devel/2010-03/msg01869.html
Signed-off-by: Ryan Harper <ryanh@us.ibm.com>
^ permalink raw reply
* RE: [PATCH 1/2] Export firmware assigned labels of network devices
From: Michael Ellerman @ 2010-06-02 23:54 UTC (permalink / raw)
To: Narendra_K
Cc: netdev, linux-hotplug, linux-pci, Matt_Domsch, Jordan_Hargrave,
Charles_Rose, Vijay_Nijhawan
In-Reply-To: <EDA0A4495861324DA2618B4C45DCB3EE612864@blrx3m08.blr.amer.dell.com>
[-- Attachment #1: Type: text/plain, Size: 1048 bytes --]
On Tue, 2010-06-01 at 00:12 +0530, Narendra_K@Dell.com wrote:
> > On Fri, 2010-05-28 at 06:55 -0500, K, Narendra wrote:
> > > Hello,
> > >
> > > This patch is in continuation of an earlier discussion -
> > >
> > > http://marc.info/?l=linux-netdev&m=126712978908314&w=3
> > >
> > > The patch has the following review suggestions from the community
> > > incorporated -
> > >
> > > 1. The name of the attribute has been changed from "smbiosname" to
> > > "label" to hide the implementation details.
> > > 2. The implementation has been moved to a new file
> > > drivers/pci/pci-label.c
> >
> > You've changed the name, which is good, but the implementation is still
> > 100% dependant on ACPI or DMI AFAICS.
> >
> > So it seems to me until it's supported on another platform it may as
> > well go in pci-acpi.c,
>
> You mean the ACPI _DSM ? If yes, it is expected to become a standard
> very soon. I assume you meant non-Dell platforms by another platform.
No. I mean non-x86 platforms, yes they still exist.
cheers
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: configure patch for cross compilation
From: Kay Sievers @ 2010-06-02 15:40 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <4C066A21.9090507@san.rr.com>
On Wed, Jun 2, 2010 at 17:09, Paul Bender <pebender@san.rr.com> wrote:
> On 6/2/2010 7:57 AM, Kay Sievers wrote:
>>> when cross compiling, it use in location the pci.ids file needs to be
>>> surrounded in a conditional. Otherwise, the configure script never allows
>>> the --with-pci-ids-path to be used.
>>
>> Why would that fail? There are 3 test in a row, two of them are
>> expected to always fail. If all of them will fail, if you must specify
>> the thing on the commandline. That seems to work fine here.
>
> I should not have used the term 'fail'. Rather, I should have used the term
> 'die'. The AC_CHECK_FILE macro checks to see whether or not the package is
> being cross compiled. If it is, then then it dies, causing the configure
> script to stop.
Ah, great. It's a feature. :)
Applied. Thanks,
Kay
^ permalink raw reply
* Re: configure patch for cross compilation
From: Paul Bender @ 2010-06-02 15:09 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <4C066A21.9090507@san.rr.com>
On 6/2/2010 7:57 AM, Kay Sievers wrote:
> On Wed, Jun 2, 2010 at 16:26, Paul Bender<pebender@san.rr.com> wrote:
>> The message asking about cross compilation reminded me that I have a patch
>> that is needed for cross compilation. Because autoconf's AC_CHECK_FILE fails
>> when cross compiling, it use in location the pci.ids file needs to be
>> surrounded in a conditional. Otherwise, the configure script never allows
>> the --with-pci-ids-path to be used.
>
> Why would that fail? There are 3 test in a row, two of them are
> expected to always fail. If all of them will fail, if you must specify
> the thing on the commandline. That seems to work fine here.
I should not have used the term 'fail'. Rather, I should have used the
term 'die'. The AC_CHECK_FILE macro checks to see whether or not the
package is being cross compiled. If it is, then then it dies, causing
the configure script to stop.
> And please never send compressed patches, especially not when the
> patch is 2 kb in size. :)
No problem, I will try to remember in the future. Some mailing lists
prefer compressing patches because of the mangling that some mail list
archiving software does to text attachments. I have trouble keeping
track of which list prefers which format.
^ permalink raw reply
* Re: configure patch for cross compilation
From: Kay Sievers @ 2010-06-02 14:57 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <4C066A21.9090507@san.rr.com>
On Wed, Jun 2, 2010 at 16:26, Paul Bender <pebender@san.rr.com> wrote:
> The message asking about cross compilation reminded me that I have a patch
> that is needed for cross compilation. Because autoconf's AC_CHECK_FILE fails
> when cross compiling, it use in location the pci.ids file needs to be
> surrounded in a conditional. Otherwise, the configure script never allows
> the --with-pci-ids-path to be used.
Why would that fail? There are 3 test in a row, two of them are
expected to always fail. If all of them will fail, if you must specify
the thing on the commandline. That seems to work fine here.
And please never send compressed patches, especially not when the
patch is 2 kb in size. :)
Kay
^ permalink raw reply
* Re: Cross Compiling UDEV 1.56
From: Paul Bender @ 2010-06-02 14:35 UTC (permalink / raw)
To: linux-hotplug
On 5/31/2010 12:01 PM, Bruno Albrecht - FALKER wrote:
> Hi,
> I'm trying to cross compile udev 1.56, but I couldn't find a "how
> to"..could you point me some directions? not even google showed me
> how...perhaps i'm not searching it right...
I do not know of any write-up on how to do. However, with the exception
of a small patch to the configure script (which I just sent to the
mailing list), cross compilation is no different than cross compiling
any package that uses autotools.
I cross compile it for MiniMyth. MiniMyth uses a GAR based build system.
The MiniMyth GAR package for udev can be found at
<http://code.google.com/p/minimyth/source/browse/#svn/trunk/gar-minimyth/script/system/udev>.
As one can see from the package DEPENDS variable, there are several
dependencies that need to be built. However, most are needed only by the
extras. So, if you are not using any of the extras, then the dependency
list much less.
^ permalink raw reply
* configure patch for cross compilation
From: Paul Bender @ 2010-06-02 14:26 UTC (permalink / raw)
To: linux-hotplug
[-- Attachment #1: Type: text/plain, Size: 418 bytes --]
The message asking about cross compilation reminded me that I have a
patch that is needed for cross compilation. Because autoconf's
AC_CHECK_FILE fails when cross compiling, it use in location the pci.ids
file needs to be surrounded in a conditional. Otherwise, the configure
script never allows the --with-pci-ids-path to be used.
The patch adds informational messages related to checking for the
pci.ids file.
[-- Attachment #2: udev-157-pci_ids_path.patch.gz --]
[-- Type: application/gzip, Size: 604 bytes --]
^ permalink raw reply
* Re: [ANNOUNCE] udev 157 release
From: Kay Sievers @ 2010-06-02 12:17 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <1275480242.1695.1.camel@yio.site>
On Wed, Jun 2, 2010 at 14:08, Robert P. J. Day <rpjday@crashcourse.ca> wrote:
> On Wed, 2 Jun 2010, Kay Sievers wrote:
>
>> Here comes a new udev version. Thanks to all who have contributed to
>> this release.
>
> i have one minor observation about the test utility. in
> udev-test.pl:
>
> if ($rules->{exp_add_error}) {
> print " as expected\n";
> } else {
> print "\n";
> system("tree $udev_root"); <-- this line
> print "\n";
> $error++;
> sleep(1);
> }
>
> obviously, if something goes wrong during the test, that script
> presumes that the "tree" utility is installed. on a stock ubuntu
> 10.04 system, it isn't so that system() call fails.
>
> is it worth verifying that "tree" is installed first before running
> the test?
Oh, it's like this since forever. I don't really care, because I can't
live without 'tree'. If you like, patch it to fall-back to 'find' or
'ls' or whatever makes sense, and I'll apply it. :)
Cheers,
Kay
^ permalink raw reply
* Re: [ANNOUNCE] udev 157 release
From: Robert P. J. Day @ 2010-06-02 12:08 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <1275480242.1695.1.camel@yio.site>
On Wed, 2 Jun 2010, Kay Sievers wrote:
> Here comes a new udev version. Thanks to all who have contributed to
> this release.
i have one minor observation about the test utility. in
udev-test.pl:
if ($rules->{exp_add_error}) {
print " as expected\n";
} else {
print "\n";
system("tree $udev_root"); <-- this line
print "\n";
$error++;
sleep(1);
}
obviously, if something goes wrong during the test, that script
presumes that the "tree" utility is installed. on a stock ubuntu
10.04 system, it isn't so that system() call fails.
is it worth verifying that "tree" is installed first before running
the test?
rday
--
====================================
Robert P. J. Day Waterloo, Ontario, CANADA
Linux Consulting, Training and Kernel Pedantry.
Web page: http://crashcourse.ca
Twitter: http://twitter.com/rpjday
====================================
^ permalink raw reply
* [ANNOUNCE] udev 157 release
From: Kay Sievers @ 2010-06-02 12:04 UTC (permalink / raw)
To: linux-hotplug
Here comes a new udev version. Thanks to all who have contributed to
this release.
The tarball can be found here:
ftp://ftp.kernel.org/pub/linux/utils/kernel/hotplug/
The development repository can be found here:
http://www.kernel.org/git/?p=linux/hotplug/udev.git;a=summary
The ChangeLog can be found here:
http://www.kernel.org/git/?p=linux/hotplug/udev.git;a=blob;hb=HEAD;f=ChangeLog
udev 157
====
Bugfixes.
The option --debug-trace and the environment variable UDEVD_MAX_CHILDSwas removed from udevd.
Udevd now checks the kernel commandline for the following variables:
udev.log-priority=<syslog priority>
udev.children-max=<maximum number of workers>
udev.exec-delay=<seconds to delay the execution of RUN=>
to help debuging coldplug setups where the loading of a kernel
module crashes the system.
The subdirectory in the source tree rules/packages has been renamed to
rules/arch, and contains only architecture specific rules now.
^ permalink raw reply
* Re: [PATCH] Fix wlan key on Inspiron 1010 & 1110
From: Martin Pitt @ 2010-06-02 7:01 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <1275460051.15999.167.camel@laptop>
Hello Jerone,
Jerone Young [2010-06-02 1:27 -0500]:
> This fixes wlan key on Inspirion 1010 & 1110.
Thanks! Pushed.
Martin
--
Martin Pitt | http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)
^ permalink raw reply
* [PATCH] Fix wlan key on Inspiron 1010 & 1110
From: Jerone Young @ 2010-06-02 6:27 UTC (permalink / raw)
To: linux-hotplug
This fixes wlan key on Inspirion 1010 & 1110.
This patch depends on previous patches sent.
The issue with all of these is that they were all Dell mini & it wasn't
noticed till recent that they all did not follow the standard that the
rest of Dell machines follow.
Also to note while this fixes the wlan key sending the proper key press,
work is still needed at the kernel level for complete support.
This is the last patch all the Dell minis have been verified to all have
this issue, and are now covered.
Signed-off-by: Jerone Young <jerone.young@canonical.com>
diff --git a/extras/keymap/95-keymap.rules b/extras/keymap/95-keymap.rules
index b60dd18..8ed2b59 100644
--- a/extras/keymap/95-keymap.rules
+++ b/extras/keymap/95-keymap.rules
@@ -53,7 +53,7 @@ GOTO="keyboard_end"
LABEL="keyboard_vendorcheck"
ENV{DMI_VENDOR}="Dell*", RUN+="keymap $name dell"
-ENV{DMI_VENDOR}="Dell*", ATTR{[dmi/id]product_name}="Inspiron 910|Inspiron 1011|Inspiron 1012|Inspiron 1210", RUN+="keymap $name 0x84 wlan"
+ENV{DMI_VENDOR}="Dell*", ATTR{[dmi/id]product_name}="Inspiron 910|Inspiron 1010|Inspiron 1011|Inspiron 1012|Inspiron 1110|Inspiron 1210", RUN+="keymap $name 0x84 wlan"
ENV{DMI_VENDOR}="Compaq*", ATTR{[dmi/id]product_name}="*E500*|*Evo N*", RUN+="keymap $name compaq-e_evo"
^ permalink raw reply related
* Fix wlan key on Inspiron 1012
From: Jerone Young @ 2010-06-01 17:45 UTC (permalink / raw)
To: linux-hotplug
This fixes wlan key on Inspiron 1012.
It seems all the mini line Dell's have had this issue. So it's a matter
of catching the older Dell mini machines, not using the standard Dell
keycode for wlan key. Think there is one more left.
Working with Dell so newer mini machines will not have this issue.
Signed-off-by: Jerone Young <jerone.young@canonical.com>
diff --git a/extras/keymap/95-keymap.rules b/extras/keymap/95-keymap.rules
index 79490da..b60dd18 100644
--- a/extras/keymap/95-keymap.rules
+++ b/extras/keymap/95-keymap.rules
@@ -53,7 +53,7 @@ GOTO="keyboard_end"
LABEL="keyboard_vendorcheck"
ENV{DMI_VENDOR}="Dell*", RUN+="keymap $name dell"
-ENV{DMI_VENDOR}="Dell*", ATTR{[dmi/id]product_name}="Inspiron 910|Inspiron 1011|Inspiron 1210", RUN+="keymap $name 0x84 wlan"
+ENV{DMI_VENDOR}="Dell*", ATTR{[dmi/id]product_name}="Inspiron 910|Inspiron 1011|Inspiron 1012|Inspiron 1210", RUN+="keymap $name 0x84 wlan"
ENV{DMI_VENDOR}="Compaq*", ATTR{[dmi/id]product_name}="*E500*|*Evo N*", RUN+="keymap $name compaq-e_evo"
^ permalink raw reply related
* Cross Compiling UDEV 1.56
From: Bruno Albrecht - FALKER @ 2010-05-31 19:01 UTC (permalink / raw)
To: linux-hotplug
Hi,
I'm trying to cross compile udev 1.56, but I couldn't find a "how
to"..could you point me some directions? not even google showed me
how...perhaps i'm not searching it right...
Cheers,
Bruno
--
Bruno Landau Albrecht
Falker Automação Agrícola Ltda.
Tel/Fax.: +55 51 3019-3730 / 3019-8730
brunolalb@falker.com.br
www.falker.com.br
Skype: brunolalb_falker
^ permalink raw reply
* RE: [PATCH 1/2] Export firmware assigned labels of network devices to sysfs
From: Narendra_K @ 2010-05-31 18:54 UTC (permalink / raw)
To: michael
Cc: netdev, linux-hotplug, linux-pci, Matt_Domsch, Jordan_Hargrave,
Charles_Rose, Vijay_Nijhawan
In-Reply-To: <1275314876.21246.29.camel@concordia>
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="windows-1254", Size: 1623 bytes --]
> -----Original Message-----
> From: netdev-owner@vger.kernel.org [mailto:netdev-
> owner@vger.kernel.org] On Behalf Of Michael Ellerman
> Sent: Monday, May 31, 2010 7:38 PM
> To: K, Narendra
> Cc: netdev@vger.kernel.org; linux-hotplug@vger.kernel.org; linux-
> pci@vger.kernel.org; Domsch, Matt; Hargrave, Jordan; Rose, Charles;
> Nijhawan, Vijay
> Subject: Re: [PATCH 1/2] Export firmware assigned labels of network
> devices to sysfs
>
> On Fri, 2010-05-28 at 06:55 -0500, K, Narendra wrote:
> > Hello,
> >
> > This patch is in continuation of an earlier discussion -
> >
> > http://marc.info/?l=linux-netdev&m\x126712978908314&w=3
> >
> > The patch has the following review suggestions from the community
> > incorporated -
> >
> > 1. The name of the attribute has been changed from "smbiosname" to
> > "label" to hide the implementation details.
> > 2. The implementation has been moved to a new file
> > drivers/pci/pci-label.c
>
> You've changed the name, which is good, but the implementation is still
> 100% dependant on ACPI or DMI AFAICS.
>
> So it seems to me until it's supported on another platform it may as
> well go in pci-acpi.c,
You mean the ACPI _DSM ? If yes, it is expected to become a standard very soon. I assume you meant non-Dell platforms by another platform.
> or at least only be compiled if (ACPI || DMI).
> Otherwise it's just dead code.
>
Is DMI not implemented widely today ? Please correct me if I am missing something here.
With regards,
Narendra K
ÿôèº{.nÇ+‰·Ÿ®‰†+%ŠËÿ±éݶ\x17¥Šwÿº{.nÇ+‰·¥Š{±þ\x1a-¦[ þ)í…æèw*\x1fjg¬±¨\x1e¶‰šŽŠÝ¢jÿ¾\a«þG«éÿ¢¸\f¢·¦j:+v‰¨ŠwèjØm¶Ÿÿþø\x1e¯ù\x1e®w¥þŠàþf£¢·hšâúÿ†Ù¥
^ permalink raw reply
* Re: [PATCH 1/2] Export firmware assigned labels of network devices
From: Michael Ellerman @ 2010-05-31 14:07 UTC (permalink / raw)
To: K, Narendra
Cc: netdev@vger.kernel.org, linux-hotplug@vger.kernel.org,
linux-pci@vger.kernel.org, Domsch, Matt, Hargrave, Jordan,
Rose, Charles, Nijhawan, Vijay
In-Reply-To: <20100528115520.GA24114@littleblue.us.dell.com>
[-- Attachment #1: Type: text/plain, Size: 781 bytes --]
On Fri, 2010-05-28 at 06:55 -0500, K, Narendra wrote:
> Hello,
>
> This patch is in continuation of an earlier discussion -
>
> http://marc.info/?l=linux-netdev&m=126712978908314&w=3
>
> The patch has the following review suggestions from the community incorporated -
>
> 1. The name of the attribute has been changed from "smbiosname" to "label" to hide
> the implementation details.
> 2. The implementation has been moved to a new file drivers/pci/pci-label.c
You've changed the name, which is good, but the implementation is still
100% dependant on ACPI or DMI AFAICS.
So it seems to me until it's supported on another platform it may as
well go in pci-acpi.c, or at least only be compiled if (ACPI || DMI).
Otherwise it's just dead code.
cheers
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* RE: [PATCH 1/2] Export firmware assigned labels of network devices to sysfs
From: Narendra_K @ 2010-05-31 7:55 UTC (permalink / raw)
To: Matt_Domsch, greg
Cc: netdev, linux-hotplug, linux-pci, Jordan_Hargrave, Charles_Rose,
Vijay_Nijhawan
In-Reply-To: <20100528181100.GA12806@auslistsprd01.us.dell.com>
> -----Original Message-----
> From: Matt Domsch [mailto:Matt_Domsch@dell.com]
> Sent: Friday, May 28, 2010 11:41 PM
> To: Greg KH
> Cc: K, Narendra; netdev@vger.kernel.org;
linux-hotplug@vger.kernel.org;
> linux-pci@vger.kernel.org; Hargrave, Jordan; Rose, Charles; Nijhawan,
> Vijay
> Subject: Re: [PATCH 1/2] Export firmware assigned labels of network
> devices to sysfs
>
> On Fri, May 28, 2010 at 08:40:41AM -0700, Greg KH wrote:
> > On Fri, May 28, 2010 at 06:55:21AM -0500, K, Narendra wrote:
> > > +static const char dell_dsm_uuid[] = {
> >
> > Um, a dell specific uuid in a generic file? What happens when we
> need
> > to support another manufacturer?
> >
> > > + 0xD0, 0x37, 0xC9, 0xE5, 0x53, 0x35, 0x7A, 0x4D,
> > > + 0x91, 0x17, 0xEA, 0x4D, 0x19, 0xC3, 0x43, 0x4D
> > > +};
>
> This simply needs to be renamed. It's defined in the ECN, so will be
> part of the spec, and is not vendor-unique, but defined once for all
> implementations. It separates this _DSM function from others.
>
> Thanks for the quick feedback.
Matt,
Thanks for the clarification. My understanding of the uuid was
incorrect. Would address this in the next version of the patch.
With regards,
Narendra K
^ permalink raw reply
* Re: [PATCH] Fix wlan key on Inspiron 910
From: Martin Pitt @ 2010-05-30 19:38 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <1275237568.1654.3375.camel@laptop>
Hey Jerone,
Jerone Young [2010-05-30 11:39 -0500]:
> This fixes the wlan key on Inspiron 910.
Thanks! Pushed.
Martin
--
Martin Pitt | http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)
^ permalink raw reply
* [PATCH] Fix wlan key on Inspiron 910
From: Jerone Young @ 2010-05-30 16:39 UTC (permalink / raw)
To: linux-hotplug
This fixes the wlan key on Inspiron 910.
Signed-off-by: Jerone Young <jerone.young@canonical.com>
diff --git a/extras/keymap/95-keymap.rules b/extras/keymap/95-keymap.rules
index c321fbb..79490da 100644
--- a/extras/keymap/95-keymap.rules
+++ b/extras/keymap/95-keymap.rules
@@ -53,7 +53,7 @@ GOTO="keyboard_end"
LABEL="keyboard_vendorcheck"
ENV{DMI_VENDOR}="Dell*", RUN+="keymap $name dell"
-ENV{DMI_VENDOR}="Dell*", ATTR{[dmi/id]product_name}="Inspiron 1011|Inspiron 1210", RUN+="keymap $name 0x84 wlan"
+ENV{DMI_VENDOR}="Dell*", ATTR{[dmi/id]product_name}="Inspiron 910|Inspiron 1011|Inspiron 1210", RUN+="keymap $name 0x84 wlan"
ENV{DMI_VENDOR}="Compaq*", ATTR{[dmi/id]product_name}="*E500*|*Evo N*", RUN+="keymap $name compaq-e_evo"
^ permalink raw reply related
* Re: [PATCH] Fix wlan key on Inspirion 1210
From: Martin Pitt @ 2010-05-29 17:32 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <1275078619.1654.108.camel@laptop>
Hey Jerone,
Jerone Young [2010-05-28 15:30 -0500]:
> This fixed wlan key on Inspirion 1210 machines.
Thanks! Pushed.
Martin
--
Martin Pitt | http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)
^ permalink raw reply
* Re: [PATCH 1/2] Export firmware assigned labels of network devices
From: Domsch, Matt @ 2010-05-29 4:51 UTC (permalink / raw)
To: Greg KH
Cc: K, Narendra, netdev@vger.kernel.org,
linux-hotplug@vger.kernel.org, linux-pci@vger.kernel.org,
Hargrave, Jordan, Rose, Charles, Nijhawan, Vijay
In-Reply-To: <20100528222745.GA28678@kroah.com>
On Fri, May 28, 2010 at 05:27:45PM -0500, Greg KH wrote:
> On Fri, May 28, 2010 at 01:11:00PM -0500, Matt Domsch wrote:
> > On Fri, May 28, 2010 at 08:40:41AM -0700, Greg KH wrote:
> > > On Fri, May 28, 2010 at 06:55:21AM -0500, K, Narendra wrote:
> > > > +static const char dell_dsm_uuid[] = {
> > >
> > > Um, a dell specific uuid in a generic file? What happens when we need
> > > to support another manufacturer?
> > >
> > > > + 0xD0, 0x37, 0xC9, 0xE5, 0x53, 0x35, 0x7A, 0x4D,
> > > > + 0x91, 0x17, 0xEA, 0x4D, 0x19, 0xC3, 0x43, 0x4D
> > > > +};
> >
> > This simply needs to be renamed. It's defined in the ECN, so will be
> > part of the spec, and is not vendor-unique, but defined once for all
> > implementations. It separates this _DSM function from others.
>
> Ok, that makes a bit more sense.
>
> Care to post that ECN publically? And no, the Linux Foundation does not
> have a PCI-SIG membership, the PCI-SIG keeps forbidding it. Other
> operating systems are allowed to join but not Linux. Strange but
> true...
I'm looking into it, and should know more next week.
--
Matt Domsch
Technology Strategist
Dell | Office of the CTO
^ permalink raw reply
* Re: [PATCH 1/2] Export firmware assigned labels of network devices
From: Greg KH @ 2010-05-28 22:27 UTC (permalink / raw)
To: Matt Domsch
Cc: K, Narendra, netdev@vger.kernel.org,
linux-hotplug@vger.kernel.org, linux-pci@vger.kernel.org,
Hargrave, Jordan, Rose, Charles, Nijhawan, Vijay
In-Reply-To: <20100528181100.GA12806@auslistsprd01.us.dell.com>
On Fri, May 28, 2010 at 01:11:00PM -0500, Matt Domsch wrote:
> On Fri, May 28, 2010 at 08:40:41AM -0700, Greg KH wrote:
> > On Fri, May 28, 2010 at 06:55:21AM -0500, K, Narendra wrote:
> > > +static const char dell_dsm_uuid[] = {
> >
> > Um, a dell specific uuid in a generic file? What happens when we need
> > to support another manufacturer?
> >
> > > + 0xD0, 0x37, 0xC9, 0xE5, 0x53, 0x35, 0x7A, 0x4D,
> > > + 0x91, 0x17, 0xEA, 0x4D, 0x19, 0xC3, 0x43, 0x4D
> > > +};
>
> This simply needs to be renamed. It's defined in the ECN, so will be
> part of the spec, and is not vendor-unique, but defined once for all
> implementations. It separates this _DSM function from others.
Ok, that makes a bit more sense.
Care to post that ECN publically? And no, the Linux Foundation does not
have a PCI-SIG membership, the PCI-SIG keeps forbidding it. Other
operating systems are allowed to join but not Linux. Strange but
true...
thanks,
greg k-h
^ permalink raw reply
* [PATCH] Fix wlan key on Inspirion 1210
From: Jerone Young @ 2010-05-28 20:30 UTC (permalink / raw)
To: linux-hotplug
This fixed wlan key on Inspirion 1210 machines.
Signed-off-by: Jerone Young <jerone.young@canonical.com>
diff --git a/extras/keymap/95-keymap.rules b/extras/keymap/95-keymap.rules
index 8c00ba1..c321fbb 100644
--- a/extras/keymap/95-keymap.rules
+++ b/extras/keymap/95-keymap.rules
@@ -53,7 +53,7 @@ GOTO="keyboard_end"
LABEL="keyboard_vendorcheck"
ENV{DMI_VENDOR}="Dell*", RUN+="keymap $name dell"
-ENV{DMI_VENDOR}="Dell*", ATTR{[dmi/id]product_name}="Inspiron 1011", RUN+="keymap $name 0x84 wlan"
+ENV{DMI_VENDOR}="Dell*", ATTR{[dmi/id]product_name}="Inspiron 1011|Inspiron 1210", RUN+="keymap $name 0x84 wlan"
ENV{DMI_VENDOR}="Compaq*", ATTR{[dmi/id]product_name}="*E500*|*Evo N*", RUN+="keymap $name compaq-e_evo"
^ permalink raw reply related
* Re: [PATCH 1/2] Export firmware assigned labels of network devices to sysfs
From: Matt Domsch @ 2010-05-28 18:11 UTC (permalink / raw)
To: Greg KH
Cc: K, Narendra, netdev@vger.kernel.org,
linux-hotplug@vger.kernel.org, linux-pci@vger.kernel.org,
Hargrave, Jordan, Rose, Charles, Nijhawan, Vijay
In-Reply-To: <20100528154041.GA27186@kroah.com>
On Fri, May 28, 2010 at 08:40:41AM -0700, Greg KH wrote:
> On Fri, May 28, 2010 at 06:55:21AM -0500, K, Narendra wrote:
> > +static const char dell_dsm_uuid[] = {
>
> Um, a dell specific uuid in a generic file? What happens when we need
> to support another manufacturer?
>
> > + 0xD0, 0x37, 0xC9, 0xE5, 0x53, 0x35, 0x7A, 0x4D,
> > + 0x91, 0x17, 0xEA, 0x4D, 0x19, 0xC3, 0x43, 0x4D
> > +};
This simply needs to be renamed. It's defined in the ECN, so will be
part of the spec, and is not vendor-unique, but defined once for all
implementations. It separates this _DSM function from others.
Thanks for the quick feedback.
Thanks,
Matt
--
Matt Domsch
Technology Strategist
Dell | Office of the CTO
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox