Re: [PATCH] panasonic-laptop: take over maintainership

2020-08-25 Thread Harald Welte
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

2020-08-22 Thread Harald Welte
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?

2019-04-07 Thread Harald Welte
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

2018-05-07 Thread Harald Welte
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

2018-05-07 Thread Harald Welte
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

2018-03-18 Thread Harald Welte
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

2018-03-18 Thread Harald Welte
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

2018-03-16 Thread Harald Welte
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

2018-03-16 Thread Harald Welte
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

2017-03-15 Thread Harald Welte
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

2017-03-15 Thread Harald Welte
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

2016-11-25 Thread Harald Welte
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

2016-11-25 Thread Harald Welte
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

2016-05-16 Thread Harald Welte
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

2016-05-16 Thread Harald Welte
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

2016-03-28 Thread Harald Welte
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

2016-03-28 Thread Harald Welte
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

2015-02-07 Thread Harald Welte
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

2015-02-07 Thread Harald Welte
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]

2013-04-16 Thread Harald Welte
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]

2013-04-16 Thread Harald Welte
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

2012-08-03 Thread Harald Welte
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

2012-08-03 Thread Harald Welte
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

2008-02-24 Thread Harald Welte
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

2008-02-24 Thread Harald Welte
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

2007-12-21 Thread Harald Welte
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

2007-12-21 Thread Harald Welte
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

2007-12-19 Thread Harald Welte
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

2007-12-19 Thread Harald Welte
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

2007-12-19 Thread Harald Welte
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

2007-12-19 Thread Harald Welte
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???

2007-12-14 Thread Harald Welte
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???

2007-12-14 Thread Harald Welte
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

2007-12-05 Thread Harald Welte
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

2007-12-05 Thread Harald Welte
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

2007-04-06 Thread Harald Welte
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

2007-04-06 Thread Harald Welte
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

2005-09-07 Thread Harald Welte
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

2005-09-07 Thread Harald Welte
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)

2005-09-06 Thread Harald Welte
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

2005-09-06 Thread Harald Welte
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

2005-09-06 Thread Harald Welte
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

2005-09-06 Thread Harald Welte
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

2005-09-06 Thread Harald Welte
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)

2005-09-06 Thread Harald Welte
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

2005-09-05 Thread Harald Welte
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

2005-09-05 Thread Harald Welte
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

2005-09-05 Thread Harald Welte
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

2005-09-05 Thread Harald Welte
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

2005-09-05 Thread Harald Welte
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

2005-09-05 Thread Harald Welte
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

2005-09-05 Thread Harald Welte
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

2005-09-05 Thread Harald Welte
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

2005-09-04 Thread Harald Welte
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

2005-09-04 Thread Harald Welte
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

2005-09-04 Thread Harald Welte
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

2005-09-04 Thread Harald Welte
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

2005-09-03 Thread Harald Welte
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

2005-09-03 Thread Harald Welte
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()

2005-09-03 Thread Harald Welte
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

2005-09-03 Thread Harald Welte
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()

2005-09-03 Thread Harald Welte
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

2005-09-03 Thread Harald Welte
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

2005-09-03 Thread Harald Welte
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()

2005-09-03 Thread Harald Welte
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

2005-09-03 Thread Harald Welte
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()

2005-09-03 Thread Harald Welte
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

2005-09-03 Thread Harald Welte
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

2005-09-03 Thread Harald Welte
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

2005-08-30 Thread Harald Welte
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

2005-08-30 Thread Harald Welte
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

2005-08-30 Thread Harald Welte
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

2005-08-30 Thread Harald Welte
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

2005-08-26 Thread Harald Welte
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

2005-08-26 Thread Harald Welte
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

2005-08-25 Thread Harald Welte
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

2005-08-25 Thread Harald Welte
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

2005-08-15 Thread Harald Welte
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

2005-08-15 Thread Harald Welte
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

2005-08-01 Thread Harald Welte
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

2005-08-01 Thread Harald Welte
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

2005-07-31 Thread Harald Welte
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

2005-07-31 Thread Harald Welte
[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

2005-07-31 Thread Harald Welte
[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

2005-07-31 Thread Harald Welte
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

2005-07-26 Thread Harald Welte
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

2005-07-26 Thread Harald Welte
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

2005-07-26 Thread Harald Welte
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

2005-07-26 Thread Harald Welte
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

2005-07-26 Thread Harald Welte
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

2005-07-26 Thread Harald Welte
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

2005-07-22 Thread Harald Welte
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

2005-07-22 Thread Harald Welte
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

2005-07-22 Thread Harald Welte
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

2005-07-22 Thread Harald Welte
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

2005-02-19 Thread Harald Welte
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

2005-02-19 Thread Harald Welte
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

2005-01-31 Thread Harald Welte
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

2005-01-31 Thread Harald Welte
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

2001-06-18 Thread Harald Welte

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/



  1   2   >