* Re: [PATCH 1/2] Export firmware assigned labels of network devices
From: Domsch, Matt @ 2010-05-28 13:16 UTC (permalink / raw)
To: K, Narendra
Cc: netdev@vger.kernel.org, linux-hotplug@vger.kernel.org,
linux-pci@vger.kernel.org, Hargrave, Jordan, Rose, Charles,
Nijhawan, Vijay
In-Reply-To: <20100528115520.GA24114@littleblue.us.dell.com>
On Fri, May 28, 2010 at 06:55:21AM -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
>
> The patch has following enhancements over the earlier patch -
>
> 1.Implement support for ACPI _DSM(Device Specific Method) provided by
> the system firmware. The _DSM returns an index which is the instance number and
> a label assigned to the network device by the system firmware. The onboard devices
> will have lower indexes than the add-in devices. The patch exports both index and
> the label to sysfs.
>
> For Example -
>
> cat /sys/class/net/eth0/device/label
> Embedded Broadcom 5709C NIC 1
>
> cat /sys/devices/pci0000:00/0000:00:01.0/0000:01:00.0/index
> 1
>
> Please refer to the PCI-SIG Draft ECN
> "PCIe Device Labeling under Operating Systems Draft ECN" at this link -
> http://www.pcisig.com/specifications/pciexpress/review_zone/.
>
> It would be great to know your views on this ECN. Please let us know if you have
> have any suggestions or changes.
Please note: the 30-day review period for this Draft ECN ends on June
21, 2010. If there are objections to this approach, or modifications
you believe are necessary, please raise them before this point so we
may adjust the draft before it is ratified.
Thanks,
Matt
--
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 15:40 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>
On Fri, May 28, 2010 at 06:55:21AM -0500, K, Narendra wrote:
> Please refer to the PCI-SIG Draft ECN
> "PCIe Device Labeling under Operating Systems Draft ECN" at this link -
> http://www.pcisig.com/specifications/pciexpress/review_zone/.
>
> It would be great to know your views on this ECN. Please let us know if you have
> have any suggestions or changes.
Note that only members of the PCI-SIG can do this, which pretty much
rules out any "normal" Linux kernel developer :(
Care to post a public version of this for us to review?
> --- /dev/null
> +++ b/drivers/pci/pci-label.c
> @@ -0,0 +1,242 @@
> +/*
> + * File: drivers/pci/pci-label.c
This line is not needed, we know the file name :)
> + * Purpose: Export the firmware label associated with a pci network interface
> + * device to sysfs
> + * Copyright (C) 2010 Dell Inc.
> + * by Narendra K <Narendra_K@dell.com>, Jordan Hargrave <Jordan_Hargrave@dell.com>
> + *
> + * This code checks if the pci network device has a related ACPI _DSM. If
> + * available, the code calls the _DSM to retrieve the index and string and
> + * exports them to sysfs. If the ACPI _DSM is not available, it falls back on
> + * SMBIOS. SMBIOS defines type 41 for onboard pci devices. This code retrieves
> + * strings associated with the type 41 and exports it to sysfs.
> + *
> + * Please see http://linux.dell.com/wiki/index.php/Oss/libnetdevname for more
> + * information.
> + */
> +
> +#include <linux/pci-label.h>
Why is this file in include/linux/ ? Who needs it there? Can't it just
be in in the drivers/pci/ directory? Actually all you need is 2
functions in there, so it could go into the internal pci.h file in that
directory without a problem, right?
> +
> +static ssize_t
> +smbiosname_string_exists(struct device *dev, char *buf)
> +{
> + struct pci_dev *pdev = to_pci_dev(dev);
> + const struct dmi_device *dmi;
> + struct dmi_devslot *dslot;
> + int bus;
> + int devfn;
> +
> + bus = pdev->bus->number;
> + devfn = pdev->devfn;
> +
> + dmi = NULL;
> + while ((dmi = dmi_find_device(DMI_DEV_TYPE_DEVSLOT, NULL, dmi)) != NULL) {
> + dslot = dmi->device_data;
> + if (dslot && dslot->bus = bus && dslot->devfn = devfn) {
> + if (buf)
> + 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 smbiosname_string_exists(dev, buf);
> +}
> +
> +struct smbios_attribute smbios_attr_label = {
> + .attr = {.name = __stringify(label), .mode = 0444, .owner = THIS_MODULE},
Can't you just put "label" as the name?
> + .show = smbiosname_show,
> + .test = smbiosname_string_exists,
> +};
> +
> +static int
> +pci_create_smbiosname_file(struct pci_dev *pdev)
> +{
> + if (smbios_attr_label.test && smbios_attr_label.test(&pdev->dev, NULL)) {
> + sysfs_create_file(&pdev->dev.kobj, &smbios_attr_label.attr);
> + 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)) {
> + sysfs_remove_file(&pdev->dev.kobj, &smbios_attr_label.attr);
> + return 0;
> + }
> + return -1;
> +}
> +
> +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
> +};
> +
> +
> +static int
> +dsm_get_label(acpi_handle handle, int func,
> + struct acpi_buffer *output,
> + char *buf, char *attribute)
> +{
> + struct acpi_object_list input;
> + union acpi_object params[4];
> + union acpi_object *obj;
> + int len = 0;
> +
> + int err;
> +
> + input.count = 4;
> + input.pointer = params;
> + params[0].type = ACPI_TYPE_BUFFER;
> + params[0].buffer.length = sizeof(dell_dsm_uuid);
> + params[0].buffer.pointer = (char *)dell_dsm_uuid;
> + params[1].type = ACPI_TYPE_INTEGER;
> + params[1].integer.value = 0x02;
> + params[2].type = ACPI_TYPE_INTEGER;
> + params[2].integer.value = func;
> + params[3].type = ACPI_TYPE_PACKAGE;
> + params[3].package.count = 0;
> + params[3].package.elements = NULL;
> +
> + err = acpi_evaluate_object(handle, "_DSM", &input, output);
> + if (err) {
> + printk(KERN_INFO "failed to evaulate _DSM\n");
> + return -1;
> + }
> +
> + obj = (union acpi_object *)output->pointer;
> +
> + switch (obj->type) {
> + case ACPI_TYPE_PACKAGE:
> + if (obj->package.count = 2) {
> + len = obj->package.elements[0].integer.value;
> + if (buf) {
> + if (!strncmp(attribute, "index", strlen(attribute)))
> + scnprintf(buf, PAGE_SIZE, "%lu\n",
> + obj->package.elements[0].integer.value);
> + else
> + scnprintf(buf, PAGE_SIZE, "%s\n",
> + obj->package.elements[1].string.pointer);
> + kfree(output->pointer);
> + return strlen(buf);
> + }
> + }
> + kfree(output->pointer);
> + return len;
> + break;
> + default:
> + return -1;
> + }
> +}
> +
> +static ssize_t
> +acpi_index_string_exist(struct device *dev, char *buf, char *attribute)
> +{
> + struct pci_dev *pdev = to_pci_dev(dev);
> +
> + struct acpi_buffer output = {ACPI_ALLOCATE_BUFFER, NULL};
> + acpi_handle handle;
> + int length;
> + int is_addin_card = 0;
> +
> + if ((pdev->class >> 16) != PCI_BASE_CLASS_NETWORK)
> + return -1;
> +
> + handle = DEVICE_ACPI_HANDLE(dev);
> +
> + if (!handle) {
> + /*
> + * The device is an add-in network controller and does have
> + * a valid handle. Try until we get the handle for the parent
> + * bridge
> + */
> + struct pci_bus *pbus;
> + for (pbus = pdev->bus; pbus; pbus = pbus->parent) {
> + handle = DEVICE_ACPI_HANDLE(&(pbus->self->dev));
> + if (handle)
> + break;
> +
> + }
> + }
> +
> + if ((length = dsm_get_label(handle, DELL_DSM_NETWORK,
> + &output, buf, attribute)) < 0)
> + return -1;
> +
> + return length;
> +}
> +
> +static ssize_t
> +acpilabel_show(struct device *dev, struct device_attribute *attr, char *buf)
> +{
> + return acpi_index_string_exist(dev, buf, "label");
> +}
> +
> +static ssize_t
> +acpiindex_show(struct device *dev, struct device_attribute *attr, char *buf)
> +{
> + return acpi_index_string_exist(dev, buf, "index");
> +}
> +
> +struct acpi_attribute acpi_attr_label = {
> + .attr = {.name = __stringify(label), .mode = 0444, .owner = THIS_MODULE},
> + .show = acpilabel_show,
> + .test = acpi_index_string_exist,
> +};
> +
> +struct acpi_attribute acpi_attr_index = {
> + .attr = {.name = __stringify(index), .mode = 0444, .owner = THIS_MODULE},
> + .show = acpiindex_show,
> + .test = acpi_index_string_exist,
> +};
> +
> +static int
> +pci_create_acpi_index_label_files(struct pci_dev *pdev)
> +{
> + if (acpi_attr_label.test && acpi_attr_label.test(&pdev->dev, NULL) > 0) {
> + sysfs_create_file(&pdev->dev.kobj, &acpi_attr_label.attr);
> + sysfs_create_file(&pdev->dev.kobj, &acpi_attr_index.attr);
> + return 0;
> + }
> + return -1;
> +}
> +
> +static int
> +pci_remove_acpi_index_label_files(struct pci_dev *pdev)
> +{
> + if (acpi_attr_label.test && acpi_attr_label.test(&pdev->dev, NULL) > 0) {
> + sysfs_remove_file(&pdev->dev.kobj, &acpi_attr_label.attr);
> + sysfs_remove_file(&pdev->dev.kobj, &acpi_attr_index.attr);
> + return 0;
> + }
> + return -1;
> +}
> +
> +int pci_create_acpi_attr_files(struct pci_dev *pdev)
> +{
> + if (!pci_create_acpi_index_label_files(pdev))
> + return 0;
> + if (!pci_create_smbiosname_file(pdev))
> + return 0;
> + return -ENODEV;
> +}
> +EXPORT_SYMBOL(pci_create_acpi_attr_files);
EXPORT_SYMBOL_GPL?
Wait, why does this need to be exported at all? What module is ever
going to call this function?
> +int pci_remove_acpi_attr_files(struct pci_dev *pdev)
> +{
> + if (!pci_remove_acpi_index_label_files(pdev))
> + return 0;
> + if (!pci_remove_smbiosname_file(pdev))
> + return 0;
> + return -ENODEV;
> +
> +}
> +EXPORT_SYMBOL(pci_remove_acpi_attr_files);
Same here, what module will call this?
> +++ b/include/linux/pci-label.h
As discussed above, this whole file does not need to exist.
> +extern int pci_create_acpi_attr_files(struct pci_dev *pdev);
> +extern int pci_remove_acpi_attr_files(struct pci_dev *pdev);
Just put these two functions in the drivers/pci/pci.h file.
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH 2/2] dmi: save OEM defined slot information
From: Alex Chiang @ 2010-05-28 15:42 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: <20100528120644.GB24114@littleblue.us.dell.com>
* K, Narendra <Narendra_K@dell.com>:
>
> This patch from Alex Chiang exports onboard device information
> as defined by SMBIOS type 209 for HP Proliants systems.
Hi,
Not sure if it really matters, but I'm no longer at HP and thus
my email address below is dead.
> From: Alex Chiang <achiang@hp.com>
>
> Some legacy platforms provide onboard device information in an
> SMBIOS OEM- defined field, notably HP Proliants.
[snip]
> Signed-off-by: Alex Chiang <achiang@hp.com>
I wrote this code when I was still at HP, so I suppose they
should get the git commit "credit" for it, unless there's already
a well-known convention of what to do when an email address
changes.
Thanks,
/ac
^ permalink raw reply
* 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
* [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
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
* 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] 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
* [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 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
* 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 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 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
* 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
* 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
* [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
* 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
* [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: [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
* 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
* 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: 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
* 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: 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 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
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