All of lore.kernel.org
 help / color / mirror / Atom feed
From: Oleksij Rempel <linux@rempel-privat.de>
To: ath9k-devel@lists.ath9k.org
Subject: [ath9k-devel] [PATCH 00/23] ath9k|ath9k_htc: move dups to common-beacon
Date: Fri, 07 Mar 2014 10:55:27 +0100	[thread overview]
Message-ID: <5319978F.6060803@rempel-privat.de> (raw)
In-Reply-To: <20140306184235.GA7788@tuxdriver.com>

Am 06.03.2014 19:42, schrieb John W. Linville:
> On Sun, Mar 02, 2014 at 01:20:11PM +0530, Sujith Manoharan wrote:
>> Oleksij Rempel wrote:
>>> I was thinking about it too, but suddenly i don't have enough time and
>>> experience to do it. Beside, there is no need to write usb layer. It is
>>> clean and separate from other part of the driver. But the HTC/WMI
>>> interface is not completely separate.
>>
>> Sure. It is just another option to consider.
>>
>>> Now about bigger picture. Right now i work only on ath9k<>ath9k_htc
>>> dups. But there are lots of dup code in ath9k itself. For example
>>> *_phy.c, *_initvals.h. Here are some examples:
>>
>> We already have duplicate detection for initvals. It is part of
>> the initvals tool in qca-swiss-army-knife.
> 
> So, where does this leave us?  Should this series be merged?  Or not?

Last response was about initvals, my patch set affect only beacon code.
Since i don't plan to rewrite ath9k_htc from scratch, i would assume it
will be better to continue this periodic clean work.

Sujith, are you agree? :) We need your Ack for this patch set.

-- 
Regards,
Oleksij

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 278 bytes
Desc: OpenPGP digital signature
Url : http://lists.ath9k.org/pipermail/ath9k-devel/attachments/20140307/5cd7dc56/attachment.pgp 

WARNING: multiple messages have this Message-ID (diff)
From: Oleksij Rempel <linux@rempel-privat.de>
To: "John W. Linville" <linville@tuxdriver.com>,
	Sujith Manoharan <sujith@msujith.org>
Cc: linux-wireless@vger.kernel.org,
	"ath9k-devel@lists.ath9k.org" <ath9k-devel@venema.h4ckr.net>
Subject: Re: [PATCH 00/23] ath9k|ath9k_htc: move dups to common-beacon
Date: Fri, 07 Mar 2014 10:55:27 +0100	[thread overview]
Message-ID: <5319978F.6060803@rempel-privat.de> (raw)
In-Reply-To: <20140306184235.GA7788@tuxdriver.com>

[-- Attachment #1: Type: text/plain, Size: 1155 bytes --]

Am 06.03.2014 19:42, schrieb John W. Linville:
> On Sun, Mar 02, 2014 at 01:20:11PM +0530, Sujith Manoharan wrote:
>> Oleksij Rempel wrote:
>>> I was thinking about it too, but suddenly i don't have enough time and
>>> experience to do it. Beside, there is no need to write usb layer. It is
>>> clean and separate from other part of the driver. But the HTC/WMI
>>> interface is not completely separate.
>>
>> Sure. It is just another option to consider.
>>
>>> Now about bigger picture. Right now i work only on ath9k<>ath9k_htc
>>> dups. But there are lots of dup code in ath9k itself. For example
>>> *_phy.c, *_initvals.h. Here are some examples:
>>
>> We already have duplicate detection for initvals. It is part of
>> the initvals tool in qca-swiss-army-knife.
> 
> So, where does this leave us?  Should this series be merged?  Or not?

Last response was about initvals, my patch set affect only beacon code.
Since i don't plan to rewrite ath9k_htc from scratch, i would assume it
will be better to continue this periodic clean work.

Sujith, are you agree? :) We need your Ack for this patch set.

-- 
Regards,
Oleksij


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 278 bytes --]

  reply	other threads:[~2014-03-07  9:55 UTC|newest]

Thread overview: 41+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-03-01 20:15 [PATCH 00/23] ath9k|ath9k_htc: move dups to common-beacon Oleksij Rempel
2014-03-01 20:15 ` [PATCH 01/23] ath9k: move struct ath_beacon_config to common Oleksij Rempel
2014-03-01 20:15 ` [PATCH 02/23] ath9k_htc: use common ath_beacon_config Oleksij Rempel
2014-03-01 20:15 ` [PATCH 03/23] ath9k_htc: move beaconq to struct htc_beacon Oleksij Rempel
2014-03-01 20:15 ` [PATCH 04/23] ath9k_htc: use ath_beacon_conf.enable_beacon Oleksij Rempel
2014-03-01 20:15 ` [PATCH 05/23] ath9k: move sc_flags to ath_common Oleksij Rempel
2014-03-01 20:15 ` [PATCH 06/23] ath9k_htc: use common->op_flags Oleksij Rempel
2014-03-01 20:15 ` [PATCH 07/23] ath9k_htc: add ATH_OP_PRIM_STA_VIF Oleksij Rempel
2014-03-01 20:15 ` [PATCH 08/23] ath9k: remove unused bc_tstamp Oleksij Rempel
2014-03-01 20:15 ` [PATCH 09/23] ath9k_htc: sync beacon slot code with ath9k Oleksij Rempel
2014-03-01 20:15 ` [PATCH 10/23] ath9k: remove unused beacon_qi Oleksij Rempel
2014-03-01 20:15 ` [PATCH 11/23] ath9k|ath9k_htc: move IEEE80211_MS_TO_TU to common Oleksij Rempel
2014-03-01 20:15 ` [PATCH 12/23] ath9k-common: add nexttbtt and intval to ath_beacon_config Oleksij Rempel
2014-03-01 20:15 ` [PATCH 13/23] ath9k: move ath9k_beacon_config_sta to common-beacon Oleksij Rempel
2014-03-01 20:15 ` [PATCH 14/23] ath9k_htc: use ath9k_cmn_beacon_config_sta Oleksij Rempel
2014-03-01 20:15 ` [PATCH 15/23] ath9k: move ath9k_beacon_config_adhoc to common Oleksij Rempel
2014-03-01 20:15 ` [PATCH 16/23] ath9k_htc: add ath9k_htc_beacon_init (but not use it) Oleksij Rempel
2014-03-01 20:16 ` [PATCH 17/23] ath9k_htc: use ath9k_htc_beacon_init in ath9k_htc_beacon_config_ap Oleksij Rempel
2014-03-01 20:16 ` [PATCH 18/23] ath9k_htc: use ath9k_htc_beacon_init in ath9k_htc_beacon_config_adhoc Oleksij Rempel
2014-03-01 20:16 ` [PATCH 19/23] ath9k_htc: use ath9k_cmn_beacon_config_adhoc Oleksij Rempel
2014-03-01 20:16 ` [PATCH 20/23] ath9k: move ath9k_beacon_config_ap common Oleksij Rempel
2014-03-01 20:16 ` [PATCH 21/23] ath9k: remove unused ath9k_get_next_tbtt Oleksij Rempel
2014-03-01 20:16 ` [PATCH 22/23] ath9k_htc: use ath9k_cmn_beacon_config_ap Oleksij Rempel
2014-03-01 20:16 ` [PATCH 23/23] ath9k_htc: move DEFAULT_SWBA_RESPONSE check to ath9k_htc_beacon_init Oleksij Rempel
2014-03-02  2:14 ` [PATCH 00/23] ath9k|ath9k_htc: move dups to common-beacon Sujith Manoharan
2014-03-02  7:27   ` [ath9k-devel] " Oleksij Rempel
2014-03-02  7:27     ` Oleksij Rempel
2014-03-02  7:50     ` [ath9k-devel] " Sujith Manoharan
2014-03-02  7:50       ` Sujith Manoharan
2014-03-06 18:42       ` [ath9k-devel] " John W. Linville
2014-03-06 18:42         ` John W. Linville
2014-03-07  9:55         ` Oleksij Rempel [this message]
2014-03-07  9:55           ` Oleksij Rempel
2014-03-07 10:18           ` [ath9k-devel] " Sujith Manoharan
2014-03-07 10:18             ` Sujith Manoharan
2014-03-10 15:08             ` [ath9k-devel] " Oleksij Rempel
2014-03-10 15:08               ` Oleksij Rempel
2014-03-14 19:22               ` [ath9k-devel] " John W. Linville
2014-03-14 19:22                 ` John W. Linville
2014-03-15  7:51                 ` [ath9k-devel] " Oleksij Rempel
2014-03-15  7:51                   ` Oleksij Rempel

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5319978F.6060803@rempel-privat.de \
    --to=linux@rempel-privat.de \
    --cc=ath9k-devel@lists.ath9k.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.