Re: [PATCH] net: chelsio: cxgb3: constify attribute_group structures.

Hi Joe, On Tuesday 11 July 2017 11:17 AM, Joe Perches wrote: On Tue, 2017-07-11 at 11:11 +0530, Arvind Yadav wrote: Hi Joe, On Monday 10 July 2017 10:30 PM, Joe Perches wrote: On Mon, 2017-07-10 at 16:04 +0530, Arvind Yadav wrote: attribute_groups are not supposed to change at runtime.

Re: [PATCH] net: chelsio: cxgb3: constify attribute_group structures.

On Tue, 2017-07-11 at 11:11 +0530, Arvind Yadav wrote: > Hi Joe, > > > On Monday 10 July 2017 10:30 PM, Joe Perches wrote: > > On Mon, 2017-07-10 at 16:04 +0530, Arvind Yadav wrote: > > > attribute_groups are not supposed to change at runtime. All functions > > > working with attribute_groups

Re: [PATCH] net: chelsio: cxgb3: constify attribute_group structures.

Hi Joe, On Monday 10 July 2017 10:30 PM, Joe Perches wrote: On Mon, 2017-07-10 at 16:04 +0530, Arvind Yadav wrote: attribute_groups are not supposed to change at runtime. All functions working with attribute_groups provided by work with const attribute_group. So mark the non-const structs as

Re: [RFC PATCH 00/12] Implement XDP bpf_redirect vairants

On 07/10/2017 11:30 AM, Jesper Dangaard Brouer wrote: > On Sat, 8 Jul 2017 21:06:17 +0200 > Jesper Dangaard Brouer wrote: > >> On Sat, 08 Jul 2017 10:46:18 +0100 (WEST) >> David Miller wrote: >> >>> From: John Fastabend >>>

Re: meson-gxbb-p200 4.12.0 network TCP transfer stalls

I use NBD for fast building and savif SD card and, sadly, the TV box crashes after few min of building On 2017 Jul 11, Marc Duponcheel wrote: > FYI > > I changed 4.12.0 drivers/net/phy/realtek.c RTL8211F code to equal the > 3.14.29 amlogic/ethernet/phy/am_realtek.c code and now the networking

Re: [PATCH v6 0/3] Add new PCI_DEV_FLAGS_NO_RELAXED_ORDERING flag

Hey Alexander, Okay, I understand your point regarding the "most likely scenario" being TLPs directed upstream to the Root Complex. But I'd still like to make sure that we have an agreed upon API/methodology for doing Peer-to-Peer with Relaxed Ordering and no Relaxed Ordering to the Root

Re: meson-gxbb-p200 4.12.0 network TCP transfer stalls

FYI I changed 4.12.0 drivers/net/phy/realtek.c RTL8211F code to equal the 3.14.29 amlogic/ethernet/phy/am_realtek.c code and now the networking works without TCP stalls. I don't say below patch should be considered mainstream (as maybe some 4.12.0 rtl8211f_config_init code should not be

Re: [PATCH net v2] samples/bpf: fix a build issue

On 7/10/17, 2:13 PM, "Daniel Borkmann" wrote: On 07/10/2017 11:04 PM, Yonghong Song wrote: > With latest net-next: > > clang -nostdinc -isystem /usr/lib/gcc/x86_64-redhat-linux/6.3.1/include -I./arch/x86/include -I./arch/x86/include/generated/uapi

Re: WARN_ON_ONCE(work > weight) in napi_poll()

On 07/04/2017 08:59 AM, Andrey Ryabinin wrote: > On 07/04/2017 04:49 PM, Kalle Valo wrote: >> Andrey Ryabinin writes: >> >>> I occasionally hit WARN_ON_ONCE(work > weight); in napi_poll() on a >>> laptop with ath10k card. >>> >>> >>> [37207.593370] [ cut here

Re: [PATCH net v2] samples/bpf: fix a build issue

On 07/10/2017 11:04 PM, Yonghong Song wrote: With latest net-next: clang -nostdinc -isystem /usr/lib/gcc/x86_64-redhat-linux/6.3.1/include -I./arch/x86/include -I./arch/x86/include/generated/uapi -I./arch/x86/include/generated -I./include -I./arch/x86/include/uapi -I./include/uapi

[PATCH net v2] samples/bpf: fix a build issue

With latest net-next: clang -nostdinc -isystem /usr/lib/gcc/x86_64-redhat-linux/6.3.1/include -I./arch/x86/include -I./arch/x86/include/generated/uapi -I./arch/x86/include/generated -I./include -I./arch/x86/include/uapi -I./include/uapi -I./include/generated/uapi -include

Re: [PATCH net] samples/bpf: fix a build issue

On 07/10/2017 10:51 PM, Yonghong Song wrote: On 7/10/17 1:27 PM, Daniel Borkmann wrote: On 07/10/2017 10:12 PM, Yonghong Song wrote: From: Yonghong Song With latest net-next: clang -nostdinc -isystem /usr/lib/gcc/x86_64-redhat-linux/6.3.1/include

Re: [PATCH net-next RFC 05/12] net: dsa: Add support for learning FDB through notification

Hi Arkadi, Arkadi Sharshevsky writes: >>> + err = dsa_port_fdb_add(p->dp, fdb_info->addr, fdb_info->vid); >>> + if (err) { >>> + netdev_dbg(dev, "fdb add failed err=%d\n", err); >>> + break; >>> + } >>> +

Re: [PATCH net] samples/bpf: fix a build issue

On 7/10/17 1:27 PM, Daniel Borkmann wrote: On 07/10/2017 10:12 PM, Yonghong Song wrote: From: Yonghong Song With latest net-next: clang -nostdinc -isystem /usr/lib/gcc/x86_64-redhat-linux/6.3.1/include -I./arch/x86/include

Re: [PATCH net] samples/bpf: fix a build issue

On 07/10/2017 10:12 PM, Yonghong Song wrote: From: Yonghong Song With latest net-next: clang -nostdinc -isystem /usr/lib/gcc/x86_64-redhat-linux/6.3.1/include -I./arch/x86/include -I./arch/x86/include/generated/uapi -I./arch/x86/include/generated -I./include

Re: [PATCH net] samples/bpf: fix a build issue

Thank you for fixing it. On 7/10/17, 1:12 PM, "Yonghong Song" wrote: From: Yonghong Song With latest net-next: clang -nostdinc -isystem /usr/lib/gcc/x86_64-redhat-linux/6.3.1/include -I./arch/x86/include

[PATCH net] samples/bpf: fix a build issue

From: Yonghong Song With latest net-next: clang -nostdinc -isystem /usr/lib/gcc/x86_64-redhat-linux/6.3.1/include -I./arch/x86/include -I./arch/x86/include/generated/uapi -I./arch/x86/include/generated -I./include -I./arch/x86/include/uapi -I./include/uapi

Re: [PATCH net-next RFC 10/12] net: dsa: Move FDB dump implementation inside DSA

Hi Arkadi, Arkadi Sharshevsky writes: > +struct dsa_slave_dump_ctx { > + struct net_device *dev; > + struct sk_buff *skb; > + struct netlink_callback *cb; > + int idx; > +}; > + > struct dsa_switch_ops { > /* >* Legacy probing. > @@ -392,9

Re: [PATCH v2] mrf24j40: Fix en error handling path in 'mrf24j40_probe()'

On 07/08/2017 04:40 AM, Christophe JAILLET wrote: If this check fails, we must release some resources as done everywhere else in this function before returning an error code. Signed-off-by: Christophe JAILLET --- V2: initialization of ret in this erro path ws

Re: [PATCH net-next 2/3] cxgb4: Add PTP Hardware Clock (PHC) support

On Tue, Jul 04, 2017 at 04:46:21PM +0530, Atul Gupta wrote: > +/** > + * cxgb4_ptp_init - initialize PTP for devices which support it > + * @adapter: board private structure > + * > + * This function performs the required steps for enabling PTP support. > + */ > +void cxgb4_ptp_init(struct adapter

Re: [RFC] get_compat_bpf_fprog(): don't copyin field-by-field

On 07/08/2017 08:22 PM, Al Viro wrote: Signed-off-by: Al Viro Acked-by: Daniel Borkmann (Looks like ppp_sock_fprog_ioctl_trans() is another such candidate.)

[patch iproute2/net-next RFC] tc: Implement filter block sharing to ingress and clsact qdiscs

From: Jiri Pirko Signed-off-by: Jiri Pirko --- include/linux/pkt_sched.h | 12 +++ tc/q_clsact.c | 54 ++- tc/q_ingress.c| 32 +--- 3 files changed, 90

[patch net-next RFC 3/4] net: sched: introduce shared filter blocks infrastructure

From: Jiri Pirko Allow qdiscs to share filter blocks among them. Each qdisc type has to use block get/put modifications that enable sharing. Shared blocks are tracked within each net namespace and identified by u32 value. This value is auto-generated in case user did not pass

[patch net-next RFC 2/4] net: sched: intruduce qdisc_net helper

From: Jiri Pirko There is going to be need to be able to obtain net structure for a qdisc. So introduce helper to do it. Signed-off-by: Jiri Pirko --- include/net/pkt_sched.h | 7 +++ 1 file changed, 7 insertions(+) diff --git

[patch net-next RFC 0/4] net: sched: allow qdiscs to share filter block instances

From: Jiri Pirko Currently the filters added to qdiscs are independent. So for example if you have 2 netdevices and you create ingress qdisc on both and you want to add identical filter rules both, you need to add them twice. This patchset makes this easier and mainly saves

[patch net-next RFC 4/4] net: sched: allow ingress and clsact qdiscs to share filter blocks

From: Jiri Pirko Benefit from the previously introduced shared filter blocks infrastructure and allow ingress and clsact qdisc instances to share filter blocks. The block index is coming from userspace as qdisc option. Signed-off-by: Jiri Pirko ---

[patch net-next RFC 1/4] net: sched: introduce support for multiple filter chain pointers registration

From: Jiri Pirko So far, there was possible only to register a single filter chain pointer to a block->chain[0]. However, when the blocks will get shareable, we need to allow multiple filter chain pointers registration. Signed-off-by: Jiri Pirko ---

Re: [PATCH] net/mlx5: IPSec, fix 64-bit division correctly

From: Arnd Bergmann Date: Mon, 10 Jul 2017 11:37:51 +0200 > The new IPSec offload code introduced a build error: > > drivers/net/ethernet/mellanox/mlx5/core/en_accel/ipsec_rxtx.o: In function > `mlx5e_ipsec_build_inverse_table': > ipsec_rxtx.c:(.text+0x556): undefined reference

Re: [RFC PATCH 00/12] Implement XDP bpf_redirect vairants

On Sat, 8 Jul 2017 21:06:17 +0200 Jesper Dangaard Brouer wrote: > On Sat, 08 Jul 2017 10:46:18 +0100 (WEST) > David Miller wrote: > > > From: John Fastabend > > Date: Fri, 07 Jul 2017 10:48:36 -0700 > > > > > On 07/07/2017

Re: [PATCH iproute2 V3 0/4] RDMAtool

Mon, Jul 10, 2017 at 06:01:44PM CEST, l...@kernel.org wrote: >On Mon, Jul 10, 2017 at 10:02:30AM +0200, Jiri Pirko wrote: >> Tue, Jul 04, 2017 at 09:55:37AM CEST, l...@kernel.org wrote: >> >Hi, >> > >> >This is third version of series implementing the RDAMtool - the tool >> >to configure RDMA

Re: [PATCH iproute2 V3 3/4] rdma: Add link object

Mon, Jul 10, 2017 at 06:22:23PM CEST, l...@kernel.org wrote: >On Mon, Jul 10, 2017 at 10:13:07AM +0200, Jiri Pirko wrote: >> Tue, Jul 04, 2017 at 09:55:40AM CEST, l...@kernel.org wrote: >> >From: Leon Romanovsky >> > >> >Link (port) object represent struct ib_port to the user

Re: [Patch] mqueue: fix netlink sock refcnt and skb refcnt

This thing is definitely not cc'd to the right people: On Sun, Jul 9, 2017 at 10:08 PM, Cong Wang wrote: > > Cc: Linus Torvalds > Cc: Andrew Morton > Cc: Manfred Spraul >

Re: [RFC PATCH 10/12] xdp: Add batching support to redirect map

On 07/10/2017 10:53 AM, Jesper Dangaard Brouer wrote: > On Fri, 07 Jul 2017 10:37:59 -0700 > John Fastabend wrote: > >> diff --git a/kernel/bpf/devmap.c b/kernel/bpf/devmap.c >> index 36dc13de..656e334 100644 >> --- a/kernel/bpf/devmap.c >> +++ b/kernel/bpf/devmap.c >

Re: [RFC PATCH 10/12] xdp: Add batching support to redirect map

On Fri, 07 Jul 2017 10:37:59 -0700 John Fastabend wrote: > diff --git a/kernel/bpf/devmap.c b/kernel/bpf/devmap.c > index 36dc13de..656e334 100644 > --- a/kernel/bpf/devmap.c > +++ b/kernel/bpf/devmap.c [...] > > +void __dev_map_insert_ctx(struct bpf_map *map, u32

Re: [RFC PATCH 03/12] xdp: add bpf_redirect helper function

On 07/09/2017 06:37 AM, Saeed Mahameed wrote: > > > On 7/7/2017 8:35 PM, John Fastabend wrote: >> This adds support for a bpf_redirect helper function to the XDP >> infrastructure. For now this only supports redirecting to the egress >> path of a port. >> >> In order to support drivers handling

Re: [PATCH v2 0/9] Remove spin_unlock_wait()

Hi Alan, On 07/08/2017 06:21 PM, Alan Stern wrote: Pardon me for barging in, but I found this whole interchange extremely confusing... On Sat, 8 Jul 2017, Ingo Molnar wrote: * Paul E. McKenney wrote: On Sat, Jul 08, 2017 at 10:35:43AM +0200, Ingo Molnar wrote:

Re: [Patch] mqueue: fix netlink sock refcnt and skb refcnt

On Sun, Jul 9, 2017 at 10:08 PM, Cong Wang wrote: > netlink_sendskb() is problematic, it releases sock refcnt > silently which could cause troubles we can call it multiple > times. info->notify_sock is a good example where we > setup once and use it to send netlink skb's

Re: [PATCH net-next RFC 08/12] net: dsa: Remove support for bypass bridge port attributes/vlan set

Hi Florian, Arkadi, Florian Fainelli writes: > I would be more comfortable if we still had a way to dump HW entries by > calling into drivers, because it's useful for debugging, and doing that > using standard tools plus an additional flag for instance: > > bridge fdb show

[RESEND PATCH net] tap: convert a mutex to a spinlock

We are not allowed to block on the RCU reader side, so can't just hold the mutex as before. As a quick fix, convert it to a spinlock. Fixes: d9f1f61c0801 ("tap: Extending tap device create/destroy APIs") Reported-by: Christian Borntraeger Tested-by: Christian Borntraeger

Re: [PATCH] brcmfmac: added LED triggers for transmit/receive

> 1) I think most of it should be some cfg80211 shareable code. I’m not sure exactly what you mean by this, could you please clarify? > 2) This "rxtx" while surely present in other places sounds like a > workaround for LED subsystem limitation. Maybe it's time to finally > rework LED triggers.

Re: [PATCH] net: chelsio: cxgb3: constify attribute_group structures.

On Mon, 2017-07-10 at 16:04 +0530, Arvind Yadav wrote: > attribute_groups are not supposed to change at runtime. All functions > working with attribute_groups provided by work > with const attribute_group. So mark the non-const structs as const. I think it's good you are doing all of these.

bug in "PCI: Support INTx masking on ConnectX-4 with firmware x.14.1100+"?

+ /* Reading from resource space should be 32b aligned */ + fw_maj_min = ioread32be(fw_ver); + fw_sub_min = ioread32be(fw_ver + 1); + fw_major = fw_maj_min & 0x; + fw_minor = fw_maj_min >> 16; + fw_subminor = fw_sub_min & 0x; Maybe second read should be

Re: net: Fix inconsistent teardown and release of private netdev state.

On Sun, Jul 9, 2017 at 7:07 PM, Jason A. Donenfeld wrote: > On Sat, Jul 8, 2017 at 12:39 AM, Cong Wang wrote: >> On Thu, Jul 6, 2017 at 7:24 AM, Jason A. Donenfeld wrote: >>> list_add(>list, _of_things); >>> >>> ret =

Re: [PATCH iproute2 V3 3/4] rdma: Add link object

On Mon, Jul 10, 2017 at 10:13:07AM +0200, Jiri Pirko wrote: > Tue, Jul 04, 2017 at 09:55:40AM CEST, l...@kernel.org wrote: > >From: Leon Romanovsky > > > >Link (port) object represent struct ib_port to the user space. > > > >Link properties: > > * Port capabilities > > * IB

Re: [PATCH iproute2 V3 0/4] RDMAtool

On Mon, Jul 10, 2017 at 10:02:30AM +0200, Jiri Pirko wrote: > Tue, Jul 04, 2017 at 09:55:37AM CEST, l...@kernel.org wrote: > >Hi, > > > >This is third version of series implementing the RDAMtool - the tool > >to configure RDMA devices. The initial proposal was sent as RFC [1] and > >was based on

Re: [PATCH] dpaa_eth: use correct device for DMA mapping API

On 10/07/17 16:14, Arnd Bergmann wrote: > Geert Uytterhoeven ran into a build error without CONFIG_HAS_DMA, > as a result of the driver calling set_dma_ops(). While we can > fix the build error in the dma-mapping implementation, there is > another problem in this driver: > > The configuration for

Re: [PATCH v2] dt-bindings: net: ravb : Add support for r8a7743 SoC

On Mon, Jul 10, 2017 at 5:32 PM, Biju Das wrote: > Add a new compatible string for the RZ/G1M (R8A7743) SoC. > > Signed-off-by: Biju Das Reviewed-by: Geert Uytterhoeven Gr{oetje,eeting}s, Geert

[PATCH v2] dt-bindings: net: ravb : Add support for r8a7743 SoC

Add a new compatible string for the RZ/G1M (R8A7743) SoC. Signed-off-by: Biju Das --- v1->v2 * Changed the subject * re-formatted the required properties .../devicetree/bindings/net/renesas,ravb.txt | 29 +- 1 file changed, 17 insertions(+),

Re: [PATCH] net/mlx5: IPSec, fix 64-bit division correctly

On Mon, 2017-07-10 at 10:24 +, Ilan Tayari wrote: > > -Original Message- > > From: Arnd Bergmann [mailto:a...@arndb.de] > > Subject: [PATCH] net/mlx5: IPSec, fix 64-bit division correctly > > > > The new IPSec offload code introduced a build error: > > > >

Re: [PATCH] dpaa_eth: use correct device for DMA mapping API

Hi Arnd, On Mon, Jul 10, 2017 at 5:14 PM, Arnd Bergmann wrote: > Geert Uytterhoeven ran into a build error without CONFIG_HAS_DMA, > as a result of the driver calling set_dma_ops(). While we can > fix the build error in the dma-mapping implementation, there is > another problem in

Re: [PATCH/RFC] dma-mapping: Provide dummy set_dma_ops() for NO_DMA=y

On 10/07/17 15:56, Christoph Hellwig wrote: > This looks reasonable to me, I'd be happy to pick it up. Can you send > it as a series with the reverts? The fact remains that the FSL driver is still doing the wrong thing though - set_dma_ops(dev1, get_dma_ops(dev2)) is just a hack which happens to

Re: [iproute PATCH] ip netns: Make sure netns name is sane

On Mon, 10 Jul 2017 13:19:12 +0200 Phil Sutter wrote: > +static bool is_basename(const char *name) > +{ > + char *name_dup = strdup(name); > + bool rc = true; > + > + if (!name_dup) > + return false; > + > + if (strcmp(basename(name_dup), name)) > +

[PATCH] dpaa_eth: use correct device for DMA mapping API

Geert Uytterhoeven ran into a build error without CONFIG_HAS_DMA, as a result of the driver calling set_dma_ops(). While we can fix the build error in the dma-mapping implementation, there is another problem in this driver: The configuration for the DMA is done by the platform code, looking up

Re: Investment Consideration

Thank you for your time, We are looking for clients in your country with good business or project that requires financing to execute. Please get back to me if you are interested in this or you know anybody who has good business ideas but lack the necessary capital to fund his projects so we

Re: CAN-FD Transceiver Limitations

On 06/29/2017 05:41 PM, Andrew Lunn wrote: >> Transceivers for CAN are not apart of any model. Traditional CAN didn't >> have a problem because all transceivers from my understanding supported >> the maximum speed of 1 Mbps defined by the spec. However, with the >> introduction of CAN Flexible

Re: [PATCH/RFC] dma-mapping: Provide dummy set_dma_ops() for NO_DMA=y

This looks reasonable to me, I'd be happy to pick it up. Can you send it as a series with the reverts?

Re: [PATCH net] mdio: mux: fix parsing mux registers outside of the PHY address range

> To be clear, are you suggesting that we add an additional property to > of_mdio_parse_addr() that specifies the limit to check against, or > remove the check and add it to each additional caller? Hi Jon Probably the simplest is to add an extra parameter to mdio_mux_init() which is the maximum

Re: [PATCH net] mdio: mux: fix parsing mux registers outside of the PHY address range

On Mon, Jul 10, 2017 at 8:56 AM, Andrew Lunn wrote: > On Mon, Jul 10, 2017 at 02:35:23PM +0200, Martin Blumenstingl wrote: >> mdio_mux_init parses the child nodes of the MDIO mux. When using >> "mdio-mux-mmioreg" the child nodes are describing the register value >> that is written

Re: [GIT] Networking

On Mon, Jul 10, 2017 at 08:10:02AM -0400, Sowmini Varadhan wrote: > > The reason that the WARN_ON is triggered is that af_alg_accept() calls > sock_init_data() which does > >2636 if (sock) { > : >2639 sock->sk= sk; Oh yes. This started out with

[PATCH net] cxgb4: fix BUG() on interrupt deallocating path of ULD

Since the introduction of ULD (Upper-Layer Drivers), the MSI-X deallocating path changed in cxgb4: the driver frees the interrupts of ULD when unregistering it or on shutdown PCI handler. Problem is that if a MSI-X is not freed before deallocated in the PCI layer, it will trigger a BUG() due to

Re: [PATCH v1 1/1] dt-binding: ptp: Add SoC compatibility strings for dte ptp clock

On Thu, Jul 06, 2017 at 10:37:57AM -0700, Arun Parameswaran wrote: > Add SoC specific compatibility strings to the Broadcom DTE > based PTP clock binding document. > > Fixed the document heading and node name. > > Fixes: 80d6076140b2 ("dt-binding: ptp: add bindings document for dte based > ptp

Re: [PATCH 2/2] net: ethernet: fsl: add phy reset after clk enable option

On Thu, Jul 06, 2017 at 03:05:30PM +0200, Richard Leitner wrote: > Some PHYs (for example the LAN8710) doesn't allow turning the clocks off > and on again without reset (according to their datasheet). Exactly this > behaviour was introduced for power saving reasons by commit e8fcfcd5684a > ("net:

[PATCH 1/2] openvswitch: Optimize updating for OvS flow_stats.

In the ovs_flow_stats_update(), we only use the node var to alloc flow_stats struct. But this is not a common case, it is unnecessary to call the numa_node_id() everytime. This patch is not a bugfix, but there maybe a small increase. Signed-off-by: Tonghao Zhang ---

[PATCH 2/2] openvswitch: Optimize operations for OvS flow_stats.

When calling the flow_free() to free the flow, we call many times (cpu_possible_mask, eg. 128 as default) cpumask_next(). That will take up our CPU usage if we call the flow_free() frequently. When we put all packets to userspace via upcall, and OvS will send them back via netlink to

Re: [PATCH] netns: avoid directory traversal (was: ip netns: Make sure netns name is sane)

Hi Matteo, On Mon, Jul 10, 2017 at 02:08:31PM +0200, Matteo Croce wrote: > I noticed that your patch still leaves an uncovered scenario, the one where > the > namespace name is "." or "..". > Calling 'ip netns del ..' will remove /var/run which is a symlink to /run on > most systems causing some

Re: [PATCH net] mdio: mux: fix parsing mux registers outside of the PHY address range

On Mon, Jul 10, 2017 at 02:35:23PM +0200, Martin Blumenstingl wrote: > mdio_mux_init parses the child nodes of the MDIO mux. When using > "mdio-mux-mmioreg" the child nodes are describing the register value > that is written to switch between the MDIO busses. > > The change which makes the error

Re: [PATCH net] mdio: mux: fix parsing mux registers outside of the PHY address range

On 07/10/2017 02:35 PM, Martin Blumenstingl wrote: > mdio_mux_init parses the child nodes of the MDIO mux. When using > "mdio-mux-mmioreg" the child nodes are describing the register value > that is written to switch between the MDIO busses. > > The change which makes the error messages more

[PATCH net] mdio: mux: fix parsing mux registers outside of the PHY address range

mdio_mux_init parses the child nodes of the MDIO mux. When using "mdio-mux-mmioreg" the child nodes are describing the register value that is written to switch between the MDIO busses. The change which makes the error messages more verbose changed the parsing of the "reg" property from a simple

Re: [GIT] Networking

On (07/10/17 18:05), Herbert Xu wrote: > > Hmm, I can't see the problem in af_alg_accept. The struct socket > comes directly from sys_accept() which creates it using sock_alloc. > > So the only thing I can think of is that the memory returned by > sock_alloc is not zeroed and therefore the

[PATCH] netns: avoid directory traversal (was: ip netns: Make sure netns name is sane)

Hi Phil, I noticed that your patch still leaves an uncovered scenario, the one where the namespace name is "." or "..". Calling 'ip netns del ..' will remove /var/run which is a symlink to /run on most systems causing some daemons, eg. dbus, to fail. ip netns doesn't validate input, allowing

[PATCH] ioc3-eth: store pointer to net_device for priviate area

Computing the alignment manually for going from priv to pub is probably not such a good idea, and in general the assumption that going from priv to pub is possible trivially could change, so rather than relying on that, we change things to just store a pointer to pub. This was sugested by DaveM in

Re: [PATCH 1/2] netdevice: add netdev_pub helper function

On Mon, Jul 10, 2017 at 10:04 AM, David Miller wrote: > I disagree. Assuming one can go from the driver private to the netdev > object trivially is a worse assumption than the other way around, and > locks us into the current implementation of how the netdev and driver >

[iproute PATCH] ip netns: Make sure netns name is sane

In order to keep track of created netns, 'ip netns' creates a mount point inside NETNS_RUN_DIR. By not checking the user-specified name, it allowed to create that mount point outside of NETNS_RUN_DIR and hence lose track of it afterwards: | # ip netns add ../../tmp/foobar | # ip netns list | #

Re: [PATCH 1/2 net] ptp: fix error codes in ptp_clock_register()

On Mon, Jul 10, 2017 at 01:29:20PM +0300, Dan Carpenter wrote: > The "goto no_pps" was a bug you introduced. I took a second look, and yes, the original commit should not have returned NULL, and the original callers did not expect NULL either. > But I feel like you're being rude, so I'm not

Re: [PATCH v6 0/3] Add new PCI_DEV_FLAGS_NO_RELAXED_ORDERING flag

Hi Casey: On 2017/7/8 10:04, Casey Leedom wrote: > Okay, thanks for the note Alexander.I'll have to look more closely > at > the patch on Monday and try it out on one of the targeted systems to verify > the semantics you describe. > All the modification is only clearing the device's

[PATCH] net: chelsio: cxgb3: constify attribute_group structures.

attribute_groups are not supposed to change at runtime. All functions working with attribute_groups provided by work with const attribute_group. So mark the non-const structs as const. File size before: textdata bss dec hex filename 28720 985 12 297177415

Re: [PATCH 1/2 net] ptp: fix error codes in ptp_clock_register()

On Mon, Jul 10, 2017 at 11:48:06AM +0200, Richard Cochran wrote: > On Mon, Jul 10, 2017 at 12:38:16PM +0300, Dan Carpenter wrote: > > There were two buggy commits so I chose the ealier one. The other buggy > > No, you are mistaken. In the original patch, NULL or PTR_ERR were > returned on

RE: [PATCH] net/mlx5: IPSec, fix 64-bit division correctly

> -Original Message- > From: Arnd Bergmann [mailto:a...@arndb.de] > Subject: [PATCH] net/mlx5: IPSec, fix 64-bit division correctly > > The new IPSec offload code introduced a build error: > > drivers/net/ethernet/mellanox/mlx5/core/en_accel/ipsec_rxtx.o: In function >

[PATCH] net: bonding: constify attribute_group structures.

attribute_groups are not supposed to change at runtime. All functions working with attribute_groups provided by work with const attribute_group. So mark the non-const structs as const. File size before: textdata bss dec hex filename 45121472 059841760

RE: [PATCH iproute2] ip: change flag names to an array

From: Stephen Hemminger > Sent: 07 July 2017 16:40 > For the most of the address flags, use a table of bit values rather > than open coding every value. This allows for easier inevitable > expansion of flags. > > This also fixes the missing stable-privacy flag. > > Signed-off-by: Stephen

[PATCH] arcnet: com20020-pci: constify attribute_group structures.

attribute_groups are not supposed to change at runtime. All functions working with attribute_groups provided by work with const attribute_group. So mark the non-const structs as const. File size before: textdata bss dec hex filename 3409 948 2843851121

Re: [GIT] Networking

On Sun, Jul 09, 2017 at 09:40:43PM +0100, David Miller wrote: > > > It look like PF_ALG sets up a ->sk in alg_create() (but this > > would get over-written in alg_accept()?) No it does not. The struct socket comes from sys_accept() and AFAICS it doesn't carry a struck sock with it. > > Cc'ing

RE: [PATCH] net/mlx5: IPSec, fix 64-bit division correctly

> -Original Message- > From: Arnd Bergmann [mailto:a...@arndb.de] > Subject: [PATCH] net/mlx5: IPSec, fix 64-bit division correctly > > The new IPSec offload code introduced a build error: > > drivers/net/ethernet/mellanox/mlx5/core/en_accel/ipsec_rxtx.o: In function >

Re: [PATCH 2/2 net] cxgb4: ptp_clock_register() returns error pointers

On Mon, Jul 10, 2017 at 10:16:15AM +0300, Dan Carpenter wrote: > We're checking ptp_clock_register() for NULL but we should be checking > for error pointers. No. > diff --git a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_ptp.c > b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_ptp.c > index

[PATCH] wireless: iwlegacy: Constify attribute_group structures.

attribute_groups are not supposed to change at runtime. All functions working with attribute_groups provided by work with const attribute_group. So mark the non-const structs as const. Signed-off-by: Arvind Yadav --- drivers/net/wireless/intel/iwlegacy/4965-mac.c | 2

Re: [PATCH v2] net: axienet: add support for standard phy-mode binding

On Fri, Jul 07, 2017 at 10:16:31AM -0700, Florian Fainelli wrote: > On 07/06/2017 11:50 PM, Alvaro Gamez Machado wrote: > > Keep supporting proprietary "xlnx,phy-type" attribute and add support for > > MII connectivity to the PHY. > > > > Signed-off-by: Alvaro Gamez Machado

Re: [PATCH 1/2 net] ptp: fix error codes in ptp_clock_register()

On Mon, Jul 10, 2017 at 12:38:16PM +0300, Dan Carpenter wrote: > There were two buggy commits so I chose the ealier one. The other buggy No, you are mistaken. In the original patch, NULL or PTR_ERR were returned on error, and that was not a bug. If you want to correct the present version of

Re: [PATCH] brcmfmac: added LED triggers for transmit/receive

On 7 July 2017 at 16:09, Russell Joyce wrote: > Add three basic LED triggers to brcmfmac, based on those in mac80211: one > for transmit, one for receive, and one for combined transmit/receive. > > Signed-off-by: Russell Joyce 1) I think most

[PATCH] wireless: iwlegacy: constify attribute_group structures.

attribute_groups are not supposed to change at runtime. All functions working with attribute_groups provided by work with const attribute_group. So mark the non-const structs as const. Signed-off-by: Arvind Yadav --- drivers/net/wireless/intel/iwlegacy/3945-mac.c | 2

[PATCH] wireless: ipw2100: constify attribute_group structures.

attribute_groups are not supposed to change at runtime. All functions working with attribute_groups provided by work with const attribute_group. So mark the non-const structs as const. Signed-off-by: Arvind Yadav --- drivers/net/wireless/intel/ipw2x00/ipw2100.c | 2

[PATCH] net/mlx5: IPSec, fix 64-bit division correctly

The new IPSec offload code introduced a build error: drivers/net/ethernet/mellanox/mlx5/core/en_accel/ipsec_rxtx.o: In function `mlx5e_ipsec_build_inverse_table': ipsec_rxtx.c:(.text+0x556): undefined reference Another patch was added on top to fix the build error, but that introduced a new

Re: [PATCH 1/2 net] ptp: fix error codes in ptp_clock_register()

On Mon, Jul 10, 2017 at 11:21:03AM +0200, Richard Cochran wrote: > On Mon, Jul 10, 2017 at 10:11:37AM +0300, Dan Carpenter wrote: > > The ptp_clock_register() function returns NULL when it's #ifdefed out > > because CONFIG_PTP_1588_CLOCK is disabled. Otherwise, it's intended to > > return error

Re: [PATCH 1/2 net] ptp: fix error codes in ptp_clock_register()

On Mon, Jul 10, 2017 at 10:11:37AM +0300, Dan Carpenter wrote: > The ptp_clock_register() function returns NULL when it's #ifdefed out > because CONFIG_PTP_1588_CLOCK is disabled. Otherwise, it's intended to > return error pointers. Unfortunately, there are a couple paths where we > forget to

Re: [PATCH v 1/2] ravb: Add support for r8a7743 SoC

Hello! On 7/10/2017 4:20 AM, Rob Herring wrote: Add support for Gigabit Ethernet E-MAC on r8a7743 (RZ/G1M) SoC. Renesas RZ/G1M (R8A7743) SoC Ethernet AVB IP is identical to the R-Car Gen2 family. For the subject: "dt-bindings: net: ..." Signed-off-by: Biju Das

[PATCH] wireless: ipw2200: constify attribute_group structures.

attribute_groups are not supposed to change at runtime. All functions working with attribute_groups provided by work with const attribute_group. So mark the non-const structs as const. Signed-off-by: Arvind Yadav --- drivers/net/wireless/intel/ipw2x00/ipw2200.c | 2

Re: [PATCH 1/2 net] ptp: fix error codes in ptp_clock_register()

On Mon, Jul 10, 2017 at 10:11:37AM +0300, Dan Carpenter wrote: > The ptp_clock_register() function returns NULL when it's #ifdefed out > because CONFIG_PTP_1588_CLOCK is disabled. Otherwise, it's intended to > return error pointers. Unfortunately, there are a couple paths where we > forget to

Re: [PATCH v2 2/2] ARM: shmobile: defconfig: Enable Ethernet AVB

On Thu, Jul 06, 2017 at 08:05:43AM +, Chris Paterson wrote: > Hello Sergei, > > Thank you for your comments. > > > From: Sergei Shtylyov [mailto:sergei.shtyl...@cogentembedded.com] > > Sent: 05 July 2017 17:14 > > > > Hello! > > > > On 07/05/2017 06:56 PM, Biju Das wrote: > > > > > The

RE: [PATCH v 1/2] ravb: Add support for r8a7743 SoC

Hello, Thanks for the review. > -Original Message- > From: Rob Herring [mailto:r...@kernel.org] > Sent: 10 July 2017 02:20 > To: Biju Das > Cc: Mark Rutland ; Russell King > ; Sergei Shtylyov >

Re: [PATCH net] ip[6]: don't register inet[6]dev when dev is down

Le 08/07/2017 à 20:56, Cong Wang a écrit : > On Fri, Jul 7, 2017 at 5:39 AM, Nicolas Dichtel > wrote: [snip] >> - the patch is easy to backport in older kernel. >> > > Easy to backport doesn't mean easy to verify. ;) As David said, this > code is mess, especially for

Re: [PATCH net] ip[6]: don't register inet[6]dev when dev is down

Le 08/07/2017 à 20:44, Cong Wang a écrit : > On Sat, Jul 8, 2017 at 3:02 AM, David Miller wrote: [snip] >> Can you show exactly why the procfs state isn't cleaned up for >> these devices moving between namespaces? Maybe that is the real >> bug and a better place to fix this.

  1   2   >