From: "Guy, Wey-Yi" <wey-yi.w.guy@intel.com>
To: Stanislaw Gruszka <sgruszka@redhat.com>
Cc: Intel Linux Wireless <ilw@linux.intel.com>,
"linux-wireless@vger.kernel.org" <linux-wireless@vger.kernel.org>
Subject: Re: [PATCH 2/3] iwlagn: simplify iwlagn_tx_skb
Date: Fri, 12 Nov 2010 09:51:02 -0800 [thread overview]
Message-ID: <1289584262.1935.0.camel@wwguy-ubuntu> (raw)
In-Reply-To: <20101112164620.GA10877@redhat.com>
On Fri, 2010-11-12 at 08:46 -0800, Stanislaw Gruszka wrote:
> Hi,
>
> On Fri, Nov 12, 2010 at 07:52:05AM -0800, Guy, Wey-Yi wrote:
> > On Thu, 2010-11-11 at 23:47 -0800, Stanislaw Gruszka wrote:
> > > We can simplify length calculation in iwlagn_tx_skb, that function
> > > is enough complex, without fuzz it more than necessary.
> > >
> > > Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
> > > ---
> > > drivers/net/wireless/iwlwifi/iwl-agn-tx.c | 33 ++++++++++------------------
> > > 1 files changed, 12 insertions(+), 21 deletions(-)
> > >
> > > diff --git a/drivers/net/wireless/iwlwifi/iwl-agn-tx.c b/drivers/net/wireless/iwlwifi/iwl-agn-tx.c
> > > index 2b078a9..1205cec 100644
> > > --- a/drivers/net/wireless/iwlwifi/iwl-agn-tx.c
> > > +++ b/drivers/net/wireless/iwlwifi/iwl-agn-tx.c
> > > @@ -522,7 +522,7 @@ int iwlagn_tx_skb(struct iwl_priv *priv, struct sk_buff *skb)
> > > dma_addr_t phys_addr;
> > > dma_addr_t txcmd_phys;
> > > dma_addr_t scratch_phys;
> > > - u16 len, len_org, firstlen, secondlen;
> > > + u16 len, firstlen, secondlen;
> > > u16 seq_number = 0;
> > > __le16 fc;
> > > u8 hdr_len;
> > > @@ -687,30 +687,23 @@ int iwlagn_tx_skb(struct iwl_priv *priv, struct sk_buff *skb)
> > > */
> > > len = sizeof(struct iwl_tx_cmd) +
> > > sizeof(struct iwl_cmd_header) + hdr_len;
> > > -
> > > - len_org = len;
> > > - firstlen = len = (len + 3) & ~3;
> > > -
> > > - if (len_org != len)
> > > - len_org = 1;
> > > - else
> > > - len_org = 0;
> > > + firstlen = (len + 3) & ~3;
> > >
> > > /* Tell NIC about any 2-byte padding after MAC header */
> > > - if (len_org)
> > > + if (firstlen != len)
> > > tx_cmd->tx_flags |= TX_CMD_FLG_MH_PAD_MSK;
> > >
> > > /* Physical address of this Tx command's header (not MAC header!),
> > > * within command buffer array. */
> > > txcmd_phys = pci_map_single(priv->pci_dev,
> > > - &out_cmd->hdr, len,
> > > + &out_cmd->hdr, firstlen,
> > > PCI_DMA_BIDIRECTIONAL);
> > > dma_unmap_addr_set(out_meta, mapping, txcmd_phys);
> > > - dma_unmap_len_set(out_meta, len, len);
> > > + dma_unmap_len_set(out_meta, len, firstlen);
> >
> > it is possible len != firstlen, right?
>
> Yes it is, firstlen is aligned up to 4 byes value, txcmd_phys dma map
> size is firstlen and in consequence I use it every time with txcmd_phys.
>
> > > /* Add buffer containing Tx command and MAC(!) header to TFD's
> > > * first entry */
> > > priv->cfg->ops->lib->txq_attach_buf_to_tfd(priv, txq,
> > > - txcmd_phys, len, 1, 0);
> > > + txcmd_phys, firstlen, 1, 0);
> > >
> > > if (!ieee80211_has_morefrags(hdr->frame_control)) {
> > > txq->need_update = 1;
> > > @@ -721,23 +714,21 @@ int iwlagn_tx_skb(struct iwl_priv *priv, struct sk_buff *skb)
> > >
> > > /* Set up TFD's 2nd entry to point directly to remainder of skb,
> > > * if any (802.11 null frames have no payload). */
> > > - secondlen = len = skb->len - hdr_len;
> > > - if (len) {
> > > + secondlen = skb->len - hdr_len;
> > > + if (secondlen > 0) {
> > > phys_addr = pci_map_single(priv->pci_dev, skb->data + hdr_len,
> > > - len, PCI_DMA_TODEVICE);
> > > + secondlen, PCI_DMA_TODEVICE);
> > > priv->cfg->ops->lib->txq_attach_buf_to_tfd(priv, txq,
> > > - phys_addr, len,
> > > + phys_addr, secondlen,
> > > 0, 0);
> > > }
> > >
> > > scratch_phys = txcmd_phys + sizeof(struct iwl_cmd_header) +
> > > offsetof(struct iwl_tx_cmd, scratch);
> > >
> > > - len = sizeof(struct iwl_tx_cmd) +
> > > - sizeof(struct iwl_cmd_header) + hdr_len;
> > > /* take back ownership of DMA buffer to enable update */
> > > pci_dma_sync_single_for_cpu(priv->pci_dev, txcmd_phys,
> > > - len, PCI_DMA_BIDIRECTIONAL);
> > > + firstlen, PCI_DMA_BIDIRECTIONAL);
> >
> > same here, "firstlen" not necessary equal "len"
>
> I guess its enough to sync just "len" but I prefer to use the
> size we used to map dma.
>
ok, it make sense
Acked-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
next prev parent reply other threads:[~2010-11-12 17:51 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-11-12 7:47 [PATCH 1/3] iwl3945: remove unused len_org variable Stanislaw Gruszka
2010-11-12 7:47 ` [PATCH 2/3] iwlagn: simplify iwlagn_tx_skb Stanislaw Gruszka
2010-11-12 15:52 ` Guy, Wey-Yi
2010-11-12 16:46 ` Stanislaw Gruszka
2010-11-12 17:51 ` Guy, Wey-Yi [this message]
2010-11-12 7:47 ` [PATCH 3/3] iwlwifi: kill elapsed_jiffies Stanislaw Gruszka
2010-11-12 15:53 ` Guy, Wey-Yi
2010-11-12 8:19 ` [PATCH 1/3] iwl3945: remove unused len_org variable Sedat Dilek
2010-11-12 8:56 ` Stanislaw Gruszka
2010-11-12 15:32 ` Guy, Wey-Yi
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=1289584262.1935.0.camel@wwguy-ubuntu \
--to=wey-yi.w.guy@intel.com \
--cc=ilw@linux.intel.com \
--cc=linux-wireless@vger.kernel.org \
--cc=sgruszka@redhat.com \
/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.