* [PATCH for 3.19] rtlwifi: rtl8192ce: Set fw_ready flag
From: Larry Finger @ 2014-12-10 20:38 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, Larry Finger, netdev, Stable
The setting of this flag was missed in previous modifications.
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Cc: Stable <stable@vger.kernel.org>
---
drivers/net/wireless/rtlwifi/rtl8192ce/hw.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/net/wireless/rtlwifi/rtl8192ce/hw.c b/drivers/net/wireless/rtlwifi/rtl8192ce/hw.c
index eecb79f..1b73158 100644
--- a/drivers/net/wireless/rtlwifi/rtl8192ce/hw.c
+++ b/drivers/net/wireless/rtlwifi/rtl8192ce/hw.c
@@ -959,6 +959,7 @@ int rtl92ce_hw_init(struct ieee80211_hw *hw)
local_save_flags(flags);
local_irq_enable();
+ rtlhal->fw_ready = false;
rtlpriv->intf_ops->disable_aspm(hw);
rtstatus = _rtl92ce_init_mac(hw);
if (!rtstatus) {
@@ -975,6 +976,7 @@ int rtl92ce_hw_init(struct ieee80211_hw *hw)
goto exit;
}
+ rtlhal->fw_ready = true;
rtlhal->last_hmeboxnum = 0;
rtl92c_phy_mac_config(hw);
/* because last function modify RCR, so we update
--
2.1.2
^ permalink raw reply related
* Re: [PATCH net v7 3/7] cxgb4/cxgb4i: set the max. pdu length in firmware
From: James Bottomley @ 2014-12-10 20:41 UTC (permalink / raw)
To: David Miller; +Cc: kxie, linux-scsi, netdev, hariprasad, anish, hch, michaelc
In-Reply-To: <20141210.153159.617405179156473446.davem@davemloft.net>
On Wed, 2014-12-10 at 15:31 -0500, David Miller wrote:
> From: Karen Xie <kxie@chelsio.com>
> Date: Wed, 10 Dec 2014 12:24:09 -0800
>
> > [PATCH net v7 3/7] cxgb4/cxgb4i: set the max. pdu length in firmware.
>
> Please listen to the feedback you have been given.
>
> Again, you should not duplicate the Subject line in your message
> body, that makes more work for the people integrating your patches
> as we have to remove all of these things by hand.
While we're on the subject of making life easier for maintainers, could
I put in a plea for threading your patch set? It really does make it
easier to find and apply all the patches, especially on a high traffic
list where they otherwise get interspersed with other messages. If you
don't use git-send-email, which threads automatically, you can thread
manually by just making all the other patches a reply to your [PATCH
0/N],
James
^ permalink raw reply
* Re: [PATCH net v7 3/7] cxgb4/cxgb4i: set the max. pdu length in firmware
From: David Miller @ 2014-12-10 20:44 UTC (permalink / raw)
To: James.Bottomley
Cc: kxie, linux-scsi, netdev, hariprasad, anish, hch, michaelc
In-Reply-To: <1418244089.8310.15.camel@HansenPartnership.com>
From: James Bottomley <James.Bottomley@HansenPartnership.com>
Date: Wed, 10 Dec 2014 23:41:29 +0300
> On Wed, 2014-12-10 at 15:31 -0500, David Miller wrote:
>> From: Karen Xie <kxie@chelsio.com>
>> Date: Wed, 10 Dec 2014 12:24:09 -0800
>>
>> > [PATCH net v7 3/7] cxgb4/cxgb4i: set the max. pdu length in firmware.
>>
>> Please listen to the feedback you have been given.
>>
>> Again, you should not duplicate the Subject line in your message
>> body, that makes more work for the people integrating your patches
>> as we have to remove all of these things by hand.
>
> While we're on the subject of making life easier for maintainers, could
> I put in a plea for threading your patch set? It really does make it
> easier to find and apply all the patches, especially on a high traffic
> list where they otherwise get interspersed with other messages.
With patchwork I never need to even think about this issue.
^ permalink raw reply
* errors in alignment changes..
From: David Miller @ 2014-12-10 20:52 UTC (permalink / raw)
To: mitsuhiro.kimura.kc; +Cc: netdev
I just re-reviewed this change:
commit 4d6a949c62f123569fb355b6ec7f314b76f93735
Author: Mitsuhiro Kimura <mitsuhiro.kimura.kc@renesas.com>
Date: Thu Nov 27 20:34:00 2014 +0900
sh_eth: Fix skb alloc size and alignment adjust rule.
and it has serious problems. Well, actually the code has
always been broken in this area.
+ /* The size of the buffer is a multiple of 16 bytes. */
+ rxdesc->buffer_length = ALIGN(mdp->rx_buf_sz, 16);
+ dma_map_single(&ndev->dev, skb->data, rxdesc->buffer_length,
+ DMA_FROM_DEVICE);
rxdesc->addr = virt_to_phys(PTR_ALIGN(skb->data, 4));
rxdesc->status = cpu_to_edmac(mdp, RD_RACT | RD_RFP);
It doesn't make any sense to call dma_map_single() if you aren't
even going to use the return value. The DMA mapping created is
the whole point of calling this function.
And then later we pass:
dma_sync_single_for_cpu(&ndev->dev, rxdesc->addr,
- mdp->rx_buf_sz,
+ ALIGN(mdp->rx_buf_sz, 16),
DMA_FROM_DEVICE);
rxdesc->addr as the "DMA address", but that must be the return value
from dma_map_single() not what you've actually stored there which is
virt_to_phys() run on the skb->data.
This code must be fixed to:
1) Put the return value from dma_map_single() into a local variable,
and check for mapping errors.
2) On success put that return value into rxdesc->addr
^ permalink raw reply
* Re: linux-next: build failure after merge of the net-next tree
From: David Miller @ 2014-12-10 20:52 UTC (permalink / raw)
To: sfr; +Cc: netdev, linux-next, linux-kernel, hariprasad
In-Reply-To: <20141210195405.5af40846@canb.auug.org.au>
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Wed, 10 Dec 2014 19:54:05 +1100
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Wed, 10 Dec 2014 19:48:02 +1100
> Subject: [PATCH] cxgb4/cxgb4vf: global named must be unique
>
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
Applied, thanks.
^ permalink raw reply
* [PATCH net v7 0/7] cxgb4/cxgbi: misc. fixes for cxgb4i
From: Karen Xie @ 2014-12-10 20:57 UTC (permalink / raw)
To: linux-scsi, netdev
Cc: kxie, hariprasad, anish, hch, James.Bottomley, michaelc, davem
[PATCH net v7 0/7] cxgb4/cxgbi: misc. fixes for cxgb4i
This patch set fixes cxgb4i's tx credit calculation and adds handling of additional rx message and negative advice types. It also removes the duplicate code in cxgb4i to set the outgoing queues of a packet.
Karen Xie (7):
cxgb4i: fix tx immediate data credit check
cxgb4i: fix credit check for tx_data_wr
cxgb4/cxgb4i: set max. outgoing pdu length in the f/w
cxgb4i: add more types of negative advice
cxgb4i: handle non pdu-aligned rx data
cxgb4i: use cxgb4's set_wr_txq() for setting outgoing queues
libcxgbi: fix the debug print accessing skb after it is freed
Sending to net as the fixes are mostly in the network area and it touches cxgb4's header file (t4fw_api.h).
v2 corrects the "CHECK"s flagged by checkpatch.pl --strict.
v3 splits the 3rd patch from v2 to two separate patches. Adds detailed commit messages and makes subject more concise. Patch 3/6 also changes the return value of is_neg_adv() from int to bool.
v4 -- please ignore.
v5 splits the 1st patch from v3 to two separate patches and reduces code duplication in make_tx_data_wr().
v6 removed the code style cleanup in the 2nd patch. The style update will be addressed in a separate patch.
v7 updates the 7th patch with more detailed commit message.
^ permalink raw reply
* Re: am335x: cpsw: interrupt failure
From: Yegor Yefremov @ 2014-12-10 20:58 UTC (permalink / raw)
To: Felipe Balbi; +Cc: netdev, N, Mugunthan V
In-Reply-To: <20141210171724.GI4602@saruman>
On Wed, Dec 10, 2014 at 6:17 PM, Felipe Balbi <balbi@ti.com> wrote:
> Hi,
>
> On Fri, Dec 05, 2014 at 11:03:44AM +0100, Yegor Yefremov wrote:
>> On Thu, Dec 4, 2014 at 5:56 PM, Felipe Balbi <balbi@ti.com> wrote:
>> > Hi,
>> >
>> > On Thu, Dec 04, 2014 at 05:41:38PM +0100, Yegor Yefremov wrote:
>> >> I have following problem. My systems reboots at high network load
>> >> after this commit (found via git bissect):
>> >>
>> >> commit 55601c9f24670ba926ebdd4d712ac3b177232330
>> >> Author: Felipe Balbi <balbi@ti.com>
>> >> Date: Mon Sep 8 17:54:58 2014 -0700
>> >>
>> >> arm: omap: intc: switch over to linear irq domain
>> >>
>> >> now that we don't need to support legacy board-files,
>> >> we can completely switch over to a linear irq domain
>> >> and make use of irq_alloc_domain_generic_chips() to
>> >> allocate all generic irq chips for us.
>> >>
>> >> Signed-off-by: Felipe Balbi <balbi@ti.com>
>> >> Signed-off-by: Tony Lindgren <tony@atomide.com>
>> >>
>> >> and I get following error messages:
>> >>
>> >> irq 0, desc: cf004000, depth: 1, count: 0, unhandled: 0
>> >
>> > irq 0 ? Weird, that's not a valid IRQ.
>> >
>> >> ->handle_irq(): c0087fc0, handle_bad_irq+0x0/0x258
>> >> ->irq_data.chip(): c08e7174, no_irq_chip+0x0/0x68
>> >> ->action(): (null)
>> >> IRQ_NOPROBE set
>> >> IRQ_NOREQUEST set
>> >> irq 0, desc: cf004000, depth: 1, count: 0, unhandled: 0
>> >> ->handle_irq(): c0087fc0, handle_bad_irq+0x0/0x258
>> >> ->irq_data.chip(): c08e7174, no_irq_chip+0x0/0x68
>> >> ->action(): (null)
>> >> IRQ_NOPROBE set
>> >> IRQ_NOREQUEST set
>> >> irq 0, desc: cf004000, depth: 1, count: 0, unhandled: 0
>> >> ->handle_irq(): c0087fc0, handle_bad_irq+0x0/0x258
>> >> ->irq_data.chip(): c08e7174, no_irq_chip+0x0/0x68
>> >> ->action(): (null)
>> >> IRQ_NOPROBE set
>> >> IRQ_NOREQUEST set
>> >> irq 0, desc: cf004000, depth: 1, count: 0, unhandled: 0
>> >> ->handle_irq(): c0087fc0, handle_bad_irq+0x0/0x258
>> >> ->irq_data.chip(): c08e7174, no_irq_chip+0x0/0x68
>> >> ->action(): (null)
>> >>
>> >> My system: am335x with fast ethernet on the first slave and gigabit
>> >> Ethernet on second CPSW slave. This issue occurs, when I ran nuttcp
>> >> with default settings.
>> >>
>> >> With commit above I can at least see these messages, but 3.18-rc7 for
>> >> example reboots without any messages.
>> >>
>> >> Any idea?
>> >
>> > if you take v3.18-rc7 and just revert that commit, does the problem go
>> > away ?
>>
>> git revert failed as the driver has more changes meanwhile or I'm
>> missing some params. I've tried to force the driver to use legacy
>> routines, but then I don't get pass U-Boot's "Starting kernel ..." See
>> attached patch.
>>
>> Compiler used:
>>
>> Linux version 3.18.0-rc7 (...) (gcc version 4.8.3 20140320
>> (prerelease) (Sourcery CodeBench Lite 2014.05-29) ) #309 SMP Fri Dec 5
>> 10:59:38 CET 2014
>>
>> Btw, what am335x based hardware do you have? I can run tests on both
>> BBB and am335x-evmsk.
>
> coming back to this. I have BBB only. Can you provide some extra
> information on how I can trigger this problem here ?
I have basically two am335x based boards, where I can trigger this
problem via nuttcp (I think iperf would do the job too). The first
system stalls almost immediately, the second one was working for about
7 minutes. I have tried the same kernel on am335x-evmsk - and this
system didn't stall. I could provide dts files for both systems.
I've tried to reduce my dts as much as I could to match am335x-evmsk
dts, I have even removed entries for the PMIC, but still the system
stalls. Btw PMIC's INT line is connected to a GPIO pin on processor.
I've used omap2plus_defconfig for all 3 devices. Any other info I can supply?
Yegor
^ permalink raw reply
* net merged into net-next, and bug fixes only
From: David Miller @ 2014-12-10 21:00 UTC (permalink / raw)
To: netdev
Please do not submit any more new-feature/cleanup patches
at this time, only bug fixes.
Thanks.
^ permalink raw reply
* RE: [PATCH net v6 7/7] libcxgbi: free skb after debug prints
From: Karen Xie @ 2014-12-10 21:02 UTC (permalink / raw)
To: David Miller
Cc: sergei.shtylyov@cogentembedded.com, linux-scsi@vger.kernel.org,
netdev@vger.kernel.org, Hariprasad S, Anish Bhatt,
hch@infradead.org, James.Bottomley@HansenPartnership.com,
michaelc@cs.wisc.edu
In-Reply-To: <20141210.153230.2033230187234379219.davem@davemloft.net>
Sorry, misread the comment, will resubmit. Thanks.
-----Original Message-----
From: David Miller [mailto:davem@davemloft.net]
Sent: Wednesday, December 10, 2014 12:33 PM
To: Karen Xie
Cc: sergei.shtylyov@cogentembedded.com; linux-scsi@vger.kernel.org; netdev@vger.kernel.org; Hariprasad S; Anish Bhatt; hch@infradead.org; James.Bottomley@HansenPartnership.com; michaelc@cs.wisc.edu
Subject: Re: [PATCH net v6 7/7] libcxgbi: free skb after debug prints
From: Karen Xie <kxie@chelsio.com>
Date: Wed, 10 Dec 2014 20:26:59 +0000
> Thanks, v7 has been submitted to address your comment. Please review.
Sorry, you did not actually address his comments.
He said to not duplicate your Subject lines in your message bodies, and you did not fix that.
^ permalink raw reply
* Re: am335x: cpsw: interrupt failure
From: Felipe Balbi @ 2014-12-10 21:02 UTC (permalink / raw)
To: Yegor Yefremov; +Cc: Felipe Balbi, netdev, N, Mugunthan V
In-Reply-To: <CAGm1_ksziwSjQnV1rDYsAv2QQCvhnZPOimowmsW5Cib7C01aqA@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1727 bytes --]
Hi,
On Wed, Dec 10, 2014 at 09:58:23PM +0100, Yegor Yefremov wrote:
[snip]
> >> git revert failed as the driver has more changes meanwhile or I'm
> >> missing some params. I've tried to force the driver to use legacy
> >> routines, but then I don't get pass U-Boot's "Starting kernel ..." See
> >> attached patch.
> >>
> >> Compiler used:
> >>
> >> Linux version 3.18.0-rc7 (...) (gcc version 4.8.3 20140320
> >> (prerelease) (Sourcery CodeBench Lite 2014.05-29) ) #309 SMP Fri Dec 5
> >> 10:59:38 CET 2014
> >>
> >> Btw, what am335x based hardware do you have? I can run tests on both
> >> BBB and am335x-evmsk.
> >
> > coming back to this. I have BBB only. Can you provide some extra
> > information on how I can trigger this problem here ?
>
> I have basically two am335x based boards, where I can trigger this
too bad, I have a single am335x board available here and that's my BBB.
Do both boards stall or only the server or only the client ?
If only one of them fail, then I try connecting my BBB to my AM437x SK
and see if that'll die too.
> problem via nuttcp (I think iperf would do the job too). The first
> system stalls almost immediately, the second one was working for about
> 7 minutes. I have tried the same kernel on am335x-evmsk - and this
> system didn't stall. I could provide dts files for both systems.
>
> I've tried to reduce my dts as much as I could to match am335x-evmsk
> dts, I have even removed entries for the PMIC, but still the system
> stalls. Btw PMIC's INT line is connected to a GPIO pin on processor.
>
> I've used omap2plus_defconfig for all 3 devices. Any other info I can
> supply?
just the extra bit of info above.
--
balbi
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH net v6 7/7] libcxgbi: free skb after debug prints
From: David Miller @ 2014-12-10 21:04 UTC (permalink / raw)
To: kxie
Cc: sergei.shtylyov, linux-scsi, netdev, hariprasad, anish, hch,
James.Bottomley, michaelc
In-Reply-To: <1442C3287A121140B690F7F20F94463D82F1B3@nice.asicdesigners.com>
From: Karen Xie <kxie@chelsio.com>
Date: Wed, 10 Dec 2014 21:02:34 +0000
> Sorry, misread the comment, will resubmit. Thanks.
Please do not top-post.
Quote the relevant material, then provide your own content
after the quoted material, not before.
^ permalink raw reply
* [PATCH net v8 1/7] cxgb4i: fix tx immediate data credit check
From: Karen Xie @ 2014-12-10 21:11 UTC (permalink / raw)
To: linux-scsi, netdev
Cc: kxie, hariprasad, anish, hch, James.Bottomley, michaelc, davem
From: Karen Xie <kxie@chelsio.com>
Only data skbs need the wr header added while control skbs do not. Make sure they are treated differently.
Signed-off-by: Karen Xie <kxie@chelsio.com>
---
drivers/scsi/cxgbi/cxgb4i/cxgb4i.c | 22 +++++++++++++++-------
drivers/scsi/cxgbi/libcxgbi.h | 4 ++--
2 files changed, 17 insertions(+), 9 deletions(-)
diff --git a/drivers/scsi/cxgbi/cxgb4i/cxgb4i.c b/drivers/scsi/cxgbi/cxgb4i/cxgb4i.c
index 1508125..f119a67 100644
--- a/drivers/scsi/cxgbi/cxgb4i/cxgb4i.c
+++ b/drivers/scsi/cxgbi/cxgb4i/cxgb4i.c
@@ -171,10 +171,14 @@ static int push_tx_frames(struct cxgbi_sock *, int);
* Returns true if a packet can be sent as an offload WR with immediate
* data. We currently use the same limit as for Ethernet packets.
*/
-static inline int is_ofld_imm(const struct sk_buff *skb)
+static inline bool is_ofld_imm(const struct sk_buff *skb)
{
- return skb->len <= (MAX_IMM_TX_PKT_LEN -
- sizeof(struct fw_ofld_tx_data_wr));
+ int len = skb->len;
+
+ if (likely(cxgbi_skcb_test_flag(skb, SKCBF_TX_NEED_HDR)))
+ len += sizeof(struct fw_ofld_tx_data_wr);
+
+ return len <= MAX_IMM_TX_PKT_LEN;
}
static void send_act_open_req(struct cxgbi_sock *csk, struct sk_buff *skb,
@@ -597,11 +601,15 @@ static int push_tx_frames(struct cxgbi_sock *csk, int req_completion)
skb_reset_transport_header(skb);
if (is_ofld_imm(skb))
- credits_needed = DIV_ROUND_UP(dlen +
- sizeof(struct fw_ofld_tx_data_wr), 16);
+ credits_needed = DIV_ROUND_UP(dlen, 16);
else
- credits_needed = DIV_ROUND_UP(8*calc_tx_flits_ofld(skb)
- + sizeof(struct fw_ofld_tx_data_wr),
+ credits_needed = DIV_ROUND_UP(
+ 8 * calc_tx_flits_ofld(skb),
+ 16);
+
+ if (likely(cxgbi_skcb_test_flag(skb, SKCBF_TX_NEED_HDR)))
+ credits_needed += DIV_ROUND_UP(
+ sizeof(struct fw_ofld_tx_data_wr),
16);
if (csk->wr_cred < credits_needed) {
diff --git a/drivers/scsi/cxgbi/libcxgbi.h b/drivers/scsi/cxgbi/libcxgbi.h
index 2c7cb1c..aba1af7 100644
--- a/drivers/scsi/cxgbi/libcxgbi.h
+++ b/drivers/scsi/cxgbi/libcxgbi.h
@@ -317,8 +317,8 @@ static inline void cxgbi_skcb_clear_flag(struct sk_buff *skb,
__clear_bit(flag, &(cxgbi_skcb_flags(skb)));
}
-static inline int cxgbi_skcb_test_flag(struct sk_buff *skb,
- enum cxgbi_skcb_flags flag)
+static inline int cxgbi_skcb_test_flag(const struct sk_buff *skb,
+ enum cxgbi_skcb_flags flag)
{
return test_bit(flag, &(cxgbi_skcb_flags(skb)));
}
^ permalink raw reply related
* [PATCH net v8 4/7] cxgb4i: additional types of negative advice
From: Karen Xie @ 2014-12-10 21:11 UTC (permalink / raw)
To: linux-scsi, netdev
Cc: kxie, hariprasad, anish, hch, James.Bottomley, michaelc, davem
From: Karen Xie <kxie@chelsio.com>
Treat both CPL_ERR_KEEPALV_NEG_ADVICE and CPL_ERR_PERSIST_NEG_ADVICE as negative advice.
Signed-off-by: Karen Xie <kxie@chelsio.com>
---
drivers/scsi/cxgbi/cxgb4i/cxgb4i.c | 12 +++++++++---
1 files changed, 9 insertions(+), 3 deletions(-)
diff --git a/drivers/scsi/cxgbi/cxgb4i/cxgb4i.c b/drivers/scsi/cxgbi/cxgb4i/cxgb4i.c
index 5f31eb7..2880f200 100644
--- a/drivers/scsi/cxgbi/cxgb4i/cxgb4i.c
+++ b/drivers/scsi/cxgbi/cxgb4i/cxgb4i.c
@@ -846,6 +846,13 @@ static void csk_act_open_retry_timer(unsigned long data)
}
+static inline bool is_neg_adv(unsigned int status)
+{
+ return status == CPL_ERR_RTX_NEG_ADVICE ||
+ status == CPL_ERR_KEEPALV_NEG_ADVICE ||
+ status == CPL_ERR_PERSIST_NEG_ADVICE;
+}
+
static void do_act_open_rpl(struct cxgbi_device *cdev, struct sk_buff *skb)
{
struct cxgbi_sock *csk;
@@ -867,7 +874,7 @@ static void do_act_open_rpl(struct cxgbi_device *cdev, struct sk_buff *skb)
"csk 0x%p,%u,0x%lx. ", (&csk->saddr), (&csk->daddr),
atid, tid, status, csk, csk->state, csk->flags);
- if (status == CPL_ERR_RTX_NEG_ADVICE)
+ if (is_neg_adv(status))
goto rel_skb;
module_put(THIS_MODULE);
@@ -973,8 +980,7 @@ static void do_abort_req_rss(struct cxgbi_device *cdev, struct sk_buff *skb)
(&csk->saddr), (&csk->daddr),
csk, csk->state, csk->flags, csk->tid, req->status);
- if (req->status == CPL_ERR_RTX_NEG_ADVICE ||
- req->status == CPL_ERR_PERSIST_NEG_ADVICE)
+ if (is_neg_adv(req->status))
goto rel_skb;
cxgbi_sock_get(csk);
^ permalink raw reply related
* [PATCH net v8 3/7] cxgb4/cxgb4i: set the max. pdu length in firmware
From: Karen Xie @ 2014-12-10 21:11 UTC (permalink / raw)
To: linux-scsi, netdev
Cc: kxie, hariprasad, anish, hch, James.Bottomley, michaelc, davem
From: Karen Xie <kxie@chelsio.com>
Programs the firmware of the maximum outgoing iscsi pdu length per connection.
Signed-off-by: Karen Xie <kxie@chelsio.com>
---
drivers/scsi/cxgbi/cxgb4i/cxgb4i.c | 69 +++++++++++++++++++++++++++---------
1 files changed, 51 insertions(+), 18 deletions(-)
diff --git a/drivers/net/ethernet/chelsio/cxgb4/t4fw_api.h b/drivers/net/ethernet/chelsio/cxgb4/t4fw_api.h
index 3409756..743a350 100644
--- a/drivers/net/ethernet/chelsio/cxgb4/t4fw_api.h
+++ b/drivers/net/ethernet/chelsio/cxgb4/t4fw_api.h
@@ -529,6 +529,7 @@ enum fw_flowc_mnem {
FW_FLOWC_MNEM_RCVNXT,
FW_FLOWC_MNEM_SNDBUF,
FW_FLOWC_MNEM_MSS,
+ FW_FLOWC_MNEM_TXDATAPLEN_MAX,
};
struct fw_flowc_mnemval {
diff --git a/drivers/scsi/cxgbi/cxgb4i/cxgb4i.c b/drivers/scsi/cxgbi/cxgb4i/cxgb4i.c
index abee611..5f31eb7 100644
--- a/drivers/scsi/cxgbi/cxgb4i/cxgb4i.c
+++ b/drivers/scsi/cxgbi/cxgb4i/cxgb4i.c
@@ -75,6 +75,7 @@ typedef void (*cxgb4i_cplhandler_func)(struct cxgbi_device *, struct sk_buff *);
static void *t4_uld_add(const struct cxgb4_lld_info *);
static int t4_uld_rx_handler(void *, const __be64 *, const struct pkt_gl *);
static int t4_uld_state_change(void *, enum cxgb4_state state);
+static inline int send_tx_flowc_wr(struct cxgbi_sock *);
static const struct cxgb4_uld_info cxgb4i_uld_info = {
.name = DRV_MODULE_NAME,
@@ -391,6 +392,12 @@ static void send_abort_req(struct cxgbi_sock *csk)
if (unlikely(csk->state == CTP_ABORTING) || !skb || !csk->cdev)
return;
+
+ if (!cxgbi_sock_flag(csk, CTPF_TX_DATA_SENT)) {
+ send_tx_flowc_wr(csk);
+ cxgbi_sock_set_flag(csk, CTPF_TX_DATA_SENT);
+ }
+
cxgbi_sock_set_state(csk, CTP_ABORTING);
cxgbi_sock_set_flag(csk, CTPF_ABORT_RPL_PENDING);
cxgbi_sock_purge_write_queue(csk);
@@ -493,20 +500,40 @@ static inline unsigned int calc_tx_flits_ofld(const struct sk_buff *skb)
return flits + sgl_len(cnt);
}
-static inline void send_tx_flowc_wr(struct cxgbi_sock *csk)
+#define FLOWC_WR_NPARAMS_MIN 9
+static inline int tx_flowc_wr_credits(int *nparamsp, int *flowclenp)
+{
+ int nparams, flowclen16, flowclen;
+
+ nparams = FLOWC_WR_NPARAMS_MIN;
+ flowclen = offsetof(struct fw_flowc_wr, mnemval[nparams]);
+ flowclen16 = DIV_ROUND_UP(flowclen, 16);
+ flowclen = flowclen16 * 16;
+ /*
+ * Return the number of 16-byte credits used by the FlowC request.
+ * Pass back the nparams and actual FlowC length if requested.
+ */
+ if (nparamsp)
+ *nparamsp = nparams;
+ if (flowclenp)
+ *flowclenp = flowclen;
+
+ return flowclen16;
+}
+
+static inline int send_tx_flowc_wr(struct cxgbi_sock *csk)
{
struct sk_buff *skb;
struct fw_flowc_wr *flowc;
- int flowclen, i;
+ int nparams, flowclen16, flowclen;
- flowclen = 80;
+ flowclen16 = tx_flowc_wr_credits(&nparams, &flowclen);
skb = alloc_wr(flowclen, 0, GFP_ATOMIC);
flowc = (struct fw_flowc_wr *)skb->head;
flowc->op_to_nparams =
- htonl(FW_WR_OP(FW_FLOWC_WR) | FW_FLOWC_WR_NPARAMS(8));
+ htonl(FW_WR_OP(FW_FLOWC_WR) | FW_FLOWC_WR_NPARAMS(nparams));
flowc->flowid_len16 =
- htonl(FW_WR_LEN16(DIV_ROUND_UP(72, 16)) |
- FW_WR_FLOWID(csk->tid));
+ htonl(FW_WR_LEN16(flowclen16) | FW_WR_FLOWID(csk->tid));
flowc->mnemval[0].mnemonic = FW_FLOWC_MNEM_PFNVFN;
flowc->mnemval[0].val = htonl(csk->cdev->pfvf);
flowc->mnemval[1].mnemonic = FW_FLOWC_MNEM_CH;
@@ -525,11 +552,9 @@ static inline void send_tx_flowc_wr(struct cxgbi_sock *csk)
flowc->mnemval[7].val = htonl(csk->advmss);
flowc->mnemval[8].mnemonic = 0;
flowc->mnemval[8].val = 0;
- for (i = 0; i < 9; i++) {
- flowc->mnemval[i].r4[0] = 0;
- flowc->mnemval[i].r4[1] = 0;
- flowc->mnemval[i].r4[2] = 0;
- }
+ flowc->mnemval[8].mnemonic = FW_FLOWC_MNEM_TXDATAPLEN_MAX;
+ flowc->mnemval[8].val = 16384;
+
set_queue(skb, CPL_PRIORITY_DATA, csk);
log_debug(1 << CXGBI_DBG_TOE | 1 << CXGBI_DBG_SOCK,
@@ -539,6 +564,8 @@ static inline void send_tx_flowc_wr(struct cxgbi_sock *csk)
csk->advmss);
cxgb4_ofld_send(csk->cdev->ports[csk->port_id], skb);
+
+ return flowclen16;
}
static inline void make_tx_data_wr(struct cxgbi_sock *csk, struct sk_buff *skb,
@@ -599,6 +626,7 @@ static int push_tx_frames(struct cxgbi_sock *csk, int req_completion)
int dlen = skb->len;
int len = skb->len;
unsigned int credits_needed;
+ int flowclen16 = 0;
skb_reset_transport_header(skb);
if (is_ofld_imm(skb))
@@ -613,6 +641,17 @@ static int push_tx_frames(struct cxgbi_sock *csk, int req_completion)
sizeof(struct fw_ofld_tx_data_wr),
16);
+ /*
+ * Assumes the initial credits is large enough to support
+ * fw_flowc_wr plus largest possible first payload
+ */
+ if (!cxgbi_sock_flag(csk, CTPF_TX_DATA_SENT)) {
+ flowclen16 = send_tx_flowc_wr(csk);
+ csk->wr_cred -= flowclen16;
+ csk->wr_una_cred += flowclen16;
+ cxgbi_sock_set_flag(csk, CTPF_TX_DATA_SENT);
+ }
+
if (csk->wr_cred < credits_needed) {
log_debug(1 << CXGBI_DBG_PDU_TX,
"csk 0x%p, skb %u/%u, wr %d < %u.\n",
@@ -622,7 +661,7 @@ static int push_tx_frames(struct cxgbi_sock *csk, int req_completion)
}
__skb_unlink(skb, &csk->write_queue);
set_queue(skb, CPL_PRIORITY_DATA, csk);
- skb->csum = credits_needed;
+ skb->csum = credits_needed + flowclen16;
csk->wr_cred -= credits_needed;
csk->wr_una_cred += credits_needed;
cxgbi_sock_enqueue_wr(csk, skb);
@@ -633,12 +672,6 @@ static int push_tx_frames(struct cxgbi_sock *csk, int req_completion)
csk->wr_cred, csk->wr_una_cred);
if (likely(cxgbi_skcb_test_flag(skb, SKCBF_TX_NEED_HDR))) {
- if (!cxgbi_sock_flag(csk, CTPF_TX_DATA_SENT)) {
- send_tx_flowc_wr(csk);
- skb->csum += 5;
- csk->wr_cred -= 5;
- csk->wr_una_cred += 5;
- }
len += cxgbi_ulp_extra_len(cxgbi_skcb_ulp_mode(skb));
make_tx_data_wr(csk, skb, dlen, len, credits_needed,
req_completion);
^ permalink raw reply related
* [PATCH net v8 6/7] cxgb4i: use set_wr_txq() to set tx queues
From: Karen Xie @ 2014-12-10 21:11 UTC (permalink / raw)
To: linux-scsi, netdev
Cc: kxie, hariprasad, anish, hch, James.Bottomley, michaelc, davem
From: Karen Xie <kxie@chelsio.com>
use cxgb4's set_wr_txq() for setting of the tx queue for a outgoing packet. Remove the similar function in cxgb4i.
Signed-off-by: Karen Xie <kxie@chelsio.com>
---
drivers/scsi/cxgbi/cxgb4i/cxgb4i.c | 16 +++++-----------
1 files changed, 5 insertions(+), 11 deletions(-)
diff --git a/drivers/scsi/cxgbi/cxgb4i/cxgb4i.c b/drivers/scsi/cxgbi/cxgb4i/cxgb4i.c
index dff7345..6aa50fc 100644
--- a/drivers/scsi/cxgbi/cxgb4i/cxgb4i.c
+++ b/drivers/scsi/cxgbi/cxgb4i/cxgb4i.c
@@ -157,12 +157,6 @@ static struct scsi_transport_template *cxgb4i_stt;
#define RCV_BUFSIZ_MASK 0x3FFU
#define MAX_IMM_TX_PKT_LEN 128
-static inline void set_queue(struct sk_buff *skb, unsigned int queue,
- const struct cxgbi_sock *csk)
-{
- skb->queue_mapping = queue;
-}
-
static int push_tx_frames(struct cxgbi_sock *, int);
/*
@@ -404,7 +398,7 @@ static void send_abort_req(struct cxgbi_sock *csk)
csk->cpl_abort_req = NULL;
req = (struct cpl_abort_req *)skb->head;
- set_queue(skb, CPL_PRIORITY_DATA, csk);
+ set_wr_txq(skb, CPL_PRIORITY_DATA, csk->port_id);
req->cmd = CPL_ABORT_SEND_RST;
t4_set_arp_err_handler(skb, csk, abort_arp_failure);
INIT_TP_WR(req, csk->tid);
@@ -430,7 +424,7 @@ static void send_abort_rpl(struct cxgbi_sock *csk, int rst_status)
csk, csk->state, csk->flags, csk->tid, rst_status);
csk->cpl_abort_rpl = NULL;
- set_queue(skb, CPL_PRIORITY_DATA, csk);
+ set_wr_txq(skb, CPL_PRIORITY_DATA, csk->port_id);
INIT_TP_WR(rpl, csk->tid);
OPCODE_TID(rpl) = cpu_to_be32(MK_OPCODE_TID(CPL_ABORT_RPL, csk->tid));
rpl->cmd = rst_status;
@@ -555,7 +549,7 @@ static inline int send_tx_flowc_wr(struct cxgbi_sock *csk)
flowc->mnemval[8].mnemonic = FW_FLOWC_MNEM_TXDATAPLEN_MAX;
flowc->mnemval[8].val = 16384;
- set_queue(skb, CPL_PRIORITY_DATA, csk);
+ set_wr_txq(skb, CPL_PRIORITY_DATA, csk->port_id);
log_debug(1 << CXGBI_DBG_TOE | 1 << CXGBI_DBG_SOCK,
"csk 0x%p, tid 0x%x, %u,%u,%u,%u,%u,%u,%u.\n",
@@ -660,7 +654,7 @@ static int push_tx_frames(struct cxgbi_sock *csk, int req_completion)
break;
}
__skb_unlink(skb, &csk->write_queue);
- set_queue(skb, CPL_PRIORITY_DATA, csk);
+ set_wr_txq(skb, CPL_PRIORITY_DATA, csk->port_id);
skb->csum = credits_needed + flowclen16;
csk->wr_cred -= credits_needed;
csk->wr_una_cred += credits_needed;
@@ -1552,7 +1546,7 @@ static int ddp_ppod_write_idata(struct cxgbi_device *cdev, unsigned int port_id,
return -ENOMEM;
}
req = (struct ulp_mem_io *)skb->head;
- set_queue(skb, CPL_PRIORITY_CONTROL, NULL);
+ set_wr_txq(skb, CPL_PRIORITY_CONTROL, 0);
ulp_mem_io_set_hdr(lldi, req, wr_len, dlen, pm_addr);
idata = (struct ulptx_idata *)(req + 1);
^ permalink raw reply related
* [PATCH net v8 5/7] cxgb4i: handle non-pdu-aligned rx data
From: Karen Xie @ 2014-12-10 21:11 UTC (permalink / raw)
To: linux-scsi, netdev
Cc: kxie, hariprasad, anish, hch, James.Bottomley, michaelc, davem
From: Karen Xie <kxie@chelsio.com>
Abort the connection upon receiving of cpl_rx_data, which means the pdu cannot be recovered from the tcp stream. This generally is due to pdu header corruption.
Signed-off-by: Karen Xie <kxie@chelsio.com>
---
drivers/scsi/cxgbi/cxgb4i/cxgb4i.c | 22 ++++++++++++++++++++++
1 files changed, 22 insertions(+), 0 deletions(-)
diff --git a/drivers/scsi/cxgbi/cxgb4i/cxgb4i.c b/drivers/scsi/cxgbi/cxgb4i/cxgb4i.c
index 2880f200..dff7345 100644
--- a/drivers/scsi/cxgbi/cxgb4i/cxgb4i.c
+++ b/drivers/scsi/cxgbi/cxgb4i/cxgb4i.c
@@ -1034,6 +1034,27 @@ rel_skb:
__kfree_skb(skb);
}
+static void do_rx_data(struct cxgbi_device *cdev, struct sk_buff *skb)
+{
+ struct cxgbi_sock *csk;
+ struct cpl_rx_data *cpl = (struct cpl_rx_data *)skb->data;
+ unsigned int tid = GET_TID(cpl);
+ struct cxgb4_lld_info *lldi = cxgbi_cdev_priv(cdev);
+ struct tid_info *t = lldi->tids;
+
+ csk = lookup_tid(t, tid);
+ if (!csk) {
+ pr_err("can't find connection for tid %u.\n", tid);
+ } else {
+ /* not expecting this, reset the connection. */
+ pr_err("csk 0x%p, tid %u, rcv cpl_rx_data.\n", csk, tid);
+ spin_lock_bh(&csk->lock);
+ send_abort_req(csk);
+ spin_unlock_bh(&csk->lock);
+ }
+ __kfree_skb(skb);
+}
+
static void do_rx_iscsi_hdr(struct cxgbi_device *cdev, struct sk_buff *skb)
{
struct cxgbi_sock *csk;
@@ -1453,6 +1474,7 @@ cxgb4i_cplhandler_func cxgb4i_cplhandlers[NUM_CPL_CMDS] = {
[CPL_SET_TCB_RPL] = do_set_tcb_rpl,
[CPL_RX_DATA_DDP] = do_rx_data_ddp,
[CPL_RX_ISCSI_DDP] = do_rx_data_ddp,
+ [CPL_RX_DATA] = do_rx_data,
};
int cxgb4i_ofld_init(struct cxgbi_device *cdev)
^ permalink raw reply related
* [PATCH net v8 0/7] cxgb4/cxgbi: misc. fixes for cxgb4i
From: Karen Xie @ 2014-12-10 21:11 UTC (permalink / raw)
To: linux-scsi, netdev
Cc: kxie, hariprasad, anish, hch, James.Bottomley, michaelc, davem
This patch set fixes cxgb4i's tx credit calculation and adds handling of additional rx message and negative advice types. It also removes the duplicate code in cxgb4i to set the outgoing queues of a packet.
Karen Xie (7):
cxgb4i: fix tx immediate data credit check
cxgb4i: fix credit check for tx_data_wr
cxgb4/cxgb4i: set max. outgoing pdu length in the f/w
cxgb4i: add more types of negative advice
cxgb4i: handle non pdu-aligned rx data
cxgb4i: use cxgb4's set_wr_txq() for setting outgoing queues
libcxgbi: fix the debug print accessing skb after it is freed
Sending to net as the fixes are mostly in the network area and it touches cxgb4's header file (t4fw_api.h).
v2 corrects the "CHECK"s flagged by checkpatch.pl --strict.
v3 splits the 3rd patch from v2 to two separate patches. Adds detailed commit messages and makes subject more concise. Patch 3/6 also changes the return value of is_neg_adv() from int to bool.
v4 -- please ignore.
v5 splits the 1st patch from v3 to two separate patches and reduces code duplication in make_tx_data_wr().
v6 removed the code style cleanup in the 2nd patch. The style update will be addressed in a separate patch.
v7 updates the 7th patch with more detailed commit message.
v8 removes the duplicate subject lines from the message bodies.
^ permalink raw reply
* [PATCH net v8 2/7] cxgb4i: fix credit check for tx_data_wr
From: Karen Xie @ 2014-12-10 21:11 UTC (permalink / raw)
To: linux-scsi, netdev
Cc: kxie, hariprasad, anish, hch, James.Bottomley, michaelc, davem
From: Karen Xie <kxie@chelsio.com>
make sure any tx credit related checking is done before adding the wr header.
Signed-off-by: Karen Xie <kxie@chelsio.com>
---
drivers/scsi/cxgbi/cxgb4i/cxgb4i.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/drivers/scsi/cxgbi/cxgb4i/cxgb4i.c b/drivers/scsi/cxgbi/cxgb4i/cxgb4i.c
index f119a67..abee611 100644
--- a/drivers/scsi/cxgbi/cxgb4i/cxgb4i.c
+++ b/drivers/scsi/cxgbi/cxgb4i/cxgb4i.c
@@ -547,10 +547,11 @@ static inline void make_tx_data_wr(struct cxgbi_sock *csk, struct sk_buff *skb,
struct fw_ofld_tx_data_wr *req;
unsigned int submode = cxgbi_skcb_ulp_mode(skb) & 3;
unsigned int wr_ulp_mode = 0;
+ bool imm = is_ofld_imm(skb);
req = (struct fw_ofld_tx_data_wr *)__skb_push(skb, sizeof(*req));
- if (is_ofld_imm(skb)) {
+ if (imm) {
req->op_to_immdlen = htonl(FW_WR_OP(FW_OFLD_TX_DATA_WR) |
FW_WR_COMPL(1) |
FW_WR_IMMDLEN(dlen));
^ permalink raw reply related
* [PATCH net v8 7/7] libcxgbi: fix freeing skb prematurely
From: Karen Xie @ 2014-12-10 21:11 UTC (permalink / raw)
To: linux-scsi, netdev
Cc: kxie, hariprasad, anish, hch, James.Bottomley, michaelc, davem
From: Karen Xie <kxie@chelsio.com>
With debug turned on the debug print would access the skb after it is freed. Fix it to free the skb after the debug print.
Signed-off-by: Karen Xie <kxie@chelsio.com>
---
drivers/scsi/cxgbi/libcxgbi.c | 4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/drivers/scsi/cxgbi/libcxgbi.c b/drivers/scsi/cxgbi/libcxgbi.c
index 7da59c3..eb58afc 100644
--- a/drivers/scsi/cxgbi/libcxgbi.c
+++ b/drivers/scsi/cxgbi/libcxgbi.c
@@ -2294,10 +2294,12 @@ int cxgbi_conn_xmit_pdu(struct iscsi_task *task)
return err;
}
- kfree_skb(skb);
log_debug(1 << CXGBI_DBG_ISCSI | 1 << CXGBI_DBG_PDU_TX,
"itt 0x%x, skb 0x%p, len %u/%u, xmit err %d.\n",
task->itt, skb, skb->len, skb->data_len, err);
+
+ kfree_skb(skb);
+
iscsi_conn_printk(KERN_ERR, task->conn, "xmit err %d.\n", err);
iscsi_conn_failure(task->conn, ISCSI_ERR_XMIT_FAILED);
return err;
^ permalink raw reply related
* Re: [PATCH v7 2/3] net: Add Keystone NetCP ethernet driver
From: Murali Karicheri @ 2014-12-10 21:31 UTC (permalink / raw)
To: David Miller
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
grant.likely-QSEj5FYQhm4dnm+yROfE0A
In-Reply-To: <20141209.131053.2026868499542642866.davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
On 12/09/2014 01:10 PM, David Miller wrote:
> From: Murali Karicheri<m-karicheri2-l0cyMroinI0@public.gmane.org>
> Date: Tue, 2 Dec 2014 16:41:42 -0500
>
>> +static void set_pkt_info_le(u32 buff, u32 buff_len, u32 ndesc,
>> + struct knav_dma_desc *desc)
>> +{
>> + desc->buff_len = cpu_to_le32(buff_len);
>> + desc->buff = cpu_to_le32(buff);
>> + desc->next_desc = cpu_to_le32(ndesc);
>> +}
>
> The members of knav_dma_desc are "u32", so you are going to get tons of
> static checker warnings from trying to assign cpu_to_le32()'s result
> (which is a le32) into them.
David,
Thanks for your comment.
Are you referring to the static code analyser sparse that is invoked
through?
make C=1 CHECK=sparse
I am running it now.
I started a build of v3.18-rc7 with this option and seeing a lot of
warnings. Am I using the right tool? A snapshot of the output is below
CHECK drivers/clk/clk.c
include/linux/err.h:40:16: warning: testing a 'safe expression'
include/linux/err.h:40:16: warning: testing a 'safe expression'
include/linux/err.h:40:16: warning: testing a 'safe expression'
include/linux/err.h:40:16: warning: testing a 'safe expression'
drivers/clk/clk.c:2263:5: warning: symbol '__clk_get' was not declared.
Should it be static?
drivers/clk/clk.c:2274:6: warning: symbol '__clk_put' was not declared.
Should it be static?
drivers/clk/clk.c:2647:37: warning: incorrect type in assignment
(different modifiers)
drivers/clk/clk.c:2647:37: expected void ( *[usertype] clk_init_cb )(
... )
drivers/clk/clk.c:2647:37: got void const *const data
drivers/clk/clk.c:67:22: warning: context imbalance in 'clk_enable_lock'
- wrong count at exit
drivers/clk/clk.c:92:9: warning: context imbalance in
'clk_enable_unlock' - unexpected unlock
CC drivers/clk/clk.o
CHECK drivers/clk/clk-divider.c
drivers/clk/clk-divider.c:362:9: warning: context imbalance in
'clk_divider_set_rate' - different lock contexts for basic block
CC drivers/clk/clk-divider.o
CHECK drivers/clk/clk-fixed-factor.c
CC drivers/clk/clk-fixed-factor.o
CHECK drivers/clk/clk-fixed-rate.c
CC drivers/clk/clk-fixed-rate.o
CHECK drivers/clk/clk-gate.c
drivers/clk/clk-gate.c:71:9: warning: context imbalance in
'clk_gate_endisable' - different lock contexts for basic block
CC drivers/clk/clk-gate.o
CHECK drivers/clk/clk-mux.c
drivers/clk/clk-mux.c:69:12: warning: context imbalance in
'clk_mux_set_parent' - different lock contexts for basic block
CC drivers/clk/clk-mux.o
CHECK drivers/clk/clk-composite.c
CC drivers/clk/clk-composite.o
CHECK drivers/clk/clk-fractional-divider.c
drivers/clk/clk-fractional-divider.c:36:9: warning: context imbalance in
'clk_fd_recalc_rate' - different lock contexts for basic block
drivers/clk/clk-fractional-divider.c:65:12: warning: context imbalance
in 'clk_fd_set_rate' - different lock contexts for basic block
CC drivers/clk/clk-fractional-divider.o
CHECK drivers/clk/clk-gpio-gate.c
drivers/clk/clk-gpio-gate.c:189:13: warning: symbol
'of_gpio_gate_clk_setup' was not declared. Should it be static?
CC drivers/clk/clk-gpio-gate.o
CHECK drivers/clk/clk-conf.c
CC drivers/clk/clk-conf.o
CHECK drivers/clk/keystone/pll.c
CC drivers/clk/keystone/pll.o
CHECK drivers/clk/keystone/gate.c
drivers/clk/keystone/gate.c:118:12: warning: context imbalance in
'keystone_clk_enable' - different lock contexts for basic block
drivers/clk/keystone/gate.c:148:9: warning: context imbalance in
'keystone_clk_disable' - different lock contexts for basic block
CC drivers/clk/keystone/gate.o
LD drivers/clk/keystone/built-in.o
LD drivers/clk/built-in.o
CHECK drivers/clocksource/clksrc-of.c
drivers/clocksource/clksrc-of.c:37:27: warning: incorrect type in
assignment (different modifiers)
drivers/clocksource/clksrc-of.c:37:27: expected void ( *[usertype]
init_func )( ... )
drivers/clocksource/clksrc-of.c:37:27: got void const *const data
CC drivers/clocksource/clksrc-of.o
CHECK drivers/clocksource/mmio.c
CC drivers/clocksource/mmio.o
CHECK drivers/clocksource/arm_arch_timer.c
CC drivers/clocksource/arm_arch_timer.o
CHECK drivers/clocksource/dummy_timer.c
CC drivers/clocksource/dummy_timer.o
CHECK drivers/clocksource/timer-keystone.c
CC drivers/clocksource/timer-keystone.o
LD drivers/clocksource/built-in.o
LD drivers/crypto/built-in.o
CHECK drivers/dma/dmaengine.c
CC drivers/dma/dmaengine.o
CHECK drivers/dma/virt-dma.c
drivers/dma/virt-dma.c:22:14: warning: symbol 'vchan_tx_submit' was not
declared. Should it be static?
CC drivers/dma/virt-dma.o
CHECK drivers/dma/of-dma.c
CC drivers/dma/of-dma.o
CHECK drivers/dma/edma.c
drivers/dma/edma.c:560:32: warning: symbol 'edma_prep_dma_memcpy' was
not declared. Should it be static?
drivers/dma/edma.c:1099:6: warning: symbol 'edma_filter_fn' was not
declared. Should it be static?
--
Murali Karicheri
Linux Kernel, Texas Instruments
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: linux-next: manual merge of the net-next tree with the net tree
From: Stephen Rothwell @ 2014-12-10 21:38 UTC (permalink / raw)
To: David Miller; +Cc: netdev, Thomas.Lendacky, linux-next, linux-kernel
In-Reply-To: <20141210.144943.1497210993149601967.davem@davemloft.net>
[-- Attachment #1: Type: text/plain, Size: 447 bytes --]
Hi Dave,
On Wed, 10 Dec 2014 14:49:43 -0500 (EST) David Miller <davem@davemloft.net> wrote:
>
> As you have seen there are a lot of merge hassles to sort out between
> the 'net' and 'net-next' tree right now, probably I just added a few
> more :-)
>
> I'll try to do the merge by the end of today so that these headaches
> go away for you.
Much appreciated.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: 3.12.33 - BUG xfrm_selector_match+0x25/0x2f6
From: Julian Anastasov @ 2014-12-10 21:41 UTC (permalink / raw)
To: Smart Weblications GmbH - Florian Wiessner
Cc: Steffen Klassert, netdev, LKML, stable, Simon Horman, lvs-devel
In-Reply-To: <5486CD9D.4060107@smart-weblications.de>
Hello,
On Tue, 9 Dec 2014, Smart Weblications GmbH - Florian Wiessner wrote:
> I rebuild everything with the two provided patches and still get:
>
> [ 512.475449] BUG: unable to handle kernel NULL pointer dereference at
> 0000000000000014
> [ 512.481277] IP: [<ffffffffa013d470>] nf_ct_seqadj_set+0x60/0x90 [nf_conntrack]
Same place, hm...
> [ 512.485323] CPU: 4 PID: 28142 Comm: vsftpd Not tainted 3.12.33 #5
Above "#5" is same as previous oops. It means kernel
is not updated. Or you updated only the IPVS modules after
applying the both patches?
You can also try without FTP tests to see if there
are oopses in xfrm, so that we can close this topic and then
to continue for the FTP problem on IPVS lists without
bothering non-IPVS people.
Regards
--
Julian Anastasov <ja@ssi.bg>
^ permalink raw reply
* Re: errors in alignment changes..
From: Sergei Shtylyov @ 2014-12-10 22:08 UTC (permalink / raw)
To: David Miller, mitsuhiro.kimura.kc; +Cc: netdev
In-Reply-To: <20141210.155203.1136471667049608187.davem@davemloft.net>
On 12/10/2014 11:52 PM, David Miller wrote:
> I just re-reviewed this change:
> commit 4d6a949c62f123569fb355b6ec7f314b76f93735
> Author: Mitsuhiro Kimura <mitsuhiro.kimura.kc@renesas.com>
> Date: Thu Nov 27 20:34:00 2014 +0900
> sh_eth: Fix skb alloc size and alignment adjust rule.
> and it has serious problems. Well, actually the code has
> always been broken in this area.
>
> + /* The size of the buffer is a multiple of 16 bytes. */
> + rxdesc->buffer_length = ALIGN(mdp->rx_buf_sz, 16);
> + dma_map_single(&ndev->dev, skb->data, rxdesc->buffer_length,
> + DMA_FROM_DEVICE);
> rxdesc->addr = virt_to_phys(PTR_ALIGN(skb->data, 4));
> rxdesc->status = cpu_to_edmac(mdp, RD_RACT | RD_RFP);
> It doesn't make any sense to call dma_map_single() if you aren't
> even going to use the return value. The DMA mapping created is
> the whole point of calling this function.
Note that this call is just moved from above, not added by this patch.
> And then later we pass:
> dma_sync_single_for_cpu(&ndev->dev, rxdesc->addr,
> - mdp->rx_buf_sz,
> + ALIGN(mdp->rx_buf_sz, 16),
> DMA_FROM_DEVICE);
> rxdesc->addr as the "DMA address", but that must be the return value
> from dma_map_single() not what you've actually stored there which is
> virt_to_phys() run on the skb->data.
> This code must be fixed to:
> 1) Put the return value from dma_map_single() into a local variable,
I have already requested such change in reply to the patch fixing several
DMA errors at once.
> and check for mapping errors.
This was done by that patch IIRC. It just needs to be properly split and
resubmitted.
> 2) On success put that return value into rxdesc->addr
I guess we can just do:
rxdesc->addr = dma_map_single(...);
WBR, Sergei
^ permalink raw reply
* Re: am335x: cpsw: interrupt failure
From: Yegor Yefremov @ 2014-12-10 22:56 UTC (permalink / raw)
To: Felipe Balbi; +Cc: netdev, N, Mugunthan V
In-Reply-To: <20141210210234.GN4602@saruman>
On Wed, Dec 10, 2014 at 10:02 PM, Felipe Balbi <balbi@ti.com> wrote:
> Hi,
>
> On Wed, Dec 10, 2014 at 09:58:23PM +0100, Yegor Yefremov wrote:
>
> [snip]
>
>> >> git revert failed as the driver has more changes meanwhile or I'm
>> >> missing some params. I've tried to force the driver to use legacy
>> >> routines, but then I don't get pass U-Boot's "Starting kernel ..." See
>> >> attached patch.
>> >>
>> >> Compiler used:
>> >>
>> >> Linux version 3.18.0-rc7 (...) (gcc version 4.8.3 20140320
>> >> (prerelease) (Sourcery CodeBench Lite 2014.05-29) ) #309 SMP Fri Dec 5
>> >> 10:59:38 CET 2014
>> >>
>> >> Btw, what am335x based hardware do you have? I can run tests on both
>> >> BBB and am335x-evmsk.
>> >
>> > coming back to this. I have BBB only. Can you provide some extra
>> > information on how I can trigger this problem here ?
>>
>> I have basically two am335x based boards, where I can trigger this
>
> too bad, I have a single am335x board available here and that's my BBB.
>
> Do both boards stall or only the server or only the client ?
>
> If only one of them fail, then I try connecting my BBB to my AM437x SK
> and see if that'll die too.
I have following setup: all three devices (am335x-evmsk inclusively)
are connected to my development host via Gigabit switch. And on all of
them I run "nuttcp -S" and my dev host is client (nuttcp -t). Just
normal setup, when you try to measure am335x network performance. So
am335x devices communicate only with my host and not with each other.
If I use 3.18 I can only observe, that the system freezes, but when I
use the kernel with above mentioned commit I see interrupt errors,
like I described in my first e-mail.
>> problem via nuttcp (I think iperf would do the job too). The first
>> system stalls almost immediately, the second one was working for about
>> 7 minutes. I have tried the same kernel on am335x-evmsk - and this
>> system didn't stall. I could provide dts files for both systems.
>>
>> I've tried to reduce my dts as much as I could to match am335x-evmsk
>> dts, I have even removed entries for the PMIC, but still the system
>> stalls. Btw PMIC's INT line is connected to a GPIO pin on processor.
>>
>> I've used omap2plus_defconfig for all 3 devices. Any other info I can
>> supply?
>
> just the extra bit of info above.
>
> --
> balbi
^ permalink raw reply
* [PATCH iproute2] ip: Simplify executing ip cmd within namespace
From: Vadim Kochan @ 2014-12-10 22:56 UTC (permalink / raw)
To: netdev; +Cc: Vadim Kochan
From: Vadim Kochan <vadim4j@gmail.com>
Added new '-ns' option to simplify executing following cmd:
ip netns exec NETNS ip OPTIONS COMMAND OBJECT
to
ip -ns NETNS OPTIONS COMMAND OBJECT
e.g.:
ip -ns vnet0 link add br0 type bridge
Signed-off-by: Vadim Kochan <vadim4j@gmail.com>
---
May be new option should have better name than '-ns' ?
ip/ip.c | 6 ++++++
ip/ip_common.h | 1 +
ip/ipnetns.c | 2 +-
man/man8/ip.8 | 21 +++++++++++++++++++++
4 files changed, 29 insertions(+), 1 deletion(-)
diff --git a/ip/ip.c b/ip/ip.c
index 5f759d5..35cf463 100644
--- a/ip/ip.c
+++ b/ip/ip.c
@@ -262,6 +262,12 @@ int main(int argc, char **argv)
rcvbuf = size;
} else if (matches(opt, "-help") == 0) {
usage();
+ } else if (matches(opt, "-ns") == 0) {
+ argc--;
+ argv++;
+ argv[0] = argv[1];
+ argv[1] = basename;
+ return netns_exec(argc, argv);
} else {
fprintf(stderr, "Option \"%s\" is unknown, try \"ip -help\".\n", opt);
exit(-1);
diff --git a/ip/ip_common.h b/ip/ip_common.h
index 75bfb82..d4f7e1f 100644
--- a/ip/ip_common.h
+++ b/ip/ip_common.h
@@ -88,6 +88,7 @@ struct link_util
struct link_util *get_link_kind(const char *kind);
struct link_util *get_link_slave_kind(const char *slave_kind);
int get_netns_fd(const char *name);
+int netns_exec(int argc, char **argv);
#ifndef INFINITY_LIFE_TIME
#define INFINITY_LIFE_TIME 0xFFFFFFFFU
diff --git a/ip/ipnetns.c b/ip/ipnetns.c
index 1c8aa02..367841c 100644
--- a/ip/ipnetns.c
+++ b/ip/ipnetns.c
@@ -129,7 +129,7 @@ static void bind_etc(const char *name)
closedir(dir);
}
-static int netns_exec(int argc, char **argv)
+int netns_exec(int argc, char **argv)
{
/* Setup the proper environment for apps that are not netns
* aware, and execute a program in that environment.
diff --git a/man/man8/ip.8 b/man/man8/ip.8
index 2d42e98..bfb0c53 100644
--- a/man/man8/ip.8
+++ b/man/man8/ip.8
@@ -134,6 +134,27 @@ the output.
use the system's name resolver to print DNS names instead of
host addresses.
+.TP
+.BR "\-ns " <NETNS>
+executes the following
+.RI "[ " OPTIONS " ] " OBJECT " { " COMMAND " | "
+.BR help " }"
+in the specified network namespace
+.IR NETNS .
+Actually it just simplifies executing of:
+
+.B ip netns exec
+.IR NETNS
+.B ip
+.RI "[ " OPTIONS " ] " OBJECT " { " COMMAND " | "
+.BR help " }"
+
+to
+
+.B ip
+.RI "-ns " NETNS " [ " OPTIONS " ] " OBJECT " { " COMMAND " | "
+.BR help " }"
+
.SH IP - COMMAND SYNTAX
.SS
--
2.1.3
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox