* Re: [PATCH net-next v2] block/drbd: use nla_put_u64_64bit()
From: David Miller @ 2016-05-03 16:05 UTC (permalink / raw)
To: lars.ellenberg
Cc: nicolas.dichtel, netdev, philipp.reisner, drbd-dev, linux-kernel
In-Reply-To: <20160503100644.GE16459@soda.linbit>
From: Lars Ellenberg <lars.ellenberg@linbit.com>
Date: Tue, 3 May 2016 12:06:44 +0200
> Please just NOT use an additional "field",
> but always use 0 to pad.
You can't, it doesn't work.
We are adding a new field to every netlink protocol family that has this
alignment problem.
^ permalink raw reply
* Re: [PATCH net-next v2] block/drbd: use nla_put_u64_64bit()
From: David Miller @ 2016-05-03 16:06 UTC (permalink / raw)
To: lars.ellenberg
Cc: nicolas.dichtel, netdev, philipp.reisner, drbd-dev, linux-kernel
In-Reply-To: <20160503100644.GE16459@soda.linbit>
From: Lars Ellenberg <lars.ellenberg@linbit.com>
Date: Tue, 3 May 2016 12:06:44 +0200
> Whereas using some arbitrary value will be wrong,
> and will needlessly break userland.
It cannot break userland.
A fundamental property of netlink is that all code must silently
ignore netlink attributes it does not understand.
This is why netlink is easily extensible.
If code isn't doing that, it is broken and must be fixed.
^ permalink raw reply
* Re: [PATCH 0/2] sctp: Add GSO support
From: David Miller @ 2016-05-03 16:09 UTC (permalink / raw)
To: marcelo.leitner
Cc: netdev, vyasevich, nhorman, linux-sctp, David.Laight,
alexander.duyck
In-Reply-To: <20160503114918.GD5676@localhost.localdomain>
From: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
Date: Tue, 3 May 2016 08:49:18 -0300
> So this is just for pure tx path, no forwarding involved.
And if that GSO segment is looped back into the stack via the
loopback interface, the packet classifier mirror action, or
netfilter?
You cannot just GSO things and then not handle such packets
properly on receive.
^ permalink raw reply
* Re: [PATCH net-next V1 00/12] Mellanox 100G ethernet SRIOV Upgrades
From: David Miller @ 2016-05-03 16:12 UTC (permalink / raw)
To: saeedm; +Cc: netdev, ogerlitz, talal, eranbe
In-Reply-To: <1462284844-16926-1-git-send-email-saeedm@mellanox.com>
Please don't have two patch series pending for the same driver (mlx5) and
the same tree (net-next).
This makes things extremely confusing (is patch set #2 dependent upon #1?
what if I ask for changes to patch set #1?).
So always let the first patch series get fully resolved before sending
the second series.
I'm tossing this series out.
^ permalink raw reply
* Re: [PATCH net v3 4/5] dt: cpsw: phy-handle, phy_id, and fixed-link are mutually exclusive
From: Rob Herring @ 2016-05-03 16:14 UTC (permalink / raw)
To: David Rivshin (Allworx)
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, linux-omap-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, David Miller, Mugunthan V N,
Grygorii Strashko, Andrew Goodbody, Markus Brunner,
Nicolas Chauvet
In-Reply-To: <1461807767-4563-1-git-send-email-drivshin.allworx-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
On Wed, Apr 27, 2016 at 09:42:47PM -0400, David Rivshin (Allworx) wrote:
> From: David Rivshin <drivshin-5fOYsn7Fw8lBDgjK7y7TUQ@public.gmane.org>
>
> The phy-handle, phy_id, and fixed-link properties are mutually exclusive,
> and only one need be specified. Make this clear in the binding doc.
>
> Also mark the phy_id property as deprecated, as phy-handle should be
> used instead.
>
> Signed-off-by: David Rivshin <drivshin-5fOYsn7Fw8lBDgjK7y7TUQ@public.gmane.org>
> ---
>
> Changes since v2 [1]:
> - split from previous patch 2
> - marked the phy_id property as deprecated [3]
> - removed Rob Herring's Acked-by due to above change
>
> Changes since v1 [2]:
> - Rebased (no conflicts)
> - Added Tested-by from Nicolas Chauvet
> - Added Acked-by from Rob Herring for the binding change
>
> [1] http://patchwork.ozlabs.org/patch/613260/
> [2] http://patchwork.ozlabs.org/patch/560324/
> [3] https://lkml.org/lkml/2016/4/22/494
>
>
> Documentation/devicetree/bindings/net/cpsw.txt | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH net-next V1 00/12] Mellanox 100G ethernet SRIOV Upgrades
From: David Miller @ 2016-05-03 16:18 UTC (permalink / raw)
To: saeedm; +Cc: netdev, ogerlitz, talal, eranbe
In-Reply-To: <20160503.121254.1213266710265417601.davem@davemloft.net>
From: David Miller <davem@davemloft.net>
Date: Tue, 03 May 2016 12:12:54 -0400 (EDT)
>
> Please don't have two patch series pending for the same driver (mlx5) and
> the same tree (net-next).
>
> This makes things extremely confusing (is patch set #2 dependent upon #1?
> what if I ask for changes to patch set #1?).
>
> So always let the first patch series get fully resolved before sending
> the second series.
>
> I'm tossing this series out.
Sorry, I just realized this is a new version of the previous series.
What confused me is "V1", because this isn't "V1". Please don't number
things like that.
The first posting is implicitly "V1" and any subsequent version is
therefore "v2", "v3", and so on.
Thanks.
^ permalink raw reply
* Re: [PATCH net-next V1 00/12] Mellanox 100G ethernet SRIOV Upgrades
From: Saeed Mahameed @ 2016-05-03 16:20 UTC (permalink / raw)
To: David Miller
Cc: Saeed Mahameed, Linux Netdev List, Or Gerlitz, Tal Alon,
Eran Ben Elisha
In-Reply-To: <20160503.121254.1213266710265417601.davem@davemloft.net>
On Tue, May 3, 2016 at 7:12 PM, David Miller <davem@davemloft.net> wrote:
>
> Please don't have two patch series pending for the same driver (mlx5) and
> the same tree (net-next).
>
This is V1 of the the only ongoing series I have for net-next
what other series are you referring to ?
^ permalink raw reply
* Re: [PATCH net-next 0/4] net: hns: update DT properties according to Rob's comments
From: Rob Herring @ 2016-05-03 16:24 UTC (permalink / raw)
To: David Miller
Cc: Yisen.Zhuang, devicetree, netdev, linux-arm-kernel, pawel.moll,
mark.rutland, ijc+devicetree, galak, will.deacon, catalin.marinas,
yankejian, huangdaode, salil.mehta, lipeng321, liguozhu,
xieqianqian, xuwei5, linuxarm
In-Reply-To: <20160429.133949.1719521222260369497.davem@davemloft.net>
On Fri, Apr 29, 2016 at 01:39:49PM -0400, David Miller wrote:
> From: Yisen Zhuang <Yisen.Zhuang@huawei.com>
> Date: Thu, 28 Apr 2016 15:09:00 +0800
>
> > There are some inappropriate properties definition in hns DT. We update the definition
> > according to Rob's review comments and fix some typos in binding.
> >
> > For more details, please see individual patches.
>
> Series applied, thanks.
It would be nice to review patches addressing my comments before they
get applied. Can you please give series with DT bindings a few more days
for review before applying.
Rob
^ permalink raw reply
* Re: [PATCH net-next V1 00/12] Mellanox 100G ethernet SRIOV Upgrades
From: Saeed Mahameed @ 2016-05-03 16:28 UTC (permalink / raw)
To: David Miller
Cc: Saeed Mahameed, Linux Netdev List, Or Gerlitz, Tal Alon,
Eran Ben Elisha
In-Reply-To: <20160503.121845.38810507805302539.davem@davemloft.net>
On Tue, May 3, 2016 at 7:18 PM, David Miller <davem@davemloft.net> wrote:
> From: David Miller <davem@davemloft.net>
>
> The first posting is implicitly "V1" and any subsequent version is
> therefore "v2", "v3", and so on.
>
Didn't know that, I am used to send V1 as an update of the first posting
Will change that habit.
Thanks
^ permalink raw reply
* Re: pull request [net]: batman-adv 20160430
From: David Miller @ 2016-05-03 16:33 UTC (permalink / raw)
To: a
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
b.a.t.m.a.n-ZwoEplunGu2X36UT3dwllkB+6BGkLq7r
In-Reply-To: <20160503144229.GD11201-bY/dlpGjfuDhXIiyNabO3w@public.gmane.org>
From: Antonio Quartulli <a@unstable.cc>
Date: Tue, 3 May 2016 22:42:29 +0800
> Do you have any plan on merging net into net-next in the following days ?
>
> I am asking because I'd prefer to avoid you the hassle of dealing with the
> conflicts.
I'll try to do this in the next few days.
^ permalink raw reply
* Re: [PATCH net] vlan: Propagate MAC address changes properly
From: David Miller @ 2016-05-03 16:34 UTC (permalink / raw)
To: mmanning; +Cc: netdev
In-Reply-To: <5728C152.7090007@brocade.com>
From: Mike Manning <mmanning@brocade.com>
Date: Tue, 3 May 2016 16:18:42 +0100
> Given that this information is implicit in real_dev_addr
That's not the reason to make or not make the simplification I
asked you do.
You can add a multi-page comment to this code, and the confusing
tests are still rediculous.
Please add the boolean state as I asked you to.
^ permalink raw reply
* Re: [PATCH net v2] vlan: Propagate MAC address to VLANs unless explicitly set
From: David Miller @ 2016-05-03 16:36 UTC (permalink / raw)
To: mmanning; +Cc: netdev
In-Reply-To: <5728C1AC.3090708@brocade.com>
There is, at the very least, a two byte hole in the vlan_dev_priv structure.
Put the boolean there as I asked you to.
^ permalink raw reply
* Re: [PATCH net-next 0/4] net: hns: update DT properties according to Rob's comments
From: David Miller @ 2016-05-03 16:37 UTC (permalink / raw)
To: robh
Cc: Yisen.Zhuang, devicetree, netdev, linux-arm-kernel, pawel.moll,
mark.rutland, ijc+devicetree, galak, will.deacon, catalin.marinas,
yankejian, huangdaode, salil.mehta, lipeng321, liguozhu,
xieqianqian, xuwei5, linuxarm
In-Reply-To: <20160503162444.GA4087@rob-hp-laptop>
From: Rob Herring <robh@kernel.org>
Date: Tue, 3 May 2016 11:24:44 -0500
> On Fri, Apr 29, 2016 at 01:39:49PM -0400, David Miller wrote:
>> From: Yisen Zhuang <Yisen.Zhuang@huawei.com>
>> Date: Thu, 28 Apr 2016 15:09:00 +0800
>>
>> > There are some inappropriate properties definition in hns DT. We update the definition
>> > according to Rob's review comments and fix some typos in binding.
>> >
>> > For more details, please see individual patches.
>>
>> Series applied, thanks.
>
> It would be nice to review patches addressing my comments before they
> get applied. Can you please give series with DT bindings a few more days
> for review before applying.
I can't go more than a day or so days, I refuse to let patches rot in
my backlog for more than that. I get sometimes a hundred new patch
submissions a day and what you are asking me to do would make maintainence
untenable for everyone, sorry.
Just be quicker on the review, then there are no problems.
^ permalink raw reply
* Re: [PATCH v1 net] net/mlx4: Avoid wrong virtual mappings
From: David Miller @ 2016-05-03 16:41 UTC (permalink / raw)
To: hagaya
Cc: dledford, linux-rdma, netdev, okaya, timur, eli, ogerlitz, eranbe,
yishaih, talal, saeedm
In-Reply-To: <1461740820-15386-1-git-send-email-hagaya@mellanox.com>
From: Haggai Abramovsky <hagaya@mellanox.com>
Date: Wed, 27 Apr 2016 10:07:00 +0300
> @@ -419,7 +419,8 @@ static int set_rq_size(struct mlx4_ib_dev *dev, struct ib_qp_cap *cap,
> }
>
> static int set_kernel_sq_size(struct mlx4_ib_dev *dev, struct ib_qp_cap *cap,
> - enum mlx4_ib_qp_type type, struct mlx4_ib_qp *qp)
> + enum mlx4_ib_qp_type type, struct mlx4_ib_qp *qp,
> + int shrink_wqe)
> {
> int s;
>
Please use 'bool' and "true/false" for shrink_wqe.
^ permalink raw reply
* Re: [PATCH net-next v2] ravb: Remove rx buffer ALIGN
From: David Miller @ 2016-05-03 16:45 UTC (permalink / raw)
To: ykaneko0929
Cc: netdev, sergei.shtylyov, horms, magnus.damm, linux-renesas-soc
In-Reply-To: <1462115991-27241-1-git-send-email-ykaneko0929@gmail.com>
From: Yoshihiro Kaneko <ykaneko0929@gmail.com>
Date: Mon, 2 May 2016 00:19:51 +0900
> From: Kazuya Mizuguchi <kazuya.mizuguchi.ks@renesas.com>
>
> Aligning the reception data size is not required.
>
> Signed-off-by: Kazuya Mizuguchi <kazuya.mizuguchi.ks@renesas.com>
> Signed-off-by: Yoshihiro Kaneko <ykaneko0929@gmail.com>
> Tested-by: Simon Horman <horms+renesas@verge.net.au>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH net-next] fq_codel: add batch ability to fq_codel_drop()
From: David Miller @ 2016-05-03 16:47 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev, dave.taht, chromatix99
In-Reply-To: <1462146446.5535.236.camel@edumazet-glaptop3.roam.corp.google.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Sun, 01 May 2016 16:47:26 -0700
> From: Eric Dumazet <edumazet@google.com>
>
> In presence of inelastic flows and stress, we can call
> fq_codel_drop() for every packet entering fq_codel qdisc.
>
> fq_codel_drop() is quite expensive, as it does a linear scan
> of 4 KB of memory to find a fat flow.
> Once found, it drops the oldest packet of this flow.
>
> Instead of dropping a single packet, try to drop 50% of the backlog
> of this fat flow, with a configurable limit of 64 packets per round.
>
> TCA_FQ_CODEL_DROP_BATCH_SIZE is the new attribute to make this
> limit configurable.
>
> With this strategy the 4 KB search is amortized to a single cache line
> per drop [1], so fq_codel_drop() no longer appears at the top of kernel
> profile in presence of few inelastic flows.
>
> [1] Assuming a 64byte cache line, and 1024 buckets
>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
> Reported-by: Dave Taht <dave.taht@gmail.com>
> Cc: Jonathan Morton <chromatix99@gmail.com>
Applied, thanks Eric.
^ permalink raw reply
* Re: [PATCH v5 1/2] can: rcar_canfd: Add Renesas R-Car CAN FD driver
From: Rob Herring @ 2016-05-03 16:47 UTC (permalink / raw)
To: Ramesh Shanmugasundaram
Cc: mkl, wg, socketcan, pawel.moll, mark.rutland, ijc+devicetree,
galak, linux-renesas-soc, devicetree, linux-can, netdev,
chris.paterson2
In-Reply-To: <1461846188-31249-2-git-send-email-ramesh.shanmugasundaram@bp.renesas.com>
On Thu, Apr 28, 2016 at 01:23:07PM +0100, Ramesh Shanmugasundaram wrote:
> This patch adds support for the CAN FD controller found in Renesas R-Car
> SoCs. The controller operates in CAN FD only mode by default.
>
> CAN FD mode supports both Classical CAN & CAN FD frame formats. The
> controller supports ISO 11898-1:2015 CAN FD format only.
>
> This controller supports two channels and the driver can enable either
> or both of the channels.
>
> Driver uses Rx FIFOs (one per channel) for reception & Common FIFOs (one
> per channel) for transmission. Rx filter rules are configured to the
> minimum (one per channel) and it accepts Standard, Extended, Data &
> Remote Frame combinations.
>
> Note: There are few documentation errors in R-Car Gen3 Hardware User
> Manual v0.5E with respect to CAN FD controller. They are listed below:
>
> 1. CAN FD interrupt numbers 29 & 30 are listed as per channel
> interrupts. However, they are common to both channels (i.e.) they are
> global and channel interrupts respectively.
>
> 2. CANFD clock is derived from PLL1. This is not documented.
>
> 3. CANFD clock is further divided by (1/2) within the CAN FD controller.
> This is not documented.
>
> 4. The minimum value of NTSEG1 in RSCFDnCFDCmNCFG register is 2 Tq. It
> is specified 4 Tq in the manual.
>
> 5. The maximum number of message RAM area the controller can use is 3584
> bytes. It is specified 10752 bytes in the manual.
>
> Signed-off-by: Ramesh Shanmugasundaram <ramesh.shanmugasundaram@bp.renesas.com>
> ---
> .../devicetree/bindings/net/can/rcar_canfd.txt | 89 ++
What happened to my ack?
> drivers/net/can/Kconfig | 1 +
> drivers/net/can/Makefile | 1 +
> drivers/net/can/rcar/Kconfig | 11 +
> drivers/net/can/rcar/Makefile | 5 +
> drivers/net/can/rcar/rcar_canfd.c | 1624 ++++++++++++++++++++
> 6 files changed, 1731 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/net/can/rcar_canfd.txt
> create mode 100644 drivers/net/can/rcar/Kconfig
> create mode 100644 drivers/net/can/rcar/Makefile
> create mode 100644 drivers/net/can/rcar/rcar_canfd.c
^ permalink raw reply
* Re: [PATCH 0/2] sctp: Add GSO support
From: Marcelo Ricardo Leitner @ 2016-05-03 16:47 UTC (permalink / raw)
To: David Miller
Cc: netdev, vyasevich, nhorman, linux-sctp, David.Laight,
alexander.duyck
In-Reply-To: <20160503.120915.2184693151751282220.davem@davemloft.net>
On Tue, May 03, 2016 at 12:09:15PM -0400, David Miller wrote:
> From: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
> Date: Tue, 3 May 2016 08:49:18 -0300
>
> > So this is just for pure tx path, no forwarding involved.
>
> And if that GSO segment is looped back into the stack via the
> loopback interface, the packet classifier mirror action, or
> netfilter?
>
> You cannot just GSO things and then not handle such packets
> properly on receive.
Good point. It will fail if one uses AUTH due to the reason I mentioned
for GRO. I have to split the GSO packet upon rx too and that should do
it. Will post a v2 when I have it.
Thanks,
Marcelo
^ permalink raw reply
* Re: [PATCH v3 net-next 2/2] net: ethernet: enc28j60: add device tree support
From: Rob Herring @ 2016-05-03 16:51 UTC (permalink / raw)
To: Michael Heimpold
Cc: Jonathan Cameron, Andrew F . Davis, Mark Brown, netdev,
devicetree, Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala
In-Reply-To: <1461873975-6368-3-git-send-email-mhei@heimpold.de>
On Thu, Apr 28, 2016 at 10:06:15PM +0200, Michael Heimpold wrote:
> The following patch adds the required match table for device tree support
> (and while at, fix the indent). It's also possible to specify the
> MAC address in the DT blob.
>
> Also add the corresponding binding documentation file.
>
> Signed-off-by: Michael Heimpold <mhei@heimpold.de>
> ---
>
> Changelog:
>
> v3: * renamed and improved binding documentation as
> suggested by Rob Herring
>
> v2: * took care of Arnd Bergmann's review comments
> - allow to specify MAC address via DT
> - unconditionally define DT id table
> * increased the driver version minor number
> * driver author's email address bounces, removed from address list
>
> v1: * Initial submission
>
>
> .../devicetree/bindings/net/microchip,enc28j60.txt | 59 ++++++++++++++++++++++
Acked-by: Rob Herring <robh@kernel.org>
> drivers/net/ethernet/microchip/enc28j60.c | 20 ++++++--
> 2 files changed, 76 insertions(+), 3 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/net/microchip,enc28j60.txt
^ permalink raw reply
* Re: [PATCH] drivers: net: xgene: constify xgene_cle_ops structure
From: David Miller @ 2016-05-03 17:03 UTC (permalink / raw)
To: Julia.Lawall
Cc: isubramanian, kernel-janitors, kchudgar, netdev, linux-kernel
In-Reply-To: <1462106189-14277-1-git-send-email-Julia.Lawall@lip6.fr>
From: Julia Lawall <Julia.Lawall@lip6.fr>
Date: Sun, 1 May 2016 14:36:28 +0200
> The xgene_cle_ops structure is never modified, so declare it as const.
>
> Done with the help of Coccinelle.
>
> Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr>
Applied.
^ permalink raw reply
* Re: [PATCH] VSOCK: constify vsock_transport structure
From: David Miller @ 2016-05-03 17:03 UTC (permalink / raw)
To: Julia.Lawall
Cc: kernel-janitors, rjui, sbranden, jonmason, netdev,
linux-arm-kernel, bcm-kernel-feedback-list, linux-kernel
In-Reply-To: <1462106955-22131-1-git-send-email-Julia.Lawall@lip6.fr>
From: Julia Lawall <Julia.Lawall@lip6.fr>
Date: Sun, 1 May 2016 14:49:15 +0200
> The vsock_transport structure is never modified, so declare it as const.
>
> Done with the help of Coccinelle.
>
> Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr>
Applied.
^ permalink raw reply
* Re: [PATCH RFT 1/2] phylib: add device reset GPIO support
From: Rob Herring @ 2016-05-03 17:03 UTC (permalink / raw)
To: Sergei Shtylyov
Cc: grant.likely, devicetree, f.fainelli, netdev, frowand.list,
pawel.moll, mark.rutland, ijc+devicetree, galak, linux-kernel
In-Reply-To: <3641492.klKRrvS8tr@wasted.cogentembedded.com>
On Fri, Apr 29, 2016 at 01:12:54AM +0300, Sergei Shtylyov wrote:
> The PHY devices sometimes do have their reset signal (maybe even power
> supply?) tied to some GPIO and sometimes it also does happen that a boot
> loader does not leave it deasserted. So far this issue has been attacked
> from (as I believe) a wrong angle: by teaching the MAC driver to manipulate
> the GPIO in question; that solution, when applied to the device trees, led
> to adding the PHY reset GPIO properties to the MAC device node, with one
> exception: Cadence MACB driver which could handle the "reset-gpios" prop
> in a PHY device subnode. I believe that the correct approach is to teach
> the 'phylib' to get the MDIO device reset GPIO from the device tree node
> corresponding to this device -- which this patch is doing...
>
> Note that I had to modify the AT803x PHY driver as it would stop working
> otherwise as it made use of the reset GPIO for its own purposes...
>
> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
>
> ---
> Changes in version 2:
> - reformatted the changelog;
> - resolved rejects, refreshed the patch.
>
> Documentation/devicetree/bindings/net/phy.txt | 2 +
> Documentation/devicetree/bindings/net/phy.txt | 2 +
Acked-by: Rob Herring <robh@kernel.org>
> drivers/net/phy/at803x.c | 19 ++------------
> drivers/net/phy/mdio_bus.c | 4 +++
> drivers/net/phy/mdio_device.c | 27 +++++++++++++++++++--
> drivers/net/phy/phy_device.c | 33 ++++++++++++++++++++++++--
> drivers/of/of_mdio.c | 16 ++++++++++++
> include/linux/mdio.h | 3 ++
> include/linux/phy.h | 5 +++
> 8 files changed, 89 insertions(+), 20 deletions(-)
>
> Index: net-next/Documentation/devicetree/bindings/net/phy.txt
> ===================================================================
> --- net-next.orig/Documentation/devicetree/bindings/net/phy.txt
> +++ net-next/Documentation/devicetree/bindings/net/phy.txt
> @@ -35,6 +35,8 @@ Optional Properties:
> - broken-turn-around: If set, indicates the PHY device does not correctly
> release the turn around line low at the end of a MDIO transaction.
>
> +- reset-gpios: The GPIO phandle and specifier for the PHY reset signal.
> +
> Example:
>
> ethernet-phy@0 {
> Index: net-next/drivers/net/phy/at803x.c
> ===================================================================
> --- net-next.orig/drivers/net/phy/at803x.c
> +++ net-next/drivers/net/phy/at803x.c
> @@ -65,7 +65,6 @@ MODULE_LICENSE("GPL");
>
> struct at803x_priv {
> bool phy_reset:1;
> - struct gpio_desc *gpiod_reset;
> };
>
> struct at803x_context {
> @@ -271,22 +270,10 @@ static int at803x_probe(struct phy_devic
> {
> struct device *dev = &phydev->mdio.dev;
> struct at803x_priv *priv;
> - struct gpio_desc *gpiod_reset;
>
> priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
> if (!priv)
> return -ENOMEM;
> -
> - if (phydev->drv->phy_id != ATH8030_PHY_ID)
> - goto does_not_require_reset_workaround;
> -
> - gpiod_reset = devm_gpiod_get_optional(dev, "reset", GPIOD_OUT_LOW);
> - if (IS_ERR(gpiod_reset))
> - return PTR_ERR(gpiod_reset);
> -
> - priv->gpiod_reset = gpiod_reset;
> -
> -does_not_require_reset_workaround:
> phydev->priv = priv;
>
> return 0;
> @@ -361,14 +348,14 @@ static void at803x_link_change_notify(st
> */
> if (phydev->drv->phy_id == ATH8030_PHY_ID) {
> if (phydev->state == PHY_NOLINK) {
> - if (priv->gpiod_reset && !priv->phy_reset) {
> + if (phydev->mdio.reset && !priv->phy_reset) {
> struct at803x_context context;
>
> at803x_context_save(phydev, &context);
>
> - gpiod_set_value(priv->gpiod_reset, 1);
> + phy_device_reset(phydev, 1);
> msleep(1);
> - gpiod_set_value(priv->gpiod_reset, 0);
> + phy_device_reset(phydev, 0);
> msleep(1);
>
> at803x_context_restore(phydev, &context);
> Index: net-next/drivers/net/phy/mdio_bus.c
> ===================================================================
> --- net-next.orig/drivers/net/phy/mdio_bus.c
> +++ net-next/drivers/net/phy/mdio_bus.c
> @@ -35,6 +35,7 @@
> #include <linux/phy.h>
> #include <linux/io.h>
> #include <linux/uaccess.h>
> +#include <linux/gpio/consumer.h>
>
> #include <asm/irq.h>
>
> @@ -371,6 +372,9 @@ void mdiobus_unregister(struct mii_bus *
> if (!mdiodev)
> continue;
>
> + if (mdiodev->reset)
> + gpiod_put(mdiodev->reset);
> +
> mdiodev->device_remove(mdiodev);
> mdiodev->device_free(mdiodev);
> }
> Index: net-next/drivers/net/phy/mdio_device.c
> ===================================================================
> --- net-next.orig/drivers/net/phy/mdio_device.c
> +++ net-next/drivers/net/phy/mdio_device.c
> @@ -12,6 +12,8 @@
> #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
>
> #include <linux/errno.h>
> +#include <linux/gpio.h>
> +#include <linux/gpio/consumer.h>
> #include <linux/init.h>
> #include <linux/interrupt.h>
> #include <linux/kernel.h>
> @@ -103,6 +105,13 @@ void mdio_device_remove(struct mdio_devi
> }
> EXPORT_SYMBOL(mdio_device_remove);
>
> +void mdio_device_reset(struct mdio_device *mdiodev, int value)
> +{
> + if (mdiodev->reset)
> + gpiod_set_value(mdiodev->reset, value);
> +}
> +EXPORT_SYMBOL(mdio_device_reset);
> +
> /**
> * mdio_probe - probe an MDIO device
> * @dev: device to probe
> @@ -117,9 +126,16 @@ static int mdio_probe(struct device *dev
> struct mdio_driver *mdiodrv = to_mdio_driver(drv);
> int err = 0;
>
> - if (mdiodrv->probe)
> + if (mdiodrv->probe) {
> + /* Deassert the reset signal */
> + mdio_device_reset(mdiodev, 0);
> +
> err = mdiodrv->probe(mdiodev);
>
> + /* Assert the reset signal */
> + mdio_device_reset(mdiodev, 1);
> + }
> +
> return err;
> }
>
> @@ -129,9 +145,16 @@ static int mdio_remove(struct device *de
> struct device_driver *drv = mdiodev->dev.driver;
> struct mdio_driver *mdiodrv = to_mdio_driver(drv);
>
> - if (mdiodrv->remove)
> + if (mdiodrv->remove) {
> + /* Deassert the reset signal */
> + mdio_device_reset(mdiodev, 0);
> +
> mdiodrv->remove(mdiodev);
>
> + /* Assert the reset signal */
> + mdio_device_reset(mdiodev, 1);
> + }
> +
> return 0;
> }
>
> Index: net-next/drivers/net/phy/phy_device.c
> ===================================================================
> --- net-next.orig/drivers/net/phy/phy_device.c
> +++ net-next/drivers/net/phy/phy_device.c
> @@ -589,6 +589,9 @@ int phy_device_register(struct phy_devic
> if (err)
> return err;
>
> + /* Deassert the reset signal */
> + phy_device_reset(phydev, 0);
> +
> /* Run all of the fixups for this PHY */
> err = phy_scan_fixups(phydev);
> if (err) {
> @@ -604,9 +607,15 @@ int phy_device_register(struct phy_devic
> goto out;
> }
>
> + /* Assert the reset signal */
> + phy_device_reset(phydev, 1);
> +
> return 0;
>
> out:
> + /* Assert the reset signal */
> + phy_device_reset(phydev, 1);
> +
> mdiobus_unregister_device(&phydev->mdio);
> return err;
> }
> @@ -792,6 +801,9 @@ int phy_init_hw(struct phy_device *phyde
> {
> int ret = 0;
>
> + /* Deassert the reset signal */
> + phy_device_reset(phydev, 0);
> +
> if (!phydev->drv || !phydev->drv->config_init)
> return 0;
>
> @@ -997,6 +1009,9 @@ void phy_detach(struct phy_device *phyde
>
> put_device(&phydev->mdio.dev);
> module_put(bus->owner);
> +
> + /* Assert the reset signal */
> + phy_device_reset(phydev, 1);
> }
> EXPORT_SYMBOL(phy_detach);
>
> @@ -1596,9 +1611,16 @@ static int phy_probe(struct device *dev)
> /* Set the state to READY by default */
> phydev->state = PHY_READY;
>
> - if (phydev->drv->probe)
> + if (phydev->drv->probe) {
> + /* Deassert the reset signal */
> + phy_device_reset(phydev, 0);
> +
> err = phydev->drv->probe(phydev);
>
> + /* Assert the reset signal */
> + phy_device_reset(phydev, 1);
> + }
> +
> mutex_unlock(&phydev->lock);
>
> return err;
> @@ -1612,8 +1634,15 @@ static int phy_remove(struct device *dev
> phydev->state = PHY_DOWN;
> mutex_unlock(&phydev->lock);
>
> - if (phydev->drv->remove)
> + if (phydev->drv->remove) {
> + /* Deassert the reset signal */
> + phy_device_reset(phydev, 0);
> +
> phydev->drv->remove(phydev);
> +
> + /* Assert the reset signal */
> + phy_device_reset(phydev, 1);
> + }
> phydev->drv = NULL;
>
> return 0;
> Index: net-next/drivers/of/of_mdio.c
> ===================================================================
> --- net-next.orig/drivers/of/of_mdio.c
> +++ net-next/drivers/of/of_mdio.c
> @@ -44,6 +44,7 @@ static int of_get_phy_id(struct device_n
> static void of_mdiobus_register_phy(struct mii_bus *mdio,
> struct device_node *child, u32 addr)
> {
> + struct gpio_desc *gpiod;
> struct phy_device *phy;
> bool is_c45;
> int rc;
> @@ -52,10 +53,17 @@ static void of_mdiobus_register_phy(stru
> is_c45 = of_device_is_compatible(child,
> "ethernet-phy-ieee802.3-c45");
>
> + gpiod = fwnode_get_named_gpiod(&child->fwnode, "reset-gpios");
> + /* Deassert the reset signal */
> + if (!IS_ERR(gpiod))
> + gpiod_direction_output(gpiod, 0);
> if (!is_c45 && !of_get_phy_id(child, &phy_id))
> phy = phy_device_create(mdio, addr, phy_id, 0, NULL);
> else
> phy = get_phy_device(mdio, addr, is_c45);
> + /* Assert the reset signal again */
> + if (!IS_ERR(gpiod))
> + gpiod_set_value(gpiod, 1);
> if (IS_ERR(phy))
> return;
>
> @@ -75,6 +83,9 @@ static void of_mdiobus_register_phy(stru
> of_node_get(child);
> phy->mdio.dev.of_node = child;
>
> + if (!IS_ERR(gpiod))
> + phy->mdio.reset = gpiod;
> +
> /* All data is now stored in the phy struct;
> * register it */
> rc = phy_device_register(phy);
> @@ -92,6 +103,7 @@ static void of_mdiobus_register_device(s
> struct device_node *child, u32 addr)
> {
> struct mdio_device *mdiodev;
> + struct gpio_desc *gpiod;
> int rc;
>
> mdiodev = mdio_device_create(mdio, addr);
> @@ -104,6 +116,10 @@ static void of_mdiobus_register_device(s
> of_node_get(child);
> mdiodev->dev.of_node = child;
>
> + gpiod = fwnode_get_named_gpiod(&child->fwnode, "reset-gpios");
> + if (!IS_ERR(gpiod))
> + mdiodev->reset = gpiod;
> +
> /* All data is now stored in the mdiodev struct; register it. */
> rc = mdio_device_register(mdiodev);
> if (rc) {
> Index: net-next/include/linux/mdio.h
> ===================================================================
> --- net-next.orig/include/linux/mdio.h
> +++ net-next/include/linux/mdio.h
> @@ -11,6 +11,7 @@
>
> #include <uapi/linux/mdio.h>
>
> +struct gpio_desc;
> struct mii_bus;
>
> /* Multiple levels of nesting are possible. However typically this is
> @@ -37,6 +38,7 @@ struct mdio_device {
> /* Bus address of the MDIO device (0-31) */
> int addr;
> int flags;
> + struct gpio_desc *reset;
> };
> #define to_mdio_device(d) container_of(d, struct mdio_device, dev)
>
> @@ -69,6 +71,7 @@ void mdio_device_free(struct mdio_device
> struct mdio_device *mdio_device_create(struct mii_bus *bus, int addr);
> int mdio_device_register(struct mdio_device *mdiodev);
> void mdio_device_remove(struct mdio_device *mdiodev);
> +void mdio_device_reset(struct mdio_device *mdiodev, int value);
> int mdio_driver_register(struct mdio_driver *drv);
> void mdio_driver_unregister(struct mdio_driver *drv);
>
> Index: net-next/include/linux/phy.h
> ===================================================================
> --- net-next.orig/include/linux/phy.h
> +++ net-next/include/linux/phy.h
> @@ -769,6 +769,11 @@ static inline int phy_read_status(struct
> return phydev->drv->read_status(phydev);
> }
>
> +static inline void phy_device_reset(struct phy_device *phydev, int value)
> +{
> + mdio_device_reset(&phydev->mdio, value);
> +}
> +
> #define phydev_err(_phydev, format, args...) \
> dev_err(&_phydev->mdio.dev, format, ##args)
>
>
^ permalink raw reply
* Re: [PATCH nf-next 3/9] netfilter: conntrack: don't attempt to iterate over empty table
From: Pablo Neira Ayuso @ 2016-05-03 17:03 UTC (permalink / raw)
To: Florian Westphal; +Cc: netfilter-devel, netdev
In-Reply-To: <1461863628-23350-4-git-send-email-fw@strlen.de>
On Thu, Apr 28, 2016 at 07:13:42PM +0200, Florian Westphal wrote:
> Once we place all conntracks into same table iteration becomes more
> costly because the table contains conntracks that we are not interested
> in (belonging to other netns).
>
> So don't bother scanning if the current namespace has no entries.
>
> Signed-off-by: Florian Westphal <fw@strlen.de>
> ---
> net/netfilter/nf_conntrack_core.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/net/netfilter/nf_conntrack_core.c b/net/netfilter/nf_conntrack_core.c
> index 29fa08b..f2e75a5 100644
> --- a/net/netfilter/nf_conntrack_core.c
> +++ b/net/netfilter/nf_conntrack_core.c
> @@ -1428,6 +1428,9 @@ void nf_ct_iterate_cleanup(struct net *net,
>
> might_sleep();
>
> + if (atomic_read(&net->ct.count) == 0)
> + return;
This optimization gets defeated with just one single conntrack (ie.
net->ct.count == 1), so I wonder if this is practical thing.
At the cost of consuming more memory per conntrack, we may consider
adding a per-net list so this iteration doesn't become a problem.
> while ((ct = get_next_corpse(net, iter, data, &bucket)) != NULL) {
> /* Time to push up daises... */
> if (del_timer(&ct->timeout))
> --
> 2.7.3
>
> --
> To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 1/4] net: ethernet: gianfar: move to new ethtool api {get|set}_link_ksettings
From: David Miller @ 2016-05-03 17:04 UTC (permalink / raw)
To: tremyfr
Cc: pantelis.antoniou, vbordug, claudiu.manoil, leoli, treding,
netdev, linux-kernel, linuxppc-dev
In-Reply-To: <1462115291-11372-1-git-send-email-tremyfr@gmail.com>
From: Philippe Reynes <tremyfr@gmail.com>
Date: Sun, 1 May 2016 17:08:08 +0200
> The ethtool api {get|set}_settings is deprecated.
> We move the gianfar driver to new api {get|set}_link_ksettings.
>
> Signed-off-by: Philippe Reynes <tremyfr@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH 2/4] net: ethernet: ucc: move to new ethtool api {get|set}_link_ksettings
From: David Miller @ 2016-05-03 17:04 UTC (permalink / raw)
To: tremyfr
Cc: pantelis.antoniou, vbordug, claudiu.manoil, leoli, treding,
netdev, linux-kernel, linuxppc-dev
In-Reply-To: <1462115291-11372-2-git-send-email-tremyfr@gmail.com>
From: Philippe Reynes <tremyfr@gmail.com>
Date: Sun, 1 May 2016 17:08:09 +0200
> The ethtool api {get|set}_settings is deprecated.
> We move the ucc driver to new api {get|set}_link_ksettings.
>
> Signed-off-by: Philippe Reynes <tremyfr@gmail.com>
Applied.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox