* Re: udev cdrom_id rules prevent unmounted CD from spinning down
From: Kay Sievers @ 2010-05-18 17:53 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <20100513153043.GA3966@elliptictech.com>
On Tue, May 18, 2010 at 18:23, Nick Bowler <nbowler@elliptictech.com> wrote:
> On 16:21 Tue 18 May , Kay Sievers wrote:
>> On Tue, May 18, 2010 at 15:25, Nick Bowler <nbowler@elliptictech.com> wrote:
>> > On 07:08 Tue 18 May , Kay Sievers wrote:
>> >> What does:
>> >> cat /sys/class/block/sr0/../../evt_media_change
>> >> print for this device?
>> >
>> > Prints 1.
>>
>> Oh, seems to be an AN capable device, which actually really sends events. :)
>>
>> I don't know if that works, never tried, but if you chmod the
>> evt_media_change file to 0664. and write 0 to it, does it still behave
>> the same?
>
> I can successfully chmod and write 0 to that file, and it reads back as
> 0, but the behaviour remains the same (the blkid rules are uncommented),
> and the disk never spins down.
Ok, as said, it was just a try. Thanks for the test.
The kernel seems not to filter events based on that mask. So a fix for
this would be in the kernel, to either provide information about the
source of the event, or to be able to suppress these AN event, which
have no obvious meaning.
Tejun,
an AN capable SATA optical drive seems to send AN events with every
open(). For userspace these look the same as the media changed events,
and cause a loop when udev checks if there is a new media. Any ideas
if these AN events are expected, or useful for anything?
David,
this is stuff we might need to cover with udisks in the future to
handle AN properly.
Thanks,
Kay
^ permalink raw reply
* Re: udev cdrom_id rules prevent unmounted CD from spinning down
From: Tejun Heo @ 2010-05-18 18:14 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <20100513153043.GA3966@elliptictech.com>
Hello,
On 05/18/2010 07:53 PM, Kay Sievers wrote:
> Tejun,
> an AN capable SATA optical drive seems to send AN events with every
> open(). For userspace these look the same as the media changed events,
> and cause a loop when udev checks if there is a new media. Any ideas
> if these AN events are expected, or useful for anything?
The open() path issues several commands and it could be that the drive
is raising AN when certain conditions are met just in case. After all
windows only uses single command for media presence polling, so
there's nothing stopping vendors from using TUR, for example, as the
level triggered check point to see whether media is available and
raise AN if so. After all, that wouldn't lose any event and in case
the internal state went out of sync, it would work as an easy resync
point.
Long term, I think the only solution is to do what windows does for
media presence polling; otherwise, we'll keep running into various
obscure issues. For short term, I dunno. Don't use AN for the time
being? :-)
Thanks.
--
tejun
^ permalink raw reply
* Re: udev cdrom_id rules prevent unmounted CD from spinning down
From: Kay Sievers @ 2010-05-18 18:20 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <20100513153043.GA3966@elliptictech.com>
On Tue, May 18, 2010 at 20:14, Tejun Heo <tj@kernel.org> wrote:
> On 05/18/2010 07:53 PM, Kay Sievers wrote:
>> Tejun,
>> an AN capable SATA optical drive seems to send AN events with every
>> open(). For userspace these look the same as the media changed events,
>> and cause a loop when udev checks if there is a new media. Any ideas
>> if these AN events are expected, or useful for anything?
>
> The open() path issues several commands and it could be that the drive
> is raising AN when certain conditions are met just in case. After all
> windows only uses single command for media presence polling, so
> there's nothing stopping vendors from using TUR, for example, as the
> level triggered check point to see whether media is available and
> raise AN if so. After all, that wouldn't lose any event and in case
> the internal state went out of sync, it would work as an easy resync
> point.
>
> Long term, I think the only solution is to do what windows does for
> media presence polling; otherwise, we'll keep running into various
> obscure issues. For short term, I dunno. Don't use AN for the time
> being? :-)
Yeah, the problem is that we already have the problem with current
software that causes the event loop. And we need a solution now. :)
We might need to switch the AN stuff off by default in the kernel, and
only enable it when we know we are able to handle it?
Kay
^ permalink raw reply
* Re: udev cdrom_id rules prevent unmounted CD from spinning down
From: Tejun Heo @ 2010-05-18 18:28 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <20100513153043.GA3966@elliptictech.com>
Hello,
On 05/18/2010 08:20 PM, Kay Sievers wrote:
> Yeah, the problem is that we already have the problem with current
> software that causes the event loop. And we need a solution now. :)
>
> We might need to switch the AN stuff off by default in the kernel, and
> only enable it when we know we are able to handle it?
Yeah, somehow ignoring those events was what I suggested. I thought
maybe it can be done in userland? Currently there is no switch on the
driver side. If the feature is there and the host supports it, it's
automatically enabled. Hmmm... When we have proper in kernel media
presence polling, AN should be piped through there anyway so it makes
sense to prevent it from reaching userland directly now. How does
that sound?
Thanks.
--
tejun
^ permalink raw reply
* Re: udev cdrom_id rules prevent unmounted CD from spinning down
From: Kay Sievers @ 2010-05-18 18:53 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <20100513153043.GA3966@elliptictech.com>
On Tue, May 18, 2010 at 20:28, Tejun Heo <tj@kernel.org> wrote:
> On 05/18/2010 08:20 PM, Kay Sievers wrote:
>> Yeah, the problem is that we already have the problem with current
>> software that causes the event loop. And we need a solution now. :)
>>
>> We might need to switch the AN stuff off by default in the kernel, and
>> only enable it when we know we are able to handle it?
>
> Yeah, somehow ignoring those events was what I suggested. I thought
> maybe it can be done in userland?
It doesn't look like we can do that. But while thinking about that:
Nick, if you run:
udevadm monitor --property
and access the device that it generates an event. does it always
contain the line:
SDEV_MEDIA_CHANGE=1
?
That would surely be incorrect to send from the kernel, if it isn't a
media change. And we might check if we can suppress these.
> Currently there is no switch on the
> driver side. If the feature is there and the host supports it, it's
> automatically enabled. Hmmm... When we have proper in kernel media
> presence polling, AN should be piped through there anyway so it makes
> sense to prevent it from reaching userland directly now. How does
> that sound?
Yeah, that sounds great. It would be just nice to have something now,
so we can fix the current issues. The in-kernel polling might need
some time still. :)
Kay
^ permalink raw reply
* Re: udev cdrom_id rules prevent unmounted CD from spinning down
From: Nick Bowler @ 2010-05-18 19:23 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <20100513153043.GA3966@elliptictech.com>
On 20:53 Tue 18 May , Kay Sievers wrote:
> Nick, if you run:
> udevadm monitor --property
> and access the device that it generates an event. does it always
> contain the line:
> SDEV_MEDIA_CHANGE=1
> ?
> That would surely be incorrect to send from the kernel, if it isn't a
> media change. And we might check if we can suppress these.
I ran the earlier blkid test with the drive idle, and yes,
SDEV_MEDIA_CHANGE=1 appears 6 times in the output.
--
Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/)
^ permalink raw reply
* Re: udev cdrom_id rules prevent unmounted CD from spinning down
From: Kay Sievers @ 2010-05-18 20:18 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <20100513153043.GA3966@elliptictech.com>
On Tue, May 18, 2010 at 21:23, Nick Bowler <nbowler@elliptictech.com> wrote:
> On 20:53 Tue 18 May , Kay Sievers wrote:
>> Nick, if you run:
>> udevadm monitor --property
>> and access the device that it generates an event. does it always
>> contain the line:
>> SDEV_MEDIA_CHANGE=1
>> ?
>> That would surely be incorrect to send from the kernel, if it isn't a
>> media change. And we might check if we can suppress these.
>
> I ran the earlier blkid test with the drive idle, and yes,
> SDEV_MEDIA_CHANGE=1 appears 6 times in the output.
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?
Thanks,
Kay
^ permalink raw reply
* Re: udev cdrom_id rules prevent unmounted CD from spinning down
From: Tejun Heo @ 2010-05-19 13:23 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <20100513153043.GA3966@elliptictech.com>
(cc'ing linux-ide and Jeff)
Hello,
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.
Thanks.
--
tejun
^ permalink raw reply
* [PATCH #upstream-fixes] libata: disable ATAPI AN by default
From: Tejun Heo @ 2010-05-19 13:38 UTC (permalink / raw)
To: Jeff Garzik, linux-ide@vger.kernel.org
Cc: Kay Sievers, Nick Bowler, David Zeuthen, linux-hotplug, stable
In-Reply-To: <4BF3E64D.2040003@kernel.org>
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(-)
diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c
index 49cffb6..5abab5d 100644
--- a/drivers/ata/libata-core.c
+++ b/drivers/ata/libata-core.c
@@ -160,6 +160,10 @@ int libata_allow_tpm = 0;
module_param_named(allow_tpm, libata_allow_tpm, int, 0444);
MODULE_PARM_DESC(allow_tpm, "Permit the use of TPM commands (0=off [default], 1=on)");
+static int atapi_an;
+module_param(atapi_an, int, 0444);
+MODULE_PARM_DESC(atapi_an, "Enable ATAPI AN media presence notification (0\x0ff [default], 1=on)");
+
MODULE_AUTHOR("Jeff Garzik");
MODULE_DESCRIPTION("Library module for ATA devices");
MODULE_LICENSE("GPL");
@@ -2572,7 +2576,8 @@ int ata_dev_configure(struct ata_device *dev)
* to enable ATAPI AN to discern between PHY status
* changed notifications and ATAPI ANs.
*/
- if ((ap->flags & ATA_FLAG_AN) && ata_id_has_atapi_AN(id) &&
+ if (atapi_an &&
+ (ap->flags & ATA_FLAG_AN) && ata_id_has_atapi_AN(id) &&
(!sata_pmp_attached(ap) ||
sata_scr_read(&ap->link, SCR_NOTIFICATION, &sntf) = 0)) {
unsigned int err_mask;
^ permalink raw reply related
* 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
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