* Failure to build ata_id
From: Thomas Koeller @ 2011-01-03 22:29 UTC (permalink / raw)
To: linux-hotplug
Hi,
since kernel release v2.6.35-rc1 (commit 7407e5bba2cc821950344fd1391d9ad1b7e0b397),
scsi/scsi.h is no longer part of the exported kernel headers. Since then, it has
not been possible to do a full build of udev anymore, because extras/ata_id/ata_id.c
wants to include this header.
I suppose new udev releases are tested with a current kernel? Am I missing something?
Thomas
^ permalink raw reply
* At wits end with a Broadcom Corp BCM92046DG-CL1ROM
From: gene heskett @ 2011-01-03 20:52 UTC (permalink / raw)
To: linux-hotplug, linux-bluetooth
In-Reply-To: <201101021327.41699.gheskett@wdtv.com>
Greetings all;
Ping? Repeat post with a few additions.
This device, a bluetooth button/dongle, or the a7 eb101 it pairs with to
create a virtual rs232 cable, have to be the most obstinate inanimate
devices ever.
AIUI the BT specs, 2 devices once paired, are to remain so, even after
powerdowns, until such time as a new pairing is performed. Right/wrong?
It takes about a days messing around to finally get it to work, usually
accomplished by unplugging it long enough for linux to detect and do the
cleanup. Then when plugging it back in, if one is quick enough to catch it
before bluetoothd times out and goes away and gets blueman-manager running
within this timeout, which appears to be in the 5 second range after its
rediscovery, then, 1 time only per reboot of this machine, I can get it to
work, and it works error free, with good signal strength showing in
blueman-manager. For possibly 12 hours or so. At some point, blueman-
manager goes away silently, and the link is dropped and cannot be re-
established by the same procedure until I have rebooted both boxes again.
Pertinent (maybe) info:
current kernel: 2.6.37-rc8
current distro: PClos, 32 bit, 100% uptodate
current hdwe: AMD quad core phenom, 4Gb dram, 4 Tb of drives
current gui: KDE-4.5.4
I have edited /etc/bluetooth/rfcomm.conf to:
#
# RFCOMM configuration file.
#
# this was ALL commented out
rfcomm0 {
# # Automatically bind the device at startup
bind yes;
#
# # Bluetooth address of the device
device 00:0C:84:00:86:F8;
#
# # RFCOMM channel for the connection
channel 1;
#
# # Description of the connection
# comment "Example Bluetooth device";
comment "connection to coco3's eb-301 device";
}
Added question: Pin seems to be a problem as I have to answer several
requests for it, and it seems to work only if I press the enter key in the
requester box, which seemingly has no effect, and then click the ok button,
which puts 5 bytes in the buffer. And FWIW, I have noted that the 4 digit
pin is stored as 5 bytes long no matter how I generate it, including
deleting the file and building a new one. So my added question is, why is
the return key not being accepted as the "go do it" key?
And as of this instant /dev/rfcomm0 has not been removed. And the link is
dead. And is again working after a reboot of both machines. No clue how
long though.
It seems to me there should be a foolproof method that will accomplish this
from reboot to reboot, but I haven't found the method yet despite warming
up googles servers searching for instructional material that does NOT
appear to exist or is so dated that the 2nd or third example in any of
those tuts is no longer valid.
What can I do, or better yet, URL's where can I find the info that makes
this Just Work(TM) for a more modern 2010-2011 distribution using todays
kernels?
Thanks all.
--
Cheers, Gene
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
^ permalink raw reply
* Re: [PATCH] Remap Eee PC touchpad toggle key to F21 used by X
From: Martin Pitt @ 2011-01-03 8:32 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <1293918278-2585-1-git-send-email-chris@cnpbagwell.com>
Hello Chris,
chris@cnpbagwell.com [2011-01-01 15:44 -0600]:
> Currently, Eee PC have a hotkey that generates KEY_F13 but this
> will soon change to KEY_TOUCHPAD_TOOGLE. Both cases do not
> work well with X.
>
> X has defined F21 for the purpose of touchpad toggle and other
> udev keymaps align with this meaning. Patch aligns Eee PC
> hotkey drivers with F21.
Thanks! Applied.
Martin
--
Martin Pitt | http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)
^ permalink raw reply
* At wits end with a Broadcom Corp BCM92046DG-CL1ROM
From: gene heskett @ 2011-01-02 18:27 UTC (permalink / raw)
To: linux-hotplug, linux-bluetooth
Greetings all;
This device, a bluetooth button/dongle, or the a7 eb101 it pairs with to
create a virtual rs232 cable, have to be the most obstinate inanimate
devices ever.
AIUI the BT specs, 2 devices once paired, are to remain so, even after
powerdowns, until such time as a new pairing is performed. Right? Or does
linux impose its own rules for low traffic, slow (9600 baud) bluetooth
links?
It takes about a days messing around to finally get it to work, usually
accomplished by unplugging it long enough for linux to detect and do the
cleanup. Then when plugging it back in, if one is quick enough to catch it
before bluetoothd times out and goes away and gets blueman-manager running
within this timeout, which appears to be in the 5 second range after its
rediscovery, then, 1 time only per reboot of this machine, I can get it to
work, and it works error free, with good signal strength showing in
blueman-manager. For possibly 12 hours or so. At some point, blueman-
manager goes away silently, and the link is dropped and cannot be re-
established by the same procedure until I have rebooted this box again.
Pertinent (maybe) info:
current kernel: 2.6.37-rc8
current distro: PClos, 32 bit, 100% uptodate
current hdwe: AMD quad core phenom, 4Gb dram, 4 Tb of drives
current gui: KDE-4.5.4
I have edited /etc/bluetooth/rfcomm.conf to:
#
# RFCOMM configuration file.
#
# this was ALL commented out
rfcomm0 {
# # Automatically bind the device at startup
bind yes;
#
# # Bluetooth address of the device
device 00:0C:84:00:86:F8;
#
# # RFCOMM channel for the connection
channel 1;
#
# # Description of the connection
# comment "Example Bluetooth device";
comment "connection to coco3's eb-301 device";
}
And as of this instant /dev/rfcomm0 has not been removed. And the link is
dead.
It seems to me there should be a foolproof method that will accomplish this
from reboot to reboot, but I haven't found the method yet despite warming
up googles servers searching for instructional material that does NOT
appear to exist.
What can I do, or better yet, where can I find the info that makes this
Just Work(TM)?
Thanks all.
--
Cheers, Gene
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
New Microsoft PnP documents released: http://www.microsoft.eu.org/PnP.html
^ permalink raw reply
* [PATCH] Remap Eee PC touchpad toggle key to F21 used by X
From: chris @ 2011-01-01 21:44 UTC (permalink / raw)
To: linux-hotplug
From: Chris Bagwell <chris@cnpbagwell.com>
Currently, Eee PC have a hotkey that generates KEY_F13 but this
will soon change to KEY_TOUCHPAD_TOOGLE. Both cases do not
work well with X.
X has defined F21 for the purpose of touchpad toggle and other
udev keymaps align with this meaning. Patch aligns Eee PC
hotkey drivers with F21.
Tested on Eee PC 1005PE using both eeepc-wmi and eeepc-laptop driver
(with acpi_osi="!Windows 2009").
Signed-off-by: Chris Bagwell <chris@cnpbagwell.com>
---
| 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
--git a/extras/keymap/95-keymap.rules b/extras/keymap/95-keymap.rules
index 053838d..9059a8c 100644
--- a/extras/keymap/95-keymap.rules
+++ b/extras/keymap/95-keymap.rules
@@ -44,6 +44,8 @@ ENV{DMI_VENDOR}="LENOVO*", KERNELS="input*", ATTRS{name}="ThinkPad Extra Butt
ENV{DMI_VENDOR}="LENOVO*", KERNELS="input*", ATTRS{name}="Lenovo ThinkPad SL Series extra buttons", RUN+="keymap $name 0x0E bluetooth"
ENV{DMI_VENDOR}="ASUS*", KERNELS="input*", ATTRS{name}="Asus Extra Buttons", ATTR{[dmi/id]product_name}="W3J", RUN+="keymap $name module-asus-w3j"
ENV{DMI_VENDOR}="Sony*", KERNELS="input*", ATTRS{name}="Sony Vaio Keys", RUN+="keymap $name module-sony"
+ENV{DMI_VENDOR}="ASUS*", KERNELS="input*", ATTRS{name}="Eee PC WMI hotkeys", RUN+="keymap $name 0x6B f21"
+ENV{DMI_VENDOR}="ASUS*", KERNELS="input*", ATTRS{name}="Eee PC Hotkey Driver", RUN+="keymap $name 0x37 f21"
# Older Vaios have some different keys
ENV{DMI_VENDOR}="Sony*", ATTR{[dmi/id]product_name}="*PCG-C1*|*PCG-K25*|*PCG-F1*|*PCG-F2*|*PCG-F3*|*PCG-F4*|*PCG-F5*|*PCG-F6*|*PCG-FX*|*PCG-FRV*|*PCG-GR*|*PCG-TR*|*PCG-NV*|*PCG-Z*|*VGN-S360*", ATTRS{name}="Sony Vaio Keys", RUN+="keymap $name module-sony-old"
--
1.7.3.4
^ permalink raw reply related
* Re: PCI/USB Vendor and model from database
From: José Félix Ontañón @ 2010-12-30 0:08 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <AANLkTi=1GzSurOXcFwBJUXfXBch24QB3cRh+0qo1a1Fp@mail.gmail.com>
El día 29 de diciembre de 2010 17:34, Kay Sievers
<kay.sievers@vrfy.org> escribió:
> 2010/12/29 José Félix Ontañón <felixonta@gmail.com>:
>> El día 29 de diciembre de 2010 01:18, Scott James Remnant
>> <scott@netsplit.com> escribió:
>>> 2010/12/28 Lennart Poettering <lennart@poettering.net>:
>>>> On Tue, 28.12.10 14:14, José Félix Ontañón (felixonta@gmail.com) wrote:
>>>>>
>>>>> Maybe this is kinda silly question but, I wonder why isn't
>>>>> "ID_VENDOR_FROM_DATABASE / ID_MODEL_FROM_DATABASE"-like properties
>>>>> imported by default using the pretty /lib/udev/usb-db and
>>>>> /lib/udev/pci-db commands for every founded pci/usb device?
>>>>>
>>>>> I mean, by adding this simple rules:
>>>>>
>>>>> SUBSYSTEMS="usb", IMPORT{program}="usb-db %p"
>>>>> SUBSYSTEMS="pci", IMPORT{program}="pci-db %p"
>>>>>
>>>>> I think this properties are very useful for apps that discover
>>>>> hardware through udev, so they will not have to reinvent the wheel by
>>>>> finding vendor/product names by themselves. Don't you think?
>>>>
>>>> The database lookup is a linear search. As long as we invoke it only for
>>>> a small subset of devices that doesn't really matter much. But if we
>>>> start to look it up for every device we should probably spend the time
>>>> to improve the db lookup first.
>>>>
>>>> It's simply a question of efficiency.
>>>>
>>> One thing that might be interesting is if we could do the lookup at
>>> the point of query, then store the answer back in the db for others to
>>> use later.
>>>
>>> That way we're efficient if nobody cares, and lose that efficiency
>>> when they do (but only for the devices they query), and subsequently
>>> efficient because the answer is cached.
>>>
>>> This veers a bit dangerously towards having apps that link with
>>> libudev process rules though?
>
>> First thing coming to my mind: there's not enough pci/usb devices
>> present on the system for increasing the computational cost
>> significantly. Querying the vendor/model names will be performed only
>> one time, at udev running, and then only one time on "add" action for
>> this subsystems. Am i wrong?
>
> As Greg says, it really can be a lot of devices, and the linear search
> in a huge text file isn't exactly what we want to do. We might need a
> real indexed database. Ideally one that does not only contain human
> readable identifiers but also whatever meta-data which is useful to
> users.
>
>> Anyway, taking care about the efficiency, the Scott solutions sounds
>> good to me but implies development on udev directly. I'm writing some
>> apps using udev so, in the meantime, will be really nice if some more
>> questions could be answered:
>
> It's difficult. We run in untrusted user-context, and can not update
> the udev database. It would be a major change in the architecture,
> which I'm not sure we should get into that. For many of the devices
> on-demand will not be sufficient, as we need the symlinks, tags and
> other things.
Ok, I see the problem, Kay. Lots of design for a system that pretends
to be small, isn't?
>> Is it acceptable to add the mentioned udev rule for a system
>> application using udev? I mean, i.e. udisk add some rules for
>> importing some props. And for a desktop app? Is it acceptable too?
>
> Sure, you can do that. Just check that it isn't already run before your rules.
I hope you don't mind if I tell the whole history now:
I'm working on a gnome-device-manager like app[1] (hal/dbus based). By
now it just pretends to be an user-friendly version of Lennart
Poettering udev-browse (browsing /sys as a treeview). I've realized
linux users tends to use lshw/lspci/lsusb for checking the
vendor_id/product_id and vendor/model names, so i though it could be
useful if a gnome-device-manager like app tell them.
After some of your and Greg's comments I think there's no doubt adding
the udev rules for importing the PCI/USB Vendor and model from
database it's not a good idea.
So, talking about efficiency, is it better to use "libwhatever" for
querying for the vendor/model names everytime the user launchs the
app?
[1] http://gitorious.org/udev-discover
>> I think it's quite comfortable, for me as desktop app coder, to
>> delegate on udev the vendor/model name querying, more if we think udev
>> provides the cool pci-db and usb-db commands.
>
> As Greg already pointed out, you should probably look up the stuff you
> need, yourself in the database files.
Well, and that points to my prev question. Is it acceptable to look up
the database files everytime the user runs the app? Not my intention
to appear lazy but I see myself doing nothing about it or coding a
vendor/model names cache or something alike, and i wonder if there's
no other way ...
> Udev must not become the new HAL. We need to be very very careful here. :)
Absolutely. I'm concerned about the problem.
> Kay
Thanks for your gentle answers Kay.
--
http://fontanon.org
^ permalink raw reply
* Re: PCI/USB Vendor and model from database
From: José Félix Ontañón @ 2010-12-29 23:09 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <AANLkTi=1GzSurOXcFwBJUXfXBch24QB3cRh+0qo1a1Fp@mail.gmail.com>
El día 29 de diciembre de 2010 17:16, Greg KH <greg@kroah.com> escribió:
> On Wed, Dec 29, 2010 at 05:08:56PM +0100, José Félix Ontañón wrote:
>> El día 29 de diciembre de 2010 01:18, Scott James Remnant
>> <scott@netsplit.com> escribió:
>> > 2010/12/28 Lennart Poettering <lennart@poettering.net>:
>> >> On Tue, 28.12.10 14:14, José Félix Ontañón (felixonta@gmail.com) wrote:
>> >>
>> >>> Hi, everybody!
>> >>>
>> >>> Maybe this is kinda silly question but, I wonder why isn't
>> >>> "ID_VENDOR_FROM_DATABASE / ID_MODEL_FROM_DATABASE"-like properties
>> >>> imported by default using the pretty /lib/udev/usb-db and
>> >>> /lib/udev/pci-db commands for every founded pci/usb device?
>> >>>
>> >>> I mean, by adding this simple rules:
>> >>>
>> >>> SUBSYSTEMS="usb", IMPORT{program}="usb-db %p"
>> >>> SUBSYSTEMS="pci", IMPORT{program}="pci-db %p"
>> >>>
>> >>> I think this properties are very useful for apps that discover
>> >>> hardware through udev, so they will not have to reinvent the wheel by
>> >>> finding vendor/product names by themselves. Don't you think?
>> >>
>> >> The database lookup is a linear search. As long as we invoke it only for
>> >> a small subset of devices that doesn't really matter much. But if we
>> >> start to look it up for every device we should probably spend the time
>> >> to improve the db lookup first.
>> >>
>> >> It's simply a question of efficiency.
>> >>
>> > One thing that might be interesting is if we could do the lookup at
>> > the point of query, then store the answer back in the db for others to
>> > use later.
>> >
>> > That way we're efficient if nobody cares, and lose that efficiency
>> > when they do (but only for the devices they query), and subsequently
>> > efficient because the answer is cached.
>> >
>> > This veers a bit dangerously towards having apps that link with
>> > libudev process rules though?
>> >
>> > Scott
>> >
>>
>> First thing coming to my mind: there's not enough pci/usb devices
>> present on the system for increasing the computational cost
>> significantly.
>
> How can you say that? I see systems with thousands of PCI devices on it
> as being very common in some areas.
You're right, I was to fast thinking about personal_computers-like
only. That's because I said it maybe was a silly question, sorry.
>> I think it's quite comfortable, for me as desktop app coder, to
>> delegate on udev the vendor/model name querying, more if we think udev
>> provides the cool pci-db and usb-db commands.
>
> Again, what's wrong with using libpci directly for this? That's what it
> is there for.
Greg, i'm coding python, do you know about a python bindings for
libpci? It would be really nice if you could tell me because I didn't
found.
Thanks for your answers.
> thanks,
>
> greg k-h
>
--
http://fontanon.org
^ permalink raw reply
* Re: PCI/USB Vendor and model from database
From: Kay Sievers @ 2010-12-29 16:34 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <AANLkTi=1GzSurOXcFwBJUXfXBch24QB3cRh+0qo1a1Fp@mail.gmail.com>
2010/12/29 José Félix Ontañón <felixonta@gmail.com>:
> El día 29 de diciembre de 2010 01:18, Scott James Remnant
> <scott@netsplit.com> escribió:
>> 2010/12/28 Lennart Poettering <lennart@poettering.net>:
>>> On Tue, 28.12.10 14:14, José Félix Ontañón (felixonta@gmail.com) wrote:
>>>>
>>>> Maybe this is kinda silly question but, I wonder why isn't
>>>> "ID_VENDOR_FROM_DATABASE / ID_MODEL_FROM_DATABASE"-like properties
>>>> imported by default using the pretty /lib/udev/usb-db and
>>>> /lib/udev/pci-db commands for every founded pci/usb device?
>>>>
>>>> I mean, by adding this simple rules:
>>>>
>>>> SUBSYSTEMS="usb", IMPORT{program}="usb-db %p"
>>>> SUBSYSTEMS="pci", IMPORT{program}="pci-db %p"
>>>>
>>>> I think this properties are very useful for apps that discover
>>>> hardware through udev, so they will not have to reinvent the wheel by
>>>> finding vendor/product names by themselves. Don't you think?
>>>
>>> The database lookup is a linear search. As long as we invoke it only for
>>> a small subset of devices that doesn't really matter much. But if we
>>> start to look it up for every device we should probably spend the time
>>> to improve the db lookup first.
>>>
>>> It's simply a question of efficiency.
>>>
>> One thing that might be interesting is if we could do the lookup at
>> the point of query, then store the answer back in the db for others to
>> use later.
>>
>> That way we're efficient if nobody cares, and lose that efficiency
>> when they do (but only for the devices they query), and subsequently
>> efficient because the answer is cached.
>>
>> This veers a bit dangerously towards having apps that link with
>> libudev process rules though?
> First thing coming to my mind: there's not enough pci/usb devices
> present on the system for increasing the computational cost
> significantly. Querying the vendor/model names will be performed only
> one time, at udev running, and then only one time on "add" action for
> this subsystems. Am i wrong?
As Greg says, it really can be a lot of devices, and the linear search
in a huge text file isn't exactly what we want to do. We might need a
real indexed database. Ideally one that does not only contain human
readable identifiers but also whatever meta-data which is useful to
users.
> Anyway, taking care about the efficiency, the Scott solutions sounds
> good to me but implies development on udev directly. I'm writing some
> apps using udev so, in the meantime, will be really nice if some more
> questions could be answered:
It's difficult. We run in untrusted user-context, and can not update
the udev database. It would be a major change in the architecture,
which I'm not sure we should get into that. For many of the devices
on-demand will not be sufficient, as we need the symlinks, tags and
other things.
> Is it acceptable to add the mentioned udev rule for a system
> application using udev? I mean, i.e. udisk add some rules for
> importing some props. And for a desktop app? Is it acceptable too?
Sure, you can do that. Just check that it isn't already run before your rules.
> I think it's quite comfortable, for me as desktop app coder, to
> delegate on udev the vendor/model name querying, more if we think udev
> provides the cool pci-db and usb-db commands.
As Greg already pointed out, you should probably look up the stuff you
need, yourself in the database files.
Udev must not become the new HAL. We need to be very very careful here. :)
Kay
^ permalink raw reply
* Re: PCI/USB Vendor and model from database
From: Greg KH @ 2010-12-29 16:16 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <AANLkTi=1GzSurOXcFwBJUXfXBch24QB3cRh+0qo1a1Fp@mail.gmail.com>
On Wed, Dec 29, 2010 at 05:08:56PM +0100, José Félix Ontañón wrote:
> El día 29 de diciembre de 2010 01:18, Scott James Remnant
> <scott@netsplit.com> escribió:
> > 2010/12/28 Lennart Poettering <lennart@poettering.net>:
> >> On Tue, 28.12.10 14:14, José Félix Ontañón (felixonta@gmail.com) wrote:
> >>
> >>> Hi, everybody!
> >>>
> >>> Maybe this is kinda silly question but, I wonder why isn't
> >>> "ID_VENDOR_FROM_DATABASE / ID_MODEL_FROM_DATABASE"-like properties
> >>> imported by default using the pretty /lib/udev/usb-db and
> >>> /lib/udev/pci-db commands for every founded pci/usb device?
> >>>
> >>> I mean, by adding this simple rules:
> >>>
> >>> SUBSYSTEMS="usb", IMPORT{program}="usb-db %p"
> >>> SUBSYSTEMS="pci", IMPORT{program}="pci-db %p"
> >>>
> >>> I think this properties are very useful for apps that discover
> >>> hardware through udev, so they will not have to reinvent the wheel by
> >>> finding vendor/product names by themselves. Don't you think?
> >>
> >> The database lookup is a linear search. As long as we invoke it only for
> >> a small subset of devices that doesn't really matter much. But if we
> >> start to look it up for every device we should probably spend the time
> >> to improve the db lookup first.
> >>
> >> It's simply a question of efficiency.
> >>
> > One thing that might be interesting is if we could do the lookup at
> > the point of query, then store the answer back in the db for others to
> > use later.
> >
> > That way we're efficient if nobody cares, and lose that efficiency
> > when they do (but only for the devices they query), and subsequently
> > efficient because the answer is cached.
> >
> > This veers a bit dangerously towards having apps that link with
> > libudev process rules though?
> >
> > Scott
> >
>
> First thing coming to my mind: there's not enough pci/usb devices
> present on the system for increasing the computational cost
> significantly.
How can you say that? I see systems with thousands of PCI devices on it
as being very common in some areas.
> I think it's quite comfortable, for me as desktop app coder, to
> delegate on udev the vendor/model name querying, more if we think udev
> provides the cool pci-db and usb-db commands.
Again, what's wrong with using libpci directly for this? That's what it
is there for.
thanks,
greg k-h
^ permalink raw reply
* Re: PCI/USB Vendor and model from database
From: José Félix Ontañón @ 2010-12-29 16:08 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <AANLkTi=1GzSurOXcFwBJUXfXBch24QB3cRh+0qo1a1Fp@mail.gmail.com>
El día 29 de diciembre de 2010 01:18, Scott James Remnant
<scott@netsplit.com> escribió:
> 2010/12/28 Lennart Poettering <lennart@poettering.net>:
>> On Tue, 28.12.10 14:14, José Félix Ontañón (felixonta@gmail.com) wrote:
>>
>>> Hi, everybody!
>>>
>>> Maybe this is kinda silly question but, I wonder why isn't
>>> "ID_VENDOR_FROM_DATABASE / ID_MODEL_FROM_DATABASE"-like properties
>>> imported by default using the pretty /lib/udev/usb-db and
>>> /lib/udev/pci-db commands for every founded pci/usb device?
>>>
>>> I mean, by adding this simple rules:
>>>
>>> SUBSYSTEMS="usb", IMPORT{program}="usb-db %p"
>>> SUBSYSTEMS="pci", IMPORT{program}="pci-db %p"
>>>
>>> I think this properties are very useful for apps that discover
>>> hardware through udev, so they will not have to reinvent the wheel by
>>> finding vendor/product names by themselves. Don't you think?
>>
>> The database lookup is a linear search. As long as we invoke it only for
>> a small subset of devices that doesn't really matter much. But if we
>> start to look it up for every device we should probably spend the time
>> to improve the db lookup first.
>>
>> It's simply a question of efficiency.
>>
> One thing that might be interesting is if we could do the lookup at
> the point of query, then store the answer back in the db for others to
> use later.
>
> That way we're efficient if nobody cares, and lose that efficiency
> when they do (but only for the devices they query), and subsequently
> efficient because the answer is cached.
>
> This veers a bit dangerously towards having apps that link with
> libudev process rules though?
>
> Scott
>
First thing coming to my mind: there's not enough pci/usb devices
present on the system for increasing the computational cost
significantly. Querying the vendor/model names will be performed only
one time, at udev running, and then only one time on "add" action for
this subsystems. Am i wrong?
Anyway, taking care about the efficiency, the Scott solutions sounds
good to me but implies development on udev directly. I'm writing some
apps using udev so, in the meantime, will be really nice if some more
questions could be answered:
Is it acceptable to add the mentioned udev rule for a system
application using udev? I mean, i.e. udisk add some rules for
importing some props. And for a desktop app? Is it acceptable too?
I think it's quite comfortable, for me as desktop app coder, to
delegate on udev the vendor/model name querying, more if we think udev
provides the cool pci-db and usb-db commands.
Cheers!
--
http://fontanon.org
^ permalink raw reply
* Re: PCI/USB Vendor and model from database
From: Scott James Remnant @ 2010-12-29 0:18 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <AANLkTi=1GzSurOXcFwBJUXfXBch24QB3cRh+0qo1a1Fp@mail.gmail.com>
2010/12/28 Lennart Poettering <lennart@poettering.net>:
> On Tue, 28.12.10 14:14, José Félix Ontañón (felixonta@gmail.com) wrote:
>
>> Hi, everybody!
>>
>> Maybe this is kinda silly question but, I wonder why isn't
>> "ID_VENDOR_FROM_DATABASE / ID_MODEL_FROM_DATABASE"-like properties
>> imported by default using the pretty /lib/udev/usb-db and
>> /lib/udev/pci-db commands for every founded pci/usb device?
>>
>> I mean, by adding this simple rules:
>>
>> SUBSYSTEMS="usb", IMPORT{program}="usb-db %p"
>> SUBSYSTEMS="pci", IMPORT{program}="pci-db %p"
>>
>> I think this properties are very useful for apps that discover
>> hardware through udev, so they will not have to reinvent the wheel by
>> finding vendor/product names by themselves. Don't you think?
>
> The database lookup is a linear search. As long as we invoke it only for
> a small subset of devices that doesn't really matter much. But if we
> start to look it up for every device we should probably spend the time
> to improve the db lookup first.
>
> It's simply a question of efficiency.
>
One thing that might be interesting is if we could do the lookup at
the point of query, then store the answer back in the db for others to
use later.
That way we're efficient if nobody cares, and lose that efficiency
when they do (but only for the devices they query), and subsequently
efficient because the answer is cached.
This veers a bit dangerously towards having apps that link with
libudev process rules though?
Scott
^ permalink raw reply
* Re: PCI/USB Vendor and model from database
From: Lennart Poettering @ 2010-12-28 23:58 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <AANLkTi=1GzSurOXcFwBJUXfXBch24QB3cRh+0qo1a1Fp@mail.gmail.com>
On Tue, 28.12.10 14:14, José Félix Ontañón (felixonta@gmail.com) wrote:
> Hi, everybody!
>
> Maybe this is kinda silly question but, I wonder why isn't
> "ID_VENDOR_FROM_DATABASE / ID_MODEL_FROM_DATABASE"-like properties
> imported by default using the pretty /lib/udev/usb-db and
> /lib/udev/pci-db commands for every founded pci/usb device?
>
> I mean, by adding this simple rules:
>
> SUBSYSTEMS="usb", IMPORT{program}="usb-db %p"
> SUBSYSTEMS="pci", IMPORT{program}="pci-db %p"
>
> I think this properties are very useful for apps that discover
> hardware through udev, so they will not have to reinvent the wheel by
> finding vendor/product names by themselves. Don't you think?
The database lookup is a linear search. As long as we invoke it only for
a small subset of devices that doesn't really matter much. But if we
start to look it up for every device we should probably spend the time
to improve the db lookup first.
It's simply a question of efficiency.
Lennart
--
Lennart Poettering - Red Hat, Inc.
^ permalink raw reply
* Re: PCI/USB Vendor and model from database
From: Greg KH @ 2010-12-28 18:45 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <AANLkTi=1GzSurOXcFwBJUXfXBch24QB3cRh+0qo1a1Fp@mail.gmail.com>
On Tue, Dec 28, 2010 at 02:14:38PM +0100, José Félix Ontañón wrote:
> Hi, everybody!
>
> Maybe this is kinda silly question but, I wonder why isn't
> "ID_VENDOR_FROM_DATABASE / ID_MODEL_FROM_DATABASE"-like properties
> imported by default using the pretty /lib/udev/usb-db and
> /lib/udev/pci-db commands for every founded pci/usb device?
>
> I mean, by adding this simple rules:
>
> SUBSYSTEMS="usb", IMPORT{program}="usb-db %p"
> SUBSYSTEMS="pci", IMPORT{program}="pci-db %p"
>
> I think this properties are very useful for apps that discover
> hardware through udev, so they will not have to reinvent the wheel by
> finding vendor/product names by themselves. Don't you think?
That would slow down every device being found, for no real user at this
time, right?
How hard is it to use libpci for the userspace program to find this
information, if it really needs it? That way, you also don't have to
have the database at early boot time, which keeps things simpler.
thanks,
greg k-h
^ permalink raw reply
* PCI/USB Vendor and model from database
From: José Félix Ontañón @ 2010-12-28 13:14 UTC (permalink / raw)
To: linux-hotplug
Hi, everybody!
Maybe this is kinda silly question but, I wonder why isn't
"ID_VENDOR_FROM_DATABASE / ID_MODEL_FROM_DATABASE"-like properties
imported by default using the pretty /lib/udev/usb-db and
/lib/udev/pci-db commands for every founded pci/usb device?
I mean, by adding this simple rules:
SUBSYSTEMS="usb", IMPORT{program}="usb-db %p"
SUBSYSTEMS="pci", IMPORT{program}="pci-db %p"
I think this properties are very useful for apps that discover
hardware through udev, so they will not have to reinvent the wheel by
finding vendor/product names by themselves. Don't you think?
Cheers!
--
http://fontanon.org
^ permalink raw reply
* Re: Udev rule $attr substitution
From: Kay Sievers @ 2010-12-26 14:59 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <4D10F63F.9030005@draisberghof.de>
On Wed, Dec 22, 2010 at 18:46, Kay Sievers <kay.sievers@vrfy.org> wrote:
> On Wed, Dec 22, 2010 at 18:40, Josua Dietze <digidietze@draisberghof.de> wrote:
>> Am 22.12.2010 16:58, schrieb Martin Pitt:
>>
>>> Josua Dietze [2010-12-22 12:42 +0100]:
>>>>
>>>> Maybe an "official" udev page consisting of the current man page and
>>>> two or three additional notes regarding changes in previously
>>>> available features would help. Or does it exist and I missed it?
>>>
>>> The one I quoted from is the official manpage, as it is released
>>> upstream in the last few versions (>= 162).
>>
>>
>> I was thinking of something that would come up if you google for "udev man
>> page" or "udev home"; this will hardly work for a XML file in a git tree ...
>>
>> But it's no big deal either; I mean, I found it eventually, right? Those who
>> really care will arrive there sooner or later.
>>
>> Thanks for your time!
>
> We sync (make doc-sync in the tree) the generated html from the libs
> the git tree to kernel.org for libudev and gudev:
> http://www.kernel.org/pub/linux/utils/kernel/hotplug/libudev/
> http://www.kernel.org/pub/linux/utils/kernel/hotplug/gudev/
> Should be easy to let xmlto create html pages for theman pages and
> sync them to:
> http://www.kernel.org/pub/linux/utils/kernel/hotplug/udev/
> at the same time.
It's here now:
http://www.kernel.org/pub/linux/utils/kernel/hotplug/udev/
Cheers,
Kay
^ permalink raw reply
* Re: [PATCH] Export ACPI _DSM provided firmware instance number and
From: Narendra_K @ 2010-12-23 19:24 UTC (permalink / raw)
To: Matt_Domsch
Cc: linux-pci, linux-hotplug, netdev, Jordan_Hargrave, Charles_Rose,
Vijay_Nijhawan
In-Reply-To: <20101223143203.GA12256@auslistsprd01.us.dell.com>
On Thu, Dec 23, 2010 at 08:02:03PM +0530, Domsch, Matt wrote:
> On Wed, Dec 22, 2010 at 08:42:39AM -0800, Narendra_K@Dell.com wrote:
> > Hello,
> >
> > This patch exports ACPI _DSM provided firmware instance number and
> > string name to sysfs.
> >
> > Please review -
>
> There are now two different meanings for the 'index' file:
>
> 1) SMBIOS-provided "type instance" value, which I've only seen in
> range [1..N] for N devices, monotonically stepwise increasing.
>
> 2) ACPI-provided "index" value, which per spec only needs to be a
> "sort key", not starting at 0 or 1, and while monotonically
> increasing, not necessarily stepwise. It's perfectly valid for the
> values to be (12, 16, 27, 29) if that's convenient for BIOS to
> generate.
>
> Therefore, a consumer of this value (such as biosdevname) must know
> which of the two it's dealing with, and either accept the value as-is,
> or sort the value list. While I suppose it could sort the value list
> in either case, I'd prefer the ACPI value to be exposed in its own
> file, perhaps 'acpi_index', to make this explicit rather than
> implicit.
>
> 'label' is fine for either case, with ACPI taking priority over
> SMBIOS if both happen to be present.
>
Matt,
Thanks for the suggestion. I agree.
Please find the version 2 of the patch.
V1 -> V2:
The attribute 'index' is changed to 'acpi_index' as the semantics of
SMBIOS provided device type instance and ACPI _DSM provided instance
number are different.
From: Narendra K <narendra_k@dell.com>
Subject: [PATCH V2] Export ACPI _DSM provided firmware instance number and string to sysfs
This patch exports ACPI _DSM (Device Specific Method) provided firmware
instance number and string name of PCI devices as defined by
'PCI Firmware Specification Revision 3.1' section 4.6.7.( DSM for Naming
a PCI or PCI Express Device Under Operating Systems) to sysfs.
New files created are:
/sys/bus/pci/devices/.../label which contains the firmware name for
the device in question, and
/sys/bus/pci/devices/.../acpi_index which contains the firmware device type
instance for the given device.
cat /sys/devices/pci0000:00/0000:00:01.0/0000:01:00.0/acpi_index
1
cat /sys/devices/pci0000:00/0000:00:01.0/0000:01:00.0/label
Embedded Broadcom 5709C NIC 1
cat /sys/devices/pci0000:00/0000:00:01.0/0000:01:00.1/acpi_index
2
cat /sys/devices/pci0000:00/0000:00:01.0/0000:01:00.1/label
Embedded Broadcom 5709C NIC 2
The ACPI _DSM provided firmware 'instance number' and 'string name' will
be given priority if the firmware also provides 'SMBIOS type 41 device
type instance and string'.
Signed-off-by: Jordan Hargrave <jordan_hargrave@dell.com>
Signed-off-by: Narendra K <narendra_k@dell.com>
---
Documentation/ABI/testing/sysfs-bus-pci | 31 +++-
drivers/pci/Makefile | 3 +-
drivers/pci/pci-label.c | 236 ++++++++++++++++++++++++++++++-
drivers/pci/pci.h | 2 +-
4 files changed, 260 insertions(+), 12 deletions(-)
diff --git a/Documentation/ABI/testing/sysfs-bus-pci b/Documentation/ABI/testing/sysfs-bus-pci
index f979d82..36bf454 100644
--- a/Documentation/ABI/testing/sysfs-bus-pci
+++ b/Documentation/ABI/testing/sysfs-bus-pci
@@ -145,9 +145,11 @@ Date: July 2010
Contact: Narendra K <narendra_k@dell.com>, linux-bugs@dell.com
Description:
Reading this attribute will provide the firmware
- given name(SMBIOS type 41 string) of the PCI device.
- The attribute will be created only if the firmware
- has given a name to the PCI device.
+ given name (SMBIOS type 41 string or ACPI _DSM string) of
+ the PCI device. The attribute will be created only
+ if the firmware has given a name to the PCI device.
+ ACPI _DSM string name will be given priority if the
+ system firmware provides SMBIOS type 41 string also.
Users:
Userspace applications interested in knowing the
firmware assigned name of the PCI device.
@@ -157,12 +159,27 @@ Date: July 2010
Contact: Narendra K <narendra_k@dell.com>, linux-bugs@dell.com
Description:
Reading this attribute will provide the firmware
- given instance(SMBIOS type 41 device type instance)
- of the PCI device. The attribute will be created
- only if the firmware has given a device type instance
- to the PCI device.
+ given instance (SMBIOS type 41 device type instance) of the
+ PCI device. The attribute will be created only if the firmware
+ has given an instance number to the PCI device.
Users:
Userspace applications interested in knowing the
firmware assigned device type instance of the PCI
device that can help in understanding the firmware
intended order of the PCI device.
+
+What: /sys/bus/pci/devices/.../acpi_index
+Date: July 2010
+Contact: Narendra K <narendra_k@dell.com>, linux-bugs@dell.com
+Description:
+ Reading this attribute will provide the firmware
+ given instance (ACPI _DSM instance number) of the PCI device.
+ The attribute will be created only if the firmware has given
+ an instance number to the PCI device. ACPI _DSM instance number
+ will be given priority if the system firmware provides SMBIOS
+ type 41 device type instance also.
+Users:
+ Userspace applications interested in knowing the
+ firmware assigned instance number of the PCI
+ device that can help in understanding the firmware
+ intended order of the PCI device.
diff --git a/drivers/pci/Makefile b/drivers/pci/Makefile
index 98e6fdf..bb1d3b2 100644
--- a/drivers/pci/Makefile
+++ b/drivers/pci/Makefile
@@ -53,8 +53,9 @@ obj-$(CONFIG_TILE) += setup-bus.o setup-irq.o
#
# ACPI Related PCI FW Functions
+# ACPI _DSM provided firmware instance and string name
#
-obj-$(CONFIG_ACPI) += pci-acpi.o
+obj-$(CONFIG_ACPI) += pci-acpi.o pci-label.o
# SMBIOS provided firmware instance and labels
obj-$(CONFIG_DMI) += pci-label.o
diff --git a/drivers/pci/pci-label.c b/drivers/pci/pci-label.c
index 90c0a72..d46693c 100644
--- a/drivers/pci/pci-label.c
+++ b/drivers/pci/pci-label.c
@@ -5,6 +5,13 @@
* by Narendra K <Narendra_K@dell.com>,
* Jordan Hargrave <Jordan_Hargrave@dell.com>
*
+ * PCI Firmware Specification Revision 3.1 section 4.6.7 (DSM for Naming a
+ * PCI or PCI Express Device Under Operating Systems) defines an instance
+ * number and string name. This code retrieves them and exports them to sysfs.
+ * If the system firmware does not provide the ACPI _DSM (Device Specific
+ * Method), then the SMBIOS type 41 instance number and string is exported to
+ * sysfs.
+ *
* 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.
@@ -19,8 +26,30 @@
#include <linux/pci_ids.h>
#include <linux/module.h>
#include <linux/device.h>
+#include <linux/nls.h>
+#include <linux/acpi.h>
+#include <linux/pci-acpi.h>
+#include <acpi/acpi_drivers.h>
+#include <acpi/acpi_bus.h>
#include "pci.h"
+#define DEVICE_LABEL_DSM 0x07
+
+#ifndef CONFIG_DMI
+
+static inline int
+pci_create_smbiosname_file(struct pci_dev *pdev)
+{
+ return -1;
+}
+
+static inline void
+pci_remove_smbiosname_file(struct pci_dev *pdev)
+{
+}
+
+#else
+
enum smbios_attr_enum {
SMBIOS_ATTR_NONE = 0,
SMBIOS_ATTR_LABEL_SHOW,
@@ -131,13 +160,214 @@ pci_remove_smbiosname_file(struct pci_dev *pdev)
sysfs_remove_group(&pdev->dev.kobj, &smbios_attr_group);
}
+#endif
+
+#ifndef CONFIG_ACPI
+
+static inline int
+pci_create_acpi_index_label_files(struct pci_dev *pdev)
+{
+ return -1;
+}
+
+static inline int
+pci_remove_acpi_index_label_files(struct pci_dev *pdev)
+{
+ return -1;
+}
+
+#else
+
+static const char device_label_dsm_uuid[] = {
+ 0xD0, 0x37, 0xC9, 0xE5, 0x53, 0x35, 0x7A, 0x4D,
+ 0x91, 0x17, 0xEA, 0x4D, 0x19, 0xC3, 0x43, 0x4D
+};
+
+enum acpi_attr_enum {
+ ACPI_ATTR_NONE = 0,
+ ACPI_ATTR_LABEL_SHOW,
+ ACPI_ATTR_INDEX_SHOW,
+};
+
+static int dsm_label_utf16s_to_utf8s(union acpi_object *obj, char *buf)
+{
+ int err;
+ err = utf16s_to_utf8s((const wchar_t *)obj->
+ package.elements[1].string.pointer,
+ obj->package.elements[1].string.length,
+ UTF16_LITTLE_ENDIAN,
+ buf, PAGE_SIZE);
+ buf[err] = '\n';
+ return err;
+}
+
+static int
+dsm_get_label(acpi_handle handle, int func,
+ struct acpi_buffer *output,
+ char *buf, enum acpi_attr_enum 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(device_label_dsm_uuid);
+ params[0].buffer.pointer = (char *)device_label_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)
+ return -1;
+
+ obj = (union acpi_object *)output->pointer;
+
+ switch (obj->type) {
+ case ACPI_TYPE_PACKAGE:
+ if (obj->package.count != 2)
+ break;
+ len = obj->package.elements[0].integer.value;
+ if (buf) {
+ if (attribute = ACPI_ATTR_INDEX_SHOW)
+ scnprintf(buf, PAGE_SIZE, "%llu\n",
+ obj->package.elements[0].integer.value);
+ else if (attribute = ACPI_ATTR_LABEL_SHOW) {
+ if (dsm_label_utf16s_to_utf8s(obj, buf) < 0)
+ return -1;
+ }
+ kfree(output->pointer);
+ return strlen(buf);
+ }
+ kfree(output->pointer);
+ return len;
+ break;
+ default:
+ kfree(output->pointer);
+ }
+ return -1;
+}
+
+static mode_t
+acpi_index_string_exist(struct kobject *kobj, struct attribute *attr, int n)
+{
+ struct device *dev;
+ struct acpi_buffer output = {ACPI_ALLOCATE_BUFFER, NULL};
+ acpi_handle handle;
+ int length;
+
+ dev = container_of(kobj, struct device, kobj);
+ handle = DEVICE_ACPI_HANDLE(dev);
+
+ if (!handle)
+ return 0;
+
+ length = dsm_get_label(handle, DEVICE_LABEL_DSM,
+ &output, NULL, ACPI_ATTR_NONE);
+
+ return (length > 0) ? S_IRUGO : 0;
+}
+
+static ssize_t
+acpilabel_show(struct device *dev, struct device_attribute *attr, char *buf)
+{
+ struct acpi_buffer output = {ACPI_ALLOCATE_BUFFER, NULL};
+ acpi_handle handle;
+ int length;
+
+ handle = DEVICE_ACPI_HANDLE(dev);
+
+ if (!handle)
+ return -1;
+
+ length = dsm_get_label(handle, DEVICE_LABEL_DSM,
+ &output, buf, ACPI_ATTR_LABEL_SHOW);
+
+ if (length < 1)
+ return -1;
+
+ return length;
+}
+
+static ssize_t
+acpiindex_show(struct device *dev, struct device_attribute *attr, char *buf)
+{
+ struct acpi_buffer output = {ACPI_ALLOCATE_BUFFER, NULL};
+ acpi_handle handle;
+ int length;
+
+ handle = DEVICE_ACPI_HANDLE(dev);
+
+ if (!handle)
+ return -1;
+
+ length = dsm_get_label(handle, DEVICE_LABEL_DSM,
+ &output, buf, ACPI_ATTR_INDEX_SHOW);
+
+ if (length < 0)
+ return -1;
+
+ return length;
+
+}
+
+static struct device_attribute acpi_attr_label = {
+ .attr = {.name = "label", .mode = 0444},
+ .show = acpilabel_show,
+};
+
+static struct device_attribute acpi_attr_index = {
+ .attr = {.name = "acpi_index", .mode = 0444},
+ .show = acpiindex_show,
+};
+
+static struct attribute *acpi_attributes[] = {
+ &acpi_attr_label.attr,
+ &acpi_attr_index.attr,
+ NULL,
+};
+
+static struct attribute_group acpi_attr_group = {
+ .attrs = acpi_attributes,
+ .is_visible = acpi_index_string_exist,
+};
+
+static int
+pci_create_acpi_index_label_files(struct pci_dev *pdev)
+{
+ if (!sysfs_create_group(&pdev->dev.kobj, &acpi_attr_group))
+ return 0;
+ return -ENODEV;
+}
+
+static int
+pci_remove_acpi_index_label_files(struct pci_dev *pdev)
+{
+ sysfs_remove_group(&pdev->dev.kobj, &acpi_attr_group);
+ return 0;
+}
+#endif
+
void pci_create_firmware_label_files(struct pci_dev *pdev)
{
- if (!pci_create_smbiosname_file(pdev))
- ;
+ if (!pci_create_acpi_index_label_files(pdev))
+ return;
+ pci_create_smbiosname_file(pdev);
}
void pci_remove_firmware_label_files(struct pci_dev *pdev)
{
- pci_remove_smbiosname_file(pdev);
+ if (!pci_remove_acpi_index_label_files(pdev))
+ return;
+ else
+ pci_remove_smbiosname_file(pdev);
}
diff --git a/drivers/pci/pci.h b/drivers/pci/pci.h
index 7d33f66..d0d0bd4 100644
--- a/drivers/pci/pci.h
+++ b/drivers/pci/pci.h
@@ -11,7 +11,7 @@
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
+#if !defined(CONFIG_DMI) && !defined(CONFIG_ACPI)
static inline void pci_create_firmware_label_files(struct pci_dev *pdev)
{ return; }
static inline void pci_remove_firmware_label_files(struct pci_dev *pdev)
--
1.7.3.1
With regards,
Narendra K
^ permalink raw reply related
* Re: [PATCH] Export ACPI _DSM provided firmware instance number and string name to sysfs
From: Matt Domsch @ 2010-12-23 14:32 UTC (permalink / raw)
To: Narendra_K
Cc: linux-pci, linux-hotplug, netdev, Jordan_Hargrave, Charles_Rose,
Vijay_Nijhawan
In-Reply-To: <20101222170737.GA2428@fedora14-r610.oslab.blr.amer.dell.com>
On Wed, Dec 22, 2010 at 08:42:39AM -0800, Narendra_K@Dell.com wrote:
> Hello,
>
> This patch exports ACPI _DSM provided firmware instance number and
> string name to sysfs.
>
> Please review -
There are now two different meanings for the 'index' file:
1) SMBIOS-provided "type instance" value, which I've only seen in
range [1..N] for N devices, monotonically stepwise increasing.
2) ACPI-provided "index" value, which per spec only needs to be a
"sort key", not starting at 0 or 1, and while monotonically
increasing, not necessarily stepwise. It's perfectly valid for the
values to be (12, 16, 27, 29) if that's convenient for BIOS to
generate.
Therefore, a consumer of this value (such as biosdevname) must know
which of the two it's dealing with, and either accept the value as-is,
or sort the value list. While I suppose it could sort the value list
in either case, I'd prefer the ACPI value to be exposed in its own
file, perhaps 'acpi_index', to make this explicit rather than
implicit.
'label' is fine for either case, with ACPI taking priority over
SMBIOS if both happen to be present.
Thanks,
Matt
--
Matt Domsch
Technology Strategist
Dell | Office of the CTO
^ permalink raw reply
* Re: Udev rule $attr substitution
From: Kay Sievers @ 2010-12-22 17:46 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <4D10F63F.9030005@draisberghof.de>
On Wed, Dec 22, 2010 at 18:40, Josua Dietze <digidietze@draisberghof.de> wrote:
> Am 22.12.2010 16:58, schrieb Martin Pitt:
>
>> Josua Dietze [2010-12-22 12:42 +0100]:
>>>
>>> Maybe an "official" udev page consisting of the current man page and
>>> two or three additional notes regarding changes in previously
>>> available features would help. Or does it exist and I missed it?
>>
>> The one I quoted from is the official manpage, as it is released
>> upstream in the last few versions (>= 162).
>
>
> I was thinking of something that would come up if you google for "udev man
> page" or "udev home"; this will hardly work for a XML file in a git tree ...
>
> But it's no big deal either; I mean, I found it eventually, right? Those who
> really care will arrive there sooner or later.
>
> Thanks for your time!
We sync (make doc-sync in the tree) the generated html from the libs
the git tree to kernel.org for libudev and gudev:
http://www.kernel.org/pub/linux/utils/kernel/hotplug/libudev/
http://www.kernel.org/pub/linux/utils/kernel/hotplug/gudev/
Should be easy to let xmlto create html pages for theman pages and
sync them to:
http://www.kernel.org/pub/linux/utils/kernel/hotplug/udev/
at the same time.
Kay
^ permalink raw reply
* Re: Udev rule $attr substitution
From: Josua Dietze @ 2010-12-22 17:40 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <4D10F63F.9030005@draisberghof.de>
Am 22.12.2010 16:58, schrieb Martin Pitt:
> Josua Dietze [2010-12-22 12:42 +0100]:
>> Maybe an "official" udev page consisting of the current man page and
>> two or three additional notes regarding changes in previously
>> available features would help. Or does it exist and I missed it?
>
> The one I quoted from is the official manpage, as it is released
> upstream in the last few versions (>= 162).
I was thinking of something that would come up if you google for "udev man page"
or "udev home"; this will hardly work for a XML file in a git tree ...
But it's no big deal either; I mean, I found it eventually, right? Those who
really care will arrive there sooner or later.
Thanks for your time!
Josua Dietze
^ permalink raw reply
* [PATCH] Export ACPI _DSM provided firmware instance number and
From: Narendra_K @ 2010-12-22 16:42 UTC (permalink / raw)
To: linux-pci, linux-hotplug
Cc: netdev, Matt_Domsch, Jordan_Hargrave, Charles_Rose,
Vijay_Nijhawan
Hello,
This patch exports ACPI _DSM provided firmware instance number and
string name to sysfs.
Please review -
From: Narendra K <narendra_k@dell.com>
Subject: [PATCH] Export ACPI _DSM provided firmware instance number and string to sysfs
This patch exports ACPI _DSM (Device Specific Method) provided firmware
instance number and string name of PCI devices as defined by
'PCI Firmware Specification Revision 3.1' section 4.6.7.( DSM for Naming
a PCI or PCI Express Device Under Operating Systems) to sysfs.
New files created are:
/sys/bus/pci/devices/.../label which contains the firmware name for
the device in question, and
/sys/bus/pci/devices/.../index which contains the firmware device type
instance for the given device.
cat /sys/devices/pci0000:00/0000:00:01.0/0000:01:00.0/index
1
cat /sys/devices/pci0000:00/0000:00:01.0/0000:01:00.0/label
Embedded Broadcom 5709C NIC 1
cat /sys/devices/pci0000:00/0000:00:01.0/0000:01:00.1/index
2
cat /sys/devices/pci0000:00/0000:00:01.0/0000:01:00.1/label
Embedded Broadcom 5709C NIC 2
Signed-off-by: Jordan Hargrave <jordan_hargrave@dell.com>
Signed-off-by: Narendra K <narendra_k@dell.com>
---
Documentation/ABI/testing/sysfs-bus-pci | 14 +-
drivers/pci/Makefile | 3 +-
drivers/pci/pci-label.c | 236 ++++++++++++++++++++++++++++++-
drivers/pci/pci.h | 2 +-
4 files changed, 243 insertions(+), 12 deletions(-)
diff --git a/Documentation/ABI/testing/sysfs-bus-pci b/Documentation/ABI/testing/sysfs-bus-pci
index f979d82..7e90ef1 100644
--- a/Documentation/ABI/testing/sysfs-bus-pci
+++ b/Documentation/ABI/testing/sysfs-bus-pci
@@ -145,9 +145,9 @@ Date: July 2010
Contact: Narendra K <narendra_k@dell.com>, linux-bugs@dell.com
Description:
Reading this attribute will provide the firmware
- given name(SMBIOS type 41 string) of the PCI device.
- The attribute will be created only if the firmware
- has given a name to the PCI device.
+ given name (SMBIOS type 41 string or ACPI _DSM string) of
+ the PCI device. The attribute will be created only
+ if the firmware has given a name to the PCI device.
Users:
Userspace applications interested in knowing the
firmware assigned name of the PCI device.
@@ -157,10 +157,10 @@ Date: July 2010
Contact: Narendra K <narendra_k@dell.com>, linux-bugs@dell.com
Description:
Reading this attribute will provide the firmware
- given instance(SMBIOS type 41 device type instance)
- of the PCI device. The attribute will be created
- only if the firmware has given a device type instance
- to the PCI device.
+ given instance (SMBIOS type 41 device type instance
+ or ACPI _DSM instance number) of the PCI device. The attribute
+ will be created only if the firmware has given an instance
+ number to the PCI device.
Users:
Userspace applications interested in knowing the
firmware assigned device type instance of the PCI
diff --git a/drivers/pci/Makefile b/drivers/pci/Makefile
index 98e6fdf..bb1d3b2 100644
--- a/drivers/pci/Makefile
+++ b/drivers/pci/Makefile
@@ -53,8 +53,9 @@ obj-$(CONFIG_TILE) += setup-bus.o setup-irq.o
#
# ACPI Related PCI FW Functions
+# ACPI _DSM provided firmware instance and string name
#
-obj-$(CONFIG_ACPI) += pci-acpi.o
+obj-$(CONFIG_ACPI) += pci-acpi.o pci-label.o
# SMBIOS provided firmware instance and labels
obj-$(CONFIG_DMI) += pci-label.o
diff --git a/drivers/pci/pci-label.c b/drivers/pci/pci-label.c
index 90c0a72..08b1ec5 100644
--- a/drivers/pci/pci-label.c
+++ b/drivers/pci/pci-label.c
@@ -5,6 +5,13 @@
* by Narendra K <Narendra_K@dell.com>,
* Jordan Hargrave <Jordan_Hargrave@dell.com>
*
+ * PCI Firmware Specification Revision 3.1 section 4.6.7 (DSM for Naming a
+ * PCI or PCI Express Device Under Operating Systems) defines an instance
+ * number and string name. This code retrieves them and exports them to sysfs.
+ * If the system firmware does not provide the ACPI _DSM (Device Specific
+ * Method), then the SMBIOS type 41 instance number and string is exported to
+ * sysfs.
+ *
* 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.
@@ -19,8 +26,30 @@
#include <linux/pci_ids.h>
#include <linux/module.h>
#include <linux/device.h>
+#include <linux/nls.h>
+#include <linux/acpi.h>
+#include <linux/pci-acpi.h>
+#include <acpi/acpi_drivers.h>
+#include <acpi/acpi_bus.h>
#include "pci.h"
+#define DEVICE_LABEL_DSM 0x07
+
+#ifndef CONFIG_DMI
+
+static inline int
+pci_create_smbiosname_file(struct pci_dev *pdev)
+{
+ return -1;
+}
+
+static inline void
+pci_remove_smbiosname_file(struct pci_dev *pdev)
+{
+}
+
+#else
+
enum smbios_attr_enum {
SMBIOS_ATTR_NONE = 0,
SMBIOS_ATTR_LABEL_SHOW,
@@ -131,13 +160,214 @@ pci_remove_smbiosname_file(struct pci_dev *pdev)
sysfs_remove_group(&pdev->dev.kobj, &smbios_attr_group);
}
+#endif
+
+#ifndef CONFIG_ACPI
+
+static inline int
+pci_create_acpi_index_label_files(struct pci_dev *pdev)
+{
+ return -1;
+}
+
+static inline int
+pci_remove_acpi_index_label_files(struct pci_dev *pdev)
+{
+ return -1;
+}
+
+#else
+
+static const char device_label_dsm_uuid[] = {
+ 0xD0, 0x37, 0xC9, 0xE5, 0x53, 0x35, 0x7A, 0x4D,
+ 0x91, 0x17, 0xEA, 0x4D, 0x19, 0xC3, 0x43, 0x4D
+};
+
+enum acpi_attr_enum {
+ ACPI_ATTR_NONE = 0,
+ ACPI_ATTR_LABEL_SHOW,
+ ACPI_ATTR_INDEX_SHOW,
+};
+
+static int dsm_label_utf16s_to_utf8s(union acpi_object *obj, char *buf)
+{
+ int err;
+ err = utf16s_to_utf8s((const wchar_t *)obj->
+ package.elements[1].string.pointer,
+ obj->package.elements[1].string.length,
+ UTF16_LITTLE_ENDIAN,
+ buf, PAGE_SIZE);
+ buf[err] = '\n';
+ return err;
+}
+
+static int
+dsm_get_label(acpi_handle handle, int func,
+ struct acpi_buffer *output,
+ char *buf, enum acpi_attr_enum 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(device_label_dsm_uuid);
+ params[0].buffer.pointer = (char *)device_label_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)
+ return -1;
+
+ obj = (union acpi_object *)output->pointer;
+
+ switch (obj->type) {
+ case ACPI_TYPE_PACKAGE:
+ if (obj->package.count != 2)
+ break;
+ len = obj->package.elements[0].integer.value;
+ if (buf) {
+ if (attribute = ACPI_ATTR_INDEX_SHOW)
+ scnprintf(buf, PAGE_SIZE, "%llu\n",
+ obj->package.elements[0].integer.value);
+ else if (attribute = ACPI_ATTR_LABEL_SHOW) {
+ if (dsm_label_utf16s_to_utf8s(obj, buf) < 0)
+ return -1;
+ }
+ kfree(output->pointer);
+ return strlen(buf);
+ }
+ kfree(output->pointer);
+ return len;
+ break;
+ default:
+ kfree(output->pointer);
+ }
+ return -1;
+}
+
+static mode_t
+acpi_index_string_exist(struct kobject *kobj, struct attribute *attr, int n)
+{
+ struct device *dev;
+ struct acpi_buffer output = {ACPI_ALLOCATE_BUFFER, NULL};
+ acpi_handle handle;
+ int length;
+
+ dev = container_of(kobj, struct device, kobj);
+ handle = DEVICE_ACPI_HANDLE(dev);
+
+ if (!handle)
+ return 0;
+
+ length = dsm_get_label(handle, DEVICE_LABEL_DSM,
+ &output, NULL, ACPI_ATTR_NONE);
+
+ return (length > 0) ? S_IRUGO : 0;
+}
+
+static ssize_t
+acpilabel_show(struct device *dev, struct device_attribute *attr, char *buf)
+{
+ struct acpi_buffer output = {ACPI_ALLOCATE_BUFFER, NULL};
+ acpi_handle handle;
+ int length;
+
+ handle = DEVICE_ACPI_HANDLE(dev);
+
+ if (!handle)
+ return -1;
+
+ length = dsm_get_label(handle, DEVICE_LABEL_DSM,
+ &output, buf, ACPI_ATTR_LABEL_SHOW);
+
+ if (length < 1)
+ return -1;
+
+ return length;
+}
+
+static ssize_t
+acpiindex_show(struct device *dev, struct device_attribute *attr, char *buf)
+{
+ struct acpi_buffer output = {ACPI_ALLOCATE_BUFFER, NULL};
+ acpi_handle handle;
+ int length;
+
+ handle = DEVICE_ACPI_HANDLE(dev);
+
+ if (!handle)
+ return -1;
+
+ length = dsm_get_label(handle, DEVICE_LABEL_DSM,
+ &output, buf, ACPI_ATTR_INDEX_SHOW);
+
+ if (length < 0)
+ return -1;
+
+ return length;
+
+}
+
+static struct device_attribute acpi_attr_label = {
+ .attr = {.name = "label", .mode = 0444},
+ .show = acpilabel_show,
+};
+
+static struct device_attribute acpi_attr_index = {
+ .attr = {.name = "index", .mode = 0444},
+ .show = acpiindex_show,
+};
+
+static struct attribute *acpi_attributes[] = {
+ &acpi_attr_label.attr,
+ &acpi_attr_index.attr,
+ NULL,
+};
+
+static struct attribute_group acpi_attr_group = {
+ .attrs = acpi_attributes,
+ .is_visible = acpi_index_string_exist,
+};
+
+static int
+pci_create_acpi_index_label_files(struct pci_dev *pdev)
+{
+ if (!sysfs_create_group(&pdev->dev.kobj, &acpi_attr_group))
+ return 0;
+ return -ENODEV;
+}
+
+static int
+pci_remove_acpi_index_label_files(struct pci_dev *pdev)
+{
+ sysfs_remove_group(&pdev->dev.kobj, &acpi_attr_group);
+ return 0;
+}
+#endif
+
void pci_create_firmware_label_files(struct pci_dev *pdev)
{
- if (!pci_create_smbiosname_file(pdev))
- ;
+ if (!pci_create_acpi_index_label_files(pdev))
+ return;
+ pci_create_smbiosname_file(pdev);
}
void pci_remove_firmware_label_files(struct pci_dev *pdev)
{
- pci_remove_smbiosname_file(pdev);
+ if (!pci_remove_acpi_index_label_files(pdev))
+ return;
+ else
+ pci_remove_smbiosname_file(pdev);
}
diff --git a/drivers/pci/pci.h b/drivers/pci/pci.h
index 7d33f66..d0d0bd4 100644
--- a/drivers/pci/pci.h
+++ b/drivers/pci/pci.h
@@ -11,7 +11,7 @@
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
+#if !defined(CONFIG_DMI) && !defined(CONFIG_ACPI)
static inline void pci_create_firmware_label_files(struct pci_dev *pdev)
{ return; }
static inline void pci_remove_firmware_label_files(struct pci_dev *pdev)
--
1.7.3.1
With regards,
Narendra K
^ permalink raw reply related
* Re: Udev rule $attr substitution
From: Martin Pitt @ 2010-12-22 15:58 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <4D10F63F.9030005@draisberghof.de>
Hello Josua,
Josua Dietze [2010-12-22 12:42 +0100]:
> What's a bit unfortunate though is the discrepancy between man pages
> and functionality of versions before the man page correction.
That's right, there was a time when the manpage was still wrong. The
manpage was fixed in August:
http://git.kernel.org/?p=linux/hotplug/udev.git;a=commitdiff;hƒ184d008ba2
> Maybe an "official" udev page consisting of the current man page and
> two or three additional notes regarding changes in previously
> available features would help. Or does it exist and I missed it?
The one I quoted from is the official manpage, as it is released
upstream in the last few versions (>= 162).
Martin
--
Martin Pitt | http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)
^ permalink raw reply
* Re: Udev rule $attr substitution
From: Josua Dietze @ 2010-12-22 11:35 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <4D10F63F.9030005@draisberghof.de>
Am 22.12.2010 09:51, schrieb Martin Pitt:
>> But I might add that there is certainly some documentation lacking
>> on this one, practially everything I found was outdated or
>> inaccurate ...
>
> This is indeed a common trap, so some time ago I tried to point this
> out more clearly in the manpage:
>
> $attr{file}, %s{file}
> The value of a sysfs attribute found at the device, where all keys
> of the rule have matched. If the matching device does not have such
> an attribute, and a previous KERNELS, SUBSYSTEMS, DRIVERS, or ATTRS
> test selected a parent device, use the attribute from that parent
> device.
>
> This tries to point out that this won't match attributes from any
> parent device. Do you think this paragraph is unclear? If so, do you
> have a suggestion how to improve it? Or did you not see it in the
> first place?
The entry in the current man page is fine.
I was broadly referring to the documentation floating around in the
Web, examples, howtos and forum discussions. Nothing of your
responsibility, really.
What's a bit unfortunate though is the discrepancy between man pages
and functionality of versions before the man page correction.
OpenSUSE 11.3 ships with v. 157 which claims to do the upward chain
search for $attr but doesn't.
Maybe an "official" udev page consisting of the current man page and
two or three additional notes regarding changes in previously
available features would help. Or does it exist and I missed it?
Just my 2c,
Josua Dietze
^ permalink raw reply
* Re: Udev rule $attr substitution
From: Martin Pitt @ 2010-12-22 8:51 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <4D10F63F.9030005@draisberghof.de>
Hello Josua,
Josua Dietze [2010-12-21 21:25 +0100]:
> I found the man page (well, xml file) in the git tree and just added
> an ATTRS match to the top level USB device.
>
> This worked:
> KERNEL="ttyUSB*", ATTRS{bNumConfigurations}="*", RUN+="myprog %p
> %s{idVendor} %s{idProduct}"
Right, you need to "select" the parent device of which you need the
id* attribute.
> But I might add that there is certainly some documentation lacking
> on this one, practially everything I found was outdated or
> inaccurate ...
This is indeed a common trap, so some time ago I tried to point this
out more clearly in the manpage:
$attr{file}, %s{file}
The value of a sysfs attribute found at the device, where all keys
of the rule have matched. If the matching device does not have such
an attribute, and a previous KERNELS, SUBSYSTEMS, DRIVERS, or ATTRS
test selected a parent device, use the attribute from that parent
device.
This tries to point out that this won't match attributes from any
parent device. Do you think this paragraph is unclear? If so, do you
have a suggestion how to improve it? Or did you not see it in the
first place?
Thank you,
Martin
--
Martin Pitt | http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)
^ permalink raw reply
* Re: Udev rule $attr substitution
From: Josua Dietze @ 2010-12-21 20:25 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <4D10F63F.9030005@draisberghof.de>
Never mind, I figured it out.
It was all a problem of not-quite-accurate man pages.
I found the man page (well, xml file) in the git tree and just added an ATTRS
match to the top level USB device.
This worked:
KERNEL="ttyUSB*", ATTRS{bNumConfigurations}="*", RUN+="myprog %p %s{idVendor}
%s{idProduct}"
Sorry for the noise, thanks anyway.
But I might add that there is certainly some documentation lacking on this one,
practially everything I found was outdated or inaccurate ...
Josua Dietze
^ permalink raw reply
* Udev rule $attr substitution
From: Josua Dietze @ 2010-12-21 18:47 UTC (permalink / raw)
To: linux-hotplug
Hi, everyone!
I'm scratching my head over this:
Rule line:
KERNEL="ttyUSB*" RUN+="myprog %p %s{idVendor} %s{idProduct}"
%p expands to something like:
/devices/pci0000:00/0000:00:1d.7/usb1/1-5/1-5:1.2/ttyUSB2/tty/ttyUSB2
But the %s (or $attr) format string will not be substituted with anything when
using udev version 157. The same rule works fine with version 125.
When doing the attribute walk with "udevadm info", the attributes are of course
found in the parent chain.
Did I miss something?
^ 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