* Re: Subject: [PATCH 01/16] Squashfs: inode operations
From: Jörn Engel @ 2008-10-17 16:53 UTC (permalink / raw)
To: Phillip Lougher
Cc: akpm, linux-embedded, linux-fsdevel, linux-kernel, tim.bird
In-Reply-To: <E1KqrTW-0001xC-9M@dylan>
None of the comments below are a reason against mainline inclusion, imo.
They should get handled, but whether that happens before or after a
merge doesn't really matter.
On Fri, 17 October 2008 16:42:50 +0100, Phillip Lougher wrote:
>
> +#include <linux/squashfs_fs.h>
> +#include <linux/squashfs_fs_sb.h>
> +#include <linux/squashfs_fs_i.h>
Current verdict seems to be that these files should live in fs/squashfs/,
not include/linux/. No kernel code beside squashfs needs the headers
and userspace tools should have a private copy.
> +static int squashfs_new_inode(struct super_block *s, struct inode *i,
> + struct squashfs_base_inode *inodeb)
> +{
> + if (squashfs_get_id(s, le16_to_cpu(inodeb->uid), &i->i_uid) == 0)
> + goto out;
> + if (squashfs_get_id(s, le16_to_cpu(inodeb->guid), &i->i_gid) == 0)
> + goto out;
> +
> + i->i_ino = le32_to_cpu(inodeb->inode_number);
> + i->i_mtime.tv_sec = le32_to_cpu(inodeb->mtime);
> + i->i_atime.tv_sec = i->i_mtime.tv_sec;
> + i->i_ctime.tv_sec = i->i_mtime.tv_sec;
> + i->i_mode = le16_to_cpu(inodeb->mode);
> + i->i_size = 0;
> +
> + return 1;
> +
> +out:
> + return 0;
> +}
Most code uses "sb" and "inode", which I consider easier to read - if
only for consistency.
> +int squashfs_read_inode(struct inode *i, long long inode)
Is your "long long inode" what most filesystems call "inode->i_ino"? It
seems to be.
> + if (squashfs_new_inode(s, i, inodeb) == 0)
> + goto failed_read;
Most linux functions return 0 on success and -ESOMETHING on error. You
return 0 on error and 1 on success. That makes it likely for someone
else to do something like
err = squashfs_foo(bar);
if (err)
goto fail;
Oops.
Jörn
--
Measure. Don't tune for speed until you've measured, and even then
don't unless one part of the code overwhelms the rest.
-- Rob Pike
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: Subject: [PATCH 00/16] Squashfs: compressed read-only filesystem
From: Jörn Engel @ 2008-10-17 17:34 UTC (permalink / raw)
To: Phillip Lougher
Cc: akpm, linux-embedded, linux-fsdevel, linux-kernel, tim.bird
In-Reply-To: <E1KqrTW-0001x8-3h@dylan>
On Fri, 17 October 2008 16:42:50 +0100, Phillip Lougher wrote:
>
> Codewise all of the packed bit-fields and the swap macros have been removed in
> favour of aligned structures and in-line swapping using leXX_to_cpu(). The
> code has also been extensively restructured, reformatted to kernel coding
> standards and commented.
Excellent! The data structures look good and I don't see a reason for
another format change. Which means the main reason against merging the
code has gone. Your style differs from other kernel code and in a
number of cases it would be nice to be more consistent with existing
conventions. It would certainly help others when reading the code. And
of course, one way to do so it to just merge and wait for some janitors
to notice squashfs and send patches. :)
I have to admit I am scared of this function:
+int squashfs_read_metadata(struct super_block *s, void *buffer,
+ long long block, unsigned int offset,
+ int length, long long *next_block,
+ unsigned int *next_offset)
It takes seven parameters, five of which look deceptively similar to me.
Almost every time I see a call to this function, my mind goes blank.
There must be some way to make this function a bit more agreeable. One
option is to fuse the "block" and "offset" parameters into a struct and
just pass two sets of this struct. Another would be to combine the two
sets of addresses into a single one. A quick look at some of the
callers shows seems to favor that approach.
squashfs_read_metadata(..., block, offset, ..., &block, &offset)
Could become
squashfs_read_metadata(..., &block, &offset, ...)
But again, such a change is no showstopper for mainline inclusion.
> Anyway that's my case for inclusion. If any readers want Squashfs
> mainlined it's probably now a good time to offer support!
Please no. A large amount of popular support would only bring you into
the reiser4 league. Bad arguments don't improve when repeated.
Support in the form of patches would be a different matter, though.
Jörn
--
Mac is for working,
Linux is for Networking,
Windows is for Solitaire!
-- stolen from dc
^ permalink raw reply
* Re: Subject: [PATCH 00/16] Squashfs: compressed read-only filesystem
From: David P. Quigley @ 2008-10-17 18:27 UTC (permalink / raw)
To: Phillip Lougher
Cc: akpm, linux-embedded, linux-fsdevel, linux-kernel, tim.bird
In-Reply-To: <E1KqrTW-0001x8-3h@dylan>
Looking through the code I see two references to xattrs, one is the
index of the xattr table in the superblock and there seems to be struct
member in one of the inode structures that is an index into this table.
Looking through the code I don't see either of these used at all. Do you
intend to add xattr support at some point? I saw reference to the desire
to add xattr support in an email from 2004 but you said that the code
has been rewritten since then. If you are going to add xattr support you
probably want to add it to more than just regular files. In SELinux and
other LSMs symlinks and directories are also labeled so they will need
xattr entries.
Dave
^ permalink raw reply
* Power cut in management
From: marco.stornelli @ 2008-10-18 11:20 UTC (permalink / raw)
To: linux-embedded
Hi all,
I'm working with a board where the power is turn on/off through a key as
in a car. Is there any design pattern to afford that? It's the first time
I have to manage a situation where the power can suddenly cut in anytime.
Hardware guys are working to get "time" to do a clean shutdown (I turn the
key but I still have the power) but any suggestions are welcome. However,
I can't use a simply read-only filesystem (at least for root fs) because
the board has got an sdcard that can be inserted (and then mounted in rw
mode) anytime. Thanks.
Regards,
Marco
^ permalink raw reply
* Re: Power cut in management
From: Jamie Lokier @ 2008-10-18 11:49 UTC (permalink / raw)
To: marco.stornelli; +Cc: linux-embedded
In-Reply-To: <4917.79.37.233.237.1224328849.squirrel@nausicaa2.coritel.it>
marco.stornelli@coritel.it wrote:
> I'm working with a board where the power is turn on/off through a key as
> in a car. Is there any design pattern to afford that? It's the first time
> I have to manage a situation where the power can suddenly cut in anytime.
> Hardware guys are working to get "time" to do a clean shutdown (I turn the
> key but I still have the power) but any suggestions are welcome. However,
> I can't use a simply read-only filesystem (at least for root fs) because
> the board has got an sdcard that can be inserted (and then mounted in rw
> mode) anytime. Thanks.
This is off the top of my head, and may be rubbish.
From http://www.linux-mtd.infradead.org/doc/ubifs.html:
We have heard reports that MMC and SD cards corrupt and loose data
if power is cut during writing. Even the data which was there long
time before may corrupt or disappear. This means that they have
bad FTL which does not do things properly. But again, this does
not have to be true for all MMCs and SDs - there are many
different vendors. But again, you should be careful.
As long as you have sufficient emergency power to finish writing a
consistent filesystem state and no incomplete block to the SD card,
and to gracefully shut down the SD card so that it stops reorganising
data on the flash internally, it should be ok. That means routing
emergency power to the CPU and SD card, so that you don't get
corruption in the middle of writing a block.
Can you use a journalling filesystem like ext3, reiserfs, xfs, or even
UBIFS on the card, or does it have to be FAT? With a journalling
filesystem, they vary on the details but basically if you can finish
the current write request in progress, there's no fs-level corruption.
With FAT, completing just the write in progress is not enough. In
principle a small number of writes could be used to get the fs into a
consistent state in an emergency, and the required number could be
kept bounded by changes to the FAT fs code.
Emergency power isn't necessarily required for the peripherals such as
panel LEDs, displays, CD drives, radios, serial ports, speakers
etc. that you might have, so by routing it only to a fewer essential
components, and shutting down the rest, you'll have a stable power for
longer off a smaller capacitor.
Make sure the hardware is able to notify the CPU by interrupt
immediately when the main power is cut, so the CPU can switch into the
emergency mode as quickly as possible, cut power to unnecessary
peripherals, only finish the I/O request already in progress, or the
minimum required for a consistent state, and gracefully shut down the
SD card. This means the board's PSU should not simply keep going for
a couple of seconds after input power is lost: it must provide you
with a logic signal too. Alos, make sure during this time that the
board's PSU voltage output remains stable and doesn't drop drastically
during the emergency shutdown, as that could lead to SD card
corruption too.
-- Jamie
^ permalink raw reply
* Re: Power cut in management
From: David Woodhouse @ 2008-10-18 12:04 UTC (permalink / raw)
To: Jamie Lokier; +Cc: marco.stornelli, linux-embedded
In-Reply-To: <20081018114910.GA29345@shareable.org>
On Sat, 2008-10-18 at 12:49 +0100, Jamie Lokier wrote:
> Can you use a journalling filesystem like ext3, reiserfs, xfs, or even
> UBIFS on the card, or does it have to be FAT? With a journalling
> filesystem, they vary on the details but basically if you can finish
> the current write request in progress, there's no fs-level corruption.
Careful. When you use a solid state "disk", you're actually using your
file system on top of an underlying "pseudo-filesystem" which makes the
flash pretend to be a disk. Your data are at the mercy of that
underlying code, which in our past experience always seem to have been
implemented by the same crack-smoking hobos they drag in off the street
to write PC BIOSes. However good your own journalling file system on
_top_ of that 'disk' is, you can still lose everything with a badly
timed power-off.
If you want to store data on solid state media, my current advice is
either to do it on _real_ flash directly with a flash-based file system
like JFFS2 or UBIFS, or to pray regularly to the deity of your choice.
--
dwmw2
^ permalink raw reply
* Re: Power cut in management
From: Jamie Lokier @ 2008-10-18 12:56 UTC (permalink / raw)
To: David Woodhouse; +Cc: marco.stornelli, linux-embedded
In-Reply-To: <1224331493.6770.1360.camel@macbook.infradead.org>
David Woodhouse wrote:
> On Sat, 2008-10-18 at 12:49 +0100, Jamie Lokier wrote:
> > Can you use a journalling filesystem like ext3, reiserfs, xfs, or even
> > UBIFS on the card, or does it have to be FAT? With a journalling
> > filesystem, they vary on the details but basically if you can finish
> > the current write request in progress, there's no fs-level corruption.
>
> Careful. When you use a solid state "disk", you're actually using your
> file system on top of an underlying "pseudo-filesystem" which makes the
> flash pretend to be a disk. Your data are at the mercy of that
> underlying code, which in our past experience always seem to have been
> implemented by the same crack-smoking hobos they drag in off the street
> to write PC BIOSes. However good your own journalling file system on
> _top_ of that 'disk' is, you can still lose everything with a badly
> timed power-off.
I agree, hence the idea to complete the current write request _and
also_ gracefully shutdown the SD card to an inactive state, before
power is dropped.
To continue the filesystem on another pseudo-filesystem analogy,
that's like calling fsync on the pseudo-filesystem.
No guarantees - even Linux has fsync worthy of crack-smoking hobos at
times ;-) - but better than not calling fsync at all!
But is it even possible to shutdown an SD card gracefully, e.g. with a
power-down command?
> If you want to store data on solid state media, my current advice is
> either to do it on _real_ flash directly with a flash-based file system
> like JFFS2 or UBIFS, or to pray regularly to the deity of your choice.
Trouble is, that's not suitable for a dashboard unit where users plug
in their own media card.
Marco didn't say if the SD card is for users to plug in their own
media, or if it's internal storage for the device.
Marco, if it's just for the device itself to use, follow David's
suggestion if you can: use real flash with UBIFS or something like it,
not an SD card. That will be much easier.
-- Jamie
^ permalink raw reply
* Re: Power cut in management
From: David Woodhouse @ 2008-10-18 13:31 UTC (permalink / raw)
To: Jamie Lokier; +Cc: marco.stornelli, linux-embedded
In-Reply-To: <20081018125621.GA30391@shareable.org>
On Sat, 2008-10-18 at 13:56 +0100, Jamie Lokier wrote:
> Trouble is, that's not suitable for a dashboard unit where users plug
> in their own media card.
>
> Marco didn't say if the SD card is for users to plug in their own
> media, or if it's internal storage for the device.
True, but the situation is different for a removable card. Firstly, it's
unlikely to be mission-critical; the device will still operate without
it. Secondly, even the most naïve of users knows that these things are
disposable.
It's different if you're building a black box around them, with one of
these things inside.
--
David Woodhouse Open Source Technology Centre
David.Woodhouse@intel.com Intel Corporation
^ permalink raw reply
* Re: Power cut in management
From: Jamie Lokier @ 2008-10-18 13:38 UTC (permalink / raw)
To: David Woodhouse; +Cc: marco.stornelli, linux-embedded
In-Reply-To: <1224336683.6770.1364.camel@macbook.infradead.org>
David Woodhouse wrote:
> On Sat, 2008-10-18 at 13:56 +0100, Jamie Lokier wrote:
> > Trouble is, that's not suitable for a dashboard unit where users plug
> > in their own media card.
> >
> > Marco didn't say if the SD card is for users to plug in their own
> > media, or if it's internal storage for the device.
>
> True, but the situation is different for a removable card. Firstly, it's
> unlikely to be mission-critical; the device will still operate without
> it. Secondly, even the most naïve of users knows that these things are
> disposable.
>
> It's different if you're building a black box around them, with one of
> these things inside.
I agree, this is very good advice.
-- Jamie
^ permalink raw reply
* Re: Power cut in management
From: Marco @ 2008-10-18 16:01 UTC (permalink / raw)
To: Jamie Lokier; +Cc: David Woodhouse, linux-embedded
In-Reply-To: <20081018133801.GA30897@shareable.org>
Jamie Lokier ha scritto:
> David Woodhouse wrote:
>> On Sat, 2008-10-18 at 13:56 +0100, Jamie Lokier wrote:
>>> Trouble is, that's not suitable for a dashboard unit where users plug
>>> in their own media card.
>>>
>>> Marco didn't say if the SD card is for users to plug in their own
>>> media, or if it's internal storage for the device.
>> True, but the situation is different for a removable card. Firstly, it's
>> unlikely to be mission-critical; the device will still operate without
>> it. Secondly, even the most naïve of users knows that these things are
>> disposable.
>>
>> It's different if you're building a black box around them, with one of
>> these things inside.
>
> I agree, this is very good advice.
>
> -- Jamie
>
Thank you very much for your response. The sdcard, however, it's for the
user so I haven't control on it, I think probably it will be FAT. Jamie
you said to manage the situation with an interrupt, I agree. My first
plan was (more or less) to have an application in user space that it
checks the interrupt (UIO driver ?) and simulates a console command to
do a clean shutdown. Then in the kernel routine I do something to cut
the power definitely. For my environment (about the time) it's possible
even in relation with the "emergency power". The only problem is: what
happens if before I install the irq handler the user turn off the
system? I mean I can't "loose" the interrupt. In this case it'd be like
a spurious interrupt from system point view. Let me know if I'm wrong.
Thanks.
^ permalink raw reply
* mio p350 could run linux?
From: Roberto A. Foglietta @ 2008-10-18 17:05 UTC (permalink / raw)
To: Embedded Linux mailing list
Hi,
I would know if somebody have ever tried to run linux on this piece of hw
http://www.mio-tech.be/en/gps-navigation-device-Mio-P350-specifications.htm
do you think it is possible? Do you know somebody who had any kind of
success in doing this?
Thanks,
--
/roberto
^ permalink raw reply
* Re: Power cut in management
From: Ben Nizette @ 2008-10-18 21:33 UTC (permalink / raw)
To: Marco; +Cc: Jamie Lokier, David Woodhouse, linux-embedded
In-Reply-To: <48FA0851.4010209@coritel.it>
On Sat, 2008-10-18 at 18:01 +0200, Marco wrote:
> The only problem is: what
> happens if before I install the irq handler the user turn off the
> system? I mean I can't "loose" the interrupt. In this case it'd be like
> a spurious interrupt from system point view. Let me know if I'm wrong.
> Thanks.
>
Make sure that
1- The grace period the hardware guys give you is long enough,
theoretically, to install the handler _and_ handle it
1a- The grace period is guaranteed no matter how long the system has
been on for
2- make the interrupt level-triggered so you don't miss it (note that
that interrupt should be disabled before a handler is registered so you
won't get a spurious interrupt)
3- ensure you don't do anything which would be affected by incorrect
power, such as fs writes, before the handler has been installed both in
the kernel and in userspace.
You should be fine :-)
--Ben.
^ permalink raw reply
* Re: mio p350 could run linux?
From: Grant Likely @ 2008-10-18 23:44 UTC (permalink / raw)
To: Roberto A. Foglietta; +Cc: Embedded Linux mailing list
In-Reply-To: <e4c675870810181005r238e2e35tf6b11e8daa20d8a0@mail.gmail.com>
On Sat, Oct 18, 2008 at 07:05:28PM +0200, Roberto A. Foglietta wrote:
> Hi,
>
> I would know if somebody have ever tried to run linux on this piece of hw
>
> http://www.mio-tech.be/en/gps-navigation-device-Mio-P350-specifications.htm
>
> do you think it is possible? Do you know somebody who had any kind of
> success in doing this?
It certainly would be possible; it has sufficient specs. The trick is
finding/learning/reverse-engineering enough about the device to get a
Linux kernel onto it and booted.
g.
^ permalink raw reply
* Re: mio p350 could run linux?
From: Roberto A. Foglietta @ 2008-10-18 23:58 UTC (permalink / raw)
To: Grant Likely; +Cc: Embedded Linux mailing list
In-Reply-To: <20081018234438.GA10411@secretlab.ca>
2008/10/19 Grant Likely <grant.likely@secretlab.ca>:
> On Sat, Oct 18, 2008 at 07:05:28PM +0200, Roberto A. Foglietta wrote:
>> Hi,
>>
>> I would know if somebody have ever tried to run linux on this piece of hw
>>
>> http://www.mio-tech.be/en/gps-navigation-device-Mio-P350-specifications.htm
>>
>> do you think it is possible? Do you know somebody who had any kind of
>> success in doing this?
>
> It certainly would be possible; it has sufficient specs. The trick is
> finding/learning/reverse-engineering enough about the device to get a
> Linux kernel onto it and booted.
>
At this time it seems nobody tried
http://anytux.org/hardware.php?system_id=1239
Unfortunately I do not have such electronics background to do a thing
like this (and I do not have the mio P350 too).
Thanks,
--
/roberto
^ permalink raw reply
* UIO - interrupt performance
From: Douglas, Jim (Jim) @ 2008-10-20 9:55 UTC (permalink / raw)
To: Embedded Linux mailing list
We are contemplating porting a large number of device drivers to Linux.
The pragmatic solution is to keep them in user mode (using the UIO
framework) where possible ... they are written in C++ for a start.
The obvious disadvantages of user mode device drivers are security /
isolation. The main benefit is ease of development.
Do you know what the *technical* disadvantages of this approach might
be? I am most concerned about possible impact on interrupt handling.
For example, I assume the context switching overhead is higher, and that
interrupt latency is more difficult to predict?
--jim douglas
Avaya UK, Registered in England and Wales under Registered Number
3049861, Registered Address: Avaya House, Cathedral Hill, Guildford,
Surrey, GU2 7YL.
^ permalink raw reply
* Re: UIO - interrupt performance
From: Ben Nizette @ 2008-10-20 10:28 UTC (permalink / raw)
To: Douglas, Jim (Jim); +Cc: Embedded Linux mailing list
In-Reply-To: <5958B8D7916AB84781FE0E7B57C218CB75AB98@306900ANEX2.global.avaya.com>
On Mon, 2008-10-20 at 10:55 +0100, Douglas, Jim (Jim) wrote:
> We are contemplating porting a large number of device drivers to Linux.
> The pragmatic solution is to keep them in user mode (using the UIO
> framework) where possible ... they are written in C++ for a start.
>
> The obvious disadvantages of user mode device drivers are security /
> isolation. The main benefit is ease of development.
>
> Do you know what the *technical* disadvantages of this approach might
> be? I am most concerned about possible impact on interrupt handling.
>
> For example, I assume the context switching overhead is higher, and that
> interrupt latency is more difficult to predict?
Userspace drivers certainly aren't first class citizens; uio and kernel
mode drivers generally aren't really interchangeable.
The technical disadvantages of userspace drivers are that you don't have
access to kernel subsystems, you can't run any userspace content in irq
context so everything needs to be scheduled before it can be dealt with.
A UIO driver still needs a kernel component to do acknowledge the
interrupt. As such when you say "interrupt latency" you need to define
the end point. A UIO driver will have it's in-kernel handler called
just as quickly as any other driver but the userspace app will need to
be scheduled before it receives notification that the IRQ has fired.
The technical advantage of a UIO driver is that devices which only need
to shift data don't have to double-handle it. e.g. an ADC card doesn't
need to move ADC results from hardware to kernel, kernel to userspace,
it's just one fluid movement.
What kind of device drivers are you talking about? They have to be of a
fairly specific flavour to fit in to a UIO model. Linux isn't a
microkernel, userspace drivers are quite restricted in their power.
FWIW there is some (out of tree) kernel code written in C++, it can be
done but you have to avoid the standard c++ library which unfortunately
includes things like 'new'.
--Ben.
^ permalink raw reply
* Re: UIO - interrupt performance
From: Christian SCHWARZ @ 2008-10-20 10:30 UTC (permalink / raw)
To: Douglas, Jim (Jim); +Cc: Embedded Linux mailing list
In-Reply-To: <5958B8D7916AB84781FE0E7B57C218CB75AB98@306900ANEX2.global.avaya.com>
Hi Jim,
> The obvious disadvantages of user mode device drivers are security /
> isolation.
without going back to the endless discussion of micro-kernels vs
monolithic OS's, the main *advantage* is security and isolation: faults
in the driver will not or to a lesser degree impact the kernel and thus
overall system stability. And drivers are isolated from each other, if
the OS is doing at least an OK job.
> Do you know what the *technical* disadvantages of this approach might
> be? I am most concerned about possible impact on interrupt handling.
The main obstacles for driver development in my opinion are:
- additional context switches (user -> user, user <-> kernel)
- you need to have a decent user <-> kernel interface, since partial INT
handling must be done in kernel mode
- a "Device driver framework" generally helps having clean drivers and
reduces code duplication and "spaghetti code" and especially reduce
context switching times
Apart from that the kernel might need to implement mechanisms like
"priority inheritance" or other scheduling policies in order to make
sure the user mode interrupt handler gets to run (with a minimal delay).
//Christian
^ permalink raw reply
* Re: UIO - interrupt performance
From: Marco Stornelli @ 2008-10-20 11:55 UTC (permalink / raw)
To: Douglas, Jim (Jim); +Cc: Embedded Linux mailing list
In-Reply-To: <5958B8D7916AB84781FE0E7B57C218CB75AB98@306900ANEX2.global.avaya.com>
I quite agree with Ben and Christian. I think UIO drivers are usable for
simple devices, I think they aren't mature (will it ever be?) to use it
with complicated devices or with strict requirement.
Regards,
Douglas, Jim (Jim) ha scritto:
> We are contemplating porting a large number of device drivers to Linux.
> The pragmatic solution is to keep them in user mode (using the UIO
> framework) where possible ... they are written in C++ for a start.
>
> The obvious disadvantages of user mode device drivers are security /
> isolation. The main benefit is ease of development.
>
> Do you know what the *technical* disadvantages of this approach might
> be? I am most concerned about possible impact on interrupt handling.
>
> For example, I assume the context switching overhead is higher, and that
> interrupt latency is more difficult to predict?
>
> --jim douglas
> Avaya UK, Registered in England and Wales under Registered Number
> 3049861, Registered Address: Avaya House, Cathedral Hill, Guildford,
> Surrey, GU2 7YL.
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-embedded" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
Marco Stornelli
Embedded Software Engineer
CoRiTeL - Consorzio di Ricerca sulle Telecomunicazioni
http://www.coritel.it
marco.stornelli@coritel.it
+39 06 72582838
^ permalink raw reply
* Re: PRAMFS with XIP support
From: Marco Stornelli @ 2008-10-20 11:58 UTC (permalink / raw)
To: Jared Hulbert; +Cc: Tim Bird, Mike Frysinger, Linux-Embedded
In-Reply-To: <6934efce0810161720q65dfb211v78745912e6743e9c@mail.gmail.com>
Jared Hulbert ha scritto:
> I'd really like to see this.
>
>> Since the feature was already submitted once (or twice even) I'd image
>> there is a record of people comments in the list archives .. That should
>> give a better idea of what needs to be changed ..
>
> If they weren't recent, i.e. 2.6.26, they might not be too relevant.
> The XIP framework changed a lot then.
>
>> I looked at the code on the sourceforge page, and I saw a few clean ups
>> that could happen. Otherwise, it didn't look bad in terms of code
>> quality.
>
> Which sourceforge page?
>
I think Daniel was talking about http://pramfs.sourceforge.net/
--
Marco Stornelli
Embedded Software Engineer
CoRiTeL - Consorzio di Ricerca sulle Telecomunicazioni
http://www.coritel.it
marco.stornelli@coritel.it
+39 06 72582838
^ permalink raw reply
* Re: UIO - interrupt performance
From: Thomas Petazzoni @ 2008-10-20 12:48 UTC (permalink / raw)
To: linux-embedded
In-Reply-To: <5958B8D7916AB84781FE0E7B57C218CB75AB98@306900ANEX2.global.avaya.com>
Le Mon, 20 Oct 2008 10:55:17 +0100,
"Douglas, Jim (Jim)" <jdouglas@avaya.com> a écrit :
> Do you know what the *technical* disadvantages of this approach might
> be? I am most concerned about possible impact on interrupt handling.
>
> For example, I assume the context switching overhead is higher, and
> that interrupt latency is more difficult to predict?
There was a presentation on UIO in embedded systems at the latest
Embedded Linux Conference in April. The presentation includes a small
analysis of UIO's overhead with regard to interrupt latency. See
http://www.celinux.org/elc08_presentations/uio080417celfelc08.pdf
Sincerly,
Thomas
--
Thomas Petazzoni, Free Electrons
Kernel, drivers and embedded Linux development,
consulting, training and support.
http://free-electrons.com
^ permalink raw reply
* Re: UIO - interrupt performance
From: Paul Mundt @ 2008-10-20 13:20 UTC (permalink / raw)
To: Marco Stornelli; +Cc: Douglas, Jim (Jim), Embedded Linux mailing list
In-Reply-To: <48FC71BD.9070703@coritel.it>
On Mon, Oct 20, 2008 at 01:55:41PM +0200, Marco Stornelli wrote:
> I quite agree with Ben and Christian. I think UIO drivers are usable for
> simple devices, I think they aren't mature (will it ever be?) to use it
> with complicated devices or with strict requirement.
>
This is a party line that has been parroted around a lot but doesn't
really have a lot of validity. UIO drivers are usable for situations
where the kernel-side handling of the device can be trivialized but still
remains a necessary component in the device support (other than IRQ
control, there is also the issue of setting up buffers and so on).
A good example of this is platforms that push their multimedia codecs and
blocks down through UIO. The reason for this is that there is a lot of
complexity, requisite support code, and general overhead associated with
supporting these blocks, most of which simply does not belong anywhere in
the kernel, even though the kernel still has to do some degree of device
support. UIO drivers are second class citizens in general, but the
argument that they only apply to simple devices is simply incorrect.
Things like uio_pdrv_genirq exist today which already allow for interrupt
control through userspace, for example. You can grep for the uio_pdrv_genirq
in-tree users to see examples of how this is used in the aforementioned
case today.
^ permalink raw reply
* Re: UIO - interrupt performance
From: Bill Gatliff @ 2008-10-20 16:13 UTC (permalink / raw)
To: Marco Stornelli; +Cc: Douglas, Jim (Jim), Embedded Linux mailing list
In-Reply-To: <48FC71BD.9070703@coritel.it>
Marco Stornelli wrote:
> I quite agree with Ben and Christian. I think UIO drivers are usable for
> simple devices, I think they aren't mature (will it ever be?) to use it
> with complicated devices or with strict requirement.
I disagree. Completely.
I recall seeing a report from the Gelato project, where they reimplemented an
IDE driver under UIO. IIRC, their test results showed at least 80% of the
in-kernel performance--- and this was a very early UIO implementation, I would
guess that things are much improved since then. I know that IDE isn't a USBH,
but it isn't a GPIO LED, either. :)
If you are concerned about timeliness of execution, then if you have never heard
of POSIX.1b then you shouldn't be writing Linux code anyway. But if you do use
the features that POSIX.1b gives you, then I haven't found UIO to be objectionable.
From a performance standpoint, the major differences between UIO vs. in-kernel
are (a) a _possible_ additional context switch at each interrupt, to transfer
control back to the userspace responder, and (b) the elimination of a syscall to
push data through an in-kernel interface back to the device. Only your own
testing with your own hardware and application can tell you if that's a net
improvement or regression and where--- if anywhere--- you take the hit.
The general upsides with UIO are huge: you can debug your driver with gdb, and
you can bind your driver tightly to your application if it makes sense to do so.
Every i/o action is potentially zero-copy straight into the correct data
structures, for example. For some workloads, that puts UIO way ahead of an
in-kernel driver without the complexity of mmap().
As an aside, if you really need an interface that resembles a device node then
you can emulate that in userspace with a FIFO. That lets you put the driver in
a standalone program if you like, and other user applications can't tell the
difference between that and a true device node. (They can figure it out if they
need to, but if they just are using open/close/read/write then they don't care).
The social downside to UIO is that you'll never get your driver(s) mainlined,
since Linux-the-kernel doesn't run in userspace. :)
Put simply, you can't dismiss UIO lightly unless you haven't worked with or
reviewed the code behind it.
b.g.
--
Bill Gatliff
bgat@billgatliff.com
^ permalink raw reply
* Re: UIO - interrupt performance
From: Bill Gatliff @ 2008-10-20 16:25 UTC (permalink / raw)
To: Thomas Petazzoni; +Cc: linux-embedded
In-Reply-To: <20081020144858.1f074d7b@surf>
Thomas Petazzoni wrote:
>
> There was a presentation on UIO in embedded systems at the latest
> Embedded Linux Conference in April. The presentation includes a small
> analysis of UIO's overhead with regard to interrupt latency. See
> http://www.celinux.org/elc08_presentations/uio080417celfelc08.pdf
Bummer, on p. 20 it doesn't describe how the latency was measured. It also
doesn't compare in-kernel measurements with equivalent UIO measurements.
I don't particularly care what the interrupt latency is, if what is being
measured is the time between when the interrupt is signaled to the CPU and the
point at which the request_irq()-registered handler runs.
Rather, most of the time I care more about how long it takes the kernel to wake
up the process that's blocked in a wait_for_completion(), because I do most of
my work outside of interrupt handlers (a characteristic of the devices and
workloads I deal with, ymmv). In that case, the difference between in-kernel
and UIO gets pretty small because the kernel activities at each interrupt are
very similar, perhaps differing only by some cache activity.
Glad they mention SCHED_[FIFO|RR], though. Without those, you're in for a
pretty unpleasant UIO experience.
b.g.
--
Bill Gatliff
bgat@billgatliff.com
^ permalink raw reply
* Re: UIO - interrupt performance
From: Ben Nizette @ 2008-10-20 22:12 UTC (permalink / raw)
To: Nicholas Mc Guire; +Cc: linux-embedded
In-Reply-To: <Pine.LNX.4.58.0810200258210.2562@vlab.hofr.at>
On Mon, 2008-10-20 at 03:06 -0800, Nicholas Mc Guire wrote:
> >
> > On Mon, 2008-10-20 at 10:55 +0100, Douglas, Jim (Jim) wrote:
> > > We are contemplating porting a large number of device drivers to Linux.
> > > The pragmatic solution is to keep them in user mode (using the UIO
> > > framework) where possible ... they are written in C++ for a start.
> > >
> > > The obvious disadvantages of user mode device drivers are security /
> > > isolation. The main benefit is ease of development.
> > >
> > > Do you know what the *technical* disadvantages of this approach might
> > > be? I am most concerned about possible impact on interrupt handling.
> > >
> > > For example, I assume the context switching overhead is higher, and that
> > > interrupt latency is more difficult to predict?
> >
> > Userspace drivers certainly aren't first class citizens; uio and kernel
> > mode drivers generally aren't really interchangeable.
> >
> > The technical disadvantages of userspace drivers are that you don't have
> > access to kernel subsystems, you can't run any userspace content in irq
> > context so everything needs to be scheduled before it can be dealt with.
> > A UIO driver still needs a kernel component to do acknowledge the
> > interrupt. As such when you say "interrupt latency" you need to define
> > the end point. A UIO driver will have it's in-kernel handler called
> > just as quickly as any other driver but the userspace app will need to
> > be scheduled before it receives notification that the IRQ has fired.
> >
> > The technical advantage of a UIO driver is that devices which only need
> > to shift data don't have to double-handle it. e.g. an ADC card doesn't
> > need to move ADC results from hardware to kernel, kernel to userspace,
> > it's just one fluid movement.
> >
> > What kind of device drivers are you talking about? They have to be of a
> > fairly specific flavour to fit in to a UIO model. Linux isn't a
> > microkernel, userspace drivers are quite restricted in their power.
> >
>
> are these claims based on benchmarks of a specific driver ? I only know
> of a singe UIO driver for a Hilscher CIF card and one for a SMX
> Cryptengine (I guess thats yours any way) but none for a AD/DIO card - if
> you know of such a driver I would be interested in seeing its performance.
When UIO was being discussed for inclusion, the example case being
thrown around was for such an ADC card. They claimed to have seen
significant improvements in speed by avoiding the double-handling of
data. Come to think of it, I can't see that this specific driver has
shown up...
But what kind of benchmarks do you want? When I say "restricted in
their power" I mean more in a feature-set kind of way than a raw speed
way. Userspace drivers can't plug in to kernel subsystems so can't, for
example, be SPI hosts or terminal devices or network hardware or
anything else which sits in the middle of a standard stack. All they
can do is be notified of an interrupt and have direct access to a lump
of memory.
As I asked before, what's your use-case? It tends to be fairly obvious
whether the hardware is suitable for a UIO-based driver or whether it's
going to have to live in kernel.
>
> Also if you know of any simple UIO sample drivers that would also help.
As in examples of the userspace half? Unfortunately uio-smx isn't ready
to fly thanks to some significant production delays but the userspace
half of the Hilscher CIF driver can be found at
http://www.osadl.org/projects/downloads/UIO/user/
--Ben.
^ permalink raw reply
* [PATCH v2 RESEND] gpiolib: Add pin change notification
From: Ben Nizette @ 2008-10-20 22:50 UTC (permalink / raw)
To: David Brownell; +Cc: Andrew Morton, linux-kernel, linux-embedded
[-- Attachment #1: Type: text/plain, Size: 826 bytes --]
This adds pin change notification to the gpiolib sysfs interface. It
requires 16 extra bytes in gpio_desc iff CONFIG_GPIO_SYSFS which in turn
means, eg, 4k of .bss usage on AVR32. Due to limitations in sysfs, this
patch makes poll(2) and friends work as expected on the "value"
attribute, though reads on "value" will never block and there is no
facility for async reads and writes.
Signed-off-by: Ben Nizette <bn@niasdigital.com>
---
Right, there seems to be a new outgoing mail server between me and you
which viciously attacks tabulations. Until I find the monkey
responsible please accept the patch as an attachment along with my
apologies.
Documentation/gpio.txt | 48 +++++++++
drivers/gpio/gpiolib.c | 246 ++++++++++++++++++++++++++++++++++++++++++++++++-
2 files changed, 289 insertions(+), 5 deletions(-)
[-- Attachment #2: pinchange.patch --]
[-- Type: text/x-patch, Size: 11349 bytes --]
diff --git a/Documentation/gpio.txt b/Documentation/gpio.txt
index b1b9887..998a40f 100644
--- a/Documentation/gpio.txt
+++ b/Documentation/gpio.txt
@@ -529,6 +529,21 @@ and have the following read/write attributes:
is configured as an output, this value may be written;
any nonzero value is treated as high.
+ "notify" ... Selects a method for the detection of pin change
+ events. This can be written or read as one of "none",
+ "irq" or a number. If "none", no detection will be
+ done, if "irq" then the change detection will be done
+ by registering an interrupt handler on the line given
+ by gpio_to_irq for that gpio. If a number is written,
+ the gpio will be polled for a state change every n
+ milliseconds where n is the number written. The
+ minimum interval is 10 milliseconds.
+
+ "notify_filter" ... This can be written and read as one of
+ "rising", "falling" or "both". If "rising", only
+ rising edges will be reported, similarly for "falling"
+ and "both".
+
GPIO controllers have paths like /sys/class/gpio/chipchip42/ (for the
controller implementing GPIOs starting at #42) and have the following
read-only attributes:
@@ -549,6 +564,39 @@ gpiochip nodes (possibly in conjunction with schematics) to determine
the correct GPIO number to use for a given signal.
+Pin Change Notification
+-----------------------
+The "value" attribute of a gpio is pollable. For this to work, you
+must have set up the notify attribute of that gpio to the type of
+detection suitable for the underlying hardware.
+
+If the hardware supports interrupts on both edges and the gpio to
+interrupt line mapping is unique, you should write "irq" to the notify
+attribute.
+
+If the hardware doesn't support this, or you're unsure, you can write
+a number to the notify attribute. This number is the delay between
+successive polls of the gpio state in milliseconds. You may not poll
+more often than 10ms intervals.
+
+You must use poll mode if communication with the gpio's chip requires
+sleeping. This is the case if, for example, the gpio is part of a
+I2C or SPI GPIO expander.
+
+By default, both rising and falling edges are reported. To filter
+this, you can write one of "rising" or "falling" to the notify_filter
+attribute. To go back to being notified of both edge changes, write
+"both" to this attribute.
+
+Once the notification has been set up, you may use poll(2) and friends
+on the "value" attribute. This attribute will register as having new
+data ready to be read if and only if there has been a state change
+since the last read(2) to the "value" attribute.
+
+Note that unlike a regular device file, a read on the "value" attribute
+will never block whether or not there's new data to be read.
+
+
Exporting from Kernel code
--------------------------
Kernel code can explicitly manage exports of GPIOs which have already been
diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c
index 9112830..f43f231 100644
--- a/drivers/gpio/gpiolib.c
+++ b/drivers/gpio/gpiolib.c
@@ -1,6 +1,7 @@
#include <linux/kernel.h>
#include <linux/module.h>
#include <linux/irq.h>
+#include <linux/interrupt.h>
#include <linux/spinlock.h>
#include <linux/device.h>
#include <linux/err.h>
@@ -49,13 +50,35 @@ struct gpio_desc {
#define FLAG_RESERVED 2
#define FLAG_EXPORT 3 /* protected by sysfs_lock */
#define FLAG_SYSFS 4 /* exported via /sys/class/gpio/control */
+#define ASYNC_MODE_IRQ 5 /* using interrupts for async notification */
+#define ASYNC_MODE_POLL 6 /* using polling for async notification */
+#define ASYNC_RISING 7 /* will notify on rising edges */
+#define ASYNC_FALLING 8 /* will notify on falling edges */
#ifdef CONFIG_DEBUG_FS
const char *label;
#endif
+
+#ifdef CONFIG_GPIO_SYSFS
+ struct device *dev;
+ struct poll_desc *poll;
+
+ /* Poll interval in jiffies, here (rather than in struct poll_desc
+ * so the user can change the value no matter what their current
+ * notification mode is */
+ long timeout;
+
+ /* Last known value */
+ int val;
+#endif
};
static struct gpio_desc gpio_desc[ARCH_NR_GPIOS];
+struct poll_desc {
+ struct delayed_work work;
+ unsigned gpio;
+};
+
static inline void desc_set_label(struct gpio_desc *d, const char *label)
{
#ifdef CONFIG_DEBUG_FS
@@ -184,12 +207,56 @@ static DEFINE_MUTEX(sysfs_lock);
* /value
* * always readable, subject to hardware behavior
* * may be writable, as zero/nonzero
- *
- * REVISIT there will likely be an attribute for configuring async
- * notifications, e.g. to specify polling interval or IRQ trigger type
- * that would for example trigger a poll() on the "value".
+ * /notify
+ * * read/write as "irq", numeric or "none"
+ * /notify_filter
+ * * read/write as "rising", "falling" or "both"
*/
+struct poll_desc *work_to_poll(struct work_struct *ws)
+{
+ return container_of((struct delayed_work *)ws, struct poll_desc, work);
+}
+
+void gpio_poll_work(struct work_struct *ws)
+{
+ struct poll_desc *poll = work_to_poll(ws);
+
+ unsigned gpio = poll->gpio;
+ struct gpio_desc *desc = &gpio_desc[gpio];
+
+ int new = gpio_get_value_cansleep(gpio);
+ int old = desc->val;
+
+ if ((new && !old && test_bit(ASYNC_RISING, &desc->flags)) ||
+ (!new && old && test_bit(ASYNC_FALLING, &desc->flags)))
+ sysfs_notify(&desc->dev->kobj, NULL, "value");
+
+ desc->val = new;
+ schedule_delayed_work(&poll->work, desc->timeout);
+}
+
+static irqreturn_t gpio_irq_handler(int irq, void *dev_id)
+{
+ struct gpio_desc *desc = dev_id;
+ int gpio = desc - gpio_desc;
+ int new, old;
+
+ if (!gpio_is_valid(gpio))
+ return IRQ_NONE;
+
+ new = gpio_get_value(gpio);
+ old = desc->val;
+
+ if ((new && !old && test_bit(ASYNC_RISING, &desc->flags)) ||
+ (!new && old && test_bit(ASYNC_FALLING, &desc->flags)))
+ sysfs_notify(&desc->dev->kobj, NULL, "value");
+
+ desc->val = new;
+
+ return IRQ_HANDLED;
+}
+
static ssize_t gpio_direction_show(struct device *dev,
struct device_attribute *attr, char *buf)
{
@@ -284,9 +351,162 @@ static ssize_t gpio_value_store(struct device *dev,
static /*const*/ DEVICE_ATTR(value, 0644,
gpio_value_show, gpio_value_store);
+static ssize_t gpio_notify_show(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ const struct gpio_desc *desc = dev_get_drvdata(dev);
+ ssize_t ret;
+
+ mutex_lock(&sysfs_lock);
+
+ if (test_bit(ASYNC_MODE_IRQ, &desc->flags))
+ ret = sprintf(buf, "irq\n");
+ else if (test_bit(ASYNC_MODE_POLL, &desc->flags))
+ ret = sprintf(buf, "%ld\n", desc->timeout * 1000 / HZ);
+ else
+ ret = sprintf(buf, "none\n");
+
+ mutex_unlock(&sysfs_lock);
+ return ret;
+}
+
+static ssize_t gpio_notify_store(struct device *dev,
+ struct device_attribute *attr, const char *buf, size_t size)
+{
+ struct gpio_desc *desc = dev_get_drvdata(dev);
+ unsigned gpio = desc - gpio_desc;
+ ssize_t status = 0;
+ int new;
+ long value;
+
+ mutex_lock(&sysfs_lock);
+
+ if (sysfs_streq(buf, "irq"))
+ new = ASYNC_MODE_IRQ;
+ else if (sysfs_streq(buf, "none"))
+ new = -1;
+ else {
+ status = strict_strtol(buf, 0, &value);
+
+ if (status || value < 10) {
+ status = -EINVAL;
+ goto out;
+ }
+
+ /* value will be in ms, convert to jiffies. */
+ desc->timeout = DIV_ROUND_UP(value * HZ, 1000);
+ new = ASYNC_MODE_POLL;
+ }
+
+ if (test_and_clear_bit(ASYNC_MODE_IRQ, &desc->flags))
+ free_irq(gpio_to_irq(gpio), desc);
+ else if (test_and_clear_bit(ASYNC_MODE_POLL, &desc->flags)) {
+ BUG_ON(!desc->poll);
+
+ cancel_delayed_work(&desc->poll->work);
+ kfree(desc->poll);
+ }
+
+ if (new == ASYNC_MODE_IRQ) {
+ if (desc->chip->can_sleep) {
+ /* -EINVAL probably isn't appropriate here,
+ * what's code for "not supported by
+ * underlying hardware"? */
+ status = -EINVAL;
+ goto out;
+ }
+
+ desc->val = gpio_get_value(gpio);
+
+ /* REVISIT: We always request both edges then filter in the
+ * irq handler. How many devices don't support this..?? */
+ status = request_irq(gpio_to_irq(gpio), gpio_irq_handler,
+ IRQF_SHARED | IRQF_TRIGGER_RISING |
+ IRQF_TRIGGER_FALLING,
+ "gpiolib", desc);
+ } else if (new == ASYNC_MODE_POLL) {
+
+ desc->poll = kmalloc(sizeof(struct poll_desc), GFP_KERNEL);
+ if (!desc->poll) {
+ status = -ENOMEM;
+ goto out;
+ }
+
+ desc->poll->gpio = gpio;
+
+ desc->val = gpio_get_value_cansleep(gpio);
+
+ INIT_DELAYED_WORK(&desc->poll->work, gpio_poll_work);
+ schedule_delayed_work(&desc->poll->work, desc->timeout);
+ }
+
+ if (new >= 0 && !status)
+ set_bit(new, &desc->flags);
+
+out:
+ if (status)
+ dev_dbg(dev, "gpio notification mode set fail, err %d\n",
+ (int)status);
+
+ mutex_unlock(&sysfs_lock);
+ return status ? : size;
+}
+
+static const DEVICE_ATTR(notify, 0644,
+ gpio_notify_show, gpio_notify_store);
+
+static ssize_t gpio_notify_filter_show(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ struct gpio_desc *desc = dev_get_drvdata(dev);
+ ssize_t status;
+
+ mutex_lock(&sysfs_lock);
+
+ if (test_bit(ASYNC_FALLING, &desc->flags) &&
+ test_bit(ASYNC_RISING, &desc->flags))
+ status = sprintf(buf, "both\n");
+ else if (test_bit(ASYNC_RISING, &desc->flags))
+ status = sprintf(buf, "rising\n");
+ else
+ status = sprintf(buf, "falling\n");
+
+ mutex_unlock(&sysfs_lock);
+ return status;
+}
+
+static ssize_t gpio_notify_filter_store(struct device *dev,
+ struct device_attribute *attr, const char *buf, size_t size)
+{
+ struct gpio_desc *desc = dev_get_drvdata(dev);
+ ssize_t status = 0;
+
+ mutex_lock(&sysfs_lock);
+
+ if (sysfs_streq(buf, "rising")) {
+ set_bit(ASYNC_RISING, &desc->flags);
+ clear_bit(ASYNC_FALLING, &desc->flags);
+ } else if (sysfs_streq(buf, "falling")) {
+ clear_bit(ASYNC_RISING, &desc->flags);
+ set_bit(ASYNC_FALLING, &desc->flags);
+ } else if (sysfs_streq(buf, "both")) {
+ set_bit(ASYNC_RISING, &desc->flags);
+ set_bit(ASYNC_FALLING, &desc->flags);
+ } else
+ status = -EINVAL;
+
+ mutex_unlock(&sysfs_lock);
+ return status ? : size;
+}
+
+static const DEVICE_ATTR(notify_filter, 0644,
+ gpio_notify_filter_show, gpio_notify_filter_store);
+
static const struct attribute *gpio_attrs[] = {
&dev_attr_direction.attr,
&dev_attr_value.attr,
+ &dev_attr_notify.attr,
+ &dev_attr_notify_filter.attr,
NULL,
};
@@ -398,6 +618,17 @@ static ssize_t unexport_store(struct class *class, const char *buf, size_t len)
status = 0;
gpio_free(gpio);
}
+
+ if (test_and_clear_bit(ASYNC_MODE_IRQ, &gpio_desc[gpio].flags))
+ free_irq(gpio_to_irq(gpio), &gpio_desc[gpio]);
+
+ if (test_and_clear_bit(ASYNC_MODE_POLL, &gpio_desc[gpio].flags)) {
+ BUG_ON(!gpio_desc[gpio].poll);
+
+ cancel_delayed_work(&gpio_desc[gpio].poll->work);
+ kfree(gpio_desc[gpio].poll);
+ }
+
done:
if (status)
pr_debug("%s: status %d\n", __func__, status);
@@ -479,6 +710,12 @@ int gpio_export(unsigned gpio, bool direction_may_change)
status = -ENODEV;
if (status == 0)
set_bit(FLAG_EXPORT, &desc->flags);
+
+ desc->dev = dev;
+ /* 100ms default poll interval */
+ desc->timeout = HZ / 10;
+ set_bit(ASYNC_RISING, &desc->flags);
+ set_bit(ASYNC_FALLING, &desc->flags);
}
mutex_unlock(&sysfs_lock);
@@ -626,7 +863,6 @@ static int __init gpiolib_sysfs_init(void)
}
spin_unlock_irqrestore(&gpio_lock, flags);
-
return status;
}
postcore_initcall(gpiolib_sysfs_init);
^ 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