* [PATCH 1/2] Add virtio-blk support to path_id
From: Ryan Harper @ 2010-06-25 13:59 UTC (permalink / raw)
To: linux-hotplug; +Cc: john cooper, Rusty Russell, qemu-devel, Ryan Harper
In-Reply-To: <1277474363-6534-1-git-send-email-ryanh@us.ibm.com>
This patch adds a case handling path_id invoked on a virtio-blk device.
Currently path_id walks the parent path to virtio-pci but doesn't know
that it's the end of the path and exits without building the path (providing no
output resulting in no disk/by-path symlinks to virtio-blk devices).
This patch handles the virtio-pci path and updates the path accordingly.
/lib/udev/path_id --debug /block/vda
udev_device_new_from_syspath: device 0x2300120 has devpath '/devices/virtio-pci/virtio1/block/vda'
udev_device_new_from_syspath: device 0x2300380 has devpath '/devices/virtio-pci/virtio1'
udev_device_new_from_syspath: device 0x2300670 has devpath '/devices/virtio-pci'
ID_PATH=virtio-pci-virtio1
And with the current persistent-storage rules generates:
% ls -al /dev/disk/by-path | grep vda
lrwxrwxrwx. 1 root root 9 Jun 1 22:09 virtio-pci-virtio1 -> ../../vda
Signed-off-by: Ryan Harper <ryanh@us.ibm.com>
---
| 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
--git a/extras/path_id/path_id.c b/extras/path_id/path_id.c
index dcee378..c19bfd0 100644
--- a/extras/path_id/path_id.c
+++ b/extras/path_id/path_id.c
@@ -448,6 +448,9 @@ int main(int argc, char **argv)
} else if (strcmp(subsys, "xen") = 0) {
path_prepend(&path, "xen-%s", udev_device_get_sysname(parent));
parent = skip_subsystem(parent, "xen");
+ } else if (strcmp(subsys, "virtio") = 0) {
+ path_prepend(&path, "virtio-pci-%s", udev_device_get_sysname(parent));
+ parent = skip_subsystem(parent, "virtio");
}
parent = udev_device_get_parent(parent);
--
1.6.3.3
^ permalink raw reply related
* [PATCH 2/2] Add virtio-blk by-id rules based on 'serial' attribute
From: Ryan Harper @ 2010-06-25 13:59 UTC (permalink / raw)
To: linux-hotplug; +Cc: john cooper, Rusty Russell, qemu-devel, Ryan Harper
In-Reply-To: <1277474363-6534-1-git-send-email-ryanh@us.ibm.com>
Using virtio-blk serial attributes add rules to extract drive serial numbers and
generate by-id links for the block device and partitions.
With these rules added, we now see the following symlinks in disk/by-id
% ls -al /dev/disk/by-id | grep vdb
lrwxrwxrwx. 1 root root 9 Jun 1 22:09 virtio-QM00001 -> ../../vda
lrwxrwxrwx. 1 root root 10 Jun 1 22:09 virtio-QM00001-part1 -> ../../vda1
Signed-off-by: Ryan Harper <ryanh@us.ibm.com>
---
rules/rules.d/60-persistent-storage.rules | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/rules/rules.d/60-persistent-storage.rules b/rules/rules.d/60-persistent-storage.rules
index 1f46041..6449e07 100644
--- a/rules/rules.d/60-persistent-storage.rules
+++ b/rules/rules.d/60-persistent-storage.rules
@@ -18,6 +18,10 @@ TEST="whole_disk", GOTO="persistent_storage_end"
# for partitions import parent information
ENV{DEVTYPE}="partition", IMPORT{parent}="ID_*"
+# virtio-blk
+KERNEL="vd*[!0-9]", ATTRS{serial}="?*", ENV{ID_SERIAL}="$attr{serial}", SYMLINK+="disk/by-id/virtio-$env{ID_SERIAL}"
+KERNEL="vd*[0-9]", ATTRS{serial}="?*", ENV{ID_SERIAL}="$attr{serial}", SYMLINK+="disk/by-id/virtio-$env{ID_SERIAL}-part%n"
+
# USB devices use their own serial number
KERNEL="sd*[!0-9]|sr*", ENV{ID_SERIAL}!="?*", SUBSYSTEMS="usb", IMPORT{program}="usb_id --export %p"
# ATA devices with their own "ata" kernel subsystem
--
1.6.3.3
^ permalink raw reply related
* Re: udevadm Operations Resulting in Unmounted /proc and /sys?
From: Scott Talbert @ 2010-06-26 2:16 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <alpine.LRH.2.00.1006242343150.14034@bear.techie.net>
Hi Martin,
On Fri, 25 Jun 2010, Martin Pitt wrote:
>> udevadm trigger --subsystem-match=block --action=change
>>
>> After this command is issued, /proc and /sys appear to become
>> unmounted somehow
>
> Please do "ubuntu-bug mountall" and attach the following information:
>
> * "udevadm monitor -e --udev" output while you manually do above
> trigger command
> * "mount" output before and after the command
> * /etc/fstab (just in case..)
This bug has already been reported here:
https://bugs.launchpad.net/ubuntu/+source/udisks/+bug/554718
I have added the information you requested.
Thanks,
Scott
^ permalink raw reply
* [PATCH] Fix stuck volume key presses for Toshiba Satellite U300 &
From: Jerone Young @ 2010-06-28 3:35 UTC (permalink / raw)
To: linux-hotplug
This patch fixes stuck volume keys for Toshiba Satellite models U300 &
U305.
Signed-off-by: Jerone Young <jerone.young@canonical.com>
diff --git a/extras/keymap/95-keyboard-force-release.rules b/extras/keymap/95-keyboard-force-release.rules
index 36d569a..e75ddc0 100644
--- a/extras/keymap/95-keyboard-force-release.rules
+++ b/extras/keymap/95-keyboard-force-release.rules
@@ -31,4 +31,6 @@ ENV{DMI_VENDOR}="MTC", ATTR{[dmi/id]product_version}="A0", RUN+="keyboard-forc
ENV{DMI_VENDOR}="PEGATRON CORP.", ATTR{[dmi/id]product_name}="Spring Peak", RUN+="keyboard-force-release.sh $devpath common-volume-keys"
+ENV{DMI_VENDOR}="TOSHIBA", ATTR{[dmi/id]product_name}="Satellite U300|Satellite Pro U300|Satellite U305", RUN+="keyboard-force-release.sh $devpath common-volume-keys"
+
LABEL="force_release_end"
^ permalink raw reply related
* Re: [PATCH] Fix stuck volume key presses for Toshiba Satellite
From: Martin Pitt @ 2010-06-28 7:14 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <1277696144.1734.378.camel@laptop>
Hello Jerone,
Jerone Young [2010-06-27 22:35 -0500]:
> This patch fixes stuck volume keys for Toshiba Satellite models U300 &
> U305.
Thanks! Pushed.
Martin
--
Martin Pitt | http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)
^ permalink raw reply
* problem with commit "cdrom_id: Do not ignore errors from scsi_cmd_run()"
From: Gerardo Exequiel Pozzi @ 2010-06-28 23:55 UTC (permalink / raw)
To: linux-hotplug
Hello
I have a problem with this commit [#1] "cdrom_id: Do not ignore errors
from scsi_cmd_run()" and qemu-kvm-0.12.4.
running /lib/udev/cdrom_id /dev/sr0 does not return
ID_CDROM_MEDIA_TRACK_COUNT_DATA (there is a iso image specified on
qemu-kvm command line, so there is a media present)
Running with --debug show that error is produced (add below)
For working again I done:
1) Only reverting this commit [#1] "cdrom_id: Do not ignore errors from
scsi_cmd_run()"
2) Only revert revert the commit [#2] "cdrom_id: Swap media state and
TOC info probing"
In case (1) no error is displayed and ID_CDROM_MEDIA_TRACK_COUNT_DATA is
printed.
In case (2) error is displayed and ID_CDROM_MEDIA_TRACK_COUNT_DATA is
printed.
As result udev rule that uses this info will fail.
Tested on Linux 2.6.33.5 and 2.6.34, under 32 bits and 64 bits with the
same results.
If need more info, please let me know.
Thanks.
# /lib/udev/cdrom_id --debug /dev/sr0
main: probing: '/dev/sr0'
cd_inquiry: INQUIRY: [QEMU ][QEMU DVD-ROM ][0.12]
cd_profiles: GET CONFIGURATION: size of features buffer 0x0010
cd_profiles: GET CONFIGURATION: feature 'profiles', with 2 entries
feature_profiles: profile 0x10 dvd_rom
feature_profiles: profile 0x08 cd_rom
cd_profiles: current profile 0x08
cd_profiles: profile 0x08 media_cd_rom
info_scsi_cmd_err: READ DISC INFORMATION failed with SK=5h/ASC h/ACQ\0h
ID_CDROM=1
ID_CDROM_CD=1
ID_CDROM_DVD=1
ID_CDROM_MRW=1
ID_CDROM_MRW_W=1
ID_CDROM_MEDIA=1
ID_CDROM_MEDIA_CD=1
[#1]
http://git.kernel.org/?p=linux/hotplug/udev.git;a=commitdiff;hXe178894bfc040834e1270c6fe9b9fdef513550#patch1
[#2]
http://git.kernel.org/?p=linux/hotplug/udev.git;a=commitdiff;h0e3b1a0d3a3ec76f16736470dc656744848d941
--
Gerardo Exequiel Pozzi
\cos^2\alpha + \sin^2\alpha = 1
^ permalink raw reply
* Re: problem with commit "cdrom_id: Do not ignore errors from scsi_cmd_run()"
From: Harald Hoyer @ 2010-06-29 10:38 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <4C293677.3030308@yahoo.com.ar>
On 06/29/2010 01:55 AM, Gerardo Exequiel Pozzi wrote:
> Hello
>
> I have a problem with this commit [#1] "cdrom_id: Do not ignore errors
> from scsi_cmd_run()" and qemu-kvm-0.12.4.
>
> running /lib/udev/cdrom_id /dev/sr0 does not return
> ID_CDROM_MEDIA_TRACK_COUNT_DATA (there is a iso image specified on
> qemu-kvm command line, so there is a media present)
> Running with --debug show that error is produced (add below)
>
> For working again I done:
> 1) Only reverting this commit [#1] "cdrom_id: Do not ignore errors from
> scsi_cmd_run()"
> 2) Only revert revert the commit [#2] "cdrom_id: Swap media state and
> TOC info probing"
>
> In case (1) no error is displayed and ID_CDROM_MEDIA_TRACK_COUNT_DATA is
> printed.
> In case (2) error is displayed and ID_CDROM_MEDIA_TRACK_COUNT_DATA is
> printed.
>
> As result udev rule that uses this info will fail.
>
> Tested on Linux 2.6.33.5 and 2.6.34, under 32 bits and 64 bits with the
> same results.
>
> If need more info, please let me know.
>
> Thanks.
>
> # /lib/udev/cdrom_id --debug /dev/sr0
> main: probing: '/dev/sr0'
> cd_inquiry: INQUIRY: [QEMU ][QEMU DVD-ROM ][0.12]
> cd_profiles: GET CONFIGURATION: size of features buffer 0x0010
> cd_profiles: GET CONFIGURATION: feature 'profiles', with 2 entries
> feature_profiles: profile 0x10 dvd_rom
> feature_profiles: profile 0x08 cd_rom
> cd_profiles: current profile 0x08
> cd_profiles: profile 0x08 media_cd_rom
> info_scsi_cmd_err: READ DISC INFORMATION failed with SK=5h/ASC h/ACQ\0h
> ID_CDROM=1
> ID_CDROM_CD=1
> ID_CDROM_DVD=1
> ID_CDROM_MRW=1
> ID_CDROM_MRW_W=1
> ID_CDROM_MEDIA=1
> ID_CDROM_MEDIA_CD=1
>
>
> [#1]
> http://git.kernel.org/?p=linux/hotplug/udev.git;a=commitdiff;hXe178894bfc040834e1270c6fe9b9fdef513550#patch1
>
> [#2]
> http://git.kernel.org/?p=linux/hotplug/udev.git;a=commitdiff;h0e3b1a0d3a3ec76f16736470dc656744848d941
>
>
Apparently qemu does not implement the scsi "READ DISC INFORMATION" command for
cdroms.
Filed on the Red Hat bugzilla https://bugzilla.redhat.com/show_bug.cgi?id`9049
^ permalink raw reply
* Re: [PATCH 1/3] Add virtioblk_id tool to extract drive serial numbers
From: Ryan Harper @ 2010-06-29 14:48 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <1275592024-2625-2-git-send-email-ryanh@us.ibm.com>
* Kay Sievers <kay.sievers@vrfy.org> [2010-06-14 08:30]:
> On Mon, Jun 14, 2010 at 15:15, Ryan Harper <ryanh@us.ibm.com> wrote:
> > * Kay Sievers <kay.sievers@vrfy.org> [2010-06-14 03:55]:
> >> On Thu, Jun 10, 2010 at 21:16, Ryan Harper <ryanh@us.ibm.com> wrote:
> >> > 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_SERIAL=QM00001
> >> > ID_SERIAL_SHORT=QM00001
> >>
> >> As requested in the ealier mail. Please provide a good reason why the
> >> kernel code can not create a "serial" file (or whatever fits your
> >> needs) in sysfs at the block device.
> >
> > I didn't see you respond John's email:
> >
> > http://www.spinics.net/lists/hotplug/msg03869.html
> >
> > which included quite bit of the gory history on this topic.
>
> Yeah, and I don't find any reason there, why a sysfs attribute will not work.
You were quite right; the sysfs attribute route was rather simple.
Thanks for pointing me in the right direction. We've got the
kernel-side fix picked up. I've posted v3 of this series that uses the
sysfs attribute.
Thanks!
--
Ryan Harper
Software Engineer; Linux Technology Center
IBM Corp., Austin, Tx
ryanh@us.ibm.com
^ permalink raw reply
* Re: [PATCH v3 0/2] Add virtio-blk support to persistent-storage rules
From: Kay Sievers @ 2010-06-29 15:29 UTC (permalink / raw)
To: Ryan Harper; +Cc: john cooper, Rusty Russell, linux-hotplug, qemu-devel
In-Reply-To: <1277474363-6534-1-git-send-email-ryanh@us.ibm.com>
On Fri, Jun 25, 2010 at 15:59, Ryan Harper <ryanh@us.ibm.com> wrote:
> 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)[2] to
> generate the by-id path; however if the guest or host qemu isn't capable
> then no action is taken.
Thanks for solving it in this much simpler way. Both patches applied.
Kay
^ permalink raw reply
* Re: [PATCH 1/2] Export firmware assigned labels of network devices to sysfs
From: Narendra K @ 2010-06-29 16:28 UTC (permalink / raw)
To: greg, matt_domsch
Cc: netdev, linux-hotplug, linux-pci, jordan_hargrave, charles_rose,
vijay_nijhawan
In-Reply-To: <EDA0A4495861324DA2618B4C45DCB3EE612AB6@blrx3m08.blr.amer.dell.com>
> From: Greg KH [mailto:greg@kroah.com]
> Sent: Wednesday, June 09, 2010 8:33 PM
> To: Domsch, Matt
> 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 Tue, Jun 08, 2010 at 11:17:09PM -0500, Matt Domsch wrote:
> > On Fri, May 28, 2010 at 11:51:40PM -0500, Domsch, Matt wrote:
> > > On Fri, May 28, 2010 at 05:27:45PM -0500, Greg KH wrote:
> > > > 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.
> >
> > I'm advised that I cannot post the ECN publically, due to it being an
> > in-progress work item of a SIG working group, and therefore falls
> > under the confidentiality rules that SIG members agree to. Members of
> > the PCI SIG have access, which unfortunately is not everyone.
>
> Then we can't properly review this, sorry. How about waiting until the
> ECN is finalized? Then we could review and possibly accept this.
>
As the ACPI ECR might take some time to become public, we have split the
original patch into SMBIOS and ACPI parts and would want to get the SMBIOS
part to get reviewed/accepted. Once the ECR is publicly available, we
would submit the ACPI specific patch.
Please find the patch addressing the SMBIOS part below -
From: Narendra K <narendra_k@dell.com>
Subject: [PATCH] Export SMBIOS provided firmware instance and lable to sysfs
This patch exports SMBIOS provided firmware instance and label of
onboard pci devices to sysfs
Signed-off-by: Jordan Hargrave <jordan_hargrave@dell.com>
Signed-off-by: Narendra K <narendra_k@dell.com>
---
drivers/firmware/dmi_scan.c | 25 ++++++++
drivers/pci/Makefile | 2 +-
drivers/pci/pci-label.c | 140 +++++++++++++++++++++++++++++++++++++++++++
drivers/pci/pci-sysfs.c | 5 ++
drivers/pci/pci.h | 2 +
include/linux/dmi.h | 9 +++
6 files changed, 182 insertions(+), 1 deletions(-)
create mode 100644 drivers/pci/pci-label.c
diff --git a/drivers/firmware/dmi_scan.c b/drivers/firmware/dmi_scan.c
index d464672..ce73fcc 100644
--- a/drivers/firmware/dmi_scan.c
+++ b/drivers/firmware/dmi_scan.c
@@ -277,6 +277,29 @@ static void __init dmi_save_ipmi_device(const struct dmi_header *dm)
list_add_tail(&dev->list, &dmi_devices);
}
+static void __init dmi_save_dev_onboard(int instance, int segment, int bus,
+ int devfn, const char *name)
+{
+ struct dmi_dev_onboard *onboard_dev;
+
+ onboard_dev = dmi_alloc(sizeof(*onboard_dev) + strlen(name) + 1);
+ if (!onboard_dev) {
+ printk(KERN_ERR "dmi_save_dev_onboard: out of memory.\n");
+ return;
+ }
+ onboard_dev->instance = instance;
+ onboard_dev->segment = segment;
+ onboard_dev->bus = bus;
+ onboard_dev->devfn = devfn;
+
+ strcpy((char *)&onboard_dev[1], name);
+ onboard_dev->dev.type = DMI_DEV_TYPE_DEV_ONBOARD;
+ onboard_dev->dev.name = (char *)&onboard_dev[1];
+ onboard_dev->dev.device_data = onboard_dev;
+
+ list_add(&onboard_dev->dev.list, &dmi_devices);
+}
+
static void __init dmi_save_extended_devices(const struct dmi_header *dm)
{
const u8 *d = (u8*) dm + 5;
@@ -285,6 +308,7 @@ static void __init dmi_save_extended_devices(const struct dmi_header *dm)
if ((*d & 0x80) = 0)
return;
+ dmi_save_dev_onboard(*(d+1), *(u16 *)(d+2), *(d+4), *(d+5), dmi_string_nosave(dm, *(d-1)));
dmi_save_one_device(*d & 0x7f, dmi_string_nosave(dm, *(d - 1)));
}
@@ -333,6 +357,7 @@ static void __init dmi_decode(const struct dmi_header *dm, void *dummy)
break;
case 41: /* Onboard Devices Extended Information */
dmi_save_extended_devices(dm);
+ break;
}
}
diff --git a/drivers/pci/Makefile b/drivers/pci/Makefile
index 0b51857..69c503a 100644
--- a/drivers/pci/Makefile
+++ b/drivers/pci/Makefile
@@ -4,7 +4,7 @@
obj-y += access.o bus.o probe.o remove.o pci.o \
pci-driver.o search.o pci-sysfs.o rom.o setup-res.o \
- irq.o vpd.o
+ irq.o vpd.o pci-label.o
obj-$(CONFIG_PROC_FS) += proc.o
obj-$(CONFIG_SYSFS) += slot.o
diff --git a/drivers/pci/pci-label.c b/drivers/pci/pci-label.c
new file mode 100644
index 0000000..0f824d6
--- /dev/null
+++ b/drivers/pci/pci-label.c
@@ -0,0 +1,140 @@
+/*
+ * Purpose: Export the firmware instance/index and label associated with
+ * a pci device to sysfs
+ * Copyright (C) 2010 Dell Inc.
+ * by Narendra K <Narendra_K@dell.com>, Jordan Hargrave <Jordan_Hargrave@dell.com>
+ *
+ * SMBIOS defines type 41 for onboard pci devices. This code retrieves
+ * the instance number and string from the type 41 record and exports
+ * it to sysfs.
+ *
+ * Please see http://linux.dell.com/wiki/index.php/Oss/libnetdevname for more
+ * information.
+ */
+
+#include <linux/dmi.h>
+#include <linux/sysfs.h>
+#include <linux/pci.h>
+#include <linux/pci_ids.h>
+#include <linux/module.h>
+#include "pci.h"
+
+#ifndef CONFIG_DMI
+
+static inline int
+pci_create_smbiosname_file(struct pci_dev *pdev)
+{
+ return -1;
+}
+
+static inline int
+pci_remove_smbiosname_file(struct pci_dev *pdev)
+{
+ return -1;
+}
+
+#else
+
+struct smbios_attribute {
+ struct attribute attr;
+ ssize_t (*show) (struct device *dev, struct device_attribute *, char *buf);
+ ssize_t (*test) (struct device *dev, char *buf, char *attribute);
+};
+
+static ssize_t
+smbios_instance_string_exist(struct device *dev, char *buf, char *attribute)
+{
+ struct pci_dev *pdev = to_pci_dev(dev);
+ const struct dmi_device *dmi;
+ struct dmi_dev_onboard *donboard;
+ int bus;
+ int devfn;
+ int attribute_is_instance = 0;
+
+ bus = pdev->bus->number;
+ devfn = pdev->devfn;
+
+ if (attribute && !strncmp(attribute, "instance", strlen(attribute)))
+ attribute_is_instance=1;
+
+ dmi = NULL;
+ while ((dmi = dmi_find_device(DMI_DEV_TYPE_DEV_ONBOARD, NULL, dmi)) != NULL) {
+ donboard = dmi->device_data;
+ if (donboard && donboard->bus = bus && donboard->devfn = devfn) {
+ if (buf) {
+ if (attribute_is_instance)
+ return scnprintf(buf, PAGE_SIZE,
+ "%d\n", donboard->instance);
+ else
+ return scnprintf(buf, PAGE_SIZE,
+ "%s\n", dmi->name);
+ }
+ return strlen(dmi->name);
+ }
+ }
+
+ return 0;
+}
+
+static ssize_t
+smbiosname_show(struct device *dev, struct device_attribute *attr, char *buf)
+{
+ return smbios_instance_string_exist(dev, buf, "label");
+}
+
+static ssize_t
+smbiosinstance_show(struct device *dev, struct device_attribute *attr, char *buf)
+{
+ return smbios_instance_string_exist(dev, buf, "instance");
+}
+
+struct smbios_attribute smbios_attr_label = {
+ .attr = {.name = "label", .mode = 0444, .owner = THIS_MODULE},
+ .show = smbiosname_show,
+ .test = smbios_instance_string_exist,
+};
+
+struct smbios_attribute smbios_attr_instance = {
+ .attr = {.name = "index", .mode = 0444, .owner = THIS_MODULE},
+ .show = smbiosinstance_show,
+ .test = smbios_instance_string_exist,
+};
+
+static int
+pci_create_smbiosname_file(struct pci_dev *pdev)
+{
+ if (smbios_attr_label.test && smbios_attr_label.test(&pdev->dev, NULL, NULL)) {
+ if (sysfs_create_file(&pdev->dev.kobj, &smbios_attr_label.attr))
+ return -1;
+ if (sysfs_create_file(&pdev->dev.kobj, &smbios_attr_instance.attr))
+ return -1;
+ return 0;
+ }
+ return -1;
+}
+
+static int
+pci_remove_smbiosname_file(struct pci_dev *pdev)
+{
+ if (smbios_attr_label.test && smbios_attr_label.test(&pdev->dev, NULL, NULL)) {
+ sysfs_remove_file(&pdev->dev.kobj, &smbios_attr_label.attr);
+ sysfs_remove_file(&pdev->dev.kobj, &smbios_attr_instance.attr);
+ return 0;
+ }
+ return -1;
+}
+#endif
+
+int pci_create_firmware_label_files(struct pci_dev *pdev)
+{
+ if (!pci_create_smbiosname_file(pdev))
+ return 0;
+ return -ENODEV;
+}
+
+int pci_remove_firmware_label_files(struct pci_dev *pdev)
+{
+ if (!pci_remove_smbiosname_file(pdev))
+ return 0;
+ return -ENODEV;
+}
diff --git a/drivers/pci/pci-sysfs.c b/drivers/pci/pci-sysfs.c
index c9957f6..2e2e69c 100644
--- a/drivers/pci/pci-sysfs.c
+++ b/drivers/pci/pci-sysfs.c
@@ -1097,6 +1097,8 @@ int __must_check pci_create_sysfs_dev_files (struct pci_dev *pdev)
if (retval)
goto err_vga_file;
+ pci_create_firmware_label_files(pdev);
+
return 0;
err_vga_file:
@@ -1164,6 +1166,9 @@ void pci_remove_sysfs_dev_files(struct pci_dev *pdev)
sysfs_remove_bin_file(&pdev->dev.kobj, pdev->rom_attr);
kfree(pdev->rom_attr);
}
+
+ pci_remove_firmware_label_files(pdev);
+
}
static int __init pci_sysfs_init(void)
diff --git a/drivers/pci/pci.h b/drivers/pci/pci.h
index f8077b3..a0f160d 100644
--- a/drivers/pci/pci.h
+++ b/drivers/pci/pci.h
@@ -11,6 +11,8 @@
extern int pci_uevent(struct device *dev, struct kobj_uevent_env *env);
extern int pci_create_sysfs_dev_files(struct pci_dev *pdev);
extern void pci_remove_sysfs_dev_files(struct pci_dev *pdev);
+extern int pci_create_firmware_label_files(struct pci_dev *pdev);
+extern int pci_remove_firmware_label_files(struct pci_dev *pdev);
extern void pci_cleanup_rom(struct pci_dev *dev);
#ifdef HAVE_PCI_MMAP
extern int pci_mmap_fits(struct pci_dev *pdev, int resno,
diff --git a/include/linux/dmi.h b/include/linux/dmi.h
index a8a3e1a..90e087f 100644
--- a/include/linux/dmi.h
+++ b/include/linux/dmi.h
@@ -20,6 +20,7 @@ enum dmi_device_type {
DMI_DEV_TYPE_SAS,
DMI_DEV_TYPE_IPMI = -1,
DMI_DEV_TYPE_OEM_STRING = -2,
+ DMI_DEV_TYPE_DEV_ONBOARD = -3,
};
struct dmi_header {
@@ -37,6 +38,14 @@ struct dmi_device {
#ifdef CONFIG_DMI
+struct dmi_dev_onboard {
+ struct dmi_device dev;
+ int instance;
+ int segment;
+ int bus;
+ int devfn;
+};
+
extern int dmi_check_system(const struct dmi_system_id *list);
const struct dmi_system_id *dmi_first_match(const struct dmi_system_id *list);
extern const char * dmi_get_system_info(int field);
--
1.6.5.2
With regards,
Narendra K
^ permalink raw reply related
* HAL Daemon, Red Hat MRG, and Sealevel
From: David Pierce @ 2010-06-29 20:25 UTC (permalink / raw)
To: linux-hotplug
Hello,
My hardware platform has a Supermicro C2SBC-Q motherboard. With Red Hat
Enterprise Linux 5 and the 2.6.24.7-149.el5rt realtime kernel and a
Sealevel 5102 synchronous serial communications card plugged in the PCI
bus, the HAL daemon hangs during boot. There is no way to view a precise
error indication as the system is totally locked up. This problem does
not happen when booting with the more vanilla Red Hat Enterprise Linux 5
2.6.18-194.el5 kernel. I've informed both Sealevel and Red Hat about this
problem. After a month I still do not have an adequate explanation why
this is happening from either vendor.
Udev may provide an explanation. Please comment.
Regards,
--
David Pierce
Delphi Research, Inc.
3954 Murphy Canyon Rd S. D-201
San Diego, CA 92123
(858) 694-1314 x207
(858) 337-0750 cell
^ permalink raw reply
* Re: problem with commit "cdrom_id: Do not ignore errors from scsi_cmd_run()"
From: Harald Hoyer @ 2010-06-30 10:09 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <4C293677.3030308@yahoo.com.ar>
On 06/29/2010 12:38 PM, Harald Hoyer wrote:
> On 06/29/2010 01:55 AM, Gerardo Exequiel Pozzi wrote:
>> Hello
>>
>> I have a problem with this commit [#1] "cdrom_id: Do not ignore errors
>> from scsi_cmd_run()" and qemu-kvm-0.12.4.
>>
>> running /lib/udev/cdrom_id /dev/sr0 does not return
>> ID_CDROM_MEDIA_TRACK_COUNT_DATA (there is a iso image specified on
>> qemu-kvm command line, so there is a media present)
>> Running with --debug show that error is produced (add below)
>>
>> For working again I done:
>> 1) Only reverting this commit [#1] "cdrom_id: Do not ignore errors from
>> scsi_cmd_run()"
>> 2) Only revert revert the commit [#2] "cdrom_id: Swap media state and
>> TOC info probing"
>>
>> In case (1) no error is displayed and ID_CDROM_MEDIA_TRACK_COUNT_DATA is
>> printed.
>> In case (2) error is displayed and ID_CDROM_MEDIA_TRACK_COUNT_DATA is
>> printed.
>>
>> As result udev rule that uses this info will fail.
>>
>> Tested on Linux 2.6.33.5 and 2.6.34, under 32 bits and 64 bits with the
>> same results.
>>
>> If need more info, please let me know.
>>
>> Thanks.
>>
>> # /lib/udev/cdrom_id --debug /dev/sr0
>> main: probing: '/dev/sr0'
>> cd_inquiry: INQUIRY: [QEMU ][QEMU DVD-ROM ][0.12]
>> cd_profiles: GET CONFIGURATION: size of features buffer 0x0010
>> cd_profiles: GET CONFIGURATION: feature 'profiles', with 2 entries
>> feature_profiles: profile 0x10 dvd_rom
>> feature_profiles: profile 0x08 cd_rom
>> cd_profiles: current profile 0x08
>> cd_profiles: profile 0x08 media_cd_rom
>> info_scsi_cmd_err: READ DISC INFORMATION failed with
>> SK=5h/ASC h/ACQ\0h
>> ID_CDROM=1
>> ID_CDROM_CD=1
>> ID_CDROM_DVD=1
>> ID_CDROM_MRW=1
>> ID_CDROM_MRW_W=1
>> ID_CDROM_MEDIA=1
>> ID_CDROM_MEDIA_CD=1
>>
>>
>> [#1]
>> http://git.kernel.org/?p=linux/hotplug/udev.git;a=commitdiff;hXe178894bfc040834e1270c6fe9b9fdef513550#patch1
>>
>>
>> [#2]
>> http://git.kernel.org/?p=linux/hotplug/udev.git;a=commitdiff;h0e3b1a0d3a3ec76f16736470dc656744848d941
>>
>>
>>
>
> Apparently qemu does not implement the scsi "READ DISC INFORMATION"
> command for cdroms.
>
> Filed on the Red Hat bugzilla
> https://bugzilla.redhat.com/show_bug.cgi?id`9049
Comment of Gerardo Exequiel Pozzi
Additional note: This only fail with IDE cd-rom, SCSI cd-rom works OK
With "-drive file=xyz.iso,if=scsi,mediaÍrom" works fine, but with "-drive
file=xyz.iso,if=ide,mediaÍrom" (or directly -cdrom) fails.
^ permalink raw reply
* Re: [PATCH 1/2] Export firmware assigned labels of network devices
From: Greg KH @ 2010-06-30 15:42 UTC (permalink / raw)
To: Narendra K
Cc: matt_domsch, netdev, linux-hotplug, linux-pci, jordan_hargrave,
charles_rose, vijay_nijhawan
In-Reply-To: <20100629162818.GA17099@auslistsprd01.us.dell.com>
On Tue, Jun 29, 2010 at 11:28:18AM -0500, Narendra K wrote:
> --- a/drivers/pci/Makefile
> +++ b/drivers/pci/Makefile
> @@ -4,7 +4,7 @@
>
> obj-y += access.o bus.o probe.o remove.o pci.o \
> pci-driver.o search.o pci-sysfs.o rom.o setup-res.o \
> - irq.o vpd.o
> + irq.o vpd.o pci-label.o
No, only build this if CONFIG_DMI is set.
> diff --git a/drivers/pci/pci-label.c b/drivers/pci/pci-label.c
> new file mode 100644
> index 0000000..0f824d6
> --- /dev/null
> +++ b/drivers/pci/pci-label.c
> @@ -0,0 +1,140 @@
> +/*
> + * Purpose: Export the firmware instance/index and label associated with
> + * a pci device to sysfs
> + * Copyright (C) 2010 Dell Inc.
> + * by Narendra K <Narendra_K@dell.com>, Jordan Hargrave <Jordan_Hargrave@dell.com>
> + *
> + * SMBIOS defines type 41 for onboard pci devices. This code retrieves
> + * the instance number and string from the type 41 record and exports
> + * it to sysfs.
> + *
> + * Please see http://linux.dell.com/wiki/index.php/Oss/libnetdevname for more
> + * information.
> + */
> +
> +#include <linux/dmi.h>
> +#include <linux/sysfs.h>
> +#include <linux/pci.h>
> +#include <linux/pci_ids.h>
> +#include <linux/module.h>
> +#include "pci.h"
> +
> +#ifndef CONFIG_DMI
> +
> +static inline int
> +pci_create_smbiosname_file(struct pci_dev *pdev)
> +{
> + return -1;
> +}
> +
> +static inline int
> +pci_remove_smbiosname_file(struct pci_dev *pdev)
> +{
> + return -1;
> +}
> +
> +#else
The above Makefile change will allow you to remove these, right? You
don't want to create the files if there is nothing that can be in them,
right?
> +pci_create_smbiosname_file(struct pci_dev *pdev)
> +{
> + if (smbios_attr_label.test && smbios_attr_label.test(&pdev->dev, NULL, NULL)) {
> + if (sysfs_create_file(&pdev->dev.kobj, &smbios_attr_label.attr))
> + return -1;
What's wrong with the 'device_create_file' calls?
thanks,
greg k-h
^ permalink raw reply
* Smartphone support
From: Juanje Ojeda @ 2010-07-01 1:05 UTC (permalink / raw)
To: linux-hotplug
[-- Attachment #1: Type: text/plain, Size: 1062 bytes --]
Hi guys :-)
I was trying to debug my Android based phone (Nexus One) and I found
that I needed some extra permissions. I also found a bug about it[1]
which was solved by adding ACL to the specific model so it could work.
This change was made at revision 4fe41ac at the 70-acl.rules file.
The problem with that is that the line has idVendor and idProduct, so
the new models from the same vendor (HTC) are not supported. But there
are new vendors with a lot of models. The list is almost (the Nexus
One is missing) updated at the Android developer site:
http://developer.android.com/guide/developing/device.html#VendorIds
I think if we left just the idVendor we won't need to update the list
so much and the list will keep sorter.
I've removed the idProduct and added the whole list of vendors and
works for me. With my Nexus One. It should be working with any HTC,
Motorola, etc with Android.
I've attached the patch in case you guys see this change good and useful.
Greetings
[1] https://bugs.launchpad.net/ubuntu/+source/udev/+bug/316215
--
Juanje Ojeda
[-- Attachment #2: 0001-Added-udev-acl-tag-to-the-new-android-based-smartpho.patch --]
[-- Type: text/x-patch, Size: 2425 bytes --]
From 8f92370b6102f8b811db9c2ce19d33ecdd77d925 Mon Sep 17 00:00:00 2001
From: Juanje Ojeda <jojeda@emergya.es>
Date: Thu, 1 Jul 2010 02:41:51 +0200
Subject: [PATCH] Added udev-acl tag to the new android based smartphones
It was just supported the G1 but now there are lots of new
devices. As long as each vendor has many models and Adndroid
developer site recomend to use just the idVendor, the idProduct
has been removed, so the new models from those vendors will be
supported.
The list of vendors has been extracted from:
http://developer.android.com/guide/developing/device.html#VendorIds
And it has been added the Google Nexus One, which wasn't in that list.
Signed-off-by: Juanje Ojeda <jojeda@emergya.es>
---
| 17 ++++++++++++++++-
1 files changed, 16 insertions(+), 1 deletions(-)
--git a/extras/udev-acl/70-acl.rules b/extras/udev-acl/70-acl.rules
index 8300ec2..7a12f4f 100644
--- a/extras/udev-acl/70-acl.rules
+++ b/extras/udev-acl/70-acl.rules
@@ -65,7 +65,22 @@ ENV{ID_SMARTCARD_READER}=="*?", TAG+="udev-acl"
SUBSYSTEM=="input", ENV{ID_INPUT_JOYSTICK}=="?*", TAG+="udev-acl"
# smart phones
-SUBSYSTEM=="usb", ATTR{idVendor}=="0bb4", ATTR{idProduct}=="0c02", TAG+="udev-acl"
+SUBSYSTEM=="usb", ATTR{idVendor}=="0502", TAG+="udev-acl" # Acer
+SUBSYSTEM=="usb", ATTR{idVendor}=="413c", TAG+="udev-acl" # Dell
+SUBSYSTEM=="usb", ATTR{idVendor}=="043c", TAG+="udev-acl" # Foxconn
+SUBSYSTEM=="usb", ATTR{idVendor}=="091e", TAG+="udev-acl" # Garmin-Asus
+SUBSYSTEM=="usb", ATTR{idVendor}=="0bb4", TAG+="udev-acl" # HTC
+SUBSYSTEM=="usb", ATTR{idVendor}=="12d1", TAG+="udev-acl" # Huawei
+SUBSYSTEM=="usb", ATTR{idVendor}=="0482", TAG+="udev-acl" # Kyocera
+SUBSYSTEM=="usb", ATTR{idVendor}=="1004", TAG+="udev-acl" # LG
+SUBSYSTEM=="usb", ATTR{idVendor}=="22b8", TAG+="udev-acl" # Motorola
+SUBSYSTEM=="usb", ATTR{idVendor}=="0955", TAG+="udev-acl" # Nvidia
+SUBSYSTEM=="usb", ATTR{idVendor}=="10a9", TAG+="udev-acl" # Pantech
+SUBSYSTEM=="usb", ATTR{idVendor}=="04e8", TAG+="udev-acl" # Sansung
+SUBSYSTEM=="usb", ATTR{idVendor}=="04dd", TAG+="udev-acl" # Sharp
+SUBSYSTEM=="usb", ATTR{idVendor}=="0fce", TAG+="udev-acl" # Sony Ericsson
+SUBSYSTEM=="usb", ATTR{idVendor}=="19d2", TAG+="udev-acl" # ZTE
+SUBSYSTEM=="usb", ATTR{idVendor}=="18d1", TAG+="udev-acl" # Nexus One
# color measurement devices
ENV{COLOR_MEASUREMENT_DEVICE}=="*?", TAG+="udev-acl"
--
1.7.0.4
^ permalink raw reply related
* Re: [PATCH] keymap: Add support for IBM-branded USB devices
From: Martin Pitt @ 2010-07-02 13:53 UTC (permalink / raw)
To: linux-hotplug
Hello Matthew,
Matthew Garrett [2010-04-01 14:22 -0400]:
> These seem to use a different layout to the Lenovo-branded devices
Whoops, sorry that this slipped through the cracks. Applied to trunk
now.
Thanks!
Martin
--
Martin Pitt | http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)
^ permalink raw reply
* udev Logitech MX5500 and Logitech DiNovo support
From: robert meijers @ 2010-07-04 19:34 UTC (permalink / raw)
To: linux-hotplug
[-- Attachment #1: Type: text/plain, Size: 571 bytes --]
Hi,
In udev 158 my Logitech MX5500 keyboard and mouse combo didn't work.
To get it working I had to patch the 70-hid2hci.rules file. In the
Arch Linux bugtracker there was also a bug report for the same
keyboard and mouse combo (FS#20039
http://bugs.archlinux.org/task/20039) in which someone reported the
Logitech DiNovo keyboard and mouse combo didn't work either so the
hid2hci rules had to be changed again. Now both keyboard and mouse
combos work fine so I would like to send in the patch (attached,
generated using git format-patch).
Kind regards,
Robert Meijers
[-- Attachment #2: hid2hci.patch --]
[-- Type: application/octet-stream, Size: 1192 bytes --]
From a523992d28d4f8f7035dd41cc99d3e5773789bc6 Mon Sep 17 00:00:00 2001
From: Robert <robert.meijers@gmail.com>
Date: Sun, 4 Jul 2010 20:35:43 +0200
Subject: [PATCH] Match Logitech MX 5500 against hidraw
---
| 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
--git a/extras/hid2hci/70-hid2hci.rules b/extras/hid2hci/70-hid2hci.rules
index c5528f0..55944b3 100644
--- a/extras/hid2hci/70-hid2hci.rules
+++ b/extras/hid2hci/70-hid2hci.rules
@@ -11,9 +11,9 @@ ATTR{bInterfaceClass}=="03", ATTR{bInterfaceSubClass}=="01", ATTR{bInterfaceProt
RUN+="hid2hci --method=dell --devpath=%p", ENV{HID2HCI_SWITCH}="1"
# Logitech devices (hidraw)
-KERNEL=="hiddev*", ATTRS{idVendor}=="046d", ATTRS{idProduct}=="c70[345bce]|c71[34bc]", \
+KERNEL=="hiddev*", ATTRS{idVendor}=="046d", ATTRS{idProduct}=="c70[345e]|c71[34]", \
RUN+="hid2hci --method=logitech-hid --devpath=%p"
-KERNEL=="hidraw*", ATTRS{idVendor}=="046d", ATTRS{idProduct}=="c70a", \
+KERNEL=="hidraw*", ATTRS{idVendor}=="046d", ATTRS{idProduct}=="c70[abc]|c71[bc]", \
RUN+="hid2hci --method=logitech-hid --devpath=%p"
ENV{DEVTYPE}!="usb_device", GOTO="hid2hci_end"
--
1.7.1.1
^ permalink raw reply related
* UDEV - DRIVER parameter
From: Lee Jones @ 2010-07-06 10:29 UTC (permalink / raw)
To: linux-hotplug
Very quick one for you.
How do you raise the DRIVER parameter from the kernel?
When I register the device the following is produced:
KERNEL[946692859.898376] add /devices/platform/**** (platform)
UDEV_LOG=3
ACTIONd
DEVPATH=/devices/platform/****
SUBSYSTEM=platform
MODALIAS=platform:****
SEQNUMs5
But I need the DRIVER parameter, i.e:
DRIVER=****
Kind regards,
Lee
^ permalink raw reply
* Re: UDEV - DRIVER parameter
From: Kay Sievers @ 2010-07-06 11:08 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <4C33057C.10805@canonical.com>
On Tue, Jul 6, 2010 at 12:29, Lee Jones <lee.jones@canonical.com> wrote:
> How do you raise the DRIVER parameter from the kernel?
>
> When I register the device the following is produced:
>
> KERNEL[946692859.898376] add    /devices/platform/**** (platform)
> UDEV_LOG=3
> ACTIONd
> DEVPATH=/devices/platform/****
> SUBSYSTEM=platform
> MODALIAS=platform:****
> SEQNUMs5
>
> But I need the DRIVER parameter, i.e:
> DRIVER=****
Only some devices have a driver bound. Only "bus" devices, "class"
devices never have a driver.
It's just the symlink "driver" in /sys in the device directory.
Your platform device may just be a plain registered device, and not
probed and bound by a driver in that sense. Usually only enumeratable
buses have drivers that create devices when they are discovered.
Kay
^ permalink raw reply
* Re: UDEV - DRIVER parameter
From: Lee Jones @ 2010-07-06 11:28 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <4C33057C.10805@canonical.com>
> Only some devices have a driver bound. Only "bus" devices, "class"
> devices never have a driver.
>
> It's just the symlink "driver" in /sys in the device directory.
>
> Your platform device may just be a plain registered device, and not
> probed and bound by a driver in that sense. Usually only enumeratable
> buses have drivers that create devices when they are discovered.
I guess I'd better tell you the full story then.
I am working on a driver (module) that provides a direct link "CPU <-> Video Codec", which I believe is non-discoverable.
I figured that I'd be able to send the uevent by registering the device as a platform one in architecture specific code.
A uevent is sent, but it is missing the DRIVER parameter.
This is the generic parameter which is used in the udev rules.
/lib/udev/rules.d/80-drivers.rules, DRIVER!="?*", ENV{MODALIAS}="?*", RUN+="/sbin/modprobe -b $env{MODALIAS}"
I want to shy away from sending another rule upstream.
Are there any other sensible alternatives?
Kind regards,
Lee
^ permalink raw reply
* Re: UDEV - DRIVER parameter
From: Kay Sievers @ 2010-07-06 11:50 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <4C33057C.10805@canonical.com>
On Tue, Jul 6, 2010 at 13:28, Lee Jones <lee.jones@canonical.com> wrote:
>> Only some devices have a driver bound. Only "bus" devices, "class"
>> devices never have a driver.
>>
>> It's just the symlink "driver" in /sys in the device directory.
>>
>> Your platform device may just be a plain registered device, and not
>> probed and bound by a driver in that sense. Usually only enumeratable
>> buses have drivers that create devices when they are discovered.
>
> I guess I'd better tell you the full story then.
>
> I am working on a driver (module) that provides a direct link "CPU <-> Video Codec", which I believe is non-discoverable.
>
> I figured that I'd be able to send the uevent by registering the device as a platform one in architecture specific code.
>
> A uevent is sent, but it is missing the DRIVER parameter.
>
> This is the generic parameter which is used in the udev rules.
>
> /lib/udev/rules.d/80-drivers.rules, DRIVER!="?*", ENV{MODALIAS}="?*", RUN+="/sbin/modprobe -b $env{MODALIAS}"
What do you mean? This rule is skipped only if DRIVER is set. This is
to prevent calling modprobe for devices which already have a driver
bound and looking-up and loading another module would not do anything
to this device. If you don't have a driver this rule will always run.
:)
Kay
^ permalink raw reply
* Re: UDEV - DRIVER parameter
From: Lee Jones @ 2010-07-06 13:05 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <4C33057C.10805@canonical.com>
> What do you mean? This rule is skipped only if DRIVER is set. This is
> to prevent calling modprobe for devices which already have a driver
> bound and looking-up and loading another module would not do anything
> to this device. If you don't have a driver this rule will always run.
> :)
It appears I've been led up the garden path, so to speak.
Let me do some more poking around.
Thanks for your help thus far Kay.
^ permalink raw reply
* [PATCH 1/2] Match Logitech MX5500 against hidraw
From: Robert Meijers @ 2010-07-06 14:43 UTC (permalink / raw)
To: linux-hotplug
Match the Logitech MX5500 keyboard and mouse combo against the hidraw rule conform commit ba854cf
Signed-off-by: Robert Meijers <robert.meijers@gmail.com>
---
| 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
--git a/extras/hid2hci/70-hid2hci.rules b/extras/hid2hci/70-hid2hci.rules
index c5528f0..5f56d55 100644
--- a/extras/hid2hci/70-hid2hci.rules
+++ b/extras/hid2hci/70-hid2hci.rules
@@ -11,9 +11,9 @@ ATTR{bInterfaceClass}="03", ATTR{bInterfaceSubClass}="01", ATTR{bInterfaceProt
RUN+="hid2hci --methodfill --devpath=%p", ENV{HID2HCI_SWITCH}="1"
# Logitech devices (hidraw)
-KERNEL="hiddev*", ATTRS{idVendor}="046d", ATTRS{idProduct}="c70[345bce]|c71[34bc]", \
+KERNEL="hiddev*", ATTRS{idVendor}="046d", ATTRS{idProduct}="c70[345bce]|c71[34]", \
RUN+="hid2hci --method=logitech-hid --devpath=%p"
-KERNEL="hidraw*", ATTRS{idVendor}="046d", ATTRS{idProduct}="c70a", \
+KERNEL="hidraw*", ATTRS{idVendor}="046d", ATTRS{idProduct}="c70a|c71[bc]", \
RUN+="hid2hci --method=logitech-hid --devpath=%p"
ENV{DEVTYPE}!="usb_device", GOTO="hid2hci_end"
--
1.7.1.1
--
To unsubscribe from this list: send the line "unsubscribe linux-hotplug" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH 2/2] Match Logitech diNovo Media against hidraw
From: Robert Meijers @ 2010-07-06 14:43 UTC (permalink / raw)
To: linux-hotplug
Match the Logitech diNovo Media keyboard and mouse combo against the hidraw rule conform commit ba854cf
Signed-off-by: Robert Meijers <robert.meijers@gmail.com>
---
| 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
--git a/extras/hid2hci/70-hid2hci.rules b/extras/hid2hci/70-hid2hci.rules
index 5f56d55..55944b3 100644
--- a/extras/hid2hci/70-hid2hci.rules
+++ b/extras/hid2hci/70-hid2hci.rules
@@ -11,9 +11,9 @@ ATTR{bInterfaceClass}="03", ATTR{bInterfaceSubClass}="01", ATTR{bInterfaceProt
RUN+="hid2hci --methodfill --devpath=%p", ENV{HID2HCI_SWITCH}="1"
# Logitech devices (hidraw)
-KERNEL="hiddev*", ATTRS{idVendor}="046d", ATTRS{idProduct}="c70[345bce]|c71[34]", \
+KERNEL="hiddev*", ATTRS{idVendor}="046d", ATTRS{idProduct}="c70[345e]|c71[34]", \
RUN+="hid2hci --method=logitech-hid --devpath=%p"
-KERNEL="hidraw*", ATTRS{idVendor}="046d", ATTRS{idProduct}="c70a|c71[bc]", \
+KERNEL="hidraw*", ATTRS{idVendor}="046d", ATTRS{idProduct}="c70[abc]|c71[bc]", \
RUN+="hid2hci --method=logitech-hid --devpath=%p"
ENV{DEVTYPE}!="usb_device", GOTO="hid2hci_end"
--
1.7.1.1
--
To unsubscribe from this list: send the line "unsubscribe linux-hotplug" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* Re: [PATCH 1/2] Export firmware assigned labels of network devices to sysfs
From: Narendra K @ 2010-07-06 18:52 UTC (permalink / raw)
To: greg
Cc: netdev, linux-hotplug, linux-pci, matt_domsch, jordan_hargrave,
charles_rose, vijay_nijhawan
In-Reply-To: <EDA0A4495861324DA2618B4C45DCB3EE612B1B@blrx3m08.blr.amer.dell.com>
> -----Original Message-----
> From: Greg KH [mailto:greg@kroah.com]
> Sent: Wednesday, June 30, 2010 9:12 PM
> To: K, Narendra
> Cc: Domsch, Matt; 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 Tue, Jun 29, 2010 at 11:28:18AM -0500, Narendra K wrote:
> > --- a/drivers/pci/Makefile
> > +++ b/drivers/pci/Makefile
> > @@ -4,7 +4,7 @@
> >
> > obj-y += access.o bus.o probe.o remove.o pci.o \
> > pci-driver.o search.o pci-sysfs.o rom.o
> setup-res.o \
> > - irq.o vpd.o
> > + irq.o vpd.o pci-label.o
>
> No, only build this if CONFIG_DMI is set.
I have corrected this to build pci-label.o if only if CONFIG_DMI is set.
> > +pci_create_smbiosname_file(struct pci_dev *pdev)
> > +{
> > + if (smbios_attr_label.test && smbios_attr_label.test(&pdev->dev,
> NULL, NULL)) {
> > + if (sysfs_create_file(&pdev->dev.kobj,
> &smbios_attr_label.attr))
> > + return -1;
>
> What's wrong with the 'device_create_file' calls?
'device_create_file' takes 'struct device_attribute *' as a param which
we have not used here because 'struct device_attribute' does not have .test
member which we needed in this patch.
Please find the patch with the above change here -
From: Narendra K <narendra_k@dell.com>
Subject: [PATCH] Export SMBIOS provided firmware instance and label to sysfs
This patch exports SMBIOS provided firmware instance and label of
onboard pci devices to sysfs
Signed-off-by: Jordan Hargrave <jordan_hargrave@dell.com>
Signed-off-by: Narendra K <narendra_k@dell.com>
---
drivers/firmware/dmi_scan.c | 25 +++++++++
drivers/pci/Makefile | 3 +
drivers/pci/pci-label.c | 123 +++++++++++++++++++++++++++++++++++++++++++
drivers/pci/pci-sysfs.c | 5 ++
drivers/pci/pci.h | 7 +++
include/linux/dmi.h | 9 +++
6 files changed, 172 insertions(+), 0 deletions(-)
create mode 100644 drivers/pci/pci-label.c
diff --git a/drivers/firmware/dmi_scan.c b/drivers/firmware/dmi_scan.c
index d464672..ce73fcc 100644
--- a/drivers/firmware/dmi_scan.c
+++ b/drivers/firmware/dmi_scan.c
@@ -277,6 +277,29 @@ static void __init dmi_save_ipmi_device(const struct dmi_header *dm)
list_add_tail(&dev->list, &dmi_devices);
}
+static void __init dmi_save_dev_onboard(int instance, int segment, int bus,
+ int devfn, const char *name)
+{
+ struct dmi_dev_onboard *onboard_dev;
+
+ onboard_dev = dmi_alloc(sizeof(*onboard_dev) + strlen(name) + 1);
+ if (!onboard_dev) {
+ printk(KERN_ERR "dmi_save_dev_onboard: out of memory.\n");
+ return;
+ }
+ onboard_dev->instance = instance;
+ onboard_dev->segment = segment;
+ onboard_dev->bus = bus;
+ onboard_dev->devfn = devfn;
+
+ strcpy((char *)&onboard_dev[1], name);
+ onboard_dev->dev.type = DMI_DEV_TYPE_DEV_ONBOARD;
+ onboard_dev->dev.name = (char *)&onboard_dev[1];
+ onboard_dev->dev.device_data = onboard_dev;
+
+ list_add(&onboard_dev->dev.list, &dmi_devices);
+}
+
static void __init dmi_save_extended_devices(const struct dmi_header *dm)
{
const u8 *d = (u8*) dm + 5;
@@ -285,6 +308,7 @@ static void __init dmi_save_extended_devices(const struct dmi_header *dm)
if ((*d & 0x80) = 0)
return;
+ dmi_save_dev_onboard(*(d+1), *(u16 *)(d+2), *(d+4), *(d+5), dmi_string_nosave(dm, *(d-1)));
dmi_save_one_device(*d & 0x7f, dmi_string_nosave(dm, *(d - 1)));
}
@@ -333,6 +357,7 @@ static void __init dmi_decode(const struct dmi_header *dm, void *dummy)
break;
case 41: /* Onboard Devices Extended Information */
dmi_save_extended_devices(dm);
+ break;
}
}
diff --git a/drivers/pci/Makefile b/drivers/pci/Makefile
index 0b51857..dc1aa09 100644
--- a/drivers/pci/Makefile
+++ b/drivers/pci/Makefile
@@ -55,6 +55,9 @@ obj-$(CONFIG_MICROBLAZE) += setup-bus.o
#
obj-$(CONFIG_ACPI) += pci-acpi.o
+# SMBIOS provided firmware instance and labels
+obj-$(CONFIG_DMI) += pci-label.o
+
# Cardbus & CompactPCI use setup-bus
obj-$(CONFIG_HOTPLUG) += setup-bus.o
diff --git a/drivers/pci/pci-label.c b/drivers/pci/pci-label.c
new file mode 100644
index 0000000..829362a
--- /dev/null
+++ b/drivers/pci/pci-label.c
@@ -0,0 +1,123 @@
+/*
+ * Purpose: Export the firmware instance/index and label associated with
+ * a pci device to sysfs
+ * Copyright (C) 2010 Dell Inc.
+ * by Narendra K <Narendra_K@dell.com>, Jordan Hargrave <Jordan_Hargrave@dell.com>
+ *
+ * SMBIOS defines type 41 for onboard pci devices. This code retrieves
+ * the instance number and string from the type 41 record and exports
+ * it to sysfs.
+ *
+ * Please see http://linux.dell.com/wiki/index.php/Oss/libnetdevname for more
+ * information.
+ */
+
+#include <linux/dmi.h>
+#include <linux/sysfs.h>
+#include <linux/pci.h>
+#include <linux/pci_ids.h>
+#include <linux/module.h>
+#include "pci.h"
+
+struct smbios_attribute {
+ struct attribute attr;
+ ssize_t (*show) (struct device *dev, struct device_attribute *, char *buf);
+ ssize_t (*test) (struct device *dev, char *buf, char *attribute);
+};
+
+static ssize_t
+smbios_instance_string_exist(struct device *dev, char *buf, char *attribute)
+{
+ struct pci_dev *pdev = to_pci_dev(dev);
+ const struct dmi_device *dmi;
+ struct dmi_dev_onboard *donboard;
+ int bus;
+ int devfn;
+ int attribute_is_instance = 0;
+
+ bus = pdev->bus->number;
+ devfn = pdev->devfn;
+
+ if (attribute && !strncmp(attribute, "instance", strlen(attribute)))
+ attribute_is_instance=1;
+
+ dmi = NULL;
+ while ((dmi = dmi_find_device(DMI_DEV_TYPE_DEV_ONBOARD, NULL, dmi)) != NULL) {
+ donboard = dmi->device_data;
+ if (donboard && donboard->bus = bus && donboard->devfn = devfn) {
+ if (buf) {
+ if (attribute_is_instance)
+ return scnprintf(buf, PAGE_SIZE,
+ "%d\n", donboard->instance);
+ else
+ return scnprintf(buf, PAGE_SIZE,
+ "%s\n", dmi->name);
+ }
+ return strlen(dmi->name);
+ }
+ }
+
+ return 0;
+}
+
+static ssize_t
+smbiosname_show(struct device *dev, struct device_attribute *attr, char *buf)
+{
+ return smbios_instance_string_exist(dev, buf, "label");
+}
+
+static ssize_t
+smbiosinstance_show(struct device *dev, struct device_attribute *attr, char *buf)
+{
+ return smbios_instance_string_exist(dev, buf, "instance");
+}
+
+struct smbios_attribute smbios_attr_label = {
+ .attr = {.name = "label", .mode = 0444, .owner = THIS_MODULE},
+ .show = smbiosname_show,
+ .test = smbios_instance_string_exist,
+};
+
+struct smbios_attribute smbios_attr_instance = {
+ .attr = {.name = "index", .mode = 0444, .owner = THIS_MODULE},
+ .show = smbiosinstance_show,
+ .test = smbios_instance_string_exist,
+};
+
+static int
+pci_create_smbiosname_file(struct pci_dev *pdev)
+{
+ if (smbios_attr_label.test && smbios_attr_label.test(&pdev->dev, NULL, NULL)) {
+ if (sysfs_create_file(&pdev->dev.kobj, &smbios_attr_label.attr))
+ return -1;
+ if (sysfs_create_file(&pdev->dev.kobj, &smbios_attr_instance.attr))
+ return -1;
+ return 0;
+ }
+ return -1;
+}
+
+static int
+pci_remove_smbiosname_file(struct pci_dev *pdev)
+{
+ if (smbios_attr_label.test && smbios_attr_label.test(&pdev->dev, NULL, NULL)) {
+ sysfs_remove_file(&pdev->dev.kobj, &smbios_attr_label.attr);
+ sysfs_remove_file(&pdev->dev.kobj, &smbios_attr_instance.attr);
+ return 0;
+ }
+ return -1;
+}
+
+int pci_create_firmware_label_files(struct pci_dev *pdev)
+{
+ if (!pci_create_smbiosname_file(pdev))
+ return 0;
+ return -ENODEV;
+}
+
+int pci_remove_firmware_label_files(struct pci_dev *pdev)
+{
+ if (!pci_remove_smbiosname_file(pdev))
+ return 0;
+ return -ENODEV;
+}
diff --git a/drivers/pci/pci-sysfs.c b/drivers/pci/pci-sysfs.c
index afd2fbf..01fd799 100644
--- a/drivers/pci/pci-sysfs.c
+++ b/drivers/pci/pci-sysfs.c
@@ -1132,6 +1132,8 @@ int __must_check pci_create_sysfs_dev_files (struct pci_dev *pdev)
pci_create_slot_links(pdev);
+ pci_create_firmware_label_files(pdev);
+
return 0;
err_vga_file:
@@ -1201,6 +1203,9 @@ void pci_remove_sysfs_dev_files(struct pci_dev *pdev)
sysfs_remove_bin_file(&pdev->dev.kobj, pdev->rom_attr);
kfree(pdev->rom_attr);
}
+
+ pci_remove_firmware_label_files(pdev);
+
}
static int __init pci_sysfs_init(void)
diff --git a/drivers/pci/pci.h b/drivers/pci/pci.h
index f8077b3..67264c7 100644
--- a/drivers/pci/pci.h
+++ b/drivers/pci/pci.h
@@ -11,6 +11,13 @@
extern int pci_uevent(struct device *dev, struct kobj_uevent_env *env);
extern int pci_create_sysfs_dev_files(struct pci_dev *pdev);
extern void pci_remove_sysfs_dev_files(struct pci_dev *pdev);
+#ifndef CONFIG_DMI
+static inline int pci_create_firmware_label_files(struct pci_dev *pdev) { return 0; }
+static inline int pci_remove_firmware_label_files(struct pci_dev *pdev) { return 0; }
+#else
+extern int pci_create_firmware_label_files(struct pci_dev *pdev);
+extern int pci_remove_firmware_label_files(struct pci_dev *pdev);
+#endif
extern void pci_cleanup_rom(struct pci_dev *dev);
#ifdef HAVE_PCI_MMAP
extern int pci_mmap_fits(struct pci_dev *pdev, int resno,
diff --git a/include/linux/dmi.h b/include/linux/dmi.h
index a8a3e1a..90e087f 100644
--- a/include/linux/dmi.h
+++ b/include/linux/dmi.h
@@ -20,6 +20,7 @@ enum dmi_device_type {
DMI_DEV_TYPE_SAS,
DMI_DEV_TYPE_IPMI = -1,
DMI_DEV_TYPE_OEM_STRING = -2,
+ DMI_DEV_TYPE_DEV_ONBOARD = -3,
};
struct dmi_header {
@@ -37,6 +38,14 @@ struct dmi_device {
#ifdef CONFIG_DMI
+struct dmi_dev_onboard {
+ struct dmi_device dev;
+ int instance;
+ int segment;
+ int bus;
+ int devfn;
+};
+
extern int dmi_check_system(const struct dmi_system_id *list);
const struct dmi_system_id *dmi_first_match(const struct dmi_system_id *list);
extern const char * dmi_get_system_info(int field);
--
1.6.5.2
With regards,
Narendra K
^ permalink raw reply related
* Re: [PATCH 1/2] Export firmware assigned labels of network devices
From: Greg KH @ 2010-07-06 23:22 UTC (permalink / raw)
To: Narendra K
Cc: netdev, linux-hotplug, linux-pci, matt_domsch, jordan_hargrave,
charles_rose, vijay_nijhawan
In-Reply-To: <20100706185218.GA19357@auslistsprd01.us.dell.com>
On Tue, Jul 06, 2010 at 01:52:18PM -0500, Narendra K wrote:
> > -----Original Message-----
> > From: Greg KH [mailto:greg@kroah.com]
> > Sent: Wednesday, June 30, 2010 9:12 PM
> > To: K, Narendra
> > Cc: Domsch, Matt; 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 Tue, Jun 29, 2010 at 11:28:18AM -0500, Narendra K wrote:
> > > --- a/drivers/pci/Makefile
> > > +++ b/drivers/pci/Makefile
> > > @@ -4,7 +4,7 @@
> > >
> > > obj-y += access.o bus.o probe.o remove.o pci.o \
> > > pci-driver.o search.o pci-sysfs.o rom.o
> > setup-res.o \
> > > - irq.o vpd.o
> > > + irq.o vpd.o pci-label.o
> >
> > No, only build this if CONFIG_DMI is set.
>
> I have corrected this to build pci-label.o if only if CONFIG_DMI is set.
>
>
> > > +pci_create_smbiosname_file(struct pci_dev *pdev)
> > > +{
> > > + if (smbios_attr_label.test && smbios_attr_label.test(&pdev->dev,
> > NULL, NULL)) {
> > > + if (sysfs_create_file(&pdev->dev.kobj,
> > &smbios_attr_label.attr))
> > > + return -1;
> >
> > What's wrong with the 'device_create_file' calls?
>
> 'device_create_file' takes 'struct device_attribute *' as a param which
> we have not used here because 'struct device_attribute' does not have .test
> member which we needed in this patch.
Why do you need it? What is calling that function? What am I missing
here?
> Please find the patch with the above change here -
Please always run your patches through scripts/checkpatch.pl and fix up
the issues it finds before sending it out and having everyone else point
them out to you :)
Also, a new thread is nice at times for new versions of patches...
thanks,
greg k-h
^ 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