* Re: udev cdrom_id rules prevent unmounted CD from spinning down
From: Kay Sievers @ 2010-05-19 13:55 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <20100513153043.GA3966@elliptictech.com>
On Wed, May 19, 2010 at 15:23, Tejun Heo <tj@kernel.org> wrote:
> For new comers: A cdrom is smart enough to actually raise AN but at
> the same time dumb enough to raise it again on each open leading to
> infinite loop involving the drive, kernel and udev.
>
> On 05/18/2010 10:18 PM, Kay Sievers wrote:
>> Tejun, the stuff in:
>> drivers/ata/libata-eh.c::sata_async_notification()
>> seems to send events for this device, even when there is no changed
>> media. Any ideas how to debug this? Or to check if these events are
>> really events we should put out to userspace?
>
> Hmmm... I've been looking through the standards and things look
> somewhat dodgy. ATA ACS continuously refers to SerialATA 2.6 for
> details on AN and SerialATA 2.6 standard in turn claims that it
> describes the AN mechanism but doesn't define all the events AN can be
> raised for and for those one should refer to command standards (in
> this case ACS), *but* both list media change event as a "yeah can be
> used like that" example. So, in the end, nobody clearly defines it.
> Sweet. :-)
>
> That said, w/o issuing further commands, the driver can't tell what
> the AN exactly means. There's no further information at all. It's a
> simple notification from the device. For ATAPI devices, it would be
> safe to assume that checking media status is the right action to take
> although both ATA and SATA standards haven't been brave enough to
> actually define it precisely; however, exposing it directly to
> userland as a media change event seems quite naive.
>
> I think it's best to plug AN till we have proper media presence
> detection inside kernel proper so that our behavior doesn't differ
> from windows apparently is the only thing many vendors are verifying
> their hardware against.
Yeah, that sounds good, and we can probably explicitly check with the
in-kernel polling if we really have a media change, and only then send
stuff out to userspace.
Sounds all good, and thanks a lot for the quick fix.
Thanks,
Kay
^ permalink raw reply
* Re: [PATCH #upstream-fixes] libata: disable ATAPI AN by default
From: Jeff Garzik @ 2010-05-19 16:14 UTC (permalink / raw)
To: Tejun Heo
Cc: linux-ide@vger.kernel.org, Kay Sievers, Nick Bowler,
David Zeuthen, linux-hotplug, stable
In-Reply-To: <4BF3E9F2.9050608@kernel.org>
On 05/19/2010 09:38 AM, Tejun Heo wrote:
> There are ATAPI devices which raise AN when hit by commands issued by
> open(). This leads to infinite loop of AN -> MEDIA_CHANGE uevent ->
> udev open() to check media -> AN.
>
> Both ACS and SerialATA standards don't define in which case ATAPI
> devices are supposed to raise or not raise AN. They both list media
> insertion event as a possible use case for ATAPI ANs but there is no
> clear description of what constitutes such events. As such, it seems
> a bit too naive to export ANs directly to userland as MEDIA_CHANGE
> events without further verification (which should behave similarly to
> windows as it apparently is the only thing that some hardware vendors
> are testing against).
Windows completely disables AN?
Or do we simply need to be less naive about _delivery_ of AN's?
Jeff
^ permalink raw reply
* Re: [PATCH #upstream-fixes] libata: disable ATAPI AN by default
From: Tejun Heo @ 2010-05-19 16:53 UTC (permalink / raw)
To: Jeff Garzik
Cc: linux-ide@vger.kernel.org, Kay Sievers, Nick Bowler,
David Zeuthen, linux-hotplug, stable
In-Reply-To: <4BF40E6C.6020701@garzik.org>
Hello,
On 05/19/2010 06:14 PM, Jeff Garzik wrote:
> Windows completely disables AN?
>
> Or do we simply need to be less naive about _delivery_ of AN's?
I think we first need to verify what the event is about before
delivering it to userland; IOW, it should kick a full polling op. The
problem is the same with periodic polling. Windows does it with
single command but we can't do that from userland as open() involves
issuing more commands. That discrepancy is basically we're having all
these problems with periodic polling and AN infinite looping.
Hardware vendors don't consider cases where their devices are hit with
a series of commands periodically or after raising an AN event. We
have quite a few drives which just die after being hit repeatedly with
media presence polling commands and this one is causing infinite loop
by re-raising AN.
So, until we can replicate the windows behavior (which actually is
pretty reasonable - just use single GET_CONFIGURATION call for polling
and status check), I think it's wiser to disable AN.
Thanks.
--
tejun
^ permalink raw reply
* Re: [PATCH #upstream-fixes] libata: disable ATAPI AN by default
From: Nick Bowler @ 2010-05-19 16:58 UTC (permalink / raw)
To: Tejun Heo
Cc: Jeff Garzik, linux-ide@vger.kernel.org, Kay Sievers,
David Zeuthen, linux-hotplug, stable
In-Reply-To: <4BF3E9F2.9050608@kernel.org>
On 15:38 Wed 19 May , Tejun Heo wrote:
> There are ATAPI devices which raise AN when hit by commands issued by
> open(). This leads to infinite loop of AN -> MEDIA_CHANGE uevent ->
> udev open() to check media -> AN.
>
> Both ACS and SerialATA standards don't define in which case ATAPI
> devices are supposed to raise or not raise AN. They both list media
> insertion event as a possible use case for ATAPI ANs but there is no
> clear description of what constitutes such events. As such, it seems
> a bit too naive to export ANs directly to userland as MEDIA_CHANGE
> events without further verification (which should behave similarly to
> windows as it apparently is the only thing that some hardware vendors
> are testing against).
>
> This patch adds libata.atapi_an module parameter and disables ATAPI AN
> by default for now.
Works here, drive now spins down properly.
Tested-By: Nick Bowler <nbowler@draconx.ca>
--
Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/)
^ permalink raw reply
* Re: [PATCH #upstream-fixes] libata: disable ATAPI AN by default
From: Robert Hancock @ 2010-05-21 4:49 UTC (permalink / raw)
To: Tejun Heo
Cc: Jeff Garzik, linux-ide@vger.kernel.org, Kay Sievers, Nick Bowler,
David Zeuthen, linux-hotplug, stable
In-Reply-To: <4BF4177B.2040108@kernel.org>
On 05/19/2010 10:53 AM, Tejun Heo wrote:
> Hello,
>
> On 05/19/2010 06:14 PM, Jeff Garzik wrote:
>> Windows completely disables AN?
>>
>> Or do we simply need to be less naive about _delivery_ of AN's?
>
> I think we first need to verify what the event is about before
> delivering it to userland; IOW, it should kick a full polling op. The
> problem is the same with periodic polling. Windows does it with
> single command but we can't do that from userland as open() involves
> issuing more commands. That discrepancy is basically we're having all
> these problems with periodic polling and AN infinite looping.
>
> Hardware vendors don't consider cases where their devices are hit with
> a series of commands periodically or after raising an AN event. We
> have quite a few drives which just die after being hit repeatedly with
> media presence polling commands and this one is causing infinite loop
> by re-raising AN.
>
> So, until we can replicate the windows behavior (which actually is
> pretty reasonable - just use single GET_CONFIGURATION call for polling
> and status check), I think it's wiser to disable AN.
There are also some drives where AN is just broken - I have a Lite-ON
DH-401S BD-ROM drive which raises AN on opening the tray, but not on
closing with media inserted.
I don't know if Windows is using AN at all yet or not. Seems like a lot
of drives aren't tested well with it though.
^ permalink raw reply
* [ANNOUNCE] udev 155 release
From: Kay Sievers @ 2010-05-24 15:41 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 155
====
Bugfixes.
Now the udev daemon itself does on startup:
- copy the content of /lib/udev/devices to /dev
- create the standard symlinks like /dev/std{in,out,err},
/dev/core, /dev/fd, ...
- use static node information provided by kernel modules
and creates these nodes to allow module on-demand loading
- possibly apply permissions to all static nodes from udev
rules which are annotated to match a static node
The default mode for a device node is 0600 now to match the kernel
created devtmpfs defaults. If GROUP= is specified and no MODE= is
given the default will be 0660.
^ permalink raw reply
* Re: [ANNOUNCE] udev 155 release
From: Bryan Kadzban @ 2010-05-25 4:48 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <1274715714.2455.1.camel@yio.site>
> - create the standard symlinks like /dev/std{in,out,err}, /dev/core,
> /dev/fd, ...
Looks like /dev/fd is pointing at /proc/fd. I think this should be
/proc/self/fd (unless newer kernels added /proc/fd). Trivial patch follows.
Signed-Off-By: Bryan Kadzban <bryan@kadzban.is-a-geek.net>
diff --git a/udev/udevd.c b/udev/udevd.c
index ab24885..802153b 100644
--- a/udev/udevd.c
+++ b/udev/udevd.c
@@ -883,7 +883,7 @@ static void static_dev_create_links(struct udev
*udev, DIR *dir)
};
static const struct stdlinks stdlinks[] = {
{ "core", "/proc/kcore" },
- { "fd", "/proc/fd" },
+ { "fd", "/proc/self/fd" },
{ "stdin", "/proc/self/fd/0" },
{ "stdout", "/proc/self/fd/1" },
{ "stderr", "/proc/self/fd/2" },
^ permalink raw reply related
* Re: [ANNOUNCE] udev 155 release
From: Kay Sievers @ 2010-05-25 4:59 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <1274715714.2455.1.camel@yio.site>
On Tue, May 25, 2010 at 06:48, Bryan Kadzban
<bryan@kadzban.is-a-geek.net> wrote:
>> - create the standard symlinks like /dev/std{in,out,err}, /dev/core,
>> /dev/fd, ...
>
> Looks like /dev/fd is pointing at /proc/fd. I think this should be
> /proc/self/fd (unless newer kernels added /proc/fd). Trivial patch follows.
Yeah, that should be "self". Applied.
Thanks,
Kay
^ permalink raw reply
* [ANNOUNCE] udev 156 release
From: Kay Sievers @ 2010-05-25 10:27 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 155
====
Bugfixes.
^ permalink raw reply
* Re: [PATCH #upstream-fixes] libata: disable ATAPI AN by default
From: Jeff Garzik @ 2010-05-25 23:41 UTC (permalink / raw)
To: Tejun Heo
Cc: linux-ide@vger.kernel.org, Kay Sievers, Nick Bowler,
David Zeuthen, linux-hotplug, stable
In-Reply-To: <4BF3E9F2.9050608@kernel.org>
On 05/19/2010 09:38 AM, Tejun Heo wrote:
> There are ATAPI devices which raise AN when hit by commands issued by
> open(). This leads to infinite loop of AN -> MEDIA_CHANGE uevent ->
> udev open() to check media -> AN.
>
> Both ACS and SerialATA standards don't define in which case ATAPI
> devices are supposed to raise or not raise AN. They both list media
> insertion event as a possible use case for ATAPI ANs but there is no
> clear description of what constitutes such events. As such, it seems
> a bit too naive to export ANs directly to userland as MEDIA_CHANGE
> events without further verification (which should behave similarly to
> windows as it apparently is the only thing that some hardware vendors
> are testing against).
>
> This patch adds libata.atapi_an module parameter and disables ATAPI AN
> by default for now.
>
> Signed-off-by: Tejun Heo<tj@kernel.org>
> Cc: Kay Sievers<kay.sievers@vrfy.org>
> Cc: Nick Bowler<nbowler@elliptictech.com>
> Cc: David Zeuthen<david@fubar.dk>
> Cc: stable@kernel.org
> ---
> drivers/ata/libata-core.c | 7 ++++++-
> 1 file changed, 6 insertions(+), 1 deletion(-)
applied
^ permalink raw reply
* [PATCH] Fix udev "temporary rules" for read-only root filesystems
From: Paul Stewart @ 2010-05-26 23:03 UTC (permalink / raw)
To: linux-hotplug
Fix udev issue where temporary persistent rules are written in one
place and read from another. The upstream udev release placed dynamic
persistent rules (ones that get deleted every reboot) in /dev/.udev/,
but the actual udev daemon read these rules out of
/dev/.udev/rules.d/. The side effect of this is that if the static
directory (/etc/udev/rules.d) is not writeable (read-only root
filesystem, for example), device interfaces keep getting renamed
wlan0, wlan1, wlan2, etc, if they are plugged and unplugged or if
udevd restarts.
In addition to the directory being incorrect, the actual filename was
incorrect as well -- the filename was set to begin with "tmp-", which
breaks the lexical sorting rules that udevd uses, so even if the file
was in the right directory, the 75-persistent-net-generator.rules
would fire first, and increment the device number anyway.
I've tested this patch to apply clieanly to udev-146 and udev-156.
Note that this change by itself won't work on most distributions (with
read only fses) unless they they also make sure that the
/dev/.udev/rules.d directory is created before udevd starts up, since
otherwise the inotify will never trigger for that directory since it
didn't exist when the inotify call was made.
--- extras/rule_generator/rule_generator.functions.orig 2008-10-23
06:33:41.000000000 -0700
+++ extras/rule_generator/rule_generator.functions 2010-05-26
10:26:20.000000000 -0700
@@ -57,7 +57,9 @@
# Choose the real rules file if it is writeable or a temporary file if not.
# Both files should be checked later when looking for existing rules.
choose_rules_file() {
- local tmp_rules_file="/dev/.udev/tmp-rules--${RULES_FILE##*/}"
+ local orig_rules_base=${RULES_FILE##*/}
+ local tmp_rules_base=${orig_rules_base%%.rules}--tmp.rules
+ local tmp_rules_file="/dev/.udev/rules.d/$tmp_rules_base"
[ -e "$RULES_FILE" -o -e "$tmp_rules_file" ] || PRINT_HEADER=1
if writeable ${RULES_FILE%/*}; then
^ permalink raw reply
* Re: [PATCH] Fix udev "temporary rules" for read-only root filesystems
From: Kay Sievers @ 2010-05-27 6:02 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <AANLkTineHRuPMK927ItHexZNN4UFniawyMwxgqztc1GZ@mail.gmail.com>
On Thu, May 27, 2010 at 01:03, Paul Stewart <pstew@google.com> wrote:
> Fix udev issue where temporary persistent rules are written in one
> place and read from another. Â The upstream udev release placed dynamic
> persistent rules (ones that get deleted every reboot) in /dev/.udev/,
> but the actual udev daemon read these rules out of
> /dev/.udev/rules.d/.
I think these temporary rules have never been expected to be read by
the udev daemon directly.
> The side effect of this is that if the static
> directory (/etc/udev/rules.d) is not writeable (read-only root
> filesystem, for example), device interfaces keep getting renamed
> wlan0, wlan1, wlan2, etc, if they are plugged and unplugged or if
> udevd restarts.
The temporary rules files, which might be created in /dev/.udev/ are
supposed to be copied to /etc/udev/rules.d/ as soon as the rootfs is
writable. There should be no restart of udevd in the meantime. :)
What kind of system you are seeing problems? Is it a known distribution?
How do you handle the temporary rules files you copy into
/dev/.udev/rules.d/? How do they get into /etc?
> Note that this change by itself won't work on most distributions (with
> read only fses) unless they they also make sure that the
> /dev/.udev/rules.d directory is created before udevd starts up, since
> otherwise the inotify will never trigger for that directory since it
> didn't exist when the inotify call was made.
What do you mean? Udevd itself creates this directory, and watches it
with inotify.
Kay
^ permalink raw reply
* Re: [PATCH] Fix udev "temporary rules" for read-only root
From: Marco d'Itri @ 2010-05-27 7:24 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <AANLkTineHRuPMK927ItHexZNN4UFniawyMwxgqztc1GZ@mail.gmail.com>
On May 27, Kay Sievers <kay.sievers@vrfy.org> wrote:
> I think these temporary rules have never been expected to be read by
> the udev daemon directly.
Indeed, I invented this for Debian which copies the files to
/etc/udev/rules.d/ in /etc/init.d/udev-mtab.
--
ciao,
Marco
^ permalink raw reply
* Re: [PATCH] Fix udev "temporary rules" for read-only root filesystems
From: Paul Stewart @ 2010-05-27 13:55 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <AANLkTineHRuPMK927ItHexZNN4UFniawyMwxgqztc1GZ@mail.gmail.com>
Thanks for the great info. I'm mostly sold that the current behavior
is a intended. I'm using a read-only-root distribution, and as such I
started this process of solving device incrementation by moving /etc/
udev/rules.d to a symlink to a writable partition.
However, I did discover a few things along the way which inspired this
patch.
Firstly, the rules in /dev/.udev are essentially "write only". Udevd
does not monitor this directory, which on the surface is okay if you
assume you will only need it briefly while in initrd. However, since
udevd never reads these rules, a device "flicker" during boot (e.g. a
usb network device detaches and re-attaches due to initial firmware
load) will cause two rules for the same device to be written to the /
dev/.udevd tmp-.rules file.
The reason for that us dual. When the device reattaches, udev finds no
rules since it doesn't monitor that directory so "NAME=" I'd never
assigned by the time the 75-persistent-rules generator runs. The
generator script doesn't care that the MAC or other identifiers for
this device are identical -- it just makes sure that if an "eth0"
already exists, that it now name the device "eth1".
So I was confused about who if anyone puts rules in /dev/.udevd/
rules.d. I read the comment in the generator code and it seemed to
imply that the location it was writing to would be seen by udev, so I
just assumed it was a mistake and merged the two. If that's not
correct, could someone clarify why that is worse than what is there
now? This way rules created by the generator go directly into udev
instead of waiing until later in the boot cycle.
Secondly, assuming the current configuration has always been the case,
I would assume nobody has actually tested that inotify works on /
dev/.udevd/rules.d if the directory does not already exist before
udevd has started. I have done this myself and it does not. If that is
unexpected behavior for udevd, I'll hunt down the issue in the C code
and send a patch for that instead of one for the unit script.
Thanks so much for the responses!
--
Paul
On May 26, 2010, at 11:02 PM, Kay Sievers <kay.sievers@vrfy.org> wrote:
> On Thu, May 27, 2010 at 01:03, Paul Stewart <pstew@google.com> wrote:
>> Fix udev issue where temporary persistent rules are written in one
>> place and read from another. The upstream udev release placed
>> dynamic
>> persistent rules (ones that get deleted every reboot) in /dev/.udev/,
>> but the actual udev daemon read these rules out of
>> /dev/.udev/rules.d/.
>
> I think these temporary rules have never been expected to be read by
> the udev daemon directly.
>
>> The side effect of this is that if the static
>> directory (/etc/udev/rules.d) is not writeable (read-only root
>> filesystem, for example), device interfaces keep getting renamed
>> wlan0, wlan1, wlan2, etc, if they are plugged and unplugged or if
>> udevd restarts.
>
> The temporary rules files, which might be created in /dev/.udev/ are
> supposed to be copied to /etc/udev/rules.d/ as soon as the rootfs is
> writable. There should be no restart of udevd in the meantime. :)
>
> What kind of system you are seeing problems? Is it a known
> distribution?
>
> How do you handle the temporary rules files you copy into
> /dev/.udev/rules.d/? How do they get into /etc?
>
>> Note that this change by itself won't work on most distributions
>> (with
>> read only fses) unless they they also make sure that the
>> /dev/.udev/rules.d directory is created before udevd starts up, since
>> otherwise the inotify will never trigger for that directory since it
>> didn't exist when the inotify call was made.
>
> What do you mean? Udevd itself creates this directory, and watches it
> with inotify.
>
> Kay
^ permalink raw reply
* Re: [PATCH] Fix udev "temporary rules" for read-only root filesystems
From: Kay Sievers @ 2010-05-27 14:16 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <AANLkTineHRuPMK927ItHexZNN4UFniawyMwxgqztc1GZ@mail.gmail.com>
On Thu, May 27, 2010 at 15:55, Paul Stewart <pstew@google.com> wrote:
> So I was confused about who if anyone puts rules in /dev/.udevd/
> rules.d. I read the comment in the generator code and it seemed to
> imply that the location it was writing to would be seen by udev, so I
> just assumed it was a mistake and merged the two. If that's not
> correct, could someone clarify why that is worse than what is there
> now? This way rules created by the generator go directly into udev
> instead of waiing until later in the boot cycle.
I guess the generator is older than the /dev/.udev/rules.d/ directory.
We could think about moving these rules there. Not sure, if there are
any unwanted side-effects.
> Secondly, assuming the current configuration has always been the case,
> I would assume nobody has actually tested that inotify works on /
> dev/.udevd/rules.d if the directory does not already exist before
> udevd has started. I have done this myself and it does not. If that is
> unexpected behavior for udevd, I'll hunt down the issue in the C code
> and send a patch for that instead of one for the unit script.
The generator run from udev rules, started by udevd. How should
anything write a rule when udevd is not running? :)
Kay
^ permalink raw reply
* [PATCH 1/2] Export firmware assigned labels of network devices to
From: K, Narendra @ 2010-05-28 11:55 UTC (permalink / raw)
To: netdev@vger.kernel.org, linux-hotplug@vger.kernel.org,
linux-pci@vger.kernel.org
Cc: Domsch, Matt, Hargrave, Jordan, Rose, Charles, Nijhawan, Vijay
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.
2.If the system firmware does not provide ACPI _DSM, then implementation falls back
onto SMBIOS and exports SMBIOS labels to sysfs.
3. If SMBIOS is not available, no label will be created.
For an example user space implementation please look at this link -
http://linux.dell.com/wiki/index.php/Oss/libnetdevname
Please review -
From: Narendra K <Narendra_K@dell.com>
This patch exports the firmware assigned labels of network devices to
sysfs which could be used by user space.This helps in providing more
meaningful names to network devices such as
Embedded Broadcom 5709C NIC 1 - First on board netwrok interface
Signed-off-by: Jordan Hargrave <Jordan_Hargrave@dell.com>
Signed-off-by: Narendra K <Narendra_K@dell.com>
---
drivers/firmware/dmi_scan.c | 24 +++++
drivers/pci/Makefile | 2 +-
drivers/pci/pci-label.c | 242 +++++++++++++++++++++++++++++++++++++++++++
drivers/pci/pci-sysfs.c | 6 +
include/linux/dmi.h | 9 ++
include/linux/pci-label.h | 38 +++++++
6 files changed, 320 insertions(+), 1 deletions(-)
create mode 100644 drivers/pci/pci-label.c
create mode 100644 include/linux/pci-label.h
diff --git a/drivers/firmware/dmi_scan.c b/drivers/firmware/dmi_scan.c
index d464672..7d8439b 100644
--- a/drivers/firmware/dmi_scan.c
+++ b/drivers/firmware/dmi_scan.c
@@ -277,6 +277,28 @@ static void __init dmi_save_ipmi_device(const struct dmi_header *dm)
list_add_tail(&dev->list, &dmi_devices);
}
+static void __init dmi_save_devslot(int id, int seg, int bus, int devfn, const char *name)
+{
+ struct dmi_devslot *slot;
+
+ slot = dmi_alloc(sizeof(*slot) + strlen(name) + 1);
+ if (!slot) {
+ printk(KERN_ERR "dmi_save_devslot: out of memory.\n");
+ return;
+ }
+ slot->id = id;
+ slot->seg = seg;
+ slot->bus = bus;
+ slot->devfn = devfn;
+
+ strcpy((char *)&slot[1], name);
+ slot->dev.type = DMI_DEV_TYPE_DEVSLOT;
+ slot->dev.name = (char *)&slot[1];
+ slot->dev.device_data = slot;
+
+ list_add(&slot->dev.list, &dmi_devices);
+}
+
static void __init dmi_save_extended_devices(const struct dmi_header *dm)
{
const u8 *d = (u8*) dm + 5;
@@ -285,6 +307,7 @@ static void __init dmi_save_extended_devices(const struct dmi_header *dm)
if ((*d & 0x80) = 0)
return;
+ dmi_save_devslot(-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 +356,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..f3f4c37
--- /dev/null
+++ b/drivers/pci/pci-label.c
@@ -0,0 +1,242 @@
+/*
+ * File: drivers/pci/pci-label.c
+ * 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>
+
+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},
+ .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[] = {
+ 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);
+
+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);
+
diff --git a/drivers/pci/pci-sysfs.c b/drivers/pci/pci-sysfs.c
index fad9398..30fa62b 100644
--- a/drivers/pci/pci-sysfs.c
+++ b/drivers/pci/pci-sysfs.c
@@ -23,6 +23,7 @@
#include <linux/mm.h>
#include <linux/capability.h>
#include <linux/pci-aspm.h>
+#include <linux/pci-label.h>
#include <linux/slab.h>
#include "pci.h"
@@ -1073,6 +1074,8 @@ int __must_check pci_create_sysfs_dev_files (struct pci_dev *pdev)
if (retval)
goto err_vga_file;
+ pci_create_acpi_attr_files(pdev);
+
return 0;
err_vga_file:
@@ -1140,6 +1143,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_acpi_attr_files(pdev);
+
}
static int __init pci_sysfs_init(void)
diff --git a/include/linux/dmi.h b/include/linux/dmi.h
index a8a3e1a..cc57c3a 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_DEVSLOT = -3,
};
struct dmi_header {
@@ -37,6 +38,14 @@ struct dmi_device {
#ifdef CONFIG_DMI
+struct dmi_devslot {
+ struct dmi_device dev;
+ int id;
+ int seg;
+ 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);
diff --git a/include/linux/pci-label.h b/include/linux/pci-label.h
new file mode 100644
index 0000000..e9a4dfb
--- /dev/null
+++ b/include/linux/pci-label.h
@@ -0,0 +1,38 @@
+/*
+ * File include/linux/pci-label.h
+ * Copyright (C) 2010 Dell Inc.
+ * by Narendra K <Narendra_K@dell.com>, Jordan Hargrave <Jordan_Hargrave@dell.com>
+ */
+
+#ifndef _PCI_LABEL_H_
+#define _PCI_LABEL_H_
+
+#include <linux/dmi.h>
+#include <linux/sysfs.h>
+#include <linux/pci.h>
+#include <linux/pci_ids.h>
+#include <linux/module.h>
+#include <linux/acpi.h>
+#include <linux/pci-acpi.h>
+#include <acpi/acpi_drivers.h>
+#include <acpi/acpi_bus.h>
+
+struct smbios_attribute {
+ struct attribute attr;
+ ssize_t (*show) (struct device *dev, char *buf);
+ ssize_t (*test) (struct device *dev, char *buf);
+};
+
+struct acpi_attribute {
+ struct attribute attr;
+ ssize_t (*show) (struct device *dev, char *buf);
+ ssize_t (*test) (struct device *dev, char *buf);
+};
+
+#define DELL_DSM_NETWORK 0x07
+
+extern int pci_create_acpi_attr_files(struct pci_dev *pdev);
+extern int pci_remove_acpi_attr_files(struct pci_dev *pdev);
+
+#endif /* _PCI_LABEL_H_ */
+
--
1.6.5.2
With regards,
Narendra K
^ permalink raw reply related
* [PATCH 2/2] dmi: save OEM defined slot information
From: K, Narendra @ 2010-05-28 12:06 UTC (permalink / raw)
To: netdev@vger.kernel.org, linux-hotplug@vger.kernel.org,
linux-pci@vger.kernel.org
Cc: achiang@hp.com, Domsch, Matt, Hargrave, Jordan, Rose, Charles,
Nijhawan, Vijay
Hello,
This patch from Alex Chiang exports onboard device information as defined by
SMBIOS type 209 for HP Proliants systems.
From: Alex Chiang <achiang@hp.com>
Some legacy platforms provide onboard device information in an SMBIOS OEM-
defined field, notably HP Proliants.
This information can be used to provide information to userspace that allows
correlation between a Linux PCI device and a chassis label.
Save this information so that it can be exposed to userspace. We choose the
string "Embedded NIC %d" since there are known platforms from other vendors
(Dell) that provide a string in this format for their onboard NICs (although
theirs is provided by a Type 41 record). This consistency will help simplify
life for userspace tools.
Only support HP platforms for now. If we need support for another vendor in
the future, we can write a fancier implementation then.
This code was inspired by the implementation in the userspace dmidecode tool,
which was originally written by John Cagle.
Signed-off-by: Alex Chiang <achiang@hp.com>
---
drivers/firmware/dmi_scan.c | 29 +++++++++++++++++++++++++++++
1 files changed, 29 insertions(+), 0 deletions(-)
diff --git a/drivers/firmware/dmi_scan.c b/drivers/firmware/dmi_scan.c
index 7d8439b..291b876 100644
--- a/drivers/firmware/dmi_scan.c
+++ b/drivers/firmware/dmi_scan.c
@@ -311,6 +311,32 @@ static void __init dmi_save_extended_devices(const struct dmi_header *dm)
dmi_save_one_device(*d & 0x7f, dmi_string_nosave(dm, *(d - 1)));
}
+static void __init dmi_save_oem_devices(const struct dmi_header *dm) {
+ int bus, devfn, count;
+ const u8 *d = (u8 *)dm + 4;
+ char name[20];
+
+ /* Only handle HP extensions for now */
+ if (strcmp(dmi_ident[DMI_BIOS_VENDOR], "HP"))
+ return;
+
+ count = 1;
+ while ((d + 8) <= ((u8 *)dm + dm->length)) {
+ if ((*d = 0x00 && *(d + 1) = 0x00) ||
+ (*d = 0xff && *(d + 1) = 0xff))
+ goto next;
+
+ bus = *(d + 1);
+ devfn = *d;
+ sprintf(name, "Embedded NIC %d", count);
+ dmi_save_devslot(-1, 0, bus, devfn, name);
+
+next:
+ count++;
+ d += 8;
+ }
+}
+
/*
* Process a DMI table entry. Right now all we care about are the BIOS
* and machine entries. For 2.5 we should pull the smbus controller info
@@ -357,6 +383,9 @@ static void __init dmi_decode(const struct dmi_header *dm, void *dummy)
case 41: /* Onboard Devices Extended Information */
dmi_save_extended_devices(dm);
break;
+ case 209:
+ dmi_save_oem_devices(dm);
+ break;
}
}
--
1.6.5.2
With regards,
Narendra K
^ permalink raw reply related
* 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
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