Re: [PATCH] UIO: introduce sysfs_ops for map_attr_ktype
Am Tue, 19 Feb 2008 01:55:05 -0800
schrieb Brandon Philips <[EMAIL PROTECTED]>:
> This fixes two bugs with UIO that cropped up recently in -rc1
>
> 1) WARNING: at fs/sysfs/file.c:334 sysfs_open_file when trying to open
>a map addr/size file - complaining about missing sysfs_ops for
> ktype
> 2) Permission denied when reading uio/uio0/maps/map0/{addr,size} when
>files are mode S_IRUGO
>
> Also fix a typo: attr_attribute -> addr_attribute
Hi Brandon,
thanks a lot for that one! I've tested with 2.6.25-rc2 with a Hilscher
NetX PCI card, works without problems. All attributes are accessible.
Makes 2.6.25-rc usable again :-)
Thanks,
Hans
>
> Signed-off-by: Brandon Philips <[EMAIL PROTECTED]>
Signed-off-by: Hans J. Koch <[EMAIL PROTECTED]>
>
> ---
> drivers/uio/uio.c | 54
> ++--- 1 file changed, 37
> insertions(+), 17 deletions(-)
>
> Index: linux-2.6/drivers/uio/uio.c
> ===
> --- linux-2.6.orig/drivers/uio/uio.c
> +++ linux-2.6/drivers/uio/uio.c
> @@ -57,29 +57,29 @@ struct uio_map {
> };
> #define to_map(map) container_of(map, struct uio_map, kobj)
>
> -
> -static ssize_t map_attr_show(struct kobject *kobj, struct
> kobj_attribute *attr,
> - char *buf)
> +static ssize_t map_addr_show(struct uio_mem *mem, char *buf)
> {
> - struct uio_map *map = to_map(kobj);
> - struct uio_mem *mem = map->mem;
> -
> - if (strncmp(attr->attr.name, "addr", 4) == 0)
> - return sprintf(buf, "0x%lx\n", mem->addr);
> -
> - if (strncmp(attr->attr.name, "size", 4) == 0)
> - return sprintf(buf, "0x%lx\n", mem->size);
> + return sprintf(buf, "0x%lx\n", mem->addr);
> +}
>
> - return -ENODEV;
> +static ssize_t map_size_show(struct uio_mem *mem, char *buf)
> +{
> + return sprintf(buf, "0x%lx\n", mem->size);
> }
>
> -static struct kobj_attribute attr_attribute =
> - __ATTR(addr, S_IRUGO, map_attr_show, NULL);
> -static struct kobj_attribute size_attribute =
> - __ATTR(size, S_IRUGO, map_attr_show, NULL);
> +struct uio_sysfs_entry {
> + struct attribute attr;
> + ssize_t (*show)(struct uio_mem *, char *);
> + ssize_t (*store)(struct uio_mem *, const char *, size_t);
> +};
> +
> +static struct uio_sysfs_entry addr_attribute =
> + __ATTR(addr, S_IRUGO, map_addr_show, NULL);
> +static struct uio_sysfs_entry size_attribute =
> + __ATTR(size, S_IRUGO, map_size_show, NULL);
>
> static struct attribute *attrs[] = {
> - _attribute.attr,
> + _attribute.attr,
> _attribute.attr,
> NULL, /* need to NULL terminate the list of
> attributes */ };
> @@ -90,8 +90,28 @@ static void map_release(struct kobject *
> kfree(map);
> }
>
> +static ssize_t map_type_show(struct kobject *kobj, struct attribute
> *attr,
> + char *buf)
> +{
> + struct uio_map *map = to_map(kobj);
> + struct uio_mem *mem = map->mem;
> + struct uio_sysfs_entry *entry;
> +
> + entry = container_of(attr, struct uio_sysfs_entry, attr);
> +
> + if (!entry->show)
> + return -EIO;
> +
> + return entry->show(mem, buf);
> +}
> +
> +static struct sysfs_ops uio_sysfs_ops = {
> + .show = map_type_show,
> +};
> +
> static struct kobj_type map_attr_type = {
> .release= map_release,
> + .sysfs_ops = _sysfs_ops,
> .default_attrs = attrs,
> };
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] UIO: introduce sysfs_ops for map_attr_ktype
Am Tue, 19 Feb 2008 01:55:05 -0800
schrieb Brandon Philips [EMAIL PROTECTED]:
This fixes two bugs with UIO that cropped up recently in -rc1
1) WARNING: at fs/sysfs/file.c:334 sysfs_open_file when trying to open
a map addr/size file - complaining about missing sysfs_ops for
ktype
2) Permission denied when reading uio/uio0/maps/map0/{addr,size} when
files are mode S_IRUGO
Also fix a typo: attr_attribute - addr_attribute
Hi Brandon,
thanks a lot for that one! I've tested with 2.6.25-rc2 with a Hilscher
NetX PCI card, works without problems. All attributes are accessible.
Makes 2.6.25-rc usable again :-)
Thanks,
Hans
Signed-off-by: Brandon Philips [EMAIL PROTECTED]
Signed-off-by: Hans J. Koch [EMAIL PROTECTED]
---
drivers/uio/uio.c | 54
++--- 1 file changed, 37
insertions(+), 17 deletions(-)
Index: linux-2.6/drivers/uio/uio.c
===
--- linux-2.6.orig/drivers/uio/uio.c
+++ linux-2.6/drivers/uio/uio.c
@@ -57,29 +57,29 @@ struct uio_map {
};
#define to_map(map) container_of(map, struct uio_map, kobj)
-
-static ssize_t map_attr_show(struct kobject *kobj, struct
kobj_attribute *attr,
- char *buf)
+static ssize_t map_addr_show(struct uio_mem *mem, char *buf)
{
- struct uio_map *map = to_map(kobj);
- struct uio_mem *mem = map-mem;
-
- if (strncmp(attr-attr.name, addr, 4) == 0)
- return sprintf(buf, 0x%lx\n, mem-addr);
-
- if (strncmp(attr-attr.name, size, 4) == 0)
- return sprintf(buf, 0x%lx\n, mem-size);
+ return sprintf(buf, 0x%lx\n, mem-addr);
+}
- return -ENODEV;
+static ssize_t map_size_show(struct uio_mem *mem, char *buf)
+{
+ return sprintf(buf, 0x%lx\n, mem-size);
}
-static struct kobj_attribute attr_attribute =
- __ATTR(addr, S_IRUGO, map_attr_show, NULL);
-static struct kobj_attribute size_attribute =
- __ATTR(size, S_IRUGO, map_attr_show, NULL);
+struct uio_sysfs_entry {
+ struct attribute attr;
+ ssize_t (*show)(struct uio_mem *, char *);
+ ssize_t (*store)(struct uio_mem *, const char *, size_t);
+};
+
+static struct uio_sysfs_entry addr_attribute =
+ __ATTR(addr, S_IRUGO, map_addr_show, NULL);
+static struct uio_sysfs_entry size_attribute =
+ __ATTR(size, S_IRUGO, map_size_show, NULL);
static struct attribute *attrs[] = {
- attr_attribute.attr,
+ addr_attribute.attr,
size_attribute.attr,
NULL, /* need to NULL terminate the list of
attributes */ };
@@ -90,8 +90,28 @@ static void map_release(struct kobject *
kfree(map);
}
+static ssize_t map_type_show(struct kobject *kobj, struct attribute
*attr,
+ char *buf)
+{
+ struct uio_map *map = to_map(kobj);
+ struct uio_mem *mem = map-mem;
+ struct uio_sysfs_entry *entry;
+
+ entry = container_of(attr, struct uio_sysfs_entry, attr);
+
+ if (!entry-show)
+ return -EIO;
+
+ return entry-show(mem, buf);
+}
+
+static struct sysfs_ops uio_sysfs_ops = {
+ .show = map_type_show,
+};
+
static struct kobj_type map_attr_type = {
.release= map_release,
+ .sysfs_ops = uio_sysfs_ops,
.default_attrs = attrs,
};
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: What's needed for a PCIe card to be recognized?
Am Sun, 17 Feb 2008 17:09:39 -0500 schrieb Mark Lord <[EMAIL PROTECTED]>: > Mark Lord wrote: > > Hans J. Koch wrote: > .. > >> Really? Unbelievable what these guys do to make my live harder... > >> So, they might use some undocumented GPIO to turn the power on, and > ... > > GPIO lines are not usually very difficult to trace, > and programming them is pretty easy, too ... I know :-) I'll do that as soon as I've got some spare time (very rare ATM). > > If I had an EeePC here, I'd do that for you (and everyone else), > but I'm waiting for a lower-power (fanless) unit to be introduced > first. Admirable. I didn't have that patience ;-) > > >> refuse that if they don't find the original card? Looks like I > >> can't have WLAN on an EeePC (I won't run a tainted kernel). Stupid > >> thing to sell a PC with Linux preinstalled but with hardware not > >> supported in mainline. > > .. > > > > Try it again with 2.6.25-rc2 and this module option: > > > >options pciehp pciehp_force=1 > > > > Just a thin hope, really, but it might work. I'll give it a try. Thanks for your hints, Hans -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: What's needed for a PCIe card to be recognized?
Am Sun, 17 Feb 2008 17:09:39 -0500 schrieb Mark Lord [EMAIL PROTECTED]: Mark Lord wrote: Hans J. Koch wrote: .. Really? Unbelievable what these guys do to make my live harder... So, they might use some undocumented GPIO to turn the power on, and ... GPIO lines are not usually very difficult to trace, and programming them is pretty easy, too ... I know :-) I'll do that as soon as I've got some spare time (very rare ATM). If I had an EeePC here, I'd do that for you (and everyone else), but I'm waiting for a lower-power (fanless) unit to be introduced first. Admirable. I didn't have that patience ;-) refuse that if they don't find the original card? Looks like I can't have WLAN on an EeePC (I won't run a tainted kernel). Stupid thing to sell a PC with Linux preinstalled but with hardware not supported in mainline. .. Try it again with 2.6.25-rc2 and this module option: options pciehp pciehp_force=1 Just a thin hope, really, but it might work. I'll give it a try. Thanks for your hints, Hans -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: What's needed for a PCIe card to be recognized?
Am Sat, 16 Feb 2008 14:39:46 -0800 schrieb Arjan van de Ven <[EMAIL PROTECTED]>: > On Sat, 16 Feb 2008 22:59:32 +0100 > Hans-Jürgen Koch <[EMAIL PROTECTED]> wrote: > > > I'm playing around with a vanilla 2.6.25-rc1, adding patches to make > > it work on an Asus EeePC. That one has the problem that its Mini > > PCIe WLAN module doesn't show up in lspci. That brought up a few > > questions that I couldn't answer yet: > > > > How can they "hide" a PCIe card? > > What could be their motive to do that? > > How can I make it appear? > > > go to the bios, enable the wireless card. > > that did it for me ;) It didn't for me. I tried all combinations (booting with/without WLAN enabled, enabling WLAN through /proc with/without pciehp loaded and so on). What kernel did you use, and which patches did you apply? Yes, I want to make it work, but I'd really like to understand what's going on there and what's behind it. Thanks, Hans -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
What's needed for a PCIe card to be recognized?
I'm playing around with a vanilla 2.6.25-rc1, adding patches to make it work on an Asus EeePC. That one has the problem that its Mini PCIe WLAN module doesn't show up in lspci. That brought up a few questions that I couldn't answer yet: How can they "hide" a PCIe card? What could be their motive to do that? How can I make it appear? I found some solutions googling around, but they all seem to be funny workarounds, like unloading pciehp and then loading it again with pciehp_force=1, then switching WLAN off and on again (through /proc/acpi/asus/wlan, I've got that one meanwhile)... This doesn't look like a clean solution to me, but I must admit that I don't know enough about PCIe hotplug to understand what's going on. I'd appreciate it if someone could give me a few hints or point me to good documentation. Output of lspci: 00:00.0 Host bridge: Intel Corporation Mobile 915GM/PM/GMS/910GML Express Processor to DRAM Controller (rev 04) 00:02.0 VGA compatible controller: Intel Corporation Mobile 915GM/GMS/910GML Express Graphics Controller (rev 04) 00:02.1 Display controller: Intel Corporation Mobile 915GM/GMS/910GML Express Graphics Controller (rev 04) 00:1b.0 Audio device: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) High Definition Audio Controller (rev 04) 00:1c.0 PCI bridge: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) PCI Express Port 1 (rev 04) 00:1c.1 PCI bridge: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) PCI Express Port 2 (rev 04) 00:1c.2 PCI bridge: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) PCI Express Port 3 (rev 04) 00:1d.0 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB UHCI #1 (rev 04) 00:1d.1 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB UHCI #2 (rev 04) 00:1d.2 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB UHCI #3 (rev 04) 00:1d.3 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB UHCI #4 (rev 04) 00:1d.7 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB2 EHCI Controller (rev 04) 00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev d4) 00:1f.0 ISA bridge: Intel Corporation 82801FBM (ICH6M) LPC Interface Bridge (rev 04) 00:1f.2 IDE interface: Intel Corporation 82801FBM (ICH6M) SATA Controller (rev 04) 00:1f.3 SMBus: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) SMBus Controller (rev 04) 03:00.0 Ethernet controller: Attansic Technology Corp. L2 100 Mbit Ethernet Adapter (rev a0) (The WLAN card should show up at 01:00.0, according to info found on the web). Thanks, Hans -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
What's needed for a PCIe card to be recognized?
I'm playing around with a vanilla 2.6.25-rc1, adding patches to make it work on an Asus EeePC. That one has the problem that its Mini PCIe WLAN module doesn't show up in lspci. That brought up a few questions that I couldn't answer yet: How can they hide a PCIe card? What could be their motive to do that? How can I make it appear? I found some solutions googling around, but they all seem to be funny workarounds, like unloading pciehp and then loading it again with pciehp_force=1, then switching WLAN off and on again (through /proc/acpi/asus/wlan, I've got that one meanwhile)... This doesn't look like a clean solution to me, but I must admit that I don't know enough about PCIe hotplug to understand what's going on. I'd appreciate it if someone could give me a few hints or point me to good documentation. Output of lspci: 00:00.0 Host bridge: Intel Corporation Mobile 915GM/PM/GMS/910GML Express Processor to DRAM Controller (rev 04) 00:02.0 VGA compatible controller: Intel Corporation Mobile 915GM/GMS/910GML Express Graphics Controller (rev 04) 00:02.1 Display controller: Intel Corporation Mobile 915GM/GMS/910GML Express Graphics Controller (rev 04) 00:1b.0 Audio device: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) High Definition Audio Controller (rev 04) 00:1c.0 PCI bridge: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) PCI Express Port 1 (rev 04) 00:1c.1 PCI bridge: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) PCI Express Port 2 (rev 04) 00:1c.2 PCI bridge: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) PCI Express Port 3 (rev 04) 00:1d.0 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB UHCI #1 (rev 04) 00:1d.1 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB UHCI #2 (rev 04) 00:1d.2 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB UHCI #3 (rev 04) 00:1d.3 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB UHCI #4 (rev 04) 00:1d.7 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB2 EHCI Controller (rev 04) 00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev d4) 00:1f.0 ISA bridge: Intel Corporation 82801FBM (ICH6M) LPC Interface Bridge (rev 04) 00:1f.2 IDE interface: Intel Corporation 82801FBM (ICH6M) SATA Controller (rev 04) 00:1f.3 SMBus: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) SMBus Controller (rev 04) 03:00.0 Ethernet controller: Attansic Technology Corp. L2 100 Mbit Ethernet Adapter (rev a0) (The WLAN card should show up at 01:00.0, according to info found on the web). Thanks, Hans -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: What's needed for a PCIe card to be recognized?
Am Sat, 16 Feb 2008 14:39:46 -0800 schrieb Arjan van de Ven [EMAIL PROTECTED]: On Sat, 16 Feb 2008 22:59:32 +0100 Hans-Jürgen Koch [EMAIL PROTECTED] wrote: I'm playing around with a vanilla 2.6.25-rc1, adding patches to make it work on an Asus EeePC. That one has the problem that its Mini PCIe WLAN module doesn't show up in lspci. That brought up a few questions that I couldn't answer yet: How can they hide a PCIe card? What could be their motive to do that? How can I make it appear? go to the bios, enable the wireless card. that did it for me ;) It didn't for me. I tried all combinations (booting with/without WLAN enabled, enabling WLAN through /proc with/without pciehp loaded and so on). What kernel did you use, and which patches did you apply? Yes, I want to make it work, but I'd really like to understand what's going on there and what's behind it. Thanks, Hans -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Is there a "blackhole" /dev/null directory?
Am Thu, 14 Feb 2008 16:23:37 +0100 (CET) schrieb Jan Engelhardt <[EMAIL PROTECTED]>: > > On Feb 14 2008 16:19, Hans-Jürgen Koch wrote: > >> > >> Q: What if a program attempts to mkdir /dev/nullmnt/foo to just > >>create a file /dev/nullmnt/foo/barfile? > >> A: /dev/nullmnt/foo must continue to exist or be accepted for a > >> while, or perhaps for eternity. > > > >Well, the problem seems to be that a "directory" is not just data but > >also contains metadata. While it's easy to write data to /dev/null, > >you cannot simply discard metadata associated with a directory. So, > >such a "/dev/null-directory" would have to remember metadata (at > >least all created filenames including subdirectories) in the same > >way as other filesystems do. Only file _content_ can be discarded. > > Not even that. Suppose a userspace program (whose output you'd like > to discard) does: [...] Well, if an application wants to read back written data, you can never use such a thing, not even in simple cases where the existing /dev/null would be enough. > } > > >To be honest, I still cannot see many sensible usecases for that... > > I agree. Good :-) Hans -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Is there a "blackhole" /dev/null directory?
Am Thu, 14 Feb 2008 16:00:06 +0100 (CET) schrieb Jan Engelhardt <[EMAIL PROTECTED]>: > > On Feb 14 2008 10:46, Andi Kleen wrote: > >Jasper Bryant-Greene <[EMAIL PROTECTED]> writes: > >> > >> This could be done fairly trivially with FUSE, and IMHO is a good > >> use for FUSE because since you're just throwing most data away, > >> performance is not a concern. > > There is a much more interesting 'problem' with a "/dev/null > directory". > > Q: Why would you need such a directory? > A: To temporarily fool a program into believing it wrote something. > > Q: Should all files disappear? (e.g. "unlink after open") > A: Maybe not, programs may stat() the file right afterwards and >get confused by the "inexistence". > > Q: What if a program attempts to mkdir /dev/nullmnt/foo to just >create a file /dev/nullmnt/foo/barfile? > A: /dev/nullmnt/foo must continue to exist or be accepted for a while, >or perhaps for eternity. Well, the problem seems to be that a "directory" is not just data but also contains metadata. While it's easy to write data to /dev/null, you cannot simply discard metadata associated with a directory. So, such a "/dev/null-directory" would have to remember metadata (at least all created filenames including subdirectories) in the same way as other filesystems do. Only file _content_ can be discarded. To be honest, I still cannot see many sensible usecases for that... Thanks, Hans -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Is there a blackhole /dev/null directory?
Am Thu, 14 Feb 2008 16:00:06 +0100 (CET) schrieb Jan Engelhardt [EMAIL PROTECTED]: On Feb 14 2008 10:46, Andi Kleen wrote: Jasper Bryant-Greene [EMAIL PROTECTED] writes: This could be done fairly trivially with FUSE, and IMHO is a good use for FUSE because since you're just throwing most data away, performance is not a concern. There is a much more interesting 'problem' with a /dev/null directory. Q: Why would you need such a directory? A: To temporarily fool a program into believing it wrote something. Q: Should all files disappear? (e.g. unlink after open) A: Maybe not, programs may stat() the file right afterwards and get confused by the inexistence. Q: What if a program attempts to mkdir /dev/nullmnt/foo to just create a file /dev/nullmnt/foo/barfile? A: /dev/nullmnt/foo must continue to exist or be accepted for a while, or perhaps for eternity. Well, the problem seems to be that a directory is not just data but also contains metadata. While it's easy to write data to /dev/null, you cannot simply discard metadata associated with a directory. So, such a /dev/null-directory would have to remember metadata (at least all created filenames including subdirectories) in the same way as other filesystems do. Only file _content_ can be discarded. To be honest, I still cannot see many sensible usecases for that... Thanks, Hans -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Is there a blackhole /dev/null directory?
Am Thu, 14 Feb 2008 16:23:37 +0100 (CET) schrieb Jan Engelhardt [EMAIL PROTECTED]: On Feb 14 2008 16:19, Hans-Jürgen Koch wrote: Q: What if a program attempts to mkdir /dev/nullmnt/foo to just create a file /dev/nullmnt/foo/barfile? A: /dev/nullmnt/foo must continue to exist or be accepted for a while, or perhaps for eternity. Well, the problem seems to be that a directory is not just data but also contains metadata. While it's easy to write data to /dev/null, you cannot simply discard metadata associated with a directory. So, such a /dev/null-directory would have to remember metadata (at least all created filenames including subdirectories) in the same way as other filesystems do. Only file _content_ can be discarded. Not even that. Suppose a userspace program (whose output you'd like to discard) does: [...] Well, if an application wants to read back written data, you can never use such a thing, not even in simple cases where the existing /dev/null would be enough. } To be honest, I still cannot see many sensible usecases for that... I agree. Good :-) Hans -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Use menuconfig for CONFIG_UIO
Am Wed, 13 Feb 2008 23:28:19 +0100 schrieb Alessandro Guido <[EMAIL PROTECTED]>: > Signed-off-by: Alessandro Guido <[EMAIL PROTECTED]> Hi Alessandro, thanks, but this was already done by Denis Cheng: http://lkml.org/lkml/2008/2/2/60 I signed-off his patch, but AFAICS it hasn't been applied yet. BTW, please CC Greg Kroah-Hartman as well if you send patches for UIO. Thanks, Hans > > --- > > drivers/uio/Kconfig |8 ++-- > 1 files changed, 2 insertions(+), 6 deletions(-) > > diff --git a/drivers/uio/Kconfig b/drivers/uio/Kconfig > index b778ed7..dce4cae 100644 > --- a/drivers/uio/Kconfig > +++ b/drivers/uio/Kconfig > @@ -1,8 +1,6 @@ > -menu "Userspace I/O" > - depends on !S390 > - > -config UIO > +menuconfig UIO > tristate "Userspace I/O drivers" > + depends on !S390 > default n > help > Enable this to allow the userspace driver core code to be > @@ -25,5 +23,3 @@ config UIO_CIF > > To compile this driver as a module, choose M here: the > module will be called uio_cif. > - > -endmenu -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
UIO sysfs attributes broken in 2.6.25-rc1
In 2.6.25-rc1, there's a strange effect: Although the map attributes "addr" and "size" show up correctly: -r--r--r-- 1 root root 4096 2008-02-13 17:49 addr -r--r--r-- 1 root root 4096 2008-02-13 17:49 size you cannot access them, not even as root. Something like "cat addr" fails with a no-permission-error. It works fine in 2.6.24-rc8. This is probably related to this patch: http://lkml.org/lkml/2008/1/25/149 Unfortunately, I signed-off that one, too... I checked if all sysfs files appear, but didn't try to access them. Sorry. Greg, any ideas? Thanks, Hans -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
UIO sysfs attributes broken in 2.6.25-rc1
In 2.6.25-rc1, there's a strange effect: Although the map attributes addr and size show up correctly: -r--r--r-- 1 root root 4096 2008-02-13 17:49 addr -r--r--r-- 1 root root 4096 2008-02-13 17:49 size you cannot access them, not even as root. Something like cat addr fails with a no-permission-error. It works fine in 2.6.24-rc8. This is probably related to this patch: http://lkml.org/lkml/2008/1/25/149 Unfortunately, I signed-off that one, too... I checked if all sysfs files appear, but didn't try to access them. Sorry. Greg, any ideas? Thanks, Hans -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Use menuconfig for CONFIG_UIO
Am Wed, 13 Feb 2008 23:28:19 +0100 schrieb Alessandro Guido [EMAIL PROTECTED]: Signed-off-by: Alessandro Guido [EMAIL PROTECTED] Hi Alessandro, thanks, but this was already done by Denis Cheng: http://lkml.org/lkml/2008/2/2/60 I signed-off his patch, but AFAICS it hasn't been applied yet. BTW, please CC Greg Kroah-Hartman as well if you send patches for UIO. Thanks, Hans --- drivers/uio/Kconfig |8 ++-- 1 files changed, 2 insertions(+), 6 deletions(-) diff --git a/drivers/uio/Kconfig b/drivers/uio/Kconfig index b778ed7..dce4cae 100644 --- a/drivers/uio/Kconfig +++ b/drivers/uio/Kconfig @@ -1,8 +1,6 @@ -menu Userspace I/O - depends on !S390 - -config UIO +menuconfig UIO tristate Userspace I/O drivers + depends on !S390 default n help Enable this to allow the userspace driver core code to be @@ -25,5 +23,3 @@ config UIO_CIF To compile this driver as a module, choose M here: the module will be called uio_cif. - -endmenu -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] arch/arm/Kconfig: Make UIO available on ARM architecture
Am Thu, 7 Feb 2008 14:12:36 +0100 schrieb Hans-Jürgen Koch <[EMAIL PROTECTED]>: AFAICT, this patch was neither rejected nor applied. It generated a long thread about changing the whole ARM Kconfig system. I feel not qualified to do that, but I still want UIO available on ARM ;-) What can I do to help? Thanks, Hans > From: Hans J Koch <[EMAIL PROTECTED]> > To: linux-kernel@vger.kernel.org > Cc: [EMAIL PROTECTED] > Cc: Greg KH <[EMAIL PROTECTED]> > Subject: arch/arm/Kconfig: Make UIO available on ARM architecture > > Source drivers/uio/Kconfig to make UIO available in menuconfig if > ARCH=arm. > > Signed-off-by: Hans J Koch <[EMAIL PROTECTED]> > --- > arch/arm/Kconfig |2 ++ > 1 file changed, 2 insertions(+) > > Index: linux-2.6/arch/arm/Kconfig > === > --- linux-2.6.orig/arch/arm/Kconfig 2008-02-07 > 13:57:58.0 +0100 +++ linux-2.6/arch/arm/Kconfig > 2008-02-07 14:08:46.0 +0100 @@ -1159,6 +1159,8 @@ > > source "drivers/dca/Kconfig" > > +source "drivers/uio/Kconfig" > + > endmenu > > source "fs/Kconfig" > > -- > To unsubscribe from this list: send the line "unsubscribe > linux-kernel" in the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] arch/arm/Kconfig: Make UIO available on ARM architecture
Am Thu, 7 Feb 2008 14:12:36 +0100 schrieb Hans-Jürgen Koch [EMAIL PROTECTED]: AFAICT, this patch was neither rejected nor applied. It generated a long thread about changing the whole ARM Kconfig system. I feel not qualified to do that, but I still want UIO available on ARM ;-) What can I do to help? Thanks, Hans From: Hans J Koch [EMAIL PROTECTED] To: linux-kernel@vger.kernel.org Cc: [EMAIL PROTECTED] Cc: Greg KH [EMAIL PROTECTED] Subject: arch/arm/Kconfig: Make UIO available on ARM architecture Source drivers/uio/Kconfig to make UIO available in menuconfig if ARCH=arm. Signed-off-by: Hans J Koch [EMAIL PROTECTED] --- arch/arm/Kconfig |2 ++ 1 file changed, 2 insertions(+) Index: linux-2.6/arch/arm/Kconfig === --- linux-2.6.orig/arch/arm/Kconfig 2008-02-07 13:57:58.0 +0100 +++ linux-2.6/arch/arm/Kconfig 2008-02-07 14:08:46.0 +0100 @@ -1159,6 +1159,8 @@ source drivers/dca/Kconfig +source drivers/uio/Kconfig + endmenu source fs/Kconfig -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] USB: mark USB drivers as being GPL only
Am Fri, 08 Feb 2008 03:20:26 +1030 schrieb David Newall <[EMAIL PROTECTED]>: > Hans-Jürgen Koch wrote: > > Am Fri, 08 Feb 2008 01:01:24 +1030 > > schrieb David Newall <[EMAIL PROTECTED]>: > > > >>> It is not legally meaningless if copyright holders publicly state > >>> how they interpret the license and what they consider a license > >>> violation. > >>> > >> Copyright-holders' opinions mean nothing. In the particular case > >> of EXPORT_SYMBOL_GPL, copyright-holders' opinions are clearly > >> flawed because they make a statement about code that they do not > >> even know of. > >> > > > > What are you talking about? That's what every GPL-licensed library > > does. By putting a library under the GPL, the copyright-holder > > clearly states that he considers all programs that link against > > that library a derived work. And that he therefor requires these > > programs to be GPL, too, no matter if these programs already exist > > or not. > > Your last sentence, above: That is what EXPORT_SYMBOL_GPL attempts to > do. The place to state such a requirement is in the licence, not in > the source code. That is what I am talking about. I can't provide > you with software under a licence that says, "you are free to use > this software in any way you want," and later say, "oh, but in the > source code is tells you that you must take a break every two hours > of use." The license says that derivative work has to be GPL. Naturally, every sensible and practically usable license has gray areas. We know that and we live with that. But if there's room for interpretation, it's perfectly OK and helpful, if the copyright holder states what his interpretation is. If you use an EXPORT_SYMBOL_GPL symbol in non-GPL code, you know that the owner of the work doesn't agree with you license-wise. You had to cheat, e.g. by setting your MODULE_LICENCE to "GPL", and deliberately acted against the wishes of the copyright holder. Here in Germany, the GPL is enforceable, and such evidence will at least weaken your position. You won't get away with just saying you didn't know the copyright holder's position. Even printouts of some mails in this thread could be used to prove that you knew. IANAL, there hasn't been such a case AFAIK, and you might well leave the court unharmed. But can you (or anyone else) be sure? That's what it's all about. > > > >> Less there be further confusion: I am not an advocate for binary > >> drivers. > >> > > > > Nice to hear. So, if you're an advocate for open source drivers, > > why do you have problems making them GPL? > > > > I don't, but EXPORT_SYMBOL_GPL doesn't do that. It makes an ambit > claim, that might coerce an author into making a driver GPL, but might > also cause them to exit the Linux market. I have a problem with > driving manufacturers away from Linux. > > > Using a symbol from a library means linking to it, and that creates > > a derived work. Why should it be different when using kernel > > symbols? > I don't agree with your claim, but I'm going to explain something > else: The GPL doesn't require software that *uses* GPL code to itself > be GPL. Yes it does. Chapter 2b requires any part that is derived from a GPL work to be GPL, too. As you well know. Just to help you a bit: The only argument you could use is that a kernel module, even if it uses GPL'ed kernel code, is not a derivative work. You _might_ succeed with that interpretation, even before a German court, and even if it can be proven that you knew that the original author doesn't agree with you. Come on, try it! > It requires software that is *distributed* as part of a GPL > work to itself be GPL. At time of distribution, a kernel module is > neither using nor linked to the kernel. Oh, come on! You cannot turn a derived work into an original work just by distributing them seperately. Thanks, Hans -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] USB: mark USB drivers as being GPL only
Am Fri, 08 Feb 2008 01:01:24 +1030 schrieb David Newall <[EMAIL PROTECTED]>: > > It is not legally meaningless if copyright holders publicly state > > how they interpret the license and what they consider a license > > violation. > > Copyright-holders' opinions mean nothing. In the particular case of > EXPORT_SYMBOL_GPL, copyright-holders' opinions are clearly flawed > because they make a statement about code that they do not even know > of. What are you talking about? That's what every GPL-licensed library does. By putting a library under the GPL, the copyright-holder clearly states that he considers all programs that link against that library a derived work. And that he therefor requires these programs to be GPL, too, no matter if these programs already exist or not. The LGPL exists to allow the linked program to be non-GPL, remember? But the kernel is GPL, and not LGPL. And all these arguments that a kernel module does not "link" against the kernel code, is therefor not a derived work, and not bound by the GPL's restrictions, is just artificial nonsense. > It's equivalent to someone saying, "you are wrong," before you've > even thought about saying something. No. The GPL is about derived work. Derived code can obviously only appear _after_ the original work. > > > In the end, a court must decide, but lots of courts will at least > > look at the statements the copyright holders made over the years. > > > > > >> and politically damaging. > >> > > > > That's your opinion because it's damaging _your_ political goals. > > > > How ludicrous. That's as much a nonsense as EXPORT_SYMBOL_GPL. You > have no idea what my political goals are. > > Less there be further confusion: I am not an advocate for binary > drivers. Nice to hear. So, if you're an advocate for open source drivers, why do you have problems making them GPL? > That role is reserved for others. However that does not > stop me from criticising something that is obviously wrong. Stating > that only a GPL code is permitted to use a symbol contravenes the GPL, > because the GPL states no such requirement. Saying that it's > impossible for code that uses the symbol to be non-GPL (as has been > claimed) is a lie at worst, and a hope at best. Nobody claiming such > a thing could know it to be true. (It is not true.) Using a symbol from a library means linking to it, and that creates a derived work. Why should it be different when using kernel symbols? Thanks, Hans -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] USB: mark USB drivers as being GPL only
Am Thu, 07 Feb 2008 23:49:42 +1030 schrieb David Newall <[EMAIL PROTECTED]>: > Hans-Jürgen Koch wrote: > > If somebody prefers an other OS for license reasons only, let them. > > You cannot have open source software without open source license. > > If a company chooses Linux, they do it for technical reasons, and > > because they're able to modify the sources to suit their needs. > > Whatever advantages they see in Linux, they have to know that they > > have to accept its license. Just saying "I like your software but > > your license is stupid" is childish. Use CE instead. > > Nobody is saying "I don't like your licence." The issue is a > technical restriction in Linux that attempts to restrict non-GPL > software from running under it. What are you trying to say? You like the license but you're against enforcing it? > It's a bullish approach, technically incompetent, What's incompetent? > legally meaningless It is not legally meaningless if copyright holders publicly state how they interpret the license and what they consider a license violation. In the end, a court must decide, but lots of courts will at least look at the statements the copyright holders made over the years. > and politically damaging. That's your opinion because it's damaging _your_ political goals. Hans -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] arch/arm/Kconfig: Make UIO available on ARM architecture
Am Thu, 7 Feb 2008 13:02:23 + schrieb Russell King - ARM Linux <[EMAIL PROTECTED]>: > > Please place it in the same relative position in arch/arm/Kconfig as > it is found in drivers/Kconfig. Argh, sorry. Here's the correct version: From: Hans J Koch <[EMAIL PROTECTED]> To: linux-kernel@vger.kernel.org Cc: [EMAIL PROTECTED] Cc: Greg KH <[EMAIL PROTECTED]> Subject: arch/arm/Kconfig: Make UIO available on ARM architecture Source drivers/uio/Kconfig to make UIO available in menuconfig if ARCH=arm. Signed-off-by: Hans J Koch <[EMAIL PROTECTED]> --- arch/arm/Kconfig |2 ++ 1 file changed, 2 insertions(+) Index: linux-2.6/arch/arm/Kconfig === --- linux-2.6.orig/arch/arm/Kconfig 2008-02-07 13:57:58.0 +0100 +++ linux-2.6/arch/arm/Kconfig 2008-02-07 14:08:46.0 +0100 @@ -1159,6 +1159,8 @@ source "drivers/dca/Kconfig" +source "drivers/uio/Kconfig" + endmenu source "fs/Kconfig" -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] arch/arm/Kconfig: Make UIO available on ARM architecture
From: Hans J Koch <[EMAIL PROTECTED]> To: linux-kernel@vger.kernel.org Cc: [EMAIL PROTECTED] Cc: Greg KH <[EMAIL PROTECTED]> Subject: arch/arm/Kconfig: Make UIO available on ARM architecture Source drivers/uio/Kconfig to make UIO available in menuconfig if ARCH=arm. I already posted this a few months ago, but it got lost somehow. Signed-off-by: Hans J Koch <[EMAIL PROTECTED]> --- arch/arm/Kconfig |2 ++ 1 file changed, 2 insertions(+) Index: linux-2.6/arch/arm/Kconfig === --- linux-2.6.orig/arch/arm/Kconfig 2008-02-07 13:01:45.0 +0100 +++ linux-2.6/arch/arm/Kconfig 2008-02-07 13:18:22.0 +0100 @@ -1066,6 +1066,8 @@ config ARCH_SUSPEND_POSSIBLE def_bool y +source "drivers/uio/Kconfig" + endmenu source "net/Kconfig" -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] arch/arm/Kconfig: Make UIO available on ARM architecture
From: Hans J Koch [EMAIL PROTECTED] To: linux-kernel@vger.kernel.org Cc: [EMAIL PROTECTED] Cc: Greg KH [EMAIL PROTECTED] Subject: arch/arm/Kconfig: Make UIO available on ARM architecture Source drivers/uio/Kconfig to make UIO available in menuconfig if ARCH=arm. I already posted this a few months ago, but it got lost somehow. Signed-off-by: Hans J Koch [EMAIL PROTECTED] --- arch/arm/Kconfig |2 ++ 1 file changed, 2 insertions(+) Index: linux-2.6/arch/arm/Kconfig === --- linux-2.6.orig/arch/arm/Kconfig 2008-02-07 13:01:45.0 +0100 +++ linux-2.6/arch/arm/Kconfig 2008-02-07 13:18:22.0 +0100 @@ -1066,6 +1066,8 @@ config ARCH_SUSPEND_POSSIBLE def_bool y +source drivers/uio/Kconfig + endmenu source net/Kconfig -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] arch/arm/Kconfig: Make UIO available on ARM architecture
Am Thu, 7 Feb 2008 13:02:23 + schrieb Russell King - ARM Linux [EMAIL PROTECTED]: Please place it in the same relative position in arch/arm/Kconfig as it is found in drivers/Kconfig. Argh, sorry. Here's the correct version: From: Hans J Koch [EMAIL PROTECTED] To: linux-kernel@vger.kernel.org Cc: [EMAIL PROTECTED] Cc: Greg KH [EMAIL PROTECTED] Subject: arch/arm/Kconfig: Make UIO available on ARM architecture Source drivers/uio/Kconfig to make UIO available in menuconfig if ARCH=arm. Signed-off-by: Hans J Koch [EMAIL PROTECTED] --- arch/arm/Kconfig |2 ++ 1 file changed, 2 insertions(+) Index: linux-2.6/arch/arm/Kconfig === --- linux-2.6.orig/arch/arm/Kconfig 2008-02-07 13:57:58.0 +0100 +++ linux-2.6/arch/arm/Kconfig 2008-02-07 14:08:46.0 +0100 @@ -1159,6 +1159,8 @@ source drivers/dca/Kconfig +source drivers/uio/Kconfig + endmenu source fs/Kconfig -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] USB: mark USB drivers as being GPL only
Am Fri, 08 Feb 2008 03:20:26 +1030 schrieb David Newall [EMAIL PROTECTED]: Hans-Jürgen Koch wrote: Am Fri, 08 Feb 2008 01:01:24 +1030 schrieb David Newall [EMAIL PROTECTED]: It is not legally meaningless if copyright holders publicly state how they interpret the license and what they consider a license violation. Copyright-holders' opinions mean nothing. In the particular case of EXPORT_SYMBOL_GPL, copyright-holders' opinions are clearly flawed because they make a statement about code that they do not even know of. What are you talking about? That's what every GPL-licensed library does. By putting a library under the GPL, the copyright-holder clearly states that he considers all programs that link against that library a derived work. And that he therefor requires these programs to be GPL, too, no matter if these programs already exist or not. Your last sentence, above: That is what EXPORT_SYMBOL_GPL attempts to do. The place to state such a requirement is in the licence, not in the source code. That is what I am talking about. I can't provide you with software under a licence that says, you are free to use this software in any way you want, and later say, oh, but in the source code is tells you that you must take a break every two hours of use. The license says that derivative work has to be GPL. Naturally, every sensible and practically usable license has gray areas. We know that and we live with that. But if there's room for interpretation, it's perfectly OK and helpful, if the copyright holder states what his interpretation is. If you use an EXPORT_SYMBOL_GPL symbol in non-GPL code, you know that the owner of the work doesn't agree with you license-wise. You had to cheat, e.g. by setting your MODULE_LICENCE to GPL, and deliberately acted against the wishes of the copyright holder. Here in Germany, the GPL is enforceable, and such evidence will at least weaken your position. You won't get away with just saying you didn't know the copyright holder's position. Even printouts of some mails in this thread could be used to prove that you knew. IANAL, there hasn't been such a case AFAIK, and you might well leave the court unharmed. But can you (or anyone else) be sure? That's what it's all about. Less there be further confusion: I am not an advocate for binary drivers. Nice to hear. So, if you're an advocate for open source drivers, why do you have problems making them GPL? I don't, but EXPORT_SYMBOL_GPL doesn't do that. It makes an ambit claim, that might coerce an author into making a driver GPL, but might also cause them to exit the Linux market. I have a problem with driving manufacturers away from Linux. Using a symbol from a library means linking to it, and that creates a derived work. Why should it be different when using kernel symbols? I don't agree with your claim, but I'm going to explain something else: The GPL doesn't require software that *uses* GPL code to itself be GPL. Yes it does. Chapter 2b requires any part that is derived from a GPL work to be GPL, too. As you well know. Just to help you a bit: The only argument you could use is that a kernel module, even if it uses GPL'ed kernel code, is not a derivative work. You _might_ succeed with that interpretation, even before a German court, and even if it can be proven that you knew that the original author doesn't agree with you. Come on, try it! It requires software that is *distributed* as part of a GPL work to itself be GPL. At time of distribution, a kernel module is neither using nor linked to the kernel. Oh, come on! You cannot turn a derived work into an original work just by distributing them seperately. Thanks, Hans -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] USB: mark USB drivers as being GPL only
Am Thu, 07 Feb 2008 23:49:42 +1030 schrieb David Newall [EMAIL PROTECTED]: Hans-Jürgen Koch wrote: If somebody prefers an other OS for license reasons only, let them. You cannot have open source software without open source license. If a company chooses Linux, they do it for technical reasons, and because they're able to modify the sources to suit their needs. Whatever advantages they see in Linux, they have to know that they have to accept its license. Just saying I like your software but your license is stupid is childish. Use CE instead. Nobody is saying I don't like your licence. The issue is a technical restriction in Linux that attempts to restrict non-GPL software from running under it. What are you trying to say? You like the license but you're against enforcing it? It's a bullish approach, technically incompetent, What's incompetent? legally meaningless It is not legally meaningless if copyright holders publicly state how they interpret the license and what they consider a license violation. In the end, a court must decide, but lots of courts will at least look at the statements the copyright holders made over the years. and politically damaging. That's your opinion because it's damaging _your_ political goals. Hans -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] USB: mark USB drivers as being GPL only
Am Wed, 6 Feb 2008 21:34:49 +0100 schrieb Christer Weinigel <[EMAIL PROTECTED]>: > > I also think that my customers, that decided to keep their kernel > modules binary only, made a big mistake and have told them so. But I > still think it's better for the Linux community to be a bit soft on > such companies for a while. That has been done, hasn't it? > It's better to let them get away with it > for a while, and slowly try to convince them about the error of their > ways, rather than see them go with Windows CE or a BSD. If somebody prefers an other OS for license reasons only, let them. You cannot have open source software without open source license. If a company chooses Linux, they do it for technical reasons, and because they're able to modify the sources to suit their needs. Whatever advantages they see in Linux, they have to know that they have to accept its license. Just saying "I like your software but your license is stupid" is childish. Use CE instead. Thanks, Hans -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] USB: mark USB drivers as being GPL only
Am Wed, 6 Feb 2008 21:34:49 +0100 schrieb Christer Weinigel [EMAIL PROTECTED]: I also think that my customers, that decided to keep their kernel modules binary only, made a big mistake and have told them so. But I still think it's better for the Linux community to be a bit soft on such companies for a while. That has been done, hasn't it? It's better to let them get away with it for a while, and slowly try to convince them about the error of their ways, rather than see them go with Windows CE or a BSD. If somebody prefers an other OS for license reasons only, let them. You cannot have open source software without open source license. If a company chooses Linux, they do it for technical reasons, and because they're able to modify the sources to suit their needs. Whatever advantages they see in Linux, they have to know that they have to accept its license. Just saying I like your software but your license is stupid is childish. Use CE instead. Thanks, Hans -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Remove needless PCI_DEVICE_ID definition from uio_cif.c
From: Hans J. Koch <[EMAIL PROTECTED]> CC: Greg Kroah-Hartman <[EMAIL PROTECTED]> CC: Benedikt Spranger <[EMAIL PROTECTED]> Subject: Remove needless PCI_DEVICE_ID definition from uio_cif.c Date: Sun, 03 Feb 2008 01:37:58 +0100 Meanwhile, PCI_DEVICE_ID_PLX_9030 is defined in pci_ids.h, no need to define it again in the driver. Signed-off-by: Hans J. Koch <[EMAIL PROTECTED]> --- drivers/uio/uio_cif.c |4 1 file changed, 4 deletions(-) Index: linux-2.6.25-rc/drivers/uio/uio_cif.c === --- linux-2.6.25-rc.orig/drivers/uio/uio_cif.c 2008-02-03 01:29:55.0 +0100 +++ linux-2.6.25-rc/drivers/uio/uio_cif.c 2008-02-03 01:31:00.0 +0100 @@ -15,10 +15,6 @@ #include -#ifndef PCI_DEVICE_ID_PLX_9030 -#define PCI_DEVICE_ID_PLX_9030 0x9030 -#endif - #define PLX9030_INTCSR 0x4C #define INTSCR_INT1_ENABLE 0x01 #define INTSCR_INT1_STATUS 0x04 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/3] uio: mark pci_device_id hilscher_pci_ids[] __devinitdata
Am Sat, 2 Feb 2008 17:51:36 +0800
schrieb Denis Cheng <[EMAIL PROTECTED]>:
Makes sense.
> Signed-off-by: Denis Cheng <[EMAIL PROTECTED]>
Signed-off-by: Hans J. Koch <[EMAIL PROTECTED]>
> ---
> drivers/uio/uio_cif.c |2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/uio/uio_cif.c b/drivers/uio/uio_cif.c
> index 838bae4..4a5a97e 100644
> --- a/drivers/uio/uio_cif.c
> +++ b/drivers/uio/uio_cif.c
> @@ -116,7 +116,7 @@ static void hilscher_pci_remove(struct pci_dev
> *dev) kfree (info);
> }
>
> -static struct pci_device_id hilscher_pci_ids[] = {
> +static struct pci_device_id hilscher_pci_ids[] __devinitdata = {
> {
> .vendor = PCI_VENDOR_ID_PLX,
> .device = PCI_DEVICE_ID_PLX_9030,
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] uio: Kconfig improvements
Am Sat, 2 Feb 2008 17:51:35 +0800 schrieb Denis Cheng <[EMAIL PROTECTED]>: Agreed. > Signed-off-by: Denis Cheng <[EMAIL PROTECTED]> Signed-off-by: Hans J. Koch <[EMAIL PROTECTED]> > --- > drivers/uio/Kconfig | 10 +- > 1 files changed, 5 insertions(+), 5 deletions(-) > > diff --git a/drivers/uio/Kconfig b/drivers/uio/Kconfig > index b778ed7..d8ab7e6 100644 > --- a/drivers/uio/Kconfig > +++ b/drivers/uio/Kconfig > @@ -1,8 +1,6 @@ > -menu "Userspace I/O" > - depends on !S390 > - > -config UIO > +menuconfig UIO > tristate "Userspace I/O drivers" > + depends on !S390 > default n > help > Enable this to allow the userspace driver core code to be > @@ -13,6 +11,8 @@ config UIO > > If you don't know what to do here, say N. > > +if UIO > + > config UIO_CIF > tristate "generic Hilscher CIF Card driver" > depends on UIO && PCI > @@ -26,4 +26,4 @@ config UIO_CIF > To compile this driver as a module, choose M here: the > module will be called uio_cif. > > -endmenu > +endif -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] uio: Kconfig improvements
Am Sat, 2 Feb 2008 17:51:35 +0800 schrieb Denis Cheng [EMAIL PROTECTED]: Agreed. Signed-off-by: Denis Cheng [EMAIL PROTECTED] Signed-off-by: Hans J. Koch [EMAIL PROTECTED] --- drivers/uio/Kconfig | 10 +- 1 files changed, 5 insertions(+), 5 deletions(-) diff --git a/drivers/uio/Kconfig b/drivers/uio/Kconfig index b778ed7..d8ab7e6 100644 --- a/drivers/uio/Kconfig +++ b/drivers/uio/Kconfig @@ -1,8 +1,6 @@ -menu Userspace I/O - depends on !S390 - -config UIO +menuconfig UIO tristate Userspace I/O drivers + depends on !S390 default n help Enable this to allow the userspace driver core code to be @@ -13,6 +11,8 @@ config UIO If you don't know what to do here, say N. +if UIO + config UIO_CIF tristate generic Hilscher CIF Card driver depends on UIO PCI @@ -26,4 +26,4 @@ config UIO_CIF To compile this driver as a module, choose M here: the module will be called uio_cif. -endmenu +endif -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/3] uio: mark pci_device_id hilscher_pci_ids[] __devinitdata
Am Sat, 2 Feb 2008 17:51:36 +0800
schrieb Denis Cheng [EMAIL PROTECTED]:
Makes sense.
Signed-off-by: Denis Cheng [EMAIL PROTECTED]
Signed-off-by: Hans J. Koch [EMAIL PROTECTED]
---
drivers/uio/uio_cif.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/uio/uio_cif.c b/drivers/uio/uio_cif.c
index 838bae4..4a5a97e 100644
--- a/drivers/uio/uio_cif.c
+++ b/drivers/uio/uio_cif.c
@@ -116,7 +116,7 @@ static void hilscher_pci_remove(struct pci_dev
*dev) kfree (info);
}
-static struct pci_device_id hilscher_pci_ids[] = {
+static struct pci_device_id hilscher_pci_ids[] __devinitdata = {
{
.vendor = PCI_VENDOR_ID_PLX,
.device = PCI_DEVICE_ID_PLX_9030,
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Remove needless PCI_DEVICE_ID definition from uio_cif.c
From: Hans J. Koch [EMAIL PROTECTED] CC: Greg Kroah-Hartman [EMAIL PROTECTED] CC: Benedikt Spranger [EMAIL PROTECTED] Subject: Remove needless PCI_DEVICE_ID definition from uio_cif.c Date: Sun, 03 Feb 2008 01:37:58 +0100 Meanwhile, PCI_DEVICE_ID_PLX_9030 is defined in pci_ids.h, no need to define it again in the driver. Signed-off-by: Hans J. Koch [EMAIL PROTECTED] --- drivers/uio/uio_cif.c |4 1 file changed, 4 deletions(-) Index: linux-2.6.25-rc/drivers/uio/uio_cif.c === --- linux-2.6.25-rc.orig/drivers/uio/uio_cif.c 2008-02-03 01:29:55.0 +0100 +++ linux-2.6.25-rc/drivers/uio/uio_cif.c 2008-02-03 01:31:00.0 +0100 @@ -15,10 +15,6 @@ #include asm/io.h -#ifndef PCI_DEVICE_ID_PLX_9030 -#define PCI_DEVICE_ID_PLX_9030 0x9030 -#endif - #define PLX9030_INTCSR 0x4C #define INTSCR_INT1_ENABLE 0x01 #define INTSCR_INT1_STATUS 0x04 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Kernel is not booting.............
Am Mon, 28 Jan 2008 02:13:09 -0800 (PST) schrieb ManojKwal <[EMAIL PROTECTED]>: > > Greetings! > > System details: > Board: DTSP-ARM926Ej-S(new board) > Cross-toolchain: ELDK4.1 > Linux kernel: 2.6.18 > u-boot: 1.1.6 > > > I sucessfully port u-boot on board...But when i boot the > kernel it stuck in mid.The complete log is following: > > > > > DRM-Engine # bootm 0x8 > ## Booting image at 0008 ... >Image Name: Linux-2.6.18-DRM >Image Type: ARM Linux Kernel Image (uncompressed) >Data Size:623896 Bytes = 609.3 kB >Load Address: 0b008000 >Entry Point: 0b008000 >Verifying Checksum ... OK > OK > No initrd > ## Transferring control to Linux (at address 0b008000) ... > > Starting kernel ... > > Uncompressing Linux... done, > booting the kernel. > > > Linux version 2.6.18-DRM ([EMAIL PROTECTED]) (gcc version > 4.0.0 (DENX ELDK 4.1 4.0.0)) #34 Mon Jan 28 17:35:46 KST 2008 > CPU: ARM926EJ-S [41069263] revision 3 (ARMv5TEJ), cr=00053177 > Machine: DTSP > Memory policy: ECC disabled, Data cache writeback > CPU0: D VIVT write-back cache > CPU0: I cache: 32768 bytes, associativity 4, 32 byte lines, 256 sets > CPU0: D cache: 32768 bytes, associativity 4, 32 byte lines, 256 sets > Built 1 zonelists. Total pages: 16128 > Kernel command line: root=/dev/ram0 mem=63M initrd=0xd00,6M > ramdisk=16384 console=ttyS0,38400 init=/linuxrc > PID hash table entries: 256 (order: 8, 1024 bytes) > Console: colour dummy device 80x30 > [cskim]:serial_dtsp_set_termios > [cskim] : [baud,quot] = 38400, 26 > Dentry cache hash table entries: 8192 (order: 3, 32768 bytes) > Inode-cache hash table entries: 4096 (order: 2, 16384 bytes) > Memory: 63MB = 63MB total > Memory: 56448KB available (980K code, 248K data, 68K > init)-->"HERE KERNEL STUCK" > > > > > Can anybody help me? I am a beginer on this type of work In general, you should post questions concerning ARM systems on the linux-arm-kernel mailing list. See http://www.arm.linux.org.uk/ for details. And, as a hint, you should use a more descriptive subject for your mail ;-) Hans > > > > Thanks in advance! > > Regards > Manoj Khandelwal > Software Engineer > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Kernel is not booting.............
Am Mon, 28 Jan 2008 02:13:09 -0800 (PST) schrieb ManojKwal [EMAIL PROTECTED]: Greetings! System details: Board: DTSP-ARM926Ej-S(new board) Cross-toolchain: ELDK4.1 Linux kernel: 2.6.18 u-boot: 1.1.6 I sucessfully port u-boot on board...But when i boot the kernel it stuck in mid.The complete log is following: DRM-Engine # bootm 0x8 ## Booting image at 0008 ... Image Name: Linux-2.6.18-DRM Image Type: ARM Linux Kernel Image (uncompressed) Data Size:623896 Bytes = 609.3 kB Load Address: 0b008000 Entry Point: 0b008000 Verifying Checksum ... OK OK No initrd ## Transferring control to Linux (at address 0b008000) ... Starting kernel ... Uncompressing Linux... done, booting the kernel. Linux version 2.6.18-DRM ([EMAIL PROTECTED]) (gcc version 4.0.0 (DENX ELDK 4.1 4.0.0)) #34 Mon Jan 28 17:35:46 KST 2008 CPU: ARM926EJ-S [41069263] revision 3 (ARMv5TEJ), cr=00053177 Machine: DTSP Memory policy: ECC disabled, Data cache writeback CPU0: D VIVT write-back cache CPU0: I cache: 32768 bytes, associativity 4, 32 byte lines, 256 sets CPU0: D cache: 32768 bytes, associativity 4, 32 byte lines, 256 sets Built 1 zonelists. Total pages: 16128 Kernel command line: root=/dev/ram0 mem=63M initrd=0xd00,6M ramdisk=16384 console=ttyS0,38400 init=/linuxrc PID hash table entries: 256 (order: 8, 1024 bytes) Console: colour dummy device 80x30 [cskim]:serial_dtsp_set_termios [cskim] : [baud,quot] = 38400, 26 Dentry cache hash table entries: 8192 (order: 3, 32768 bytes) Inode-cache hash table entries: 4096 (order: 2, 16384 bytes) Memory: 63MB = 63MB total Memory: 56448KB available (980K code, 248K data, 68K init)--HERE KERNEL STUCK Can anybody help me? I am a beginer on this type of work In general, you should post questions concerning ARM systems on the linux-arm-kernel mailing list. See http://www.arm.linux.org.uk/ for details. And, as a hint, you should use a more descriptive subject for your mail ;-) Hans Thanks in advance! Regards Manoj Khandelwal Software Engineer -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 185/196] UIO: constify function pointer tables
Am Thu, 24 Jan 2008 23:33:34 -0800
schrieb Greg Kroah-Hartman <[EMAIL PROTECTED]>:
> From: Jan Engelhardt <[EMAIL PROTECTED]>
>
> Signed-off-by: Jan Engelhardt <[EMAIL PROTECTED]>
> Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
Signed-off-by: Hans J. Koch <[EMAIL PROTECTED]>
> ---
> drivers/uio/uio.c |4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/uio/uio.c b/drivers/uio/uio.c
> index 03b66fb..cc246fa 100644
> --- a/drivers/uio/uio.c
> +++ b/drivers/uio/uio.c
> @@ -39,7 +39,7 @@ struct uio_device {
>
> static int uio_major;
> static DEFINE_IDR(uio_idr);
> -static struct file_operations uio_fops;
> +static const struct file_operations uio_fops;
>
> /* UIO class infrastructure */
> static struct uio_class {
> @@ -508,7 +508,7 @@ static int uio_mmap(struct file *filep, struct
> vm_area_struct *vma) }
> }
>
> -static struct file_operations uio_fops = {
> +static const struct file_operations uio_fops = {
> .owner = THIS_MODULE,
> .open = uio_open,
> .release= uio_release,
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 185/196] UIO: constify function pointer tables
Am Thu, 24 Jan 2008 23:33:34 -0800
schrieb Greg Kroah-Hartman [EMAIL PROTECTED]:
From: Jan Engelhardt [EMAIL PROTECTED]
Signed-off-by: Jan Engelhardt [EMAIL PROTECTED]
Signed-off-by: Greg Kroah-Hartman [EMAIL PROTECTED]
Signed-off-by: Hans J. Koch [EMAIL PROTECTED]
---
drivers/uio/uio.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/uio/uio.c b/drivers/uio/uio.c
index 03b66fb..cc246fa 100644
--- a/drivers/uio/uio.c
+++ b/drivers/uio/uio.c
@@ -39,7 +39,7 @@ struct uio_device {
static int uio_major;
static DEFINE_IDR(uio_idr);
-static struct file_operations uio_fops;
+static const struct file_operations uio_fops;
/* UIO class infrastructure */
static struct uio_class {
@@ -508,7 +508,7 @@ static int uio_mmap(struct file *filep, struct
vm_area_struct *vma) }
}
-static struct file_operations uio_fops = {
+static const struct file_operations uio_fops = {
.owner = THIS_MODULE,
.open = uio_open,
.release= uio_release,
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 04/18] uio: nopage
Am Wed, 5 Dec 2007 11:10:42 +0100 schrieb Nick Piggin <[EMAIL PROTECTED]>: > On Wed, Dec 05, 2007 at 11:04:08AM +0100, Hans-Jürgen Koch wrote: > > Am Wed, 05 Dec 2007 18:15:51 +1100 > > schrieb [EMAIL PROTECTED]: > > > > > Convert uio from nopage to fault. > > > > > > Signed-off-by: Nick Piggin <[EMAIL PROTECTED]> > > > Cc: [EMAIL PROTECTED] > > > > Hi Nick, > > could you please add me to Cc: for UIO stuff: > > > > Cc: [EMAIL PROTECTED] > > Sure, I'll try to remember in future. It would be helpful if you could > add an entry to MAINTAINERS? Well, although I wrote a lot of UIO code and feel a bit responsible for it, I don't know if I can call myself an UIO maintainer. ATM, I think it's considered "driver core" and is therefore in Greg's domain. Thanks, Hans > > > > > The patch itself looks alright to me, but I didn't test with a real > > driver. > > > > Acked-by: Hans J Koch <[EMAIL PROTECTED]> > > Thanks, > Nick > > > -- > To unsubscribe from this list: send the line "unsubscribe > linux-kernel" in the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 04/18] uio: nopage
Am Wed, 05 Dec 2007 18:15:51 +1100
schrieb [EMAIL PROTECTED]:
> Convert uio from nopage to fault.
>
> Signed-off-by: Nick Piggin <[EMAIL PROTECTED]>
> Cc: [EMAIL PROTECTED]
Hi Nick,
could you please add me to Cc: for UIO stuff:
Cc: [EMAIL PROTECTED]
The patch itself looks alright to me, but I didn't test with a real
driver.
Acked-by: Hans J Koch <[EMAIL PROTECTED]>
Thanks,
Hans
> Cc: linux-kernel@vger.kernel.org
> ---
> drivers/uio/uio.c | 14 ++
> 1 file changed, 6 insertions(+), 8 deletions(-)
>
> Index: linux-2.6/drivers/uio/uio.c
> ===
> --- linux-2.6.orig/drivers/uio/uio.c
> +++ linux-2.6/drivers/uio/uio.c
> @@ -412,30 +412,28 @@ static void uio_vma_close(struct vm_area
> idev->vma_count--;
> }
>
> -static struct page *uio_vma_nopage(struct vm_area_struct *vma,
> -unsigned long address, int *type)
> +static int uio_vma_fault(struct vm_area_struct *vma, struct vm_fault
> *vmf) {
> struct uio_device *idev = vma->vm_private_data;
> - struct page* page = NOPAGE_SIGBUS;
> + struct page *page;
>
> int mi = uio_find_mem_index(vma);
> if (mi < 0)
> - return page;
> + return VM_FAULT_SIGBUS;
>
> if (idev->info->mem[mi].memtype == UIO_MEM_LOGICAL)
> page = virt_to_page(idev->info->mem[mi].addr);
> else
> page =
> vmalloc_to_page((void*)idev->info->mem[mi].addr); get_page(page);
> - if (type)
> - *type = VM_FAULT_MINOR;
> - return page;
> + vmf->page = page;
> + return 0;
> }
>
> static struct vm_operations_struct uio_vm_ops = {
> .open = uio_vma_open,
> .close = uio_vma_close,
> - .nopage = uio_vma_nopage,
> + .fault = uio_vma_fault,
> };
>
> static int uio_mmap_physical(struct vm_area_struct *vma)
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 04/18] uio: nopage
Am Wed, 05 Dec 2007 18:15:51 +1100
schrieb [EMAIL PROTECTED]:
Convert uio from nopage to fault.
Signed-off-by: Nick Piggin [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Hi Nick,
could you please add me to Cc: for UIO stuff:
Cc: [EMAIL PROTECTED]
The patch itself looks alright to me, but I didn't test with a real
driver.
Acked-by: Hans J Koch [EMAIL PROTECTED]
Thanks,
Hans
Cc: linux-kernel@vger.kernel.org
---
drivers/uio/uio.c | 14 ++
1 file changed, 6 insertions(+), 8 deletions(-)
Index: linux-2.6/drivers/uio/uio.c
===
--- linux-2.6.orig/drivers/uio/uio.c
+++ linux-2.6/drivers/uio/uio.c
@@ -412,30 +412,28 @@ static void uio_vma_close(struct vm_area
idev-vma_count--;
}
-static struct page *uio_vma_nopage(struct vm_area_struct *vma,
-unsigned long address, int *type)
+static int uio_vma_fault(struct vm_area_struct *vma, struct vm_fault
*vmf) {
struct uio_device *idev = vma-vm_private_data;
- struct page* page = NOPAGE_SIGBUS;
+ struct page *page;
int mi = uio_find_mem_index(vma);
if (mi 0)
- return page;
+ return VM_FAULT_SIGBUS;
if (idev-info-mem[mi].memtype == UIO_MEM_LOGICAL)
page = virt_to_page(idev-info-mem[mi].addr);
else
page =
vmalloc_to_page((void*)idev-info-mem[mi].addr); get_page(page);
- if (type)
- *type = VM_FAULT_MINOR;
- return page;
+ vmf-page = page;
+ return 0;
}
static struct vm_operations_struct uio_vm_ops = {
.open = uio_vma_open,
.close = uio_vma_close,
- .nopage = uio_vma_nopage,
+ .fault = uio_vma_fault,
};
static int uio_mmap_physical(struct vm_area_struct *vma)
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 04/18] uio: nopage
Am Wed, 5 Dec 2007 11:10:42 +0100 schrieb Nick Piggin [EMAIL PROTECTED]: On Wed, Dec 05, 2007 at 11:04:08AM +0100, Hans-Jürgen Koch wrote: Am Wed, 05 Dec 2007 18:15:51 +1100 schrieb [EMAIL PROTECTED]: Convert uio from nopage to fault. Signed-off-by: Nick Piggin [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Hi Nick, could you please add me to Cc: for UIO stuff: Cc: [EMAIL PROTECTED] Sure, I'll try to remember in future. It would be helpful if you could add an entry to MAINTAINERS? Well, although I wrote a lot of UIO code and feel a bit responsible for it, I don't know if I can call myself an UIO maintainer. ATM, I think it's considered driver core and is therefore in Greg's domain. Thanks, Hans The patch itself looks alright to me, but I didn't test with a real driver. Acked-by: Hans J Koch [EMAIL PROTECTED] Thanks, Nick -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] r8169 fix regression on ASUS motherboards (updated)
Am Thu, 8 Nov 2007 01:21:12 +0100 schrieb Francois Romieu <[EMAIL PROTECTED]>: > Mark Lord <[EMAIL PROTECTED]> : > [...] > > I've now received a couple of private emails from people reporting > > full success with this patch. > > Ok, I have pushed the patch below for Jeff to pull at korg. > > >From 1dd7681bc2ff171341ea5cae957f8ecb5c0c102e Mon Sep 17 00:00:00 > >2001 > From: Mark Lord <[EMAIL PROTECTED]> > Date: Thu, 8 Nov 2007 01:03:04 +0100 > Subject: [PATCH] r8169: revert > 7da97ec96a0934319c7fbedd3d38baf533e20640 (partly) > > Various symptoms depending on the .config options: > - the card stops working after some (short) time > - the card does not work at all > - the card disappears (nothing in lspci/dmesg) > > A real power-off is needed to recover the card. This patch fixes the same problem on my MSI board. > > Signed-off-by: Mark Lord <[EMAIL PROTECTED]> > Signed-off-by: Francois Romieu <[EMAIL PROTECTED]> Acked-by: Hans J. Koch <[EMAIL PROTECTED]> > --- > drivers/net/r8169.c |1 + > 1 files changed, 1 insertions(+), 0 deletions(-) > > diff --git a/drivers/net/r8169.c b/drivers/net/r8169.c > index 9dbab3f..a37cf82 100644 > --- a/drivers/net/r8169.c > +++ b/drivers/net/r8169.c > @@ -1328,6 +1328,7 @@ static void rtl_hw_phy_config(struct net_device > *dev) break; > case RTL_GIGA_MAC_VER_11: > case RTL_GIGA_MAC_VER_12: > + break; > case RTL_GIGA_MAC_VER_17: > rtl8168b_hw_phy_config(ioaddr); > break; - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: r8169: NFG in 2.6.24-rc2
Am Thu, 8 Nov 2007 08:52:56 +0100 schrieb Hans-Jürgen Koch <[EMAIL PROTECTED]>: > Am Wed, 07 Nov 2007 11:07:07 -0500 > schrieb Mark Lord <[EMAIL PROTECTED]>: > > > My ASUS board has one of these: > > > > 01:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. > > RTL8111/8168B PCI Express Gigabit Ethernet controller (rev 01) > > Subsystem: ASUSTeK Computer Inc. Unknown device 81aa Control: I/O+ > > Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- > > SERR- FastB2B- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast > > >TAbort- SERR- > >IRQ 16 Region 0: I/O ports at 9800 [size=256] > > Region 2: Memory at ff3ff000 (64-bit, non-prefetchable) > > [size=4K] Expansion ROM at ff3c [disabled] [size=128K] > > Capabilities: [40] Power Management version 2 > > Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=375mA > > PME(D0-,D1+,D2+,D3hot+,D3cold+) Status: D0 PME-Enable- DSel=0 > > DScale=0 PME- Capabilities: [48] Vital Product Data > > Capabilities: [50] Message Signalled Interrupts: Mask- > > 64bit+ Queue=0/1 Enable- Address: Data: > > Capabilities: [60] Express Endpoint IRQ 0 > > Device: Supported: MaxPayload 1024 bytes, PhantFunc > > 0, ExtTag+ Device: Latency L0s <1us, L1 unlimited > > Device: AtnBtn+ AtnInd+ PwrInd+ > > Device: Errors: Correctable- Non-Fatal- Fatal- > > Unsupported- Device: RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+ > > Device: MaxPayload 128 bytes, MaxReadReq 4096 bytes > > Link: Supported Speed 2.5Gb/s, Width x4, ASPM L0s, > > Port 0 Link: Latency L0s unlimited, L1 unlimited > > Link: ASPM Disabled RCB 64 bytes CommClk+ ExtSynch- > > Link: Speed 2.5Gb/s, Width x1 > > Capabilities: [84] Vendor Specific Information > > > > It works perfectly in 2.6.23. > > It does not work in 2.6.24-rc2. Dunno about -rc1 or earlier -git*. > > > > Without CONFIG_PCI_MSI, it works slightly, enough to ping it a > > couple of times, but it then dies when used for anything real: > > > > r8169 Gigabit Ethernet driver 2.2LK loaded > > r8169 :01:00.0: no MSI. Back to INTx. > > ... > > eth0: RTL8168b/8111b at 0xf884a000, 00:17:31:64:e0:bc, XID > > 3000 IRQ 16 ... > > r8169: eth0: link up > > ... > > kernel: NETDEV WATCHDOG: eth0: transmit timed out > > r8169: eth0: link up > > ... > > Not usable from this point on. > > Same problem here with a MSI K9AGM2 board. The problem appeared in > 2.6.24-rc1 (http://bugzilla.kernel.org/show_bug.cgi?id=9257). > > It seems to be better in -rc2, at least the chip is detected again. I > can assign an IP to that interface and bring it up, but no data > traffic is possible. After some tests in both directions, ifconfig > reports 157.6 KiB RX bytes, but TX bytes is 0, so sent packets seem > to disappear quite early. The patch just submitted by Francois Romieu fixes the problem. Thanks, Hans - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] r8169 fix regression on ASUS motherboards (updated)
Am Thu, 8 Nov 2007 01:21:12 +0100 schrieb Francois Romieu [EMAIL PROTECTED]: Mark Lord [EMAIL PROTECTED] : [...] I've now received a couple of private emails from people reporting full success with this patch. Ok, I have pushed the patch below for Jeff to pull at korg. From 1dd7681bc2ff171341ea5cae957f8ecb5c0c102e Mon Sep 17 00:00:00 2001 From: Mark Lord [EMAIL PROTECTED] Date: Thu, 8 Nov 2007 01:03:04 +0100 Subject: [PATCH] r8169: revert 7da97ec96a0934319c7fbedd3d38baf533e20640 (partly) Various symptoms depending on the .config options: - the card stops working after some (short) time - the card does not work at all - the card disappears (nothing in lspci/dmesg) A real power-off is needed to recover the card. This patch fixes the same problem on my MSI board. Signed-off-by: Mark Lord [EMAIL PROTECTED] Signed-off-by: Francois Romieu [EMAIL PROTECTED] Acked-by: Hans J. Koch [EMAIL PROTECTED] --- drivers/net/r8169.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/drivers/net/r8169.c b/drivers/net/r8169.c index 9dbab3f..a37cf82 100644 --- a/drivers/net/r8169.c +++ b/drivers/net/r8169.c @@ -1328,6 +1328,7 @@ static void rtl_hw_phy_config(struct net_device *dev) break; case RTL_GIGA_MAC_VER_11: case RTL_GIGA_MAC_VER_12: + break; case RTL_GIGA_MAC_VER_17: rtl8168b_hw_phy_config(ioaddr); break; - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: r8169: NFG in 2.6.24-rc2
Am Thu, 8 Nov 2007 08:52:56 +0100 schrieb Hans-Jürgen Koch [EMAIL PROTECTED]: Am Wed, 07 Nov 2007 11:07:07 -0500 schrieb Mark Lord [EMAIL PROTECTED]: My ASUS board has one of these: 01:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller (rev 01) Subsystem: ASUSTeK Computer Inc. Unknown device 81aa Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast TAbort- TAbort- MAbort- SERR- PERR- Interrupt: pin A routed to IRQ 16 Region 0: I/O ports at 9800 [size=256] Region 2: Memory at ff3ff000 (64-bit, non-prefetchable) [size=4K] Expansion ROM at ff3c [disabled] [size=128K] Capabilities: [40] Power Management version 2 Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=375mA PME(D0-,D1+,D2+,D3hot+,D3cold+) Status: D0 PME-Enable- DSel=0 DScale=0 PME- Capabilities: [48] Vital Product Data Capabilities: [50] Message Signalled Interrupts: Mask- 64bit+ Queue=0/1 Enable- Address: Data: Capabilities: [60] Express Endpoint IRQ 0 Device: Supported: MaxPayload 1024 bytes, PhantFunc 0, ExtTag+ Device: Latency L0s 1us, L1 unlimited Device: AtnBtn+ AtnInd+ PwrInd+ Device: Errors: Correctable- Non-Fatal- Fatal- Unsupported- Device: RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+ Device: MaxPayload 128 bytes, MaxReadReq 4096 bytes Link: Supported Speed 2.5Gb/s, Width x4, ASPM L0s, Port 0 Link: Latency L0s unlimited, L1 unlimited Link: ASPM Disabled RCB 64 bytes CommClk+ ExtSynch- Link: Speed 2.5Gb/s, Width x1 Capabilities: [84] Vendor Specific Information It works perfectly in 2.6.23. It does not work in 2.6.24-rc2. Dunno about -rc1 or earlier -git*. Without CONFIG_PCI_MSI, it works slightly, enough to ping it a couple of times, but it then dies when used for anything real: r8169 Gigabit Ethernet driver 2.2LK loaded r8169 :01:00.0: no MSI. Back to INTx. ... eth0: RTL8168b/8111b at 0xf884a000, 00:17:31:64:e0:bc, XID 3000 IRQ 16 ... r8169: eth0: link up ... kernel: NETDEV WATCHDOG: eth0: transmit timed out r8169: eth0: link up ... Not usable from this point on. Same problem here with a MSI K9AGM2 board. The problem appeared in 2.6.24-rc1 (http://bugzilla.kernel.org/show_bug.cgi?id=9257). It seems to be better in -rc2, at least the chip is detected again. I can assign an IP to that interface and bring it up, but no data traffic is possible. After some tests in both directions, ifconfig reports 157.6 KiB RX bytes, but TX bytes is 0, so sent packets seem to disappear quite early. The patch just submitted by Francois Romieu fixes the problem. Thanks, Hans - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: r8169: NFG in 2.6.24-rc2
Am Wed, 07 Nov 2007 11:07:07 -0500 schrieb Mark Lord <[EMAIL PROTECTED]>: > My ASUS board has one of these: > > 01:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. > RTL8111/8168B PCI Express Gigabit Ethernet controller (rev 01) > Subsystem: ASUSTeK Computer Inc. Unknown device 81aa Control: I/O+ > Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- > FastB2B- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast > >TAbort- SERR- >IRQ 16 Region 0: I/O ports at 9800 [size=256] > Region 2: Memory at ff3ff000 (64-bit, non-prefetchable) > [size=4K] Expansion ROM at ff3c [disabled] [size=128K] > Capabilities: [40] Power Management version 2 > Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=375mA > PME(D0-,D1+,D2+,D3hot+,D3cold+) Status: D0 PME-Enable- DSel=0 > DScale=0 PME- Capabilities: [48] Vital Product Data > Capabilities: [50] Message Signalled Interrupts: Mask- 64bit+ > Queue=0/1 Enable- Address: Data: > Capabilities: [60] Express Endpoint IRQ 0 > Device: Supported: MaxPayload 1024 bytes, PhantFunc > 0, ExtTag+ Device: Latency L0s <1us, L1 unlimited > Device: AtnBtn+ AtnInd+ PwrInd+ > Device: Errors: Correctable- Non-Fatal- Fatal- > Unsupported- Device: RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+ > Device: MaxPayload 128 bytes, MaxReadReq 4096 bytes > Link: Supported Speed 2.5Gb/s, Width x4, ASPM L0s, > Port 0 Link: Latency L0s unlimited, L1 unlimited > Link: ASPM Disabled RCB 64 bytes CommClk+ ExtSynch- > Link: Speed 2.5Gb/s, Width x1 > Capabilities: [84] Vendor Specific Information > > It works perfectly in 2.6.23. > It does not work in 2.6.24-rc2. Dunno about -rc1 or earlier -git*. > > Without CONFIG_PCI_MSI, it works slightly, enough to ping it a couple > of times, but it then dies when used for anything real: > > r8169 Gigabit Ethernet driver 2.2LK loaded > r8169 :01:00.0: no MSI. Back to INTx. > ... > eth0: RTL8168b/8111b at 0xf884a000, 00:17:31:64:e0:bc, XID > 3000 IRQ 16 ... > r8169: eth0: link up > ... > kernel: NETDEV WATCHDOG: eth0: transmit timed out > r8169: eth0: link up > ... > Not usable from this point on. Same problem here with a MSI K9AGM2 board. The problem appeared in 2.6.24-rc1 (http://bugzilla.kernel.org/show_bug.cgi?id=9257). It seems to be better in -rc2, at least the chip is detected again. I can assign an IP to that interface and bring it up, but no data traffic is possible. After some tests in both directions, ifconfig reports 157.6 KiB RX bytes, but TX bytes is 0, so sent packets seem to disappear quite early. Thanks, Hans - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: r8169: NFG in 2.6.24-rc2
Am Wed, 07 Nov 2007 11:07:07 -0500 schrieb Mark Lord [EMAIL PROTECTED]: My ASUS board has one of these: 01:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller (rev 01) Subsystem: ASUSTeK Computer Inc. Unknown device 81aa Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast TAbort- TAbort- MAbort- SERR- PERR- Interrupt: pin A routed to IRQ 16 Region 0: I/O ports at 9800 [size=256] Region 2: Memory at ff3ff000 (64-bit, non-prefetchable) [size=4K] Expansion ROM at ff3c [disabled] [size=128K] Capabilities: [40] Power Management version 2 Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=375mA PME(D0-,D1+,D2+,D3hot+,D3cold+) Status: D0 PME-Enable- DSel=0 DScale=0 PME- Capabilities: [48] Vital Product Data Capabilities: [50] Message Signalled Interrupts: Mask- 64bit+ Queue=0/1 Enable- Address: Data: Capabilities: [60] Express Endpoint IRQ 0 Device: Supported: MaxPayload 1024 bytes, PhantFunc 0, ExtTag+ Device: Latency L0s 1us, L1 unlimited Device: AtnBtn+ AtnInd+ PwrInd+ Device: Errors: Correctable- Non-Fatal- Fatal- Unsupported- Device: RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+ Device: MaxPayload 128 bytes, MaxReadReq 4096 bytes Link: Supported Speed 2.5Gb/s, Width x4, ASPM L0s, Port 0 Link: Latency L0s unlimited, L1 unlimited Link: ASPM Disabled RCB 64 bytes CommClk+ ExtSynch- Link: Speed 2.5Gb/s, Width x1 Capabilities: [84] Vendor Specific Information It works perfectly in 2.6.23. It does not work in 2.6.24-rc2. Dunno about -rc1 or earlier -git*. Without CONFIG_PCI_MSI, it works slightly, enough to ping it a couple of times, but it then dies when used for anything real: r8169 Gigabit Ethernet driver 2.2LK loaded r8169 :01:00.0: no MSI. Back to INTx. ... eth0: RTL8168b/8111b at 0xf884a000, 00:17:31:64:e0:bc, XID 3000 IRQ 16 ... r8169: eth0: link up ... kernel: NETDEV WATCHDOG: eth0: transmit timed out r8169: eth0: link up ... Not usable from this point on. Same problem here with a MSI K9AGM2 board. The problem appeared in 2.6.24-rc1 (http://bugzilla.kernel.org/show_bug.cgi?id=9257). It seems to be better in -rc2, at least the chip is detected again. I can assign an IP to that interface and bring it up, but no data traffic is possible. After some tests in both directions, ifconfig reports 157.6 KiB RX bytes, but TX bytes is 0, so sent packets seem to disappear quite early. Thanks, Hans - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] doc: add uio document to docbook compilation target
Am Sun, 14 Oct 2007 20:49:42 -0700 schrieb Randy Dunlap <[EMAIL PROTECTED]>: > On Mon, 15 Oct 2007 08:21:01 +0900 Satoru Takeuchi wrote: > > > Add uio document to DocBook compilation target. > > > > `make *docs' doesn't generate "The Userspace I/O HOWTO", the user > > space I/O document written in DocBook. True. Thanks for your help. > > > > Signed-off-by: Satoru Takeuchi <[EMAIL PROTECTED]> > > > > Index: linux/Documentation/DocBook/Makefile > > === > > --- linux.orig/Documentation/DocBook/Makefile 2007-10-12 > > 23:54:19.0 +0900 +++ > > linux/Documentation/DocBook/Makefile2007-10-12 > > 23:55:14.0 +0900 @@ -11,7 +11,7 @@ DOCBOOKS := wanbook.xml > > z8530book.xml mc procfs-guide.xml writing_usb_driver.xml \ > > kernel-api.xml filesystems.xml lsm.xml usb.xml \ gadget.xml > > libata.xml mtdnand.xml librs.xml rapidio.xml \ > > - genericirq.xml > > + genericirq.xml uio-howto.xml > > > > ### > > # The build process is as follows (targets): > > Hi, > > Thanks, looks reasonable, but patch does not apply cleanly to > mainline or -mm. (trivial to fix) > > --- > ~Randy Here's a version against mainline 2.6.23: Thanks, Hans -- Add uio document to DocBook compilation target. `make *docs' doesn't generate "The Userspace I/O HOWTO", the user space I/O document written in DocBook. Signed-off-by: Satoru Takeuchi <[EMAIL PROTECTED]> Signed-off-by: Hans J. Koch <[EMAIL PROTECTED]> Index: linux-2.6.23/Documentation/DocBook/Makefile === --- linux-2.6.23.orig/Documentation/DocBook/Makefile2007-10-15 08:05:35.0 +0200 +++ linux-2.6.23/Documentation/DocBook/Makefile 2007-10-15 08:07:56.0 +0200 @@ -11,7 +11,7 @@ procfs-guide.xml writing_usb_driver.xml \ kernel-api.xml filesystems.xml lsm.xml usb.xml \ gadget.xml libata.xml mtdnand.xml librs.xml rapidio.xml \ - genericirq.xml + genericirq.xml uio-howto.xml ### # The build process is as follows (targets): - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] doc: add uio document to docbook compilation target
Am Sun, 14 Oct 2007 20:49:42 -0700 schrieb Randy Dunlap [EMAIL PROTECTED]: On Mon, 15 Oct 2007 08:21:01 +0900 Satoru Takeuchi wrote: Add uio document to DocBook compilation target. `make *docs' doesn't generate The Userspace I/O HOWTO, the user space I/O document written in DocBook. True. Thanks for your help. Signed-off-by: Satoru Takeuchi [EMAIL PROTECTED] Index: linux/Documentation/DocBook/Makefile === --- linux.orig/Documentation/DocBook/Makefile 2007-10-12 23:54:19.0 +0900 +++ linux/Documentation/DocBook/Makefile2007-10-12 23:55:14.0 +0900 @@ -11,7 +11,7 @@ DOCBOOKS := wanbook.xml z8530book.xml mc procfs-guide.xml writing_usb_driver.xml \ kernel-api.xml filesystems.xml lsm.xml usb.xml \ gadget.xml libata.xml mtdnand.xml librs.xml rapidio.xml \ - genericirq.xml + genericirq.xml uio-howto.xml ### # The build process is as follows (targets): Hi, Thanks, looks reasonable, but patch does not apply cleanly to mainline or -mm. (trivial to fix) --- ~Randy Here's a version against mainline 2.6.23: Thanks, Hans -- Add uio document to DocBook compilation target. `make *docs' doesn't generate The Userspace I/O HOWTO, the user space I/O document written in DocBook. Signed-off-by: Satoru Takeuchi [EMAIL PROTECTED] Signed-off-by: Hans J. Koch [EMAIL PROTECTED] Index: linux-2.6.23/Documentation/DocBook/Makefile === --- linux-2.6.23.orig/Documentation/DocBook/Makefile2007-10-15 08:05:35.0 +0200 +++ linux-2.6.23/Documentation/DocBook/Makefile 2007-10-15 08:07:56.0 +0200 @@ -11,7 +11,7 @@ procfs-guide.xml writing_usb_driver.xml \ kernel-api.xml filesystems.xml lsm.xml usb.xml \ gadget.xml libata.xml mtdnand.xml librs.xml rapidio.xml \ - genericirq.xml + genericirq.xml uio-howto.xml ### # The build process is as follows (targets): - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
2.6.23-rc8-mm2: Fix a compile problem in macb.c
Compiling macb.c fails because the type of parameter 2 of macb_poll()
was changed from int* to int. Furthermore, a local variable was removed
but was still used inside the function. This patch fixes it.
Signed-off-by: Hans J. Koch <[EMAIL PROTECTED]>
---
Index: linux-2.6.23-rc/drivers/net/macb.c
===
--- linux-2.6.23-rc.orig/drivers/net/macb.c 2007-09-27 12:55:21.0
+0200
+++ linux-2.6.23-rc/drivers/net/macb.c 2007-09-27 13:00:28.0 +0200
@@ -492,7 +492,7 @@
}
dev_dbg(>pdev->dev, "poll: status = %08lx, budget = %d\n",
- (unsigned long)status, *budget);
+ (unsigned long)status, budget);
if (!(status & MACB_BIT(REC))) {
dev_warn(>pdev->dev,
@@ -503,7 +503,7 @@
}
work_done = macb_rx(bp, budget);
- if (work_done < orig_budget)
+ if (work_done < budget)
netif_rx_complete(dev, napi);
/*
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
2.6.23-rc8-mm2: Fix a compile problem in macb.c
Compiling macb.c fails because the type of parameter 2 of macb_poll()
was changed from int* to int. Furthermore, a local variable was removed
but was still used inside the function. This patch fixes it.
Signed-off-by: Hans J. Koch [EMAIL PROTECTED]
---
Index: linux-2.6.23-rc/drivers/net/macb.c
===
--- linux-2.6.23-rc.orig/drivers/net/macb.c 2007-09-27 12:55:21.0
+0200
+++ linux-2.6.23-rc/drivers/net/macb.c 2007-09-27 13:00:28.0 +0200
@@ -492,7 +492,7 @@
}
dev_dbg(bp-pdev-dev, poll: status = %08lx, budget = %d\n,
- (unsigned long)status, *budget);
+ (unsigned long)status, budget);
if (!(status MACB_BIT(REC))) {
dev_warn(bp-pdev-dev,
@@ -503,7 +503,7 @@
}
work_done = macb_rx(bp, budget);
- if (work_done orig_budget)
+ if (work_done budget)
netif_rx_complete(dev, napi);
/*
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Wasting our Freedom
Am Montag 17 September 2007 15:15 schrieb Jason Dixon: > > The GPL places additional restrictions on code. It is therefore less > free than the BSD. > > Free code + restrictions = non-free code. The legal restriction that people must not enter your house uninvited by smashing the door adds to your freedom, don't you think so? Hans - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Wasting our Freedom
Am Montag 17 September 2007 15:15 schrieb Jason Dixon: The GPL places additional restrictions on code. It is therefore less free than the BSD. Free code + restrictions = non-free code. The legal restriction that people must not enter your house uninvited by smashing the door adds to your freedom, don't you think so? Hans - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Fix a lock problem in generic phy code
Am Donnerstag 13 September 2007 schrieb Jeff Garzik: > Hans-Jürgen Koch wrote: > > Lock debugging finds a problem in phy.c and phy_device.c, > > this patch fixes it. Tested on an AT91SAM9263-EK board, > > kernel 2.6.23-rc4. > > > > Signed-off-by: Hans J. Koch <[EMAIL PROTECTED]> > > applied Thanks! Andrew applied it to -mm, too. Hans - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Fix a lock problem in generic phy code
Am Donnerstag 13 September 2007 schrieb Jeff Garzik: Hans-Jürgen Koch wrote: Lock debugging finds a problem in phy.c and phy_device.c, this patch fixes it. Tested on an AT91SAM9263-EK board, kernel 2.6.23-rc4. Signed-off-by: Hans J. Koch [EMAIL PROTECTED] applied Thanks! Andrew applied it to -mm, too. Hans - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH resend] Fix a lock problem in generic phy code
Am Montag 10 September 2007 schrieb Herbert Xu: > Hans-J??rgen Koch <[EMAIL PROTECTED]> wrote: > > The following patch fixes it. Tested on an AT91SAM9263-EK board, kernel > > 2.6.23-rc4 and -rc3-mm1. > > Could you please audit all instances of physdev->lock and add > _bh where necessary? I can see that at least phys_stop also > needs the _bh. I think the patch does all that's necessary. At least, there're no error messages in the logs anymore. I didn't check if there's an error on unload, though. > > We should also consider whether it makes sense to move the > timer into a work queue. Somebody who's more involved in that PHY stuff should probably do that. I'm on holidays, sitting in a hotel room, and will probably not have the time to have a deeper look into that. Thanks, Hans - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH resend] Fix a lock problem in generic phy code
Am Montag 10 September 2007 schrieb Herbert Xu: Hans-J??rgen Koch [EMAIL PROTECTED] wrote: The following patch fixes it. Tested on an AT91SAM9263-EK board, kernel 2.6.23-rc4 and -rc3-mm1. Could you please audit all instances of physdev-lock and add _bh where necessary? I can see that at least phys_stop also needs the _bh. I think the patch does all that's necessary. At least, there're no error messages in the logs anymore. I didn't check if there's an error on unload, though. We should also consider whether it makes sense to move the timer into a work queue. Somebody who's more involved in that PHY stuff should probably do that. I'm on holidays, sitting in a hotel room, and will probably not have the time to have a deeper look into that. Thanks, Hans - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH resend] Fix a lock problem in generic phy code
I already sent this patch on August, 31. I never got an answer, so here it
is again.
Lock debugging finds a problem in phy.c and phy_device.c:
[ 3.42] =
[ 3.42] [ INFO: inconsistent lock state ]
[ 3.42] 2.6.23-rc3-mm1 #21
[ 3.42] -
[ 3.42] inconsistent {softirq-on-W} -> {in-softirq-W} usage.
[ 3.42] swapper/1 [HC0[0]:SC1[1]:HE1:SE0] takes:
[ 3.42] (>lock){-+..}, at: [] phy_timer+0x1c/0x4c8
[ 3.42] {softirq-on-W} state was registered at:
[ 3.42] [] lock_acquire+0x94/0xac
[ 3.42] [] _spin_lock+0x40/0x50
[ 3.42] [] phy_probe+0x40/0x88
[ 3.42] [] phy_attach+0xc8/0xfc
[ 3.42] [] phy_connect+0x1c/0x58
[ 3.42] [] macb_probe+0x4fc/0x5bc
[ 3.42] [] platform_drv_probe+0x20/0x24
[ 3.42] [] driver_probe_device+0xb0/0x1bc
[ 3.42] [] __driver_attach+0xe4/0xe8
[ 3.42] [] bus_for_each_dev+0x54/0x80
[ 3.42] [] driver_attach+0x20/0x28
[ 3.42] [] bus_add_driver+0x84/0x1e0
[ 3.42] [] driver_register+0x54/0x90
[ 3.42] [] platform_driver_register+0x6c/0x88
[ 3.42] [] macb_init+0x14/0x1c
[ 3.42] [] kernel_init+0x9c/0x2b4
[ 3.42] [] do_exit+0x0/0x8e8
[ 3.42] irq event stamp: 115025
[ 3.42] hardirqs last enabled at (115025): []
_spin_unlock_irq+0x30/0x60
[ 3.42] hardirqs last disabled at (115024): []
_spin_lock_irq+0x28/0x60
[ 3.42] softirqs last enabled at (114999): []
__do_softirq+0xfc/0x12c
[ 3.42] softirqs last disabled at (115022): []
irq_exit+0x68/0x7c
[ 3.42]
[ 3.42] other info that might help us debug this:
[ 3.42] no locks held by swapper/1.
[ 3.42]
[ 3.42] stack backtrace:
[ 3.42] [] (dump_stack+0x0/0x14) from []
(print_usage_bug+0x120/0x150)
[ 3.42] [] (print_usage_bug+0x0/0x150) from []
(mark_lock+0x574/0x6bc)
[ 3.42] [] (mark_lock+0x0/0x6bc) from []
(__lock_acquire+0x4d0/0x1198)
[ 3.42] [] (__lock_acquire+0x0/0x1198) from []
(lock_acquire+0x94/0xac)
[ 3.42] [] (lock_acquire+0x0/0xac) from []
(_spin_lock+0x40/0x50)
[ 3.42] [] (_spin_lock+0x0/0x50) from []
(phy_timer+0x1c/0x4c8)
[ 3.42] r5:c098a800 r4:0104
[ 3.42] [] (phy_timer+0x0/0x4c8) from []
(run_timer_softirq+0x1a0/0x218)
[ 3.42] r7:c081ddd0 r6:c0331e80 r5:c098aa50 r4:0104
[ 3.42] [] (run_timer_softirq+0x0/0x218) from []
(__do_softirq+0x94/0x12c)
[ 3.42] [] (__do_softirq+0x0/0x12c) from []
(irq_exit+0x68/0x7c)
[ 3.42] [] (irq_exit+0x0/0x7c) from []
(__exception_text_start+0x60/0x74)
[ 3.42] r4:0001
[ 3.42] [] (__exception_text_start+0x0/0x74) from []
(__irq_svc+0x48/0x74)
[ 3.42] Exception stack(0xc081de70 to 0xc081deb8)
[ 3.42] de60: c030b2a8 c081a800
6013 c081c000
[ 3.42] de80: c032db40 c081dee0 c032d758 c081dece 0012 c030b398
0034 c081df2c
[ 3.42] dea0: c081deb8 c081deb8 c003d6f0 c003d6f8 6013
[ 3.42] r7:0003 r6:0001 r5:fefff000 r4:
[ 3.42] [] (vprintk+0x0/0x474) from []
(printk+0x28/0x30)
[ 3.42] [] (printk+0x0/0x30) from []
(sock_register+0x64/0x84)
[ 3.42] r3:0001 r2:0002 r1:0001 r0:c02e4c88
[ 3.42] [] (sock_register+0x0/0x84) from []
(af_unix_init+0x40/0x88)
[ 3.42] r5: r4:
[ 3.42] [] (af_unix_init+0x0/0x88) from []
(kernel_init+0x9c/0x2b4)
[ 3.42] r4:
[ 3.42] [] (kernel_init+0x0/0x2b4) from []
(do_exit+0x0/0x8e8)
The following patch fixes it. Tested on an AT91SAM9263-EK board, kernel
2.6.23-rc4 and -rc3-mm1.
Signed-off-by: Hans J. Koch <[EMAIL PROTECTED]>
---
Index: linux-2.6.23-rc/drivers/net/phy/phy_device.c
===
--- linux-2.6.23-rc.orig/drivers/net/phy/phy_device.c 2007-08-31
14:07:47.0 +0200
+++ linux-2.6.23-rc/drivers/net/phy/phy_device.c2007-08-31
14:08:22.0 +0200
@@ -644,7 +644,7 @@
if (!(phydrv->flags & PHY_HAS_INTERRUPT))
phydev->irq = PHY_POLL;
- spin_lock(>lock);
+ spin_lock_bh(>lock);
/* Start out supporting everything. Eventually,
* a controller will attach, and may modify one
@@ -658,7 +658,7 @@
if (phydev->drv->probe)
err = phydev->drv->probe(phydev);
- spin_unlock(>lock);
+ spin_unlock_bh(>lock);
return err;
Index: linux-2.6.23-rc/drivers/net/phy/phy.c
===
--- linux-2.6.23-rc.orig/drivers/net/phy/phy.c 2007-08-31 14:15:20.0
+0200
+++ linux-2.6.23-rc/drivers/net/phy/phy.c 2007-08-31 14:15:43.0
+0200
@@ -755,7 +755,7 @@
*/
void phy_start(struct phy_device *phydev)
{
-
[PATCH resend] Fix a lock problem in generic phy code
I already sent this patch on August, 31. I never got an answer, so here it
is again.
Lock debugging finds a problem in phy.c and phy_device.c:
[ 3.42] =
[ 3.42] [ INFO: inconsistent lock state ]
[ 3.42] 2.6.23-rc3-mm1 #21
[ 3.42] -
[ 3.42] inconsistent {softirq-on-W} - {in-softirq-W} usage.
[ 3.42] swapper/1 [HC0[0]:SC1[1]:HE1:SE0] takes:
[ 3.42] (dev-lock){-+..}, at: [c017da1c] phy_timer+0x1c/0x4c8
[ 3.42] {softirq-on-W} state was registered at:
[ 3.42] [c006021c] lock_acquire+0x94/0xac
[ 3.42] [c026423c] _spin_lock+0x40/0x50
[ 3.42] [c017e2b4] phy_probe+0x40/0x88
[ 3.42] [c017e60c] phy_attach+0xc8/0xfc
[ 3.42] [c017e6c4] phy_connect+0x1c/0x58
[ 3.42] [c017fc44] macb_probe+0x4fc/0x5bc
[ 3.42] [c0177b44] platform_drv_probe+0x20/0x24
[ 3.42] [c0176210] driver_probe_device+0xb0/0x1bc
[ 3.42] [c01764dc] __driver_attach+0xe4/0xe8
[ 3.42] [c017550c] bus_for_each_dev+0x54/0x80
[ 3.42] [c0176074] driver_attach+0x20/0x28
[ 3.42] [c01758d4] bus_add_driver+0x84/0x1e0
[ 3.42] [c0176708] driver_register+0x54/0x90
[ 3.42] [c0177de0] platform_driver_register+0x6c/0x88
[ 3.42] [c00167ec] macb_init+0x14/0x1c
[ 3.42] [c00087e4] kernel_init+0x9c/0x2b4
[ 3.42] [c0040338] do_exit+0x0/0x8e8
[ 3.42] irq event stamp: 115025
[ 3.42] hardirqs last enabled at (115025): [c0264958]
_spin_unlock_irq+0x30/0x60
[ 3.42] hardirqs last disabled at (115024): [c02642c8]
_spin_lock_irq+0x28/0x60
[ 3.42] softirqs last enabled at (114999): [c0042910]
__do_softirq+0xfc/0x12c
[ 3.42] softirqs last disabled at (115022): [c0042ee8]
irq_exit+0x68/0x7c
[ 3.42]
[ 3.42] other info that might help us debug this:
[ 3.42] no locks held by swapper/1.
[ 3.42]
[ 3.42] stack backtrace:
[ 3.42] [c0028af4] (dump_stack+0x0/0x14) from [c005d8e4]
(print_usage_bug+0x120/0x150)
[ 3.42] [c005d7c4] (print_usage_bug+0x0/0x150) from [c005e5e8]
(mark_lock+0x574/0x6bc)
[ 3.42] [c005e074] (mark_lock+0x0/0x6bc) from [c005f4c0]
(__lock_acquire+0x4d0/0x1198)
[ 3.42] [c005eff0] (__lock_acquire+0x0/0x1198) from [c006021c]
(lock_acquire+0x94/0xac)
[ 3.42] [c0060188] (lock_acquire+0x0/0xac) from [c026423c]
(_spin_lock+0x40/0x50)
[ 3.42] [c02641fc] (_spin_lock+0x0/0x50) from [c017da1c]
(phy_timer+0x1c/0x4c8)
[ 3.42] r5:c098a800 r4:0104
[ 3.42] [c017da00] (phy_timer+0x0/0x4c8) from [c0046ee4]
(run_timer_softirq+0x1a0/0x218)
[ 3.42] r7:c081ddd0 r6:c0331e80 r5:c098aa50 r4:0104
[ 3.42] [c0046d44] (run_timer_softirq+0x0/0x218) from [c00428a8]
(__do_softirq+0x94/0x12c)
[ 3.42] [c0042814] (__do_softirq+0x0/0x12c) from [c0042ee8]
(irq_exit+0x68/0x7c)
[ 3.42] [c0042e80] (irq_exit+0x0/0x7c) from [c0023060]
(__exception_text_start+0x60/0x74)
[ 3.42] r4:0001
[ 3.42] [c0023000] (__exception_text_start+0x0/0x74) from [c0023b28]
(__irq_svc+0x48/0x74)
[ 3.42] Exception stack(0xc081de70 to 0xc081deb8)
[ 3.42] de60: c030b2a8 c081a800
6013 c081c000
[ 3.42] de80: c032db40 c081dee0 c032d758 c081dece 0012 c030b398
0034 c081df2c
[ 3.42] dea0: c081deb8 c081deb8 c003d6f0 c003d6f8 6013
[ 3.42] r7:0003 r6:0001 r5:fefff000 r4:
[ 3.42] [c003d494] (vprintk+0x0/0x474) from [c003d930]
(printk+0x28/0x30)
[ 3.42] [c003d908] (printk+0x0/0x30) from [c01d3558]
(sock_register+0x64/0x84)
[ 3.42] r3:0001 r2:0002 r1:0001 r0:c02e4c88
[ 3.42] [c01d34f4] (sock_register+0x0/0x84) from [c001b7bc]
(af_unix_init+0x40/0x88)
[ 3.42] r5: r4:
[ 3.42] [c001b77c] (af_unix_init+0x0/0x88) from [c00087e4]
(kernel_init+0x9c/0x2b4)
[ 3.42] r4:
[ 3.42] [c0008748] (kernel_init+0x0/0x2b4) from [c0040338]
(do_exit+0x0/0x8e8)
The following patch fixes it. Tested on an AT91SAM9263-EK board, kernel
2.6.23-rc4 and -rc3-mm1.
Signed-off-by: Hans J. Koch [EMAIL PROTECTED]
---
Index: linux-2.6.23-rc/drivers/net/phy/phy_device.c
===
--- linux-2.6.23-rc.orig/drivers/net/phy/phy_device.c 2007-08-31
14:07:47.0 +0200
+++ linux-2.6.23-rc/drivers/net/phy/phy_device.c2007-08-31
14:08:22.0 +0200
@@ -644,7 +644,7 @@
if (!(phydrv-flags PHY_HAS_INTERRUPT))
phydev-irq = PHY_POLL;
- spin_lock(phydev-lock);
+ spin_lock_bh(phydev-lock);
/* Start out supporting everything. Eventually,
* a controller will attach, and may modify one
@@ -658,7 +658,7 @@
if (phydev-drv-probe)
err = phydev-drv-probe(phydev);
-
Re: [PATCH] Fix a lock problem in generic phy code
Am Freitag 31 August 2007 schrieb Hans-Jürgen Koch:
> Lock debugging finds a problem in phy.c and phy_device.c,
> this patch fixes it. Tested on an AT91SAM9263-EK board,
> kernel 2.6.23-rc4.
FYI, here's the log message without that patch:
[3.42] =
[3.42] [ INFO: inconsistent lock state ]
[3.42] 2.6.23-rc3-mm1 #21
[3.42] -
[3.42] inconsistent {softirq-on-W} -> {in-softirq-W} usage.
[3.42] swapper/1 [HC0[0]:SC1[1]:HE1:SE0] takes:
[3.42] (>lock){-+..}, at: [] phy_timer+0x1c/0x4c8
[3.42] {softirq-on-W} state was registered at:
[3.42] [] lock_acquire+0x94/0xac
[3.42] [] _spin_lock+0x40/0x50
[3.42] [] phy_probe+0x40/0x88
[3.42] [] phy_attach+0xc8/0xfc
[3.42] [] phy_connect+0x1c/0x58
[3.42] [] macb_probe+0x4fc/0x5bc
[3.42] [] platform_drv_probe+0x20/0x24
[3.42] [] driver_probe_device+0xb0/0x1bc
[3.42] [] __driver_attach+0xe4/0xe8
[3.42] [] bus_for_each_dev+0x54/0x80
[3.42] [] driver_attach+0x20/0x28
[3.42] [] bus_add_driver+0x84/0x1e0
[3.42] [] driver_register+0x54/0x90
[3.42] [] platform_driver_register+0x6c/0x88
[3.42] [] macb_init+0x14/0x1c
[3.42] [] kernel_init+0x9c/0x2b4
[3.42] [] do_exit+0x0/0x8e8
[3.42] irq event stamp: 115025
[3.42] hardirqs last enabled at (115025): []
_spin_unlock_irq+0x30/0x60
[3.42] hardirqs last disabled at (115024): []
_spin_lock_irq+0x28/0x60
[3.42] softirqs last enabled at (114999): []
__do_softirq+0xfc/0x12c
[3.42] softirqs last disabled at (115022): []
irq_exit+0x68/0x7c
[3.42]
[3.42] other info that might help us debug this:
[3.42] no locks held by swapper/1.
[3.42]
[3.42] stack backtrace:
[3.42] [] (dump_stack+0x0/0x14) from []
(print_usage_bug+0x120/0x150)
[3.42] [] (print_usage_bug+0x0/0x150) from []
(mark_lock+0x574/0x6bc)
[3.42] [] (mark_lock+0x0/0x6bc) from []
(__lock_acquire+0x4d0/0x1198)
[3.42] [] (__lock_acquire+0x0/0x1198) from []
(lock_acquire+0x94/0xac)
[3.42] [] (lock_acquire+0x0/0xac) from []
(_spin_lock+0x40/0x50)
[3.42] [] (_spin_lock+0x0/0x50) from []
(phy_timer+0x1c/0x4c8)
[3.42] r5:c098a800 r4:0104
[3.42] [] (phy_timer+0x0/0x4c8) from []
(run_timer_softirq+0x1a0/0x218)
[3.42] r7:c081ddd0 r6:c0331e80 r5:c098aa50 r4:0104
[3.42] [] (run_timer_softirq+0x0/0x218) from []
(__do_softirq+0x94/0x12c)
[3.42] [] (__do_softirq+0x0/0x12c) from []
(irq_exit+0x68/0x7c)
[3.42] [] (irq_exit+0x0/0x7c) from []
(__exception_text_start+0x60/0x74)
[3.42] r4:0001
[3.42] [] (__exception_text_start+0x0/0x74) from []
(__irq_svc+0x48/0x74)
[3.42] Exception stack(0xc081de70 to 0xc081deb8)
[3.42] de60: c030b2a8 c081a800
6013 c081c000
[3.42] de80: c032db40 c081dee0 c032d758 c081dece 0012 c030b398
0034 c081df2c
[3.42] dea0: c081deb8 c081deb8 c003d6f0 c003d6f8 6013
[3.42] r7:0003 r6:0001 r5:fefff000 r4:
[3.42] [] (vprintk+0x0/0x474) from []
(printk+0x28/0x30)
[3.42] [] (printk+0x0/0x30) from []
(sock_register+0x64/0x84)
[3.42] r3:0001 r2:0002 r1:0001 r0:c02e4c88
[3.42] [] (sock_register+0x0/0x84) from []
(af_unix_init+0x40/0x88)
[3.42] r5: r4:
[3.42] [] (af_unix_init+0x0/0x88) from []
(kernel_init+0x9c/0x2b4)
[3.42] r4:
[3.42] [] (kernel_init+0x0/0x2b4) from []
(do_exit+0x0/0x8e8)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Fix a lock problem in generic phy code
Lock debugging finds a problem in phy.c and phy_device.c,
this patch fixes it. Tested on an AT91SAM9263-EK board,
kernel 2.6.23-rc4.
Signed-off-by: Hans J. Koch <[EMAIL PROTECTED]>
---
Index: linux-2.6.23-rc/drivers/net/phy/phy_device.c
===
--- linux-2.6.23-rc.orig/drivers/net/phy/phy_device.c 2007-08-31
14:07:47.0 +0200
+++ linux-2.6.23-rc/drivers/net/phy/phy_device.c2007-08-31
14:08:22.0
+0200
@@ -644,7 +644,7 @@
if (!(phydrv->flags & PHY_HAS_INTERRUPT))
phydev->irq = PHY_POLL;
- spin_lock(>lock);
+ spin_lock_bh(>lock);
/* Start out supporting everything. Eventually,
* a controller will attach, and may modify one
@@ -658,7 +658,7 @@
if (phydev->drv->probe)
err = phydev->drv->probe(phydev);
- spin_unlock(>lock);
+ spin_unlock_bh(>lock);
return err;
Index: linux-2.6.23-rc/drivers/net/phy/phy.c
===
--- linux-2.6.23-rc.orig/drivers/net/phy/phy.c 2007-08-31 14:15:20.0
+0200
+++ linux-2.6.23-rc/drivers/net/phy/phy.c 2007-08-31 14:15:43.0
+0200
@@ -755,7 +755,7 @@
*/
void phy_start(struct phy_device *phydev)
{
- spin_lock(>lock);
+ spin_lock_bh(>lock);
switch (phydev->state) {
case PHY_STARTING:
@@ -769,7 +769,7 @@
default:
break;
}
- spin_unlock(>lock);
+ spin_unlock_bh(>lock);
}
EXPORT_SYMBOL(phy_stop);
EXPORT_SYMBOL(phy_start);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Fix a lock problem in generic phy code
Am Freitag 31 August 2007 schrieb Hans-Jürgen Koch:
Lock debugging finds a problem in phy.c and phy_device.c,
this patch fixes it. Tested on an AT91SAM9263-EK board,
kernel 2.6.23-rc4.
FYI, here's the log message without that patch:
[3.42] =
[3.42] [ INFO: inconsistent lock state ]
[3.42] 2.6.23-rc3-mm1 #21
[3.42] -
[3.42] inconsistent {softirq-on-W} - {in-softirq-W} usage.
[3.42] swapper/1 [HC0[0]:SC1[1]:HE1:SE0] takes:
[3.42] (dev-lock){-+..}, at: [c017da1c] phy_timer+0x1c/0x4c8
[3.42] {softirq-on-W} state was registered at:
[3.42] [c006021c] lock_acquire+0x94/0xac
[3.42] [c026423c] _spin_lock+0x40/0x50
[3.42] [c017e2b4] phy_probe+0x40/0x88
[3.42] [c017e60c] phy_attach+0xc8/0xfc
[3.42] [c017e6c4] phy_connect+0x1c/0x58
[3.42] [c017fc44] macb_probe+0x4fc/0x5bc
[3.42] [c0177b44] platform_drv_probe+0x20/0x24
[3.42] [c0176210] driver_probe_device+0xb0/0x1bc
[3.42] [c01764dc] __driver_attach+0xe4/0xe8
[3.42] [c017550c] bus_for_each_dev+0x54/0x80
[3.42] [c0176074] driver_attach+0x20/0x28
[3.42] [c01758d4] bus_add_driver+0x84/0x1e0
[3.42] [c0176708] driver_register+0x54/0x90
[3.42] [c0177de0] platform_driver_register+0x6c/0x88
[3.42] [c00167ec] macb_init+0x14/0x1c
[3.42] [c00087e4] kernel_init+0x9c/0x2b4
[3.42] [c0040338] do_exit+0x0/0x8e8
[3.42] irq event stamp: 115025
[3.42] hardirqs last enabled at (115025): [c0264958]
_spin_unlock_irq+0x30/0x60
[3.42] hardirqs last disabled at (115024): [c02642c8]
_spin_lock_irq+0x28/0x60
[3.42] softirqs last enabled at (114999): [c0042910]
__do_softirq+0xfc/0x12c
[3.42] softirqs last disabled at (115022): [c0042ee8]
irq_exit+0x68/0x7c
[3.42]
[3.42] other info that might help us debug this:
[3.42] no locks held by swapper/1.
[3.42]
[3.42] stack backtrace:
[3.42] [c0028af4] (dump_stack+0x0/0x14) from [c005d8e4]
(print_usage_bug+0x120/0x150)
[3.42] [c005d7c4] (print_usage_bug+0x0/0x150) from [c005e5e8]
(mark_lock+0x574/0x6bc)
[3.42] [c005e074] (mark_lock+0x0/0x6bc) from [c005f4c0]
(__lock_acquire+0x4d0/0x1198)
[3.42] [c005eff0] (__lock_acquire+0x0/0x1198) from [c006021c]
(lock_acquire+0x94/0xac)
[3.42] [c0060188] (lock_acquire+0x0/0xac) from [c026423c]
(_spin_lock+0x40/0x50)
[3.42] [c02641fc] (_spin_lock+0x0/0x50) from [c017da1c]
(phy_timer+0x1c/0x4c8)
[3.42] r5:c098a800 r4:0104
[3.42] [c017da00] (phy_timer+0x0/0x4c8) from [c0046ee4]
(run_timer_softirq+0x1a0/0x218)
[3.42] r7:c081ddd0 r6:c0331e80 r5:c098aa50 r4:0104
[3.42] [c0046d44] (run_timer_softirq+0x0/0x218) from [c00428a8]
(__do_softirq+0x94/0x12c)
[3.42] [c0042814] (__do_softirq+0x0/0x12c) from [c0042ee8]
(irq_exit+0x68/0x7c)
[3.42] [c0042e80] (irq_exit+0x0/0x7c) from [c0023060]
(__exception_text_start+0x60/0x74)
[3.42] r4:0001
[3.42] [c0023000] (__exception_text_start+0x0/0x74) from [c0023b28]
(__irq_svc+0x48/0x74)
[3.42] Exception stack(0xc081de70 to 0xc081deb8)
[3.42] de60: c030b2a8 c081a800
6013 c081c000
[3.42] de80: c032db40 c081dee0 c032d758 c081dece 0012 c030b398
0034 c081df2c
[3.42] dea0: c081deb8 c081deb8 c003d6f0 c003d6f8 6013
[3.42] r7:0003 r6:0001 r5:fefff000 r4:
[3.42] [c003d494] (vprintk+0x0/0x474) from [c003d930]
(printk+0x28/0x30)
[3.42] [c003d908] (printk+0x0/0x30) from [c01d3558]
(sock_register+0x64/0x84)
[3.42] r3:0001 r2:0002 r1:0001 r0:c02e4c88
[3.42] [c01d34f4] (sock_register+0x0/0x84) from [c001b7bc]
(af_unix_init+0x40/0x88)
[3.42] r5: r4:
[3.42] [c001b77c] (af_unix_init+0x0/0x88) from [c00087e4]
(kernel_init+0x9c/0x2b4)
[3.42] r4:
[3.42] [c0008748] (kernel_init+0x0/0x2b4) from [c0040338]
(do_exit+0x0/0x8e8)
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Fix a lock problem in generic phy code
Lock debugging finds a problem in phy.c and phy_device.c,
this patch fixes it. Tested on an AT91SAM9263-EK board,
kernel 2.6.23-rc4.
Signed-off-by: Hans J. Koch [EMAIL PROTECTED]
---
Index: linux-2.6.23-rc/drivers/net/phy/phy_device.c
===
--- linux-2.6.23-rc.orig/drivers/net/phy/phy_device.c 2007-08-31
14:07:47.0 +0200
+++ linux-2.6.23-rc/drivers/net/phy/phy_device.c2007-08-31
14:08:22.0
+0200
@@ -644,7 +644,7 @@
if (!(phydrv-flags PHY_HAS_INTERRUPT))
phydev-irq = PHY_POLL;
- spin_lock(phydev-lock);
+ spin_lock_bh(phydev-lock);
/* Start out supporting everything. Eventually,
* a controller will attach, and may modify one
@@ -658,7 +658,7 @@
if (phydev-drv-probe)
err = phydev-drv-probe(phydev);
- spin_unlock(phydev-lock);
+ spin_unlock_bh(phydev-lock);
return err;
Index: linux-2.6.23-rc/drivers/net/phy/phy.c
===
--- linux-2.6.23-rc.orig/drivers/net/phy/phy.c 2007-08-31 14:15:20.0
+0200
+++ linux-2.6.23-rc/drivers/net/phy/phy.c 2007-08-31 14:15:43.0
+0200
@@ -755,7 +755,7 @@
*/
void phy_start(struct phy_device *phydev)
{
- spin_lock(phydev-lock);
+ spin_lock_bh(phydev-lock);
switch (phydev-state) {
case PHY_STARTING:
@@ -769,7 +769,7 @@
default:
break;
}
- spin_unlock(phydev-lock);
+ spin_unlock_bh(phydev-lock);
}
EXPORT_SYMBOL(phy_stop);
EXPORT_SYMBOL(phy_start);
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Pausing kernel boot messages
Am Montag 27 August 2007 13:58 schrieb Andreas Schwab: > Hans-Jürgen Koch <[EMAIL PROTECTED]> writes: > > > Am Montag 27 August 2007 13:21 schrieb Esteban Fernandez: > >> How do you pause the kernel boot messages ? > >> > >> ^S, Pause and Scroll lock do nothing and you can't Shift-Page-Up after a > >> kernel panic. > > > > These are functions of a shell (like bash), > > Definitely not. The shell is not a console driver, it only uses it. Right, I wasn't precise. But it's still possible that you don't have your keyboard available during early parts of the boot process. Hans - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Pausing kernel boot messages
Am Montag 27 August 2007 13:21 schrieb Esteban Fernandez: > How do you pause the kernel boot messages ? > > ^S, Pause and Scroll lock do nothing and you can't Shift-Page-Up after a > kernel panic. These are functions of a shell (like bash), which you haven't got yet during kernel boot. You can read the kernel boot messages _after_ your system's up using dmesg etc. If you can't do that, e.g. because your kernel always hangs during boot, you could enable a serial console in your kernel and watch/log your kernel messages with a terminal program running on a different computer. Hans - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Pausing kernel boot messages
Am Montag 27 August 2007 13:21 schrieb Esteban Fernandez: How do you pause the kernel boot messages ? ^S, Pause and Scroll lock do nothing and you can't Shift-Page-Up after a kernel panic. These are functions of a shell (like bash), which you haven't got yet during kernel boot. You can read the kernel boot messages _after_ your system's up using dmesg etc. If you can't do that, e.g. because your kernel always hangs during boot, you could enable a serial console in your kernel and watch/log your kernel messages with a terminal program running on a different computer. Hans - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Pausing kernel boot messages
Am Montag 27 August 2007 13:58 schrieb Andreas Schwab: Hans-Jürgen Koch [EMAIL PROTECTED] writes: Am Montag 27 August 2007 13:21 schrieb Esteban Fernandez: How do you pause the kernel boot messages ? ^S, Pause and Scroll lock do nothing and you can't Shift-Page-Up after a kernel panic. These are functions of a shell (like bash), Definitely not. The shell is not a console driver, it only uses it. Right, I wasn't precise. But it's still possible that you don't have your keyboard available during early parts of the boot process. Hans - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] [374/2many] MAINTAINERS - PCNET32 NETWORK DRIVER
Am Montag 13 August 2007 09:18 schrieb Al Viro: > On Sun, Aug 12, 2007 at 11:46:49PM -0700, Joe Perches wrote: > > On Sun, 2007-08-12 at 23:36 -0700, David Miller wrote: > > > Ok, 374 patches is just rediculious. > > > > > > So many patches eats up an enormous amount of mailing list resources, > > > and for these patches in particular there are few reasons to split > > > them up at all. The fact that the split up landed you at 300+ patches > > > is a very good indication of that. > > > > More than ridiculous. Completely agree. > > > > I tried to send 1 patch over the last couple of days. > > Unfortunately, it's > 100KB and disappears into the void. > > So put it on anonftp/webpage/git tree and post the URI, damnit. > Of all ridiculous reasons for a mailbomb... Or make it 3 or 4 or even 40 patches, but not 500. Hans - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] [374/2many] MAINTAINERS - PCNET32 NETWORK DRIVER
Am Montag 13 August 2007 09:18 schrieb Al Viro: On Sun, Aug 12, 2007 at 11:46:49PM -0700, Joe Perches wrote: On Sun, 2007-08-12 at 23:36 -0700, David Miller wrote: Ok, 374 patches is just rediculious. So many patches eats up an enormous amount of mailing list resources, and for these patches in particular there are few reasons to split them up at all. The fact that the split up landed you at 300+ patches is a very good indication of that. More than ridiculous. Completely agree. I tried to send 1 patch over the last couple of days. Unfortunately, it's 100KB and disappears into the void. So put it on anonftp/webpage/git tree and post the URI, damnit. Of all ridiculous reasons for a mailbomb... Or make it 3 or 4 or even 40 patches, but not 500. Hans - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] at91 pm: Compilation fix for at91sam926x
Am Freitag 10 August 2007 00:15 schrieb Ulf Samuelsson: > > > > +#if defined(CONFIG_ARCH_AT91RM9200) > > > at91_sys_write(AT91_SDRAMC_SRR, 1); /* > > > self-refresh mode */ > > > Why don't use: > > if (cpu_is_at91rm9200()) > > at91_sys_write(AT91_SDRAMC_SRR, 1); > > What is the benefit? > Will the optimizer remove the code if the CPU is not the at91rm9200? No, it won't. cpu_is_something() is intended for runtime decisions. Remember that the purpose of this patch was to solve a compile time issue (see subject). AT91_SDRAMC_SRR isn't defined properly for non-9200 processors because they don't have that register. So we need something like #ifdef to include this line only on 9200. Hans - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] at91 pm: Compilation fix for at91sam926x
Am Freitag 10 August 2007 00:15 schrieb Ulf Samuelsson: +#if defined(CONFIG_ARCH_AT91RM9200) at91_sys_write(AT91_SDRAMC_SRR, 1); /* self-refresh mode */ Why don't use: if (cpu_is_at91rm9200()) at91_sys_write(AT91_SDRAMC_SRR, 1); What is the benefit? Will the optimizer remove the code if the CPU is not the at91rm9200? No, it won't. cpu_is_something() is intended for runtime decisions. Remember that the purpose of this patch was to solve a compile time issue (see subject). AT91_SDRAMC_SRR isn't defined properly for non-9200 processors because they don't have that register. So we need something like #ifdef to include this line only on 9200. Hans - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] at91 pm: Compilation fix for at91sam926x
Am Donnerstag 09 August 2007 19:17 schrieb Andy Herzig: > On Thu, 2007-08-09 at 18:01 +0200, Marc Pignat wrote: > > > > > +#if defined(CONFIG_ARCH_AT91RM9200) > > > > at91_sys_write(AT91_SDRAMC_SRR, 1); /* > > > > self-refresh mode */ > > Why don't use: > > if (cpu_is_at91rm9200()) > > at91_sys_write(AT91_SDRAMC_SRR, 1); > > > No reason. That looks good to me. No, it doesn't look good. It won't compile. Hans - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/3] UIO: Documentation
Am Donnerstag 09 August 2007 16:12 schrieb Alan Cox: > > That's no UIO invention. Userspace software that uses kernel interfaces like > > syscall, device files, sysfs, and so on, is by definition _not_ a derived > > work > > of the kernel and can be distributed under any license. > > This I believe incorrect. Please cite caselaw if you know better. What about the statement at the top of COPYING in the top level kernel source directory? I know, you've got examples in mind where a kernel module and a userspace program are dependent on each other and none of them can be used without the other. Of course, we've got such a case for a UIO kernel module and userspace driver. But if the degree of dependency between kernel and userspace can constitute a different legal situation, then we have a _very_ large legal grayzone. > > > With UIO, you have a kernel module that is so small, that even somebody who > > hasn't got the hardware can easily review it and tell if the code is OK or > > not. > > It is easy to maintain and doesn't reveal any secrets about the hardware. > > False > > Because you have no idea if the interface is correct or the userspace is > doing stuff like triggering DMA to arbitary addresses via the interface > or mmap functions. If it does so then even if its root only you've blown > your security model. OK, I agree. But in comparison to using /dev/mem for these tasks, I still consider UIO an improvement. Thanks, Hans - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] at91 pm: Compilation fix for at91sam926x
(added linux-arm-kernel to CC)
Am Donnerstag 09 August 2007 14:10 schrieb Andy Herzig:
> Hello all,
>
> This patch is intended to fix compilation errors when I tried to add in
> power management to my Atmel AT91SAM9260 board. First, there is no
> separate memory controller in the 9260 as there is in the 9200, so calls
> to do anything with it in pm.c fail.
Correct. I made the same discovery with my AT91SAM9263 board.
>
> Secondly, at91_suspend_entering_slow_clock() is not declared extern by
> drivers that use it. This used to cause only a warning, but in
> 2.6.23-rc1 and beyond, it is an error.
Patch looks good to me. Kernel compiles for my 9263. Didn't test
suspend/resume yet, though.
>
> Signed-off-by: Andrew J. Herzig <[EMAIL PROTECTED]>
Acked-by: Hans J. Koch <[EMAIL PROTECTED]>
> ---
> arch/arm/mach-at91/pm.c |5 -
> drivers/serial/atmel_serial.c |2 ++
> drivers/usb/gadget/at91_udc.c |2 ++
> drivers/usb/host/ohci-at91.c |1 +
> 4 files changed, 9 insertions(+), 1 deletion(-)
>
> diff -uprN -X linux-2.6.23-rc2/Documentation/dontdiff
> linux-2.6.23-rc2-vanilla/arch/arm/mach-at91/pm.c
> linux-2.6.23-rc2/arch/arm/mach-at91/pm.c
> --- linux-2.6.23-rc2-vanilla/arch/arm/mach-at91/pm.c2007-08-08
> 13:28:37.0 -0400
> +++ linux-2.6.23-rc2/arch/arm/mach-at91/pm.c2007-08-08
> 13:36:43.0 -0400
> @@ -176,7 +176,9 @@ static int at91_pm_enter(suspend_state_t
> */
> asm("b 1f; .align 5; 1:");
> asm("mcr p15, 0, r0, c7, c10, 4"); /* drain
> write buffer */
> +#if defined(CONFIG_ARCH_AT91RM9200)
> at91_sys_write(AT91_SDRAMC_SRR, 1); /*
> self-refresh mode */
> +#endif
> /* fall though to next state */
>
> case PM_SUSPEND_ON:
> @@ -218,8 +220,9 @@ static int __init at91_pm_init(void)
> #endif
>
> /* Disable SDRAM low-power mode. Cannot be used with
> self-refresh. */
> +#if defined(CONFIG_ARCH_AT91RM9200)
> at91_sys_write(AT91_SDRAMC_LPR, 0);
> -
> +#endif
> pm_set_ops(_pm_ops);
>
> return 0;
> diff -uprN -X linux-2.6.23-rc2/Documentation/dontdiff
> linux-2.6.23-rc2-vanilla/drivers/serial/atmel_serial.c
> linux-2.6.23-rc2/drivers/serial/atmel_serial.c
> --- linux-2.6.23-rc2-vanilla/drivers/serial/atmel_serial.c
> 2007-08-08 13:28:33.0 -0400
> +++ linux-2.6.23-rc2/drivers/serial/atmel_serial.c 2007-08-08
> 13:32:52.0 -0400
> @@ -916,6 +916,8 @@ static struct uart_driver atmel_uart = {
> };
>
> #ifdef CONFIG_PM
> +extern int at91_suspend_entering_slow_clock(void);
> +
> static int atmel_serial_suspend(struct platform_device *pdev,
> pm_message_t state)
> {
> struct uart_port *port = platform_get_drvdata(pdev);
> diff -uprN -X linux-2.6.23-rc2/Documentation/dontdiff
> linux-2.6.23-rc2-vanilla/drivers/usb/gadget/at91_udc.c
> linux-2.6.23-rc2/drivers/usb/gadget/at91_udc.c
> --- linux-2.6.23-rc2-vanilla/drivers/usb/gadget/at91_udc.c
> 2007-08-08 13:28:27.0 -0400
> +++ linux-2.6.23-rc2/drivers/usb/gadget/at91_udc.c 2007-08-08
> 13:33:21.0 -0400
> @@ -1770,6 +1770,8 @@ static int __exit at91udc_remove(struct
> }
>
> #ifdef CONFIG_PM
> +extern int at91_suspend_entering_slow_clock(void);
> +
> static int at91udc_suspend(struct platform_device *pdev, pm_message_t
> mesg)
> {
> struct at91_udc *udc = platform_get_drvdata(pdev);
> diff -uprN -X linux-2.6.23-rc2/Documentation/dontdiff
> linux-2.6.23-rc2-vanilla/drivers/usb/host/ohci-at91.c
> linux-2.6.23-rc2/drivers/usb/host/ohci-at91.c
> --- linux-2.6.23-rc2-vanilla/drivers/usb/host/ohci-at91.c
> 2007-08-08 13:28:27.0 -0400
> +++ linux-2.6.23-rc2/drivers/usb/host/ohci-at91.c 2007-08-08
> 13:32:45.0 -0400
> @@ -282,6 +282,7 @@ static int ohci_hcd_at91_drv_remove(stru
> }
>
> #ifdef CONFIG_PM
> +extern int at91_suspend_entering_slow_clock(void);
>
> static int
> ohci_hcd_at91_drv_suspend(struct platform_device *pdev, pm_message_t
> mesg)
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Documentation files in html format?
Am Donnerstag 09 August 2007 12:31 schrieb Stephen Hemminger: > Since the network device documentation needs a rewrite, I was thinking > of using basic html format instead of just plain text. Why don't you simply use DocBook? Then the user has the choice to convert to HTML, PDF, LaTex or whatever. Thanks, Hans - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/3] UIO: Documentation
Am Donnerstag 09 August 2007 00:12 schrieb [EMAIL PROTECTED]: > > If you have UIO in the kernel talking to stuff in userspace, you're going to > have to deal with closed-source stuff at the userspace end of the pipe. That's no UIO invention. Userspace software that uses kernel interfaces like syscall, device files, sysfs, and so on, is by definition _not_ a derived work of the kernel and can be distributed under any license. If you ask a manufacturer of an industrial IO card for a Linux driver today, you either get nothing at all, or you get an unmaintainable and buggy piece of crap for an ancient kernel. The alternative is a binary kernel module that really violates the GPL. With UIO, you have a kernel module that is so small, that even somebody who hasn't got the hardware can easily review it and tell if the code is OK or not. It is easy to maintain and doesn't reveal any secrets about the hardware. The kernel remains clean, which further improves maintenance and debugging. People frequently use /dev/mem to access hardware from userspace, that's nothing new. UIO really improves this, making it safer and more user friendly. And it prevents people from inventing dirty tricks to do some sort of interrupt handling in user space (which is simply not possible). Furthermore, drivers for this kind of hardware are written by programmers in industry, who often don't have kernel experience, reviews, time for tests, and so on. I really prefer it if they do their stuff in userspace. And they prefer it, too, because they can use all the nice tools and libraries they're used to. There might be a small possibility that a manufacturer now writes a closed source UIO driver, and would have written an open source kernel driver if UIO didn't exist. But, honestly, I doubt that we'll find many such cases. Thanks, Hans - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/3] UIO: Documentation
Am Donnerstag 09 August 2007 01:40 schrieb Alan Cox: > > On the other hand, given that we've always said that closed-source stuff in > > userspace is OK, the only way to not let *that* horse out of the barn is to > > not merge UIO at all. > > It really makes no difference whether it is merged or not. The test is > "derivative work" and not 'linking'. > > A user space driver that is unusuable without a specific GPL kernel chunk > is quite likely to be a derived work of the GPL kernel module I disagree. UIO is a documented kernel<->userspace interface, like sysfs or proc. Using your argument, we would also have to say that a userspace software that is unusable without sysfs is a derived work of the kernel. But IANAL, tell me if I missed an important point. > so the > documentation is giving poor advice however I guess you mean this sentence: "if you need to keep some parts of your driver closed source, you can do so without violating the GPL license on the kernel." What would you write instead? Thanks, Hans - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/3] UIO: Documentation
Am Mittwoch 08 August 2007 23:36 schrieb Jesper Juhl: > On 19/07/2007, Greg Kroah-Hartman <[EMAIL PROTECTED]> wrote: > > From: Hans J. Koch <[EMAIL PROTECTED]> > > > > Documentation for the UIO interface > > > ... > > +If you use UIO for your card's driver, here's what you get: > > + > ... > > + > > + if you need to keep some parts of your driver closed source, > > + you can do so without violating the GPL license on the > > kernel. > > + > > + > > + > ... > > Do we really want this? Yes. Please remember that UIO is for industrial I/O cards, not mainstream PC hardware. You'll never see an UIO driver for an USB Scanner or a TV card. Just try to write one. You will see that an UIO kernel driver for a device that has to interact with lots of kernel subsystems will become almost as big as a normal kernel driver. Not much left for user space. Typical industrial IO cards are simple PCI cards with loads of functions that don't fit in any kernel subsystem. A pure kernel driver is usually _big_ and ugly and introduces 50 new ioctls and will never make it into mainline. > > In my oppinion we run the risk here of encouraging behaviour akin to > what NVidia is doing - release a small kernel "glue" module and then > keep the driver proper in a binary blob (in userspace, but still a > binary blob). If a company wants to do that, they'll do it, with or without UIO. > If the company goes out of business and take their driver source with > them then users are left with a useless, un-debugable, un-maintainable > binary blob. > Don't we instead want to encourage/pressure people to release specs > and/or source code for their hardware/drivers so open, modifiable > drivers can be written? No. Please note that there _are_ reasons to keep code closed. I agree with you when it comes to mass market hardware like graphics cards. But in embedded systems with custom hardware for military or other critical applications, you can't force a manufacturer to show you his concepts. Usually, he's not allowed to. UIO offers a legal way for these people to implement their driver. Without it, they'll violate the GPL or don't use Linux at all. > > This opens the door for people to start writing closed drivers. No. UIO doesn't change anything. You were always free to choose your license for userspace stuff. What we want to achieve is that IO cards, for which you get a driver with 5000 lines of unreadable code for 2.6.12 from the manufacturer at the moment, can get a sensible driver with mainline support. That's all. We will see if that encourages manufacturers to make drivers closed source. Thanks, Hans - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/3] UIO: Documentation
Am Mittwoch 08 August 2007 23:36 schrieb Jesper Juhl: On 19/07/2007, Greg Kroah-Hartman [EMAIL PROTECTED] wrote: From: Hans J. Koch [EMAIL PROTECTED] Documentation for the UIO interface ... +paraIf you use UIO for your card's driver, here's what you get:/para + ... +listitem + paraif you need to keep some parts of your driver closed source, + you can do so without violating the GPL license on the kernel./para +/listitem +/itemizedlist + ... Do we really want this? Yes. Please remember that UIO is for industrial I/O cards, not mainstream PC hardware. You'll never see an UIO driver for an USB Scanner or a TV card. Just try to write one. You will see that an UIO kernel driver for a device that has to interact with lots of kernel subsystems will become almost as big as a normal kernel driver. Not much left for user space. Typical industrial IO cards are simple PCI cards with loads of functions that don't fit in any kernel subsystem. A pure kernel driver is usually _big_ and ugly and introduces 50 new ioctls and will never make it into mainline. In my oppinion we run the risk here of encouraging behaviour akin to what NVidia is doing - release a small kernel glue module and then keep the driver proper in a binary blob (in userspace, but still a binary blob). If a company wants to do that, they'll do it, with or without UIO. If the company goes out of business and take their driver source with them then users are left with a useless, un-debugable, un-maintainable binary blob. Don't we instead want to encourage/pressure people to release specs and/or source code for their hardware/drivers so open, modifiable drivers can be written? No. Please note that there _are_ reasons to keep code closed. I agree with you when it comes to mass market hardware like graphics cards. But in embedded systems with custom hardware for military or other critical applications, you can't force a manufacturer to show you his concepts. Usually, he's not allowed to. UIO offers a legal way for these people to implement their driver. Without it, they'll violate the GPL or don't use Linux at all. This opens the door for people to start writing closed drivers. No. UIO doesn't change anything. You were always free to choose your license for userspace stuff. What we want to achieve is that IO cards, for which you get a driver with 5000 lines of unreadable code for 2.6.12 from the manufacturer at the moment, can get a sensible driver with mainline support. That's all. We will see if that encourages manufacturers to make drivers closed source. Thanks, Hans - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/3] UIO: Documentation
Am Donnerstag 09 August 2007 01:40 schrieb Alan Cox: On the other hand, given that we've always said that closed-source stuff in userspace is OK, the only way to not let *that* horse out of the barn is to not merge UIO at all. It really makes no difference whether it is merged or not. The test is derivative work and not 'linking'. A user space driver that is unusuable without a specific GPL kernel chunk is quite likely to be a derived work of the GPL kernel module I disagree. UIO is a documented kernel-userspace interface, like sysfs or proc. Using your argument, we would also have to say that a userspace software that is unusable without sysfs is a derived work of the kernel. But IANAL, tell me if I missed an important point. so the documentation is giving poor advice however I guess you mean this sentence: if you need to keep some parts of your driver closed source, you can do so without violating the GPL license on the kernel. What would you write instead? Thanks, Hans - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Documentation files in html format?
Am Donnerstag 09 August 2007 12:31 schrieb Stephen Hemminger: Since the network device documentation needs a rewrite, I was thinking of using basic html format instead of just plain text. Why don't you simply use DocBook? Then the user has the choice to convert to HTML, PDF, LaTex or whatever. Thanks, Hans - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/3] UIO: Documentation
Am Donnerstag 09 August 2007 00:12 schrieb [EMAIL PROTECTED]: If you have UIO in the kernel talking to stuff in userspace, you're going to have to deal with closed-source stuff at the userspace end of the pipe. That's no UIO invention. Userspace software that uses kernel interfaces like syscall, device files, sysfs, and so on, is by definition _not_ a derived work of the kernel and can be distributed under any license. If you ask a manufacturer of an industrial IO card for a Linux driver today, you either get nothing at all, or you get an unmaintainable and buggy piece of crap for an ancient kernel. The alternative is a binary kernel module that really violates the GPL. With UIO, you have a kernel module that is so small, that even somebody who hasn't got the hardware can easily review it and tell if the code is OK or not. It is easy to maintain and doesn't reveal any secrets about the hardware. The kernel remains clean, which further improves maintenance and debugging. People frequently use /dev/mem to access hardware from userspace, that's nothing new. UIO really improves this, making it safer and more user friendly. And it prevents people from inventing dirty tricks to do some sort of interrupt handling in user space (which is simply not possible). Furthermore, drivers for this kind of hardware are written by programmers in industry, who often don't have kernel experience, reviews, time for tests, and so on. I really prefer it if they do their stuff in userspace. And they prefer it, too, because they can use all the nice tools and libraries they're used to. There might be a small possibility that a manufacturer now writes a closed source UIO driver, and would have written an open source kernel driver if UIO didn't exist. But, honestly, I doubt that we'll find many such cases. Thanks, Hans - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] at91 pm: Compilation fix for at91sam926x
(added linux-arm-kernel to CC)
Am Donnerstag 09 August 2007 14:10 schrieb Andy Herzig:
Hello all,
This patch is intended to fix compilation errors when I tried to add in
power management to my Atmel AT91SAM9260 board. First, there is no
separate memory controller in the 9260 as there is in the 9200, so calls
to do anything with it in pm.c fail.
Correct. I made the same discovery with my AT91SAM9263 board.
Secondly, at91_suspend_entering_slow_clock() is not declared extern by
drivers that use it. This used to cause only a warning, but in
2.6.23-rc1 and beyond, it is an error.
Patch looks good to me. Kernel compiles for my 9263. Didn't test
suspend/resume yet, though.
Signed-off-by: Andrew J. Herzig [EMAIL PROTECTED]
Acked-by: Hans J. Koch [EMAIL PROTECTED]
---
arch/arm/mach-at91/pm.c |5 -
drivers/serial/atmel_serial.c |2 ++
drivers/usb/gadget/at91_udc.c |2 ++
drivers/usb/host/ohci-at91.c |1 +
4 files changed, 9 insertions(+), 1 deletion(-)
diff -uprN -X linux-2.6.23-rc2/Documentation/dontdiff
linux-2.6.23-rc2-vanilla/arch/arm/mach-at91/pm.c
linux-2.6.23-rc2/arch/arm/mach-at91/pm.c
--- linux-2.6.23-rc2-vanilla/arch/arm/mach-at91/pm.c2007-08-08
13:28:37.0 -0400
+++ linux-2.6.23-rc2/arch/arm/mach-at91/pm.c2007-08-08
13:36:43.0 -0400
@@ -176,7 +176,9 @@ static int at91_pm_enter(suspend_state_t
*/
asm(b 1f; .align 5; 1:);
asm(mcr p15, 0, r0, c7, c10, 4); /* drain
write buffer */
+#if defined(CONFIG_ARCH_AT91RM9200)
at91_sys_write(AT91_SDRAMC_SRR, 1); /*
self-refresh mode */
+#endif
/* fall though to next state */
case PM_SUSPEND_ON:
@@ -218,8 +220,9 @@ static int __init at91_pm_init(void)
#endif
/* Disable SDRAM low-power mode. Cannot be used with
self-refresh. */
+#if defined(CONFIG_ARCH_AT91RM9200)
at91_sys_write(AT91_SDRAMC_LPR, 0);
-
+#endif
pm_set_ops(at91_pm_ops);
return 0;
diff -uprN -X linux-2.6.23-rc2/Documentation/dontdiff
linux-2.6.23-rc2-vanilla/drivers/serial/atmel_serial.c
linux-2.6.23-rc2/drivers/serial/atmel_serial.c
--- linux-2.6.23-rc2-vanilla/drivers/serial/atmel_serial.c
2007-08-08 13:28:33.0 -0400
+++ linux-2.6.23-rc2/drivers/serial/atmel_serial.c 2007-08-08
13:32:52.0 -0400
@@ -916,6 +916,8 @@ static struct uart_driver atmel_uart = {
};
#ifdef CONFIG_PM
+extern int at91_suspend_entering_slow_clock(void);
+
static int atmel_serial_suspend(struct platform_device *pdev,
pm_message_t state)
{
struct uart_port *port = platform_get_drvdata(pdev);
diff -uprN -X linux-2.6.23-rc2/Documentation/dontdiff
linux-2.6.23-rc2-vanilla/drivers/usb/gadget/at91_udc.c
linux-2.6.23-rc2/drivers/usb/gadget/at91_udc.c
--- linux-2.6.23-rc2-vanilla/drivers/usb/gadget/at91_udc.c
2007-08-08 13:28:27.0 -0400
+++ linux-2.6.23-rc2/drivers/usb/gadget/at91_udc.c 2007-08-08
13:33:21.0 -0400
@@ -1770,6 +1770,8 @@ static int __exit at91udc_remove(struct
}
#ifdef CONFIG_PM
+extern int at91_suspend_entering_slow_clock(void);
+
static int at91udc_suspend(struct platform_device *pdev, pm_message_t
mesg)
{
struct at91_udc *udc = platform_get_drvdata(pdev);
diff -uprN -X linux-2.6.23-rc2/Documentation/dontdiff
linux-2.6.23-rc2-vanilla/drivers/usb/host/ohci-at91.c
linux-2.6.23-rc2/drivers/usb/host/ohci-at91.c
--- linux-2.6.23-rc2-vanilla/drivers/usb/host/ohci-at91.c
2007-08-08 13:28:27.0 -0400
+++ linux-2.6.23-rc2/drivers/usb/host/ohci-at91.c 2007-08-08
13:32:45.0 -0400
@@ -282,6 +282,7 @@ static int ohci_hcd_at91_drv_remove(stru
}
#ifdef CONFIG_PM
+extern int at91_suspend_entering_slow_clock(void);
static int
ohci_hcd_at91_drv_suspend(struct platform_device *pdev, pm_message_t
mesg)
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/3] UIO: Documentation
Am Donnerstag 09 August 2007 16:12 schrieb Alan Cox: That's no UIO invention. Userspace software that uses kernel interfaces like syscall, device files, sysfs, and so on, is by definition _not_ a derived work of the kernel and can be distributed under any license. This I believe incorrect. Please cite caselaw if you know better. What about the statement at the top of COPYING in the top level kernel source directory? I know, you've got examples in mind where a kernel module and a userspace program are dependent on each other and none of them can be used without the other. Of course, we've got such a case for a UIO kernel module and userspace driver. But if the degree of dependency between kernel and userspace can constitute a different legal situation, then we have a _very_ large legal grayzone. With UIO, you have a kernel module that is so small, that even somebody who hasn't got the hardware can easily review it and tell if the code is OK or not. It is easy to maintain and doesn't reveal any secrets about the hardware. False Because you have no idea if the interface is correct or the userspace is doing stuff like triggering DMA to arbitary addresses via the interface or mmap functions. If it does so then even if its root only you've blown your security model. OK, I agree. But in comparison to using /dev/mem for these tasks, I still consider UIO an improvement. Thanks, Hans - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] at91 pm: Compilation fix for at91sam926x
Am Donnerstag 09 August 2007 19:17 schrieb Andy Herzig: On Thu, 2007-08-09 at 18:01 +0200, Marc Pignat wrote: +#if defined(CONFIG_ARCH_AT91RM9200) at91_sys_write(AT91_SDRAMC_SRR, 1); /* self-refresh mode */ Why don't use: if (cpu_is_at91rm9200()) at91_sys_write(AT91_SDRAMC_SRR, 1); No reason. That looks good to me. No, it doesn't look good. It won't compile. Hans - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [rfc] Re: [PATCH] Make UIO available for arm architecture
Am Mittwoch 08 August 2007 18:10 schrieb Greg KH: > On Wed, Aug 08, 2007 at 06:15:21PM +0200, Jan Engelhardt wrote: > > > > On Aug 8 2007 18:08, Hans-J??rgen Koch wrote: > > >--- > > >Index: linux-2.6.23-rc/arch/arm/Kconfig > > >=== > > >--- linux-2.6.23-rc.orig/arch/arm/Kconfig 2007-08-08 17:52:02.0 > > >+0200 > > >+++ linux-2.6.23-rc/arch/arm/Kconfig 2007-08-08 17:53:29.0 > > >+0200 > > >@@ -1052,6 +1052,8 @@ > > > > > > source "drivers/dma/Kconfig" > > > > > >+source "drivers/uio/Kconfig" > > >+ > > > endmenu > > > > > > source "fs/Kconfig" > > > > I am raising a general question here. > > Should not such cross-platform things be made available in a general > > Kconfig rather than having to patch each arch's Kconfig? > > > > I am thinking of drivers/Kconfig for this one (of course I am aware that > > this > > requires an extra "depends on X86 || SPARC || others" in > > drivers/pci/Kconfig), > > and perhaps even a top-level Kconfig for things like truly arch-independent > > fs/Kconfig. > > Um, uio _is_ in drivers/Kconfig already :) Of course :-) > > But I'm guessing that ARM doesn't use that file yet? No, they don't. They source Kconfigs from each drivers subdirectory. > If so, I have no > objection to the above patch, but it should go through the ARM > developers, not me. OK, as I've CCed linux-arm-kernel, I hope Russell will do that. Thanks, Hans - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Make UIO available for arm architecture
The config system doesn't show the UIO menu if arch=arm, this patch fixes it. Signed-off-by: Hans J. Koch <[EMAIL PROTECTED]> --- Index: linux-2.6.23-rc/arch/arm/Kconfig === --- linux-2.6.23-rc.orig/arch/arm/Kconfig 2007-08-08 17:52:02.0 +0200 +++ linux-2.6.23-rc/arch/arm/Kconfig2007-08-08 17:53:29.0 +0200 @@ -1052,6 +1052,8 @@ source "drivers/dma/Kconfig" +source "drivers/uio/Kconfig" + endmenu source "fs/Kconfig" - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Make UIO available for arm architecture
The config system doesn't show the UIO menu if arch=arm, this patch fixes it. Signed-off-by: Hans J. Koch [EMAIL PROTECTED] --- Index: linux-2.6.23-rc/arch/arm/Kconfig === --- linux-2.6.23-rc.orig/arch/arm/Kconfig 2007-08-08 17:52:02.0 +0200 +++ linux-2.6.23-rc/arch/arm/Kconfig2007-08-08 17:53:29.0 +0200 @@ -1052,6 +1052,8 @@ source drivers/dma/Kconfig +source drivers/uio/Kconfig + endmenu source fs/Kconfig - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [rfc] Re: [PATCH] Make UIO available for arm architecture
Am Mittwoch 08 August 2007 18:10 schrieb Greg KH: On Wed, Aug 08, 2007 at 06:15:21PM +0200, Jan Engelhardt wrote: On Aug 8 2007 18:08, Hans-J??rgen Koch wrote: --- Index: linux-2.6.23-rc/arch/arm/Kconfig === --- linux-2.6.23-rc.orig/arch/arm/Kconfig 2007-08-08 17:52:02.0 +0200 +++ linux-2.6.23-rc/arch/arm/Kconfig 2007-08-08 17:53:29.0 +0200 @@ -1052,6 +1052,8 @@ source drivers/dma/Kconfig +source drivers/uio/Kconfig + endmenu source fs/Kconfig I am raising a general question here. Should not such cross-platform things be made available in a general Kconfig rather than having to patch each arch's Kconfig? I am thinking of drivers/Kconfig for this one (of course I am aware that this requires an extra depends on X86 || SPARC || others in drivers/pci/Kconfig), and perhaps even a top-level Kconfig for things like truly arch-independent fs/Kconfig. Um, uio _is_ in drivers/Kconfig already :) Of course :-) But I'm guessing that ARM doesn't use that file yet? No, they don't. They source Kconfigs from each drivers subdirectory. If so, I have no objection to the above patch, but it should go through the ARM developers, not me. OK, as I've CCed linux-arm-kernel, I hope Russell will do that. Thanks, Hans - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RT-PATCH] v2.6.23-rc1-rt0 Add missing header in sch_generic.c
v2.6.23-rc1-rt0 adds an msleep(1) in net/sched/sch_generic.c without including the neceessary header. This patches fixes it. Signed-off-by: Hans J. Koch <[EMAIL PROTECTED]> Index: linux-2.6.23-rc/net/sched/sch_generic.c === --- linux-2.6.23-rc.orig/net/sched/sch_generic.c2007-07-24 20:09:18.0 +0200 +++ linux-2.6.23-rc/net/sched/sch_generic.c 2007-07-24 20:10:13.0 +0200 @@ -25,6 +25,7 @@ #include #include #include +#include #include /* Main transmission queue. */ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [lm-sensors] drivers/hwmon/lm93.c: array overruns
Am Dienstag 24 Juli 2007 10:10 schrieb Jean Delvare:
> Hi Hans,
>
> On Mon, 23 Jul 2007 09:36:57 +0200, Hans-Jürgen Koch wrote:
> > Am Montag 23 Juli 2007 02:54 schrieb Adrian Bunk:
> > > The Coverity checker spotted the following array overruns
> > > in drivers/hwmon/lm93.c:
> > >
> > > <-- snip -->
> > >
> > > ...
> > > struct lm93_data {
> > > ...
> > > struct {
> > > u8 min;
> > > u8 max;
> > > } temp_lim[3];
> > > ...
> > > };
> > > ...
> > > static void lm93_update_client_common(struct lm93_data *data,
> > > struct i2c_client *client)
> > > {
> > > ...
> > > for (i = 0; i < 4; i++) {
> > > data->temp_lim[i].min =
> > > lm93_read_byte(client, LM93_REG_TEMP_MIN(i));
> > > data->temp_lim[i].max =
> > > lm93_read_byte(client, LM93_REG_TEMP_MAX(i));
> > > }
> > > ...
> > >
> > > <-- snip -->
> >
> > This patch should fix it. Thanks a lot, Adrian!
> >
> >
> > This fixes an array overflow bug. We have 4 pairs of min/max temperature
> > limits, not 3.
> >
> > Signed-off-by: Hans J. Koch <[EMAIL PROTECTED]>
> >
> > --
> > Index: linux-2.6.23-rc/drivers/hwmon/lm93.c
> > ===
> > --- linux-2.6.23-rc.orig/drivers/hwmon/lm93.c 2007-07-23
> > 09:22:56.0 +0200
> > +++ linux-2.6.23-rc/drivers/hwmon/lm93.c2007-07-23 09:29:37.0
> > +0200
> > @@ -234,7 +234,7 @@
> > struct {
> > u8 min;
> > u8 max;
> > - } temp_lim[3];
> > + } temp_lim[4];
> >
> > /* vin1 - vin16: low and high limits */
> > struct {
>
> This will do as a quick fix, so:
>
> Acked-by: Jean Delvare <[EMAIL PROTECTED]>
>
> However, I see that temp4 (which isn't a real temperature channel) is
> not exposed in sysfs. Reading and storing register values you never use
> doesn't seem particularly interesting, so something needs to be done
> here: either drop support for temp4 entirely, or expose the temp4
> values in sysfs.
I've got that on my TODO list. I'll soon work on that driver again. I'm still
waiting for that #§$?& NDA-covered datasheet of the LM94. As soon as I've got
that, I need to review all these values anyway because there might be subtle
differences between LM93 and LM94.
For the moment, I'd like to postpone the decision about what to do with temp4.
Thanks anyway for pointing this out.
Hans
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [lm-sensors] drivers/hwmon/lm93.c: array overruns
Am Dienstag 24 Juli 2007 10:10 schrieb Jean Delvare:
Hi Hans,
On Mon, 23 Jul 2007 09:36:57 +0200, Hans-Jürgen Koch wrote:
Am Montag 23 Juli 2007 02:54 schrieb Adrian Bunk:
The Coverity checker spotted the following array overruns
in drivers/hwmon/lm93.c:
-- snip --
...
struct lm93_data {
...
struct {
u8 min;
u8 max;
} temp_lim[3];
...
};
...
static void lm93_update_client_common(struct lm93_data *data,
struct i2c_client *client)
{
...
for (i = 0; i 4; i++) {
data-temp_lim[i].min =
lm93_read_byte(client, LM93_REG_TEMP_MIN(i));
data-temp_lim[i].max =
lm93_read_byte(client, LM93_REG_TEMP_MAX(i));
}
...
-- snip --
This patch should fix it. Thanks a lot, Adrian!
This fixes an array overflow bug. We have 4 pairs of min/max temperature
limits, not 3.
Signed-off-by: Hans J. Koch [EMAIL PROTECTED]
--
Index: linux-2.6.23-rc/drivers/hwmon/lm93.c
===
--- linux-2.6.23-rc.orig/drivers/hwmon/lm93.c 2007-07-23
09:22:56.0 +0200
+++ linux-2.6.23-rc/drivers/hwmon/lm93.c2007-07-23 09:29:37.0
+0200
@@ -234,7 +234,7 @@
struct {
u8 min;
u8 max;
- } temp_lim[3];
+ } temp_lim[4];
/* vin1 - vin16: low and high limits */
struct {
This will do as a quick fix, so:
Acked-by: Jean Delvare [EMAIL PROTECTED]
However, I see that temp4 (which isn't a real temperature channel) is
not exposed in sysfs. Reading and storing register values you never use
doesn't seem particularly interesting, so something needs to be done
here: either drop support for temp4 entirely, or expose the temp4
values in sysfs.
I've got that on my TODO list. I'll soon work on that driver again. I'm still
waiting for that #§$? NDA-covered datasheet of the LM94. As soon as I've got
that, I need to review all these values anyway because there might be subtle
differences between LM93 and LM94.
For the moment, I'd like to postpone the decision about what to do with temp4.
Thanks anyway for pointing this out.
Hans
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[RT-PATCH] v2.6.23-rc1-rt0 Add missing header in sch_generic.c
v2.6.23-rc1-rt0 adds an msleep(1) in net/sched/sch_generic.c without including the neceessary header. This patches fixes it. Signed-off-by: Hans J. Koch [EMAIL PROTECTED] Index: linux-2.6.23-rc/net/sched/sch_generic.c === --- linux-2.6.23-rc.orig/net/sched/sch_generic.c2007-07-24 20:09:18.0 +0200 +++ linux-2.6.23-rc/net/sched/sch_generic.c 2007-07-24 20:10:13.0 +0200 @@ -25,6 +25,7 @@ #include linux/init.h #include linux/rcupdate.h #include linux/list.h +#include linux/delay.h #include net/pkt_sched.h /* Main transmission queue. */ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: drivers/hwmon/lm93.c: array overruns
Am Montag 23 Juli 2007 02:54 schrieb Adrian Bunk:
> The Coverity checker spotted the following array overruns
> in drivers/hwmon/lm93.c:
>
> <-- snip -->
>
> ...
> struct lm93_data {
> ...
> struct {
> u8 min;
> u8 max;
> } temp_lim[3];
> ...
> };
> ...
> static void lm93_update_client_common(struct lm93_data *data,
> struct i2c_client *client)
> {
> ...
> for (i = 0; i < 4; i++) {
> data->temp_lim[i].min =
> lm93_read_byte(client, LM93_REG_TEMP_MIN(i));
> data->temp_lim[i].max =
> lm93_read_byte(client, LM93_REG_TEMP_MAX(i));
> }
> ...
>
> <-- snip -->
This patch should fix it. Thanks a lot, Adrian!
This fixes an array overflow bug. We have 4 pairs of min/max temperature
limits, not 3.
Signed-off-by: Hans J. Koch <[EMAIL PROTECTED]>
--
Index: linux-2.6.23-rc/drivers/hwmon/lm93.c
===
--- linux-2.6.23-rc.orig/drivers/hwmon/lm93.c 2007-07-23 09:22:56.0
+0200
+++ linux-2.6.23-rc/drivers/hwmon/lm93.c2007-07-23 09:29:37.0
+0200
@@ -234,7 +234,7 @@
struct {
u8 min;
u8 max;
- } temp_lim[3];
+ } temp_lim[4];
/* vin1 - vin16: low and high limits */
struct {
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: drivers/hwmon/lm93.c: array overruns
Am Montag 23 Juli 2007 02:54 schrieb Adrian Bunk:
The Coverity checker spotted the following array overruns
in drivers/hwmon/lm93.c:
-- snip --
...
struct lm93_data {
...
struct {
u8 min;
u8 max;
} temp_lim[3];
...
};
...
static void lm93_update_client_common(struct lm93_data *data,
struct i2c_client *client)
{
...
for (i = 0; i 4; i++) {
data-temp_lim[i].min =
lm93_read_byte(client, LM93_REG_TEMP_MIN(i));
data-temp_lim[i].max =
lm93_read_byte(client, LM93_REG_TEMP_MAX(i));
}
...
-- snip --
This patch should fix it. Thanks a lot, Adrian!
This fixes an array overflow bug. We have 4 pairs of min/max temperature
limits, not 3.
Signed-off-by: Hans J. Koch [EMAIL PROTECTED]
--
Index: linux-2.6.23-rc/drivers/hwmon/lm93.c
===
--- linux-2.6.23-rc.orig/drivers/hwmon/lm93.c 2007-07-23 09:22:56.0
+0200
+++ linux-2.6.23-rc/drivers/hwmon/lm93.c2007-07-23 09:29:37.0
+0200
@@ -234,7 +234,7 @@
struct {
u8 min;
u8 max;
- } temp_lim[3];
+ } temp_lim[4];
/* vin1 - vin16: low and high limits */
struct {
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/3] UIO: Hilscher CIF card driver
Am Donnerstag 19 Juli 2007 22:02 schrieb Jan Engelhardt:
>
> On Jul 19 2007 21:28, Hans-Jürgen Koch wrote:
> >Am Donnerstag 19 Juli 2007 18:33 schrieb Jan Engelhardt:
> >> On Jul 18 2007 16:26, Greg Kroah-Hartman wrote:
> >> >
> >> >http://www.tglx.de/private/hjk/cif-orig-2.6.tar.bz2
> >> >
> >> >WARNING: Don't look at the code for too long, you might become sick :-)
> >>
> >> Taking precautions for people? I get a 404...
> >
> >Now it's there.
>
> , my eyes... ("Microsoft" is a good summary of the codingstyle...)
It's not just coding style, it's also concept. This was written with
the only goal to get a card working at one particular time. What happens
in future is not important. Would you like to port this driver to 2.6.22?
Would you like to post it on lkml, signed-off by you?
The concept is bad because the authors of that driver never tried to
find out how a driver should look like and what has to be done to get
it into mainline. Allright, with such a big driver for a relatively
unknown card(?) it's not easy to include that in mainline. That's
why we now have UIO... It greatly simplifies tasks like that.
I really hope that UIO will soon be used for industrial cards like
this one, and that we can fill drivers/uio/ with lots of small
kernel modules. And yes, these programmers in industry who wrote
drivers like the above, they will still be doing what they want and
what they're able to. But, hopefully, they'll now do it in userspace.
Thanks,
Hans
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/3] UIO: Hilscher CIF card driver
Am Donnerstag 19 Juli 2007 18:33 schrieb Jan Engelhardt: > > On Jul 18 2007 16:26, Greg Kroah-Hartman wrote: > > > >http://www.tglx.de/private/hjk/cif-orig-2.6.tar.bz2 > > > >WARNING: Don't look at the code for too long, you might become sick :-) > > Taking precautions for people? I get a 404... Now it's there. Thanks, Hans - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/3] UIO: Hilscher CIF card driver
Am Donnerstag 19 Juli 2007 18:33 schrieb Jan Engelhardt: On Jul 18 2007 16:26, Greg Kroah-Hartman wrote: http://www.tglx.de/private/hjk/cif-orig-2.6.tar.bz2 WARNING: Don't look at the code for too long, you might become sick :-) Taking precautions for people? I get a 404... Now it's there. Thanks, Hans - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
