* [PATCH net-next v10 2/7] cxgb4i: fix credit check for tx_data_wr
From: Karen Xie @ 2014-12-12 3:13 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 8abe8a3..197d7de 100644
--- a/drivers/scsi/cxgbi/cxgb4i/cxgb4i.c
+++ b/drivers/scsi/cxgbi/cxgb4i/cxgb4i.c
@@ -549,10 +549,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, val;
+ 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_V(FW_OFLD_TX_DATA_WR) |
FW_WR_COMPL_F |
FW_WR_IMMDLEN_V(dlen));
^ permalink raw reply related
* [PATCH net-next v10 5/7] cxgb4i: handle non-pdu-aligned rx data
From: Karen Xie @ 2014-12-12 3:13 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 8ca91fd..8b7e8f8 100644
--- a/drivers/scsi/cxgbi/cxgb4i/cxgb4i.c
+++ b/drivers/scsi/cxgbi/cxgb4i/cxgb4i.c
@@ -1037,6 +1037,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;
@@ -1456,6 +1477,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-next v10 0/7] cxgb4/cxgbi: misc. fixes for cxgb4i
From: Karen Xie @ 2014-12-12 3:13 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.
v9 reformatted the commit messages to be max. 80 characters per line.
v10 rebased to net-next tree.
^ permalink raw reply
* [PATCH net-next v10 1/7] cxgb4i: fix tx immediate data credit check
From: Karen Xie @ 2014-12-12 3:13 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 69fbfc8..8abe8a3 100644
--- a/drivers/scsi/cxgbi/cxgb4i/cxgb4i.c
+++ b/drivers/scsi/cxgbi/cxgb4i/cxgb4i.c
@@ -172,10 +172,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,
@@ -600,11 +604,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-next v10 6/7] cxgb4i: use set_wr_txq() to set tx queues
From: Karen Xie @ 2014-12-12 3:13 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 8b7e8f8..a83d2ce 100644
--- a/drivers/scsi/cxgbi/cxgb4i/cxgb4i.c
+++ b/drivers/scsi/cxgbi/cxgb4i/cxgb4i.c
@@ -158,12 +158,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);
/*
@@ -405,7 +399,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);
@@ -431,7 +425,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;
@@ -557,7 +551,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",
@@ -663,7 +657,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;
@@ -1555,7 +1549,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: phy: export fixed_phy_register()
From: Mark Salter @ 2014-12-12 4:03 UTC (permalink / raw)
To: Florian Fainelli; +Cc: netdev, linux-kernel, davem, Mark Salter
When building the bcmgenet driver as module, I get:
ERROR: "fixed_phy_register" [drivers/net/ethernet/broadcom/genet/genet.ko] undefined!
commit b0ba512e225d72 ("net: bcmgenet: enable driver to work without device
tree") which added a call to fixed_phy_register. But fixed_phy_register
needs to be exported if used from a module.
Signed-off-by: Mark Salter <msalter@redhat.com>
---
drivers/net/phy/fixed.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/phy/fixed.c b/drivers/net/phy/fixed.c
index 47872caa..3ad0e6e 100644
--- a/drivers/net/phy/fixed.c
+++ b/drivers/net/phy/fixed.c
@@ -274,6 +274,7 @@ struct phy_device *fixed_phy_register(unsigned int irq,
return phy;
}
+EXPORT_SYMBOL_GPL(fixed_phy_register);
static int __init fixed_mdio_bus_init(void)
{
--
1.8.3.1
^ permalink raw reply related
* Re: errors in alignment changes..
From: Simon Horman @ 2014-12-12 4:30 UTC (permalink / raw)
To: David Miller; +Cc: sergei.shtylyov, mitsuhiro.kimura.kc, netdev
In-Reply-To: <20141210.204215.46146677361631214.davem@davemloft.net>
On Wed, Dec 10, 2014 at 08:42:15PM -0500, David Miller wrote:
> From: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
> Date: Thu, 11 Dec 2014 01:08:07 +0300
>
> > I guess we can just do:
> >
> > rxdesc->addr = dma_map_single(...);
>
> Best not to leave a potentially invalid DMA address in a
> receive descriptor the chip can potentially fetch and
> look at.
>
> That's why I said to put it into a local variable and
> check for errors first.
Hi Dave,
this patch ending up in net is partially my fault.
Sergei, do you have time to address David's concerns in relation to this
patch? If not I would like to suggest reverting it for now.
^ permalink raw reply
* Re: randconfig build error with next-20141210, in drivers/net/ethernet/broadcom/genet
From: Florian Fainelli @ 2014-12-12 5:09 UTC (permalink / raw)
To: David Miller, jim.epost; +Cc: sfr, linux-next, linux-kernel, netdev
In-Reply-To: <20141211.142220.610076934853342634.davem@davemloft.net>
Le 11/12/2014 11:22, David Miller a écrit :
> From: Jim Davis <jim.epost@gmail.com> Date: Wed, 10 Dec 2014
> 09:10:45 -0700
>
>> Building with the attached random configuration file,
>>
>> ERROR: "fixed_phy_register"
>> [drivers/net/ethernet/broadcom/genet/genet.ko] undefined!
>
> Florian, I don't understand why FIXED_PHY is only selected in
> Kconfig if the driver is statically built into the kernel.
>
> That makes no sense at all, you should need that module regardless
> of how the driver itself is enabled.
AFAIR this was introduced to silence a warning you reported:
"I think you need to work on the Kconfig dependencies a little bit more.
I have BCMGENET specified as modular, which absolutely should work. Yet
Kconfig complains.
warning: (BCMGENET) selects FIXED_PHY which has unmet direct
dependencies (NETDEVICES && PHYLIB=y)"
but I agree, this makes no sense, we should select FIXED_PHY
unconditionnally, will send you patches tomorrow to fix that.
>
> Can't we just remove the "XXX=y" in all of those silly:
>
> select FIXED_PHY if XXX=y
>
> expressions?
>
> There are three such cases right now:
>
> drivers/net/dsa/Kconfig: select FIXED_PHY if NET_DSA_BCM_SF2=y
> drivers/net/ethernet/broadcom/Kconfig: select FIXED_PHY if
> BCMGENET=y drivers/net/ethernet/broadcom/Kconfig: select FIXED_PHY
> if SYSTEMPORT=y
>
--
Florian
^ permalink raw reply
* [PATCH] net: sock: correctly handle failed prog retrieval from fd
From: Sasha Levin @ 2014-12-12 5:33 UTC (permalink / raw)
To: davem; +Cc: ast, dborkman, hannes, netdev, linux-kernel, Sasha Levin
Commit "net: sock: allow eBPF programs to be attached to sockets" didn't
correctly handle the case where there is a failure getting the prog from
a given fd.
This allows for easy NULL ptr deref from userspace.
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
---
net/core/filter.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/core/filter.c b/net/core/filter.c
index 8cc3c03..ec9baea 100644
--- a/net/core/filter.c
+++ b/net/core/filter.c
@@ -1103,8 +1103,8 @@ int sk_attach_bpf(u32 ufd, struct sock *sk)
return -EPERM;
prog = bpf_prog_get(ufd);
- if (!prog)
- return -EINVAL;
+ if (IS_ERR(prog))
+ return PTR_ERR(prog);
if (prog->aux->prog_type != BPF_PROG_TYPE_SOCKET_FILTER) {
/* valid fd, but invalid program type */
--
2.1.0
^ permalink raw reply related
* RE: Bug: mv643xxx fails with highmem
From: fugang.duan @ 2014-12-12 5:34 UTC (permalink / raw)
To: David Miller, linux@arm.linux.org.uk
Cc: Fabio.Estevam@freescale.com, ezequiel.garcia@free-electrons.com,
netdev@vger.kernel.org
In-Reply-To: <20141211.152756.1471877201690056873.davem@davemloft.net>
From: David Miller <davem@davemloft.net> Sent: Friday, December 12, 2014 4:28 AM
> To: linux@arm.linux.org.uk
> Cc: Duan Fugang-B38611; Estevam Fabio-R49496; ezequiel.garcia@free-
> electrons.com; netdev@vger.kernel.org
> Subject: Re: Bug: mv643xxx fails with highmem
>
> From: Russell King - ARM Linux <linux@arm.linux.org.uk>
> Date: Thu, 11 Dec 2014 20:25:07 +0000
>
> > Would other drivers need fixing for this as well? Eg, fec_main.c does
> > the following, and this driver is used on iMX6 which can also have
> > highmem:
> >
> > static int
> > fec_enet_txq_submit_frag_skb(struct fec_enet_priv_tx_q *txq,
> > struct sk_buff *skb,
> > struct net_device *ndev) {
> > bufaddr = page_address(this_frag->page.p) +
> > this_frag->page_offset; ...
> > addr = dma_map_single(&fep->pdev->dev, bufaddr,
> frag_len,
> > DMA_TO_DEVICE);
>
> Probably, yes.
Hi, all,
I will submit one patch to fix the issue.
Regards,
Andy
^ permalink raw reply
* Re: [PATCH iproute2 v3] ip: Simplify executing ip cmd within network ns
From: vadim4j @ 2014-12-12 6:04 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: Vadim Kochan, netdev
In-Reply-To: <20141211172640.1afc3283@urahara>
On Thu, Dec 11, 2014 at 05:26:40PM -0800, Stephen Hemminger wrote:
> On Fri, 12 Dec 2014 00:32:51 +0200
> Vadim Kochan <vadim4j@gmail.com> wrote:
>
> > +
> > +#define NETNS_RUN_DIR "/var/run/netns"
> > +#define NETNS_ETC_DIR "/etc/netns"
> > +
> > +#ifndef CLONE_NEWNET
> > +#define CLONE_NEWNET 0x40000000 /* New network namespace (lo, device, names sockets, etc) */
> > +#endif
> > +
> > +#ifndef MNT_DETACH
> > +#define MNT_DETACH 0x00000002 /* Just detach from the tree */
> > +#endif /* MNT_DETACH */
> > +
> > +/* sys/mount.h may be out too old to have these */
> > +#ifndef MS_REC
> > +#define MS_REC 16384
> > +#endif
> > +
> > +#ifndef MS_SLAVE
> > +#define MS_SLAVE (1 << 19)
> > +#endif
> > +
> > +#ifndef MS_SHARED
> > +#define MS_SHARED (1 << 20)
> > +#endif
> > +
> > +extern int netns_switch(char *netns);
> > +
>
> Maybe it would be cleaner to introduce a new file netns.h
> with this and the setnetns syscall wrapper
>
And MS_*/MNT_* defines to new mount.h ?
Thanks,
^ permalink raw reply
* [PATCH net] cxgb4: Add support for QSA modules
From: Hariprasad Shenai @ 2014-12-12 6:37 UTC (permalink / raw)
To: netdev; +Cc: davem, leedom, anish, nirranjan, Hariprasad Shenai
Firmware 1.12.25.0 added support for QSA module, adding the driver code for it.
Also fixes some ethtool get settings for other module types.
Signed-off-by: Hariprasad Shenai <hariprasad@chelsio.com>
---
drivers/net/ethernet/chelsio/cxgb4/cxgb4.h | 2 +-
drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c | 13 ++++++++++---
drivers/net/ethernet/chelsio/cxgb4/t4fw_api.h | 1 +
3 files changed, 12 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/chelsio/cxgb4/cxgb4.h b/drivers/net/ethernet/chelsio/cxgb4/cxgb4.h
index a18d33f..5ab5c31 100644
--- a/drivers/net/ethernet/chelsio/cxgb4/cxgb4.h
+++ b/drivers/net/ethernet/chelsio/cxgb4/cxgb4.h
@@ -392,7 +392,7 @@ struct port_info {
s16 xact_addr_filt; /* index of exact MAC address filter */
u16 rss_size; /* size of VI's RSS table slice */
s8 mdio_addr;
- u8 port_type;
+ enum fw_port_type port_type;
u8 mod_type;
u8 port_id;
u8 tx_chan;
diff --git a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c
index 973dbb7..ccf3436 100644
--- a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c
+++ b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c
@@ -2325,7 +2325,7 @@ static int identify_port(struct net_device *dev,
return t4_identify_port(adap, adap->fn, netdev2pinfo(dev)->viid, val);
}
-static unsigned int from_fw_linkcaps(unsigned int type, unsigned int caps)
+static unsigned int from_fw_linkcaps(enum fw_port_type type, unsigned int caps)
{
unsigned int v = 0;
@@ -2354,14 +2354,20 @@ static unsigned int from_fw_linkcaps(unsigned int type, unsigned int caps)
SUPPORTED_10000baseKR_Full | SUPPORTED_1000baseKX_Full |
SUPPORTED_10000baseKX4_Full;
else if (type == FW_PORT_TYPE_FIBER_XFI ||
- type == FW_PORT_TYPE_FIBER_XAUI || type == FW_PORT_TYPE_SFP) {
+ type == FW_PORT_TYPE_FIBER_XAUI ||
+ type == FW_PORT_TYPE_SFP ||
+ type == FW_PORT_TYPE_QSFP_10G ||
+ type == FW_PORT_TYPE_QSA) {
v |= SUPPORTED_FIBRE;
if (caps & FW_PORT_CAP_SPEED_1G)
v |= SUPPORTED_1000baseT_Full;
if (caps & FW_PORT_CAP_SPEED_10G)
v |= SUPPORTED_10000baseT_Full;
- } else if (type == FW_PORT_TYPE_BP40_BA)
+ } else if (type == FW_PORT_TYPE_BP40_BA ||
+ type == FW_PORT_TYPE_QSFP) {
v |= SUPPORTED_40000baseSR4_Full;
+ v |= SUPPORTED_FIBRE;
+ }
if (caps & FW_PORT_CAP_ANEG)
v |= SUPPORTED_Autoneg;
@@ -2396,6 +2402,7 @@ static int get_settings(struct net_device *dev, struct ethtool_cmd *cmd)
cmd->port = PORT_FIBRE;
else if (p->port_type == FW_PORT_TYPE_SFP ||
p->port_type == FW_PORT_TYPE_QSFP_10G ||
+ p->port_type == FW_PORT_TYPE_QSA ||
p->port_type == FW_PORT_TYPE_QSFP) {
if (p->mod_type == FW_PORT_MOD_TYPE_LR ||
p->mod_type == FW_PORT_MOD_TYPE_SR ||
diff --git a/drivers/net/ethernet/chelsio/cxgb4/t4fw_api.h b/drivers/net/ethernet/chelsio/cxgb4/t4fw_api.h
index beaf80a..834fa48 100644
--- a/drivers/net/ethernet/chelsio/cxgb4/t4fw_api.h
+++ b/drivers/net/ethernet/chelsio/cxgb4/t4fw_api.h
@@ -2470,6 +2470,7 @@ enum fw_port_type {
FW_PORT_TYPE_BP4_AP,
FW_PORT_TYPE_QSFP_10G,
FW_PORT_TYPE_QSFP,
+ FW_PORT_TYPE_QSA,
FW_PORT_TYPE_BP40_BA,
FW_PORT_TYPE_NONE = FW_PORT_CMD_PTYPE_M
--
1.7.1
^ permalink raw reply related
* Re: [PATCH] net: sock: correctly handle failed prog retrieval from fd
From: Alexei Starovoitov @ 2014-12-12 6:34 UTC (permalink / raw)
To: Sasha Levin
Cc: David S. Miller, Daniel Borkmann, Hannes Frederic Sowa,
Network Development, LKML
In-Reply-To: <1418362428-15067-1-git-send-email-sasha.levin@oracle.com>
On Thu, Dec 11, 2014 at 9:33 PM, Sasha Levin <sasha.levin@oracle.com> wrote:
> diff --git a/net/core/filter.c b/net/core/filter.c
> index 8cc3c03..ec9baea 100644
> --- a/net/core/filter.c
> +++ b/net/core/filter.c
> @@ -1103,8 +1103,8 @@ int sk_attach_bpf(u32 ufd, struct sock *sk)
> return -EPERM;
>
> prog = bpf_prog_get(ufd);
> - if (!prog)
> - return -EINVAL;
> + if (IS_ERR(prog))
> + return PTR_ERR(prog);
thank you for the fix, but the same fix is already applied
to net-next and pushed all the way to:
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=198bf1b046e370a7d3987b195cff5f1efebec3ac
sorry for the headache that this bug caused.
^ permalink raw reply
* Re: [PATCH v2 0/6] net-PPP: Deletion of a few unnecessary checks
From: SF Markus Elfring @ 2014-12-12 7:01 UTC (permalink / raw)
To: David Miller
Cc: Sergei Shtylyov, Paul Mackerras, linux-ppp, netdev, Eric Dumazet,
linux-kernel, kernel-janitors, Julia Lawall
In-Reply-To: <20141209.145447.2234157264287438778.davem@davemloft.net>
> Generally speaking, it is advisable to not leave error pointers in data
> structures, even if they are about to be free'd up in an error path anyways.
>
> Therefore I do not like some of the patches in this series.
Can you give any more concrete feedback here?
Regards,
Markus
^ permalink raw reply
* Re: [PATCH net] net: ipv6: allow explicitly choosing optimistic addresses
From: Lorenzo Colitti @ 2014-12-12 7:37 UTC (permalink / raw)
To: Erik Kline
Cc: netdev@vger.kernel.org, YOSHIFUJI Hideaki, Hannes Frederic Sowa
In-Reply-To: <1418356200-7457-1-git-send-email-ek@google.com>
On Fri, Dec 12, 2014 at 12:50 PM, Erik Kline <ek@google.com> wrote:
>
> @@ -1527,7 +1527,8 @@ int ipv6_chk_addr(struct net *net, const struct in6_addr *addr,
> if (!net_eq(dev_net(ifp->idev->dev), net))
> continue;
> if (ipv6_addr_equal(&ifp->addr, addr) &&
> - !(ifp->flags&IFA_F_TENTATIVE) &&
> + (!(ifp->flags&IFA_F_TENTATIVE) ||
> + ifp->flags&IFA_F_OPTIMISTIC) &&
> (dev == NULL || ifp->idev->dev == dev ||
> !(ifp->scope&(IFA_LINK|IFA_HOST) || strict))) {
> rcu_read_unlock_bh();
I looked at the callers of ipv6_chk_addr (lxr finds 19 files); from
what I saw, this change will make all of them more correct except for
ndisc_solicit. With this change, ndisc_solicit could now send
neighbour solicitations from optimistic addresses, which is not
allowed by the RFC.
^ permalink raw reply
* Re: [PATCH net-next] Avoid reducing cwnd when ACK+DSACK is received
From: Sébastien Barré @ 2014-12-12 7:43 UTC (permalink / raw)
To: David Miller; +Cc: netdev, gregory.detal, nanditad, ycheng
In-Reply-To: <20141211.151443.136899813480310270.davem@davemloft.net>
Le 11/12/2014 21:14, David Miller a écrit :
> The net-next tree is closed, therefore it is not appropriate to submit net-next
> changes at this time.
Sorry for that, I missed your mail announcing that next-next was closed.
Will resubmit when it is open again.
regards,
Sébastien.
>
> Thanks.
^ permalink raw reply
* Re: [PATCH v2 1/1] net/macb: add TX multiqueue support for gem
From: Cyrille Pitchen @ 2014-12-12 8:24 UTC (permalink / raw)
To: Thomas Petazzoni
Cc: nicolas.ferre, davem, linux-arm-kernel, netdev, soren.brinkmann,
linux-kernel
In-Reply-To: <20141211203103.4191887a@free-electrons.com>
Le 11/12/2014 20:31, Thomas Petazzoni a écrit :
> Dear Cyrille Pitchen,
>
> On Thu, 11 Dec 2014 11:16:51 +0100, Cyrille Pitchen wrote:
>
>> +#define GEM_ISR1 0x0400
>> +#define GEM_ISR2 0x0404
>> +#define GEM_ISR3 0x0408
>> +#define GEM_ISR4 0x040c
>> +#define GEM_ISR5 0x0410
>> +#define GEM_ISR6 0x0414
>> +#define GEM_ISR7 0x0418
>
> What about doing instead:
>
> #define GEM_ISR(q) ((q) == 0 ? MACB_ISR : 0x400 + (q) << 2)
>
> And ditto for all other registers, which will save a lot of boring repeated code.
>
> If you do that, then you can avoid the following fields in the
> macb_queue structure:
>
> + unsigned int ISR;
> + unsigned int IER;
> + unsigned int IDR;
> + unsigned int IMR;
> + unsigned int TBQP;
>
> And the not very pleasant calculation of those offsets:
>
> + bp->queues[0].bp = bp;
> + bp->queues[0].ISR = MACB_ISR;
> + bp->queues[0].IER = MACB_IER;
> + bp->queues[0].IDR = MACB_IDR;
> + bp->queues[0].IMR = MACB_IMR;
> + bp->queues[0].TBQP = MACB_TBQP;
> + for (q = 1, queue = &bp->queues[1]; q < MACB_MAX_QUEUES; ++q) {
> + if (!(queue_mask & (1 << q)))
> + continue;
> +
> + queue->bp = bp;
> + queue->ISR = (q-1) * sizeof(u32) + GEM_ISR1;
> + queue->IER = (q-1) * sizeof(u32) + GEM_IER1;
> + queue->IDR = (q-1) * sizeof(u32) + GEM_IDR1;
> + queue->IMR = (q-1) * sizeof(u32) + GEM_IMR1;
> + queue->TBQP = (q-1) * sizeof(u32) + GEM_TBQP1;
> + queue++;
> + }
>
> You replace the ISR, IER, IDR, IMR and TBQP by an "id" field in
> macb_queue, which contains the queue number, and then change your:
>
> +#define queue_readl(queue, reg) \
> + __raw_readl((queue)->bp->regs + queue->reg)
> +#define queue_writel(queue, reg, value) \
> + __raw_writel((value), (queue)->bp->regs + queue->reg)
>
> to
>
> +#define queue_readl(queue, reg) \
> + __raw_readl((queue)->bp->regs + reg((queue)->id))
> +#define queue_writel(queue, reg, value) \
> + __raw_writel((value), (queue)->bp->regs + reg((queue)->id)
>
> Best regards,
>
> Thomas
>
Good idea, I'm working on it.
Thanks,
Cyrille
^ permalink raw reply
* Re: [PATCH v2 1/1] net/macb: add TX multiqueue support for gem
From: Cyrille Pitchen @ 2014-12-12 8:59 UTC (permalink / raw)
To: David Laight, 'Thomas Petazzoni'
Cc: nicolas.ferre@atmel.com, davem@davemloft.net,
linux-arm-kernel@lists.infradead.org, netdev@vger.kernel.org,
soren.brinkmann@xilinx.com, linux-kernel@vger.kernel.org
In-Reply-To: <063D6719AE5E284EB5DD2968C1650D6D1CA0BA36@AcuExch.aculab.com>
Le 12/12/2014 10:45, David Laight a écrit :
> From: Thomas Petazzoni
>> On Thu, 11 Dec 2014 11:16:51 +0100, Cyrille Pitchen wrote:
>>
>>> +#define GEM_ISR1 0x0400
>>> +#define GEM_ISR2 0x0404
>>> +#define GEM_ISR3 0x0408
>>> +#define GEM_ISR4 0x040c
>>> +#define GEM_ISR5 0x0410
>>> +#define GEM_ISR6 0x0414
>>> +#define GEM_ISR7 0x0418
>>
>> What about doing instead:
>>
>> #define GEM_ISR(q) ((q) == 0 ? MACB_ISR : 0x400 + (q) << 2)
>>
>> And ditto for all other registers, which will save a lot of boring repeated code.
>
> It will probably add a lot of object code and, depending on how often
> the registers are accesses, might have performance impact.
>
> Having:
> #define GEM_ISR(n) (0x400 + (n) << 4)
> will save source code.
>
> David
>
>
>
So you suggest that we keep the unsigned int fields ISR, IMR, IER, IDR, TBQP in
the struct macb_queue and initialize them once for all in macb_probe() like
patch v2 does but only replace the GEM_ISR1 .. GEM_ISR7 defines by GEM_ISR(n)
in macb.h?
This way there would be to test at run time and we can handle the special
register mapping of queue0.
Is it what you meant?
Regards,
Cyrille
^ permalink raw reply
* RE: [RFC PATCH net-next 1/1] net: Support for switch port configuration
From: Varlese, Marco @ 2014-12-12 9:19 UTC (permalink / raw)
To: Roopa Prabhu, Jiri Pirko
Cc: John Fastabend, netdev@vger.kernel.org,
stephen@networkplumber.org, Fastabend, John R, sfeldma@gmail.com,
linux-kernel@vger.kernel.org
In-Reply-To: <5489D739.9010303@cumulusnetworks.com>
> -----Original Message-----
> From: Roopa Prabhu [mailto:roopa@cumulusnetworks.com]
> Sent: Thursday, December 11, 2014 5:41 PM
> To: Jiri Pirko
> Cc: Varlese, Marco; John Fastabend; netdev@vger.kernel.org;
> stephen@networkplumber.org; Fastabend, John R; sfeldma@gmail.com;
> linux-kernel@vger.kernel.org
> Subject: Re: [RFC PATCH net-next 1/1] net: Support for switch port
> configuration
>
> On 12/11/14, 8:56 AM, Jiri Pirko wrote:
> > Thu, Dec 11, 2014 at 05:37:46PM CET, roopa@cumulusnetworks.com wrote:
> >> On 12/11/14, 3:01 AM, Jiri Pirko wrote:
> >>> Thu, Dec 11, 2014 at 10:59:42AM CET, marco.varlese@intel.com wrote:
> >>>>> -----Original Message-----
> >>>>> From: John Fastabend [mailto:john.fastabend@gmail.com]
> >>>>> Sent: Wednesday, December 10, 2014 5:04 PM
> >>>>> To: Jiri Pirko
> >>>>> Cc: Varlese, Marco; netdev@vger.kernel.org;
> >>>>> stephen@networkplumber.org; Fastabend, John R;
> >>>>> roopa@cumulusnetworks.com; sfeldma@gmail.com; linux-
> >>>>> kernel@vger.kernel.org
> >>>>> Subject: Re: [RFC PATCH net-next 1/1] net: Support for switch port
> >>>>> configuration
> >>>>>
> >>>>> On 12/10/2014 08:50 AM, Jiri Pirko wrote:
> >>>>>> Wed, Dec 10, 2014 at 05:23:40PM CET, marco.varlese@intel.com
> wrote:
> >>>>>>> From: Marco Varlese <marco.varlese@intel.com>
> >>>>>>>
> >>>>>>> Switch hardware offers a list of attributes that are
> >>>>>>> configurable on a per port basis.
> >>>>>>> This patch provides a mechanism to configure switch ports by
> >>>>>>> adding an NDO for setting specific values to specific attributes.
> >>>>>>> There will be a separate patch that extends iproute2 to call the
> >>>>>>> new NDO.
> >>>>>> What are these attributes? Can you give some examples. I'm asking
> >>>>>> because there is a plan to pass generic attributes to switch
> >>>>>> ports replacing current specific ndo_switch_port_stp_update. In
> >>>>>> this case, bridge is setting that attribute.
> >>>>>>
> >>>>>> Is there need to set something directly from userspace or does it
> >>>>>> make rather sense to use involved bridge/ovs/bond ? I think that
> >>>>>> both will be needed.
> >>>>> +1
> >>>>>
> >>>>> I think for many attributes it would be best to have both. The in
> >>>>> kernel callers and netlink userspace can use the same driver ndo_ops.
> >>>>>
> >>>>> But then we don't _require_ any specific bridge/ovs/etc module.
> >>>>> And we may have some attributes that are not specific to any
> >>>>> existing software module. I'm guessing Marco has some examples of
> these.
> >>>>>
> >>>>> [...]
> >>>>>
> >>>>>
> >>>>> --
> >>>>> John Fastabend Intel Corporation
> >>>> We do have a need to configure the attributes directly from user-space
> and I have identified the tool to do that in iproute2.
> >>>>
> >>>> An example of attributes are:
> >>>> * enabling/disabling of learning of source addresses on a given
> >>>> port (you can imagine the attribute called LEARNING for example);
> >>>> * internal loopback control (i.e. LOOPBACK) which will control how
> >>>> the flow of traffic behaves from the switch fabric towards an
> >>>> egress port;
> >>>> * flooding for broadcast/multicast/unicast type of packets (i.e.
> >>>> BFLOODING, MFLOODING, UFLOODING);
> >>>>
> >>>> Some attributes would be of the type enabled/disabled while other will
> allow specific values to allow the user to configure different behaviours of
> that feature on that particular port on that platform.
> >>>>
> >>>> One thing to mention - as John stated as well - there might be some
> attributes that are not specific to any software module but rather have to do
> with the actual hardware/platform to configure.
> >>>>
> >>>> I hope this clarifies some points.
> >>> It does. Makes sense. We need to expose this attr set/get for both
> >>> in-kernel and userspace use cases.
> >>>
> >>> Please adjust you patch for this. Also, as a second patch, it would
> >>> be great if you can convert ndo_switch_port_stp_update to this new
> ndo.
> >> Why are we exposing generic switch attribute get/set from userspace
> >> ?. We already have specific attributes for learning/flooding which
> >> can be extended further.
> > Yes, but that is for PF_BRIDGE and bridge specific attributes. There
> > might be another generic attrs, no?
> I cant think of any. And plus, the whole point of switchdev l2 offloads was to
> map these to existing bridge attributes. And we already have a match for
> some of the attributes that marco wants.
>
> If there is a need for such attributes, i don't see why it is needed for switch
> devices only.
> It is needed for any hw (nics etc). And, a precedence to this is to do it via
> ethtool.
>
> Having said that, am sure we will find a need for this in the future.
> And having a netlink attribute always helps.
>
> Today, it seems like these can be mapped to existing attributes that are
> settable via ndo_bridge_setlink/getlink.
>
> >
> >> And for in kernel api....i had a sample patch in my RFC series (Which
> >> i was going to resubmit, until it was decided that we will use
> >> existing api around
> >> ndo_bridge_setlink/ndo_bridge_getlink):
> >> http://www.spinics.net/lists/netdev/msg305473.html
> > Yes, this might become handy for other generic non-bridge attrs.
> >
> >> Thanks,
> >> Roopa
> >>
> >>
> >>
The list I provided is only a subset of the attributes we will need to be exposed. I do have more and I'm sure that more will come in the future. As I mentioned in few posts earlier, some attributes are generic and some are not.
I did not consider ethtool for few reasons but the main one is that I was under the impression that netlink was preferred in many circumstances over the ethotool_ops. Plus, all the cases I have identified so far are going to nicely fit into the setlink set of operations.
^ permalink raw reply
* [PATCH net] net: ethernet: smsc: Allow to select SMC91X for nios2
From: Tobias Klauser @ 2014-12-12 9:21 UTC (permalink / raw)
To: netdev
This chip is present on the Nios2 Development Kit 2C35.
Signed-off-by: Tobias Klauser <tklauser@distanz.ch>
---
drivers/net/ethernet/smsc/Kconfig | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/smsc/Kconfig b/drivers/net/ethernet/smsc/Kconfig
index 753630f..6279268 100644
--- a/drivers/net/ethernet/smsc/Kconfig
+++ b/drivers/net/ethernet/smsc/Kconfig
@@ -6,7 +6,7 @@ config NET_VENDOR_SMSC
bool "SMC (SMSC)/Western Digital devices"
default y
depends on ARM || ISA || MAC || ARM64 || MIPS || M32R || SUPERH || \
- BLACKFIN || MN10300 || COLDFIRE || XTENSA || PCI || PCMCIA
+ BLACKFIN || MN10300 || COLDFIRE || XTENSA || NIOS2 || PCI || PCMCIA
---help---
If you have a network (Ethernet) card belonging to this class, say Y
and read the Ethernet-HOWTO, available from
@@ -39,7 +39,7 @@ config SMC91X
select CRC32
select MII
depends on (ARM || M32R || SUPERH || MIPS || BLACKFIN || \
- MN10300 || COLDFIRE || ARM64 || XTENSA)
+ MN10300 || COLDFIRE || ARM64 || XTENSA || NIOS2)
---help---
This is a driver for SMC's 91x series of Ethernet chipsets,
including the SMC91C94 and the SMC91C111. Say Y if you want it
--
2.2.0
^ permalink raw reply related
* [PATCH net] net: ethernet: davicom: Allow to select DM9000 for nios2
From: Tobias Klauser @ 2014-12-12 9:21 UTC (permalink / raw)
To: netdev
This chip is present on older revisions of the DE2 development kit.
Signed-off-by: Tobias Klauser <tklauser@distanz.ch>
---
drivers/net/ethernet/davicom/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/davicom/Kconfig b/drivers/net/ethernet/davicom/Kconfig
index 316c5e5..7ec2d74 100644
--- a/drivers/net/ethernet/davicom/Kconfig
+++ b/drivers/net/ethernet/davicom/Kconfig
@@ -4,7 +4,7 @@
config DM9000
tristate "DM9000 support"
- depends on ARM || BLACKFIN || MIPS || COLDFIRE
+ depends on ARM || BLACKFIN || MIPS || COLDFIRE || NIOS2
select CRC32
select MII
---help---
--
2.2.0
^ permalink raw reply related
* RE: [PATCH v2 1/1] net/macb: add TX multiqueue support for gem
From: David Laight @ 2014-12-12 9:45 UTC (permalink / raw)
To: 'Thomas Petazzoni', Cyrille Pitchen
Cc: nicolas.ferre@atmel.com, davem@davemloft.net,
linux-arm-kernel@lists.infradead.org, netdev@vger.kernel.org,
soren.brinkmann@xilinx.com, linux-kernel@vger.kernel.org
In-Reply-To: <20141211203103.4191887a@free-electrons.com>
From: Thomas Petazzoni
> On Thu, 11 Dec 2014 11:16:51 +0100, Cyrille Pitchen wrote:
>
> > +#define GEM_ISR1 0x0400
> > +#define GEM_ISR2 0x0404
> > +#define GEM_ISR3 0x0408
> > +#define GEM_ISR4 0x040c
> > +#define GEM_ISR5 0x0410
> > +#define GEM_ISR6 0x0414
> > +#define GEM_ISR7 0x0418
>
> What about doing instead:
>
> #define GEM_ISR(q) ((q) == 0 ? MACB_ISR : 0x400 + (q) << 2)
>
> And ditto for all other registers, which will save a lot of boring repeated code.
It will probably add a lot of object code and, depending on how often
the registers are accesses, might have performance impact.
Having:
#define GEM_ISR(n) (0x400 + (n) << 4)
will save source code.
David
^ permalink raw reply
* RE: [PATCH net] net: ethernet: davicom: Allow to select DM9000 for nios2
From: David Laight @ 2014-12-12 9:49 UTC (permalink / raw)
To: 'Tobias Klauser', netdev@vger.kernel.org
In-Reply-To: <1418376071-28709-1-git-send-email-tklauser@distanz.ch>
From: Tobias Klauser
> This chip is present on older revisions of the DE2 development kit.
Doesn't that mean the selector should be DE2 not NIOS2.
NIOS2 is a cpu not a board and I think this is an external peripheral
not something implemented in the fpga itself.
David
>
> Signed-off-by: Tobias Klauser <tklauser@distanz.ch>
> ---
> drivers/net/ethernet/davicom/Kconfig | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/ethernet/davicom/Kconfig b/drivers/net/ethernet/davicom/Kconfig
> index 316c5e5..7ec2d74 100644
> --- a/drivers/net/ethernet/davicom/Kconfig
> +++ b/drivers/net/ethernet/davicom/Kconfig
> @@ -4,7 +4,7 @@
>
> config DM9000
> tristate "DM9000 support"
> - depends on ARM || BLACKFIN || MIPS || COLDFIRE
> + depends on ARM || BLACKFIN || MIPS || COLDFIRE || NIOS2
> select CRC32
> select MII
> ---help---
> --
> 2.2.0
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v2 1/1] net/macb: add TX multiqueue support for gem
From: Thomas Petazzoni @ 2014-12-12 9:52 UTC (permalink / raw)
To: David Laight
Cc: Cyrille Pitchen, nicolas.ferre@atmel.com, davem@davemloft.net,
linux-arm-kernel@lists.infradead.org, netdev@vger.kernel.org,
soren.brinkmann@xilinx.com, linux-kernel@vger.kernel.org
In-Reply-To: <063D6719AE5E284EB5DD2968C1650D6D1CA0BA36@AcuExch.aculab.com>
Dear David Laight,
On Fri, 12 Dec 2014 09:45:30 +0000, David Laight wrote:
> From: Thomas Petazzoni
> > On Thu, 11 Dec 2014 11:16:51 +0100, Cyrille Pitchen wrote:
> >
> > > +#define GEM_ISR1 0x0400
> > > +#define GEM_ISR2 0x0404
> > > +#define GEM_ISR3 0x0408
> > > +#define GEM_ISR4 0x040c
> > > +#define GEM_ISR5 0x0410
> > > +#define GEM_ISR6 0x0414
> > > +#define GEM_ISR7 0x0418
> >
> > What about doing instead:
> >
> > #define GEM_ISR(q) ((q) == 0 ? MACB_ISR : 0x400 + (q) << 2)
> >
> > And ditto for all other registers, which will save a lot of boring repeated code.
>
> It will probably add a lot of object code and, depending on how often
> the registers are accesses, might have performance impact.
>
> Having:
> #define GEM_ISR(n) (0x400 + (n) << 4)
> will save source code.
Except that this won't work for n == 0, because for n == 0, the
register offset is not 0x400.
And in fact, my code was also wrong, it should be:
((q) == 0 ? MACB_ISR : 0x400 + ((q)-1) << 2))
Since q=1 is at 0x400.
Best regards,
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply
* Re: [PATCH net] net: ethernet: davicom: Allow to select DM9000 for nios2
From: Tobias Klauser @ 2014-12-12 9:57 UTC (permalink / raw)
To: David Laight; +Cc: netdev@vger.kernel.org
In-Reply-To: <063D6719AE5E284EB5DD2968C1650D6D1CA0BA4C@AcuExch.aculab.com>
On 2014-12-12 at 10:49:13 +0100, David Laight <David.Laight@ACULAB.COM> wrote:
> From: Tobias Klauser
> > This chip is present on older revisions of the DE2 development kit.
>
> Doesn't that mean the selector should be DE2 not NIOS2.
>
> NIOS2 is a cpu not a board and I think this is an external peripheral
> not something implemented in the fpga itself.
You're of course right, but since nios2 relies on device tree there is
no notion of a specific board at compile time.
Moreover, the chip might be used on other boards (I personally know of
at least one) based on the nios2 softcore.
Cheers
Tobias
^ permalink raw reply
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