Re: [PATCH] panasonic-laptop: take over maintainership
On Tue, Aug 25, 2020 at 06:13:41PM +0800, Kenneth Chan wrote: > Take over maintaniership of panasonic-laptop from Harald Welte. > > > Signed-off-by: Kenneth Chan Acked-by: Harald Welte -- - Harald Weltehttp://laforge.gnumonks.org/ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
Re: [PATCH 0/9] platform/x86: panasonic-laptop: add optical drive, brightness and battery charging threshold
Dear Keneth and Linux kernel developers, as I have discontinued maintenance of the panasonic-laptop driver (and recently sent a related MAINTAINERS update to that fact), I would like to suggest Kenneth as the new maintainer for this driver. Regards, Harald -- - Harald Weltehttp://laforge.gnumonks.org/ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
Re: Removing pcap?
Hi Alexandre, On Sun, Apr 07, 2019 at 04:07:41PM +0200, Alexandre Belloni wrote: > Is it worth fixing the RTC driver or could I remove it? I've left OpenEZX behind quite a long time ago. Antonio was working on it for some more time, I don't know if he's still actively using or maintaining it. >From my personal point of view, it's only historically relevant and can certainly be removed from current-day mainline kernels. That's of course unless some other people are still actively using it, which I somewhat doubt about a decade since those phones were last made. Regards, Harlad -- - Harald Weltehttp://laforge.gnumonks.org/ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
Re: [PATCH v2 net-next 2/4] net: add skeleton of bpfilter kernel module
Hi Alexei + netdev list, On Wed, May 02, 2018 at 09:36:02PM -0700, Alexei Starovoitov wrote: > Later bpfilter_process_sockopt() will be called from bpfilter hooks > in get/setsockopt() to pass iptable commands into umh via bpfilter.ko This is a part I'm quite heavily opposed to - at least at this point. Unless bpfilter offered something that is semantically compatible to what netfilter/iptables is currently implementing, I don't think bpfilter should be [allowed to] overriding the iptables {get,set}sockopt() calls. I appreciate that people are working on a different architecture packet filter than what we used to. I also understand that there is a need for backwards compatibility. I still think it's wrong to offer that compatibility on the {set,get}sockopt level, rather than on the "iptables command line utility replacement" level. But nevermind, you guys have a different opinion on that, on which we can agree to disagree. However, no matter what you do, the most important part from the user point of view is to make sure you don't break semantics. netfilter/iptables semantics have an intricate notion abut when which chain of which table is executed, in which order, at what particular point of the packet traversal during the network stack. The packet filtering rulesets that people have created over more than 18 years are based on those semantics. If you offer the same interface, but not that very same semantics, the packet filtering policies can an will break - and they will break so in a hidden way. To the user, it appears as if the ruleset is loaded with the assumed semantics, but in reality it isn't. Unless you can replicate those semantics 1:1, I think it is not only wrong to override the iptables sockopt interface, but it's outright dangerous. Having less matches/targets implemented than original iptables is something that I believe is acceptable (and inevitable, at least in the beginning). If somebody tries to load a related ruleset with bpfilter active, it will fail gracefully and the user can chose to not use that match/target in his ruleset, or to not use bpfilter. But if the ruleset loads but behaves different than before (because e.g. it's executed from a completely different place in the stack), that's IMHO an absolute no-go that must be avoided at all cost. If that's the case, you are actively breaking network security, rather than creating it. So I think there's only two ways to go: a) replicate the exact semantics/order of the filter/mangle/raw/... tables and their chains, both among themselves as well as in terms of ordering with other parts of the network stack, or b) not use the existing tables/chains with their pre-defined semantics but rather start new 'tables' which can then have different semantics as defined at the time of their implementation. My apologies if I misunderstood something about bpfilter. Feel free to correct me where I'm wrong. Thanks. Regards, Harald -- - Harald Welte <lafo...@gnumonks.org> http://laforge.gnumonks.org/ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
Re: [PATCH v2 net-next 2/4] net: add skeleton of bpfilter kernel module
Hi Alexei + netdev list, On Wed, May 02, 2018 at 09:36:02PM -0700, Alexei Starovoitov wrote: > Later bpfilter_process_sockopt() will be called from bpfilter hooks > in get/setsockopt() to pass iptable commands into umh via bpfilter.ko This is a part I'm quite heavily opposed to - at least at this point. Unless bpfilter offered something that is semantically compatible to what netfilter/iptables is currently implementing, I don't think bpfilter should be [allowed to] overriding the iptables {get,set}sockopt() calls. I appreciate that people are working on a different architecture packet filter than what we used to. I also understand that there is a need for backwards compatibility. I still think it's wrong to offer that compatibility on the {set,get}sockopt level, rather than on the "iptables command line utility replacement" level. But nevermind, you guys have a different opinion on that, on which we can agree to disagree. However, no matter what you do, the most important part from the user point of view is to make sure you don't break semantics. netfilter/iptables semantics have an intricate notion abut when which chain of which table is executed, in which order, at what particular point of the packet traversal during the network stack. The packet filtering rulesets that people have created over more than 18 years are based on those semantics. If you offer the same interface, but not that very same semantics, the packet filtering policies can an will break - and they will break so in a hidden way. To the user, it appears as if the ruleset is loaded with the assumed semantics, but in reality it isn't. Unless you can replicate those semantics 1:1, I think it is not only wrong to override the iptables sockopt interface, but it's outright dangerous. Having less matches/targets implemented than original iptables is something that I believe is acceptable (and inevitable, at least in the beginning). If somebody tries to load a related ruleset with bpfilter active, it will fail gracefully and the user can chose to not use that match/target in his ruleset, or to not use bpfilter. But if the ruleset loads but behaves different than before (because e.g. it's executed from a completely different place in the stack), that's IMHO an absolute no-go that must be avoided at all cost. If that's the case, you are actively breaking network security, rather than creating it. So I think there's only two ways to go: a) replicate the exact semantics/order of the filter/mangle/raw/... tables and their chains, both among themselves as well as in terms of ordering with other parts of the network stack, or b) not use the existing tables/chains with their pre-defined semantics but rather start new 'tables' which can then have different semantics as defined at the time of their implementation. My apologies if I misunderstood something about bpfilter. Feel free to correct me where I'm wrong. Thanks. Regards, Harald -- - Harald Weltehttp://laforge.gnumonks.org/ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
Re: [PATCH] char: pcmcia: cm4000_cs: Replace mdelay with usleep_range in set_protocol
Hi Jia-Ju Bai, On Sun, Mar 18, 2018 at 10:49:57PM +0800, Jia-Ju Bai wrote: > This is found by a static analysis tool named DCNS written by myself. nice catch! > Signed-off-by: Jia-Ju Bai <baijiaju1...@gmail.com> Acked-by: Harald Welte <lafo...@gnumonks.org> -- - Harald Welte <lafo...@gnumonks.org> http://laforge.gnumonks.org/ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
Re: [PATCH] char: pcmcia: cm4000_cs: Replace mdelay with usleep_range in set_protocol
Hi Jia-Ju Bai, On Sun, Mar 18, 2018 at 10:49:57PM +0800, Jia-Ju Bai wrote: > This is found by a static analysis tool named DCNS written by myself. nice catch! > Signed-off-by: Jia-Ju Bai Acked-by: Harald Welte -- - Harald Weltehttp://laforge.gnumonks.org/ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
Re: [PATCH] platform/x86: panasonic-laptop: add support to mute and hardware optical switch
Hi Kenneth, thanks for your fix. I'm not currently using any Panasonic Laptop devices anymore (After the CF-R series was discontinued), so I'm not able to properly maintain this driver anymore. However, your changes look sound to me (aside from that we don't use C++ style comments in kernel source code), hence: Acked-by: Harald Welte <lafo...@gnumonks.org> -- - Harald Welte <lafo...@gnumonks.org> http://laforge.gnumonks.org/ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
Re: [PATCH] platform/x86: panasonic-laptop: add support to mute and hardware optical switch
Hi Kenneth, thanks for your fix. I'm not currently using any Panasonic Laptop devices anymore (After the CF-R series was discontinued), so I'm not able to properly maintain this driver anymore. However, your changes look sound to me (aside from that we don't use C++ style comments in kernel source code), hence: Acked-by: Harald Welte -- - Harald Weltehttp://laforge.gnumonks.org/ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
Re: [PATCH] netfilter: logging copyrights is useless
Hi Corentin, On Wed, Mar 15, 2017 at 02:17:39PM +0100, Corentin Labbe wrote: > Logging copyrights does not add any useful information in logs. > This patch remove such logging Historically, there were plenty of more copyright notices for certain drivers or sections of the code being printed while booting. I still remember fondly the many ethernet driver notices of a Donald Becker, for example. I understand that it is questionable whether or not such statements are "useful". You might argue, their use is in * stating a legal formality to the user * making it simpler to determine if a given part of code is used in a given device (e.g. as part of GPL enforcement) while just logging the serial console and no requirement to (find a way to) dump the internal flash Besides such practical arguments (it is of what use to whom), there are legal concerns regarding the removal of copyright statements. This holds true on whether or not it is Free Software, or whether or not it is GPL licensed. If an author puts a copyright statement somehwere, he exercises his right to be regarded as the author of the work. It is typically not permitted to remove such notices, as that would be a copyright infringement in itself. Also, beyond general legal concerns, the GPLv2 states explicitly: > c) If the modified program normally reads commands interactively > when run, you must cause it, when started running for such > interactive use in the most ordinary way, to print or display an > announcement including an appropriate copyright notice and a notice > that there is no warranty (or else, saying that you provide a > warranty) and that users may redistribute the program under these > conditions, and telling the user how to view a copy of this License. > (Exception: if the Program itself is interactive but does not normally > print such an announcement, your work based on the Program is not > required to print an announcement.) Now you can argue whether the kernel is a an interactive program, but at least you can see some intent to not remove any notices/messages that were originally present in the program. So I think your patch could only applied if the respective copyright holders agree to remove their respective notices. I personally would argue to keep them. Nobody has complained about them so far, and they have probably saved many weeks of my work time in GPL compliance / enforcement work. I understand this is a "niche use case", though ;) -- - Harald Welte <lafo...@netfilter.org> http://netfilter.org/ "Fragmentation is like classful addressing -- an interesting early architectural error that shows how much experimentation was going on while IP was being designed."-- Paul Vixie
Re: [PATCH] netfilter: logging copyrights is useless
Hi Corentin, On Wed, Mar 15, 2017 at 02:17:39PM +0100, Corentin Labbe wrote: > Logging copyrights does not add any useful information in logs. > This patch remove such logging Historically, there were plenty of more copyright notices for certain drivers or sections of the code being printed while booting. I still remember fondly the many ethernet driver notices of a Donald Becker, for example. I understand that it is questionable whether or not such statements are "useful". You might argue, their use is in * stating a legal formality to the user * making it simpler to determine if a given part of code is used in a given device (e.g. as part of GPL enforcement) while just logging the serial console and no requirement to (find a way to) dump the internal flash Besides such practical arguments (it is of what use to whom), there are legal concerns regarding the removal of copyright statements. This holds true on whether or not it is Free Software, or whether or not it is GPL licensed. If an author puts a copyright statement somehwere, he exercises his right to be regarded as the author of the work. It is typically not permitted to remove such notices, as that would be a copyright infringement in itself. Also, beyond general legal concerns, the GPLv2 states explicitly: > c) If the modified program normally reads commands interactively > when run, you must cause it, when started running for such > interactive use in the most ordinary way, to print or display an > announcement including an appropriate copyright notice and a notice > that there is no warranty (or else, saying that you provide a > warranty) and that users may redistribute the program under these > conditions, and telling the user how to view a copy of this License. > (Exception: if the Program itself is interactive but does not normally > print such an announcement, your work based on the Program is not > required to print an announcement.) Now you can argue whether the kernel is a an interactive program, but at least you can see some intent to not remove any notices/messages that were originally present in the program. So I think your patch could only applied if the respective copyright holders agree to remove their respective notices. I personally would argue to keep them. Nobody has complained about them so far, and they have probably saved many weeks of my work time in GPL compliance / enforcement work. I understand this is a "niche use case", though ;) -- - Harald Welte http://netfilter.org/ "Fragmentation is like classful addressing -- an interesting early architectural error that shows how much experimentation was going on while IP was being designed."-- Paul Vixie
Re: [PATCH] ARM: pxa: ezx: fix a910 camera data
Hi Stefan, On Thu, Nov 24, 2016 at 11:10:09PM +0100, Stefan Schmidt wrote: > Daniel, Harald, if one of you is still interested in these and what to > pick up the work again, please speak up now. :) I have no interest, motivtaion nor time to still work on ezx support. I guess the number of people running a recent kernel on more than 10 year old 2G-only phones is pretty low these days. If anyone has a serious interest in taking this over, I think I still have some A780 and A1200 units that I am happy to provide. Regards, Harald -- - Harald Welte <lafo...@gnumonks.org> http://laforge.gnumonks.org/ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
Re: [PATCH] ARM: pxa: ezx: fix a910 camera data
Hi Stefan, On Thu, Nov 24, 2016 at 11:10:09PM +0100, Stefan Schmidt wrote: > Daniel, Harald, if one of you is still interested in these and what to > pick up the work again, please speak up now. :) I have no interest, motivtaion nor time to still work on ezx support. I guess the number of people running a recent kernel on more than 10 year old 2G-only phones is pretty low these days. If anyone has a serious interest in taking this over, I think I still have some A780 and A1200 units that I am happy to provide. Regards, Harald -- - Harald Weltehttp://laforge.gnumonks.org/ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
Re: [PATCH] pcmcia: cm4040 remove KERN_INFO as it is not at start of printk message
Hi Colin, the fix is obviously correct, but still for a matter of the record: Acked-by: Harald Welte <lafo...@gnumonks.org> -- - Harald Welte <lafo...@gnumonks.org> http://laforge.gnumonks.org/ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
Re: [PATCH] pcmcia: cm4040 remove KERN_INFO as it is not at start of printk message
Hi Colin, the fix is obviously correct, but still for a matter of the record: Acked-by: Harald Welte -- - Harald Weltehttp://laforge.gnumonks.org/ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
Re: [PATCH] platform/x86: panasonic-laptop: set pcc after null device check to avoid null pointer dereference
On Mon, Mar 28, 2016 at 05:26:12PM +0100, Colin King wrote: > Signed-off-by: Colin Ian King <colin.k...@canonical.com> Acked-by: Harald Welte <lafo...@gnumonks.org> -- - Harald Welte <lafo...@gnumonks.org> http://laforge.gnumonks.org/ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
Re: [PATCH] platform/x86: panasonic-laptop: set pcc after null device check to avoid null pointer dereference
On Mon, Mar 28, 2016 at 05:26:12PM +0100, Colin King wrote: > Signed-off-by: Colin Ian King Acked-by: Harald Welte -- - Harald Weltehttp://laforge.gnumonks.org/ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
Re: [PATCH 1/2] pcmcia: cm4000_cs.c: Remove duplicated function names
Hi Rasmus, On Fri, Feb 06, 2015 at 12:17:21AM +0100, Rasmus Villemoes wrote: > The macro DEBUGP already ensures that __func__ is included in the > output, so there's no reason to have the function name in the format > string itself. Acked-by: Harald Welte also for 2/2 of that patch series. Thanks! Regards, Harald -- - Harald Weltehttp://laforge.gnumonks.org/ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] pcmcia: cm4000_cs.c: Remove duplicated function names
Hi Rasmus, On Fri, Feb 06, 2015 at 12:17:21AM +0100, Rasmus Villemoes wrote: The macro DEBUGP already ensures that __func__ is included in the output, so there's no reason to have the function name in the format string itself. Acked-by: Harald Welte lafo...@gnumonks.org also for 2/2 of that patch series. Thanks! Regards, Harald -- - Harald Welte lafo...@gnumonks.org http://laforge.gnumonks.org/ Privacy in residential applications is a desirable marketing option. (ETSI EN 300 175-7 Ch. A6) -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 24/28] proc: Supply an accessor to get the name in a proc_dir_entry struct [RFC]
Hi David, On Tue, Apr 16, 2013 at 07:27:25PM +0100, David Howells wrote: > This is only needed by the xt_hashlimit netfilter module as that appears to > use the name in the pde to save a label in the xt_hashlimit_htable struct - > which will be a problem if CONFIG_PROC_FS=n. I don't know the larger context of this patch (and am not follwing filesystem related work in general), but at least from the xt_hashlimit point of view this of course looks fine. We can always wrap direct accesses to structure members behind an API call. For consistency reasons 'proc_get_name()' might be a better name than get_proc_name(), but that's probably a matter of taste. Pleaes note that I'm only the original author but not the active maintainer of the xt_hashlimit (formerly ipt_hashlimit) code. Regards, Harald -- - Harald Welte http://netfilter.org/ "Fragmentation is like classful addressing -- an interesting early architectural error that shows how much experimentation was going on while IP was being designed."-- Paul Vixie -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 24/28] proc: Supply an accessor to get the name in a proc_dir_entry struct [RFC]
Hi David, On Tue, Apr 16, 2013 at 07:27:25PM +0100, David Howells wrote: This is only needed by the xt_hashlimit netfilter module as that appears to use the name in the pde to save a label in the xt_hashlimit_htable struct - which will be a problem if CONFIG_PROC_FS=n. I don't know the larger context of this patch (and am not follwing filesystem related work in general), but at least from the xt_hashlimit point of view this of course looks fine. We can always wrap direct accesses to structure members behind an API call. For consistency reasons 'proc_get_name()' might be a better name than get_proc_name(), but that's probably a matter of taste. Pleaes note that I'm only the original author but not the active maintainer of the xt_hashlimit (formerly ipt_hashlimit) code. Regards, Harald -- - Harald Welte lafo...@netfilter.org http://netfilter.org/ Fragmentation is like classful addressing -- an interesting early architectural error that shows how much experimentation was going on while IP was being designed.-- Paul Vixie -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org 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] Use get_online_cpus to avoid races involving for_each_online_cpu
Hi Silas, thanks a lot for the finding and addressing the issue. On Thu, Aug 02, 2012 at 05:07:08PM -0700, Silas Boyd-Wickizer wrote: > Signed-off-by: Silas Boyd-Wickizer Acked-by: Harald Welte -- - Harald Weltehttp://laforge.gnumonks.org/ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org 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] Use get_online_cpus to avoid races involving for_each_online_cpu
Hi Silas, thanks a lot for the finding and addressing the issue. On Thu, Aug 02, 2012 at 05:07:08PM -0700, Silas Boyd-Wickizer wrote: Signed-off-by: Silas Boyd-Wickizer s...@mit.edu Acked-by: Harald Welte lafo...@gnumonks.org -- - Harald Welte lafo...@gnumonks.org http://laforge.gnumonks.org/ Privacy in residential applications is a desirable marketing option. (ETSI EN 300 175-7 Ch. A6) -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Fw: [PATCH 1/1] file capabilities: simplify signal check
On Sun, Feb 24, 2008 at 09:09:31PM +0300, Oleg Nesterov wrote: > I just have an almost off-topic (sorry ;) question. Do we really need > kill_pid_info_as_uid() ? Harald Welte cc'ed. > > From "[PATCH] Fix signal sending in usbdevio on async URB completion" > commit 46113830a18847cff8da73005e57bc49c2f95a56 > > > If a process issues an URB from userspace and (starts to) terminate > > before the URB comes back, we run into the issue described above. > This > > is because the urb saves a pointer to "current" when it is posted to > the > > device, but there's no guarantee that this pointer is still valid > > afterwards. > > > > In fact, there are three separate issues: > > > > 1) the pointer to "current" can become invalid, since the task could > be > >completely gone when the URB completion comes back from the device. > > > > 2) Even if the saved task pointer is still pointing to a valid > task_struct, > >task_struct->sighand could have gone meanwhile. > > > > 3) Even if the process is perfectly fine, permissions may have > changed, > >and we can no longer send it a signal. > > The problems 1) and 2) are solved by converting to a struct pid. Is 3) a real > problem? The task which does ioctl(USBDEVFS_SUBMITURB) explicitly asks to send > the signal to it, should we deny the signal even if it changes its credentials > in some way? At the time I discovered the abovementioned problem, '1' and '2' were real practical issues that I was seeing on live systems, triggerable from userspace with no problems. '3' was more of a theoretical issue that was discovered while reading the code and spending some thought on it. I personally am too remote to whatever you're currently doing to the code ('using struct pid') in order to give any comment. The overall process of 'saving the current pointer and re-using it at some later point while the original task might be gone or modified' must work. Whether or not we should deny the signal even if the process changes its own credentials in some way sounds like a much more esoteric question to me. I think it's fair to say that the resulting behavior is "unspecified but shouldn't cause the process and/or kernel to misbehave" At least I'm not aware of any usbdevio logic that would require some specific behaviour here. -- - Harald Welte <[EMAIL PROTECTED]> http://laforge.gnumonks.org/ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) signature.asc Description: Digital signature
Re: Fw: [PATCH 1/1] file capabilities: simplify signal check
On Sun, Feb 24, 2008 at 09:09:31PM +0300, Oleg Nesterov wrote: I just have an almost off-topic (sorry ;) question. Do we really need kill_pid_info_as_uid() ? Harald Welte cc'ed. From [PATCH] Fix signal sending in usbdevio on async URB completion commit 46113830a18847cff8da73005e57bc49c2f95a56 If a process issues an URB from userspace and (starts to) terminate before the URB comes back, we run into the issue described above. This is because the urb saves a pointer to current when it is posted to the device, but there's no guarantee that this pointer is still valid afterwards. In fact, there are three separate issues: 1) the pointer to current can become invalid, since the task could be completely gone when the URB completion comes back from the device. 2) Even if the saved task pointer is still pointing to a valid task_struct, task_struct-sighand could have gone meanwhile. 3) Even if the process is perfectly fine, permissions may have changed, and we can no longer send it a signal. The problems 1) and 2) are solved by converting to a struct pid. Is 3) a real problem? The task which does ioctl(USBDEVFS_SUBMITURB) explicitly asks to send the signal to it, should we deny the signal even if it changes its credentials in some way? At the time I discovered the abovementioned problem, '1' and '2' were real practical issues that I was seeing on live systems, triggerable from userspace with no problems. '3' was more of a theoretical issue that was discovered while reading the code and spending some thought on it. I personally am too remote to whatever you're currently doing to the code ('using struct pid') in order to give any comment. The overall process of 'saving the current pointer and re-using it at some later point while the original task might be gone or modified' must work. Whether or not we should deny the signal even if the process changes its own credentials in some way sounds like a much more esoteric question to me. I think it's fair to say that the resulting behavior is unspecified but shouldn't cause the process and/or kernel to misbehave At least I'm not aware of any usbdevio logic that would require some specific behaviour here. -- - Harald Welte [EMAIL PROTECTED] http://laforge.gnumonks.org/ Privacy in residential applications is a desirable marketing option. (ETSI EN 300 175-7 Ch. A6) signature.asc Description: Digital signature
linux-2.6.24-rcX regression / xserver-xorg-video-intel / Q35
Hi! I'm running an Intel DQ35JO mainboard (Q35 chipset, Q6600 CPU) and I am observing a regression with linux-2.6.24-rc1 through -rc6 (linux-2.6.git as of today, ea67db4cdbbf7f4e74150e71da0984e25121f500). The last working version is 2.6.24-rc1. The system is running debian unstable (current) using xserver-xorg-video-intel 2.2.0-1 So what is the actual problem: It seems to be related to the way how the iommu/gart is used for memory allocation of the framebuffer memory. Xorg starts just as it should, but the lower part of the screen is completely gobbled. I suppose the lower part of the screen is actually showing off-screen memory at some completely differnt location. Interestingly, the mouse cursor is superimposed on top of the garbage (and it is not distorted). The visible effect can be observed at the following screenshot: http://ganesha.gnumonks.org/~laforge/tmp/2624rc_xorg_intel.jpg lspci: 00:00.0 Host bridge: Intel Corporation Unknown device 29b0 (rev 02) 00:02.0 VGA compatible controller: Intel Corporation Unknown device 29b2 (rev 02) 00:02.1 Display controller: Intel Corporation Unknown device 29b3 (rev 02) 00:02.0 VGA compatible controller: Intel Corporation Unknown device 29b2 (rev 02) (prog-if 00 [VGA]) Subsystem: Intel Corporation Unknown device 4f4a Flags: bus master, fast devsel, latency 0, IRQ 11 Memory at e038 (32-bit, non-prefetchable) [size=512K] I/O ports at 2430 [size=8] Memory at d000 (32-bit, prefetchable) [size=256M] Memory at e020 (32-bit, non-prefetchable) [size=1M] Capabilities: [90] Message Signalled Interrupts: Mask- 64bit- Queue=0/0 Enable- Capabilities: [d0] Power Management version 2 00:02.1 Display controller: Intel Corporation Unknown device 29b3 (rev 02) Subsystem: Intel Corporation Unknown device 4f4a Flags: bus master, fast devsel, latency 0 Memory at e030 (32-bit, non-prefetchable) [size=512K] Capabilities: [d0] Power Management version 2 Please let me know if I should provide more details. I'm also happy to test any patches :) Cheers, -- - Harald Welte <[EMAIL PROTECTED]> http://gnumonks.org/ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) -- 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/
linux-2.6.24-rcX regression / xserver-xorg-video-intel / Q35
Hi! I'm running an Intel DQ35JO mainboard (Q35 chipset, Q6600 CPU) and I am observing a regression with linux-2.6.24-rc1 through -rc6 (linux-2.6.git as of today, ea67db4cdbbf7f4e74150e71da0984e25121f500). The last working version is 2.6.24-rc1. The system is running debian unstable (current) using xserver-xorg-video-intel 2.2.0-1 So what is the actual problem: It seems to be related to the way how the iommu/gart is used for memory allocation of the framebuffer memory. Xorg starts just as it should, but the lower part of the screen is completely gobbled. I suppose the lower part of the screen is actually showing off-screen memory at some completely differnt location. Interestingly, the mouse cursor is superimposed on top of the garbage (and it is not distorted). The visible effect can be observed at the following screenshot: http://ganesha.gnumonks.org/~laforge/tmp/2624rc_xorg_intel.jpg lspci: 00:00.0 Host bridge: Intel Corporation Unknown device 29b0 (rev 02) 00:02.0 VGA compatible controller: Intel Corporation Unknown device 29b2 (rev 02) 00:02.1 Display controller: Intel Corporation Unknown device 29b3 (rev 02) 00:02.0 VGA compatible controller: Intel Corporation Unknown device 29b2 (rev 02) (prog-if 00 [VGA]) Subsystem: Intel Corporation Unknown device 4f4a Flags: bus master, fast devsel, latency 0, IRQ 11 Memory at e038 (32-bit, non-prefetchable) [size=512K] I/O ports at 2430 [size=8] Memory at d000 (32-bit, prefetchable) [size=256M] Memory at e020 (32-bit, non-prefetchable) [size=1M] Capabilities: [90] Message Signalled Interrupts: Mask- 64bit- Queue=0/0 Enable- Capabilities: [d0] Power Management version 2 00:02.1 Display controller: Intel Corporation Unknown device 29b3 (rev 02) Subsystem: Intel Corporation Unknown device 4f4a Flags: bus master, fast devsel, latency 0 Memory at e030 (32-bit, non-prefetchable) [size=512K] Capabilities: [d0] Power Management version 2 Please let me know if I should provide more details. I'm also happy to test any patches :) Cheers, -- - Harald Welte [EMAIL PROTECTED] http://gnumonks.org/ Privacy in residential applications is a desirable marketing option. (ETSI EN 300 175-7 Ch. A6) -- 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] Samsung S3C24xx SD/MMC driver
Hi Pierre, thanks for your comments. On Wed, Dec 19, 2007 at 05:54:33PM +0100, Pierre Ossman wrote: > Well, my biggest beef with this driver is the excessive debug code. I > did a cleanup in an older version of the driver, but it shouldn't be > to difficult to do the same for this one. I've included my patch for > reference. ok, I'll re-work the patch according to your sample and re-submit. The debugging was needed during development, and might still be needed to debug some weird issues. btw: OpenMoko is currently working on an ar6k wifi driver on top of the new mainline kernel SDIO support using the s3c_mci host controller driver as basis. So within not-too-distant-time we should also be able to have SDIO working and tested on s3c_mci. > > Index: linux-2.6/drivers/mmc/host/s3cmci.c > > === > > --- /dev/null > > +++ linux-2.6/drivers/mmc/host/s3cmci.c > > > +#include > > This is always a warning sign. It should never be needed in a host driver. ok, will see how to remove it. > > + *words = sg->length >> 2; > > + *pointer = page_address(sg_page(sg)) + sg->offset; > > + > > The length might not be a multiple of four. And it might also be > completely unaligned. Make sure you can either handle such requests, > or fail them with -EINVAL. ok, will update before submitting the next version. -- - Harald Welte <[EMAIL PROTECTED]> http://openmoko.org/ Software for the world's first truly open Free Software mobile phone -- 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] Samsung S3C24xx SD/MMC driver
Hi! This is a MMC/SD driver for the Samsung S3C24xx SD/MMC controller, originally developed years ago by Thomas Kleffel <[EMAIL PROTECTED]>. Due to time constraints, he had no time to further maintain the driver and follow the mainline Linux changes in the SD/MMC stack. With his authorization, I have taken over the task of making it compliant to the current mainline SD/MMC API and take care of the mainline kernel merge. So please advise on whatever changes you deem neccessary and I'll try to do my best to incorporate them for a hopefully not-too-distant mainline merge. After a potential kernel inclusion, we would co-maintain the driver. Acked-by: Thomas Kleffel <[EMAIL PROTECTED]> Signed-off-by: Harald Welte <[EMAIL PROTECTED]> --- Index: linux-2.6/include/asm-arm/arch-s3c2410/regs-sdi.h === --- linux-2.6.orig/include/asm-arm/arch-s3c2410/regs-sdi.h +++ linux-2.6/include/asm-arm/arch-s3c2410/regs-sdi.h @@ -28,9 +28,15 @@ #define S3C2410_SDIDCNT (0x30) #define S3C2410_SDIDSTA (0x34) #define S3C2410_SDIFSTA (0x38) + #define S3C2410_SDIDATA (0x3C) #define S3C2410_SDIIMSK (0x40) +#define S3C2440_SDIDATA (0x40) +#define S3C2440_SDIIMSK (0x3C) + +#define S3C2440_SDICON_SDRESET(1<<8) +#define S3C2440_SDICON_MMCCLOCK (1<<5) #define S3C2410_SDICON_BYTEORDER (1<<4) #define S3C2410_SDICON_SDIOIRQ(1<<3) #define S3C2410_SDICON_RWAITEN(1<<2) @@ -42,7 +48,8 @@ #define S3C2410_SDICMDCON_LONGRSP (1<<10) #define S3C2410_SDICMDCON_WAITRSP (1<<9) #define S3C2410_SDICMDCON_CMDSTART(1<<8) -#define S3C2410_SDICMDCON_INDEX (0xff) +#define S3C2410_SDICMDCON_SENDERHOST (1<<6) +#define S3C2410_SDICMDCON_INDEX (0x3f) #define S3C2410_SDICMDSTAT_CRCFAIL(1<<12) #define S3C2410_SDICMDSTAT_CMDSENT(1<<11) @@ -51,6 +58,9 @@ #define S3C2410_SDICMDSTAT_XFERING(1<<8) #define S3C2410_SDICMDSTAT_INDEX (0xff) +#define S3C2440_SDIDCON_DS_BYTE (0<<22) +#define S3C2440_SDIDCON_DS_HALFWORD (1<<22) +#define S3C2440_SDIDCON_DS_WORD (2<<22) #define S3C2410_SDIDCON_IRQPERIOD (1<<21) #define S3C2410_SDIDCON_TXAFTERRESP (1<<20) #define S3C2410_SDIDCON_RXAFTERCMD(1<<19) @@ -59,6 +69,7 @@ #define S3C2410_SDIDCON_WIDEBUS (1<<16) #define S3C2410_SDIDCON_DMAEN (1<<15) #define S3C2410_SDIDCON_STOP (1<<14) +#define S3C2440_SDIDCON_DATSTART (1<<14) #define S3C2410_SDIDCON_DATMODE (3<<12) #define S3C2410_SDIDCON_BLKNUM(0x7ff) @@ -68,6 +79,7 @@ #define S3C2410_SDIDCON_XFER_RXSTART (2<<12) #define S3C2410_SDIDCON_XFER_TXSTART (3<<12) +#define S3C2410_SDIDCON_BLKNUM_MASK (0xFFF) #define S3C2410_SDIDCNT_BLKNUM_SHIFT (12) #define S3C2410_SDIDSTA_RDYWAITREQ(1<<10) @@ -82,10 +94,12 @@ #define S3C2410_SDIDSTA_TXDATAON (1<<1) #define S3C2410_SDIDSTA_RXDATAON (1<<0) +#define S3C2440_SDIFSTA_FIFORESET (1<<16) +#define S3C2440_SDIFSTA_FIFOFAIL (3<<14) /* 3 is correct (2 bits) */ #define S3C2410_SDIFSTA_TFDET (1<<13) #define S3C2410_SDIFSTA_RFDET (1<<12) -#define S3C2410_SDIFSTA_TXHALF (1<<11) -#define S3C2410_SDIFSTA_TXEMPTY(1<<10) +#define S3C2410_SDIFSTA_TFHALF (1<<11) +#define S3C2410_SDIFSTA_TFEMPTY(1<<10) #define S3C2410_SDIFSTA_RFLAST (1<<9) #define S3C2410_SDIFSTA_RFFULL (1<<8) #define S3C2410_SDIFSTA_RFHALF (1<<7) Index: linux-2.6/drivers/mmc/host/s3cmci.c === --- /dev/null +++ linux-2.6/drivers/mmc/host/s3cmci.c @@ -0,0 +1,1409 @@ +/* + * linux/drivers/mmc/s3cmci.h - Samsung S3C MCI driver + * + * Copyright (C) 2004-2006 maintech GmbH, Thomas Kleffel <[EMAIL PROTECTED]> + * Copyright (C) 2007 OpenMoko, Inc., Harald Welte <[EMAIL PROTECTED]> + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. + */ + +#include +#include +#include +#include +#include +#include +#include + +#include +#include + +#include +#include +#include +#include + +#include "s3cmci.h" + +#define DRIVER_NAME "s3c-mci" + +enum dbg_channels { + dbg_err = (1 << 0), + dbg_debug = (1 << 1), + dbg_info = (1 << 2), + dbg_irq = (1 << 3), + dbg_sg= (1 << 4), + dbg_dma = (1 << 5), + dbg_pio = (1 << 6), + dbg_fail = (1 <&
[PATCH] Samsung S3C24xx SD/MMC driver
Hi! This is a MMC/SD driver for the Samsung S3C24xx SD/MMC controller, originally developed years ago by Thomas Kleffel [EMAIL PROTECTED]. Due to time constraints, he had no time to further maintain the driver and follow the mainline Linux changes in the SD/MMC stack. With his authorization, I have taken over the task of making it compliant to the current mainline SD/MMC API and take care of the mainline kernel merge. So please advise on whatever changes you deem neccessary and I'll try to do my best to incorporate them for a hopefully not-too-distant mainline merge. After a potential kernel inclusion, we would co-maintain the driver. Acked-by: Thomas Kleffel [EMAIL PROTECTED] Signed-off-by: Harald Welte [EMAIL PROTECTED] --- Index: linux-2.6/include/asm-arm/arch-s3c2410/regs-sdi.h === --- linux-2.6.orig/include/asm-arm/arch-s3c2410/regs-sdi.h +++ linux-2.6/include/asm-arm/arch-s3c2410/regs-sdi.h @@ -28,9 +28,15 @@ #define S3C2410_SDIDCNT (0x30) #define S3C2410_SDIDSTA (0x34) #define S3C2410_SDIFSTA (0x38) + #define S3C2410_SDIDATA (0x3C) #define S3C2410_SDIIMSK (0x40) +#define S3C2440_SDIDATA (0x40) +#define S3C2440_SDIIMSK (0x3C) + +#define S3C2440_SDICON_SDRESET(18) +#define S3C2440_SDICON_MMCCLOCK (15) #define S3C2410_SDICON_BYTEORDER (14) #define S3C2410_SDICON_SDIOIRQ(13) #define S3C2410_SDICON_RWAITEN(12) @@ -42,7 +48,8 @@ #define S3C2410_SDICMDCON_LONGRSP (110) #define S3C2410_SDICMDCON_WAITRSP (19) #define S3C2410_SDICMDCON_CMDSTART(18) -#define S3C2410_SDICMDCON_INDEX (0xff) +#define S3C2410_SDICMDCON_SENDERHOST (16) +#define S3C2410_SDICMDCON_INDEX (0x3f) #define S3C2410_SDICMDSTAT_CRCFAIL(112) #define S3C2410_SDICMDSTAT_CMDSENT(111) @@ -51,6 +58,9 @@ #define S3C2410_SDICMDSTAT_XFERING(18) #define S3C2410_SDICMDSTAT_INDEX (0xff) +#define S3C2440_SDIDCON_DS_BYTE (022) +#define S3C2440_SDIDCON_DS_HALFWORD (122) +#define S3C2440_SDIDCON_DS_WORD (222) #define S3C2410_SDIDCON_IRQPERIOD (121) #define S3C2410_SDIDCON_TXAFTERRESP (120) #define S3C2410_SDIDCON_RXAFTERCMD(119) @@ -59,6 +69,7 @@ #define S3C2410_SDIDCON_WIDEBUS (116) #define S3C2410_SDIDCON_DMAEN (115) #define S3C2410_SDIDCON_STOP (114) +#define S3C2440_SDIDCON_DATSTART (114) #define S3C2410_SDIDCON_DATMODE (312) #define S3C2410_SDIDCON_BLKNUM(0x7ff) @@ -68,6 +79,7 @@ #define S3C2410_SDIDCON_XFER_RXSTART (212) #define S3C2410_SDIDCON_XFER_TXSTART (312) +#define S3C2410_SDIDCON_BLKNUM_MASK (0xFFF) #define S3C2410_SDIDCNT_BLKNUM_SHIFT (12) #define S3C2410_SDIDSTA_RDYWAITREQ(110) @@ -82,10 +94,12 @@ #define S3C2410_SDIDSTA_TXDATAON (11) #define S3C2410_SDIDSTA_RXDATAON (10) +#define S3C2440_SDIFSTA_FIFORESET (116) +#define S3C2440_SDIFSTA_FIFOFAIL (314) /* 3 is correct (2 bits) */ #define S3C2410_SDIFSTA_TFDET (113) #define S3C2410_SDIFSTA_RFDET (112) -#define S3C2410_SDIFSTA_TXHALF (111) -#define S3C2410_SDIFSTA_TXEMPTY(110) +#define S3C2410_SDIFSTA_TFHALF (111) +#define S3C2410_SDIFSTA_TFEMPTY(110) #define S3C2410_SDIFSTA_RFLAST (19) #define S3C2410_SDIFSTA_RFFULL (18) #define S3C2410_SDIFSTA_RFHALF (17) Index: linux-2.6/drivers/mmc/host/s3cmci.c === --- /dev/null +++ linux-2.6/drivers/mmc/host/s3cmci.c @@ -0,0 +1,1409 @@ +/* + * linux/drivers/mmc/s3cmci.h - Samsung S3C MCI driver + * + * Copyright (C) 2004-2006 maintech GmbH, Thomas Kleffel [EMAIL PROTECTED] + * Copyright (C) 2007 OpenMoko, Inc., Harald Welte [EMAIL PROTECTED] + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. + */ + +#include linux/module.h +#include linux/dma-mapping.h +#include linux/clk.h +#include linux/mmc/mmc.h +#include linux/mmc/host.h +#include linux/platform_device.h +#include linux/irq.h + +#include asm/dma.h +#include asm/dma-mapping.h + +#include asm/io.h +#include asm/arch/regs-sdi.h +#include asm/arch/regs-gpio.h +#include asm/arch/mci.h + +#include s3cmci.h + +#define DRIVER_NAME s3c-mci + +enum dbg_channels { + dbg_err = (1 0), + dbg_debug = (1 1), + dbg_info = (1 2), + dbg_irq = (1 3), + dbg_sg= (1 4), + dbg_dma = (1 5), + dbg_pio = (1 6), + dbg_fail = (1 7), + dbg_conf = (1 8), +}; + +static const int dbgmap_err = dbg_err | dbg_fail; +static const int dbgmap_info = dbg_info | dbg_conf; +static const int dbgmap_debug = dbg_debug; + +#define dbg(host, channels, args...)\ + do
Re: [PATCH] Samsung S3C24xx SD/MMC driver
Hi Pierre, thanks for your comments. On Wed, Dec 19, 2007 at 05:54:33PM +0100, Pierre Ossman wrote: Well, my biggest beef with this driver is the excessive debug code. I did a cleanup in an older version of the driver, but it shouldn't be to difficult to do the same for this one. I've included my patch for reference. ok, I'll re-work the patch according to your sample and re-submit. The debugging was needed during development, and might still be needed to debug some weird issues. btw: OpenMoko is currently working on an ar6k wifi driver on top of the new mainline kernel SDIO support using the s3c_mci host controller driver as basis. So within not-too-distant-time we should also be able to have SDIO working and tested on s3c_mci. Index: linux-2.6/drivers/mmc/host/s3cmci.c === --- /dev/null +++ linux-2.6/drivers/mmc/host/s3cmci.c +#include linux/mmc/mmc.h This is always a warning sign. It should never be needed in a host driver. ok, will see how to remove it. + *words = sg-length 2; + *pointer = page_address(sg_page(sg)) + sg-offset; + The length might not be a multiple of four. And it might also be completely unaligned. Make sure you can either handle such requests, or fail them with -EINVAL. ok, will update before submitting the next version. -- - Harald Welte [EMAIL PROTECTED] http://openmoko.org/ Software for the world's first truly open Free Software mobile phone -- 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: HTC TyTN || (P4550) violates GPL?? Or maybe Qualcomm itself with MSM7200???
Hi, this is Harald from gpl-violations.org. Given my involvement with projects like OpenEZX and OpenMoko, I was obviosuly very interested in investigating this issue. CIJOML wrote: Hi there, it looks like there is running linux somewhere inside in the radio part of the firmware... http://forum.xda-developers.com/archive/index.php/t-326419.html $ strings kaiser_radio_0x301.nb |grep -i linux M6500C L4/Linux L4 Linux NICTNICTA::Pistachio - built on Jan 23 2007 18:10:22 by [EMAIL PROTECTED] using gcc version 3.4.1 start_linux_cmd vmlinux != NULL vmlinux vmlinux igms_name=ramdisk root=/dev/igms0 start_linux Can anybody else confirm this and contact those companies for source codes? I have confirmed that the abovementioned strings are present in the radio firmware of the device. However, after a detailed analysis (spent the better part of yesterday looking at the various L4 sources and the firmware binary) it seems evident that the strings are part of the linux loader, i.e. the part of L4 that can execute a specially-modified linux kernel (called wombat). The lua startup script of the radio firmware does not execute the start_linux function but rather only the start_server function to start a number of proprietary servers on top of the microkernel. So at least up to this level of analysis, I cannot find any reason to believe there is Linux in the radio firmware. However, this obviously is also no hard proof. If anyone still has reason to believe Linux is used in the radio firmware of the Qualcomm MSM7200 chipset, please let me know. I'm happy to investigate in case new evidence comes up. As a side note, it would be the most stupid thing to do for a GSM chipset vendor. In all existing smartphone chipsets you have two CPU cores (an ARM9 for baseband and ARM11 for the UI/apps in the MSM7200) to avoid any licensing and regulatory issues arising from running the GSM stack in the more-or-less open OS on the application side (Windows Mobile, Linux, ...) Cheers, - Harald Welte <[EMAIL PROTECTED]> http://gnumonks.org/ We all know Linux is great...it does infinite loops in 5 seconds. -- Linus -- 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: HTC TyTN || (P4550) violates GPL?? Or maybe Qualcomm itself with MSM7200???
Hi, this is Harald from gpl-violations.org. Given my involvement with projects like OpenEZX and OpenMoko, I was obviosuly very interested in investigating this issue. CIJOML wrote: Hi there, it looks like there is running linux somewhere inside in the radio part of the firmware... http://forum.xda-developers.com/archive/index.php/t-326419.html $ strings kaiser_radio_0x301.nb |grep -i linux M6500C L4/Linux L4 Linux NICTNICTA::Pistachio - built on Jan 23 2007 18:10:22 by [EMAIL PROTECTED] using gcc version 3.4.1 start_linux_cmd vmlinux != NULL vmlinux vmlinux igms_name=ramdisk root=/dev/igms0 start_linux Can anybody else confirm this and contact those companies for source codes? I have confirmed that the abovementioned strings are present in the radio firmware of the device. However, after a detailed analysis (spent the better part of yesterday looking at the various L4 sources and the firmware binary) it seems evident that the strings are part of the linux loader, i.e. the part of L4 that can execute a specially-modified linux kernel (called wombat). The lua startup script of the radio firmware does not execute the start_linux function but rather only the start_server function to start a number of proprietary servers on top of the microkernel. So at least up to this level of analysis, I cannot find any reason to believe there is Linux in the radio firmware. However, this obviously is also no hard proof. If anyone still has reason to believe Linux is used in the radio firmware of the Qualcomm MSM7200 chipset, please let me know. I'm happy to investigate in case new evidence comes up. As a side note, it would be the most stupid thing to do for a GSM chipset vendor. In all existing smartphone chipsets you have two CPU cores (an ARM9 for baseband and ARM11 for the UI/apps in the MSM7200) to avoid any licensing and regulatory issues arising from running the GSM stack in the more-or-less open OS on the application side (Windows Mobile, Linux, ...) Cheers, - Harald Welte [EMAIL PROTECTED] http://gnumonks.org/ We all know Linux is great...it does infinite loops in 5 seconds. -- Linus -- 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 br_fdb_fini() section mismatch
When compiling a kernel (current linus git or 2.6.24-rc4) with built-in CONFIG_BRIDGE, I get the following error: LD .tmp_vmlinux1 `br_fdb_fini' referenced in section `.init.text' of net/built-in.o: defined in discarded section `.exit.text' of net/built-in.o make: *** [.tmp_vmlinux1] Error 1 This patch fixes it. Signed-off-by: Harald Welte <[EMAIL PROTECTED]> diff --git a/net/bridge/br_fdb.c b/net/bridge/br_fdb.c index eb57502..bc40377 100644 --- a/net/bridge/br_fdb.c +++ b/net/bridge/br_fdb.c @@ -44,7 +44,7 @@ int __init br_fdb_init(void) return 0; } -void __exit br_fdb_fini(void) +void br_fdb_fini(void) { kmem_cache_destroy(br_fdb_cache); } -- - Harald Welte <[EMAIL PROTECTED]> http://gnumonks.org/ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) -- 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 br_fdb_fini() section mismatch
When compiling a kernel (current linus git or 2.6.24-rc4) with built-in CONFIG_BRIDGE, I get the following error: LD .tmp_vmlinux1 `br_fdb_fini' referenced in section `.init.text' of net/built-in.o: defined in discarded section `.exit.text' of net/built-in.o make: *** [.tmp_vmlinux1] Error 1 This patch fixes it. Signed-off-by: Harald Welte [EMAIL PROTECTED] diff --git a/net/bridge/br_fdb.c b/net/bridge/br_fdb.c index eb57502..bc40377 100644 --- a/net/bridge/br_fdb.c +++ b/net/bridge/br_fdb.c @@ -44,7 +44,7 @@ int __init br_fdb_init(void) return 0; } -void __exit br_fdb_fini(void) +void br_fdb_fini(void) { kmem_cache_destroy(br_fdb_cache); } -- - Harald Welte [EMAIL PROTECTED] http://gnumonks.org/ Privacy in residential applications is a desirable marketing option. (ETSI EN 300 175-7 Ch. A6) -- 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: basic support for neo1973
On Thu, Apr 05, 2007 at 10:48:50AM +0200, Pavel Machek wrote: > This adds very basic support for fic1973 (aka gta01, aka > openmoko). With this patch applied, I can boot the kernel and actually > see the messages. please coordinate with Ben Dooks. He's the 24xx maintainer and has already picked up a number of our changes for mainline merging in the next merge window. -- - Harald Welte <[EMAIL PROTECTED]> http://openmoko.org/ Software for the world's first truly open Free Software mobile phone - 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: basic support for neo1973
On Thu, Apr 05, 2007 at 10:48:50AM +0200, Pavel Machek wrote: This adds very basic support for fic1973 (aka gta01, aka openmoko). With this patch applied, I can boot the kernel and actually see the messages. please coordinate with Ben Dooks. He's the 24xx maintainer and has already picked up a number of our changes for mainline merging in the next merge window. -- - Harald Welte [EMAIL PROTECTED] http://openmoko.org/ Software for the world's first truly open Free Software mobile phone - 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] Omnikey Cardman 4000 driver
On Mon, Sep 05, 2005 at 12:44:37PM -0700, Nish Aravamudan wrote: > It looks like all callers of these functions pass in milliseconds? Any > chance you can get rid of these two and use msleep_interruptible() and > msleep() instead? As long as you are not using these functions around > wait-queues, you are ok (which I think is the case here). Ok, I've changed the driver accordingly and I'll repost after some more testing. -- - Harald Welte <[EMAIL PROTECTED]> http://gnumonks.org/ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) pgpUMyh6qs3p1.pgp Description: PGP signature
Re: [PATCH] Omnikey Cardman 4000 driver
On Mon, Sep 05, 2005 at 12:44:37PM -0700, Nish Aravamudan wrote: It looks like all callers of these functions pass in milliseconds? Any chance you can get rid of these two and use msleep_interruptible() and msleep() instead? As long as you are not using these functions around wait-queues, you are ok (which I think is the case here). Ok, I've changed the driver accordingly and I'll repost after some more testing. -- - Harald Welte [EMAIL PROTECTED] http://gnumonks.org/ Privacy in residential applications is a desirable marketing option. (ETSI EN 300 175-7 Ch. A6) pgpUMyh6qs3p1.pgp Description: PGP signature
Re: [PATCH] Omnikey Cardman 4040 driver (UPDATE)
Hi hch, thanks for your feedback. An updated version of the patch is at the bottom of this mail. On Mon, Sep 05, 2005 at 08:06:35PM +0100, Christoph Hellwig wrote: > > +#include > > I don't think you need this one. done > > +#include > > you shouldn't need this one. done > > +static atomic_t cm4040_num_devices_open; > > + > > +#ifdef PCMCIA_DEBUG > > +static int pc_debug = PCMCIA_DEBUG; > > +module_param(pc_debug, int, 0600); > > +#define DEBUG(n, x, args...) do { if (pc_debug >= (n)) > > \ > > + printk(KERN_DEBUG "%s:%s:" x, MODULE_NAME, \ > > +__FUNCTION__, ##args); } while (0) > > +#else > > +#define DEBUG(n, args...) > > +#endif > > What about just using pr_debug (or dev_dbg where you have a struct device > handy) I really appreciate the multiple debug levels of the driver, sorry. However, I have converted the DEBUG macro to use dev_printk as a compromise. > Please make the poll timer per device. We generally try to avoid > global state, and this allows to get rid of the opencount tracking aswell. done. > > +static ssize_t cm4040_read(struct file *filp, char __user *buf, > > + size_t count, loff_t *ppos) > > +{ > > + struct reader_dev *dev = (struct reader_dev *) filp->private_data; > > no need to case a void pointer. well, but good style in my opioion anyway. Anway, I don't really mind, so it has been removed. > > + if (count < 10) > > + return -EFAULT; > > + > > + if (filp->f_flags & O_NONBLOCK) { > > + DEBUG(4, "filep->f_flags O_NONBLOCK set\n"); > > + DEBUG(2, "<- cm4040_read (failure)\n"); > > + return -EAGAIN; > > + } > > this sounds rather pointless. letting an O_NONBLOCK open fail all > the time doesn't sound like a good idea. what about fcntl enabling NONBLOCK after the open? Other character drivers (such as rtc) do the same, btw. Is there any way how I can tell the VFS to make any nonblocking operation fail? > please use iminor. done. > given that you fail O_NONLOCK in open already the code above makes even > less sense. see my comment above. > > + dev->owner = current; > > this doesn't make a lot of sense and seems to be only used in > debug code, I'd suggest killing it. done. > you should be able to use file->private_data here. done > I think these events became methods of their own recently, not sure > if it hit -mm or mainline yet. I cannot find anything like that in mainline, thus my code remains unchanged for now. diff --git a/MAINTAINERS b/MAINTAINERS --- a/MAINTAINERS +++ b/MAINTAINERS @@ -1737,6 +1737,11 @@ L: [EMAIL PROTECTED] W: http://www.linuxtr.net S: Maintained +OMNIKEY CARDMAN 4040 DRIVER +P: Harald Welte +M: [EMAIL PROTECTED] +S: Maintained + ONSTREAM SCSI TAPE DRIVER P: Willem Riede M: [EMAIL PROTECTED] diff --git a/drivers/char/pcmcia/Kconfig b/drivers/char/pcmcia/Kconfig --- a/drivers/char/pcmcia/Kconfig +++ b/drivers/char/pcmcia/Kconfig @@ -18,5 +18,18 @@ config SYNCLINK_CS The module will be called synclinkmp. If you want to do that, say M here. +config CARDMAN_4040 + tristate "Omnikey CardMan 4040 support" + depends on PCMCIA + help + Enable support for the Omnikey CardMan 4040 PCMCIA Smartcard + reader. + + This card is basically a USB CCID device connected to a FIFO + in I/O space. To use the kernel driver, you will need either the + PC/SC ifdhandler provided from the Omnikey homepage + (http://www.omnikey.com/), or a current development version of OpenCT + (http://www.opensc.org/). + endmenu diff --git a/drivers/char/pcmcia/Makefile b/drivers/char/pcmcia/Makefile --- a/drivers/char/pcmcia/Makefile +++ b/drivers/char/pcmcia/Makefile @@ -5,3 +5,4 @@ # obj-$(CONFIG_SYNCLINK_CS) += synclink_cs.o +obj-$(CONFIG_CARDMAN_4040) += cm4040_cs.o diff --git a/drivers/char/pcmcia/cm4040_cs.c b/drivers/char/pcmcia/cm4040_cs.c new file mode 100644 --- /dev/null +++ b/drivers/char/pcmcia/cm4040_cs.c @@ -0,0 +1,835 @@ +/* + * A driver for the Omnikey PCMCIA smartcard reader CardMan 4040 + * + * (c) 2000-2004 Omnikey AG (http://www.omnikey.com/) + * + * (C) 2005 Harald Welte <[EMAIL PROTECTED]> + * - add support for poll() + * - driver cleanup + * - add waitqueues + * - adhere to linux kernel coding style and policies + * - support 2.6.13 "new style" pcmcia interface + * + * The device basically is a USB CCID compliant device that has been + * attached to an I/O-Mapped FIFO. + * + * All rights reserved,
Re: [PATCH] New: Omnikey CardMan 4040 PCMCIA Driver
On Tue, Sep 06, 2005 at 09:15:10AM -0700, Roland Dreier wrote: > Harald> Obviously, if HZ would ever go below 100, the code above > Harald> would provide some problems. I'm not sure what the future > Harald> plans with HZ are, but I'll add an #error statement in > Harald> case HZ goes smaller than that. > > It might be simpler just to define it to msecs_to_jiffies(10). That's what I did in the last version that was posted to lkml ;) -- - Harald Welte <[EMAIL PROTECTED]> http://gnumonks.org/ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) pgp7m8zaAY3Vq.pgp Description: PGP signature
Re: [PATCH] Omnikey Cardman 4000 driver
On Mon, Sep 05, 2005 at 10:36:57PM +0200, Jesper Juhl wrote: > On 9/6/05, Harald Welte <[EMAIL PROTECTED]> wrote: > > Hi! > > > [snip] > > > > Please consider mergin mainline, thanks. > > > [snip] > > Wouldn't it be better to first merge it in -mm and get some wider > testing before pushing for mainline? From my past experience (I'm involved in writing smartcard reader drivers for some time now), users of smartcard readers tend to be "typical corporate users" who won't run anything but the distribution kernel. I really doubt that the drivers would get much more testing in -mm than they would in mainline. Also, what is the point of putting entirely new code (no changes to existing code!) into -mm? I understand that changes to existing code can inarguably benefit from some testing in -mm first. But new drivers? Where's the point? The devices are not supported in the existing kernel, so it cannot get worse by having a driver (even if it still contains one or the other bug). -- - Harald Welte <[EMAIL PROTECTED]> http://gnumonks.org/ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) pgp3yXjcwvAf4.pgp Description: PGP signature
Re: [PATCH] Omnikey Cardman 4000 driver
On Mon, Sep 05, 2005 at 10:36:57PM +0200, Jesper Juhl wrote: On 9/6/05, Harald Welte [EMAIL PROTECTED] wrote: Hi! [snip] Please consider mergin mainline, thanks. [snip] Wouldn't it be better to first merge it in -mm and get some wider testing before pushing for mainline? From my past experience (I'm involved in writing smartcard reader drivers for some time now), users of smartcard readers tend to be typical corporate users who won't run anything but the distribution kernel. I really doubt that the drivers would get much more testing in -mm than they would in mainline. Also, what is the point of putting entirely new code (no changes to existing code!) into -mm? I understand that changes to existing code can inarguably benefit from some testing in -mm first. But new drivers? Where's the point? The devices are not supported in the existing kernel, so it cannot get worse by having a driver (even if it still contains one or the other bug). -- - Harald Welte [EMAIL PROTECTED] http://gnumonks.org/ Privacy in residential applications is a desirable marketing option. (ETSI EN 300 175-7 Ch. A6) pgp3yXjcwvAf4.pgp Description: PGP signature
Re: [PATCH] New: Omnikey CardMan 4040 PCMCIA Driver
On Tue, Sep 06, 2005 at 09:15:10AM -0700, Roland Dreier wrote: Harald Obviously, if HZ would ever go below 100, the code above Harald would provide some problems. I'm not sure what the future Harald plans with HZ are, but I'll add an #error statement in Harald case HZ goes smaller than that. It might be simpler just to define it to msecs_to_jiffies(10). That's what I did in the last version that was posted to lkml ;) -- - Harald Welte [EMAIL PROTECTED] http://gnumonks.org/ Privacy in residential applications is a desirable marketing option. (ETSI EN 300 175-7 Ch. A6) pgp7m8zaAY3Vq.pgp Description: PGP signature
Re: [PATCH] Omnikey Cardman 4040 driver (UPDATE)
Hi hch, thanks for your feedback. An updated version of the patch is at the bottom of this mail. On Mon, Sep 05, 2005 at 08:06:35PM +0100, Christoph Hellwig wrote: +#include linux/version.h I don't think you need this one. done +#include pcmcia/version.h you shouldn't need this one. done +static atomic_t cm4040_num_devices_open; + +#ifdef PCMCIA_DEBUG +static int pc_debug = PCMCIA_DEBUG; +module_param(pc_debug, int, 0600); +#define DEBUG(n, x, args...) do { if (pc_debug = (n)) \ + printk(KERN_DEBUG %s:%s: x, MODULE_NAME, \ +__FUNCTION__, ##args); } while (0) +#else +#define DEBUG(n, args...) +#endif What about just using pr_debug (or dev_dbg where you have a struct device handy) I really appreciate the multiple debug levels of the driver, sorry. However, I have converted the DEBUG macro to use dev_printk as a compromise. Please make the poll timer per device. We generally try to avoid global state, and this allows to get rid of the opencount tracking aswell. done. +static ssize_t cm4040_read(struct file *filp, char __user *buf, + size_t count, loff_t *ppos) +{ + struct reader_dev *dev = (struct reader_dev *) filp-private_data; no need to case a void pointer. well, but good style in my opioion anyway. Anway, I don't really mind, so it has been removed. + if (count 10) + return -EFAULT; + + if (filp-f_flags O_NONBLOCK) { + DEBUG(4, filep-f_flags O_NONBLOCK set\n); + DEBUG(2, - cm4040_read (failure)\n); + return -EAGAIN; + } this sounds rather pointless. letting an O_NONBLOCK open fail all the time doesn't sound like a good idea. what about fcntl enabling NONBLOCK after the open? Other character drivers (such as rtc) do the same, btw. Is there any way how I can tell the VFS to make any nonblocking operation fail? please use iminor. done. given that you fail O_NONLOCK in open already the code above makes even less sense. see my comment above. + dev-owner = current; this doesn't make a lot of sense and seems to be only used in debug code, I'd suggest killing it. done. you should be able to use file-private_data here. done I think these events became methods of their own recently, not sure if it hit -mm or mainline yet. I cannot find anything like that in mainline, thus my code remains unchanged for now. diff --git a/MAINTAINERS b/MAINTAINERS --- a/MAINTAINERS +++ b/MAINTAINERS @@ -1737,6 +1737,11 @@ L: [EMAIL PROTECTED] W: http://www.linuxtr.net S: Maintained +OMNIKEY CARDMAN 4040 DRIVER +P: Harald Welte +M: [EMAIL PROTECTED] +S: Maintained + ONSTREAM SCSI TAPE DRIVER P: Willem Riede M: [EMAIL PROTECTED] diff --git a/drivers/char/pcmcia/Kconfig b/drivers/char/pcmcia/Kconfig --- a/drivers/char/pcmcia/Kconfig +++ b/drivers/char/pcmcia/Kconfig @@ -18,5 +18,18 @@ config SYNCLINK_CS The module will be called synclinkmp. If you want to do that, say M here. +config CARDMAN_4040 + tristate Omnikey CardMan 4040 support + depends on PCMCIA + help + Enable support for the Omnikey CardMan 4040 PCMCIA Smartcard + reader. + + This card is basically a USB CCID device connected to a FIFO + in I/O space. To use the kernel driver, you will need either the + PC/SC ifdhandler provided from the Omnikey homepage + (http://www.omnikey.com/), or a current development version of OpenCT + (http://www.opensc.org/). + endmenu diff --git a/drivers/char/pcmcia/Makefile b/drivers/char/pcmcia/Makefile --- a/drivers/char/pcmcia/Makefile +++ b/drivers/char/pcmcia/Makefile @@ -5,3 +5,4 @@ # obj-$(CONFIG_SYNCLINK_CS) += synclink_cs.o +obj-$(CONFIG_CARDMAN_4040) += cm4040_cs.o diff --git a/drivers/char/pcmcia/cm4040_cs.c b/drivers/char/pcmcia/cm4040_cs.c new file mode 100644 --- /dev/null +++ b/drivers/char/pcmcia/cm4040_cs.c @@ -0,0 +1,835 @@ +/* + * A driver for the Omnikey PCMCIA smartcard reader CardMan 4040 + * + * (c) 2000-2004 Omnikey AG (http://www.omnikey.com/) + * + * (C) 2005 Harald Welte [EMAIL PROTECTED] + * - add support for poll() + * - driver cleanup + * - add waitqueues + * - adhere to linux kernel coding style and policies + * - support 2.6.13 new style pcmcia interface + * + * The device basically is a USB CCID compliant device that has been + * attached to an I/O-Mapped FIFO. + * + * All rights reserved, Dual BSD/GPL Licensed. + */ + +/* #define PCMCIA_DEBUG 6 */ + +#include linux/kernel.h +#include linux/module.h +#include linux/slab.h +#include linux/init.h +#include linux/fs.h +#include linux/delay.h +#include linux/poll.h +#include linux/wait.h +#include asm/uaccess.h +#include asm/io.h + +#include pcmcia/cs_types.h +#include pcmcia/cs.h +#include pcmcia/cistpl.h +#include pcmcia
Re: [PATCH] New: Omnikey CardMan 4040 PCMCIA Driver
On Sat, Sep 03, 2005 at 04:27:00PM -0500, Chase Venters wrote: > > Below you can find a driver for the Omnikey CardMan 4040 PCMCIA > > Smartcard Reader. > > Someone correct me if I'm wrong, but wouldn't these #defines be a problem > with > the new HZ flexibility: > > #define CCID_DRIVER_BULK_DEFAULT_TIMEOUT(150*HZ) > #define CCID_DRIVER_ASYNC_POWERUP_TIMEOUT (35*HZ) > #define CCID_DRIVER_MINIMUM_TIMEOUT (3*HZ) The defines above certainly have no problems. They want to wait for multiples of seconds. > /* how often to poll for fifo status change */ > #define POLL_PERIOD (HZ/100) > > In particular, 2.6.13 allows a HZ of 100, which would define POLL_PERIOD to > 0. > Your later calls to mod_timer would be setting cmx_poll_timer to the current > value of jiffies. 100/100 == 1. As far as my limited math skills go, only 0 divided by something can give a result of zero ;) So yes, the code would poll every 1/100th of a second, even with HZ=100. Obviously, if HZ would ever go below 100, the code above would provide some problems. I'm not sure what the future plans with HZ are, but I'll add an #error statement in case HZ goes smaller than that. > Also, you've got a typo in the comments: thanks. -- - Harald Welte <[EMAIL PROTECTED]> http://gnumonks.org/ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) pgpb5i3Zcc8TV.pgp Description: PGP signature
[PATCH] Omnikey Cardman 4040 driver
Hi! I've now incorporated all the suggested changes (thanks once again on the many comments received). The resulting driver has been tested and works fine. Please consider applying the driver to the mainline tree, thanks. Add new Omnikey Cardman 4040 smartcard reader driver Signed-off-by: Harald Welte <[EMAIL PROTECTED]> --- commit 1c1cd1c5aba9ae1c0ea32d55c5b25f2370aaeca4 tree 016dec439275ab425575901dca5ee261bbc0aa0f parent c4ab879b6ef599bf88d19b9b145878ef73400ce7 author Harald Welte <[EMAIL PROTECTED]> Mo, 05 Sep 2005 21:47:01 +0200 committer Harald Welte <[EMAIL PROTECTED]> Mo, 05 Sep 2005 21:47:01 +0200 MAINTAINERS |5 drivers/char/pcmcia/Kconfig | 13 + drivers/char/pcmcia/Makefile|1 drivers/char/pcmcia/cm4040_cs.c | 897 +++ drivers/char/pcmcia/cm4040_cs.h | 47 ++ 5 files changed, 963 insertions(+), 0 deletions(-) diff --git a/MAINTAINERS b/MAINTAINERS --- a/MAINTAINERS +++ b/MAINTAINERS @@ -1737,6 +1737,11 @@ L: [EMAIL PROTECTED] W: http://www.linuxtr.net S: Maintained +OMNIKEY CARDMAN 4040 DRIVER +P: Harald Welte +M: [EMAIL PROTECTED] +S: Maintained + ONSTREAM SCSI TAPE DRIVER P: Willem Riede M: [EMAIL PROTECTED] diff --git a/drivers/char/pcmcia/Kconfig b/drivers/char/pcmcia/Kconfig --- a/drivers/char/pcmcia/Kconfig +++ b/drivers/char/pcmcia/Kconfig @@ -18,5 +18,18 @@ config SYNCLINK_CS The module will be called synclinkmp. If you want to do that, say M here. +config CARDMAN_4040 + tristate "Omnikey CardMan 4040 support" + depends on PCMCIA + help + Enable support for the Omnikey CardMan 4040 PCMCIA Smartcard + reader. + + This card is basically a USB CCID device connected to a FIFO + in I/O space. To use the kernel driver, you will need either the + PC/SC ifdhandler provided from the Omnikey homepage + (http://www.omnikey.com/), or a current development version of OpenCT + (http://www.opensc.org/). + endmenu diff --git a/drivers/char/pcmcia/Makefile b/drivers/char/pcmcia/Makefile --- a/drivers/char/pcmcia/Makefile +++ b/drivers/char/pcmcia/Makefile @@ -5,3 +5,4 @@ # obj-$(CONFIG_SYNCLINK_CS) += synclink_cs.o +obj-$(CONFIG_CARDMAN_4040) += cm4040_cs.o diff --git a/drivers/char/pcmcia/cm4040_cs.c b/drivers/char/pcmcia/cm4040_cs.c new file mode 100644 --- /dev/null +++ b/drivers/char/pcmcia/cm4040_cs.c @@ -0,0 +1,897 @@ + /* + * A driver for the Omnikey PCMCIA smartcard reader CardMan 4040 + * + * (c) 2000-2004 Omnikey AG (http://www.omnikey.com/) + * + * (C) 2005 Harald Welte <[EMAIL PROTECTED]> + * - add support for poll() + * - driver cleanup + * - add waitqueues + * - adhere to linux kernel coding style and policies + * - support 2.6.13 "new style" pcmcia interface + * + * The device basically is a USB CCID compliant device that has been + * attached to an I/O-Mapped FIFO. + * + * All rights reserved, Dual BSD/GPL Licensed. + */ + +/* #define PCMCIA_DEBUG 6 */ + +#include + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include +#include +#include +#include +#include +#include +#include + +#include "cm4040_cs.h" + +static atomic_t cm4040_num_devices_open; + +#ifdef PCMCIA_DEBUG +static int pc_debug = PCMCIA_DEBUG; +module_param(pc_debug, int, 0600); +#define DEBUG(n, x, args...) do { if (pc_debug >= (n)) \ + printk(KERN_DEBUG "%s:%s:" x, MODULE_NAME, \ +__FUNCTION__, ##args); } while (0) +#else +#define DEBUG(n, args...) +#endif + +static char *version = +"OMNIKEY CardMan 4040 v1.1.0gm3 - All bugs added by Harald Welte"; + +#defineCCID_DRIVER_BULK_DEFAULT_TIMEOUT(150*HZ) +#defineCCID_DRIVER_ASYNC_POWERUP_TIMEOUT (35*HZ) +#defineCCID_DRIVER_MINIMUM_TIMEOUT (3*HZ) +#define READ_WRITE_BUFFER_SIZE 512 +#define POLL_LOOP_COUNT1000 + +/* how often to poll for fifo status change */ +#define POLL_PERIODmsecs_to_jiffies(10) + +static void reader_release(dev_link_t *link); +static void reader_detach(dev_link_t *link); + +static int major; + +#defineBS_READABLE 0x01 +#defineBS_WRITABLE 0x02 + +struct reader_dev { + dev_link_t link; + dev_node_t node; + wait_queue_head_t devq; + + wait_queue_head_t poll_wait; + wait_queue_head_t read_wait; + wait_queue_head_t write_wait; + + unsigned intbuffer_status; + + unsigned int
Re: [PATCH] New: Omnikey CardMan 4040 PCMCIA Driver
On Sun, Sep 04, 2005 at 12:27:20AM +0200, Jesper Juhl wrote: > On 9/4/05, Harald Welte <[EMAIL PROTECTED]> wrote: > > On Sun, Sep 04, 2005 at 12:12:18PM +0200, Harald Welte wrote: > > > Hi! > > > > > > Below you can find a driver for the Omnikey CardMan 4040 PCMCIA > > > Smartcard Reader. > > > > Sorry, the patch was missing a "cg-add" of the header file. Please use > > the patch below. > > It would be so much nicer if the patch actually was "below" - that is > "inline in the email as opposed to as an attachment". Having to first > save an attachment and then cut'n'paste from it is a pain. This is a neverending discussion. A number of kernel develpoers I know prefer attachements these days. It's a matter of your email client, and why it doesn't just append a "plaintext" attachment at the bottom of your mail and rather display you the "save as" icon/button/whatever. > Anyway, a few comments below : > > +#define DEBUG(n, x, args...) do { if (pc_debug >= (n)) > \ > > > line longer than 80 chars. Please adhere to CodingStyle and keep lines > <80 chars. The line is _not_ longer than 80 chars, at least not if you remove the "+" from the beginning of the patch and you hve 8 chars wide > There's more than one occourance of this. there was one occurrence in the file which I have missed, thanks. > +static inline int cmx_waitForBulkOutReady(reader_dev_t *dev) > > > Why TheStudlyCaps ? Please keep function names lowercase. There are > more instances of this, only pointing out one. Yes, there are. My initial idea was to diverge as little as possible from the original vendor driver, making it easy to pull in changes from their tree in the future, should it be neccessarry. However, it has diverged that much now, it doesn't really matter whether I also rename the functions, too. Please stay tuned for the next revision of the patch. > Please use only tabs for indentation (line 1 of the above is indented > with spaces). thanks, should have catched all of them now. > lowercase prefered also for variables. done > Space after ","s please : DEBUG(5, "cmx_waitForBulkInReady rc=%.2x\n", rc); done > get rid of the space before the opening paren : > static int cmx_open(struct inode *inode, struct file *filp) done > How about not having to indent so deep by rewriting that as done > + cmx_poll_timer.function = _do_poll; > > shouldn't this be >cmx_poll_timer.function = cmx_do_poll; > ??? I don't really know what difference it would make. My understanding of 'c' is that both cases would take the address of the function. My personal taste is rather to explicitly indicate this with an '&' than let the compiler implicitly take the address. -- - Harald Welte <[EMAIL PROTECTED]> http://gnumonks.org/ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) pgp0GtfIPIiSQ.pgp Description: PGP signature
Re: [PATCH] New: Omnikey CardMan 4040 PCMCIA Driver
On Sun, Sep 04, 2005 at 02:58:27PM +0200, Ingo Oeser wrote: > just use > return nonseekable_open(inode, filp); > > to really disable any file pointer positioning (e.g. pwrite/pread too). > > Addtionally cmx_llseek() is implement already as "no_llseek()" > by the VFS, so you delete it from the driver an use no_llseek() from > the VFS instead. great, thanks, I've merged your suggested changes into my local tree. Stay tuned for a re-submit later today. -- - Harald Welte <[EMAIL PROTECTED]> http://gnumonks.org/ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) pgpD9aDqrpuRh.pgp Description: PGP signature
Re: [PATCH] New: Omnikey CardMan 4040 PCMCIA Driver
On Sun, Sep 04, 2005 at 02:58:27PM +0200, Ingo Oeser wrote: just use return nonseekable_open(inode, filp); to really disable any file pointer positioning (e.g. pwrite/pread too). Addtionally cmx_llseek() is implement already as no_llseek() by the VFS, so you delete it from the driver an use no_llseek() from the VFS instead. great, thanks, I've merged your suggested changes into my local tree. Stay tuned for a re-submit later today. -- - Harald Welte [EMAIL PROTECTED] http://gnumonks.org/ Privacy in residential applications is a desirable marketing option. (ETSI EN 300 175-7 Ch. A6) pgpD9aDqrpuRh.pgp Description: PGP signature
Re: [PATCH] New: Omnikey CardMan 4040 PCMCIA Driver
On Sun, Sep 04, 2005 at 12:27:20AM +0200, Jesper Juhl wrote: On 9/4/05, Harald Welte [EMAIL PROTECTED] wrote: On Sun, Sep 04, 2005 at 12:12:18PM +0200, Harald Welte wrote: Hi! Below you can find a driver for the Omnikey CardMan 4040 PCMCIA Smartcard Reader. Sorry, the patch was missing a cg-add of the header file. Please use the patch below. It would be so much nicer if the patch actually was below - that is inline in the email as opposed to as an attachment. Having to first save an attachment and then cut'n'paste from it is a pain. This is a neverending discussion. A number of kernel develpoers I know prefer attachements these days. It's a matter of your email client, and why it doesn't just append a plaintext attachment at the bottom of your mail and rather display you the save as icon/button/whatever. Anyway, a few comments below : +#define DEBUG(n, x, args...) do { if (pc_debug = (n)) \ line longer than 80 chars. Please adhere to CodingStyle and keep lines 80 chars. The line is _not_ longer than 80 chars, at least not if you remove the + from the beginning of the patch and you hve 8 chars wide There's more than one occourance of this. there was one occurrence in the file which I have missed, thanks. +static inline int cmx_waitForBulkOutReady(reader_dev_t *dev) Why TheStudlyCaps ? Please keep function names lowercase. There are more instances of this, only pointing out one. Yes, there are. My initial idea was to diverge as little as possible from the original vendor driver, making it easy to pull in changes from their tree in the future, should it be neccessarry. However, it has diverged that much now, it doesn't really matter whether I also rename the functions, too. Please stay tuned for the next revision of the patch. Please use only tabs for indentation (line 1 of the above is indented with spaces). thanks, should have catched all of them now. lowercase prefered also for variables. done Space after ,s please : DEBUG(5, cmx_waitForBulkInReady rc=%.2x\n, rc); done get rid of the space before the opening paren : static int cmx_open(struct inode *inode, struct file *filp) done How about not having to indent so deep by rewriting that as done + cmx_poll_timer.function = cmx_do_poll; shouldn't this be cmx_poll_timer.function = cmx_do_poll; ??? I don't really know what difference it would make. My understanding of 'c' is that both cases would take the address of the function. My personal taste is rather to explicitly indicate this with an '' than let the compiler implicitly take the address. -- - Harald Welte [EMAIL PROTECTED] http://gnumonks.org/ Privacy in residential applications is a desirable marketing option. (ETSI EN 300 175-7 Ch. A6) pgp0GtfIPIiSQ.pgp Description: PGP signature
[PATCH] Omnikey Cardman 4040 driver
Hi! I've now incorporated all the suggested changes (thanks once again on the many comments received). The resulting driver has been tested and works fine. Please consider applying the driver to the mainline tree, thanks. Add new Omnikey Cardman 4040 smartcard reader driver Signed-off-by: Harald Welte [EMAIL PROTECTED] --- commit 1c1cd1c5aba9ae1c0ea32d55c5b25f2370aaeca4 tree 016dec439275ab425575901dca5ee261bbc0aa0f parent c4ab879b6ef599bf88d19b9b145878ef73400ce7 author Harald Welte [EMAIL PROTECTED] Mo, 05 Sep 2005 21:47:01 +0200 committer Harald Welte [EMAIL PROTECTED] Mo, 05 Sep 2005 21:47:01 +0200 MAINTAINERS |5 drivers/char/pcmcia/Kconfig | 13 + drivers/char/pcmcia/Makefile|1 drivers/char/pcmcia/cm4040_cs.c | 897 +++ drivers/char/pcmcia/cm4040_cs.h | 47 ++ 5 files changed, 963 insertions(+), 0 deletions(-) diff --git a/MAINTAINERS b/MAINTAINERS --- a/MAINTAINERS +++ b/MAINTAINERS @@ -1737,6 +1737,11 @@ L: [EMAIL PROTECTED] W: http://www.linuxtr.net S: Maintained +OMNIKEY CARDMAN 4040 DRIVER +P: Harald Welte +M: [EMAIL PROTECTED] +S: Maintained + ONSTREAM SCSI TAPE DRIVER P: Willem Riede M: [EMAIL PROTECTED] diff --git a/drivers/char/pcmcia/Kconfig b/drivers/char/pcmcia/Kconfig --- a/drivers/char/pcmcia/Kconfig +++ b/drivers/char/pcmcia/Kconfig @@ -18,5 +18,18 @@ config SYNCLINK_CS The module will be called synclinkmp. If you want to do that, say M here. +config CARDMAN_4040 + tristate Omnikey CardMan 4040 support + depends on PCMCIA + help + Enable support for the Omnikey CardMan 4040 PCMCIA Smartcard + reader. + + This card is basically a USB CCID device connected to a FIFO + in I/O space. To use the kernel driver, you will need either the + PC/SC ifdhandler provided from the Omnikey homepage + (http://www.omnikey.com/), or a current development version of OpenCT + (http://www.opensc.org/). + endmenu diff --git a/drivers/char/pcmcia/Makefile b/drivers/char/pcmcia/Makefile --- a/drivers/char/pcmcia/Makefile +++ b/drivers/char/pcmcia/Makefile @@ -5,3 +5,4 @@ # obj-$(CONFIG_SYNCLINK_CS) += synclink_cs.o +obj-$(CONFIG_CARDMAN_4040) += cm4040_cs.o diff --git a/drivers/char/pcmcia/cm4040_cs.c b/drivers/char/pcmcia/cm4040_cs.c new file mode 100644 --- /dev/null +++ b/drivers/char/pcmcia/cm4040_cs.c @@ -0,0 +1,897 @@ + /* + * A driver for the Omnikey PCMCIA smartcard reader CardMan 4040 + * + * (c) 2000-2004 Omnikey AG (http://www.omnikey.com/) + * + * (C) 2005 Harald Welte [EMAIL PROTECTED] + * - add support for poll() + * - driver cleanup + * - add waitqueues + * - adhere to linux kernel coding style and policies + * - support 2.6.13 new style pcmcia interface + * + * The device basically is a USB CCID compliant device that has been + * attached to an I/O-Mapped FIFO. + * + * All rights reserved, Dual BSD/GPL Licensed. + */ + +/* #define PCMCIA_DEBUG 6 */ + +#include linux/version.h + +#include linux/kernel.h +#include linux/module.h +#include linux/slab.h +#include linux/init.h +#include linux/fs.h +#include linux/delay.h +#include linux/poll.h +#include linux/wait.h +#include asm/uaccess.h +#include asm/io.h + +#include pcmcia/version.h +#include pcmcia/cs_types.h +#include pcmcia/cs.h +#include pcmcia/cistpl.h +#include pcmcia/cisreg.h +#include pcmcia/ciscode.h +#include pcmcia/ds.h + +#include cm4040_cs.h + +static atomic_t cm4040_num_devices_open; + +#ifdef PCMCIA_DEBUG +static int pc_debug = PCMCIA_DEBUG; +module_param(pc_debug, int, 0600); +#define DEBUG(n, x, args...) do { if (pc_debug = (n)) \ + printk(KERN_DEBUG %s:%s: x, MODULE_NAME, \ +__FUNCTION__, ##args); } while (0) +#else +#define DEBUG(n, args...) +#endif + +static char *version = +OMNIKEY CardMan 4040 v1.1.0gm3 - All bugs added by Harald Welte; + +#defineCCID_DRIVER_BULK_DEFAULT_TIMEOUT(150*HZ) +#defineCCID_DRIVER_ASYNC_POWERUP_TIMEOUT (35*HZ) +#defineCCID_DRIVER_MINIMUM_TIMEOUT (3*HZ) +#define READ_WRITE_BUFFER_SIZE 512 +#define POLL_LOOP_COUNT1000 + +/* how often to poll for fifo status change */ +#define POLL_PERIODmsecs_to_jiffies(10) + +static void reader_release(dev_link_t *link); +static void reader_detach(dev_link_t *link); + +static int major; + +#defineBS_READABLE 0x01 +#defineBS_WRITABLE 0x02 + +struct reader_dev { + dev_link_t link; + dev_node_t node; + wait_queue_head_t devq; + + wait_queue_head_t poll_wait; + wait_queue_head_t read_wait
Re: [PATCH] New: Omnikey CardMan 4040 PCMCIA Driver
On Sat, Sep 03, 2005 at 04:27:00PM -0500, Chase Venters wrote: Below you can find a driver for the Omnikey CardMan 4040 PCMCIA Smartcard Reader. Someone correct me if I'm wrong, but wouldn't these #defines be a problem with the new HZ flexibility: #define CCID_DRIVER_BULK_DEFAULT_TIMEOUT(150*HZ) #define CCID_DRIVER_ASYNC_POWERUP_TIMEOUT (35*HZ) #define CCID_DRIVER_MINIMUM_TIMEOUT (3*HZ) The defines above certainly have no problems. They want to wait for multiples of seconds. /* how often to poll for fifo status change */ #define POLL_PERIOD (HZ/100) In particular, 2.6.13 allows a HZ of 100, which would define POLL_PERIOD to 0. Your later calls to mod_timer would be setting cmx_poll_timer to the current value of jiffies. 100/100 == 1. As far as my limited math skills go, only 0 divided by something can give a result of zero ;) So yes, the code would poll every 1/100th of a second, even with HZ=100. Obviously, if HZ would ever go below 100, the code above would provide some problems. I'm not sure what the future plans with HZ are, but I'll add an #error statement in case HZ goes smaller than that. Also, you've got a typo in the comments: thanks. -- - Harald Welte [EMAIL PROTECTED] http://gnumonks.org/ Privacy in residential applications is a desirable marketing option. (ETSI EN 300 175-7 Ch. A6) pgpb5i3Zcc8TV.pgp Description: PGP signature
Re: [PATCH] New: Omnikey CardMan 4040 PCMCIA Driver
Hi Nish, thanks for your comments. On Sat, Sep 03, 2005 at 03:13:43PM -0700, Nish Aravamudan wrote: > On 9/3/05, Chase Venters <[EMAIL PROTECTED]> wrote: > > > Below you can find a driver for the Omnikey CardMan 4040 PCMCIA > > > Smartcard Reader. > > > > #define CCID_DRIVER_BULK_DEFAULT_TIMEOUT(150*HZ) > > These are all fine. Although I am a bit suspicious of 150 second > timeouts; but if that is the hardware... That's a definition from the original vendor-supplied driver. Unfortunately there's no hardware documentation, so I can't verify it. But generally speaking, serial smart cards can really be slow, so I think it could make sense. > > /* how often to poll for fifo status change */ > > #define POLL_PERIOD (HZ/100) > > This needs to be msecs_to_jiffies(10), please. thanks, changed in my local tree now. > Of bigger concern to me is the use of the sleep_on() family of > functions, all of which are deprecated. Ok, I'm working on replacing the respective code with wait_event_interruptible_timeout(). -- - Harald Welte <[EMAIL PROTECTED]> http://gnumonks.org/ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) pgpjkUFyNclXx.pgp Description: PGP signature
Re: [PATCH] New: Omnikey CardMan 4040 PCMCIA Driver
Thanks for your comments, Alexey. I've now incorprorated all of the requested changes and am testing the driver. If everything is still fine, I'll repost later today. -- - Harald Welte <[EMAIL PROTECTED]> http://gnumonks.org/ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) pgpCUESmjveeW.pgp Description: PGP signature
Re: [PATCH] New: Omnikey CardMan 4040 PCMCIA Driver
Thanks for your comments, Alexey. I've now incorprorated all of the requested changes and am testing the driver. If everything is still fine, I'll repost later today. -- - Harald Welte [EMAIL PROTECTED] http://gnumonks.org/ Privacy in residential applications is a desirable marketing option. (ETSI EN 300 175-7 Ch. A6) pgpCUESmjveeW.pgp Description: PGP signature
Re: [PATCH] New: Omnikey CardMan 4040 PCMCIA Driver
Hi Nish, thanks for your comments. On Sat, Sep 03, 2005 at 03:13:43PM -0700, Nish Aravamudan wrote: On 9/3/05, Chase Venters [EMAIL PROTECTED] wrote: Below you can find a driver for the Omnikey CardMan 4040 PCMCIA Smartcard Reader. #define CCID_DRIVER_BULK_DEFAULT_TIMEOUT(150*HZ) These are all fine. Although I am a bit suspicious of 150 second timeouts; but if that is the hardware... That's a definition from the original vendor-supplied driver. Unfortunately there's no hardware documentation, so I can't verify it. But generally speaking, serial smart cards can really be slow, so I think it could make sense. /* how often to poll for fifo status change */ #define POLL_PERIOD (HZ/100) This needs to be msecs_to_jiffies(10), please. thanks, changed in my local tree now. Of bigger concern to me is the use of the sleep_on() family of functions, all of which are deprecated. Ok, I'm working on replacing the respective code with wait_event_interruptible_timeout(). -- - Harald Welte [EMAIL PROTECTED] http://gnumonks.org/ Privacy in residential applications is a desirable marketing option. (ETSI EN 300 175-7 Ch. A6) pgpjkUFyNclXx.pgp Description: PGP signature
Re: [PATCH] New: Omnikey CardMan 4040 PCMCIA Driver
On Sun, Sep 04, 2005 at 12:12:18PM +0200, Harald Welte wrote: > Hi! > > Below you can find a driver for the Omnikey CardMan 4040 PCMCIA > Smartcard Reader. Sorry, the patch was missing a "cg-add" of the header file. Please use the patch below. -- - Harald Welte <[EMAIL PROTECTED]> http://gnumonks.org/ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) Add Omnikey CardMan 4040 Driver Signed-off-by: Harald Welte <[EMAIL PROTECTED]> --- commit 0e760a5785ebb83b932d104679cc2b2b4070b1c1 tree 46d71d0c6b41b441a1a8d725b741450f1334296e parent c4ab879b6ef599bf88d19b9b145878ef73400ce7 author Harald Welte <[EMAIL PROTECTED]> So, 04 Sep 2005 13:05:44 +0200 committer Harald Welte <[EMAIL PROTECTED]> So, 04 Sep 2005 13:05:44 +0200 MAINTAINERS |5 drivers/char/pcmcia/Kconfig | 13 + drivers/char/pcmcia/Makefile|1 drivers/char/pcmcia/cm4040_cs.c | 900 +++ drivers/char/pcmcia/cm4040_cs.h | 52 ++ 5 files changed, 971 insertions(+), 0 deletions(-) diff --git a/MAINTAINERS b/MAINTAINERS --- a/MAINTAINERS +++ b/MAINTAINERS @@ -1737,6 +1737,11 @@ L: [EMAIL PROTECTED] W: http://www.linuxtr.net S: Maintained +OMNIKEY CARDMAN 4040 DRIVER +P: Harald Welte +M: [EMAIL PROTECTED] +S: Maintained + ONSTREAM SCSI TAPE DRIVER P: Willem Riede M: [EMAIL PROTECTED] diff --git a/drivers/char/pcmcia/Kconfig b/drivers/char/pcmcia/Kconfig --- a/drivers/char/pcmcia/Kconfig +++ b/drivers/char/pcmcia/Kconfig @@ -18,5 +18,18 @@ config SYNCLINK_CS The module will be called synclinkmp. If you want to do that, say M here. +config CARDMAN_4040 + tristate "Omnikey CardMan 4040 support" + depends on PCMCIA + help + Enable support for the Omnikey CardMan 4040 PCMCIA Smartcard + reader. + + This card is basically a USB CCID device connected to a FIFO + in I/O space. To use the kernel driver, you will need either the + PC/SC ifdhandler provided from the Omnikey homepage + (http://www.omnikey.com/), or a current development version of OpenCT + (http://www.opensc.org/). + endmenu diff --git a/drivers/char/pcmcia/Makefile b/drivers/char/pcmcia/Makefile --- a/drivers/char/pcmcia/Makefile +++ b/drivers/char/pcmcia/Makefile @@ -5,3 +5,4 @@ # obj-$(CONFIG_SYNCLINK_CS) += synclink_cs.o +obj-$(CONFIG_CARDMAN_4040) += cm4040_cs.o diff --git a/drivers/char/pcmcia/cm4040_cs.c b/drivers/char/pcmcia/cm4040_cs.c new file mode 100644 --- /dev/null +++ b/drivers/char/pcmcia/cm4040_cs.c @@ -0,0 +1,900 @@ + /* + * A driver for the Omnikey PCMCIA smartcard reader CardMan 4040 + * + * (c) 2000-2004 Omnikey AG (http://www.omnikey.com/) + * + * (C) 2005 Harald Welte <[EMAIL PROTECTED]> + * - add support for poll() + * - driver cleanup + * - add waitqueues + * - adhere to linux kenrel coding style and policies + * - support 2.6.13 "new style" pcmcia interface + * + * All rights reserved, Dual BSD/GPL Licensed. + */ + +/* #define PCMCIA_DEBUG 6 */ + +#include +#include + +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include +#include +#include +#include +#include +#include +#include + +#include "cm4040_cs.h" + +static atomic_t cmx_num_devices_open; + +#ifdef PCMCIA_DEBUG +static int pc_debug = PCMCIA_DEBUG; +module_param(pc_debug, int, 0600); +#define DEBUG(n, x, args...) do { if (pc_debug >= (n)) \ + printk(KERN_DEBUG "%s:%s:" x, MODULE_NAME, \ +__FUNCTION__, ##args); } while (0) +#else +#define DEBUG(n, args...) +#endif + +static volatile char *version = +"OMNIKEY CardMan 4040 v1.1.0gm3 - All bugs added by Harald Welte"; + +#defineCCID_DRIVER_BULK_DEFAULT_TIMEOUT(150*HZ) +#defineCCID_DRIVER_ASYNC_POWERUP_TIMEOUT (35*HZ) +#defineCCID_DRIVER_MINIMUM_TIMEOUT (3*HZ) +#define READ_WRITE_BUFFER_SIZE 512 +#define POLL_LOOP_COUNT1000 + +/* how often to poll for fifo status change */ +#define POLL_PERIOD(HZ/100) + +static void reader_release(u_long arg); +static void reader_detach(dev_link_t *link); + +static int major; + +#defineBS_READABLE 0x01 +#defineBS_WRITABLE 0x02 + +typedef struct reader_dev_t { + dev_link_t link; + dev_node_t node; + wait_queue_head_t devq; + + wait_queue_head_t poll_wait; + wait_queue_
[PATCH] New: Omnikey CardMan 4040 PCMCIA Driver
Hi! Below you can find a driver for the Omnikey CardMan 4040 PCMCIA Smartcard Reader. It's based on some source code originally made available by the vendor (as BSD/GPL dual licensed code), but has undergone significant changes to make it more compliant with the general kernel community coding practise. As this is the first PCMCIA driver that I'm involved in, please let me know if I missed something. If there are no objections, I'd like to see it included in mainline. Thanks! -- - Harald Welte <[EMAIL PROTECTED]> http://gnumonks.org/ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) Omnikey CardMan 4040 PCMCIA Smartcard reader driver Signed-off-by: Harald Welte <[EMAIL PROTECTED]> --- commit 04ec3ca3e3c6fd6d88c508b6ebe32726ef109367 tree e27a5ccafbcebda6ebfe90036016f0e76dd93137 parent c4ab879b6ef599bf88d19b9b145878ef73400ce7 author Harald Welte <[EMAIL PROTECTED]> So, 04 Sep 2005 11:59:37 +0200 committer Harald Welte <[EMAIL PROTECTED]> So, 04 Sep 2005 11:59:37 +0200 MAINTAINERS |5 drivers/char/pcmcia/Kconfig | 13 + drivers/char/pcmcia/Makefile|1 drivers/char/pcmcia/cm4040_cs.c | 900 +++ 4 files changed, 919 insertions(+), 0 deletions(-) diff --git a/MAINTAINERS b/MAINTAINERS --- a/MAINTAINERS +++ b/MAINTAINERS @@ -1737,6 +1737,11 @@ L: [EMAIL PROTECTED] W: http://www.linuxtr.net S: Maintained +OMNIKEY CARDMAN 4040 DRIVER +P: Harald Welte +M: [EMAIL PROTECTED] +S: Maintained + ONSTREAM SCSI TAPE DRIVER P: Willem Riede M: [EMAIL PROTECTED] diff --git a/drivers/char/pcmcia/Kconfig b/drivers/char/pcmcia/Kconfig --- a/drivers/char/pcmcia/Kconfig +++ b/drivers/char/pcmcia/Kconfig @@ -18,5 +18,18 @@ config SYNCLINK_CS The module will be called synclinkmp. If you want to do that, say M here. +config CARDMAN_4040 + tristate "Omnikey CardMan 4040 support" + depends on PCMCIA + help + Enable support for the Omnikey CardMan 4040 PCMCIA Smartcard + reader. + + This card is basically a USB CCID device connected to a FIFO + in I/O space. To use the kernel driver, you will need either the + PC/SC ifdhandler provided from the Omnikey homepage + (http://www.omnikey.com/), or a current development version of OpenCT + (http://www.opensc.org/). + endmenu diff --git a/drivers/char/pcmcia/Makefile b/drivers/char/pcmcia/Makefile --- a/drivers/char/pcmcia/Makefile +++ b/drivers/char/pcmcia/Makefile @@ -5,3 +5,4 @@ # obj-$(CONFIG_SYNCLINK_CS) += synclink_cs.o +obj-$(CONFIG_CARDMAN_4040) += cm4040_cs.o diff --git a/drivers/char/pcmcia/cm4040_cs.c b/drivers/char/pcmcia/cm4040_cs.c new file mode 100644 --- /dev/null +++ b/drivers/char/pcmcia/cm4040_cs.c @@ -0,0 +1,900 @@ + /* + * A driver for the Omnikey PCMCIA smartcard reader CardMan 4040 + * + * (c) 2000-2004 Omnikey AG (http://www.omnikey.com/) + * + * (C) 2005 Harald Welte <[EMAIL PROTECTED]> + * - add support for poll() + * - driver cleanup + * - add waitqueues + * - adhere to linux kenrel coding style and policies + * - support 2.6.13 "new style" pcmcia interface + * + * All rights reserved, Dual BSD/GPL Licensed. + */ + +/* #define PCMCIA_DEBUG 6 */ + +#include +#include + +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include +#include +#include +#include +#include +#include +#include + +#include "cm4040_cs.h" + +static atomic_t cmx_num_devices_open; + +#ifdef PCMCIA_DEBUG +static int pc_debug = PCMCIA_DEBUG; +module_param(pc_debug, int, 0600); +#define DEBUG(n, x, args...) do { if (pc_debug >= (n)) \ + printk(KERN_DEBUG "%s:%s:" x, MODULE_NAME, \ +__FUNCTION__, ##args); } while (0) +#else +#define DEBUG(n, args...) +#endif + +static volatile char *version = +"OMNIKEY CardMan 4040 v1.1.0gm3 - All bugs added by Harald Welte"; + +#defineCCID_DRIVER_BULK_DEFAULT_TIMEOUT(150*HZ) +#defineCCID_DRIVER_ASYNC_POWERUP_TIMEOUT (35*HZ) +#defineCCID_DRIVER_MINIMUM_TIMEOUT (3*HZ) +#define READ_WRITE_BUFFER_SIZE 512 +#define POLL_LOOP_COUNT1000 + +/* how often to poll for fifo status change */ +#define POLL_PERIOD(HZ/100) + +static void reader_release(u_long arg); +static void reader_detach(dev_link_t *link); + +static int major; + +#defineBS_READABLE 0x01 +#defineBS_WRITABLE 0x02 + +typedef struct reader_
Re: [PATCH 2/2] [NETFILTER] remove bogus hand-coded htonll()
On Sat, Sep 03, 2005 at 09:54:25AM -0700, Jouni Malinen wrote: > On Sat, Sep 03, 2005 at 10:43:15AM +0200, Harald Welte wrote: > > > htonll() is nothing else than cpu_to_be64(), so we'd rather call the > > latter. > > Actually, the htonll() implementation does not seem to be doing what > cpu_to_be64() is doing.. However, I would assume this is a bug in > htonll() and this change to use cpu_to_be64() is fixing that. ACK. > Can this bug cause any major problems in the current implementation? the "current implementation" was only merged after 2.6.13 is released, so I doubt anyone but the netfilter developers is using it yet. > I would assume that the first index should have had '-i' added to it, if > the purpose is to swap byte order.. The code here is leaving some > arbitrary data in 7 bytes of the 64-bit variable and setting > (u8*)[7] = (u8*)[7] in somewhat inefficient way ;-). In addition, > this looks more like swap-8-bytes-unconditionally than doing this based > on host byte order.. yes, yes, yes. Somehow this ancient buggy implementation slipped into mainline. I know I had fixed this before. So please let's all forget about this embarrassing htonll() and move on. -- - Harald Welte <[EMAIL PROTECTED]> http://netfilter.org/ "Fragmentation is like classful addressing -- an interesting early architectural error that shows how much experimentation was going on while IP was being designed."-- Paul Vixie pgpZliKCIUmq8.pgp Description: PGP signature
[PATCH 1/2] nfnetlink: make needlessly global functions static
Hi Dave, please apply the appended patch. Thanks, -- - Harald Welte <[EMAIL PROTECTED]> http://netfilter.org/ "Fragmentation is like classful addressing -- an interesting early architectural error that shows how much experimentation was going on while IP was being designed."-- Paul Vixie [NETFILTER] make needlessly global functions static Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]> Signed-off-by: Harald Welte <[EMAIL PROTECTED]> --- commit a2c9c9a399f2069f31d608d142da8d5d82609b0d tree 63cce7c2cc4d738a2604c54d87961b4a32ab3aac parent 0905251a08bf51d5e2d1996c21fcdc5acfbbde13 author Adrian Bunk <[EMAIL PROTECTED]> Sa, 03 Sep 2005 10:34:27 +0200 committer Harald Welte <[EMAIL PROTECTED]> Sa, 03 Sep 2005 10:34:27 +0200 net/netfilter/nfnetlink.c |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/net/netfilter/nfnetlink.c b/net/netfilter/nfnetlink.c --- a/net/netfilter/nfnetlink.c +++ b/net/netfilter/nfnetlink.c @@ -344,14 +344,14 @@ static void nfnetlink_rcv(struct sock *s } while(nfnl && nfnl->sk_receive_queue.qlen); } -void __exit nfnetlink_exit(void) +static void __exit nfnetlink_exit(void) { printk("Removing netfilter NETLINK layer.\n"); sock_release(nfnl->sk_socket); return; } -int __init nfnetlink_init(void) +static int __init nfnetlink_init(void) { printk("Netfilter messages via NETLINK v%s.\n", nfversion); pgpxaToo6kNcY.pgp Description: PGP signature
[PATCH 2/2] [NETFILTER] remove bogus hand-coded htonll()
Hi Dave, please apply the appended patch. I somehow thought I had fixed this quite some time ago. Probably I lost it with some merge :( Thanks, -- - Harald Welte <[EMAIL PROTECTED]> http://netfilter.org/ "Fragmentation is like classful addressing -- an interesting early architectural error that shows how much experimentation was going on while IP was being designed."-- Paul Vixie [NETFILTER] remove bogus hand-coded htonll() from nenetlink_queue htonll() is nothing else than cpu_to_be64(), so we'd rather call the latter. Signed-off-by: Harald Welte <[EMAIL PROTECTED]> --- commit 0905251a08bf51d5e2d1996c21fcdc5acfbbde13 tree a8072738e54f24b0d4392cf33252594d4a6848e1 parent e8d296c78dff8485c5cd90217b91433185a58871 author Harald Welte <[EMAIL PROTECTED]> Sa, 03 Sep 2005 10:31:19 +0200 committer Harald Welte <[EMAIL PROTECTED]> Sa, 03 Sep 2005 10:31:19 +0200 net/netfilter/nfnetlink_queue.c | 15 ++- 1 files changed, 2 insertions(+), 13 deletions(-) diff --git a/net/netfilter/nfnetlink_queue.c b/net/netfilter/nfnetlink_queue.c --- a/net/netfilter/nfnetlink_queue.c +++ b/net/netfilter/nfnetlink_queue.c @@ -76,17 +76,6 @@ typedef int (*nfqnl_cmpfn)(struct nfqnl_ static DEFINE_RWLOCK(instances_lock); -u_int64_t htonll(u_int64_t in) -{ - u_int64_t out; - int i; - - for (i = 0; i < sizeof(u_int64_t); i++) - ((u_int8_t *))[sizeof(u_int64_t)-1] = ((u_int8_t *))[i]; - - return out; -} - #define INSTANCE_BUCKETS 16 static struct hlist_head instance_table[INSTANCE_BUCKETS]; @@ -497,8 +486,8 @@ nfqnl_build_packet_message(struct nfqnl_ if (entry->skb->tstamp.off_sec) { struct nfqnl_msg_packet_timestamp ts; - ts.sec = htonll(skb_tv_base.tv_sec + entry->skb->tstamp.off_sec); - ts.usec = htonll(skb_tv_base.tv_usec + entry->skb->tstamp.off_usec); + ts.sec = cpu_to_be64(skb_tv_base.tv_sec + entry->skb->tstamp.off_sec); + ts.usec = cpu_to_be64(skb_tv_base.tv_usec + entry->skb->tstamp.off_usec); NFA_PUT(skb, NFQA_TIMESTAMP, sizeof(ts), ); } pgpfTvXdErwAO.pgp Description: PGP signature
Re: [netfilter-core] [2.6 patch] net/netfilter/nfnetlink*: make functions static
On Sat, Sep 03, 2005 at 03:28:29AM +0200, Adrian Bunk wrote: > This patch makes needlessly global functions static. Thanks for your patch. I'll merge it with my local changes (it clashes, since the "htonll" implementation was removed) and submit it via davem later today. -- - Harald Welte <[EMAIL PROTECTED]> http://netfilter.org/ "Fragmentation is like classful addressing -- an interesting early architectural error that shows how much experimentation was going on while IP was being designed."-- Paul Vixie pgpkZ6c3hvVjR.pgp Description: PGP signature
Re: [netfilter-core] [2.6 patch] net/netfilter/nfnetlink*: make functions static
On Sat, Sep 03, 2005 at 03:28:29AM +0200, Adrian Bunk wrote: This patch makes needlessly global functions static. Thanks for your patch. I'll merge it with my local changes (it clashes, since the htonll implementation was removed) and submit it via davem later today. -- - Harald Welte [EMAIL PROTECTED] http://netfilter.org/ Fragmentation is like classful addressing -- an interesting early architectural error that shows how much experimentation was going on while IP was being designed.-- Paul Vixie pgpkZ6c3hvVjR.pgp Description: PGP signature
[PATCH 2/2] [NETFILTER] remove bogus hand-coded htonll()
Hi Dave, please apply the appended patch. I somehow thought I had fixed this quite some time ago. Probably I lost it with some merge :( Thanks, -- - Harald Welte [EMAIL PROTECTED] http://netfilter.org/ Fragmentation is like classful addressing -- an interesting early architectural error that shows how much experimentation was going on while IP was being designed.-- Paul Vixie [NETFILTER] remove bogus hand-coded htonll() from nenetlink_queue htonll() is nothing else than cpu_to_be64(), so we'd rather call the latter. Signed-off-by: Harald Welte [EMAIL PROTECTED] --- commit 0905251a08bf51d5e2d1996c21fcdc5acfbbde13 tree a8072738e54f24b0d4392cf33252594d4a6848e1 parent e8d296c78dff8485c5cd90217b91433185a58871 author Harald Welte [EMAIL PROTECTED] Sa, 03 Sep 2005 10:31:19 +0200 committer Harald Welte [EMAIL PROTECTED] Sa, 03 Sep 2005 10:31:19 +0200 net/netfilter/nfnetlink_queue.c | 15 ++- 1 files changed, 2 insertions(+), 13 deletions(-) diff --git a/net/netfilter/nfnetlink_queue.c b/net/netfilter/nfnetlink_queue.c --- a/net/netfilter/nfnetlink_queue.c +++ b/net/netfilter/nfnetlink_queue.c @@ -76,17 +76,6 @@ typedef int (*nfqnl_cmpfn)(struct nfqnl_ static DEFINE_RWLOCK(instances_lock); -u_int64_t htonll(u_int64_t in) -{ - u_int64_t out; - int i; - - for (i = 0; i sizeof(u_int64_t); i++) - ((u_int8_t *)out)[sizeof(u_int64_t)-1] = ((u_int8_t *)in)[i]; - - return out; -} - #define INSTANCE_BUCKETS 16 static struct hlist_head instance_table[INSTANCE_BUCKETS]; @@ -497,8 +486,8 @@ nfqnl_build_packet_message(struct nfqnl_ if (entry-skb-tstamp.off_sec) { struct nfqnl_msg_packet_timestamp ts; - ts.sec = htonll(skb_tv_base.tv_sec + entry-skb-tstamp.off_sec); - ts.usec = htonll(skb_tv_base.tv_usec + entry-skb-tstamp.off_usec); + ts.sec = cpu_to_be64(skb_tv_base.tv_sec + entry-skb-tstamp.off_sec); + ts.usec = cpu_to_be64(skb_tv_base.tv_usec + entry-skb-tstamp.off_usec); NFA_PUT(skb, NFQA_TIMESTAMP, sizeof(ts), ts); } pgpfTvXdErwAO.pgp Description: PGP signature
[PATCH 1/2] nfnetlink: make needlessly global functions static
Hi Dave, please apply the appended patch. Thanks, -- - Harald Welte [EMAIL PROTECTED] http://netfilter.org/ Fragmentation is like classful addressing -- an interesting early architectural error that shows how much experimentation was going on while IP was being designed.-- Paul Vixie [NETFILTER] make needlessly global functions static Signed-off-by: Adrian Bunk [EMAIL PROTECTED] Signed-off-by: Harald Welte [EMAIL PROTECTED] --- commit a2c9c9a399f2069f31d608d142da8d5d82609b0d tree 63cce7c2cc4d738a2604c54d87961b4a32ab3aac parent 0905251a08bf51d5e2d1996c21fcdc5acfbbde13 author Adrian Bunk [EMAIL PROTECTED] Sa, 03 Sep 2005 10:34:27 +0200 committer Harald Welte [EMAIL PROTECTED] Sa, 03 Sep 2005 10:34:27 +0200 net/netfilter/nfnetlink.c |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/net/netfilter/nfnetlink.c b/net/netfilter/nfnetlink.c --- a/net/netfilter/nfnetlink.c +++ b/net/netfilter/nfnetlink.c @@ -344,14 +344,14 @@ static void nfnetlink_rcv(struct sock *s } while(nfnl nfnl-sk_receive_queue.qlen); } -void __exit nfnetlink_exit(void) +static void __exit nfnetlink_exit(void) { printk(Removing netfilter NETLINK layer.\n); sock_release(nfnl-sk_socket); return; } -int __init nfnetlink_init(void) +static int __init nfnetlink_init(void) { printk(Netfilter messages via NETLINK v%s.\n, nfversion); pgpxaToo6kNcY.pgp Description: PGP signature
Re: [PATCH 2/2] [NETFILTER] remove bogus hand-coded htonll()
On Sat, Sep 03, 2005 at 09:54:25AM -0700, Jouni Malinen wrote: On Sat, Sep 03, 2005 at 10:43:15AM +0200, Harald Welte wrote: htonll() is nothing else than cpu_to_be64(), so we'd rather call the latter. Actually, the htonll() implementation does not seem to be doing what cpu_to_be64() is doing.. However, I would assume this is a bug in htonll() and this change to use cpu_to_be64() is fixing that. ACK. Can this bug cause any major problems in the current implementation? the current implementation was only merged after 2.6.13 is released, so I doubt anyone but the netfilter developers is using it yet. I would assume that the first index should have had '-i' added to it, if the purpose is to swap byte order.. The code here is leaving some arbitrary data in 7 bytes of the 64-bit variable and setting (u8*)out[7] = (u8*)in[7] in somewhat inefficient way ;-). In addition, this looks more like swap-8-bytes-unconditionally than doing this based on host byte order.. yes, yes, yes. Somehow this ancient buggy implementation slipped into mainline. I know I had fixed this before. So please let's all forget about this embarrassing htonll() and move on. -- - Harald Welte [EMAIL PROTECTED] http://netfilter.org/ Fragmentation is like classful addressing -- an interesting early architectural error that shows how much experimentation was going on while IP was being designed.-- Paul Vixie pgpZliKCIUmq8.pgp Description: PGP signature
[PATCH] New: Omnikey CardMan 4040 PCMCIA Driver
Hi! Below you can find a driver for the Omnikey CardMan 4040 PCMCIA Smartcard Reader. It's based on some source code originally made available by the vendor (as BSD/GPL dual licensed code), but has undergone significant changes to make it more compliant with the general kernel community coding practise. As this is the first PCMCIA driver that I'm involved in, please let me know if I missed something. If there are no objections, I'd like to see it included in mainline. Thanks! -- - Harald Welte [EMAIL PROTECTED] http://gnumonks.org/ Privacy in residential applications is a desirable marketing option. (ETSI EN 300 175-7 Ch. A6) Omnikey CardMan 4040 PCMCIA Smartcard reader driver Signed-off-by: Harald Welte [EMAIL PROTECTED] --- commit 04ec3ca3e3c6fd6d88c508b6ebe32726ef109367 tree e27a5ccafbcebda6ebfe90036016f0e76dd93137 parent c4ab879b6ef599bf88d19b9b145878ef73400ce7 author Harald Welte [EMAIL PROTECTED] So, 04 Sep 2005 11:59:37 +0200 committer Harald Welte [EMAIL PROTECTED] So, 04 Sep 2005 11:59:37 +0200 MAINTAINERS |5 drivers/char/pcmcia/Kconfig | 13 + drivers/char/pcmcia/Makefile|1 drivers/char/pcmcia/cm4040_cs.c | 900 +++ 4 files changed, 919 insertions(+), 0 deletions(-) diff --git a/MAINTAINERS b/MAINTAINERS --- a/MAINTAINERS +++ b/MAINTAINERS @@ -1737,6 +1737,11 @@ L: [EMAIL PROTECTED] W: http://www.linuxtr.net S: Maintained +OMNIKEY CARDMAN 4040 DRIVER +P: Harald Welte +M: [EMAIL PROTECTED] +S: Maintained + ONSTREAM SCSI TAPE DRIVER P: Willem Riede M: [EMAIL PROTECTED] diff --git a/drivers/char/pcmcia/Kconfig b/drivers/char/pcmcia/Kconfig --- a/drivers/char/pcmcia/Kconfig +++ b/drivers/char/pcmcia/Kconfig @@ -18,5 +18,18 @@ config SYNCLINK_CS The module will be called synclinkmp. If you want to do that, say M here. +config CARDMAN_4040 + tristate Omnikey CardMan 4040 support + depends on PCMCIA + help + Enable support for the Omnikey CardMan 4040 PCMCIA Smartcard + reader. + + This card is basically a USB CCID device connected to a FIFO + in I/O space. To use the kernel driver, you will need either the + PC/SC ifdhandler provided from the Omnikey homepage + (http://www.omnikey.com/), or a current development version of OpenCT + (http://www.opensc.org/). + endmenu diff --git a/drivers/char/pcmcia/Makefile b/drivers/char/pcmcia/Makefile --- a/drivers/char/pcmcia/Makefile +++ b/drivers/char/pcmcia/Makefile @@ -5,3 +5,4 @@ # obj-$(CONFIG_SYNCLINK_CS) += synclink_cs.o +obj-$(CONFIG_CARDMAN_4040) += cm4040_cs.o diff --git a/drivers/char/pcmcia/cm4040_cs.c b/drivers/char/pcmcia/cm4040_cs.c new file mode 100644 --- /dev/null +++ b/drivers/char/pcmcia/cm4040_cs.c @@ -0,0 +1,900 @@ + /* + * A driver for the Omnikey PCMCIA smartcard reader CardMan 4040 + * + * (c) 2000-2004 Omnikey AG (http://www.omnikey.com/) + * + * (C) 2005 Harald Welte [EMAIL PROTECTED] + * - add support for poll() + * - driver cleanup + * - add waitqueues + * - adhere to linux kenrel coding style and policies + * - support 2.6.13 new style pcmcia interface + * + * All rights reserved, Dual BSD/GPL Licensed. + */ + +/* #define PCMCIA_DEBUG 6 */ + +#include linux/config.h +#include linux/version.h + +#include linux/kernel.h +#include linux/module.h +#include linux/slab.h +#include linux/init.h +#include linux/fs.h +#include linux/delay.h +#include linux/poll.h +#include asm/uaccess.h +#include asm/io.h + +#include pcmcia/version.h +#include pcmcia/cs_types.h +#include pcmcia/cs.h +#include pcmcia/cistpl.h +#include pcmcia/cisreg.h +#include pcmcia/ciscode.h +#include pcmcia/ds.h + +#include cm4040_cs.h + +static atomic_t cmx_num_devices_open; + +#ifdef PCMCIA_DEBUG +static int pc_debug = PCMCIA_DEBUG; +module_param(pc_debug, int, 0600); +#define DEBUG(n, x, args...) do { if (pc_debug = (n)) \ + printk(KERN_DEBUG %s:%s: x, MODULE_NAME, \ +__FUNCTION__, ##args); } while (0) +#else +#define DEBUG(n, args...) +#endif + +static volatile char *version = +OMNIKEY CardMan 4040 v1.1.0gm3 - All bugs added by Harald Welte; + +#defineCCID_DRIVER_BULK_DEFAULT_TIMEOUT(150*HZ) +#defineCCID_DRIVER_ASYNC_POWERUP_TIMEOUT (35*HZ) +#defineCCID_DRIVER_MINIMUM_TIMEOUT (3*HZ) +#define READ_WRITE_BUFFER_SIZE 512 +#define POLL_LOOP_COUNT1000 + +/* how often to poll for fifo status change */ +#define POLL_PERIOD(HZ/100) + +static void reader_release(u_long arg); +static void reader_detach(dev_link_t *link); + +static int major; + +#define
Re: [PATCH] New: Omnikey CardMan 4040 PCMCIA Driver
On Sun, Sep 04, 2005 at 12:12:18PM +0200, Harald Welte wrote: Hi! Below you can find a driver for the Omnikey CardMan 4040 PCMCIA Smartcard Reader. Sorry, the patch was missing a cg-add of the header file. Please use the patch below. -- - Harald Welte [EMAIL PROTECTED] http://gnumonks.org/ Privacy in residential applications is a desirable marketing option. (ETSI EN 300 175-7 Ch. A6) Add Omnikey CardMan 4040 Driver Signed-off-by: Harald Welte [EMAIL PROTECTED] --- commit 0e760a5785ebb83b932d104679cc2b2b4070b1c1 tree 46d71d0c6b41b441a1a8d725b741450f1334296e parent c4ab879b6ef599bf88d19b9b145878ef73400ce7 author Harald Welte [EMAIL PROTECTED] So, 04 Sep 2005 13:05:44 +0200 committer Harald Welte [EMAIL PROTECTED] So, 04 Sep 2005 13:05:44 +0200 MAINTAINERS |5 drivers/char/pcmcia/Kconfig | 13 + drivers/char/pcmcia/Makefile|1 drivers/char/pcmcia/cm4040_cs.c | 900 +++ drivers/char/pcmcia/cm4040_cs.h | 52 ++ 5 files changed, 971 insertions(+), 0 deletions(-) diff --git a/MAINTAINERS b/MAINTAINERS --- a/MAINTAINERS +++ b/MAINTAINERS @@ -1737,6 +1737,11 @@ L: [EMAIL PROTECTED] W: http://www.linuxtr.net S: Maintained +OMNIKEY CARDMAN 4040 DRIVER +P: Harald Welte +M: [EMAIL PROTECTED] +S: Maintained + ONSTREAM SCSI TAPE DRIVER P: Willem Riede M: [EMAIL PROTECTED] diff --git a/drivers/char/pcmcia/Kconfig b/drivers/char/pcmcia/Kconfig --- a/drivers/char/pcmcia/Kconfig +++ b/drivers/char/pcmcia/Kconfig @@ -18,5 +18,18 @@ config SYNCLINK_CS The module will be called synclinkmp. If you want to do that, say M here. +config CARDMAN_4040 + tristate Omnikey CardMan 4040 support + depends on PCMCIA + help + Enable support for the Omnikey CardMan 4040 PCMCIA Smartcard + reader. + + This card is basically a USB CCID device connected to a FIFO + in I/O space. To use the kernel driver, you will need either the + PC/SC ifdhandler provided from the Omnikey homepage + (http://www.omnikey.com/), or a current development version of OpenCT + (http://www.opensc.org/). + endmenu diff --git a/drivers/char/pcmcia/Makefile b/drivers/char/pcmcia/Makefile --- a/drivers/char/pcmcia/Makefile +++ b/drivers/char/pcmcia/Makefile @@ -5,3 +5,4 @@ # obj-$(CONFIG_SYNCLINK_CS) += synclink_cs.o +obj-$(CONFIG_CARDMAN_4040) += cm4040_cs.o diff --git a/drivers/char/pcmcia/cm4040_cs.c b/drivers/char/pcmcia/cm4040_cs.c new file mode 100644 --- /dev/null +++ b/drivers/char/pcmcia/cm4040_cs.c @@ -0,0 +1,900 @@ + /* + * A driver for the Omnikey PCMCIA smartcard reader CardMan 4040 + * + * (c) 2000-2004 Omnikey AG (http://www.omnikey.com/) + * + * (C) 2005 Harald Welte [EMAIL PROTECTED] + * - add support for poll() + * - driver cleanup + * - add waitqueues + * - adhere to linux kenrel coding style and policies + * - support 2.6.13 new style pcmcia interface + * + * All rights reserved, Dual BSD/GPL Licensed. + */ + +/* #define PCMCIA_DEBUG 6 */ + +#include linux/config.h +#include linux/version.h + +#include linux/kernel.h +#include linux/module.h +#include linux/slab.h +#include linux/init.h +#include linux/fs.h +#include linux/delay.h +#include linux/poll.h +#include asm/uaccess.h +#include asm/io.h + +#include pcmcia/version.h +#include pcmcia/cs_types.h +#include pcmcia/cs.h +#include pcmcia/cistpl.h +#include pcmcia/cisreg.h +#include pcmcia/ciscode.h +#include pcmcia/ds.h + +#include cm4040_cs.h + +static atomic_t cmx_num_devices_open; + +#ifdef PCMCIA_DEBUG +static int pc_debug = PCMCIA_DEBUG; +module_param(pc_debug, int, 0600); +#define DEBUG(n, x, args...) do { if (pc_debug = (n)) \ + printk(KERN_DEBUG %s:%s: x, MODULE_NAME, \ +__FUNCTION__, ##args); } while (0) +#else +#define DEBUG(n, args...) +#endif + +static volatile char *version = +OMNIKEY CardMan 4040 v1.1.0gm3 - All bugs added by Harald Welte; + +#defineCCID_DRIVER_BULK_DEFAULT_TIMEOUT(150*HZ) +#defineCCID_DRIVER_ASYNC_POWERUP_TIMEOUT (35*HZ) +#defineCCID_DRIVER_MINIMUM_TIMEOUT (3*HZ) +#define READ_WRITE_BUFFER_SIZE 512 +#define POLL_LOOP_COUNT1000 + +/* how often to poll for fifo status change */ +#define POLL_PERIOD(HZ/100) + +static void reader_release(u_long arg); +static void reader_detach(dev_link_t *link); + +static int major; + +#defineBS_READABLE 0x01 +#defineBS_WRITABLE 0x02 + +typedef struct reader_dev_t { + dev_link_t link; + dev_node_t node
Re: APs from the Kernel Summit run Linux
On Tue, Aug 30, 2005 at 02:18:10PM +0200, Vojtech Pavlik wrote: > > If it is from the ASUS, what makes you think that the D-Link runs the > > same OS? It is quite often the case that one chipset design has > > multiple operating systems ported to it (you see systems with the same > > broadcom or Intersil chipset, one running Linux, the other VxWorks). > > > Please indicate how you came to the conclusion that the D-Link really > > runs Linux. > > The device's ESSID during boot is 'Marvell AP-32', and the Libertas > AP-32 and AP-52 design toolkits contain only ports of Linux and eCos to > the device, according to Marvell. Considering the device's routing > capabilities I'm believe it's running Linux, but I don't have a solid > proof yet, unfortunately. The eCos port is intended for the non-router > variety of the design. There could also be a 3rd party toolkit with a different OS that you don't know about... > On the other hand, eCos seems to be GPL, too, although it's possible > that the owner dual-licenses it. According to http://sources.redhat.com/ecos/, it is either still RedHat or already transferred to the FSF. That doesn't sound like dual licensing, I don't think the FSF would do that... > > > A firmware image is available from D-Link > > > and it seems to be composed of compressed blocks padded by zeroes. I > > > haven't > > > verified yet that it's indeed a compressed kernel, cramfs, etc, but it > > > seems > > > quite likely. > > > > I'm downloading it right now, and I'll see whether I can find any Linux > > in there. > > Good luck. I'll try to take a look, too. Up to now I can only tell you that it doesn't look like any of the 50+ linux firmware images I've seen so far. > > Sure, it's (unfortunately) not the first time I'm dealing with D-Link on > > their GPL [in]compliance :(( > > Rather unrelated, I'm trying to figure out what to do with Elo > Touchsystems, they used my HID driver as a base of their own binary-only > driver and don't answer to e-mail. Well, if you seriously want to do something about it: They have a German subsidiary. So if the respective product can be bought through that .de office, we can do something about it here. Let's take this offline. -- - Harald Welte <[EMAIL PROTECTED]> http://gpl-violations.org/ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) pgpinh5n2os13.pgp Description: PGP signature
Re: APs from the Kernel Summit run Linux
On Tue, Aug 30, 2005 at 10:55:22AM +0200, Vojtech Pavlik wrote: > Hi! > > The D-Link DWL-G730AP devices from the Kernel Summit run Linux, And it's > likely a GPL violation, too, since sources are nowhere to be found. *lol*. Interestingly they must have twiddled the IP stack since when I tried an "nmap" on the device, it didn't recognize it as a Linux TCP/IP stack. > They're based on a Marvell Libertas AP-32 (ARM9) design, similar > to the ASUS WL-530g. A bootlog from the ASUS (which has telnet enabled > for some reason, and thus can be logged in) is at the end of the mail. So you grabbed that bootlog from the ASUS device, or from the D-Link? If it is from the ASUS, what makes you think that the D-Link runs the same OS? It is quite often the case that one chipset design has multiple operating systems ported to it (you see systems with the same broadcom or Intersil chipset, one running Linux, the other VxWorks). Please indicate how you came to the conclusion that the D-Link really runs Linux. > A firmware image is available from D-Link > (ftp://ftp.dlink.com/Wireless/dwlg730AP/Firmware/dwlg730ap_firmware_100.bin), > and it seems to be composed of compressed blocks padded by zeroes. I haven't > verified yet that it's indeed a compressed kernel, cramfs, etc, but it seems > quite likely. I'm downloading it right now, and I'll see whether I can find any Linux in there. > Anyone interested in dissecting it, and pushing D-Link/Marvell to release > the kernel sources? Sure, it's (unfortunately) not the first time I'm dealing with D-Link on their GPL [in]compliance :(( > I'd love to get more out of this cute device ... If the design really is identical enough to the ASUS device, then I suggest looking into http://dlsvr02.asus.com/pub/ASUS/wireless/WL-530g/GPL_1825.zip Cheers, -- - Harald Welte <[EMAIL PROTECTED]> http://gpl-violations.org/ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) pgprOeIMoVspG.pgp Description: PGP signature
Re: APs from the Kernel Summit run Linux
On Tue, Aug 30, 2005 at 10:55:22AM +0200, Vojtech Pavlik wrote: Hi! The D-Link DWL-G730AP devices from the Kernel Summit run Linux, And it's likely a GPL violation, too, since sources are nowhere to be found. *lol*. Interestingly they must have twiddled the IP stack since when I tried an nmap on the device, it didn't recognize it as a Linux TCP/IP stack. They're based on a Marvell Libertas AP-32 (ARM9) design, similar to the ASUS WL-530g. A bootlog from the ASUS (which has telnet enabled for some reason, and thus can be logged in) is at the end of the mail. So you grabbed that bootlog from the ASUS device, or from the D-Link? If it is from the ASUS, what makes you think that the D-Link runs the same OS? It is quite often the case that one chipset design has multiple operating systems ported to it (you see systems with the same broadcom or Intersil chipset, one running Linux, the other VxWorks). Please indicate how you came to the conclusion that the D-Link really runs Linux. A firmware image is available from D-Link (ftp://ftp.dlink.com/Wireless/dwlg730AP/Firmware/dwlg730ap_firmware_100.bin), and it seems to be composed of compressed blocks padded by zeroes. I haven't verified yet that it's indeed a compressed kernel, cramfs, etc, but it seems quite likely. I'm downloading it right now, and I'll see whether I can find any Linux in there. Anyone interested in dissecting it, and pushing D-Link/Marvell to release the kernel sources? Sure, it's (unfortunately) not the first time I'm dealing with D-Link on their GPL [in]compliance :(( I'd love to get more out of this cute device ... If the design really is identical enough to the ASUS device, then I suggest looking into http://dlsvr02.asus.com/pub/ASUS/wireless/WL-530g/GPL_1825.zip Cheers, -- - Harald Welte [EMAIL PROTECTED] http://gpl-violations.org/ Privacy in residential applications is a desirable marketing option. (ETSI EN 300 175-7 Ch. A6) pgprOeIMoVspG.pgp Description: PGP signature
Re: APs from the Kernel Summit run Linux
On Tue, Aug 30, 2005 at 02:18:10PM +0200, Vojtech Pavlik wrote: If it is from the ASUS, what makes you think that the D-Link runs the same OS? It is quite often the case that one chipset design has multiple operating systems ported to it (you see systems with the same broadcom or Intersil chipset, one running Linux, the other VxWorks). Please indicate how you came to the conclusion that the D-Link really runs Linux. The device's ESSID during boot is 'Marvell AP-32', and the Libertas AP-32 and AP-52 design toolkits contain only ports of Linux and eCos to the device, according to Marvell. Considering the device's routing capabilities I'm believe it's running Linux, but I don't have a solid proof yet, unfortunately. The eCos port is intended for the non-router variety of the design. There could also be a 3rd party toolkit with a different OS that you don't know about... On the other hand, eCos seems to be GPL, too, although it's possible that the owner dual-licenses it. According to http://sources.redhat.com/ecos/, it is either still RedHat or already transferred to the FSF. That doesn't sound like dual licensing, I don't think the FSF would do that... A firmware image is available from D-Link and it seems to be composed of compressed blocks padded by zeroes. I haven't verified yet that it's indeed a compressed kernel, cramfs, etc, but it seems quite likely. I'm downloading it right now, and I'll see whether I can find any Linux in there. Good luck. I'll try to take a look, too. Up to now I can only tell you that it doesn't look like any of the 50+ linux firmware images I've seen so far. Sure, it's (unfortunately) not the first time I'm dealing with D-Link on their GPL [in]compliance :(( Rather unrelated, I'm trying to figure out what to do with Elo Touchsystems, they used my HID driver as a base of their own binary-only driver and don't answer to e-mail. Well, if you seriously want to do something about it: They have a German subsidiary. So if the respective product can be bought through that .de office, we can do something about it here. Let's take this offline. -- - Harald Welte [EMAIL PROTECTED] http://gpl-violations.org/ Privacy in residential applications is a desirable marketing option. (ETSI EN 300 175-7 Ch. A6) pgpinh5n2os13.pgp Description: PGP signature
Re: oops in 2.6.13-rc6-git12 in tcp/netfilter routines
On Thu, Aug 25, 2005 at 11:02:01PM +0200, Sven Schuster wrote: > > Hi Harald, > > On Thu, Aug 25, 2005 at 06:55:50PM +0200, Harald Welte told us: > > Is it true that PeerGuardian is a proprietary application? I'm not > > going to debug this problem using a proprietary ip_queue program, sorry. > > sorry to jump in here, but I took a quick look at PeerGuardian, > according to > http://methlabs.org/wiki/license_information > it's open source. The source code is available at > http://methlabs.org/projects/peerguardian-linuxosx/ ok, thanks. Sorry for the confusion, but the 'official' website is just a blog that didn't really reveal all that much information. -- - Harald Welte <[EMAIL PROTECTED]> http://netfilter.org/ "Fragmentation is like classful addressing -- an interesting early architectural error that shows how much experimentation was going on while IP was being designed."-- Paul Vixie pgpS5H7yzk190.pgp Description: PGP signature
Re: oops in 2.6.13-rc6-git12 in tcp/netfilter routines
On Thu, Aug 25, 2005 at 11:02:01PM +0200, Sven Schuster wrote: Hi Harald, On Thu, Aug 25, 2005 at 06:55:50PM +0200, Harald Welte told us: Is it true that PeerGuardian is a proprietary application? I'm not going to debug this problem using a proprietary ip_queue program, sorry. sorry to jump in here, but I took a quick look at PeerGuardian, according to http://methlabs.org/wiki/license_information it's open source. The source code is available at http://methlabs.org/projects/peerguardian-linuxosx/ ok, thanks. Sorry for the confusion, but the 'official' website is just a blog that didn't really reveal all that much information. -- - Harald Welte [EMAIL PROTECTED] http://netfilter.org/ Fragmentation is like classful addressing -- an interesting early architectural error that shows how much experimentation was going on while IP was being designed.-- Paul Vixie pgpS5H7yzk190.pgp Description: PGP signature
Re: oops in 2.6.13-rc6-git12 in tcp/netfilter routines
On Thu, Aug 25, 2005 at 03:39:02PM +0200, Alessandro Suardi wrote: > Howdy, and excuse me for crossposting - feel free to zap CC to > unrelated, if any, mailing lists. > > just gave PeerGuardian a spin on my eDonkey home box and > said box didn't last half a day before oopsing in netlink/nf/tcp > related routines (or so it seems to my untrained eye). Yes, it indeed could be that there is some fishy interaction between the tcp stack and ip_queue causing the oops. > K7800, 256MB RAM, uptodate FC3 running 2.6.13-rc6-git12, > doing nothing but running MetaMachine's eDonkey 1.4.3 QT gui. > PeerGuardian is the 1.5 beta version available from methlabs.org. Is it true that PeerGuardian is a proprietary application? I'm not going to debug this problem using a proprietary ip_queue program, sorry. If you can produce a testcase with open source userspace ip_queue code, I could look into reproducing the problem locally and debugging the problem more thoroughly. While it definitely is a kernel bug (whatever userspace sends should not crash the kernel), it might be something that specifically [only] PeerGuardian does to the packet. Something that ip_queue doesn't check (but should check) on packet reinjection and therefore upsets the TCP stack. Also helpful would be the output of an "strace -f -x -s65535 -e trace=sendmsg" on the PeerGuardian (daemon?) process. > [] die+0xe4/0x170 > [] do_trap+0x7f/0xc0 > [] do_invalid_op+0xa3/0xb0 > [] error_code+0x4f/0x54 > [] kfree_skbmem+0xb/0x20 > [] __kfree_skb+0x5f/0xf0 ok, so something down the chain from kfree_skb() results in an invalid operation? looks more like some compiler problem, bad memory or memory corruption to me. Try to reproduce the problem without PG. > [] tcp_clean_rtx_queue+0x16a/0x470 > [] tcp_ack+0xf6/0x360 > [] tcp_rcv_established+0x277/0x7a0 > [] tcp_v4_do_rcv+0xf0/0x110 > [] tcp_v4_rcv+0x6e0/0x820 > [] ip_local_deliver_finish+0x84/0x160 so something in the tcp stack ends up doing tcp_clean_rtx_queue() > [] nf_reinject+0x13a/0x1c0 > [] ipq_issue_verdict+0x28/0x40 > [] ipq_set_verdict+0x48/0x70 ip_queue reinjects a packet via nf_reinject() > [] ipq_receive_peer+0x39/0x50 > [] ipq_receive_sk+0x172/0x190 ip_queue receives and ipq verdict msg packet from netlink > [] netlink_data_ready+0x35/0x60 > [] netlink_sendskb+0x24/0x60 > [] netlink_unicast+0x127/0x160 > [] netlink_sendmsg+0x204/0x2b0 > [] sock_sendmsg+0xb0/0xe0 > [] sys_sendmsg+0x134/0x240 > [] sys_socketcall+0x224/0x230 > [] sysenter_past_esp+0x54/0x75 process sendmsg()s on the netlink socket. -- - Harald Welte <[EMAIL PROTECTED]> http://netfilter.org/ "Fragmentation is like classful addressing -- an interesting early architectural error that shows how much experimentation was going on while IP was being designed."-- Paul Vixie pgpz7kKVQdD10.pgp Description: PGP signature
Re: oops in 2.6.13-rc6-git12 in tcp/netfilter routines
On Thu, Aug 25, 2005 at 03:39:02PM +0200, Alessandro Suardi wrote: Howdy, and excuse me for crossposting - feel free to zap CC to unrelated, if any, mailing lists. just gave PeerGuardian a spin on my eDonkey home box and said box didn't last half a day before oopsing in netlink/nf/tcp related routines (or so it seems to my untrained eye). Yes, it indeed could be that there is some fishy interaction between the tcp stack and ip_queue causing the oops. K7800, 256MB RAM, uptodate FC3 running 2.6.13-rc6-git12, doing nothing but running MetaMachine's eDonkey 1.4.3 QT gui. PeerGuardian is the 1.5 beta version available from methlabs.org. Is it true that PeerGuardian is a proprietary application? I'm not going to debug this problem using a proprietary ip_queue program, sorry. If you can produce a testcase with open source userspace ip_queue code, I could look into reproducing the problem locally and debugging the problem more thoroughly. While it definitely is a kernel bug (whatever userspace sends should not crash the kernel), it might be something that specifically [only] PeerGuardian does to the packet. Something that ip_queue doesn't check (but should check) on packet reinjection and therefore upsets the TCP stack. Also helpful would be the output of an strace -f -x -s65535 -e trace=sendmsg on the PeerGuardian (daemon?) process. [c0103714] die+0xe4/0x170 [c010381f] do_trap+0x7f/0xc0 [c0103b33] do_invalid_op+0xa3/0xb0 [c0102faf] error_code+0x4f/0x54 [c02eb05b] kfree_skbmem+0xb/0x20 [c02eb0cf] __kfree_skb+0x5f/0xf0 ok, so something down the chain from kfree_skb() results in an invalid operation? looks more like some compiler problem, bad memory or memory corruption to me. Try to reproduce the problem without PG. [c031304a] tcp_clean_rtx_queue+0x16a/0x470 [c0313746] tcp_ack+0xf6/0x360 [c0315d57] tcp_rcv_established+0x277/0x7a0 [c031eba0] tcp_v4_do_rcv+0xf0/0x110 [c031f2a0] tcp_v4_rcv+0x6e0/0x820 [c0305594] ip_local_deliver_finish+0x84/0x160 so something in the tcp stack ends up doing tcp_clean_rtx_queue() [c02fbe4a] nf_reinject+0x13a/0x1c0 [c033f0d8] ipq_issue_verdict+0x28/0x40 [c033f968] ipq_set_verdict+0x48/0x70 ip_queue reinjects a packet via nf_reinject() [c033fa79] ipq_receive_peer+0x39/0x50 [c033fc72] ipq_receive_sk+0x172/0x190 ip_queue receives and ipq verdict msg packet from netlink [c02fffa5] netlink_data_ready+0x35/0x60 [c02ff4a4] netlink_sendskb+0x24/0x60 [c02ff657] netlink_unicast+0x127/0x160 [c02ffcc4] netlink_sendmsg+0x204/0x2b0 [c02e6dc0] sock_sendmsg+0xb0/0xe0 [c02e83f4] sys_sendmsg+0x134/0x240 [c02e88e4] sys_socketcall+0x224/0x230 [c0102d3b] sysenter_past_esp+0x54/0x75 process sendmsg()s on the netlink socket. -- - Harald Welte [EMAIL PROTECTED] http://netfilter.org/ Fragmentation is like classful addressing -- an interesting early architectural error that shows how much experimentation was going on while IP was being designed.-- Paul Vixie pgpz7kKVQdD10.pgp Description: PGP signature
Re: 2.6.13-rc5-mm1: BUG: rwlock recursion on CPU#0
On Sun, Aug 14, 2005 at 08:15:53PM -0600, Zwane Mwaikambo wrote: > Is the following patch correct? ip_conntrack_event_cache should never be > called with ip_conntrack_lock held and ct_add_counters does not need to be > called with ip_conntrack_lock held. No, it's not correct. ct_add_countes has to be called from within write_lock_bh() on ip_conntrack_lock. So if you keep the ct_add_counters() call where it is and only apply the rest of your patch (i.e. deferring of ip_conntrack_event_cache() call), then I think your patch would work. However, the whole eventcache needs to be audited, it's called from a number of places. As Patrick wrote he's working on a solution, I'm not going to intervene or replicate his work. As a interim solution I'd suggest disabling CONFIG_IP_NF_CT_ACCT [which can't be vital anyway, since it was only added in net-2.6.14 (and thus -mm)]. Cheers, -- - Harald Welte <[EMAIL PROTECTED]> http://netfilter.org/ "Fragmentation is like classful addressing -- an interesting early architectural error that shows how much experimentation was going on while IP was being designed."-- Paul Vixie pgp4mtnL5UmbM.pgp Description: PGP signature
Re: 2.6.13-rc5-mm1: BUG: rwlock recursion on CPU#0
On Sun, Aug 14, 2005 at 08:15:53PM -0600, Zwane Mwaikambo wrote: Is the following patch correct? ip_conntrack_event_cache should never be called with ip_conntrack_lock held and ct_add_counters does not need to be called with ip_conntrack_lock held. No, it's not correct. ct_add_countes has to be called from within write_lock_bh() on ip_conntrack_lock. So if you keep the ct_add_counters() call where it is and only apply the rest of your patch (i.e. deferring of ip_conntrack_event_cache() call), then I think your patch would work. However, the whole eventcache needs to be audited, it's called from a number of places. As Patrick wrote he's working on a solution, I'm not going to intervene or replicate his work. As a interim solution I'd suggest disabling CONFIG_IP_NF_CT_ACCT [which can't be vital anyway, since it was only added in net-2.6.14 (and thus -mm)]. Cheers, -- - Harald Welte [EMAIL PROTECTED] http://netfilter.org/ Fragmentation is like classful addressing -- an interesting early architectural error that shows how much experimentation was going on while IP was being designed.-- Paul Vixie pgp4mtnL5UmbM.pgp Description: PGP signature
Re: git-net-fixup.patch added to -mm tree
On Sun, Jul 31, 2005 at 10:12:46PM -0700, David S. Miller wrote: > From: [EMAIL PROTECTED] > Date: Sun, 31 Jul 2005 22:03:47 -0700 > > > From: Andrew Morton <[EMAIL PROTECTED]> > > > > Signed-off-by: Andrew Morton <[EMAIL PROTECTED]> > ... > > /* decrement reference count on a conntrack */ > > -extern void ip_conntrack_put(struct ip_conntrack *ct); > > +static inline void > > +ip_conntrack_put(struct ip_conntrack *ct) > > +{ > > + IP_NF_ASSERT(ct); > > + nf_conntrack_put(>ct_general); > > +} > > You can instead just kill the EXPORT_SYMBOL_GPL() in > ip_conntrack_standalone.c as that's the only reference outside of > ip_conntrack_core.c for 2.6.13 this should work. net-2.6.14 contains ip_conntrack_netlink.c, which needs ip_conntrakc_put (and therefore the EXPORT_SYMBOL_GPL(). We also have other code out-of-tree (e.g. ct_sync) that need the symbo. I know this is no rectification, but I'm merely mentioning it JFYI. -- - Harald Welte <[EMAIL PROTECTED]> http://gnumonks.org/ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) pgpsXtiVh9Se7.pgp Description: PGP signature
Re: git-net-fixup.patch added to -mm tree
On Sun, Jul 31, 2005 at 10:12:46PM -0700, David S. Miller wrote: From: [EMAIL PROTECTED] Date: Sun, 31 Jul 2005 22:03:47 -0700 From: Andrew Morton [EMAIL PROTECTED] Signed-off-by: Andrew Morton [EMAIL PROTECTED] ... /* decrement reference count on a conntrack */ -extern void ip_conntrack_put(struct ip_conntrack *ct); +static inline void +ip_conntrack_put(struct ip_conntrack *ct) +{ + IP_NF_ASSERT(ct); + nf_conntrack_put(ct-ct_general); +} You can instead just kill the EXPORT_SYMBOL_GPL() in ip_conntrack_standalone.c as that's the only reference outside of ip_conntrack_core.c for 2.6.13 this should work. net-2.6.14 contains ip_conntrack_netlink.c, which needs ip_conntrakc_put (and therefore the EXPORT_SYMBOL_GPL(). We also have other code out-of-tree (e.g. ct_sync) that need the symbo. I know this is no rectification, but I'm merely mentioning it JFYI. -- - Harald Welte [EMAIL PROTECTED] http://gnumonks.org/ Privacy in residential applications is a desirable marketing option. (ETSI EN 300 175-7 Ch. A6) pgpsXtiVh9Se7.pgp Description: PGP signature
Re: iptables redirect is broken on bridged setup
On Fri, Jul 29, 2005 at 03:11:35PM +0300, Denis Vlasenko wrote: > Note that REDIRECT loads ip_conntrack, and this seem to > cause problems, see another bugzilla entry at > https://bugzilla.netfilter.org/bugzilla/show_bug.cgi?id=339 REDIRECT is a for of DNAT, like you correctly state. DNAT _needs_ ip_conntrack, so that's not what is causing problems. Causing problems is probably the nf_reset() and other hacks that were put into the briding code to remove conntrack references once a packet enters the bridge (in order to make the 'fake iptables hooks' from the bridging code work). There were recently a number of fixes for this issue, which each caused new bugs. Could you please try with a current development kernel (linus' git tree, or davem's net-2.6.14 tree) and see if the problem persists? -- - Harald Welte <[EMAIL PROTECTED]> http://netfilter.org/ "Fragmentation is like classful addressing -- an interesting early architectural error that shows how much experimentation was going on while IP was being designed."-- Paul Vixie pgpT5xFPiJ24e.pgp Description: PGP signature
Re: iptables redirect is broken on bridged setup
[removed a number of unneccessarry CC's from list] On Fri, Jul 29, 2005 at 12:11:52PM +0300, Denis Vlasenko wrote: > Linux 2.6.12 Denis, your bug is not getting fixed faster, no matter how often you will post it at how many places and to how many recipients. We have seen it, and we will look at it. bridging and netfilter/iptables is always a very tricky case, and the code was developed by separate groups who - as it is my impression - don't fully understand each others codebase too well. Also, many of the possible combinations of bridging and netfilter/iptables have apparently not been tested (or even used by anyone), so I'm not surprised that you see some unexpected behaviour. Also, the bridging/ebtables maintainer Bart de Schuymer is currently on holidays, as I understand. So please be patient. -- - Harald Welte <[EMAIL PROTECTED]> http://netfilter.org/ "Fragmentation is like classful addressing -- an interesting early architectural error that shows how much experimentation was going on while IP was being designed."-- Paul Vixie pgpyBlS3uLVpN.pgp Description: PGP signature
Re: iptables redirect is broken on bridged setup
[removed a number of unneccessarry CC's from list] On Fri, Jul 29, 2005 at 12:11:52PM +0300, Denis Vlasenko wrote: Linux 2.6.12 Denis, your bug is not getting fixed faster, no matter how often you will post it at how many places and to how many recipients. We have seen it, and we will look at it. bridging and netfilter/iptables is always a very tricky case, and the code was developed by separate groups who - as it is my impression - don't fully understand each others codebase too well. Also, many of the possible combinations of bridging and netfilter/iptables have apparently not been tested (or even used by anyone), so I'm not surprised that you see some unexpected behaviour. Also, the bridging/ebtables maintainer Bart de Schuymer is currently on holidays, as I understand. So please be patient. -- - Harald Welte [EMAIL PROTECTED] http://netfilter.org/ Fragmentation is like classful addressing -- an interesting early architectural error that shows how much experimentation was going on while IP was being designed.-- Paul Vixie pgpyBlS3uLVpN.pgp Description: PGP signature
Re: iptables redirect is broken on bridged setup
On Fri, Jul 29, 2005 at 03:11:35PM +0300, Denis Vlasenko wrote: Note that REDIRECT loads ip_conntrack, and this seem to cause problems, see another bugzilla entry at https://bugzilla.netfilter.org/bugzilla/show_bug.cgi?id=339 REDIRECT is a for of DNAT, like you correctly state. DNAT _needs_ ip_conntrack, so that's not what is causing problems. Causing problems is probably the nf_reset() and other hacks that were put into the briding code to remove conntrack references once a packet enters the bridge (in order to make the 'fake iptables hooks' from the bridging code work). There were recently a number of fixes for this issue, which each caused new bugs. Could you please try with a current development kernel (linus' git tree, or davem's net-2.6.14 tree) and see if the problem persists? -- - Harald Welte [EMAIL PROTECTED] http://netfilter.org/ Fragmentation is like classful addressing -- an interesting early architectural error that shows how much experimentation was going on while IP was being designed.-- Paul Vixie pgpT5xFPiJ24e.pgp Description: PGP signature
Re: [PATCH] 1 Wire drivers illegally overload NETLINK_NFLOG
On Sun, Jul 24, 2005 at 07:15:05PM -0700, David S. Miller wrote: > > I strongly disrecommend increasing NPROTO. Maybe we should look into > > reusing NETLINK_FIREWALL (which was an old 2.2.x kernel interface). > > ip_queue.c still uses NETLINK_FIREWALL so we really can't use > that. sorry, I didn't remember that ip_queue reused the 2.2.x netlink number :( We should have renamed it to make it clear. > So instead, as in the patch below, I solved this for now by using > the NETLINK_SKIP value which was reserved years ago yet never > made use of. thanks. -- - Harald Welte <[EMAIL PROTECTED]> http://netfilter.org/ "Fragmentation is like classful addressing -- an interesting early architectural error that shows how much experimentation was going on while IP was being designed."-- Paul Vixie pgpHVOu8MUreE.pgp Description: PGP signature
Re: Netlink connector
On Mon, Jul 25, 2005 at 11:33:51PM +0400, Evgeniy Polyakov wrote: > Netlink is transport protocol - no need to add complexity into it, > it must be as simple as possible and thus extensible. yes. but when you run into a serious addressing shortage (like the internet does with ipv4), you develop something that provides more addresses (such as ipv6). That's why support for more groups than 32 (per family) is something that should be put in the netlink protocol. I totally agree that we need a higher-level api on top of that, in order to hide the details of the networking stack for those not interested in it. -- - Harald Welte <[EMAIL PROTECTED]> http://netfilter.org/ "Fragmentation is like classful addressing -- an interesting early architectural error that shows how much experimentation was going on while IP was being designed."-- Paul Vixie pgpyoFvK5oqLK.pgp Description: PGP signature
Re: Netlink connector
On Mon, Jul 25, 2005 at 02:02:10AM -0400, James Morris wrote: > On Sun, 24 Jul 2005, David S. Miller wrote: > >From: Evgeniy Polyakov <[EMAIL PROTECTED]> > >Date: Sat, 23 Jul 2005 13:14:55 +0400 > >>Andrew has no objection against connector and it lives in -mm > >A patch sitting in -mm has zero significance. > > The significance I think is that Andrew is trying to gently encourage some > further progress in the area. Patrick McHardy is currently working on some ideas on how to extend netlink. The fundamental problem that the connector is trying to solve: 1) provide more 'groups' (to transport more different kinds of events) 2) provide an abstract API for other kernel code, so it doesn't have to know anything about skb's or networking. IMHO issue number '1' should (and can) be adressed within netlink. Wait for Patrick's work on this to show up on netdev. We can then think whether the connctor API (or something similar) can be put on top of it. -- - Harald Welte <[EMAIL PROTECTED]> http://netfilter.org/ "Fragmentation is like classful addressing -- an interesting early architectural error that shows how much experimentation was going on while IP was being designed."-- Paul Vixie pgpR29EQBIMUR.pgp Description: PGP signature
Re: Netlink connector
On Mon, Jul 25, 2005 at 02:02:10AM -0400, James Morris wrote: On Sun, 24 Jul 2005, David S. Miller wrote: From: Evgeniy Polyakov [EMAIL PROTECTED] Date: Sat, 23 Jul 2005 13:14:55 +0400 Andrew has no objection against connector and it lives in -mm A patch sitting in -mm has zero significance. The significance I think is that Andrew is trying to gently encourage some further progress in the area. Patrick McHardy is currently working on some ideas on how to extend netlink. The fundamental problem that the connector is trying to solve: 1) provide more 'groups' (to transport more different kinds of events) 2) provide an abstract API for other kernel code, so it doesn't have to know anything about skb's or networking. IMHO issue number '1' should (and can) be adressed within netlink. Wait for Patrick's work on this to show up on netdev. We can then think whether the connctor API (or something similar) can be put on top of it. -- - Harald Welte [EMAIL PROTECTED] http://netfilter.org/ Fragmentation is like classful addressing -- an interesting early architectural error that shows how much experimentation was going on while IP was being designed.-- Paul Vixie pgpR29EQBIMUR.pgp Description: PGP signature
Re: Netlink connector
On Mon, Jul 25, 2005 at 11:33:51PM +0400, Evgeniy Polyakov wrote: Netlink is transport protocol - no need to add complexity into it, it must be as simple as possible and thus extensible. yes. but when you run into a serious addressing shortage (like the internet does with ipv4), you develop something that provides more addresses (such as ipv6). That's why support for more groups than 32 (per family) is something that should be put in the netlink protocol. I totally agree that we need a higher-level api on top of that, in order to hide the details of the networking stack for those not interested in it. -- - Harald Welte [EMAIL PROTECTED] http://netfilter.org/ Fragmentation is like classful addressing -- an interesting early architectural error that shows how much experimentation was going on while IP was being designed.-- Paul Vixie pgpyoFvK5oqLK.pgp Description: PGP signature
Re: [PATCH] 1 Wire drivers illegally overload NETLINK_NFLOG
On Sun, Jul 24, 2005 at 07:15:05PM -0700, David S. Miller wrote: I strongly disrecommend increasing NPROTO. Maybe we should look into reusing NETLINK_FIREWALL (which was an old 2.2.x kernel interface). ip_queue.c still uses NETLINK_FIREWALL so we really can't use that. sorry, I didn't remember that ip_queue reused the 2.2.x netlink number :( We should have renamed it to make it clear. So instead, as in the patch below, I solved this for now by using the NETLINK_SKIP value which was reserved years ago yet never made use of. thanks. -- - Harald Welte [EMAIL PROTECTED] http://netfilter.org/ Fragmentation is like classful addressing -- an interesting early architectural error that shows how much experimentation was going on while IP was being designed.-- Paul Vixie pgpHVOu8MUreE.pgp Description: PGP signature
Re: [PATCH] 1 Wire drivers illegally overload NETLINK_NFLOG
On Fri, Jul 22, 2005 at 11:05:59PM -0400, YOSHIFUJI Hideaki / 吉藤英明 wrote: > In article <[EMAIL PROTECTED]> (at Sat, 23 Jul 2005 08:54:27 -0400), Harald > Welte <[EMAIL PROTECTED]> says: > > > --- a/include/linux/netlink.h > > +++ b/include/linux/netlink.h > > @@ -20,7 +20,7 @@ > > #define NETLINK_IP6_FW 13 > > #define NETLINK_DNRTMSG14 /* DECnet routing messages */ > > #define NETLINK_KOBJECT_UEVENT 15 /* Kernel messages to userspace > > */ > > -#define NETLINK_TAPBASE16 /* 16 to 31 are ethertap */ > > +#define NETLINK_W1 16 /* 16 to 31 are ethertap */ > > > > #define MAX_LINKS 32 > > > > Comment says that 16-31 are used for ethertap. > So, probably assigh NETLINK_W1 at 32, and bump MAX_LINKS? MAX_LINKS > 32 would result in larger statically allocated pointer arrays. It would also only work if NPROTO is increased too, IIRC. I strongly disrecommend increasing NPROTO. Maybe we should look into reusing NETLINK_FIREWALL (which was an old 2.2.x kernel interface). But to be honest, I don't really care all that much as long as existing and still very actively used values are not just overloaded. -- - Harald Welte <[EMAIL PROTECTED]> http://netfilter.org/ "Fragmentation is like classful addressing -- an interesting early architectural error that shows how much experimentation was going on while IP was being designed."-- Paul Vixie pgpTs1HzWp2SU.pgp Description: PGP signature
[PATCH] 1 Wire drivers illegally overload NETLINK_NFLOG
Hi Dave, Hi Evgeniy, the following patch fixes the illegal use of NETLINK_NFLOG by the 1wire drivers. It assumes that the netlink tap families can now safely be reclaimed, which is the case according to Dave at netconf'05. I'm not sure who would be the right person to fix this, but this patch needs to go into both 2.6.12.x and 2.6.13 trees, since it potentially causes a security problem by preventing the iptables ULOG This has been the third new piece of code that reuses NETLINK_NFLOG within a couple of months. I would really appreciate if people would actually ask/apply for a new protocol number instead of just overloading existing values and thereby causing breakage. Thanks, Harald -- - Harald Welte <[EMAIL PROTECTED]> http://netfilter.org/ "Fragmentation is like classful addressing -- an interesting early architectural error that shows how much experimentation was going on while IP was being designed."-- Paul Vixie Give the 1-wire driver stack its own netlink protocol number, instead of overloading NETLINK_NFLOG. I wonder what I have done to people, that they always overload the NETLINK_NFLOG protocol number and thereby effectively prevent the packet filter logging mechanism. Please don't re-use protocol numbers. Signed-off-by: Harald Welte <[EMAIL PROTECTED]> --- commit b4a566c332048b642506eff7de825fce710ff42c tree 07ef162f6d449dd67c586c9c63680004787b86c5 parent d5d3fb40b6db511dbd47a84634a1249de6b7b297 author laforge <[EMAIL PROTECTED]> Sa, 23 Jul 2005 08:41:24 -0400 committer laforge <[EMAIL PROTECTED]> Sa, 23 Jul 2005 08:41:24 -0400 drivers/w1/w1_int.c |4 ++-- include/linux/netlink.h |2 +- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/w1/w1_int.c b/drivers/w1/w1_int.c --- a/drivers/w1/w1_int.c +++ b/drivers/w1/w1_int.c @@ -88,10 +88,10 @@ static struct w1_master * w1_alloc_dev(u dev->groups = 23; dev->seq = 1; - dev->nls = netlink_kernel_create(NETLINK_NFLOG, NULL); + dev->nls = netlink_kernel_create(NETLINK_W1, NULL); if (!dev->nls) { printk(KERN_ERR "Failed to create new netlink socket(%u) for w1 master %s.\n", - NETLINK_NFLOG, dev->dev.bus_id); + NETLINK_W1, dev->dev.bus_id); } err = device_register(>dev); diff --git a/include/linux/netlink.h b/include/linux/netlink.h --- a/include/linux/netlink.h +++ b/include/linux/netlink.h @@ -20,7 +20,7 @@ #define NETLINK_IP6_FW 13 #define NETLINK_DNRTMSG14 /* DECnet routing messages */ #define NETLINK_KOBJECT_UEVENT 15 /* Kernel messages to userspace */ -#define NETLINK_TAPBASE16 /* 16 to 31 are ethertap */ +#define NETLINK_W1 16 /* 16 to 31 are ethertap */ #define MAX_LINKS 32 pgpMMbFchIvsE.pgp Description: PGP signature
[PATCH] 1 Wire drivers illegally overload NETLINK_NFLOG
Hi Dave, Hi Evgeniy, the following patch fixes the illegal use of NETLINK_NFLOG by the 1wire drivers. It assumes that the netlink tap families can now safely be reclaimed, which is the case according to Dave at netconf'05. I'm not sure who would be the right person to fix this, but this patch needs to go into both 2.6.12.x and 2.6.13 trees, since it potentially causes a security problem by preventing the iptables ULOG This has been the third new piece of code that reuses NETLINK_NFLOG within a couple of months. I would really appreciate if people would actually ask/apply for a new protocol number instead of just overloading existing values and thereby causing breakage. Thanks, Harald -- - Harald Welte [EMAIL PROTECTED] http://netfilter.org/ Fragmentation is like classful addressing -- an interesting early architectural error that shows how much experimentation was going on while IP was being designed.-- Paul Vixie Give the 1-wire driver stack its own netlink protocol number, instead of overloading NETLINK_NFLOG. I wonder what I have done to people, that they always overload the NETLINK_NFLOG protocol number and thereby effectively prevent the packet filter logging mechanism. Please don't re-use protocol numbers. Signed-off-by: Harald Welte [EMAIL PROTECTED] --- commit b4a566c332048b642506eff7de825fce710ff42c tree 07ef162f6d449dd67c586c9c63680004787b86c5 parent d5d3fb40b6db511dbd47a84634a1249de6b7b297 author laforge [EMAIL PROTECTED] Sa, 23 Jul 2005 08:41:24 -0400 committer laforge [EMAIL PROTECTED] Sa, 23 Jul 2005 08:41:24 -0400 drivers/w1/w1_int.c |4 ++-- include/linux/netlink.h |2 +- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/w1/w1_int.c b/drivers/w1/w1_int.c --- a/drivers/w1/w1_int.c +++ b/drivers/w1/w1_int.c @@ -88,10 +88,10 @@ static struct w1_master * w1_alloc_dev(u dev-groups = 23; dev-seq = 1; - dev-nls = netlink_kernel_create(NETLINK_NFLOG, NULL); + dev-nls = netlink_kernel_create(NETLINK_W1, NULL); if (!dev-nls) { printk(KERN_ERR Failed to create new netlink socket(%u) for w1 master %s.\n, - NETLINK_NFLOG, dev-dev.bus_id); + NETLINK_W1, dev-dev.bus_id); } err = device_register(dev-dev); diff --git a/include/linux/netlink.h b/include/linux/netlink.h --- a/include/linux/netlink.h +++ b/include/linux/netlink.h @@ -20,7 +20,7 @@ #define NETLINK_IP6_FW 13 #define NETLINK_DNRTMSG14 /* DECnet routing messages */ #define NETLINK_KOBJECT_UEVENT 15 /* Kernel messages to userspace */ -#define NETLINK_TAPBASE16 /* 16 to 31 are ethertap */ +#define NETLINK_W1 16 /* 16 to 31 are ethertap */ #define MAX_LINKS 32 pgpMMbFchIvsE.pgp Description: PGP signature
Re: [PATCH] 1 Wire drivers illegally overload NETLINK_NFLOG
On Fri, Jul 22, 2005 at 11:05:59PM -0400, YOSHIFUJI Hideaki / 吉藤英明 wrote: In article [EMAIL PROTECTED] (at Sat, 23 Jul 2005 08:54:27 -0400), Harald Welte [EMAIL PROTECTED] says: --- a/include/linux/netlink.h +++ b/include/linux/netlink.h @@ -20,7 +20,7 @@ #define NETLINK_IP6_FW 13 #define NETLINK_DNRTMSG14 /* DECnet routing messages */ #define NETLINK_KOBJECT_UEVENT 15 /* Kernel messages to userspace */ -#define NETLINK_TAPBASE16 /* 16 to 31 are ethertap */ +#define NETLINK_W1 16 /* 16 to 31 are ethertap */ #define MAX_LINKS 32 Comment says that 16-31 are used for ethertap. So, probably assigh NETLINK_W1 at 32, and bump MAX_LINKS? MAX_LINKS 32 would result in larger statically allocated pointer arrays. It would also only work if NPROTO is increased too, IIRC. I strongly disrecommend increasing NPROTO. Maybe we should look into reusing NETLINK_FIREWALL (which was an old 2.2.x kernel interface). But to be honest, I don't really care all that much as long as existing and still very actively used values are not just overloaded. -- - Harald Welte [EMAIL PROTECTED] http://netfilter.org/ Fragmentation is like classful addressing -- an interesting early architectural error that shows how much experimentation was going on while IP was being designed.-- Paul Vixie pgpTs1HzWp2SU.pgp Description: PGP signature
Re: Netfilter: TARPIT Target
On Thu, Feb 17, 2005 at 09:41:47AM -0500, Fao, Sean wrote: > I wanted to use the TARPIT target provided by Netfilter, but I am unable > to find the module in the kernel. Has it been removed or am I looking > in the wrong place? 1) it has never been in the mainstream kernel 2) the netfilter project doesn't support it's dangerous protocol abuse and will therefor never submit it into the mainline kernel 3) as compromise with the authors, we included it to be part of the patch-o-matic-ng patchset, available from http://www.netfilter.org/ > Sean E. Fao -- - Harald Welte <[EMAIL PROTECTED]> http://www.gnumonks.org/ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) signature.asc Description: Digital signature
Re: Netfilter: TARPIT Target
On Thu, Feb 17, 2005 at 09:41:47AM -0500, Fao, Sean wrote: I wanted to use the TARPIT target provided by Netfilter, but I am unable to find the module in the kernel. Has it been removed or am I looking in the wrong place? 1) it has never been in the mainstream kernel 2) the netfilter project doesn't support it's dangerous protocol abuse and will therefor never submit it into the mainline kernel 3) as compromise with the authors, we included it to be part of the patch-o-matic-ng patchset, available from http://www.netfilter.org/ Sean E. Fao -- - Harald Welte [EMAIL PROTECTED] http://www.gnumonks.org/ Privacy in residential applications is a desirable marketing option. (ETSI EN 300 175-7 Ch. A6) signature.asc Description: Digital signature
Re: Performance of iptables-restore on large rule sets
On Fri, Jan 28, 2005 at 12:56:30PM -0600, Steve Bergman wrote: > I have a large rule set (~53000 rules) that I sometimes load using > iptables-restore. (It takes almost an hour. That's really slow. I've seen multiple minutes, but an hour? What kind of system is this? How does the ruleset look like? Maybe some dns resolvals are timing out? > Googling around tells me that the loop detection code in the kernel is > slow with large rule sets. That's wrong. What used to be slow is libiptc. iptables-1.2.11 should actually already be significantly faster than all prior versions. Please try the current pre-1.3.0 snapshots from ftp://ftp.netfilter.org/pub/iptables/snapshot Please report back if they solve your performance issue. > Steve Bergman -- - Harald Welte <[EMAIL PROTECTED]> http://www.gnumonks.org/ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) signature.asc Description: Digital signature
Re: Performance of iptables-restore on large rule sets
On Fri, Jan 28, 2005 at 12:56:30PM -0600, Steve Bergman wrote: I have a large rule set (~53000 rules) that I sometimes load using iptables-restore. (It takes almost an hour. That's really slow. I've seen multiple minutes, but an hour? What kind of system is this? How does the ruleset look like? Maybe some dns resolvals are timing out? Googling around tells me that the loop detection code in the kernel is slow with large rule sets. That's wrong. What used to be slow is libiptc. iptables-1.2.11 should actually already be significantly faster than all prior versions. Please try the current pre-1.3.0 snapshots from ftp://ftp.netfilter.org/pub/iptables/snapshot Please report back if they solve your performance issue. Steve Bergman -- - Harald Welte [EMAIL PROTECTED] http://www.gnumonks.org/ Privacy in residential applications is a desirable marketing option. (ETSI EN 300 175-7 Ch. A6) signature.asc Description: Digital signature
Re: ipchains autoload
On Fri, Jun 08, 2001 at 07:17:22AM +0200, Nico Schottelius wrote: > Hello! > > I don't really know howto specify that kmod > should autoload the ipchains module, when I am > using ipchains. > > Anyone any idea howto tell kmod to load it then ? there is no way to do that. The problem is, that ipfwadm / ipchains and iptables use the same setsockopt() / getsockopt() based communication between kernel and userspace - so the kernel can never know which one of the three you want to load. > Nico -- Live long and prosper - Harald Welte / [EMAIL PROTECTED] http://www.gnumonks.org/ GCS/E/IT d- s-: a-- C+++ UL$ P+++ L$ E--- W- N++ o? K- w--- O- M- V-- PS+ PE-- Y+ PGP++ t++ 5-- !X !R tv-- b+++ DI? !D G+ e* h+ r% y+(*) - 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/