From yzsumishu at happy.bbexcite.jp  Tue Apr 12 04:23:37 2016
From: yzsumishu at happy.bbexcite.jp (yzsumishu at happy.bbexcite.jp)
Date: Tue, 12 Apr 2016 20:23:37 +0900
Subject: 4.9GHz activation on ath6kl
Message-ID: <20160412112337.32245.64874.yzsumishu@mose-webmail-front1504.hop.2iij.net>


Hello everyone

Does anybody work on an activation of 4.9GHz compliant with 802.11j on ath6kl driver ?
I want to communicate directly how to do that and what you have modification points.

Please let me know if you know.

YZ




From derosier at gmail.com  Fri Apr 15 17:18:52 2016
From: derosier at gmail.com (Steve deRosier)
Date: Fri, 15 Apr 2016 17:18:52 -0700
Subject: [PATCH] ath6kl: fix missing uart debug pin for 6004 HW 3.0
Message-ID: <1460765932-12660-1-git-send-email-steve.derosier@lairdtech.com>

For some reason, the 6004 HW 3.0 definition was missing the value for the
uarttx_pin (used for firmware debug). This corrects this situation.

Signed-off-by: Steve deRosier <steve.derosier at lairdtech.com>
---
 drivers/net/wireless/ath/ath6kl/init.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/net/wireless/ath/ath6kl/init.c b/drivers/net/wireless/ath/ath6kl/init.c
index da557dc..3daeb27 100644
--- a/drivers/net/wireless/ath/ath6kl/init.c
+++ b/drivers/net/wireless/ath/ath6kl/init.c
@@ -173,6 +173,7 @@ static const struct ath6kl_hw hw_list[] = {
 		.reserved_ram_size		= 7168,
 		.board_addr			= 0x436400,
 		.testscript_addr		= 0,
+		.uarttx_pin			= 11,
 		.flags				= 0,
 
 		.fw = {
-- 
1.9.1



From derosier at gmail.com  Fri Apr 15 17:19:46 2016
From: derosier at gmail.com (Steve deRosier)
Date: Fri, 15 Apr 2016 17:19:46 -0700
Subject: [PATCH] ath6kl: Add ability to set debug uart baud rate
Message-ID: <1460765986-12698-1-git-send-email-steve.derosier@lairdtech.com>

It's useful to permit the customization of the debug uart baud rate. Enable
this and send down the value to the chip if we're enabling debug.

Signed-off-by: Steve deRosier <steve.derosier at lairdtech.com>
---
 drivers/net/wireless/ath/ath6kl/core.c | 3 +++
 drivers/net/wireless/ath/ath6kl/core.h | 1 +
 drivers/net/wireless/ath/ath6kl/init.c | 8 ++++++++
 3 files changed, 12 insertions(+)

diff --git a/drivers/net/wireless/ath/ath6kl/core.c b/drivers/net/wireless/ath/ath6kl/core.c
index 4ec02ce..ebb9f16 100644
--- a/drivers/net/wireless/ath/ath6kl/core.c
+++ b/drivers/net/wireless/ath/ath6kl/core.c
@@ -31,6 +31,7 @@ unsigned int debug_mask;
 static unsigned int suspend_mode;
 static unsigned int wow_mode;
 static unsigned int uart_debug;
+static unsigned int uart_rate = 115200;
 static unsigned int ath6kl_p2p;
 static unsigned int testmode;
 static unsigned int recovery_enable;
@@ -40,6 +41,7 @@ module_param(debug_mask, uint, 0644);
 module_param(suspend_mode, uint, 0644);
 module_param(wow_mode, uint, 0644);
 module_param(uart_debug, uint, 0644);
+module_param(uart_rate, uint, 0644);
 module_param(ath6kl_p2p, uint, 0644);
 module_param(testmode, uint, 0644);
 module_param(recovery_enable, uint, 0644);
@@ -180,6 +182,7 @@ int ath6kl_core_init(struct ath6kl *ar, enum ath6kl_htc_type htc_type)
 
 	if (uart_debug)
 		ar->conf_flags |= ATH6KL_CONF_UART_DEBUG;
+	ar->hw.uarttx_rate = uart_rate;
 
 	set_bit(FIRST_BOOT, &ar->flag);
 
diff --git a/drivers/net/wireless/ath/ath6kl/core.h b/drivers/net/wireless/ath/ath6kl/core.h
index 5f3acfe..80ce54d 100644
--- a/drivers/net/wireless/ath/ath6kl/core.h
+++ b/drivers/net/wireless/ath/ath6kl/core.h
@@ -781,6 +781,7 @@ struct ath6kl {
 		u32 board_addr;
 		u32 refclk_hz;
 		u32 uarttx_pin;
+		u32 uarttx_rate;
 		u32 testscript_addr;
 		u8 tx_ant;
 		u8 rx_ant;
diff --git a/drivers/net/wireless/ath/ath6kl/init.c b/drivers/net/wireless/ath/ath6kl/init.c
index 3daeb27..58fb227 100644
--- a/drivers/net/wireless/ath/ath6kl/init.c
+++ b/drivers/net/wireless/ath/ath6kl/init.c
@@ -651,6 +651,14 @@ int ath6kl_configure_target(struct ath6kl *ar)
 	if (status)
 		return status;
 
+	/* Only set the baud rate if we're actually doing debug */
+	if (ar->conf_flags & ATH6KL_CONF_UART_DEBUG) {
+		status = ath6kl_bmi_write_hi32(ar, hi_desired_baud_rate,
+					       ar->hw.uarttx_rate);
+		if (status)
+			return status;
+	}
+
 	/* Configure target refclk_hz */
 	if (ar->hw.refclk_hz != 0) {
 		status = ath6kl_bmi_write_hi32(ar, hi_refclk_hz,
-- 
1.9.1



From julian.calaby at gmail.com  Sun Apr 17 17:07:46 2016
From: julian.calaby at gmail.com (Julian Calaby)
Date: Mon, 18 Apr 2016 10:07:46 +1000
Subject: [PATCH] ath6kl: Add ability to set debug uart baud rate
In-Reply-To: <1460765986-12698-1-git-send-email-steve.derosier@lairdtech.com>
References: <1460765986-12698-1-git-send-email-steve.derosier@lairdtech.com>
Message-ID: <CAGRGNgV_W6uJF5DR43XdqvHPgBha1AfALYXcX4Lj=4jkO8TftQ@mail.gmail.com>

Hi Steve,

On Sat, Apr 16, 2016 at 10:19 AM, Steve deRosier <derosier at gmail.com> wrote:
> It's useful to permit the customization of the debug uart baud rate. Enable
> this and send down the value to the chip if we're enabling debug.
>
> Signed-off-by: Steve deRosier <steve.derosier at lairdtech.com>

This looks like it's using standard serial rates. Does it accept
non-standard rates? If not, should this be checked before being passed
to the hardware?

Thanks,

-- 
Julian Calaby

Email: julian.calaby at gmail.com
Profile: http://www.google.com/profiles/julian.calaby/


From derosier at gmail.com  Mon Apr 18 11:12:41 2016
From: derosier at gmail.com (Steve deRosier)
Date: Mon, 18 Apr 2016 11:12:41 -0700
Subject: [PATCH] ath6kl: Add ability to set debug uart baud rate
In-Reply-To: <CAGRGNgV_W6uJF5DR43XdqvHPgBha1AfALYXcX4Lj=4jkO8TftQ@mail.gmail.com>
References: <1460765986-12698-1-git-send-email-steve.derosier@lairdtech.com>
 <CAGRGNgV_W6uJF5DR43XdqvHPgBha1AfALYXcX4Lj=4jkO8TftQ@mail.gmail.com>
Message-ID: <CALupW3CsuSGy=xBw-Wj5FfD+ALKBGi9xvi=Z8+YTdL9mGku5HQ@mail.gmail.com>

Hi Julian,

Thanks for looking at the patch.

On Sun, Apr 17, 2016 at 5:07 PM, Julian Calaby <julian.calaby at gmail.com> wrote:
> Hi Steve,
>
> This looks like it's using standard serial rates. Does it accept
> non-standard rates? If not, should this be checked before being passed
> to the hardware?
>

It should use standard serial rates, and obviously I defaulted it to a
sensible one. However, there's nothing that prevents you from using
odd and arbitrary rates in the firmware and it should just suck it in
and use it. In other words, the firmware will happily try to set 9507
baud if you tell it to.

This is specifically for debugging and working with the firmware and
IMHO, if you are using this feature and feel a need to set it to
something weird, I think the user should be allowed to. If you know
enough to be able to shoot yourself in the foot with this, then you
should know enough of what you should or shouldn't do and should be
allowed to. It's a debugging tool only and I don't see any reason to
waste lines in the driver to validate this input.

That's my perspective on the issue, but I recognize other opinions may
differ. Or you may know of a specific chip where it does matter (the
6003s and 6004s I'm using don't seem to care). If you or Kalle insist
on it, I'll be happy to add in some value checking for this parameter.
It just doesn't seem worth-while to me.

- Steve


From julian.calaby at gmail.com  Mon Apr 18 17:27:53 2016
From: julian.calaby at gmail.com (Julian Calaby)
Date: Tue, 19 Apr 2016 10:27:53 +1000
Subject: [PATCH] ath6kl: Add ability to set debug uart baud rate
In-Reply-To: <CALupW3CsuSGy=xBw-Wj5FfD+ALKBGi9xvi=Z8+YTdL9mGku5HQ@mail.gmail.com>
References: <1460765986-12698-1-git-send-email-steve.derosier@lairdtech.com>
 <CAGRGNgV_W6uJF5DR43XdqvHPgBha1AfALYXcX4Lj=4jkO8TftQ@mail.gmail.com>
 <CALupW3CsuSGy=xBw-Wj5FfD+ALKBGi9xvi=Z8+YTdL9mGku5HQ@mail.gmail.com>
Message-ID: <CAGRGNgVM8cVyKaNi0PEjqPmamPp3+YAXbVMu+Hifi6R0Le-ekg@mail.gmail.com>

Hi Steve,

On Tue, Apr 19, 2016 at 4:12 AM, Steve deRosier <derosier at gmail.com> wrote:
> Hi Julian,
>
> Thanks for looking at the patch.
>
> On Sun, Apr 17, 2016 at 5:07 PM, Julian Calaby <julian.calaby at gmail.com> wrote:
>> Hi Steve,
>>
>> This looks like it's using standard serial rates. Does it accept
>> non-standard rates? If not, should this be checked before being passed
>> to the hardware?
>>
>
> It should use standard serial rates, and obviously I defaulted it to a
> sensible one. However, there's nothing that prevents you from using
> odd and arbitrary rates in the firmware and it should just suck it in
> and use it. In other words, the firmware will happily try to set 9507
> baud if you tell it to.
>
> This is specifically for debugging and working with the firmware and
> IMHO, if you are using this feature and feel a need to set it to
> something weird, I think the user should be allowed to. If you know
> enough to be able to shoot yourself in the foot with this, then you
> should know enough of what you should or shouldn't do and should be
> allowed to. It's a debugging tool only and I don't see any reason to
> waste lines in the driver to validate this input.

I'm of the opinion that one should never underestimate the ability of
people to attempt to shoot themselves in the foot. However this is
only a debugging interface so you do make a good point.

I guess I'm worried that some idiot is going to set it to 2 baud or 2
billion baud for some dumb reason then come complaining to us when
their wireless card crashes or locks up or something.

Maybe we can just sweep this all under the carpet by putting all the
debug uart stuff behind some nice #ifdef.

> That's my perspective on the issue, but I recognize other opinions may
> differ. Or you may know of a specific chip where it does matter (the
> 6003s and 6004s I'm using don't seem to care). If you or Kalle insist
> on it, I'll be happy to add in some value checking for this parameter.
> It just doesn't seem worth-while to me.

Thanks,

-- 
Julian Calaby

Email: julian.calaby at gmail.com
Profile: http://www.google.com/profiles/julian.calaby/


From derosier at gmail.com  Mon Apr 18 20:06:53 2016
From: derosier at gmail.com (Steve deRosier)
Date: Mon, 18 Apr 2016 23:06:53 -0400
Subject: [PATCH] ath6kl: Add ability to set debug uart baud rate
In-Reply-To: <CAGRGNgVM8cVyKaNi0PEjqPmamPp3+YAXbVMu+Hifi6R0Le-ekg@mail.gmail.com>
References: <1460765986-12698-1-git-send-email-steve.derosier@lairdtech.com>
 <CAGRGNgV_W6uJF5DR43XdqvHPgBha1AfALYXcX4Lj=4jkO8TftQ@mail.gmail.com>
 <CALupW3CsuSGy=xBw-Wj5FfD+ALKBGi9xvi=Z8+YTdL9mGku5HQ@mail.gmail.com>
 <CAGRGNgVM8cVyKaNi0PEjqPmamPp3+YAXbVMu+Hifi6R0Le-ekg@mail.gmail.com>
Message-ID: <CALupW3BtioZsX9dyBGEbtQrMh4O-BjA-0zG0MG1OwEH0YLbKKQ@mail.gmail.com>

Hi Julian,

First off, let me say I do appreciate your comments and I do
understand your perspective. I also generally prefer not to let users
shoot-themselves in the foot if it's avoidable.

In this case, however, I don't happen to agree with you. For one
specific reason: I don't want to say what baud rates are "safe"
because I think that's even more dangerous than not checking - because
we have no way of actually knowing what is or isn't for a particular
chip.

Oddly enough I thought this all out before I ever sent the patch up.

>
> I'm of the opinion that one should never underestimate the ability of
> people to attempt to shoot themselves in the foot. However this is
> only a debugging interface so you do make a good point.
>
> I guess I'm worried that some idiot is going to set it to 2 baud or 2
> billion baud for some dumb reason then come complaining to us when
> their wireless card crashes or locks up or something.
>
> Maybe we can just sweep this all under the carpet by putting all the
> debug uart stuff behind some nice #ifdef.

Well, first off the debugging stuff was never under some #ifdef. So,
we should make it even more complicated and add an #ifdef and yet
another kconfig option?

AFAIK, the firmware would be perfectly happy with 2 baud. I'm not in
my lab to try it right now, but it might well be (though your
throughput would be crap). Nor do I know the upper limit of the
register the firmware uses.

My firmware guy wanted 115200, and I could've hard-coded it to that
value, but I figured a bit of flexibility was warranted and would be
more upstreamable. I don't know every single valid or invalid value
for every ar6xxx chip. If we have it check for the value, then we have
some obligation to know the values we let in are valid for either all
or at least the chip the user is using. I don't know what was invalid
for many species of 6002. Or even all of the 6003 and 6004s and I've
been working with both the firmware and driver for these chips for 3
years now. What might be valid on the yet to be imagined 6009?

If we check, we are saying, "these are safe values and we want you to use them".

99.999% of users don't have access to this pin without a soldering
iron. I think someone who is going to tack a wire to their 6k chip is
entitled to set even stupid values if they think they have a reason.

Again, simply my perspective.

On a compromise: do you have a specific list of baud rates you'd like
to support and you know are valid across a wide swath of ath6kl chips?
Every rate I've tried, normal or weird, works fine. Granted, I haven't
tried anything slower than 9600, nor have I bothered checking the
clock error on the weird rates. If you have said list, I'd be happy to
code it up. But I think that specifically checking for rates is the
same as saying "this rate is supported" and I don't know that, so I
hope you do know what ones are valid.

Maybe you agree with my line of thinking (now that you know what it
is) or maybe not. That's OK. ;)

Thanks,
- Steve


From julian.calaby at gmail.com  Mon Apr 18 21:01:13 2016
From: julian.calaby at gmail.com (Julian Calaby)
Date: Tue, 19 Apr 2016 14:01:13 +1000
Subject: [PATCH] ath6kl: Add ability to set debug uart baud rate
In-Reply-To: <CALupW3BtioZsX9dyBGEbtQrMh4O-BjA-0zG0MG1OwEH0YLbKKQ@mail.gmail.com>
References: <1460765986-12698-1-git-send-email-steve.derosier@lairdtech.com>
 <CAGRGNgV_W6uJF5DR43XdqvHPgBha1AfALYXcX4Lj=4jkO8TftQ@mail.gmail.com>
 <CALupW3CsuSGy=xBw-Wj5FfD+ALKBGi9xvi=Z8+YTdL9mGku5HQ@mail.gmail.com>
 <CAGRGNgVM8cVyKaNi0PEjqPmamPp3+YAXbVMu+Hifi6R0Le-ekg@mail.gmail.com>
 <CALupW3BtioZsX9dyBGEbtQrMh4O-BjA-0zG0MG1OwEH0YLbKKQ@mail.gmail.com>
Message-ID: <CAGRGNgUQNnUb3Hnzgg=LF3c+aoZ3jgrK8cL5jOSxETfgiXTijQ@mail.gmail.com>

Hi Steve,

On Tue, Apr 19, 2016 at 1:06 PM, Steve deRosier <derosier at gmail.com> wrote:
> Hi Julian,
>
> First off, let me say I do appreciate your comments and I do
> understand your perspective. I also generally prefer not to let users
> shoot-themselves in the foot if it's avoidable.
>
> In this case, however, I don't happen to agree with you. For one
> specific reason: I don't want to say what baud rates are "safe"
> because I think that's even more dangerous than not checking - because
> we have no way of actually knowing what is or isn't for a particular
> chip.
>
> Oddly enough I thought this all out before I ever sent the patch up.

I questioned this change because it looked like you hadn't. You didn't
mention this in the patch description and the change itself didn't
imply this to me.

>> I'm of the opinion that one should never underestimate the ability of
>> people to attempt to shoot themselves in the foot. However this is
>> only a debugging interface so you do make a good point.
>>
>> I guess I'm worried that some idiot is going to set it to 2 baud or 2
>> billion baud for some dumb reason then come complaining to us when
>> their wireless card crashes or locks up or something.
>>
>> Maybe we can just sweep this all under the carpet by putting all the
>> debug uart stuff behind some nice #ifdef.
>
> Well, first off the debugging stuff was never under some #ifdef. So,
> we should make it even more complicated and add an #ifdef and yet
> another kconfig option?

Having debug options under an #ifdef is pretty common.

> AFAIK, the firmware would be perfectly happy with 2 baud. I'm not in
> my lab to try it right now, but it might well be (though your
> throughput would be crap). Nor do I know the upper limit of the
> register the firmware uses.

This is kinda what I was looking for when I asked the question in the
first place. You don't know for certain which rates are safe and which
aren't and you don't know the limits of the hardware / firmware.

> My firmware guy wanted 115200, and I could've hard-coded it to that
> value, but I figured a bit of flexibility was warranted and would be
> more upstreamable. I don't know every single valid or invalid value
> for every ar6xxx chip. If we have it check for the value, then we have
> some obligation to know the values we let in are valid for either all
> or at least the chip the user is using. I don't know what was invalid
> for many species of 6002. Or even all of the 6003 and 6004s and I've
> been working with both the firmware and driver for these chips for 3
> years now. What might be valid on the yet to be imagined 6009?

To be honest, I wouldn't have questioned this if you'd hardcoded it to
115200. Practically all serial hardware these days is capable of that
rate, it's standard and it's sensible.

> If we check, we are saying, "these are safe values and we want you to use them".
>
> 99.999% of users don't have access to this pin without a soldering
> iron. I think someone who is going to tack a wire to their 6k chip is
> entitled to set even stupid values if they think they have a reason.

True, but the other side of this is that 99.999% of the people who
will be using this will be using a standard baud rate. I personally
cannot think of any sensible use case for a rate other than 115200
unless Qualcomm themselves produce hardware that interfaces with this
and isn't capable of that rate. (And anyone doing firmware debugging
will also be doing kernel development or be next to someone who is, so
an #ifdef shouldn't be an issue.)

> Again, simply my perspective.
>
> On a compromise: do you have a specific list of baud rates you'd like
> to support and you know are valid across a wide swath of ath6kl chips?
> Every rate I've tried, normal or weird, works fine. Granted, I haven't
> tried anything slower than 9600, nor have I bothered checking the
> clock error on the weird rates. If you have said list, I'd be happy to
> code it up. But I think that specifically checking for rates is the
> same as saying "this rate is supported" and I don't know that, so I
> hope you do know what ones are valid.

I don't know which ones are valid. 9600 to 115200 inclusive sounds
like a sensible range to me. I was hoping that Kalle or someone knew
or could talk to the hardware / firmware people (assuming they're
still available. ath6k is obsolete IIRC.) and ask them.

> Maybe you agree with my line of thinking (now that you know what it
> is) or maybe not. That's OK. ;)

I see your points. I agree with most of them. I don't agree with your
logic that it should be unrestricted however.

I consider this matter closed unless you decide to change the patch or
someone else has comments. I don't decide if this is to be merged or
not, so I'll leave this up to them.

Thanks,

-- 
Julian Calaby

Email: julian.calaby at gmail.com
Profile: http://www.google.com/profiles/julian.calaby/


From kvalo at qca.qualcomm.com  Tue Apr 19 06:00:54 2016
From: kvalo at qca.qualcomm.com (Valo, Kalle)
Date: Tue, 19 Apr 2016 13:00:54 +0000
Subject: [PATCH] ath6kl: Add ability to set debug uart baud rate
In-Reply-To: <CALupW3CsuSGy=xBw-Wj5FfD+ALKBGi9xvi=Z8+YTdL9mGku5HQ@mail.gmail.com>	(Steve
 deRosier's message of "Mon, 18 Apr 2016 11:12:41 -0700")
References: <1460765986-12698-1-git-send-email-steve.derosier@lairdtech.com>
 <CAGRGNgV_W6uJF5DR43XdqvHPgBha1AfALYXcX4Lj=4jkO8TftQ@mail.gmail.com>
 <CALupW3CsuSGy=xBw-Wj5FfD+ALKBGi9xvi=Z8+YTdL9mGku5HQ@mail.gmail.com>
Message-ID: <87lh493g8r.fsf@qca.qualcomm.com>

Steve deRosier <derosier at gmail.com> writes:

> On Sun, Apr 17, 2016 at 5:07 PM, Julian Calaby <julian.calaby at gmail.com> wrote:
>> Hi Steve,
>>
>> This looks like it's using standard serial rates. Does it accept
>> non-standard rates? If not, should this be checked before being passed
>> to the hardware?
>>
>
> It should use standard serial rates, and obviously I defaulted it to a
> sensible one. However, there's nothing that prevents you from using
> odd and arbitrary rates in the firmware and it should just suck it in
> and use it. In other words, the firmware will happily try to set 9507
> baud if you tell it to.
>
> This is specifically for debugging and working with the firmware and
> IMHO, if you are using this feature and feel a need to set it to
> something weird, I think the user should be allowed to. If you know
> enough to be able to shoot yourself in the foot with this, then you
> should know enough of what you should or shouldn't do and should be
> allowed to. It's a debugging tool only and I don't see any reason to
> waste lines in the driver to validate this input.

I think likewise, normal users shouldn't touch this setting at all.

-- 
Kalle Valo

From kvalo at qca.qualcomm.com  Wed Apr 27 05:54:37 2016
From: kvalo at qca.qualcomm.com (Valo, Kalle)
Date: Wed, 27 Apr 2016 12:54:37 +0000
Subject: [PATCH] ath6kl: fix missing uart debug pin for 6004 HW 3.0
In-Reply-To: <1460765932-12660-1-git-send-email-steve.derosier@lairdtech.com>
 (Steve deRosier's message of "Fri, 15 Apr 2016 17:18:52 -0700")
References: <1460765932-12660-1-git-send-email-steve.derosier@lairdtech.com>
Message-ID: <87eg9rw6sy.fsf@kamboji.qca.qualcomm.com>

Steve deRosier <derosier at gmail.com> writes:

> For some reason, the 6004 HW 3.0 definition was missing the value for the
> uarttx_pin (used for firmware debug). This corrects this situation.
>
> Signed-off-by: Steve deRosier <steve.derosier at lairdtech.com>

Applied, thanks.

-- 
Kalle Valo

From kvalo at codeaurora.org  Wed Apr 27 05:55:04 2016
From: kvalo at codeaurora.org (Kalle Valo)
Date: Wed, 27 Apr 2016 15:55:04 +0300
Subject: [PATCH] ath6kl: Add ability to set debug uart baud rate
In-Reply-To: <1460765986-12698-1-git-send-email-steve.derosier@lairdtech.com>
 (Steve deRosier's message of "Fri, 15 Apr 2016 17:19:46 -0700")
References: <1460765986-12698-1-git-send-email-steve.derosier@lairdtech.com>
Message-ID: <87a8kfw6s7.fsf@kamboji.qca.qualcomm.com>

Steve deRosier <derosier at gmail.com> writes:

> It's useful to permit the customization of the debug uart baud rate. Enable
> this and send down the value to the chip if we're enabling debug.
>
> Signed-off-by: Steve deRosier <steve.derosier at lairdtech.com>

Applied, thanks.

-- 
Kalle Valo


