Re: pending-fixes build: 1 failures 5 warnings (v4.20-rc2-261-g59a9ebee0952)

[Mark Brown]

On Thu, Nov 15, 2018 at 05:00:30PM +, Build bot for Mark Brown wrote:

Today's pending-fixes branch fails to build an arm allmodconfig due to:

>   arm-allmodconfig
> ../drivers/net/ethernet/qlogic/qed/qed_rdma.h:186:79: error: expected ';' 
> before '}' token
> ../drivers/net/ethernet/qlogic/qed/qed_rdma.h:186:79: error: expected ';' 
> before '}' token
> ../drivers/net/ethernet/qlogic/qed/qed_rdma.h:186:79: error: expected ';' 
> before '}' token
> ../drivers/net/ethernet/qlogic/qed/qed_rdma.h:186:79: error: expected ';' 
> before '}' token
> ../drivers/net/ethernet/qlogic/qed/qed_rdma.h:186:79: error: expected ';' 
> before '}' token

caused by 291d57f67d2449737 (qed: Fix rdma_info structure allocation) -
there's a simple typo in the !QED_RDMA stubs that were added.


signature.asc
Description: PGP signature

Re: [PATCH v2 lora-next 1/4] net: lora: sx1301: convert burst spi functions to regmap raw

[Mark Brown]

On Wed, Oct 10, 2018 at 09:59:29AM +0200, Andreas Färber wrote:
> Am 09.10.18 um 14:52 schrieb Ben Whitten:

> > -   return spi_sync_transfer(priv->spi, xfr, 2);
> > +   return regmap_raw_write(priv->regmap, reg, val, len);

> ... Which would mean we are lacking a noinc API for write here!

> @Mark/Stefan, any reason noinc was not implemented symmetrically?

Nobody wanted it enough to do the work of implementing it, there's
nothing stopping someone doing that.


signature.asc
Description: PGP signature

linux-next: manual merge of the scsi tree with the net-next tree

[Mark Brown]

Hi James,

Today's linux-next merge of the scsi tree got a conflict in:

  drivers/scsi/qedf/qedf.h

between commit:

  8673daf4f55bf3b91 ("qedf: Add get_generic_tlv_data handler.")

from the net-next tree and commit:

  4b9b7fabb39b3e9d7 ("scsi: qedf: Improve firmware debug dump handling")

from the scsi tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

diff --cc drivers/scsi/qedf/qedf.h
index cabb6af60fb8,2372a40326f8..
--- a/drivers/scsi/qedf/qedf.h
+++ b/drivers/scsi/qedf/qedf.h
@@@ -501,9 -499,8 +504,10 @@@ extern int qedf_post_io_req(struct qedf
  extern void qedf_process_seq_cleanup_compl(struct qedf_ctx *qedf,
struct fcoe_cqe *cqe, struct qedf_ioreq *io_req);
  extern int qedf_send_flogi(struct qedf_ctx *qedf);
 +extern void qedf_get_protocol_tlv_data(void *dev, void *data);
  extern void qedf_fp_io_handler(struct work_struct *work);
 +extern void qedf_get_generic_tlv_data(void *dev, struct qed_generic_tlvs 
*data);
+ extern void qedf_wq_grcdump(struct work_struct *work);
  
  #define FCOE_WORD_TO_BYTE  4
  #define QEDF_MAX_TASK_NUM 0x


signature.asc
Description: PGP signature

linux-next: manual merge of the net-next tree with the net tree

[Mark Brown]

Hi all,

Today's linux-next merge of the net-next tree got a conflict in:

  net/ipv4/fib_frontend.c

between commit:

  2eabd764cb5512f1338 ("net: ipv4: add missing RTA_TABLE to rtm_ipv4_policy")

from the net tree and commit:

  404eb77ea766260c45c ("ipv4: support sport, dport and ip_proto in 
RTM_GETROUTE")

from the net-next tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

diff --cc net/ipv4/fib_frontend.c
index e66172aaf241,897ae92dff0f..
--- a/net/ipv4/fib_frontend.c
+++ b/net/ipv4/fib_frontend.c
@@@ -649,7 -649,9 +649,10 @@@ const struct nla_policy rtm_ipv4_policy
[RTA_ENCAP] = { .type = NLA_NESTED },
[RTA_UID]   = { .type = NLA_U32 },
[RTA_MARK]  = { .type = NLA_U32 },
 +  [RTA_TABLE] = { .type = NLA_U32 },
+   [RTA_IP_PROTO]  = { .type = NLA_U8 },
+   [RTA_SPORT] = { .type = NLA_U16 },
+   [RTA_DPORT] = { .type = NLA_U16 },
  };
  
  static int rtm_to_fib_config(struct net *net, struct sk_buff *skb,


signature.asc
Description: PGP signature

Re: [PATCH v2 08/13] ASoC: pxa: remove the dmaengine compat need

[Mark Brown]

On Thu, May 24, 2018 at 09:06:58AM +0200, Robert Jarzmik wrote:
> As the pxa architecture switched towards the dmaengine slave map, the
> old compatibility mechanism to acquire the dma requestor line number and
> priority are not needed anymore.

Acked-by: Mark Brown <broo...@kernel.org>


signature.asc
Description: PGP signature

Re: [PATCH 0/8] arm: renesas: Change platform dependency to ARCH_RENESAS

[Mark Brown]

On Fri, Apr 20, 2018 at 03:28:26PM +0200, Geert Uytterhoeven wrote:

> The first 6 patches can be applied independently by subsystem
> maintainers.
> The last two patches depend on the first 6 patches, and are thus marked
> RFC.

Would it not make sense to try to apply everything en masse rather than
delaying?  I'm happy to apply the subsystem stuff but if it gets things
done quicker or more efficiently I'm also happy to have the lot merged
as one series.


signature.asc
Description: PGP signature

Re: [PATCH 08/15] ASoC: pxa: remove the dmaengine compat need

[Mark Brown]

On Mon, Apr 02, 2018 at 04:26:49PM +0200, Robert Jarzmik wrote:
> As the pxa architecture switched towards the dmaengine slave map, the
> old compatibility mechanism to acquire the dma requestor line number and
> priority are not needed anymore.

Acked-by: Mark Brown <broo...@kernel.org>

If there's no dependency I'm happy to take this for 4.18.


signature.asc
Description: PGP signature

Re: linux-next: manual merge of the net-next tree with Linus' tree

[Mark Brown]

On Mon, Oct 30, 2017 at 10:43:07AM -0700, Jakub Kicinski wrote:
> On Mon, 30 Oct 2017 17:02:24 +0000, Mark Brown wrote:

> > is submitted for merging.  You may also want to consider cooperating
> > with the maintainer of the conflicting tree to minimise any particularly
> > complex conflicts.

> Unfortunately, this is not a correct resolution.  Please see below.

So I actually ended up just throwing this away (and the rest of what was
going on for net-next, there were just far too many of these self
conflicts.  The tree is one of the bigger time sinks when doing -next
but today was particularly heavy.


signature.asc
Description: PGP signature

linux-next: manual merge of the net-next tree with Linus' tree

[Mark Brown]

Hi all,

Today's linux-next merge of the net-next tree got a conflict in:

  net/ipv4/tcp_output.c

between commit:

  5889e2c0e441d8 ("tcp: call tcp_rate_skb_sent() when retransmit with unaligned 
skb->data")

from Linus' tree and commit:

  e2080072ed2d98 ("tcp: new list for sent but unacked skbs for RACK recovery")

from the net-next tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

diff --cc net/ipv4/tcp_output.c
index ae60dd3faed0,aab6e7145013..
--- a/net/ipv4/tcp_output.c
+++ b/net/ipv4/tcp_output.c
@@@ -2840,13 -2905,14 +2907,16 @@@ int __tcp_retransmit_skb(struct sock *s
 skb_headroom(skb) >= 0x)) {
struct sk_buff *nskb;
  
-   nskb = __pskb_copy(skb, MAX_TCP_HEADER, GFP_ATOMIC);
-   err = nskb ? tcp_transmit_skb(sk, nskb, 0, GFP_ATOMIC) :
--ENOBUFS;
+   tcp_skb_tsorted_save(skb) {
+   nskb = __pskb_copy(skb, MAX_TCP_HEADER, GFP_ATOMIC);
+   err = nskb ? tcp_transmit_skb(sk, nskb, 0, GFP_ATOMIC) :
+-ENOBUFS;
+   } tcp_skb_tsorted_restore(skb);
+ 
 -  if (!err)
 +  if (!err) {
-   skb->skb_mstamp = tp->tcp_mstamp;
+   tcp_update_skb_after_send(tp, skb);
 +  tcp_rate_skb_sent(sk, skb);
 +  }
} else {
err = tcp_transmit_skb(sk, skb, 1, GFP_ATOMIC);
}


signature.asc
Description: PGP signature

linux-next: manual merge of the net-next tree with Linus' tree

[Mark Brown]

Hi all,

Today's linux-next merge of the net-next tree got a conflict in:

  kernel/bpf/sockmap.c

between commit:

  bfa640757e9378c ("bpf: rename sk_actions to align with bpf infrastructure")

from Linus' tree and commit:

  6aaae2b6c4330a4 ("bpf: rename bpf_compute_data_end into 
bpf_compute_data_pointers")

from the net-next tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

diff --cc kernel/bpf/sockmap.c
index 66f00a2b27f4,eef843c3b419..
--- a/kernel/bpf/sockmap.c
+++ b/kernel/bpf/sockmap.c


signature.asc
Description: PGP signature

linux-next: manual merge of the net-next tree with Linus' tree

[Mark Brown]

Hi all,

Today's linux-next merge of the net-next tree got a conflict in:

  drivers/net/ethernet/netronome/nfp/flower/action.c

between commit:

  d309ae5c6a0064 ("nfp: refuse offloading filters that redirects to upper 
devices")

from Linus' tree and commit:

  62d3f60b4d065c ("nfp: use struct fields for 8 bit-wide access")

from the net-next tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

diff --cc drivers/net/ethernet/netronome/nfp/flower/action.c
index 8ea9320014ee,0a5fc9f8545f..
--- a/drivers/net/ethernet/netronome/nfp/flower/action.c
+++ b/drivers/net/ethernet/netronome/nfp/flower/action.c
@@@ -105,19 -104,326 +104,329 @@@ nfp_fl_output(struct nfp_fl_output *out
if (!out_dev)
return -EOPNOTSUPP;
  
-   /* Only offload egress ports are on the same device as the ingress
-* port.
+   tmp_flags = last ? NFP_FL_OUT_FLAGS_LAST : 0;
+ 
+   if (tun_type) {
+   /* Verify the egress netdev matches the tunnel type. */
+   if (!nfp_fl_netdev_is_tunnel_type(out_dev, tun_type))
+   return -EOPNOTSUPP;
+ 
+   if (*tun_out_cnt)
+   return -EOPNOTSUPP;
+   (*tun_out_cnt)++;
+ 
+   output->flags = cpu_to_be16(tmp_flags |
+   NFP_FL_OUT_FLAGS_USE_TUN);
+   output->port = cpu_to_be32(NFP_FL_PORT_TYPE_TUN | tun_type);
+   } else {
+   /* Set action output parameters. */
+   output->flags = cpu_to_be16(tmp_flags);
+ 
+   /* Only offload if egress ports are on the same device as the
+* ingress port.
+*/
+   if (!switchdev_port_same_parent_id(in_dev, out_dev))
+   return -EOPNOTSUPP;
+ 
+   output->port = cpu_to_be32(nfp_repr_get_port_id(out_dev));
+   if (!output->port)
+   return -EOPNOTSUPP;
+   }
+   nfp_flow->meta.shortcut = output->port;
+ 
+   return 0;
+ }
+ 
+ static bool nfp_fl_supported_tun_port(const struct tc_action *action)
+ {
+   struct ip_tunnel_info *tun = tcf_tunnel_info(action);
+ 
+   return tun->key.tp_dst == htons(NFP_FL_VXLAN_PORT);
+ }
+ 
+ static struct nfp_fl_pre_tunnel *nfp_fl_pre_tunnel(char *act_data, int 
act_len)
+ {
+   size_t act_size = sizeof(struct nfp_fl_pre_tunnel);
+   struct nfp_fl_pre_tunnel *pre_tun_act;
+ 
+   /* Pre_tunnel action must be first on action list.
+* If other actions already exist they need pushed forward.
 */
-   if (!switchdev_port_same_parent_id(in_dev, out_dev))
+   if (act_len)
+   memmove(act_data + act_size, act_data, act_len);
+ 
+   pre_tun_act = (struct nfp_fl_pre_tunnel *)act_data;
+ 
+   memset(pre_tun_act, 0, act_size);
+ 
+   pre_tun_act->head.jump_id = NFP_FL_ACTION_OPCODE_PRE_TUNNEL;
+   pre_tun_act->head.len_lw = act_size >> NFP_FL_LW_SIZ;
+ 
+   return pre_tun_act;
+ }
+ 
+ static int
+ nfp_fl_set_vxlan(struct nfp_fl_set_vxlan *set_vxlan,
+const struct tc_action *action,
+struct nfp_fl_pre_tunnel *pre_tun)
+ {
+   struct ip_tunnel_info *vxlan = tcf_tunnel_info(action);
+   size_t act_size = sizeof(struct nfp_fl_set_vxlan);
+   u32 tmp_set_vxlan_type_index = 0;
+   /* Currently support one pre-tunnel so index is always 0. */
+   int pretun_idx = 0;
+ 
+   if (vxlan->options_len) {
+   /* Do not support options e.g. vxlan gpe. */
return -EOPNOTSUPP;
+   }
+ 
 +  if (!nfp_netdev_is_nfp_repr(out_dev))
 +  return -EOPNOTSUPP;
 +
-   output->port = cpu_to_be32(nfp_repr_get_port_id(out_dev));
-   if (!output->port)
+   set_vxlan->head.jump_id = NFP_FL_ACTION_OPCODE_SET_IPV4_TUNNEL;
+   set_vxlan->head.len_lw = act_size >> NFP_FL_LW_SIZ;
+ 
+   /* Set tunnel type and pre-tunnel index. */
+   tmp_set_vxlan_type_index |=
+   FIELD_PREP(NFP_FL_IPV4_TUNNEL_TYPE, NFP_FL_TUNNEL_VXLAN) |
+   FIELD_PREP(NFP_FL_IPV4_PRE_TUN_INDEX, pretun_idx);
+ 
+   set_vxlan->tun_type_index = cpu_to_be32(tmp_set_vxlan_type_index);
+ 
+   set_vxlan->tun_id = vxlan->key.tun_id;
+   set_vxlan->tun_flags = vxlan->key.tun_flags;
+   set_vxlan->ipv4_ttl = vxlan->key.ttl;
+   set_vxlan->ipv4_tos = vxlan->key.tos;
+ 
+   /* Complete pre_tunnel action. */
+   pre_tun->ipv4_dst = vxlan->key.u.ipv4.dst;
+ 
+   return 0;
+ }
+ 
+ static void nfp_fl_set_helper32(u32 value, u32 mask, u8 *p_exact, u8 *p_mask)
+ {
+   u32 oldvalue = get_unaligned((u32 

linux-next: /home/broonie/tmpfs/next/kernel/bpf/verifier.c:

[Mark Brown]

Hi all,

After merging the net-next tree, today's linux-next build (x86allmodconfig)
failed like this:

/home/broonie/tmpfs/next/kernel/bpf/verifier.c: In function 'check_mem_access':
/home/broonie/tmpfs/next/kernel/bpf/verifier.c:1010:12: error: passing argument 
1 of 'verbose' from incompatible pointer type 
[-Werror=incompatible-pointer-types]
verbose("dereference of modified ctx ptr R%d off=%d+%d, ctx+const is 
allowed, ctx+const+const is not\n",
^
/home/broonie/tmpfs/next/kernel/bpf/verifier.c:173:28: note: expected 'struct 
bpf_verifier_env *' but argument is of type 'char *'
 static __printf(2, 3) void verbose(struct bpf_verifier_env *env,
^
/home/broonie/tmpfs/next/kernel/bpf/verifier.c:1011:5: warning: passing 
argument 2 of 'verbose' makes pointer from integer without a cast 
[-Wint-conversion]
 regno, reg->off, off - reg->off);
 ^
/home/broonie/tmpfs/next/kernel/bpf/verifier.c:173:28: note: expected 'const 
char *' but argument is of type 'u32 {aka unsigned int}'
 static __printf(2, 3) void verbose(struct bpf_verifier_env *env,
^
cc1: some warnings being treated as errors
/home/broonie/tmpfs/next/scripts/Makefile.build:313: recipe for target 
'kernel/bpf/verifier.o' failed

Caused by commit

  28e33f9d78eef ("bpf: disallow arithmetic operations on context pointer")

interacting with

  61bd5218eef34 ("bpf: move global verifier log into verifier environment")


signature.asc
Description: PGP signature

linux-next: manual merge of the net-next tree with the net tree

[Mark Brown]

Hi all,

Today's linux-next merge of the net-next tree got a conflict in:

  tools/testing/selftests/bpf/test_verifier.c

between commit:

  28e33f9d78eef ("bpf: disallow arithmetic operations on context pointer")

from the net tree and commit:

  22c8852624fc9 ("bpf: improve selftests and add tests for meta pointer")

from the net-next tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

diff --cc tools/testing/selftests/bpf/test_verifier.c
index 3c7d3a45a3c5,cc91d0159f43..
--- a/tools/testing/selftests/bpf/test_verifier.c
+++ b/tools/testing/selftests/bpf/test_verifier.c
@@@ -6645,20 -6645,325 +6645,339 @@@ static struct bpf_test tests[] = 
.errstr = "BPF_END uses reserved fields",
.result = REJECT,
},
 +  {
 +  "arithmetic ops make PTR_TO_CTX unusable",
 +  .insns = {
 +  BPF_ALU64_IMM(BPF_ADD, BPF_REG_1,
 +offsetof(struct __sk_buff, data) -
 +offsetof(struct __sk_buff, mark)),
 +  BPF_LDX_MEM(BPF_W, BPF_REG_0, BPF_REG_1,
 +  offsetof(struct __sk_buff, mark)),
 +  BPF_EXIT_INSN(),
 +  },
 +  .errstr = "dereference of modified ctx ptr R1 off=68+8, 
ctx+const is allowed, ctx+const+const is not",
 +  .result = REJECT,
 +  .prog_type = BPF_PROG_TYPE_SCHED_CLS,
 +  },
+   {
+   "meta access, test1",
+   .insns = {
+   BPF_LDX_MEM(BPF_W, BPF_REG_2, BPF_REG_1,
+   offsetof(struct xdp_md, data_meta)),
+   BPF_LDX_MEM(BPF_W, BPF_REG_3, BPF_REG_1,
+   offsetof(struct xdp_md, data)),
+   BPF_MOV64_REG(BPF_REG_0, BPF_REG_2),
+   BPF_ALU64_IMM(BPF_ADD, BPF_REG_0, 8),
+   BPF_JMP_REG(BPF_JGT, BPF_REG_0, BPF_REG_3, 1),
+   BPF_LDX_MEM(BPF_B, BPF_REG_0, BPF_REG_2, 0),
+   BPF_MOV64_IMM(BPF_REG_0, 0),
+   BPF_EXIT_INSN(),
+   },
+   .result = ACCEPT,
+   .prog_type = BPF_PROG_TYPE_XDP,
+   },
+   {
+   "meta access, test2",
+   .insns = {
+   BPF_LDX_MEM(BPF_W, BPF_REG_2, BPF_REG_1,
+   offsetof(struct xdp_md, data_meta)),
+   BPF_LDX_MEM(BPF_W, BPF_REG_3, BPF_REG_1,
+   offsetof(struct xdp_md, data)),
+   BPF_MOV64_REG(BPF_REG_0, BPF_REG_2),
+   BPF_ALU64_IMM(BPF_SUB, BPF_REG_0, 8),
+   BPF_MOV64_REG(BPF_REG_4, BPF_REG_2),
+   BPF_ALU64_IMM(BPF_ADD, BPF_REG_4, 8),
+   BPF_JMP_REG(BPF_JGT, BPF_REG_4, BPF_REG_3, 1),
+   BPF_LDX_MEM(BPF_B, BPF_REG_0, BPF_REG_0, 0),
+   BPF_MOV64_IMM(BPF_REG_0, 0),
+   BPF_EXIT_INSN(),
+   },
+   .result = REJECT,
+   .errstr = "invalid access to packet, off=-8",
+   .prog_type = BPF_PROG_TYPE_XDP,
+   },
+   {
+   "meta access, test3",
+   .insns = {
+   BPF_LDX_MEM(BPF_W, BPF_REG_2, BPF_REG_1,
+   offsetof(struct xdp_md, data_meta)),
+   BPF_LDX_MEM(BPF_W, BPF_REG_3, BPF_REG_1,
+   offsetof(struct xdp_md, data_end)),
+   BPF_MOV64_REG(BPF_REG_0, BPF_REG_2),
+   BPF_ALU64_IMM(BPF_ADD, BPF_REG_0, 8),
+   BPF_JMP_REG(BPF_JGT, BPF_REG_0, BPF_REG_3, 1),
+   BPF_LDX_MEM(BPF_B, BPF_REG_0, BPF_REG_2, 0),
+   BPF_MOV64_IMM(BPF_REG_0, 0),
+   BPF_EXIT_INSN(),
+   },
+   .result = REJECT,
+   .errstr = "invalid access to packet",
+   .prog_type = BPF_PROG_TYPE_XDP,
+   },
+   {
+   "meta access, test4",
+   .insns = {
+   BPF_LDX_MEM(BPF_W, BPF_REG_2, BPF_REG_1,
+   offsetof(struct xdp_md, data_meta)),
+   BPF_LDX_MEM(BPF_W, BPF_REG_3, BPF_REG_1,
+   offsetof(struct xdp_md, data_end)),
+   BPF_LDX_MEM(BPF_W, BPF_REG_4, BPF_REG_1,
+   offsetof(struct xdp_md, data)),
+  

Re: linux-next: manual merge of the net-next tree with the net tree

[Mark Brown]

On Tue, Oct 17, 2017 at 02:30:29PM +0300, Sergei Shtylyov wrote:

> > diff --cc drivers/net/dsa/mv88e6060.c
> > index f123ed57630d,6173be889d95..
> > --- a/drivers/net/dsa/mv88e6060.c
> > +++ b/drivers/net/dsa/mv88e6060.c

>Your mail ends here.

Yes, that's the resulting diff.


signature.asc
Description: PGP signature

linux-next: net/sched/sch_mqprio.c

[Mark Brown]

Hi all,

After merging the net-next tree, today's linux-next build (KCONFIG_NAME)
failed like this:

ERROR: "netdev_txq_to_tc" [net/sched/sch_mqprio.ko] undefined!
/home/broonie/tmpfs/next/scripts/Makefile.modpost:91: recipe for target '__modpo
st' failed

Caused by commit

  32302902ff093 ("mqprio: Reserve last 32 classid values for HW traffic classes 
and misc IDs")

which adds a user of that function in a module but that function is not
exported.  As noted on the previous report reverting to a previous
net-next caused other errors so I've reverted that specific commit.


signature.asc
Description: PGP signature

Re: linux-next: net/sched/cls_flower.c

[Mark Brown]

On Tue, Oct 17, 2017 at 12:21:07PM +0200, Jiri Pirko wrote:
> Tue, Oct 17, 2017 at 12:15:09PM CEST, broo...@kernel.org wrote:

> >/home/broonie/tmpfs/next/net/sched/cls_flower.c:270:27: error: 'struct 
> >cls_fl_filter' has no member named 'hw_dev'
> >  cls_flower.egress_dev = f->hw_dev != tp->q->dev_queue->dev;

> This fix ("net/sched: cls_flower: Set egress_dev mark when calling into the 
> HW driver")
> went to -net tree, should not go to -next. Apparently there is some mixup.
> DaveM?

The issue is that:

> >  7578d7b45ed870b1 ("net: sched: remove unused tcf_exts_get_dev helper and 
> > cls_flower->egress_dev")

> >both in the net-next tree.  Falling back to previous net-next trees
> >introduced other issues so I reverted that commit for today.

the removal happened in the net-next tree, breaking the commit that was
previously introduced in the net tree (sorry, didn't notice that the
immediate commit was in there not net-next).


signature.asc
Description: PGP signature

Re: linux-next: net/sched/cls_flower.c

[Mark Brown]

On Tue, Oct 17, 2017 at 11:15:09AM +0100, Mark Brown wrote:

> Caused by commit
> 
>   7578d7b45ed870b13a8ace57e32feaed623c2a94 ("net/sched: cls_flower: Set 
> egress_dev mark when calling into the HW driver")

Cut'n'paste error, this should be 

c019b5166e11faaf9ed3b64316ed338eaa19de60

Sorry about that.


signature.asc
Description: PGP signature

linux-next: net/sched/cls_flower.c

[Mark Brown]

Hi all,

After merging the net-next tree, today's linux-next build
(x86_allmodconfig) failed like this:

/home/broonie/tmpfs/next/net/sched/cls_flower.c: In function 
'fl_hw_destroy_filter':
/home/broonie/tmpfs/next/net/sched/cls_flower.c:208:12: error: 'struct 
tc_cls_flower_offload' has no member named 'egress_dev'
  cls_flower.egress_dev = f->hw_dev != tp->q->dev_queue->dev;
^
/home/broonie/tmpfs/next/net/sched/cls_flower.c:208:27: error: 'struct 
cls_fl_filter' has no member named 'hw_dev'
  cls_flower.egress_dev = f->hw_dev != tp->q->dev_queue->dev;
   ^
/home/broonie/tmpfs/next/net/sched/cls_flower.c: In function 
'fl_hw_update_stats':
/home/broonie/tmpfs/next/net/sched/cls_flower.c:270:12: error: 'struct 
tc_cls_flower_offload' has no member named 'egress_dev'
  cls_flower.egress_dev = f->hw_dev != tp->q->dev_queue->dev;
^
/home/broonie/tmpfs/next/net/sched/cls_flower.c:270:27: error: 'struct 
cls_fl_filter' has no member named 'hw_dev'
  cls_flower.egress_dev = f->hw_dev != tp->q->dev_queue->dev;
   ^
/home/broonie/tmpfs/next/scripts/Makefile.build:319: recipe for target 
'net/sched/cls_flower.o' failed

Caused by commit

  7578d7b45ed870b13a8ace57e32feaed623c2a94 ("net/sched: cls_flower: Set 
egress_dev mark when calling into the HW driver")

interacting with 

  7578d7b45ed870b1 ("net: sched: remove unused tcf_exts_get_dev helper and 
cls_flower->egress_dev")

both in the net-next tree.  Falling back to previous net-next trees
introduced other issues so I reverted that commit for today.


signature.asc
Description: PGP signature

linux-next: manual merge of the net-next tree with the net tree

[Mark Brown]

Hi all,

Today's linux-next merge of the net-next tree got a conflict in:

  drivers/net/dsa/mv88e6060.c

between commit:

  3efc93c2bc243 ("net: dsa: mv88e6060: fix switch MAC address")

from the net tree and commit:

  56c3ff9bf23e1 ("net: dsa: mv88e6060: setup random mac address")

from the net-next tree.

I fixed it up (see below, the relevant code was deleted in net-next) and
can carry the fix as necessary. This is now fixed as far as linux-next
is concerned, but any non trivial conflicts should be mentioned to your
upstream maintainer when your tree is submitted for merging.  You may
also want to consider cooperating with the maintainer of the conflicting
tree to minimise any particularly complex conflicts.

diff --cc drivers/net/dsa/mv88e6060.c
index f123ed57630d,6173be889d95..
--- a/drivers/net/dsa/mv88e6060.c
+++ b/drivers/net/dsa/mv88e6060.c


signature.asc
Description: PGP signature

linux-next: manual merge of the rdma tree with the FIXME tree

[Mark Brown]

Hi Doug,

Today's linux-next merge of the rdma tree got a conflict in:

  drivers/net/ethernet/mellanox/mlx4/catas.c

between commit:

  d2a0012e7632a5 ("drivers: net: mlx4: use setup_timer() helper.")

from the net-next tree and commit:

  55c0fcc3de4605 ("net/mlx4_core: Convert timers to use timer_setup()")

from the rdma tree.

I fixed it up by taking the second commit and can carry the fix as
necessary. This is now fixed as far as linux-next is concerned, but any
non trivial conflicts should be mentioned to your upstream maintainer
when your tree is submitted for merging.  You may also want to consider
cooperating with the maintainer of the conflicting tree to minimise any
particularly complex conflicts.


signature.asc
Description: PGP signature

[PATCH] nfp: Explicitly include linux/bug.h

[Mark Brown]

Today's -next build encountered an error due to a missing definition of
WARN_ON(), caused by some header reorganization removing an implicit
inclusion of linux/bug.h.  Fix this with an explicit inclusion.

Signed-off-by: Mark Brown <broo...@kernel.org>
---
 drivers/net/ethernet/netronome/nfp/nfp_app.c | 1 +
 drivers/net/ethernet/netronome/nfp/nfp_asm.h | 1 +
 2 files changed, 2 insertions(+)

diff --git a/drivers/net/ethernet/netronome/nfp/nfp_app.c 
b/drivers/net/ethernet/netronome/nfp/nfp_app.c
index 82c290763529..5d9e2eba5b49 100644
--- a/drivers/net/ethernet/netronome/nfp/nfp_app.c
+++ b/drivers/net/ethernet/netronome/nfp/nfp_app.c
@@ -31,6 +31,7 @@
  * SOFTWARE.
  */
 
+#include 
 #include 
 #include 
 
diff --git a/drivers/net/ethernet/netronome/nfp/nfp_asm.h 
b/drivers/net/ethernet/netronome/nfp/nfp_asm.h
index c4c18dd5630a..aa397bf308e4 100644
--- a/drivers/net/ethernet/netronome/nfp/nfp_asm.h
+++ b/drivers/net/ethernet/netronome/nfp/nfp_asm.h
@@ -35,6 +35,7 @@
 #define __NFP_ASM_H__ 1
 
 #include 
+#include 
 #include 
 
 #define REG_NONE   0
-- 
2.14.1

linux-next: build failure after merge of the akpm-current tree

[Mark Brown]

Hi Andrew,

After merging the akpm-current tree, today's linux-next build
(x86 allmodconfig) failed like this:

  CC [M]  drivers/net/ethernet/netronome/nfp/nfp_app.o
In file included from 
/home/broonie/tmpfs/next/drivers/net/ethernet/netronome/nfp/nfp_asm.c:40:0:
/home/broonie/tmpfs/next/drivers/net/ethernet/netronome/nfp/nfp_asm.h: In 
function '__enc_swreg_lm':
/home/broonie/tmpfs/next/drivers/net/ethernet/netronome/nfp/nfp_asm.h:301:2: 
error: implicit declaration of function 'WARN_ON' 
[-Werror=implicit-function-declaration]
  WARN_ON(id > 3 || (off && mode != NN_LM_MOD_NONE));
  ^
cc1: some warnings being treated as errors

Caused by some reliance on an implicit include being exposed by a header
reorganization in your tree.  I'll add a patch for this which I'll post,
probably tomorrow morning.


signature.asc
Description: PGP signature

Re: linux-next: manual merge of the drivers-x86 tree with the net-next tree

[Mark Brown]

On Mon, Oct 09, 2017 at 10:43:01PM +0300, Mika Westerberg wrote:

> If possible, I would rather move this chapter to be before "Networking
> over Thunderbolt cable". Reason is that it then follows NVM flashing
> chapter which is typically where you need to force power in the first
> place.

I guess that's something best sorted out either in the relevant trees or
during the merge window?


signature.asc
Description: PGP signature

linux-next: manual merge of the cgroup tree with the net-next tree

[Mark Brown]

Hi Tejun,

Today's linux-next merge of the cgroup tree got a conflict in:

  kernel/cgroup/cgroup.c

between commit:

  324bda9e6c5ad ("bpf: multi program support for cgroup+bpf")

from the net-next tree and commit:

  041cd640b2f3c ("cgroup: Implement cgroup2 basic CPU usage accounting")

from the cgroup tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

diff --cc kernel/cgroup/cgroup.c
index 00f5b358aeac,c3421ee0d230..
--- a/kernel/cgroup/cgroup.c
+++ b/kernel/cgroup/cgroup.c
@@@ -4765,8 -4785,9 +4788,11 @@@ static struct cgroup *cgroup_create(str
  
return cgrp;
  
 +out_idr_free:
 +  cgroup_idr_remove(>cgroup_idr, cgrp->id);
+ out_stat_exit:
+   if (cgroup_on_dfl(parent))
+   cgroup_stat_exit(cgrp);
  out_cancel_ref:
percpu_ref_exit(>self.refcnt);
  out_free_cgrp:


signature.asc
Description: PGP signature

linux-next: manual merge of the drivers-x86 tree with the net-next tree

[Mark Brown]

Hi Darren,

[Apologies for multiple copies - for some reason vger seems to eat mails
I send from scripts, still trying to figure this out]

Today's linux-next merge of the drivers-x86 tree got a conflict in:

  Documentation/admin-guide/thunderbolt.rst

between commit:

   e69b6c02b4c3b ("net: Add support for networking over Thunderbolt cable")

from the net-next tree and commit:

   ce6a90027c10f ("platform/x86: Add driver to force WMI Thunderbolt controller 
power status")

from the drivers-x86 tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

diff --cc Documentation/admin-guide/thunderbolt.rst
index 5c62d11d77e8,dadcd66ee12f..
--- a/Documentation/admin-guide/thunderbolt.rst
+++ b/Documentation/admin-guide/thunderbolt.rst
@@@ -198,26 -198,17 +198,41 @@@ information is missing
  To recover from this mode, one needs to flash a valid NVM image to the
  host host controller in the same way it is done in the previous chapter.
  
 +Networking over Thunderbolt cable
 +-
 +Thunderbolt technology allows software communication across two hosts
 +connected by a Thunderbolt cable.
 +
 +It is possible to tunnel any kind of traffic over Thunderbolt link but
 +currently we only support Apple ThunderboltIP protocol.
 +
 +If the other host is running Windows or macOS only thing you need to
 +do is to connect Thunderbolt cable between the two hosts, the
 +``thunderbolt-net`` is loaded automatically. If the other host is also
 +Linux you should load ``thunderbolt-net`` manually on one host (it does
 +not matter which one)::
 +
 +  # modprobe thunderbolt-net
 +
 +This triggers module load on the other host automatically. If the driver
 +is built-in to the kernel image, there is no need to do anything.
 +
 +The driver will create one virtual ethernet interface per Thunderbolt
 +port which are named like ``thunderbolt0`` and so on. From this point
 +you can either use standard userspace tools like ``ifconfig`` to
 +configure the interface or let your GUI to handle it automatically.
++
+ Forcing power
+ -
+ Many OEMs include a method that can be used to force the power of a
+ thunderbolt controller to an "On" state even if nothing is connected.
+ If supported by your machine this will be exposed by the WMI bus with
+ a sysfs attribute called "force_power".
+ 
+ For example the intel-wmi-thunderbolt driver exposes this attribute in:
+   
/sys/devices/platform/PNP0C14:00/wmi_bus/wmi_bus-PNP0C14:00/86CCFD48-205E-4A77-9C48-2021CBEDE341/force_power
+ 
+   To force the power to on, write 1 to this attribute file.
+   To disable force power, write 0 to this attribute file.
+ 
+ Note: it's currently not possible to query the force power state of a 
platform.


signature.asc
Description: PGP signature

[PATCH] net: ethernet: mediatek: Explicitly include linux/interrupt.h

[Mark Brown]

The mediatek ethernet driver uses interrupts but does not explicitly
include linux/interrupt.h, relying on implicit includes.  Fix this so we
don't get build breaks as happened for ARM in next-20170720.

Signed-off-by: Mark Brown <broo...@kernel.org>
---
 drivers/net/ethernet/mediatek/mtk_eth_soc.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/net/ethernet/mediatek/mtk_eth_soc.c 
b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
index 7e95cf547ff1..95881ef6ee24 100644
--- a/drivers/net/ethernet/mediatek/mtk_eth_soc.c
+++ b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
@@ -22,6 +22,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "mtk_eth_soc.h"
 
-- 
2.13.2

Re: next-20170720 build: 1 failures 4 warnings (next-20170720)

[Mark Brown]

On Thu, Jul 20, 2017 at 07:26:32AM +0100, Build bot for Mark Brown wrote:

Today's -next fails to build an arm allmodconfig due to:

>   arm-allmodconfig
> ../drivers/net/ethernet/mediatek/mtk_eth_soc.c:1685:8: error: unknown type 
> name 'irqreturn_t'
> ../drivers/net/ethernet/mediatek/mtk_eth_soc.c:1694:9: error: 'IRQ_HANDLED' 
> undeclared (first use in this function)
> ../drivers/net/ethernet/mediatek/mtk_eth_soc.c:1697:8: error: unknown type 
> name 'irqreturn_t'
> ../drivers/net/ethernet/mediatek/mtk_eth_soc.c:1706:9: error: 'IRQ_HANDLED' 
> undeclared (first use in this function)
> ../drivers/net/ethernet/mediatek/mtk_eth_soc.c:2475:8: error: implicit 
> declaration of function 'devm_request_irq' 
> [-Werror=implicit-function-declaration]

There's no obvious relevant change in the driver, some other header
change will have broken the implicit inclusion it's relying on.  I just
sent a patch.


signature.asc
Description: PGP signature

[PATCH] qed*: Fix build for !QED_RDMA

[Mark Brown]

A stray semicolon was introduced by bbfcd1e8e1677b (qed*: Set rdma
generic functions prefix), remove it.

Signed-off-by: Mark Brown <broo...@kernel.org>
---
 include/linux/qed/qede_rdma.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/linux/qed/qede_rdma.h b/include/linux/qed/qede_rdma.h
index 1348a16e5e4b..9904617a9730 100644
--- a/include/linux/qed/qede_rdma.h
+++ b/include/linux/qed/qede_rdma.h
@@ -81,7 +81,7 @@ void qede_rdma_dev_remove(struct qede_dev *dev);
 void qede_rdma_event_changeaddr(struct qede_dev *edr);
 
 #else
-static inline int qede_rdma_dev_add(struct qede_dev *dev);
+static inline int qede_rdma_dev_add(struct qede_dev *dev)
 {
return 0;
 }
-- 
2.11.0

Re: next-20170621 build: 1 failures 7 warnings (next-20170621)

[Mark Brown]

On Wed, Jun 21, 2017 at 10:56:07AM +0100, Build bot for Mark Brown wrote:

Today's -next fails to build an arm allmodconfig with:

> ../include/linux/qed/qede_rdma.h:85:1: error: expected identifier or '(' 
> before '{' token
> ../include/linux/qed/qede_rdma.h:85:1: error: expected identifier or '(' 
> before '{' token
> ../include/linux/qed/qede_rdma.h:85:1: error: expected identifier or '(' 
> before '{' token
> ../include/linux/qed/qede_rdma.h:85:1: error: expected identifier or '(' 
> before '{' token
> ../include/linux/qed/qede_rdma.h:85:1: error: expected identifier or '(' 
> before '{' token
> ../include/linux/qed/qede_rdma.h:85:1: error: expected identifier or '(' 
> before '{' token

caused by bbfcd1e8e1677b (qed*: Set rdma generic functions prefix), the
stub for !QED_RDMA just has a syntax error.


signature.asc
Description: PGP signature

Re: next-20170608 build: 1 failures 4 warnings (next-20170608)

[Mark Brown]

On Thu, Jun 08, 2017 at 10:57:50AM +0100, Build bot for Mark Brown wrote:

Today's -next fails to build an ARM allmodconfig due to:

>   arm-allmodconfig
> ../drivers/hsi/clients/ssi_protocol.c:1069:5: error: 'struct net_device' has 
> no member named 'destructor'

due to cf124db566e6 (net: Fix inconsistent teardown and release of
private netdev state.) which missed this instance, presumably due to a
combination of it not being in one of the normal networking driver
directories and only being buildable on ARM.


signature.asc
Description: PGP signature

Re: next-20170330 build: 2 failures 8 warnings (next-20170330)

[Mark Brown]

On Thu, Mar 30, 2017 at 01:50:39PM +0100, Build bot for Mark Brown wrote:

Today's -next fails to build an ARM allmodconfig due to:

>   arm-allmodconfig
> ../drivers/net/ethernet/faraday/ftgmac100.c:153:9: error: implicit 
> declaration of function 'device_get_mac_address' 
> [-Werror=implicit-function-declaration]
> ../drivers/net/ethernet/faraday/ftgmac100.c:1262:6: error: implicit 
> declaration of function 'of_machine_is_compatible' 
> [-Werror=implicit-function-declaration]
> ../drivers/net/ethernet/faraday/ftgmac100.c:1406:6: error: implicit 
> declaration of function 'of_get_property' 
> [-Werror=implicit-function-declaration]

This driver is using DT and device property APIs without explicitly
including the required headers and has been relying on implict includes,
it should instead include them directly.  I've sent a patch for this.


signature.asc
Description: PGP signature

[PATCH] net/faraday: Explicitly include linux/of.h and linux/property.h

[Mark Brown]

This driver uses interfaces from linux/of.h and linux/property.h but
relies on implict inclusion of those headers which means that changes in
other headers could break the build, as happened in -next for arm today.
Add a explicit includes.

Signed-off-by: Mark Brown <broo...@kernel.org>
---
 drivers/net/ethernet/faraday/ftgmac100.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/net/ethernet/faraday/ftgmac100.c 
b/drivers/net/ethernet/faraday/ftgmac100.c
index 928b0df2b8e0..ade6b3e4ed13 100644
--- a/drivers/net/ethernet/faraday/ftgmac100.c
+++ b/drivers/net/ethernet/faraday/ftgmac100.c
@@ -28,8 +28,10 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
-- 
2.11.0

Re: next-20170110 build: 1 failures 4 warnings (next-20170110)

[Mark Brown]

On Tue, Jan 10, 2017 at 07:21:32AM +, Build bot for Mark Brown wrote:

Today's -next fails to build an arm allmodconfig due to:

>   arm-allmodconfig
> ../drivers/net/ethernet/ti/netcp_core.c:1951:28: error: initialization from 
> incompatible pointer type [-Werror=incompatible-pointer-types]

caused by 6a8162e99ef344 (net: netcp: store network statistics in 64
bits).  It's assigning the function

  static struct rtnl_link_stats64 *
  netcp_get_stats(struct net_device *ndev, struct rtnl_link_stats64 *stats)

to ndo_get_stats64 which expects a function returning void.


signature.asc
Description: PGP signature

Applied "misc: atmel-ssc: register as sound DAI if #sound-dai-cells is present" to the asoc tree

[Mark Brown]

The patch

   misc: atmel-ssc: register as sound DAI if #sound-dai-cells is present

has been applied to the asoc tree at

   git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git 

All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.  

You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.

If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.

Please add any relevant lists and maintainers to the CCs when replying
to this mail.

Thanks,
Mark

>From e8314d7d53c8b050aac2828a5de5f28a997b468b Mon Sep 17 00:00:00 2001
From: Peter Rosin <p...@axentia.se>
Date: Tue, 6 Dec 2016 20:22:36 +0100
Subject: [PATCH] misc: atmel-ssc: register as sound DAI if #sound-dai-cells is
 present

The SSC is currently not usable with the ASoC simple-audio-card, as
every SSC audio user has to build a platform driver that may do as
little as calling atmel_ssc_set_audio/atmel_ssc_put_audio (which
allocates the SSC and registers a DAI with the ASoC subsystem).

So, have that happen automatically, if the #sound-dai-cells property
is present in devicetree, which it has to be anyway for simple audio
card to work.

Signed-off-by: Peter Rosin <p...@axentia.se>
Acked-by: Rob Herring <r...@kernel.org>
Acked-by: Nicolas Ferre <nicolas.fe...@atmel.com>
Signed-off-by: Mark Brown <broo...@kernel.org>
---
 .../devicetree/bindings/misc/atmel-ssc.txt |  2 +
 drivers/misc/atmel-ssc.c   | 50 ++
 include/linux/atmel-ssc.h  |  1 +
 3 files changed, 53 insertions(+)

diff --git a/Documentation/devicetree/bindings/misc/atmel-ssc.txt 
b/Documentation/devicetree/bindings/misc/atmel-ssc.txt
index efc98ea1f23d..f8629bb73945 100644
--- a/Documentation/devicetree/bindings/misc/atmel-ssc.txt
+++ b/Documentation/devicetree/bindings/misc/atmel-ssc.txt
@@ -24,6 +24,8 @@ Optional properties:
this parameter to choose where the clock from.
  - By default the clock is from TK pin, if the clock from RK pin, this
property is needed.
+  - #sound-dai-cells: Should contain <0>.
+ - This property makes the SSC into an automatically registered DAI.
 
 Examples:
 - PDC transfer:
diff --git a/drivers/misc/atmel-ssc.c b/drivers/misc/atmel-ssc.c
index 0516ecda54d3..b2a0340f277e 100644
--- a/drivers/misc/atmel-ssc.c
+++ b/drivers/misc/atmel-ssc.c
@@ -20,6 +20,8 @@
 
 #include 
 
+#include "../../sound/soc/atmel/atmel_ssc_dai.h"
+
 /* Serialize access to ssc_list and user count */
 static DEFINE_SPINLOCK(user_lock);
 static LIST_HEAD(ssc_list);
@@ -145,6 +147,49 @@ static inline const struct atmel_ssc_platform_data * __init
platform_get_device_id(pdev)->driver_data;
 }
 
+#ifdef CONFIG_SND_ATMEL_SOC_SSC
+static int ssc_sound_dai_probe(struct ssc_device *ssc)
+{
+   struct device_node *np = ssc->pdev->dev.of_node;
+   int ret;
+   int id;
+
+   ssc->sound_dai = false;
+
+   if (!of_property_read_bool(np, "#sound-dai-cells"))
+   return 0;
+
+   id = of_alias_get_id(np, "ssc");
+   if (id < 0)
+   return id;
+
+   ret = atmel_ssc_set_audio(id);
+   ssc->sound_dai = !ret;
+
+   return ret;
+}
+
+static void ssc_sound_dai_remove(struct ssc_device *ssc)
+{
+   if (!ssc->sound_dai)
+   return;
+
+   atmel_ssc_put_audio(of_alias_get_id(ssc->pdev->dev.of_node, "ssc"));
+}
+#else
+static inline int ssc_sound_dai_probe(struct ssc_device *ssc)
+{
+   if (of_property_read_bool(ssc->pdev->dev.of_node, "#sound-dai-cells"))
+   return -ENOTSUPP;
+
+   return 0;
+}
+
+static inline void ssc_sound_dai_remove(struct ssc_device *ssc)
+{
+}
+#endif
+
 static int ssc_probe(struct platform_device *pdev)
 {
struct resource *regs;
@@ -204,6 +249,9 @@ static int ssc_probe(struct platform_device *pdev)
dev_info(>dev, "Atmel SSC device at 0x%p (irq %d)\n",
ssc->regs, ssc->irq);
 
+   if (ssc_sound_dai_probe(ssc))
+   dev_err(>dev, "failed to auto-setup ssc for audio\n");
+
return 0;
 }
 
@@ -211,6 +259,8 @@ static int ssc_remove(struct platform_device *pdev)
 {
struct ssc_device *ssc = platform_get_drvdata(pdev);
 
+   ssc_sound_dai_remove(ssc);
+
spin_lock(_lock);
list_del(>list);
spin_unlock(_lock);
diff --git a/include/linux/a

Re: next-20160929 build: 2 failures 4 warnings (next-20160929)

[Mark Brown]

On Thu, Sep 29, 2016 at 12:40:35PM +0100, Build bot for Mark Brown wrote:

For the past couple of days -next has been failing to build an ARM
allmodconfig due to:

>   arm-allmodconfig
> ERROR: "__aeabi_uldivmod" [net/netfilter/xt_hashlimit.ko] undefined!

which appears to be triggered by 11d5f15723c9 (netfilter: xt_hashlimit:
Create revision 2 to support higher pps rates) introducing a division of
a 64 bit number which should be done using do_div().


signature.asc
Description: PGP signature

Re: [PATCH v2] net: hns: mark symbols static where possible

[Mark Brown]

On Tue, Sep 27, 2016 at 07:50:14AM -0400, David Miller wrote:

> This still doesn't apply to the net-next tree.

> If you aren't actually building your patch against the net-next
> tree, don't bother submitting these patches any more.

Baoyou, Dave is referring to his git tree at:

   git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git

(see MAINTAINERS)


signature.asc
Description: PGP signature

Re: next-20160816 build: 1 failures 2 warnings (next-20160816)

[Mark Brown]

On Tue, Aug 16, 2016 at 10:37:20AM +0100, Build bot for Mark Brown wrote:

Today's -next fails to build an ARM allmodconfig due to:

>   arm-allmodconfig
> ../drivers/net/ethernet/mellanox/mlx5/core/debugfs.c:300:61: error: 'outb' 
> undeclared (first use in this function)

which appears to be caused by 535e20f083e6 ({net,IB}/mlx5: QP/XRCD
commands via mlx5 ifc).  outb() just isn't available as standard on ARM,
it's not something that's meaningful for the hardware.


signature.asc
Description: PGP signature

Re: next-20160701 build: 2 failures 5 warnings (next-20160701)

[Mark Brown]

On Fri, Jul 01, 2016 at 10:00:09AM +0100, Build bot for Mark Brown wrote:

Today's -next fails to build am ARM allmodconfig due to:

>   arm-allmodconfig
> ../drivers/net/ethernet/mediatek/mtk_eth_soc.c:1300:2: error: implicit 
> declaration of function 'mtk_handle_irq' 
> [-Werror=implicit-function-declaration]
> ../drivers/net/ethernet/mediatek/mtk_eth_soc.c:1300:25: error: subscripted 
> value is neither array nor pointer nor vector

due to the recent changes to the interrupt handling code, the function
has been split into rx and tx functions but the NET_POLL_CONTROLLER code
hasn't been updated.


signature.asc
Description: PGP signature

Re: linux-next: build failure after merge of the net-next tree

[Mark Brown]

On Fri, Apr 22, 2016 at 04:20:43PM -0700, Jeff Kirsher wrote:
> On Fri, 2016-04-22 at 10:20 +0100, Mark Brown wrote:

> > > Jeff, please have your folks look into this.  Probably just a
> > simple
> > > conversion to mdelay().

> > This is still present, it's been breaking ARM allmodconfig builds for
> > about two weeks now.

> Interesting that no one spoke up until just a week ago.  I have a fix
> and I ready to push it to David Miller.

Like Stephen said it had been there for a couple of days already at the
time it was reported; I happened to be busy at the time it came up so
wasn't looking at the build reports myself.  If you've got a fix please
get it submitted ASAP, having common test configurations broken for any
length of time does get disruptive.


signature.asc
Description: PGP signature

Re: linux-next: build failure after merge of the net-next tree

[Mark Brown]

On Wed, Apr 13, 2016 at 11:15:13AM -0400, David Miller wrote:
> From: Stephen Rothwell 

> > After merging the net-next tree, today's linux-next build (arm
> > allmodconfig) failed like thisi (this has actually been failing for a
> > few days, now):

> > ERROR: "__bad_udelay" [drivers/net/ethernet/intel/ixgbe/ixgbe.ko] undefined!

> > Caused by commit

> >   49425dfc7451 ("ixgbe: Add support for x550em_a 10G MAC type")

> > arm only allows udelay()s up to 2 milliseconds.  This commit
> > adds a 5 ms udelay in ixgbe_acquire_swfw_sync_x550em_a() in
> > drivers/net/ethernet/intel/ixgbe/ixgbe_x550.c.

> Jeff, please have your folks look into this.  Probably just a simple
> conversion to mdelay().

This is still present, it's been breaking ARM allmodconfig builds for
about two weeks now.


signature.asc
Description: PGP signature

Re: [PATCHv2] wlcore: spi: add wl18xx support

[Mark Brown]

On Thu, Apr 21, 2016 at 11:07:37AM +, Reizer, Eyal wrote:

> * (i) If the transfer isn't the last one in the message, this flag is
> * used to make the chipselect briefly go inactive in the middle of the
> * message.  Toggling chipselect in this way may be needed to terminate
> * a chip command, letting a single spi_message perform all of group of
> * chip transactions together.

> Now, in my case I need the CS pin to go inactive and stay inactive during the 
> transfer 
> of the next byte for completing the SPI init correctly (sending the extra 
> clock cycles while CS is inactive)
> If I read the above correctly, CS will only briefly go inactive but will when 
> the next byte 
> is sent it will be active again.
> What am I missing?

No, it changes the state.  The main use case is a brief bounce but
you can use it for other things.


signature.asc
Description: PGP signature

[PATCH] net: phy: spi_ks8895: Don't leak references to SPI devices

[Mark Brown]

The ks8895 driver is using spi_dev_get() apparently just to take a copy
of the SPI device used to instantiate it but never calls spi_dev_put()
to free it.  Since the device is guaranteed to exist between probe() and
remove() there should be no need for the driver to take an extra
reference to it so fix the leak by just using a straight assignment.

Signed-off-by: Mark Brown <broo...@kernel.org>
---
 drivers/net/phy/spi_ks8995.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/phy/spi_ks8995.c b/drivers/net/phy/spi_ks8995.c
index b5d50d458728..93ffedfa2994 100644
--- a/drivers/net/phy/spi_ks8995.c
+++ b/drivers/net/phy/spi_ks8995.c
@@ -441,7 +441,7 @@ static int ks8995_probe(struct spi_device *spi)
return -ENOMEM;
 
mutex_init(>lock);
-   ks->spi = spi_dev_get(spi);
+   ks->spi = spi;
ks->chip = _chip[variant];
 
if (ks->spi->dev.of_node) {
-- 
2.8.0.rc3

Re: [PATCHv2] wlcore: spi: add wl18xx support

[Mark Brown]

On Tue, Apr 19, 2016 at 06:04:49PM +, Reizer, Eyal wrote:

> Thanks! Glad the illustration helped.
> I will try it out again as if i recall cotrectly, i did try that l, and it 
> didnt produce the correct waveform, but perhaps i didnt understand the usage 
> of .cs_change correctly.
> Will double check anyway.

It could also be a bug in your controller driver, it's common for them
to not handle cs_change correctly (at least those that open code the
message loop, obviously modern ones just factor this out into the core).


signature.asc
Description: PGP signature

Re: [PATCHv2] wlcore: spi: add wl18xx support

[Mark Brown]

On Tue, Apr 19, 2016 at 05:38:02PM +, Reizer, Eyal wrote:
> Hi Mark,
> 
> Hope you can see the attached picture that illustrates what need to sent for 
> sucesfull SPI init.

I think what the picture shows is that you just need to send at least
one byte at the end of the transfer *after* deasserting /CS which is
totally not what I'd have understood from any of the previous
discussion.  That is already supported, just send an extra byte using
.cs_change to do what is says.


signature.asc
Description: PGP signature

Re: [PATCHv2] wlcore: spi: add wl18xx support

[Mark Brown]

On Tue, Apr 19, 2016 at 05:21:01PM +, Reizer, Eyal wrote:

> The main quirk here is that i need to send extra clocks after the spi init 
> command while the CS pin is "high" in order to put the wilink chip into SPI 
> mode.
> So just sending an empty transfer wouldnt do the trick here.

A single byte transfer would result in extra clocks being sent so there
must be more to it than that...

> Do you have a recomendation on how to do it without changing the core logic. 
> If it is possible it would be really great.

Please be explicit about what you're trying to do here.  I imagine you
may need to change the core logic but we need to know what it is that
the device needs.


signature.asc
Description: PGP signature

Re: [PATCHv2] wlcore: spi: add wl18xx support

[Mark Brown]

On Tue, Apr 19, 2016 at 09:05:45AM +, Reizer, Eyal wrote:

> Understood. As this special CS manipulation is unique to wspi (wilink spi)  I 
> think the 
> best option is to move this gpio allocation into wlcore_spi as a new device 
> tree entry
> used only by this driver.

That sounds like it is going to break normal chip select operation which
doesn't seem like a good idea either.  What exactly are you trying to do
here?  If you need to send some extra bytes at the end of a transfer why
not just do that, or add an empty transfer with a delay.  It's hard to
see what more you could do with only control of the chip select...


signature.asc
Description: PGP signature

Re: [PATCHv2] wlcore: spi: add wl18xx support

[Mark Brown]

On Mon, Apr 18, 2016 at 05:55:51AM +, Reizer, Eyal wrote:

> > I would suggest fixing this using a new API function from the SPI core, if 
> > we
> > don't already have a generic way to do it.

> Originally this is what I have done until I was pointed to the generic 
> cs-gpio mechanism 
> in the SPI core. 
> It is a generic mechanism already in the SPI core driver.
> See: Documentation/devicetree/bindings/spi/spi-bus.txt

> It is also part of the generic spi.h (include/Linux/spi/spi.h), already part 
> of 
> " struct spi_device" So it seemed redundant adding another mechanism for 
> implementing the same.

No!  This is a *terrible* and broken idea.  Client drivers should *not*
be peering inside controller implementations like this, and they should
especially not be trying to change the chip select without the core
knowing about it.  This is at best going to be fragile, at worst it will
actively break some systems.  Whatever you are trying to do needs to go
through the SPI core with some degree of abstraction, the core needs to
know what's going on and the driver needs to support systems that don't
or can't mux the chip select out as a GPIO.


signature.asc
Description: PGP signature

Re: next-20160222 build: 5 failures 9 warnings (next-20160222)

[Mark Brown]

On Mon, Feb 22, 2016 at 08:36:46AM +, Build bot for Mark Brown wrote:

Today's -next fails to build an arm allmodconfig due to:

>   arm-allmodconfig
> ../drivers/net/ethernet/ti/netcp_core.c:1846:31: error: invalid type argument 
> of '->' (have 'struct tc_to_netdev')
> ../drivers/net/ethernet/ti/netcp_core.c:1851:35: error: invalid type argument 
> of '->' (have 'struct tc_to_netdev')
> ../drivers/net/ethernet/ti/netcp_core.c:1855:8: error: invalid type argument 
> of '->' (have 'struct tc_to_netdev')
> ../drivers/net/ethernet/ti/netcp_core.c:1856:28: error: invalid type argument 
> of '->' (have 'struct tc_to_netdev')
> ../drivers/net/ethernet/ti/netcp_core.c:1857:21: error: invalid type argument 
> of '->' (have 'struct tc_to_netdev')

caused by commit 16e5cc647173a (net: rework setup_tc ndo op to consume
general tc operand) in the net-next tree which looks to have a missing *
in the rewrite of the function arguments for that driver.


signature.asc
Description: PGP signature

Re: next-20160104 build: 3 failures 15 warnings (next-20160104)

[Mark Brown]

On Mon, Jan 04, 2016 at 11:07:41PM +0100, Arnd Bergmann wrote:
> On Monday 04 January 2016 16:50:25 Mark Brown wrote:
> > On Mon, Jan 04, 2016 at 12:12:20PM +, Build bot for Mark Brown wrote:

> > and various other linker errors caused by the fact that the new fman
> > driver uses PHYLIB but does not depend on or select it.

> This is the patch I submitted for the problem. I don't think that simply
> adding the 'select' would be a good idea because that would force PHYLIB
> builtin for allmodconfig.

Indeed, that was why I held off on my own patch - I wanted to go back
and try to understand why we were using a bool there.


signature.asc
Description: PGP signature

Re: next-20160104 build: 3 failures 15 warnings (next-20160104)

[Mark Brown]

On Mon, Jan 04, 2016 at 12:12:20PM +, Build bot for Mark Brown wrote:

Today's linux-next fails to build an arm allmodconfig (and probably also
at least arm64 though other errors prevent that getting to linking
currently) due to:

| drivers/built-in.o: In function `dtsec_restart_autoneg':
| :(.text+0x30f86c): undefined reference to `mdiobus_read'
| :(.text+0x30f89c): undefined reference to `mdiobus_write'
| drivers/built-in.o: In function `dtsec_init':
| :(.text+0x31008c): undefined reference to `mdiobus_write'
| :(.text+0x3100b4): undefined reference to `mdiobus_write'
| :(.text+0x3100dc): undefined reference to `mdiobus_write'
| :(.text+0x310128): undefined reference to `mdiobus_write'
| drivers/built-in.o::(.text+0x310150): more undefined references to 
`mdiobus_write' follow
| drivers/built-in.o: In function `dtsec_config':
| :(.text+0x310804): undefined reference to `of_phy_find_device'

and various other linker errors caused by the fact that the new fman
driver uses PHYLIB but does not depend on or select it.


signature.asc
Description: PGP signature

linux-next: manual merge of the ipvs-next tree with the tree

[Mark Brown]

Hi Simon,

Today's linux-next merge of the ipvs-next tree got a conflict in  between 
commit 264640fc2c5f4f ("ipv6: distinguish frag queues by device for multicast 
and link-local packets") from the net tree and commit 029f7f3b8701c 
("netfilter: ipv6: nf_defrag: avoid/free clone operations") from the ipvs-next 
tree.

I fixed it up (see below) and can carry the fix as necessary (no action
is required).

diff --cc net/ipv6/netfilter/nf_conntrack_reasm.c
index bab4441ed4e4,912bc3afc183..
--- a/net/ipv6/netfilter/nf_conntrack_reasm.c
+++ b/net/ipv6/netfilter/nf_conntrack_reasm.c
@@@ -582,31 -576,19 +577,21 @@@ int nf_ct_frag6_gather(struct net *net
}
  
if (find_prev_fhdr(skb, , , ) < 0)
-   return skb;
+   return -EINVAL;
  
-   clone = skb_clone(skb, GFP_ATOMIC);
-   if (clone == NULL) {
-   pr_debug("Can't clone skb\n");
-   return skb;
-   }
- 
-   NFCT_FRAG6_CB(clone)->orig = skb;
- 
-   if (!pskb_may_pull(clone, fhoff + sizeof(*fhdr))) {
-   pr_debug("message is too short.\n");
-   goto ret_orig;
-   }
+   if (!pskb_may_pull(skb, fhoff + sizeof(*fhdr)))
+   return -ENOMEM;
  
-   skb_set_transport_header(clone, fhoff);
-   hdr = ipv6_hdr(clone);
-   fhdr = (struct frag_hdr *)skb_transport_header(clone);
+   skb_set_transport_header(skb, fhoff);
+   hdr = ipv6_hdr(skb);
+   fhdr = (struct frag_hdr *)skb_transport_header(skb);
  
fq = fq_find(net, fhdr->identification, user, >saddr, >daddr,
 -   ip6_frag_ecn(hdr));
 -  if (fq == NULL)
 +   skb->dev ? skb->dev->ifindex : 0, ip6_frag_ecn(hdr));
 +  if (fq == NULL) {
 +  pr_debug("Can't find and can't create new queue\n");
-   goto ret_orig;
+   return -ENOMEM;
 +  }
  
spin_lock_bh(>q.lock);
  


pgp_KZoZvCNjL.pgp
Description: PGP signature

Re: next-20151126 build: 3 failures 15 warnings (next-20151126)

[Mark Brown]

On Thu, Nov 26, 2015 at 08:34:20PM +0200, Kalle Valo wrote:
> Mark Brown <broo...@kernel.org> writes:

> > It still ought to be fixed regardless of why it showed up - the
> > intention of the code is that we build the real thermal code regardless
> > of if that's modular or not but that's not what the code actually does.

> Like I said above Michal will apply a fix to his tree. Read the full
> discussion from patchwork:

> https://patchwork.kernel.org/patch/7707801/

Oh, right - a fix for this specific issue rather than a fix for whatever
change he made.


signature.asc
Description: PGP signature

[PATCH 1/2] net: fsl: Don't use NO_IRQ to check return value of irq_of_parse_and_map()

[Mark Brown]

This driver can be built on arm64 but relies on NO_IRQ to check the return
value of irq_of_parse_and_map() which fails to build on arm64 because the
architecture does not provide a NO_IRQ. Fix this to correctly check the
return value of irq_of_parse_and_map().

Even on ARM systems where the driver was previously used the check was
broken since on ARM NO_IRQ is -1 but irq_of_parse_and_map() returns 0 on
error.

Signed-off-by: Mark Brown <broo...@kernel.org>
---
 drivers/net/ethernet/freescale/gianfar.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/net/ethernet/freescale/gianfar.c 
b/drivers/net/ethernet/freescale/gianfar.c
index 67b1850c034e..4ce60e0c8341 100644
--- a/drivers/net/ethernet/freescale/gianfar.c
+++ b/drivers/net/ethernet/freescale/gianfar.c
@@ -647,9 +647,9 @@ static int gfar_parse_group(struct device_node *np,
if (model && strcasecmp(model, "FEC")) {
gfar_irq(grp, RX)->irq = irq_of_parse_and_map(np, 1);
gfar_irq(grp, ER)->irq = irq_of_parse_and_map(np, 2);
-   if (gfar_irq(grp, TX)->irq == NO_IRQ ||
-   gfar_irq(grp, RX)->irq == NO_IRQ ||
-   gfar_irq(grp, ER)->irq == NO_IRQ)
+   if (!gfar_irq(grp, TX)->irq ||
+   !gfar_irq(grp, RX)->irq ||
+   !gfar_irq(grp, ER)->irq)
return -EINVAL;
}
 
-- 
2.6.2

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: next-20151126 build: 3 failures 15 warnings (next-20151126)

[Mark Brown]

On Thu, Nov 26, 2015 at 09:06:25AM +, Build bot for Mark Brown wrote:

For the past couple of days an arm64 allmodconfig has been failing to
build due to:

>   arm64-allmodconfig
> ../drivers/net/ethernet/freescale/gianfar.c:650:33: error: 'NO_IRQ' 
> undeclared (first use in this function)
> ../drivers/net/ethernet/freescale/gianfar_ptp.c:470:22: error: 'NO_IRQ' 
> undeclared (first use in this function)

introduced by fe761bcb9046029 (net: fsl: expands dependencies of
NET_VENDOR_FREESCALE) which enables build of the Freescale networking
drivers on arm64.  Since in common with many other architectures arm64
does not provide a NO_IRQ (and even those that do aren't consistent) the
driver should be modified to not rely on this and instead check the
return values of the functions it uses to look up interrupts.


signature.asc
Description: PGP signature

[PATCH 2/2] net: fsl: Fix error checking for platform_get_irq()

[Mark Brown]

The gianfar driver has recently been enabled on arm64 but fails to build
since it check the return value of platform_get_irq() against NO_IRQ. Fix
this by instead checking for a negative error code.

Even on ARM where this code was previously being built this check was
incorrect since platform_get_irq() returns a negative error code which
may not be exactly the (unsigned int)(-1) that NO_IRQ is defined to be.

Signed-off-by: Mark Brown <broo...@kernel.org>
---
 drivers/net/ethernet/freescale/gianfar_ptp.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/freescale/gianfar_ptp.c 
b/drivers/net/ethernet/freescale/gianfar_ptp.c
index 664d0c261269..b40fba929d65 100644
--- a/drivers/net/ethernet/freescale/gianfar_ptp.c
+++ b/drivers/net/ethernet/freescale/gianfar_ptp.c
@@ -467,7 +467,7 @@ static int gianfar_ptp_probe(struct platform_device *dev)
 
etsects->irq = platform_get_irq(dev, 0);
 
-   if (etsects->irq == NO_IRQ) {
+   if (etsects->irq < 0) {
pr_err("irq not in device tree\n");
goto no_node;
}
-- 
2.6.2

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: next-20151126 build: 3 failures 15 warnings (next-20151126)

[Mark Brown]

On Thu, Nov 26, 2015 at 09:06:25AM +, Build bot for Mark Brown wrote:

Today's -next fails to build an arm64 allmodconfig due to:

>   arm64-allmodconfig
> ../drivers/net/wireless/ath/ath10k/thermal.c:119:6: error: redefinition of 
> 'ath10k_thermal_event_temperature'
> ../drivers/net/wireless/ath/ath10k/thermal.c:136:6: error: redefinition of 
> 'ath10k_thermal_set_throttling'
> ../drivers/net/wireless/ath/ath10k/thermal.c:162:5: error: redefinition of 
> 'ath10k_thermal_register'
> ../drivers/net/wireless/ath/ath10k/thermal.c:216:6: error: redefinition of 
> 'ath10k_thermal_unregister'

This is happening because there are stub functions provided in the
driver's thermal.h for !THERMAL cases but these are guarded by an #ifdef
not an #if and so fails to do the right thing if the thermal code is
built as a module.  It looks like this was somehow triggered as part of
the reorganisation of the WiFi directory structure.


signature.asc
Description: PGP signature

Re: next-20151126 build: 3 failures 15 warnings (next-20151126)

[Mark Brown]

On Thu, Nov 26, 2015 at 02:39:40PM +0200, Kalle Valo wrote:
> Mark Brown <broo...@kernel.org> writes:

> > It looks like this was somehow triggered as part of the reorganisation
> > of the WiFi directory structure.

> This is surprising and also worrying, any ideas why? It would be good to
> understand the root cause in case there's a bug in wireless drivers
> directory reorganisation.

No, I didn't make much effort to check though since the use of ifdef was
clearly a bug waiting to happen anyway, I was more surprised it worked
at all than anything.


signature.asc
Description: PGP signature

Re: next-20151126 build: 3 failures 15 warnings (next-20151126)

[Mark Brown]

On Thu, Nov 26, 2015 at 06:58:32PM +0200, Kalle Valo wrote:
> Mark Brown <broo...@kernel.org> writes:

> > No, I didn't make much effort to check though since the use of ifdef was
> > clearly a bug waiting to happen anyway, I was more surprised it worked
> > at all than anything.

> Michal Marek explains[1] that this is due to commit cf4f21938e13
> ("kbuild: Allow to specify composite modules with modname-m") and has
> nothing to do with the wireless drivers reorganisation. I'll drop this
> patch as Michal will apply his fix to the kbuild tree.

It still ought to be fixed regardless of why it showed up - the
intention of the code is that we build the real thermal code regardless
of if that's modular or not but that's not what the code actually does.


signature.asc
Description: PGP signature

Re: [PATCH 1/2] regmap: only call custom reg_update_bits() if reg is marked volatile

[Mark Brown]

On Tue, Oct 06, 2015 at 06:25:08AM -0700, David Miller wrote:

> > 4) David should then merge the regmap for-next branch into net-next

> Nope, this doesn't work at all.

> It is my tree which people depend upon, not the other way around.

Yes, it does work - this is the way we normally handle cross tree
issues.  There is nothing about pulling code from other trees into your
tree which will stop other people depending on your tree, obviously
anything you merge in needs to stay fast forward only and ideally not
make any resulting pull requests look terrible but that's really the
only restriction.


signature.asc
Description: Digital signature

Re: [PATCH 1/2] regmap: only call custom reg_update_bits() if reg is marked volatile

[Mark Brown]

On Mon, Oct 05, 2015 at 11:29:56PM -0700, David Miller wrote:
> From: Mark Brown <broo...@kernel.org>

> > Dave, to be clear please do *not* apply this patch at least for the time
> > being - I've not reviewed it or the one from Thursday that you applied
> > this morning.

> It's applied, it's pushed out to my tree, and therefore this will need to
> be fixed up with a relative patch of some sort.

This appears to be an incremental change, not the initial commit which
you already applied.  I'm asking you to stop applying changes to regmap
which have not been reviewed.

> What you don't seem to understand is that my GIT tree is never rebased
> or mangled because many people depend upon it.  So once a patch is
> applied, that commit lives on forever.

I'm not *so* concerned if the patch lives in history, I'm concerned with
having something I can sensibly review and ideally getting the code into
my tree.


signature.asc
Description: Digital signature

Re: [PATCH net-next v2 1/2] regmap: Allow installing custom reg_update_bits function

[Mark Brown]

On Mon, Oct 05, 2015 at 11:21:48PM -0700, David Miller wrote:

> > Ugh, this is a mess :(  Can you please drop this patch instead?

> I can't just "drop" changes.  Once a commit hits my tree it is part
> of the permanent record.

I was expecting a revert if you want to keep the branch fast forward
only.

> The easiest thing to do is to send a relative fix, and that's why
> I have asked for exactly that.

This isn't very good for reviewing the API change, and of course I'd
also expect this change to be in the regmap tree so we can work on
regmap without collisions, I obviously can't just merge in net-next.
I was thinking about making some further changes on top of this and it
*is* fiddling about in the core.

Jon, please send me a patch against the regmap tree for review while we
work out how to sort out this mess.


signature.asc
Description: Digital signature

Re: [PATCH 1/2] regmap: only call custom reg_update_bits() if reg is marked volatile

[Mark Brown]

On Tue, Oct 06, 2015 at 08:50:43AM -0400, Jon Ringle wrote:

> 4) David should then merge the regmap for-next branch into net-next

What I generally do (and what's best practice in general for cross tree
work) is apply patches on topic branches and then create a signed tag
for anything that's being merged into another tree.  That both means
we've got a signed tag for the chain of trust in the code and means that
only the specific dependency gets pulled into other trees rather than
everything that's queued.  Minimising what's pulled in makes pull
requests look cleaner and avoids noise from in development code
appearing in other trees (eg, any bugs in other code that's not quite
ready won't get merged).

In my specific trees nobody should ever merge my for-FOO branches,
they're rebuilt frequently - the topic branches are fast forward only
and intended for that (though like I say a signed tag is best).  Linus
complains about keeping the for-FOO branches fast forward
only.

> 5) I will submit a new patch to net-next for the encx24j600 driver
> that should build against the regmap changes

> Sound like a good plan?

Makes sense to me modulo the signed tag thing above.


signature.asc
Description: Digital signature

Re: [PATCH net-next v3 1/2] regmap: Allow installing custom reg_update_bits function

[Mark Brown]

On Thu, Oct 01, 2015 at 12:38:07PM -0400, j...@ringle.org wrote:
> From: Jon Ringle 
> 
> This commit allows installing a custom reg_update_bits function for cases 
> where
> the hardware provides a mechanism to set or clear register bits without a
> read/modify/write cycle. Such is the case with the Microchip ENCX24J600.

Thanks, I've applied this.  I'll extend it so that individual devices
can do this as well - I've not looked at your driver but it might be
that this is a better option than regmap_bus for your driver (but both
are supported so meh).  Dave, I've tagged the commit and there's a pull
request for this below:

The following changes since commit 6ff33f3902c3b1c5d0db6b1e2c70b6d76fba357f:

  Linux 4.3-rc1 (2015-09-12 16:35:56 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap.git 
tags/regmap-offload-update-bits

for you to fetch changes up to 77792b11409c9270d98e604b4314b85ce886ac7d:

  regmap: Allow installing custom reg_update_bits function (2015-10-06 16:12:34 
+0100)


regmap: Allow buses to provide a custom update_bits() operation

Some buses provide a native _update_bits() operation which for uncached
registers is faster than doing a read/modify/write cycle as it is a
single bus transaction.  Add support for implementing this to regmap.


Jon Ringle (1):
  regmap: Allow installing custom reg_update_bits function

 drivers/base/regmap/internal.h |  2 ++
 drivers/base/regmap/regmap.c   | 29 ++---
 include/linux/regmap.h |  3 +++
 3 files changed, 23 insertions(+), 11 deletions(-)


signature.asc
Description: Digital signature

Re: [PATCH net-next v2 1/2] regmap: Allow installing custom reg_update_bits function

[Mark Brown]

On Mon, Oct 05, 2015 at 06:16:09AM -0700, David Miller wrote:

> >> Applied.

> > Thanks David. However, I've sent a v3 patch, and also expecting feedback 
> > from Mark Brown on the regmap portion of it.

> Please send me relative changes from v2 to v3, thanks.

> Sorry about that.

Ugh, this is a mess :(  Can you please drop this patch instead?


signature.asc
Description: Digital signature

Re: [PATCH 1/2] regmap: only call custom reg_update_bits() if reg is marked volatile

[Mark Brown]

On Mon, Oct 05, 2015 at 09:29:31AM -0400, j...@ringle.org wrote:
> From: Jon Ringle 
> 
> The only time that it makes sense to call a custom provided reg_update_bits
> function, is the register being updated is one that has volatile bits.
> Otherwise, the normal read/modify/write cycle (where the read is likely to
> be free from the cache) will do just fine. This should keep the reg cache
> intact, since volatile registers won't get cached anyway.

Dave, to be clear please do *not* apply this patch at least for the time
being - I've not reviewed it or the one from Thursday that you applied
this morning.


signature.asc
Description: Digital signature

Re: [PATCH 1/2] regmap: Allow installing custom reg_update_bits function

[Mark Brown]

On Thu, Oct 01, 2015 at 08:29:19AM -0400, Jon Ringle wrote:
> On Thu, 1 Oct 2015, Mark Brown wrote:

> > This completely bypasses and therefore breaks the cache infrastructure.

> Right after sending the v2 patch, I realized that calling the 
> custom reg_update_bits would only be applicable for registers that are 
> marked as volatile. Would the following solution be acceptable (it would 

Well, it should still *work* with a cache, though it's certainly true
that it's unlikely to have any performance benefit with cached register
since the read part of the read/modify/write cycle is essentially free 
with the cache.

> also simplify the regmap_update_bits in the encx24j600 driver):

>   if (regmap_volatile(map, reg) && map->reg_update_bits) {
>   return map->reg_update_bits(map->bus_context, reg, mask, 
>   val, change, force_write);

> The cache state should not matter for volatile registers, right?

Right.  I see you've sent a new patch already, I'll reply to that after
I've thought about it a little.


signature.asc
Description: Digital signature

Re: [PATCH 1/2] regmap: Allow installing custom reg_update_bits function

[Mark Brown]

On Thu, Oct 01, 2015 at 02:33:06AM -0400, j...@ringle.org wrote:

> @@ -2509,6 +2510,10 @@ static int _regmap_update_bits(struct regmap *map, 
> unsigned int reg,
>   int ret;
>   unsigned int tmp, orig;
>  
> + if (map->reg_update_bits)
> + return map->reg_update_bits(map->bus_context, reg, mask, val,
> + change, force_write);
> +
>   ret = _regmap_read(map, reg, );
>   if (ret != 0)
>   return ret;

This completely bypasses and therefore breaks the cache infrastructure.


signature.asc
Description: Digital signature

[PATCH] natsemi: Update locking documentation

[Mark Brown]

The documentation regarding synchronisation at the head of the natsemi
driver was badly bitrotted so replace it with a general statement about
the techniques used which is less likely to bitrot.

Also remove the note saying these chips are uncommon - it makes little
difference but they were used in a number of laptops and at least one mass
market PCI ethernet card.

Signed-off-by: Mark Brown [EMAIL PROTECTED]
---
 drivers/net/natsemi.c |   18 ++
 1 files changed, 2 insertions(+), 16 deletions(-)

diff --git a/drivers/net/natsemi.c b/drivers/net/natsemi.c
index c329a4f..0a3e604 100644
--- a/drivers/net/natsemi.c
+++ b/drivers/net/natsemi.c
@@ -203,22 +203,8 @@ skbuff at an offset of +2, 16-byte aligning the IP 
header.
 IIId. Synchronization
 
 Most operations are synchronized on the np-lock irq spinlock, except the
-performance critical codepaths:
-
-The rx process only runs in the interrupt handler. Access from outside
-the interrupt handler is only permitted after disable_irq().
-
-The rx process usually runs under the netif_tx_lock. If np-intr_tx_reap
-is set, then access is permitted under spin_lock_irq(np-lock).
-
-Thus configuration functions that want to access everything must call
-   disable_irq(dev-irq);
-   netif_tx_lock_bh(dev);
-   spin_lock_irq(np-lock);
-
-IV. Notes
-
-NatSemi PCI network controllers are very uncommon.
+recieve and transmit paths which are synchronised using a combination of
+hardware descriptor ownership, disabling interrupts and NAPI poll scheduling.
 
 IVb. References
 
-- 
1.5.3.8

--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] natsemi: Use round_jiffies() for slow timers

[Mark Brown]

Unless we have failed to fill the RX ring the timer used by the natsemi
driver is not particularly urgent and can use round_jiffies() to allow
grouping with other timers.

Signed-off-by: Mark Brown [EMAIL PROTECTED]
---
Rediffed against current netdev-2.6.git#upstream

 drivers/net/natsemi.c |   10 +++---
 1 files changed, 7 insertions(+), 3 deletions(-)

diff --git a/drivers/net/natsemi.c b/drivers/net/natsemi.c
index 527f9dc..b881786 100644
--- a/drivers/net/natsemi.c
+++ b/drivers/net/natsemi.c
@@ -1576,7 +1576,7 @@ static int netdev_open(struct net_device *dev)
 
/* Set the timer to check for link beat. */
init_timer(np-timer);
-   np-timer.expires = jiffies + NATSEMI_TIMER_FREQ;
+   np-timer.expires = round_jiffies(jiffies + NATSEMI_TIMER_FREQ);
np-timer.data = (unsigned long)dev;
np-timer.function = netdev_timer; /* timer handler */
add_timer(np-timer);
@@ -1856,7 +1856,11 @@ static void netdev_timer(unsigned long data)
next_tick = 1;
}
}
-   mod_timer(np-timer, jiffies + next_tick);
+
+   if (next_tick  1)
+   mod_timer(np-timer, round_jiffies(jiffies + next_tick));
+   else
+   mod_timer(np-timer, jiffies + next_tick);
 }
 
 static void dump_ring(struct net_device *dev)
@@ -3331,7 +3335,7 @@ static int natsemi_resume (struct pci_dev *pdev)
spin_unlock_irq(np-lock);
enable_irq(dev-irq);
 
-   mod_timer(np-timer, jiffies + 1*HZ);
+   mod_timer(np-timer, round_jiffies(jiffies + 1*HZ));
}
netif_device_attach(dev);
 out:
-- 
1.5.3.4

-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] natsemi: Check return value for pci_enable_device()

[Mark Brown]

pci_enable_device() is __must_check so do that in natsemi_resume().

Signed-off-by: Mark Brown [EMAIL PROTECTED]
---
 drivers/net/natsemi.c |   10 --
 1 files changed, 8 insertions(+), 2 deletions(-)

diff --git a/drivers/net/natsemi.c b/drivers/net/natsemi.c
index b881786..50e1ec6 100644
--- a/drivers/net/natsemi.c
+++ b/drivers/net/natsemi.c
@@ -3314,13 +3314,19 @@ static int natsemi_resume (struct pci_dev *pdev)
 {
struct net_device *dev = pci_get_drvdata (pdev);
struct netdev_private *np = netdev_priv(dev);
+   int ret = 0;
 
rtnl_lock();
if (netif_device_present(dev))
goto out;
if (netif_running(dev)) {
BUG_ON(!np-hands_off);
-   pci_enable_device(pdev);
+   ret = pci_enable_device(pdev);
+   if (ret  0) {
+   dev_err(pdev-dev,
+   pci_enable_device() failed: %d\n, ret);
+   goto out;
+   }
/*  pci_power_on(pdev); */
 
napi_enable(np-napi);
@@ -3340,7 +3346,7 @@ static int natsemi_resume (struct pci_dev *pdev)
netif_device_attach(dev);
 out:
rtnl_unlock();
-   return 0;
+   return ret;
 }
 
 #endif /* CONFIG_PM */
-- 
1.5.3.4

-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] natsemi: Use NATSEMI_TIMER_FREQ consistently

[Mark Brown]

The natsemi driver has a define NATSEMI_TIMER_FREQ which looks like it
controls the normal frequency of the chip poll timer but in fact only
takes effect for the first run of the timer.  Adjust the value of the
define to match that used by the timer and use the define consistently.

Signed-off-by: Mark Brown [EMAIL PROTECTED]
---
 drivers/net/natsemi.c |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/net/natsemi.c b/drivers/net/natsemi.c
index 0b33a58..1f88604 100644
--- a/drivers/net/natsemi.c
+++ b/drivers/net/natsemi.c
@@ -108,7 +108,7 @@ static int full_duplex[MAX_UNITS];
 #define TX_TIMEOUT  (2*HZ)
 
 #define NATSEMI_HW_TIMEOUT 400
-#define NATSEMI_TIMER_FREQ 3*HZ
+#define NATSEMI_TIMER_FREQ 5*HZ
 #define NATSEMI_PG0_NREGS  64
 #define NATSEMI_RFDR_NREGS 8
 #define NATSEMI_PG1_NREGS  4
@@ -1797,7 +1797,7 @@ static void netdev_timer(unsigned long data)
struct net_device *dev = (struct net_device *)data;
struct netdev_private *np = netdev_priv(dev);
void __iomem * ioaddr = ns_ioaddr(dev);
-   int next_tick = 5*HZ;
+   int next_tick = NATSEMI_TIMER_FREQ;
 
if (netif_msg_timer(np)) {
/* DO NOT read the IntrStatus register,
-- 
1.5.3.4

-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] natsemi: Use round_jiffies() for slow timers

[Mark Brown]

Unless we have failed to fill the RX ring the timer used by the natsemi
driver is not particularly urgent and can use round_jiffies() to allow
grouping with other timers.

Signed-off-by: Mark Brown [EMAIL PROTECTED]
---
 drivers/net/natsemi.c |   10 +++---
 1 files changed, 7 insertions(+), 3 deletions(-)

diff --git a/drivers/net/natsemi.c b/drivers/net/natsemi.c
index b47a12d..0b33a58 100644
--- a/drivers/net/natsemi.c
+++ b/drivers/net/natsemi.c
@@ -1575,7 +1575,7 @@ static int netdev_open(struct net_device *dev)
 
/* Set the timer to check for link beat. */
init_timer(np-timer);
-   np-timer.expires = jiffies + NATSEMI_TIMER_FREQ;
+   np-timer.expires = round_jiffies(jiffies + NATSEMI_TIMER_FREQ);
np-timer.data = (unsigned long)dev;
np-timer.function = netdev_timer; /* timer handler */
add_timer(np-timer);
@@ -1855,7 +1855,11 @@ static void netdev_timer(unsigned long data)
next_tick = 1;
}
}
-   mod_timer(np-timer, jiffies + next_tick);
+
+   if (next_tick  1)
+   mod_timer(np-timer, round_jiffies(jiffies + next_tick));
+   else
+   mod_timer(np-timer, jiffies + next_tick);
 }
 
 static void dump_ring(struct net_device *dev)
@@ -3330,7 +3334,7 @@ static int natsemi_resume (struct pci_dev *pdev)
spin_unlock_irq(np-lock);
enable_irq(dev-irq);
 
-   mod_timer(np-timer, jiffies + 1*HZ);
+   mod_timer(np-timer, round_jiffies(jiffies + 1*HZ));
}
netif_device_attach(dev);
netif_poll_enable(dev);
-- 
1.5.3.4

-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 1/2] natsemi: Improve diagnostics for DspCfg workaround

[Mark Brown]

The natsemi driver has a workaround for broken hardware which resets itself
from time to time.  There is a diagnostic message for this workaround but
it is not printed by default, making the driver behavior more obscure than
it needs to be.  Make the message be displayed by default.

Signed-Off-By: Mark Brown [EMAIL PROTECTED]
---

 drivers/net/natsemi.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/net/natsemi.c b/drivers/net/natsemi.c
index a8d7ff2..109e802 100644
--- a/drivers/net/natsemi.c
+++ b/drivers/net/natsemi.c
@@ -1756,7 +1756,7 @@ static void netdev_timer(unsigned long data)
if (dspcfg != np-dspcfg) {
if (!netif_queue_stopped(dev)) {
spin_unlock_irq(np-lock);
-   if (netif_msg_hw(np))
+   if (netif_msg_drv(np))
printk(KERN_NOTICE %s: possible phy 
reset: 
re-initializing\n, dev-name);
disable_irq(dev-irq);

-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 2/2] Subject: natsemi: Allow users to disable workaround for DspCfg reset

[Mark Brown]

The natsemi driver contains a workaround for broken hardware which can
partially reset the chip at unpredictable times, detected by checking for
spontaneous changes in the DspCfg register.  The effects of the hardware
bug appear to be variable and can range from minor problems like small
numbers of corrupted packets to major ones such as the chip becoming
non-functional.  In the case of minor problems the chip reconfiguration
required to work around the hardware can cause more problems than the bug
itself.

Since we have no way of automatically determining how badly the problem
manifests on any given system provide an option in sysfs allowing users to
disable the workaround at runtime and provides a module option to set the
default.

Signed-Off-By: Mark Brown [EMAIL PROTECTED]
---

 drivers/net/natsemi.c |   68 -
 1 files changed, 66 insertions(+), 2 deletions(-)

diff --git a/drivers/net/natsemi.c b/drivers/net/natsemi.c
index 109e802..223e0e6 100644
--- a/drivers/net/natsemi.c
+++ b/drivers/net/natsemi.c
@@ -81,6 +81,8 @@ static const int multicast_filter_limit = 100;
Setting to  1518 effectively disables this feature. */
 static int rx_copybreak;
 
+static int dspcfg_workaround = 1;
+
 /* Used to pass the media type, etc.
Both 'options[]' and 'full_duplex[]' should exist for driver
interoperability.
@@ -139,12 +141,14 @@ MODULE_LICENSE(GPL);
 module_param(mtu, int, 0);
 module_param(debug, int, 0);
 module_param(rx_copybreak, int, 0);
+module_param(dspcfg_workaround, int, 1);
 module_param_array(options, int, NULL, 0);
 module_param_array(full_duplex, int, NULL, 0);
 MODULE_PARM_DESC(mtu, DP8381x MTU (all boards));
 MODULE_PARM_DESC(debug, DP8381x default debug level);
 MODULE_PARM_DESC(rx_copybreak,
DP8381x copy breakpoint for copy-only-tiny-frames);
+MODULE_PARM_DESC(dspcfg_workaround, DP8381x: control DspCfg workaround);
 MODULE_PARM_DESC(options,
DP8381x: Bits 0-3: media type, bit 17: full duplex);
 MODULE_PARM_DESC(full_duplex, DP8381x full duplex setting(s) (1));
@@ -590,6 +594,7 @@ struct netdev_private {
u32 srr;
/* expected DSPCFG value */
u16 dspcfg;
+   int dspcfg_workaround;
/* parms saved in ethtool format */
u16 speed;  /* The forced speed, 10Mb, 100Mb, gigabit */
u8  duplex; /* Duplex, half or full */
@@ -656,6 +661,56 @@ static int netdev_get_regs(struct net_device *dev, u8 
*buf);
 static int netdev_get_eeprom(struct net_device *dev, u8 *buf);
 static const struct ethtool_ops ethtool_ops;
 
+#define NATSEMI_ATTR(_name) \
+static ssize_t natsemi_show_##_name(struct device *dev, \
+ struct device_attribute *attr, char *buf); \
+static ssize_t natsemi_set_##_name(struct device *dev, \
+   struct device_attribute *attr, \
+   const char *buf, size_t count); \
+static DEVICE_ATTR(_name, 0644, natsemi_show_##_name, 
natsemi_set_##_name)
+
+#define NATSEMI_CREATE_FILE(_dev, _name) \
+ device_create_file(_dev-dev, dev_attr_##_name)
+#define NATSEMI_REMOVE_FILE(_dev, _name) \
+ device_create_file(_dev-dev, dev_attr_##_name)
+
+NATSEMI_ATTR(dspcfg_workaround);
+
+static ssize_t natsemi_show_dspcfg_workaround(struct device *dev,
+ struct device_attribute *attr, 
+ char *buf)
+{
+   struct netdev_private *np = netdev_priv(to_net_dev(dev));
+
+   return sprintf(buf, %s\n, np-dspcfg_workaround ? on : off);
+}
+
+static ssize_t natsemi_set_dspcfg_workaround(struct device *dev,
+struct device_attribute *attr,
+const char *buf, size_t count)
+{
+   struct netdev_private *np = netdev_priv(to_net_dev(dev));
+   int new_setting;
+   u32 flags;
+
+/* Find out the new setting */
+if (!strncmp(on, buf, count - 1) || !strncmp(1, buf, count - 1))
+new_setting = 1;
+else if (!strncmp(off, buf, count - 1)
+ || !strncmp(0, buf, count - 1))
+   new_setting = 0;
+   else
+ return count; 
+
+   spin_lock_irqsave(np-lock, flags);
+
+   np-dspcfg_workaround = new_setting;
+
+   spin_unlock_irqrestore(np-lock, flags);
+
+   return count;
+}
+
 static inline void __iomem *ns_ioaddr(struct net_device *dev)
 {
return (void __iomem *) dev-base_addr;
@@ -820,6 +875,7 @@ static int __devinit natsemi_probe1 (struct pci_dev *pdev,
np-ignore_phy = 1;
else
np-ignore_phy = 0;
+   np-dspcfg_workaround = dspcfg_workaround;
 
/* Initial port:
 * - If configured to ignore the PHY set up for external.
@@ -899,6 +955,9 @@ static int __devinit natsemi_probe1 (struct pci_dev *pdev,
if (i)
goto err_register_netdev

[PATCH 0/2] natsemi: Improve DspCfg workaround

[Mark Brown]

The natsemi driver contains a workaround for broken hardware which can
on some boards cause more problems than it solves.  The following patch
series improves this by making the diagnostic more obvious and allowing
users to disable the workaround if it causes them problems.

-- 
You grabbed my hand and we fell into it, like a daydream - or a fever.
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Natsemi DP83815 driver spaming

[Mark Brown]

On Tue, May 01, 2007 at 11:51:41PM -0700, Tim Hockin wrote:

 I'm not sure what the right answer is.  The code was designed to do
 the right thing, and yet in your case it's broken.  Does it need to be
 a build option to work around broken hardware?  Yuck.

Without a system that really needs the original problem that was being
worked around it's going to be hard to see if the workaround still does
the job.  Given the nature of the failure I wouldn't be surprised if it
broke different things on every board that has problems.

How about a sysfs tuneable?  It's not nice but at least it's runtime.

-- 
You grabbed my hand and we fell into it, like a daydream - or a fever.


signature.asc
Description: Digital signature

Re: Natsemi DP83815 driver spaming

[Mark Brown]

On Wed, May 02, 2007 at 10:05:31PM +0200, Rafał Bilski wrote:

 What about module option?

That would work, though you crossed in the post with me writing a patch
adding a sysfs file; I merged the two for overkill (below).  I also have
a patch which changes the log message for the workaround so that it is
displayed by default in order to make this easier to diagnose.

diff --git a/drivers/net/natsemi.c b/drivers/net/natsemi.c
index 109e802..b9f3ab3 100644
--- a/drivers/net/natsemi.c
+++ b/drivers/net/natsemi.c
@@ -81,6 +81,8 @@ static const int multicast_filter_limit = 100;
Setting to  1518 effectively disables this feature. */
 static int rx_copybreak;
 
+static int dspcfg_workaround = 1;
+
 /* Used to pass the media type, etc.
Both 'options[]' and 'full_duplex[]' should exist for driver
interoperability.
@@ -139,12 +141,14 @@ MODULE_LICENSE(GPL);
 module_param(mtu, int, 0);
 module_param(debug, int, 0);
 module_param(rx_copybreak, int, 0);
+module_param(dspcfg_workaround, int, 1);
 module_param_array(options, int, NULL, 0);
 module_param_array(full_duplex, int, NULL, 0);
 MODULE_PARM_DESC(mtu, DP8381x MTU (all boards));
 MODULE_PARM_DESC(debug, DP8381x default debug level);
 MODULE_PARM_DESC(rx_copybreak,
DP8381x copy breakpoint for copy-only-tiny-frames);
+MODULE_PARM_DESC(dspcfg_workaround, DP8381x: control DspCfg workaround);
 MODULE_PARM_DESC(options,
DP8381x: Bits 0-3: media type, bit 17: full duplex);
 MODULE_PARM_DESC(full_duplex, DP8381x full duplex setting(s) (1));
@@ -590,6 +594,7 @@ struct netdev_private {
u32 srr;
/* expected DSPCFG value */
u16 dspcfg;
+   int dspcfg_workaround;
/* parms saved in ethtool format */
u16 speed;  /* The forced speed, 10Mb, 100Mb, gigabit */
u8  duplex; /* Duplex, half or full */
@@ -656,6 +661,56 @@ static int netdev_get_regs(struct net_device *dev, u8 
*buf);
 static int netdev_get_eeprom(struct net_device *dev, u8 *buf);
 static const struct ethtool_ops ethtool_ops;
 
+#define NATSEMI_ATTR(_name) \
+static ssize_t natsemi_show_##_name(struct device *dev, \
+ struct device_attribute *attr, char *buf); \
+static ssize_t natsemi_set_##_name(struct device *dev, \
+   struct device_attribute *attr, \
+   const char *buf, size_t count); \
+static DEVICE_ATTR(_name, 0644, natsemi_show_##_name, 
natsemi_set_##_name)
+
+#define NATSEMI_CREATE_FILE(_dev, _name) \
+ device_create_file(_dev-dev, dev_attr_##_name)
+#define NATSEMI_REMOVE_FILE(_dev, _name) \
+ device_create_file(_dev-dev, dev_attr_##_name)
+
+NATSEMI_ATTR(dspcfg_workaround);
+
+static ssize_t natsemi_show_dspcfg_workaround(struct device *dev,
+ struct device_attribute *attr, 
+ char *buf)
+{
+   struct netdev_private *np = netdev_priv(to_net_dev(dev));
+
+   return sprintf(buf, %s\n, np-dspcfg_workaround ? on : off);
+}
+
+static ssize_t natsemi_set_dspcfg_workaround(struct device *dev,
+struct device_attribute *attr,
+const char *buf, size_t count)
+{
+   struct netdev_private *np = netdev_priv(to_net_dev(dev));
+   int new_setting;
+   u32 flags;
+
+/* Find out the new setting */
+if (!strncmp(on, buf, count - 1) || !strncmp(1, buf, count - 1))
+new_setting = 1;
+else if (!strncmp(off, buf, count - 1)
+ || !strncmp(0, buf, count - 1))
+   new_setting = 0;
+   else
+ return count; 
+
+   spin_lock_irqsave(np-lock, flags);
+
+   np-dspcfg_workaround = new_setting;
+
+   spin_unlock_irqrestore(np-lock, flags);
+
+   return count;
+}
+
 static inline void __iomem *ns_ioaddr(struct net_device *dev)
 {
return (void __iomem *) dev-base_addr;
@@ -820,6 +875,7 @@ static int __devinit natsemi_probe1 (struct pci_dev *pdev,
np-ignore_phy = 1;
else
np-ignore_phy = 0;
+   np-dspcfg_workaround = dspcfg_workaround;
 
/* Initial port:
 * - If configured to ignore the PHY set up for external.
@@ -899,6 +955,9 @@ static int __devinit natsemi_probe1 (struct pci_dev *pdev,
if (i)
goto err_register_netdev;
 
+   if (!NATSEMI_CREATE_FILE(pdev, dspcfg_workaround))
+   goto err_create_file;
+
if (netif_msg_drv(np)) {
printk(KERN_INFO natsemi %s: %s at %#08lx (%s), ,
dev-name, natsemi_pci_info[chip_idx].name, iostart,
@@ -915,6 +974,9 @@ static int __devinit natsemi_probe1 (struct pci_dev *pdev,
}
return 0;
 
+ err_create_file:
+   unregister_netdev(dev);
+
  err_register_netdev:
iounmap(ioaddr);
 
@@ -1727,7 +1789,8 @@ static void init_registers(struct net_device *dev)
  *It seems that 

Re: Natsemi DP83815 driver spaming

[Mark Brown]

On Mon, Apr 30, 2007 at 08:55:22PM -0700, Andrew Morton wrote:
 On Mon, 30 Apr 2007 22:58:47 +0200 Rafał Bilski [EMAIL PROTECTED] wrote:
   ezri user.info kernel: eth0: DSPCFG accepted after 0 usec.
   ezri user.notice kernel: eth0: Wake-up event 0x8a
   ezri user.info kernel: eth0: Setting full-duplex based on negotiated link 
   capability.

Could you please run ethtool -s eth0 msglvl 0x to turn logging
from the driver right up and send a log?  This will spam the log if
there is any traffic but should say why the driver is doing this.

 It seems to be repeatedly setting the same duplex setting.  The closest
 thing I can see in there in recent times is
 68c90166e4aaa15ddcdd4778ad30bfb8b32534be, Add support for using MII port
 with no PHY.

It's not just setting the same duplex setting, the WoL message indicates
that it's doing that as part of init_registers() which should only be
happening in error handling paths and during resume or open.

-- 
You grabbed my hand and we fell into it, like a daydream - or a fever.


signature.asc
Description: Digital signature

Re: Natsemi DP83815 driver spaming

[Mark Brown]

On Tue, May 01, 2007 at 12:25:20PM +0200, Rafał Bilski wrote:

 eth0: Media selection timer tick.
 eth0: possible phy reset: re-initializing

This is why the reset is being triggered - it's a workaround for a hardware
bug which checks to make sure the hardware is in the state that the
kernel thinks it is is going off.  The code has this explanatory comment:

 * 2) check for sudden death of the NIC:
 *It seems that a reference set for this chip went out with incorrect info,
 *and there exist boards that aren't quite right.  An unexpected voltage
 *drop can cause the PHY to get itself in a weird state (basically reset).
 *NOTE: this only seems to affect revC chips.

I'd suggest checking your power supply as a first step.

[BTW, as Andrew said please don't drop people from the CC.]

-- 
You grabbed my hand and we fell into it, like a daydream - or a fever.


signature.asc
Description: Digital signature

Re: Natsemi DP83815 driver spaming

[Mark Brown]

On Tue, May 01, 2007 at 09:52:30PM +0200, Rafał Bilski wrote:

   * 2) check for sudden death of the NIC:
   *It seems that a reference set for this chip went out with incorrect 
  info,
   *and there exist boards that aren't quite right.  An unexpected voltage
   *drop can cause the PHY to get itself in a weird state (basically 
  reset).
   *NOTE: this only seems to affect revC chips.

 Code commented out and NIC is working OK. Strange.
 eth0: DSPCFG accepted after 0 usec.
 eth0: link up.
 eth0: Setting full-duplex based on negotiated link capability.
 dspcfg = 0x  np-dspcfg = 0x5060

Oh, that's entertaining.  I have to confess that I've never seen an that
triggered the workaround before - adding the maintainer, Tim Hockin, who
may be able to shed some light on the expected behaviour here?

-- 
You grabbed my hand and we fell into it, like a daydream - or a fever.


signature.asc
Description: Digital signature

Re: [PATCH] natsemi: netpoll fixes

[Mark Brown]

On Tue, Mar 13, 2007 at 04:53:54PM +0300, Sergei Shtylyov wrote:
 Mark Brown wrote:

 confused and eventually locks up.  Before locking up it will usually
 report one or more oversided packets so this is a useful hint that we
 should reset the recieve state machine in order to recover from this.

That's all good by why we need to completely lose TX and other interrupts
 in the meantime? High inbound traffic doesn't necessarily mean a high 
 outbound one, does it?

While the code in the driver can cope if the chip takes a while to
respond to the reset as far as I have been able to tell in testing 
it does so close enough to immediately to avoid repeating the loop at
all.  The effect on transmit processing should be minimal.

-- 
You grabbed my hand and we fell into it, like a daydream - or a fever.


signature.asc
Description: Digital signature

Re: [PATCH] natsemi: netpoll fixes

[Mark Brown]

On Mon, Mar 12, 2007 at 04:05:48PM +0300, Sergei Shtylyov wrote:
 Mark Brown wrote:

 hands_off is stronger than that - it's used for sync with some of the
 other code paths like suspend/resume and means don't touch the chip.
 I've added a new driver local flag instead.

I'm not sure it was worth it -- we already had __LINK_STATE_RX_SCHED...

It would be nice but as well as being a general layering violation it
could cause problems when trying to quiesce the hardware since
netif_poll_disable() sets this without actually scheduling the poll.

   Yeah, it seems currently unjustified.  However IntrEnable would have 
   been an ultimate criterion on taking or ignoring an interrupt 
   otherwise...

I guess the tradeoff depends on the probability
of getting the isr called when NAPI is active for the device.

I mean I didn't understand why there's tradeoff and how it depends on 
the probability...

Reading device registers means going over the PCI bus, which is
expensive.  Shadowing the interrupt mask state in the driver makes
the driver more complicated but means that we avoid synchronous PCI
accesses, reducing the number of cycles the CPU spends stalled doing
those.

The performance benefit from the extra code complexity depends on how
often we end up doing the extra read.  Since one of the things NAPI does
is provide some interrupt mitigation the extra work is most likely to be
noticable if some other device is generating interrupts that trigger the
natsemi interrupt handler.

 Moving netdev_rx() would fix that one but there's some others too -
 there's one in the timer routine if the chip crashes.  In the case you

Erm, sorry, I'm not seeing it -- could you point with finger please? 
:-)

In netdev_timer() when the device is using PORT_TP if the DspCfg read
back from the chip differs from the one we think we programmed into it
then the driver thinks the PHY fell over.  It then goes through an init
sequence, including init_registers() which will reset IntrEnable among
other things.

 describe above the consequences shouldn't be too bad since it tends to
 only occur at high volume so further traffic will tend to occur and
 cause things to recover - all the testing of that patch was done with
 the bug present and no ill effects.

Oversized packets occur only at high volume? Is it some errata?

It's an errata - AN 1287 which you can get from the National web site.
It's not actually that chip that's getting oversided packets, what
happens is that the state machine which reads data off the wire gets
confused and eventually locks up.  Before locking up it will usually
report one or more oversided packets so this is a useful hint that we
should reset the recieve state machine in order to recover from this.

(If I only knew somebody else was working on that issue, it could have 
 saved my cycles, sigh... but well, I should have said  that I was going to 
 recast the patch. :-)

Yeah, me too.  I'll submit this one once I've finished testing, then
audit other IntrStatus accesses.

 -   readl(ioaddr + IntrMask));
 +spin_lock_irqsave(np-intr_lock, flags);

Yeah, I've suspected that we need to grab np-lock here... but does that 
 separate spinlock actually protect us from anything?

...

 +/* We need to ensure that the ISR doesn't run between telling
 + * NAPI we're done and enabling the interrupt. */
 
Why? :-O

This is to ensure that the interrupt handler can't run between us
marking that the poll has complete and reenabling the interrupt from the
chip.  That would mean that the chip would end up with interrupts from
the chip enabled while the poll is scheduled.

-- 
You grabbed my hand and we fell into it, like a daydream - or a fever.


signature.asc
Description: Digital signature

Re: [PATCH] natsemi: netpoll fixes

[Mark Brown]

On Mon, Mar 12, 2007 at 12:05:46PM -0700, Mark Huth wrote:

 Since the interrupts are enabled as the NAPI-callback exits, and the 
 interrupts are disabled in the isr after the callback is scheduled, this 
 fully avoids the potential race conditions, and requires no locking.  If 

I've benchmarked both approaches and they appear to be much of a
muchness for performance in my tests so I've updated my patch to use
this approach instead.  Thanks for the suggestion, it is simpler.

 If you would like me to prepare formal patches based on any of these 
 concepts, let me know.

That's OK - unless any further suggestions I'll submit the patch below
after further testing.  The improvements to trace and correctness of the
interupt handler seem useful.

Subject: natsemi: Fix NAPI for interrupt sharing

The interrupt status register for the natsemi chips is clear on read and
was read unconditionally from both the interrupt and from the NAPI poll
routine, meaning that if the interrupt service routine was called (for 
example, due to a shared interrupt) while a NAPI poll was scheduled
interrupts could be missed.  This patch fixes that by ensuring that the
interrupt status register is only read by the interrupt handler when
interrupts are enabled from the chip.

It also reverts a workaround for this problem from the netpoll hook and
improves the trace for interrupt events.

Thanks to Sergei Shtylyov [EMAIL PROTECTED] for spotting the
issue, Mark Huth [EMAIL PROTECTED] for a simpler method and Simon
Blake [EMAIL PROTECTED] for testing resources.

Signed-Off-By: Mark Brown [EMAIL PROTECTED]

Index: linux-2.6/drivers/net/natsemi.c
===
--- linux-2.6.orig/drivers/net/natsemi.c2007-03-11 02:32:43.0 
+
+++ linux-2.6/drivers/net/natsemi.c 2007-03-13 00:12:29.0 +
@@ -2119,10 +2119,12 @@
struct netdev_private *np = netdev_priv(dev);
void __iomem * ioaddr = ns_ioaddr(dev);
 
-   if (np-hands_off)
+   /* Reading IntrStatus automatically acknowledges so don't do
+* that while interrupts are disabled, (for example, while a
+* poll is scheduled).  */
+   if (np-hands_off || !readl(ioaddr + IntrEnable))
return IRQ_NONE;
 
-   /* Reading automatically acknowledges. */
np-intr_status = readl(ioaddr + IntrStatus);
 
if (netif_msg_intr(np))
@@ -2131,17 +2133,23 @@
   dev-name, np-intr_status,
   readl(ioaddr + IntrMask));
 
-   if (!np-intr_status)
-   return IRQ_NONE;
-
-   prefetch(np-rx_skbuff[np-cur_rx % RX_RING_SIZE]);
+   if (np-intr_status) {
+   prefetch(np-rx_skbuff[np-cur_rx % RX_RING_SIZE]);
 
-   if (netif_rx_schedule_prep(dev)) {
/* Disable interrupts and register for poll */
-   natsemi_irq_disable(dev);
-   __netif_rx_schedule(dev);
+   if (netif_rx_schedule_prep(dev)) {
+   natsemi_irq_disable(dev);
+   __netif_rx_schedule(dev);
+   } else
+   printk(KERN_WARNING
+  %s: Ignoring interrupt, status %#08x, mask 
%#08x.\n,
+  dev-name, np-intr_status,
+  readl(ioaddr + IntrMask));
+
+   return IRQ_HANDLED;
}
-   return IRQ_HANDLED;
+
+   return IRQ_NONE;
 }
 
 /* This is the NAPI poll routine.  As well as the standard RX handling
@@ -2156,6 +2164,12 @@
int work_done = 0;
 
do {
+   if (netif_msg_intr(np))
+   printk(KERN_DEBUG
+  %s: Poll, status %#08x, mask %#08x.\n,
+  dev-name, np-intr_status,
+  readl(ioaddr + IntrMask));
+
if (np-intr_status 
(IntrTxDone | IntrTxIntr | IntrTxIdle | IntrTxErr)) {
spin_lock(np-lock);
@@ -2399,19 +2413,8 @@
 #ifdef CONFIG_NET_POLL_CONTROLLER
 static void natsemi_poll_controller(struct net_device *dev)
 {
-   struct netdev_private *np = netdev_priv(dev);
-
disable_irq(dev-irq);
-
-   /*
-* A real interrupt might have already reached us at this point
-* but NAPI might still haven't called us back.  As the interrupt
-* status register is cleared by reading, we should prevent an
-* interrupt loss in this case...
-*/
-   if (!np-intr_status)
-   intr_handler(dev-irq, dev);
-
+   intr_handler(dev-irq, dev);
enable_irq(dev-irq);
 }
 #endif

-- 
You grabbed my hand and we fell into it, like a daydream - or a fever.


signature.asc
Description: Digital signature

Re: [PATCH] natsemi: netpoll fixes

[Mark Brown]

On Sat, Mar 10, 2007 at 11:25:05PM +0300, Sergei Shtylyov wrote:

Oops, I was going to recast the patch but my attention switched 
elsewhere for couple of days, and it slipped into mainline. I'm now 
 preparing a better patch to also protect...

Ah, I was also looking at it.  I enclose my current patch which appears
to work although I have not finished testing it yet.

 interrupt handler, check the dev-state __LINK_STATE_SCHED flag - if 
 it's set, leave immediately, it can't be our interrupt. If it's clear, 
 read the irq enable hardware register.  If enabled, do the rest of the 
 interrupt handler.

It seems that there's no need to read it, as it gets set to 0 
 synchronously with setting the 'hands_off' flag (except in NAPI 
 callback)...

hands_off is stronger than that - it's used for sync with some of the
other code paths like suspend/resume and means don't touch the chip.
I've added a new driver local flag instead.

Yeah, it seems currently unjustified.  However IntrEnable would have 
been an ultimate criterion on taking or ignoring an interrupt otherwise...

 I guess the tradeoff depends on the probability 
 of getting the isr called when NAPI is active for the device.

Didn't get it... :-/

Some systems can provoke this fairly easily - Sokeris have some boards
where at least three natsemis share a single interrupt line, for example
(the model I'm looking at has three, they look to have another
configuration where 5 would end up on the line).

BTW, it seems I've found another interrupt lossage path in the driver:

 netdev_poll() - netdev_rx() - reset_rx()

 If the netdev_rx() detects an oversized packet, it will call reset_rx() 
 which will spin in a loop collecting interrupt status until it sees 
 RxResetDone there.  The issue is 'intr_status' field will get overwritten 
 and interrupt status lost after netdev_rx() returns to netdev_poll().  How 
 do you think, is this corner case worth fixing (by moving netdev_rx() call
 to the top of a do/while loop)?

Moving netdev_rx() would fix that one but there's some others too -
there's one in the timer routine if the chip crashes.  In the case you
describe above the consequences shouldn't be too bad since it tends to
only occur at high volume so further traffic will tend to occur and
cause things to recover - all the testing of that patch was done with
the bug present and no ill effects.

Subject: natsemi: Fix NAPI for interrupt sharing
To: Jeff Garzik [EMAIL PROTECTED]
Cc: Sergei Shtylyov [EMAIL PROTECTED], Simon Blake [EMAIL PROTECTED], John 
Philips [EMAIL PROTECTED], netdev@vger.kernel.org

The interrupt status register for the natsemi chips is clear on read and
was read unconditionally from both the interrupt and from the NAPI poll
routine, meaning that if the interrupt service routine was called (for 
example, due to a shared interrupt) while a NAPI poll was scheduled
interrupts could be missed.  This patch fixes that by ensuring that the
interrupt status register is only read when there is no poll scheduled.

It also reverts a workaround for this problem from the netpoll hook.

Thanks to Sergei Shtylyov [EMAIL PROTECTED] for spotting the
issue and Simon Blake [EMAIL PROTECTED] for testing resources.

Signed-Off-By: Mark Brown [EMAIL PROTECTED]

Index: linux-2.6/drivers/net/natsemi.c
===
--- linux-2.6.orig/drivers/net/natsemi.c2007-03-11 02:32:43.0 
+
+++ linux-2.6/drivers/net/natsemi.c 2007-03-11 12:09:14.0 +
@@ -571,6 +571,8 @@
int oom;
/* Interrupt status */
u32 intr_status;
+   int poll_active;
+   spinlock_t intr_lock;
/* Do not touch the nic registers */
int hands_off;
/* Don't pay attention to the reported link state. */
@@ -812,9 +814,11 @@
pci_set_drvdata(pdev, dev);
np-iosize = iosize;
spin_lock_init(np-lock);
+   spin_lock_init(np-intr_lock);
np-msg_enable = (debug = 0) ? (1debug)-1 : NATSEMI_DEF_MSG;
np-hands_off = 0;
np-intr_status = 0;
+   np-poll_active = 0;
np-eeprom_size = natsemi_pci_info[chip_idx].eeprom_size;
if (natsemi_pci_info[chip_idx].flags  NATSEMI_FLAG_IGNORE_PHY)
np-ignore_phy = 1;
@@ -1406,6 +1410,8 @@
writel(rfcr, ioaddr + RxFilterAddr);
 }
 
+/* MUST be called so that both NAPI poll and ISR are excluded due to
+ * use of intr_status. */
 static void reset_rx(struct net_device *dev)
 {
int i;
@@ -2118,30 +2124,45 @@
struct net_device *dev = dev_instance;
struct netdev_private *np = netdev_priv(dev);
void __iomem * ioaddr = ns_ioaddr(dev);
+   unsigned long flags;
+   irqreturn_t status = IRQ_NONE;
 
if (np-hands_off)
return IRQ_NONE;
 
-   /* Reading automatically acknowledges. */
-   np-intr_status = readl(ioaddr + IntrStatus);
-
-   if (netif_msg_intr(np

Re: [PATCH] natsemi: netpoll fixes

[Mark Brown]

On Tue, Mar 06, 2007 at 12:10:08AM +0400, Sergei Shtylyov wrote:

  #ifdef CONFIG_NET_POLL_CONTROLLER
  static void natsemi_poll_controller(struct net_device *dev)
  {
 + struct netdev_private *np = netdev_priv(dev);
 +
   disable_irq(dev-irq);
 - intr_handler(dev-irq, dev);
 +
 + /*
 +  * A real interrupt might have already reached us at this point
 +  * but NAPI might still haven't called us back.  As the interrupt
 +  * status register is cleared by reading, we should prevent an
 +  * interrupt loss in this case...
 +  */
 + if (!np-intr_status)
 + intr_handler(dev-irq, dev);
 +
   enable_irq(dev-irq);

Is it possible for this to run at the same time as the NAPI poll?  If so
then it is possible for the netpoll poll to run between np-intr_status
being cleared and netif_rx_complete() being called.  If the hardware
asserts an interrupt at the wrong moment then this could cause the 

In any case, this is a problem independently of netpoll if the chip
shares an interrupt with anything so the interrupt handler should be
fixed to cope with this situation instead.

-- 
You grabbed my hand and we fell into it, like a daydream - or a fever.


signature.asc
Description: Digital signature

Re: [PATCH] natsemi: netpoll fixes

[Mark Brown]

[Once more with CCs]

On Tue, Mar 06, 2007 at 12:10:08AM +0400, Sergei Shtylyov wrote:

  #ifdef CONFIG_NET_POLL_CONTROLLER
  static void natsemi_poll_controller(struct net_device *dev)
  {
 + struct netdev_private *np = netdev_priv(dev);
 +
   disable_irq(dev-irq);
 - intr_handler(dev-irq, dev);
 +
 + /*
 +  * A real interrupt might have already reached us at this point
 +  * but NAPI might still haven't called us back.  As the
 interrupt
 +  * status register is cleared by reading, we should prevent an
 +  * interrupt loss in this case...
 +  */
 + if (!np-intr_status)
 + intr_handler(dev-irq, dev);
 +
   enable_irq(dev-irq);

Is it possible for this to run at the same time as the NAPI poll?  If so
then it is possible for the netpoll poll to run between np-intr_status
being cleared and netif_rx_complete() being called.  If the hardware
asserts an interrupt at the wrong moment then this could cause the

In any case, this is a problem independently of netpoll if the chip
shares an interrupt with anything so the interrupt handler should be
fixed to cope with this situation instead.

--
You grabbed my hand and we fell into it, like a daydream - or a fever.


signature.asc
Description: Digital signature

natsemi: Fix detection of vanilla natsemi cards

[Mark Brown]

Bob Tracy [EMAIL PROTECTED] reported that the addition of support
for Aculab E1/T1 cPCI carrier cards broke detection of vanilla natsemi
cards.  This patch fixes that: the problem is that the driver-specific
ta in the PCI device table is an index into a second table and this
had not been updated for the vanilla cards.

This patch fixes the problem minimally.

Signed-Off-By: Mark Brown [EMAIL PROTECTED]

--- linux.orig/drivers/net/natsemi.c2007-02-23 11:13:03.0 +
+++ linux/drivers/net/natsemi.c 2007-02-23 11:12:00.0 +
@@ -260,7 +260,7 @@
 
 static const struct pci_device_id natsemi_pci_tbl[] __devinitdata = {
{ PCI_VENDOR_ID_NS, 0x0020, 0x12d9, 0x000c, 0, 0, 0 },
-   { PCI_VENDOR_ID_NS, 0x0020, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0 },
+   { PCI_VENDOR_ID_NS, 0x0020, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 1 },
{ } /* terminate list */
 };
 MODULE_DEVICE_TABLE(pci, natsemi_pci_tbl);

-- 
You grabbed my hand and we fell into it, like a daydream - or a fever.
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

natsemi: Fix detection of vanilla natsemi cards

[Mark Brown]

Bob Tracy [EMAIL PROTECTED] reported that the addition of support
for Aculab E1/T1 cPCI carrier cards broke detection of vanilla natsemi
cards.  This patch fixes that: the problem is that the driver-specific
data in the PCI device table is an index into a second table and this
had not been updated for the vanilla cards.

This patch fixes the problem minimally.

Signed-Off-By: Mark Brown [EMAIL PROTECTED]

--- linux.orig/drivers/net/natsemi.c2007-02-23 11:13:03.0 +
+++ linux/drivers/net/natsemi.c 2007-02-23 11:12:00.0 +
@@ -260,7 +260,7 @@
 
 static const struct pci_device_id natsemi_pci_tbl[] __devinitdata = {
{ PCI_VENDOR_ID_NS, 0x0020, 0x12d9, 0x000c, 0, 0, 0 },
-   { PCI_VENDOR_ID_NS, 0x0020, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0 }
+   { PCI_VENDOR_ID_NS, 0x0020, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 1 },
{ } /* terminate list */
 };
 MODULE_DEVICE_TABLE(pci, natsemi_pci_tbl);

-- 
You grabbed my hand and we fell into it, like a daydream - or a fever.
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: natsemi: Fix detection of vanilla natsemi cards

[Mark Brown]

On Fri, Feb 23, 2007 at 07:47:40AM -0600, Bob Tracy wrote:

 ACK except for a missing comma at the end of the line being replaced,
 which prevents the patch from applying cleanly.  Otherwise, this fixes
 the problem I was having.  Thanks!

Aargh.

--- linux.orig/drivers/net/natsemi.c2007-02-23 11:13:03.0 +
+++ linux/drivers/net/natsemi.c 2007-02-23 11:12:00.0 +
@@ -260,7 +260,7 @@
 
 static const struct pci_device_id natsemi_pci_tbl[] __devinitdata = {
{ PCI_VENDOR_ID_NS, 0x0020, 0x12d9, 0x000c, 0, 0, 0 },
-   { PCI_VENDOR_ID_NS, 0x0020, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0 },
+   { PCI_VENDOR_ID_NS, 0x0020, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 1 },
{ } /* terminate list */
 };
 MODULE_DEVICE_TABLE(pci, natsemi_pci_tbl);

-- 
You grabbed my hand and we fell into it, like a daydream - or a fever.
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[patch 0/2] natsemi: Support Aculab E1/T1 cPCI carrier cards

[Mark Brown]

These patches add support for the Aculab E1/T1 cPCI carrier card to the
natsemi driver.  The first patch provides support for using the MII port
with no PHY and the second adds the quirks required to detect and
configure the card.

This revision should address the issues raised by Jeff over the weekend.
Apologies if I've missed anything.

--
You grabbed my hand and we fell into it, like a daydream - or a fever.
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[patch 2/2] natsemi: Support Aculab E1/T1 PMXc cPCI carrier cards

[Mark Brown]

Aculab E1/T1 PMXc cPCI carrier card cards present a natsemi on the cPCI
bus with an oversized EEPROM using a direct MII-MII connection with no
PHY.  This patch adds a new device table entry supporting these cards.

Signed-Off-By: Mark Brown [EMAIL PROTECTED]

---

This revision removes extra braces from the previous version.

Index: linux/drivers/net/natsemi.c
===
--- linux.orig/drivers/net/natsemi.c2007-02-19 10:16:50.0 +
+++ linux/drivers/net/natsemi.c 2007-02-19 10:18:25.0 +
@@ -244,6 +244,9 @@
MII_EN_SCRM = 0x0004,   /* enable scrambler (tp) */
 };
 
+enum {
+   NATSEMI_FLAG_IGNORE_PHY = 0x1,
+};
 
 /* array of board data directly indexed by pci_tbl[x].driver_data */
 static const struct {
@@ -251,10 +254,12 @@
unsigned long flags;
unsigned int eeprom_size;
 } natsemi_pci_info[] __devinitdata = {
+   { Aculab E1/T1 PMXc cPCI carrier card, NATSEMI_FLAG_IGNORE_PHY, 128 },
{ NatSemi DP8381[56], 0, 24 },
 };
 
 static const struct pci_device_id natsemi_pci_tbl[] __devinitdata = {
+   { PCI_VENDOR_ID_NS, 0x0020, 0x12d9, 0x000c, 0, 0, 0 },
{ PCI_VENDOR_ID_NS, 0x0020, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0 },
{ } /* terminate list */
 };
@@ -811,7 +816,10 @@
np-hands_off = 0;
np-intr_status = 0;
np-eeprom_size = natsemi_pci_info[chip_idx].eeprom_size;
-   np-ignore_phy = 0;
+   if (natsemi_pci_info[chip_idx].flags  NATSEMI_FLAG_IGNORE_PHY)
+   np-ignore_phy = 1;
+   else
+   np-ignore_phy = 0;
 
/* Initial port:
 * - If configured to ignore the PHY set up for external.

--
You grabbed my hand and we fell into it, like a daydream - or a fever.
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[patch 1/2] natsemi: Add support for using MII port with no PHY

[Mark Brown]

This patch provides code paths which allow the natsemi driver to use the
external MII port on the chip but ignore any PHYs that may be attached to it.
The link state will be left as it was when the driver started and can be
configured via ethtool.  Any PHYs that are present can be accessed via the MII
ioctl()s.

This is useful for systems where the device is connected without a PHY
or where either information or actions outside the scope of the driver
are required in order to use the PHYs.

Signed-Off-By: Mark Brown [EMAIL PROTECTED]

---

This revision of the patch fixes some issues brought up during review.

Previous versions of this patch exposed the new functionality as a module
option.  This has been removed.  Any hardware that needs this should be
identifiable by a quirk since it unlikely to behave correctly with an
unmodified driver.

Index: linux/drivers/net/natsemi.c
===
--- linux.orig/drivers/net/natsemi.c2007-02-19 10:10:40.0 +
+++ linux/drivers/net/natsemi.c 2007-02-19 10:20:45.0 +
@@ -568,6 +568,8 @@
u32 intr_status;
/* Do not touch the nic registers */
int hands_off;
+   /* Don't pay attention to the reported link state. */
+   int ignore_phy;
/* external phy that is used: only valid if dev-if_port != PORT_TP */
int mii;
int phy_addr_external;
@@ -696,7 +698,10 @@
struct netdev_private *np = netdev_priv(dev);
u32 tmp;
 
-   netif_carrier_off(dev);
+   if (np-ignore_phy)
+   netif_carrier_on(dev);
+   else
+   netif_carrier_off(dev);
 
/* get the initial settings from hardware */
tmp= mdio_read(dev, MII_BMCR);
@@ -806,8 +811,10 @@
np-hands_off = 0;
np-intr_status = 0;
np-eeprom_size = natsemi_pci_info[chip_idx].eeprom_size;
+   np-ignore_phy = 0;
 
/* Initial port:
+* - If configured to ignore the PHY set up for external.
 * - If the nic was configured to use an external phy and if find_mii
 *   finds a phy: use external port, first phy that replies.
 * - Otherwise: internal port.
@@ -815,7 +822,7 @@
 * The address would be used to access a phy over the mii bus, but
 * the internal phy is accessed through mapped registers.
 */
-   if (readl(ioaddr + ChipConfig)  CfgExtPhy)
+   if (np-ignore_phy || readl(ioaddr + ChipConfig)  CfgExtPhy)
dev-if_port = PORT_MII;
else
dev-if_port = PORT_TP;
@@ -825,7 +832,9 @@
 
if (dev-if_port != PORT_TP) {
np-phy_addr_external = find_mii(dev);
-   if (np-phy_addr_external == PHY_ADDR_NONE) {
+   /* If we're ignoring the PHY it doesn't matter if we can't
+* find one. */
+   if (!np-ignore_phy  np-phy_addr_external == PHY_ADDR_NONE) {
dev-if_port = PORT_TP;
np-phy_addr_external = PHY_ADDR_INTERNAL;
}
@@ -891,6 +900,8 @@
printk(%02x, IRQ %d, dev-dev_addr[i], irq);
if (dev-if_port == PORT_TP)
printk(, port TP.\n);
+   else if (np-ignore_phy)
+   printk(, port MII, ignoring PHY\n);
else
printk(, port MII, phy ad %d.\n, 
np-phy_addr_external);
}
@@ -1571,9 +1582,13 @@
 {
struct netdev_private *np = netdev_priv(dev);
void __iomem * ioaddr = ns_ioaddr(dev);
-   int duplex;
+   int duplex = np-duplex;
u16 bmsr;
 
+   /* If we are ignoring the PHY then don't try reading it. */
+   if (np-ignore_phy)
+   goto propagate_state;
+
/* The link status field is latched: it remains low after a temporary
 * link failure until it's read. We need the current link status,
 * thus read twice.
@@ -1585,7 +1600,7 @@
if (netif_carrier_ok(dev)) {
if (netif_msg_link(np))
printk(KERN_NOTICE %s: link down.\n,
-   dev-name);
+  dev-name);
netif_carrier_off(dev);
undo_cable_magic(dev);
}
@@ -1609,6 +1624,7 @@
duplex = 1;
}
 
+propagate_state:
/* if duplex is set then bit 28 must be set, too */
if (duplex ^ !!(np-rx_config  RxAcceptTx)) {
if (netif_msg_link(np))
@@ -2819,6 +2835,15 @@
}
 
/*
+* If we're ignoring the PHY then autoneg and the internal
+* transciever are really not going to work so don't let the
+* user select them.
+*/
+   if (np-ignore_phy  (ecmd-autoneg == AUTONEG_ENABLE ||
+  ecmd-port == PORT_TP))
+   return

[patch 0/2] natsemi: Support Aculab E1/T1 cPCI carrier cards

[Mark Brown]

These patches add support for the Aculab E1/T1 cPCI carrier card to the
natsemi driver.  The first patch provides support for using the MII port
with no PHY and the second adds the quirk required to configure the
card.

--
You grabbed my hand and we fell into it, like a daydream - or a fever.
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[patch 2/2] natsemi: Support Aculab E1/T1 PMXc cPCI carrier cards

[Mark Brown]

Aculab E1/T1 PMXc cPCI carrier card cards present a natsemi on the cPCI
bus with an oversized EEPROM using a direct MII-MII connection with no
PHY.  This patch adds a new device table entry supporting these cards.

Signed-Off-By: Mark Brown [EMAIL PROTECTED]

Index: linux/drivers/net/natsemi.c
===
--- linux.orig/drivers/net/natsemi.c2007-02-12 18:09:44.0 +
+++ linux/drivers/net/natsemi.c 2007-02-12 18:09:59.0 +
@@ -244,6 +244,9 @@
MII_EN_SCRM = 0x0004,   /* enable scrambler (tp) */
 };
 
+enum {
+   NATSEMI_FLAG_IGNORE_PHY = 0x1,
+};
 
 /* array of board data directly indexed by pci_tbl[x].driver_data */
 static const struct {
@@ -251,10 +254,12 @@
unsigned long flags;
unsigned int eeprom_size;
 } natsemi_pci_info[] __devinitdata = {
+   { Aculab E1/T1 PMXc cPCI carrier card, NATSEMI_FLAG_IGNORE_PHY, 128 },
{ NatSemi DP8381[56], 0, 24 },
 };
 
 static const struct pci_device_id natsemi_pci_tbl[] __devinitdata = {
+   { PCI_VENDOR_ID_NS, 0x0020, 0x12d9, 0x000c, 0, 0, 0 },
{ PCI_VENDOR_ID_NS, 0x0020, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0 },
{ } /* terminate list */
 };
@@ -811,7 +816,11 @@
np-hands_off = 0;
np-intr_status = 0;
np-eeprom_size = natsemi_pci_info[chip_idx].eeprom_size;
-   np-ignore_phy = 0;
+   if (natsemi_pci_info[chip_idx].flags  NATSEMI_FLAG_IGNORE_PHY) {
+   np-ignore_phy = 1;
+   } else {
+   np-ignore_phy = 0;
+   }
 
/* Initial port:
 * - If configured to ignore the PHY set up for external.

--
You grabbed my hand and we fell into it, like a daydream - or a fever.
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [patch 1/2] natsemi: Add support for using MII port with no PHY

[Mark Brown]

On Wed, Feb 14, 2007 at 03:28:34PM +0200, Ahmed S. Darwish wrote:

 A trivial comment actually, Is there a point to write multi-line comments 
 in two different formats ?

No goal in doing that, no - it wasn't a conscious decision.

-- 
You grabbed my hand and we fell into it, like a daydream - or a fever.
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] natsemi: Messages being noisy

[Mark Brown]

On Thu, Sep 14, 2006 at 08:46:07AM -0700, [EMAIL PROTECTED] wrote:
 On Thu, Sep 14, 2006 at 05:39:08PM +0200, Ingo Oeser wrote:

  Is it possible to have the maximum value right from the start?
  May I tune it somewhere to be the maximum from the start?

 This will (if I recall) increase transmit latency.  It's a fine line.  You
 might tune it up, but this fallback path probably should not be removed..

Yes, raising the limit there will increase transmit latency since it
causes the chip to wait for more data to be DMAed before it begins
pushing the frame out.  I guess the dropped packet could be worked
around by resubmitting the dropped packet when we reconfigure the chip,
though obviously that's not ideal.

It would be interesting to understand what caused this to start
happening.  The main change in natsemi itself between 2.6.13.4 and
2.6.16.27 is the introduction of NAPI although it could be some other
change causing PCI bandwidth to become more scarce.

-- 
You grabbed my hand and we fell into it, like a daydream - or a fever.
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [patch 3/9] natsemi: Add support for using MII port with no PHY

[Mark Brown]

On Thu, Apr 27, 2006 at 05:54:58AM -0400, Jeff Garzik wrote:

 Provide a module option which configures the natsemi driver to use the
 external MII port on the chip but ignore any PHYs that may be attached to 
 it. The link state will be left as it was when the driver started and can 

 The proper way to do this is via the force_media boolean flag found in 
 several net drivers.

I've had a look at several of the net drivers that implement this option
(e100, smc91x, starfire and the shared code in mii.c).  Unless I'm
misreading the code it looks like the effect of this option in those
drivers is to disable autonegotiation but still configure the PHY when
the NIC is configured.

That is a subset of what the patch does and isn't sufficient for the
hardware this patch targets: sometimes there may be a PHY visible on the
MII bus but with a different configuration to the natsemi or there may
be no PHY present at all.  In this case the code in the natsemi driver
that configures the PHY to match the configuration of the natsemi also
needs to be disabled.

It looks like I should implement a force_media option and redo this
patch to use that.

-- 
You grabbed my hand and we fell into it, like a daydream - or a fever.
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [patch 1/4] natsemi: Add support for using MII port with no PHY

[Mark Brown]

On Thu, Mar 16, 2006 at 01:09:02AM -0800, Andrew Morton wrote:
 Mark Brown [EMAIL PROTECTED] wrote:

   +  if (np-ignore_phy  (ecmd-autoneg == AUTONEG_ENABLE ||
   + ecmd-port == PORT_INTERNAL)) {

 What's PORT_INTERNAL?  ethtool doesn't appear to define that.

It should be PORT_TP, sorry:

This patch provides a module option which configures the natsemi driver
to use the external MII port on the chip but ignore any PHYs that may be
attached to it.  The link state will be left as it was when the driver
started and can be configured via ethtool.  Any PHYs that are present
can be accessed via the MII ioctl()s.

This is useful for systems where the device is connected without a PHY
or where either information or actions outside the scope of the driver
are required in order to use the PHYs.

Signed-Off-By: Mark Brown [EMAIL PROTECTED]

Index: natsemi-queue/drivers/net/natsemi.c
===
--- natsemi-queue.orig/drivers/net/natsemi.c2006-02-25 13:38:34.0 
+
+++ natsemi-queue/drivers/net/natsemi.c 2006-02-25 13:50:51.0 +
@@ -259,7 +259,7 @@ MODULE_PARM_DESC(debug, DP8381x default
 MODULE_PARM_DESC(rx_copybreak, 
DP8381x copy breakpoint for copy-only-tiny-frames);
 MODULE_PARM_DESC(options, 
-   DP8381x: Bits 0-3: media type, bit 17: full duplex);
+   DP8381x: Bits 0-3: media type, bit 17: full duplex, bit 18: ignore 
PHY);
 MODULE_PARM_DESC(full_duplex, DP8381x full duplex setting(s) (1));
 
 /*
@@ -690,6 +690,8 @@ struct netdev_private {
u32 intr_status;
/* Do not touch the nic registers */
int hands_off;
+   /* Don't pay attention to the reported link state. */
+   int ignore_phy;
/* external phy that is used: only valid if dev-if_port != PORT_TP */
int mii;
int phy_addr_external;
@@ -891,7 +893,19 @@ static int __devinit natsemi_probe1 (str
np-hands_off = 0;
np-intr_status = 0;
 
+   option = find_cnt  MAX_UNITS ? options[find_cnt] : 0;
+   if (dev-mem_start)
+   option = dev-mem_start;
+
+   /* Ignore the PHY status? */
+   if (option  0x400) {
+   np-ignore_phy = 1;
+   } else {
+   np-ignore_phy = 0;
+   }
+
/* Initial port:
+* - If configured to ignore the PHY set up for external.
 * - If the nic was configured to use an external phy and if find_mii
 *   finds a phy: use external port, first phy that replies.
 * - Otherwise: internal port.
@@ -899,7 +913,7 @@ static int __devinit natsemi_probe1 (str
 * The address would be used to access a phy over the mii bus, but
 * the internal phy is accessed through mapped registers.
 */
-   if (readl(ioaddr + ChipConfig)  CfgExtPhy)
+   if (np-ignore_phy || readl(ioaddr + ChipConfig)  CfgExtPhy)
dev-if_port = PORT_MII;
else
dev-if_port = PORT_TP;
@@ -909,7 +923,9 @@ static int __devinit natsemi_probe1 (str
 
if (dev-if_port != PORT_TP) {
np-phy_addr_external = find_mii(dev);
-   if (np-phy_addr_external == PHY_ADDR_NONE) {
+   /* If we're ignoring the PHY it doesn't matter if we can't
+* find one. */
+   if (!np-ignore_phy  np-phy_addr_external == PHY_ADDR_NONE) {
dev-if_port = PORT_TP;
np-phy_addr_external = PHY_ADDR_INTERNAL;
}
@@ -917,10 +933,6 @@ static int __devinit natsemi_probe1 (str
np-phy_addr_external = PHY_ADDR_INTERNAL;
}
 
-   option = find_cnt  MAX_UNITS ? options[find_cnt] : 0;
-   if (dev-mem_start)
-   option = dev-mem_start;
-
/* The lower four bits are the media type. */
if (option) {
if (option  0x200)
@@ -954,7 +966,10 @@ static int __devinit natsemi_probe1 (str
if (mtu)
dev-mtu = mtu;
 
-   netif_carrier_off(dev);
+   if (np-ignore_phy)
+   netif_carrier_on(dev);
+   else
+   netif_carrier_off(dev);
 
/* get the initial settings from hardware */
tmp= mdio_read(dev, MII_BMCR);
@@ -1002,6 +1017,8 @@ static int __devinit natsemi_probe1 (str
printk(%02x, IRQ %d, dev-dev_addr[i], irq);
if (dev-if_port == PORT_TP)
printk(, port TP.\n);
+   else if (np-ignore_phy)
+   printk(, port MII, ignoring PHY\n);
else
printk(, port MII, phy ad %d.\n, 
np-phy_addr_external);
}
@@ -1682,42 +1699,44 @@ static void check_link(struct net_device
 {
struct netdev_private *np = netdev_priv(dev);
void __iomem * ioaddr = ns_ioaddr(dev);
-   int duplex;
+   int duplex = np-full_duplex;
u16 bmsr;
-   
-   /* The link status field

Re: [patch 1/4] natsemi: Add support for using MII port with no PHY

[Mark Brown]

On Sun, Mar 12, 2006 at 01:41:13PM -0800, [EMAIL PROTECTED] wrote:

 Not that my opinion should hold much weight, having been absent from the
 driver for some time, but yuck.  Is there no better way to do this thatn
 sprinkling poo all over it?

The changes are mostly isolated into check_link(), the fact that half
the function gets placed inside a conditional but diff sees it as a
bunch of smaller changes makes the changes look a lot more invasive than
they actually are.  I guess that could be helped by splitting the PHY
access code out of check_link() into check_phy_status() or something but
I'm not sure how much that really helps.

-- 
You grabbed my hand and we fell into it, like a daydream - or a fever.
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[patch 2/4] natsemi: Support oversized EEPROMs

[Mark Brown]

The natsemi chip can have a larger EEPROM attached than it itself uses
for configuration.  This patch adds support for user space access
to such an EEPROM.

Signed-off-by: Mark Brown [EMAIL PROTECTED]

Index: natsemi-queue/drivers/net/natsemi.c
===
--- natsemi-queue.orig/drivers/net/natsemi.c2006-02-25 17:40:15.0 
+
+++ natsemi-queue/drivers/net/natsemi.c 2006-02-25 17:40:39.0 +
@@ -226,7 +226,7 @@ static int full_duplex[MAX_UNITS];
 NATSEMI_PG1_NREGS)
 #define NATSEMI_REGS_VER   1 /* v1 added RFDR registers */
 #define NATSEMI_REGS_SIZE  (NATSEMI_NREGS * sizeof(u32))
-#define NATSEMI_EEPROM_SIZE24 /* 12 16-bit values */
+#define NATSEMI_DEF_EEPROM_SIZE24 /* 12 16-bit values */
 
 /* Buffer sizes:
  * The nic writes 32-bit values, even if the upper bytes of
@@ -716,6 +716,8 @@ struct netdev_private {
unsigned int iosize;
spinlock_t lock;
u32 msg_enable;
+   /* EEPROM data */
+   int eeprom_size;
 };
 
 static void move_int_phy(struct net_device *dev, int addr);
@@ -892,6 +894,7 @@ static int __devinit natsemi_probe1 (str
np-msg_enable = (debug = 0) ? (1debug)-1 : NATSEMI_DEF_MSG;
np-hands_off = 0;
np-intr_status = 0;
+   np-eeprom_size = NATSEMI_DEF_EEPROM_SIZE;
 
option = find_cnt  MAX_UNITS ? options[find_cnt] : 0;
if (dev-mem_start)
@@ -2601,7 +2604,8 @@ static int get_regs_len(struct net_devic
 
 static int get_eeprom_len(struct net_device *dev)
 {
-   return NATSEMI_EEPROM_SIZE;
+   struct netdev_private *np = netdev_priv(dev);
+   return np-eeprom_size;
 }
 
 static int get_settings(struct net_device *dev, struct ethtool_cmd *ecmd)
@@ -2688,15 +2692,20 @@ static u32 get_link(struct net_device *d
 static int get_eeprom(struct net_device *dev, struct ethtool_eeprom *eeprom, 
u8 *data)
 {
struct netdev_private *np = netdev_priv(dev);
-   u8 eebuf[NATSEMI_EEPROM_SIZE];
+   u8 *eebuf;
int res;
 
+   eebuf = kmalloc(np-eeprom_size, GFP_KERNEL);
+   if (!eebuf)
+   return -ENOMEM;
+
eeprom-magic = PCI_VENDOR_ID_NS | (PCI_DEVICE_ID_NS_8381516);
spin_lock_irq(np-lock);
res = netdev_get_eeprom(dev, eebuf);
spin_unlock_irq(np-lock);
if (!res)
memcpy(data, eebuf+eeprom-offset, eeprom-len);
+   kfree(eebuf);
return res;
 }
 
@@ -3062,9 +3071,10 @@ static int netdev_get_eeprom(struct net_
int i;
u16 *ebuf = (u16 *)buf;
void __iomem * ioaddr = ns_ioaddr(dev);
+   struct netdev_private *np = netdev_priv(dev);
 
/* eeprom_read reads 16 bits, and indexes by 16 bits */
-   for (i = 0; i  NATSEMI_EEPROM_SIZE/2; i++) {
+   for (i = 0; i  np-eeprom_size/2; i++) {
ebuf[i] = eeprom_read(ioaddr, i);
/* The EEPROM itself stores data bit-swapped, but eeprom_read
 * reads it back sanely. So we swap it back here in order to

--
You grabbed my hand and we fell into it, like a daydream - or a fever.
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html