Re: OMAP4430 SDP with KS8851: very slow networking

On Fri, Dec 07, 2018 at 11:03:12AM -0800, Tony Lindgren wrote: > * Tony Lindgren [181207 18:14]: > > Hi, > > > > * Russell King - ARM Linux [181207 18:01]: > > > Hi Tony, > > > > > > You know most of what's been going on from IRC, but here

Re: OMAP4430 SDP with KS8851: very slow networking

Hi Tony, You know most of what's been going on from IRC, but here's the patch which gets me: 1) working interrupts for networking 2) solves the stuck-wakeup problem It also contains some of the debug bits I added. I think what this means is that we should strip out ec0daae685b2 ("gpio: omap:

Re: [RFC PATCH 4/6] dt-bindings: update mvneta binding document

On Fri, Dec 07, 2018 at 05:30:52PM +0530, Kishon Vijay Abraham I wrote: > Hi, > > On 07/12/18 5:03 PM, Russell King - ARM Linux wrote: > > On Fri, Dec 07, 2018 at 04:43:27PM +0530, Kishon Vijay Abraham I wrote: > >> Russell, > >> > >> No, I haven't merged

Re: [RFC PATCH 4/6] dt-bindings: update mvneta binding document

On Fri, Dec 07, 2018 at 04:43:27PM +0530, Kishon Vijay Abraham I wrote: > Russell, > > No, I haven't merged patches from this series. That would have failed > compilation since Grygorii modified enum phy_mode which is used in this > series. > You have also noted this in your cover letter. Ok,

Re: [RFC PATCH 4/6] dt-bindings: update mvneta binding document

On Fri, Dec 07, 2018 at 09:37:54AM +0530, Kishon Vijay Abraham I wrote: > Hi Russell, > > On 05/12/18 9:00 PM, Rob Herring wrote: > > On Wed, Dec 5, 2018 at 5:00 AM Russell King - ARM Linux > > wrote: > >> > >> On Mon, Dec 03, 2018 at 05:54:55PM -0600,

Re: OMAP4430 SDP with KS8851: very slow networking

On Thu, Dec 06, 2018 at 08:31:54AM -0800, Tony Lindgren wrote: > Hi, > > * Russell King - ARM Linux [181206 13:23]: > > It looks very much like a receive problem - in that the board is not > > always aware of a packet having been received until it attempts to > >

OMAP4430 SDP with KS8851: very slow networking

Hi, I'm experiencing very slow networking on my OMAP4430 SDP board, which uses the SPI ethernet chip KS8851. The initial symptom I noticed is that tftping the 3MB kernel image inside Linux takes more than 5 minutes. Running tcpdump on the tftp server shows: 13:13:29.018377 IP

Re: [RFC PATCH 4/6] dt-bindings: update mvneta binding document

On Mon, Dec 03, 2018 at 05:54:55PM -0600, Rob Herring wrote: > On Mon, Nov 12, 2018 at 12:31:02PM +, Russell King wrote: > > Signed-off-by: Russell King > > Needs a better subject and a commit msg. Hmm, not sure why it didn't contain: "dt-bindings: net: mvneta: add phys property Add an

Re: [RFC PATCH] net: mvpp2: fix detection of 10G SFP modules

On Tue, Dec 04, 2018 at 12:19:54PM +0200, Baruch Siach wrote: > Hi Russell, > > On Thu, Nov 29, 2018 at 10:00:43PM +, Russell King - ARM Linux wrote: > > On Thu, Nov 29, 2018 at 11:31:23AM -0800, Florian Fainelli wrote: > > > On 11/29/2018 4:4

Re: [RFC PATCH] net: mvpp2: fix detection of 10G SFP modules

On Thu, Nov 29, 2018 at 11:31:23AM -0800, Florian Fainelli wrote: > > > On 11/29/2018 4:49 AM, Baruch Siach wrote: > > The mvpp2_phylink_validate() relies on the interface field of > > phylink_link_state to determine valid link modes. However, when called > > from phylink_sfp_module_insert()

Re: [PATCH] net: phy: sfp: correct store of detected link modes

On Thu, Nov 29, 2018 at 02:30:53PM +0200, Baruch Siach wrote: > Hi Russell, > > Russell King - ARM Linux writes: > > On Thu, Nov 29, 2018 at 12:40:11PM +0200, Baruch Siach wrote: > >> The link modes that sfp_parse_support() detects are stored in the > >> 'modes' b

Re: [PATCH] net: phy: sfp: correct store of detected link modes

On Thu, Nov 29, 2018 at 12:40:11PM +0200, Baruch Siach wrote: > The link modes that sfp_parse_support() detects are stored in the > 'modes' bitmap. There is no reason to make an exception for 1000Base-PX > or 1000Base-BX10. I think you may be carrying some local patch, have an incorrect merge, or

Re: [RFC PATCH 5/6] net: marvell: neta: add support for 2500base-X

On Wed, Nov 14, 2018 at 02:18:14PM +0530, Kishon Vijay Abraham I wrote: > Hi, > > On 12/11/18 6:01 PM, Russell King wrote: > > Signed-off-by: Russell King > > --- > > drivers/net/ethernet/marvell/mvneta.c | 58 > > ++- > > 1 file changed, 51 insertions(+), 7

Re: [RFC PATCH 0/6] Armada 38x comphy driver to support 2.5Gbps networking

On Wed, Nov 14, 2018 at 01:39:29PM +0530, Kishon Vijay Abraham I wrote: > Hi, > > On 12/11/18 5:59 PM, Russell King - ARM Linux wrote: > > Hi, > > > > This series adds support for dynamically switching between 1Gbps > > and 2.5Gbps networking for the Marvell Arma

[RFC PATCH 0/6] Armada 38x comphy driver to support 2.5Gbps networking

Hi, This series adds support for dynamically switching between 1Gbps and 2.5Gbps networking for the Marvell Armada 38x SoCs, tested on Armada 388 on the Clearfog platform. This is necessary to be able to connect (eg) a Clearfog platform with a Macchiatobin platform via the SFP sockets, as

Re: [PATCH RFC net-next 0/3] net: phy: sfp: Warn when using generic PHY driver

On Tue, Nov 06, 2018 at 04:09:35PM -0800, Florian Fainelli wrote: > On 11/6/18 4:03 PM, Russell King - ARM Linux wrote: > > On Tue, Nov 06, 2018 at 03:38:44PM -0800, David Miller wrote: > >> From: Florian Fainelli > >> Date: Tue, 6 Nov 2018 15:29:10 -0800 > >

Re: [PATCH RFC net-next 0/3] net: phy: sfp: Warn when using generic PHY driver

On Tue, Nov 06, 2018 at 03:38:44PM -0800, David Miller wrote: > From: Florian Fainelli > Date: Tue, 6 Nov 2018 15:29:10 -0800 > > > This patch series allows warning an user that the generic PHY driver(s) > > are used when a SFP incorporates a PHY (e.g: 1000BaseT SFP) which is > > likely not

Re: [PATCH net-next 3/4] net: phy-c45: Implement reset/suspend/resume callbacks

On Tue, Oct 23, 2018 at 11:28:09AM +0100, Jose Abreu wrote: > On 23-10-2018 11:20, Russell King - ARM Linux wrote: > > I have no idea what you're proposing there - your patches weren't copied > > to me. > > They just set / unset MDIO_CTRL1_LPOWER bit in PCS. I find that >

Re: [PATCH net-next 3/4] net: phy-c45: Implement reset/suspend/resume callbacks

On Tue, Oct 23, 2018 at 11:17:50AM +0100, Jose Abreu wrote: > On 22-10-2018 18:13, Florian Fainelli wrote: > > On 10/22/18 8:48 AM, Russell King - ARM Linux wrote: > >> On Mon, Oct 22, 2018 at 01:47:48PM +0100, Jose Abreu wrote: > >>> Hello, > >>> &g

Re: [PATCH net-next 3/4] net: phy-c45: Implement reset/suspend/resume callbacks

On Mon, Oct 22, 2018 at 01:47:48PM +0100, Jose Abreu wrote: > Hello, > > On 22-10-2018 13:28, Andrew Lunn wrote: > >> EXPORT_SYMBOL_GPL(gen10g_resume); > >> @@ -327,7 +381,7 @@ struct phy_driver genphy_10g_driver = { > >>.phy_id = 0x, > >>.phy_id_mask= 0x, >

Re: [RFC PATCH] skb: Define NET_IP_ALIGN based on CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS

On Thu, Oct 04, 2018 at 07:43:59PM +0200, Ard Biesheuvel wrote: > (+ Arnd, Russell, Catalin, Will) > > On 4 October 2018 at 19:36, Ben Hutchings > wrote: > > NET_IP_ALIGN is supposed to be defined as 0 if DMA writes to an > > unaligned buffer would be more expensive than CPU access to unaligned

Re: [PATCH] net: phy: phylink: fix SFP interface autodetection

On Sat, Sep 22, 2018 at 10:09:44PM +0300, Baruch Siach wrote: > When connecting a PHY to phylink use the detected interface. Otherwise, > the link fails to come up when the configured 'phy-mode' differs from > the SFP detected mode. > > This fixes 1GB SFP module link up on eth3 of the

Re: [PATCH] net: phy: phylink: fix SFP interface autodetection

On Mon, Sep 17, 2018 at 05:19:57PM +0300, Baruch Siach wrote: > When the switching to the SFP detected link mode update the main > link_interface field as well. Otherwise, the link fails to come up when > the configured 'phy-mode' defers from the SFP detected mode. > > This fixes 1GB SFP module

Re: [offlist] Re: Crash in netlink/sk_filter_trim_cap on ARMv7 on 4.18rc1

On Fri, Aug 17, 2018 at 02:40:19PM +0200, Daniel Borkmann wrote: > I'd have one potential bug suspicion, for the 4.18 one you were trying, > could you run with the below patch to see whether it would help? I think this is almost certainly the problem - looking at the history, it seems that the

Re: [offlist] Re: Crash in netlink/sk_filter_trim_cap on ARMv7 on 4.18rc1

On Thu, Aug 16, 2018 at 10:35:16PM +0200, Marc Haber wrote: > On Mon, Jun 25, 2018 at 05:41:27PM +0100, Peter Robinson wrote: > > So with that and the other fix there was no improvement, with those > > and the BPF JIT disabled it works, I'm not sure if the two patches > > have any effect with the

Re: [PATCH] net: phy: sftp: print debug message with text, not numbers

You might want to fix the subject line. On Wed, Aug 08, 2018 at 08:54:12PM +0200, Andrew Lunn wrote: > Convert the state numbers, device state, etc from numbers to strings > when printing debug messages. > > Signed-off-by: Andrew Lunn > --- > drivers/net/phy/sfp.c | 76

Re: Is it currently possible to connect SFP to dsa port?

On Wed, Aug 08, 2018 at 03:00:13PM +0200, Marek Behún wrote: > Btw: some SFP modules can operate in 2500BASE-X mode. Currently the SFP > driver does not support this, and there even isn't code in the > mainline kernel for mvneta to switch to 2500BASEX. On Armada 3720 this > has to be done by

Re: [PATCH 00/14] ARM BPF jit compiler improvements

On Thu, Jul 12, 2018 at 11:12:45PM +0200, Daniel Borkmann wrote: > On 07/12/2018 11:02 PM, Russell King - ARM Linux wrote: > > On Thu, Jul 12, 2018 at 09:02:41PM +0200, Daniel Borkmann wrote: > >> Applied to bpf-next, thanks a lot Russell! > > > > Thanks, I've just

Re: [PATCH 00/14] ARM BPF jit compiler improvements

On Thu, Jul 12, 2018 at 09:02:41PM +0200, Daniel Borkmann wrote: > Applied to bpf-next, thanks a lot Russell! Thanks, I've just sent four more patches, which is the sum total of what I'm intending to send for BPF improvements for the next merge window. -- RMK's Patch system:

[PATCH net-next 0/4] Further ARM BPF jit compiler improvements

Four further jit compiler improves for 32-bit ARM. arch/arm/net/bpf_jit_32.c | 120 -- 1 file changed, 73 insertions(+), 47 deletions(-) -- RMK's Patch system: http://www.armlinux.org.uk/developer/patches/ FTTC broadband for 0.8mile line in suburbia:

[PATCH 00/14] ARM BPF jit compiler improvements

Hi, This series improves the ARM BPF JIT compiler by: - enumerating the stack layout rather than using constants that happen to be multiples of four - rejig the BPF "register" accesses to use negative numbers instead of positive, which could be confused with register numbers in the bpf2a32

Re: [PATCH net-next 01/13] ARM: net: bpf: enumerate the JIT scratch stack layout

On Tue, Jul 10, 2018 at 08:30:04PM +0200, Daniel Borkmann wrote: > Hi Russell, > > thanks a lot for your work on the arm32 JIT! > > On 07/10/2018 02:36 PM, Russell King wrote: > > Enumerate the contents of the JIT scratch stack layout used for storing > > some of the JITs 64-bit registers, tail

Re: [PATCH net-next 13/13] ARM: net: bpf: use double-word load/stores where available

On Tue, Jul 10, 2018 at 10:03:33AM -0700, Olof Johansson wrote: > Hi Russell, > > @@ -663,13 +679,27 @@ static inline void emit_a32_mov_r(const s8 dst, const > > s8 src, > > static inline void emit_a32_mov_r64(const bool is64, const s8 dst[], > > const s8 src[],

[PATCH 00/13] ARM BPF jit compiler improvements

Hi, This series improves the ARM BPF JIT compiler by: - enumerating the stack layout rather than using constants that happen to be multiples of four - rejig the BPF "register" accesses to use negative numbers instead of positive, which could be confused with register numbers in the bpf2a32

Re: [offlist] Re: Crash in netlink/sk_filter_trim_cap on ARMv7 on 4.18rc1

On Thu, Jul 05, 2018 at 12:41:54AM +0100, Russell King - ARM Linux wrote: > Subject says offlist, but this isn't... > > On Wed, Jul 04, 2018 at 08:33:20AM +0100, Peter Robinson wrote: > > Sorry for the delay on this from my end. I noticed there was some bpf > > bits land

Re: [offlist] Re: Crash in netlink/sk_filter_trim_cap on ARMv7 on 4.18rc1

Subject says offlist, but this isn't... On Wed, Jul 04, 2018 at 08:33:20AM +0100, Peter Robinson wrote: > Sorry for the delay on this from my end. I noticed there was some bpf > bits land in the last net fixes pull request landed Monday so I built > a kernel with the JIT reenabled. It seems it's

Re: [PATCH net-next 1/2] net: phy: sfp: make the i2c-bus property really optional

On Thu, May 17, 2018 at 03:04:06PM +0200, Andrew Lunn wrote: > On Thu, May 17, 2018 at 02:56:48PM +0200, Antoine Tenart wrote: > > Hi Andrew, > > > > On Thu, May 17, 2018 at 02:41:28PM +0200, Andrew Lunn wrote: > > > On Thu, May 17, 2018 at 10:29:06AM +0200, Antoine Tenart wrote: > > > > The

Re: [PATCH net-next 1/2] net: phy: sfp: make the i2c-bus property really optional

On Thu, May 17, 2018 at 02:41:28PM +0200, Andrew Lunn wrote: > On Thu, May 17, 2018 at 10:29:06AM +0200, Antoine Tenart wrote: > > The SFF,SFP documentation is clear about making all the DT properties, > > with the exception of the compatible, optional. In practice this is not > > the case and

Re: [PATCH net-next v3 00/10] net: mvpp2: phylink conversion

On Thu, May 17, 2018 at 10:29:29AM +0200, Antoine Tenart wrote: > Since v2: > - Removed the SFP description from the DB boards, as their SFP cages > are wired properly. We now use fixed-link. I think you mean "improperly" here. -- RMK's Patch system:

Re: [PATCH net-next v2 3/9] net: phy: phylink: Poll link GPIOs

On Thu, May 10, 2018 at 01:17:31PM -0700, Florian Fainelli wrote: > From: Russell King > > When using a fixed link with a link GPIO, we need to poll that GPIO to > determine link state changes. This is consistent with what fixed_phy.c does. > > Signed-off-by: Florian

Re: [PATCH net-next v2 03/13] net: phy: sfp: warn the user when no tx_disable pin is available

On Sat, May 05, 2018 at 10:52:42PM +0200, Andrew Lunn wrote: > On Sat, May 05, 2018 at 01:38:31PM -0700, Florian Fainelli wrote: > > On May 4, 2018 10:14:25 AM PDT, Andrew Lunn wrote: > > >On Fri, May 04, 2018 at 10:07:53AM -0700, Florian Fainelli wrote: > > >> On 05/04/2018 06:56

Re: [PATCH net-next] net: phy: sfp: handle cases where neither BR,min nor BR,max is given

On Sat, May 05, 2018 at 01:35:34PM -0700, Florian Fainelli wrote: > On May 4, 2018 8:21:03 AM PDT, Antoine Tenart > wrote: > >When computing the bitrate using values read from an SFP module EEPROM, > >we use the nominal BR plus BR,min and BR,max to determine the >

Re: [PATCH net-next v2 06/13] phy: add 2.5G SGMII mode to the phy_mode enum

rvell Comphy code from my tree and transition to the bootlin Comphy code instead. Of course, the perfect solution would be to get the whole series merged, but I'm just thinking about the situation where we're still discussing points when the next merge window opens. Thanks. > --- > include/linux/

Re: [PATCH net-next] net: phy: sfp: handle cases where neither BR,min nor BR,max is given

On Fri, May 04, 2018 at 05:21:03PM +0200, Antoine Tenart wrote: > When computing the bitrate using values read from an SFP module EEPROM, > we use the nominal BR plus BR,min and BR,max to determine the > boundaries. But in some cases BR,min and BR,max aren't provided, which > led the SFP code to

Re: [PATCH net] net: phy: sfp: fix the BR,min computation

On Fri, May 04, 2018 at 05:10:54PM +0200, Antoine Tenart wrote: > In an SFP EEPROM values can be read to get information about a given SFP > module. One of those is the bitrate, which can be determined using a > nominal bitrate in addition with min and max values (in %). The SFP code > currently

Re: [PATCH net-next v2 03/13] net: phy: sfp: warn the user when no tx_disable pin is available

On Fri, May 04, 2018 at 03:56:33PM +0200, Antoine Tenart wrote: > In case no Tx disable pin is available the SFP modules will always be > emitting. This could be an issue when using modules using laser as their > light source as we would have no way to disable it when the fiber is > removed. This

Re: [PATCH net-next v2 02/13] net: phy: sfp: handle non-wired SFP connectors

On Fri, May 04, 2018 at 03:56:32PM +0200, Antoine Tenart wrote: > SFP connectors can be solder on a board without having any of their pins > (LOS, i2c...) wired. In such cases the SFP link state cannot be guessed, > and the overall link status reporting is left to other layers. > > In order to

BUG: DSA blocks (some?) multicast traffic

sure. I'm pretty sure that it used to work at some point, as I'm a heavy user of IPv6 internally, and I'm quite certain that I would have noticed a failure such as this. The setup on the target is eth2 is part of a Linux bridge device. -- RMK's Patch system: http://www.armlinux.org.uk/devel

Re: [PATCH v2 2/2] net: mvneta: improve suspend/resume

On Fri, Mar 30, 2018 at 06:36:15PM +0800, Jisheng Zhang wrote: > Current suspend/resume implementation reuses the mvneta_open() and > mvneta_close(), but it could be optimized to take only necessary > actions during suspend/resume. > > One obvious problem of current implementation is: after

Re: [EXT] [PATCH net-next v2 0/2] phylink: API changes

ay, March 29, 2018 1:44 AM > To: netdev@vger.kernel.org > Cc: Florian Fainelli <f.faine...@gmail.com>; Thomas Petazzoni > <thomas.petazz...@free-electrons.com>; Andrew Lunn <and...@lunn.ch>; David S. > Miller <da...@davemloft.net>; Russell King <rmk+ker...

Re: [PATCH net-next 2/2] sfp/phylink: move module EEPROM ethtool access into netdev core ethtool

vers/net/ethernet/marvell/mvneta.c | 18 -- > drivers/net/phy/phylink.c | 28 > drivers/net/phy/sfp-bus.c | 6 ++ > include/linux/netdevice.h | 3 +++ > include/linux/phylink.h | 3 --- > n

Re: [PATCH net-next 1/2] net: phy: phylink: Provide PHY interface to mac_link_{up,down}

ed-off-by: Florian Fainelli <f.faine...@gmail.com> Similar comments to previous version wrt documentation, but... Acked-by: Russell King <rmk+ker...@armlinux.org.uk> > --- > drivers/net/ethernet/marvell/mvneta.c | 4 +++- > drivers/net/phy/phylink.c | 4 +++- > incl

Re: [PATCH] sfp: allow cotsworks modules

On Wed, Mar 28, 2018 at 09:19:01AM -0700, Joe Perches wrote: > On Wed, 2018-03-28 at 11:41 +0100, Russell King - ARM Linux wrote: > > On Wed, Mar 28, 2018 at 03:33:57AM -0700, Joe Perches wrote: > > > On Wed, 2018-03-28 at 11:18 +0100, Russell King wrote: > > &g

Re: [PATCH] sfp: allow cotsworks modules

On Wed, Mar 28, 2018 at 03:33:57AM -0700, Joe Perches wrote: > On Wed, 2018-03-28 at 11:18 +0100, Russell King wrote: > > Cotsworks modules fail the checksums - it appears that Cotsworks > > reprograms the EEPROM at the end of production with the final product > > information (serial, date code,

Re: [PATCH net-next 2/4] net: phy: phylink: Provide PHY interface to mac_link_{up,down}

Florian Fainelli <f.faine...@gmail.com> > --- > drivers/net/ethernet/marvell/mvneta.c | 4 +++- > drivers/net/phy/phylink.c | 6 +- > include/linux/phylink.h | 10 -- > 3 files changed, 16 insertions(+), 4 deletions(-) > > diff --git

Re: [PATCH net-next 3/4] net: dsa: Plug in PHYLINK support

w others as well. Maybe it makes sense to pull in that patch? > > To make this generic, we would have to have net_device carry a reference > to a phylink instance, which I would rather not do. Were you possibly > referring to this patch set: > > http://git.armlinux.org.

Re: [EXT] Re: [PATCH net-next 02/10] net: phy: phylink: allow 10GKR interface to use in-band negotiation

<antoine.ten...@bootlin.com>; Russell King - ARM Linux > > <li...@armlinux.org.uk>; da...@davemloft.net; kis...@ti.com; > > gregory.clem...@bootlin.com; ja...@lakedaemon.net; > > sebastian.hesselba...@gmail.com; netdev@vger.kernel.org; linux- > > ker...@vg

Re: [PATCH net-next 02/10] net: phy: phylink: allow 10GKR interface to use in-band negotiation

On Mon, Mar 19, 2018 at 02:10:09PM +0100, Antoine Tenart wrote: > Hi Andrew, > > On Mon, Mar 19, 2018 at 01:59:53PM +0100, Andrew Lunn wrote: > > > > If they don't have PHYs, how are the connected to the outside world? > > On 7k/8k you have the following scheme for 10G only interfaces: > >

Re: [EXT] Re: [PATCH net-next 02/10] net: phy: phylink: allow 10GKR interface to use in-band negotiation

On Mon, Mar 19, 2018 at 01:01:07PM +, Yan Markman wrote: > The DTS-patch for this board (in "old" format) is attached > > > Yan Markman > Tel. 05-44732819 > > > -Original Message- > From: Stefan Chulski > Sent: Monday, March 19, 2018 2:

Re: [PATCH net-next 02/10] net: phy: phylink: allow 10GKR interface to use in-band negotiation

On Mon, Mar 19, 2018 at 09:52:52AM +0100, Antoine Tenart wrote: > Hi Russell, > > On Fri, Mar 16, 2018 at 03:53:07PM +, Russell King - ARM Linux wrote: > > On Fri, Mar 16, 2018 at 11:33:43AM +0100, Antoine Tenart wrote: > > > The PHY mode 10GKR can use in-band negotiat

Re: [PATCH net-next 03/10] net: mvpp2: phylink support

On Fri, Mar 16, 2018 at 11:33:44AM +0100, Antoine Tenart wrote: > +static void mvpp2_phylink_validate(struct net_device *dev, > +unsigned long *supported, > +struct phylink_link_state *state) > +{ > +

Re: [PATCH net-next 02/10] net: phy: phylink: allow 10GKR interface to use in-band negotiation

On Fri, Mar 16, 2018 at 11:33:43AM +0100, Antoine Tenart wrote: > The PHY mode 10GKR can use in-band negotiation. This patches allows this > mode to be used with MLO_AN_INBAND in phylink. > > Signed-off-by: Antoine Tenart > --- > drivers/net/phy/phylink.c | 3 ++- >

Re: [PATCH net-next 3/4] dt-bindings: add maximum power level to SFP binding

Hi Rob, This patch, and the patches that make use of it have now been merged into their respective trees, but I note that you haven't reviewed this patch. Obviously, providing an ack is now moot, but it would still be good for a response before 4.16-final is released. On Tue, Feb 27, 2018 at

[PATCH net-next 0/4] SFP updates

s.c | 162 ++ drivers/net/phy/sfp.c | 150 +--- include/linux/sfp.h | 18 +-- 5 files changed, 243 insertions(+), 125 deletions(-) -- RMK's Patch system: http://www.armlinux.org

Re: handling of phy_stop() and phy_stop_machine() in phylib

On Wed, Feb 07, 2018 at 09:56:37PM +0100, Heiner Kallweit wrote: > Am 04.02.2018 um 03:48 schrieb Florian Fainelli: > > > > > > On 02/03/2018 03:58 PM, Heiner Kallweit wrote: > >> Am 03.02.2018 um 21:17 schrieb Andrew Lunn: > >>> On Sat, Feb 03, 2018 at 05:41:54PM +0100, Heiner Kallweit wrote: >

Re: Potential issue with f5e64032a799 "net: phy: fix resume handling"

If a link is down the network driver may decide to runtime-suspend the PHY > (power it down). In case of runtime pm I'd say we need to keep irq and > workqueue active to be able to react if a cable is plugged in and the PHY > wakes up automatically and establishes a link. Maybe a better solut

Re: [PATCH net-next v5 0/4] net: mvpp2: 1000BaseX and 2500BaseX support

On Fri, Jan 12, 2018 at 08:51:26AM +0100, Antoine Tenart wrote: > Hi all, > > This series adds 1000BaseX and 2500BaseX support to the Marvell PPv2 > driver. In order to use it, the 2.5 SGMII mode is added in the Marvell > common PHY driver (cp110-comphy). > > This was tested on a mcbin. > > All

Re: [PATCH v2 00/19] prevent bounds-check bypass via speculative execution

pace control. That by itself is not sufficient for > attack (per current understanding) [3], but it is a necessary > pre-condition. So 'hygiene' refers to cleaning up those suspect > pointers regardless of whether they are usable as a gadget. > > These patches are also be available

Re: [PATCH] net: phy: Fix phy_modify() semantic difference fallout

On Thu, Jan 11, 2018 at 05:00:03PM +0100, Geert Uytterhoeven wrote: > On Thu, Jan 11, 2018 at 4:54 PM, Geert Uytterhoeven > <ge...@linux-m68k.org> wrote: > > On Thu, Jan 11, 2018 at 4:53 PM, Russell King - ARM Linux > > <li...@armlinux.org.uk> wrote: > >> O

Re: [PATCH] net: phy: Fix phy_modify() semantic difference fallout

On Thu, Jan 11, 2018 at 10:48:35AM -0500, David Miller wrote: > From: Geert Uytterhoeven > Date: Tue, 9 Jan 2018 12:11:21 +0100 > > > In case of success, the return values of (__)phy_write() and > > (__)phy_modify() are not compatible: (__)phy_write() returns 0, while >

Re: [PATCH 34/38] arm: Implement thread_struct whitelist for hardened usercopy

his patch is wrong and will introduce a regression. Thanks. > > Cc: Russell King <li...@armlinux.org.uk> > Cc: Ingo Molnar <mi...@kernel.org> > Cc: Christian Borntraeger <borntrae...@de.ibm.com> > Cc: "Peter Zijlstra (Intel)" <pet...@infradead.org&g

Re: [PATCH] net: phy: Fix phy_modify() semantic difference fallout

On Tue, Jan 09, 2018 at 07:25:40PM +0100, Geert Uytterhoeven wrote: > Hi Russell, > > On Tue, Jan 9, 2018 at 3:22 PM, Russell King - ARM Linux > <li...@armlinux.org.uk> wrote: > > On Tue, Jan 09, 2018 at 03:10:08PM +0100, Andrew Lunn wrote: > >> On Tue, Jan 09

Re: [PATCH] net: phy: Fix phy_modify() semantic difference fallout

On Tue, Jan 09, 2018 at 03:48:13PM +0100, Andrew Lunn wrote: > > > I took a quick look at the uses of phy_modify(). I don't see any uses > > > of the return code other than as an error indicator. So having it > > > return 0 on success seems like a better fix. > > > > I'd like to avoid that,

Re: [PATCH net-next v3 4/4] net: mvpp2: 2500baseX support

On Tue, Jan 09, 2018 at 09:59:45AM +0100, Antoine Tenart wrote: > This patch adds the 2500Base-X PHY mode support in the Marvell PPv2 > driver. 2500Base-X is quite close to 1000Base-X and SGMII modes and uses > nearly the same code path. Sorry, also... > @@ -4668,6 +4692,10 @@ static void

Re: [PATCH net-next v3 4/4] net: mvpp2: 2500baseX support

On Tue, Jan 09, 2018 at 09:59:45AM +0100, Antoine Tenart wrote: > This patch adds the 2500Base-X PHY mode support in the Marvell PPv2 > driver. 2500Base-X is quite close to 1000Base-X and SGMII modes and uses > nearly the same code path. For 2500Base-X, do you report a speed of 2500Mbps through

Re: [PATCH] net: phy: Fix phy_modify() semantic difference fallout

On Tue, Jan 09, 2018 at 03:10:08PM +0100, Andrew Lunn wrote: > On Tue, Jan 09, 2018 at 12:11:21PM +0100, Geert Uytterhoeven wrote: > > In case of success, the return values of (__)phy_write() and > > (__)phy_modify() are not compatible: (__)phy_write() returns 0, while > > (__)phy_modify() returns

Re: Issue with commit fea23fb591cc "net: phy: convert read-modify-write to phy_modify()"

On Fri, Jan 05, 2018 at 02:44:07AM +0200, Ivan Khoronzhuk wrote: > + G.Strashko > The below change also brokes phy connect for am572x.. > > int genphy_restart_aneg(struct phy_device *phydev) > { > - int ctl = phy_read(phydev, MII_BMCR); > - > - if (ctl < 0) > - return

Re: Issue with commit fea23fb591cc "net: phy: convert read-modify-write to phy_modify()"

On Thu, Jan 04, 2018 at 08:00:53AM +0100, Heiner Kallweit wrote: > Parameter mask of phy_modify() holds the bits to be cleared. > In the mentioned commit parameter mask seems to be inverted in > few cases, what IMO is wrong (see example). I'd be grateful if you could list those that you think are

Re: [PATCH net-next v2 4/4] net: mvpp2: 2500baseX support

e PHY_INTERFACE_MODE_2500BASEX: > > + mode = PHY_MODE_2500SGMII; > > + break; > > I think this is the source of confusion with linux/phy.h and > linux/phy/phy.h. > > What would PHY_INTERFACE_MODE_2500SGMII use? > > Where is this all getting confused?

Re: [PATCH net-next 0/5] Export SERDES stats via ethtool -S

On Wed, Jan 03, 2018 at 03:09:17PM +0100, Andrew Lunn wrote: > The mv88e6352 family has a SERDES interface which can be used for > example to connect to SFF/SFP modules. This interface has a couple of > statistics counters. Add support for including these counters in the > output of ethtool -S.

Re: [EXT] Re: [PATCH net-next 5/6] arm64: dts: marvell: mcbin: enable the fourth network interface

On Wed, Jan 03, 2018 at 05:00:47PM +, Stefan Chulski wrote: > > > > -Original Message- > > > > Hi Russell, > > > > > > > > Indeed. RGMII MAC behaves same way, although it shouldn't be named > > > > as 'in- band' to be on par with the specifications. Anyway - this > > > > one is rather

Re: [PATCH net-next v2 0/7] Resolve races in phy accessors

On Wed, Jan 03, 2018 at 11:04:31AM -0500, David Miller wrote: > From: Russell King - ARM Linux <li...@armlinux.org.uk> > Date: Tue, 2 Jan 2018 10:52:18 + > > > This series resolves races with various accesses to PHY registers. > > The first five patches are nece

Re: [PATCH net-next 1/6] phy: add 2.5G SGMII mode to the phy_mode enum

On Wed, Jan 03, 2018 at 04:08:30PM +0100, Andrew Lunn wrote: > > > >>> diff --git a/include/linux/phy/phy.h b/include/linux/phy/phy.h > > > >>> index 4f8423a948d5..70459a28f3a1 100644 > > > >>> --- a/include/linux/phy/phy.h > > > >

Re: [PATCH 00/10] Convert mvneta to phylink

On Tue, Jan 02, 2018 at 05:22:42PM +, Russell King - ARM Linux wrote: > Hi, > > This series converts mvneta to use phylink, which is necessary to > support the SFP cages on SolidRun's Clearfog platform. This series just > converts mvneta without adding the DT parts - h

[PATCH 00/10] Convert mvneta to phylink

ink properties without needing the link parameters to be explicitly stated in DT - that is a subject of a future patch. drivers/net/ethernet/marvell/Kconfig | 2 +- drivers/net/ethernet/marvell/mvneta.c | 687 -- drivers/net/phy/fixed_phy.c | 31

[PATCH net-next v2 0/7] Resolve races in phy accessors

+-- drivers/net/phy/phy-core.c | 216 - drivers/net/phy/phy_device.c | 50 + include/linux/mdio.h | 3 + include/linux/phy.h | 40 7 files changed, 490 insertions(+), 346 deletions(-) -- RMK's Patch system: http://www.armlinux.org.uk

Re: [PATCH net-next 4/7] net: phy: add paged phy register accessors

On Sun, Dec 31, 2017 at 10:07:14AM +, Russell King - ARM Linux wrote: > On Sun, Dec 31, 2017 at 09:10:39AM +0100, Andrew Lunn wrote: > > > +/** > > > + * phy_save_page() - take the bus lock and save the current page > > > + * @phydev: a pointer to a phy_d

Re: [PATCH net-next A 3/5] sfp: add support for 1000Base-PX and 1000Base-BX10

Hi, I'm not entirely convinced that adding support for this is correct, so I'm going to drop this patch from a re-post of the series today. Base-PX, being EPON, requires additional layers (eg, MPMC on top of the MAC to control transmission), and it's not clear whether the SFP module takes care of

Re: [EXT] Re: [PATCH net-next 5/6] arm64: dts: marvell: mcbin: enable the fourth network interface

On Mon, Jan 01, 2018 at 10:35:25AM +, Stefan Chulski wrote: > > > -Original Message- > > Hi Russell, > > > > Indeed. RGMII MAC behaves same way, although it shouldn't be named as 'in- > > band' to be on par with the specifications. Anyway - this one is rather a > > stub for > >

Re: [PATCH net-next 4/7] net: phy: add paged phy register accessors

On Sun, Dec 31, 2017 at 09:10:39AM +0100, Andrew Lunn wrote: > > +/** > > + * phy_save_page() - take the bus lock and save the current page > > + * @phydev: a pointer to a phy_device > > + * > > + * Take the MDIO bus lock, and return the current page number. On error, > > + * returns a negative

Re: [PATCH net-next 5/6] arm64: dts: marvell: mcbin: enable the fourth network interface

Hi Marcin, On Sat, Dec 30, 2017 at 05:34:23PM +0100, Marcin Wojtas wrote: > Yes, I already split the series and will send first one right away. I > will be followed by MDIO bus / PHY handling proposal, including the > bits related to phylink. I'm looking forward to your opinion on that > once

Re: [PATCH net-next 7/7] net: phy: convert read-modify-write to phy_modify()

Hi, Unfortunately, I've found this afternoon that this patch causes a regression for Marvell PHYs connected in RGMII mode - so please do not apply this patch. The remainder of the series is fine. Thanks. -- RMK's Patch system: http://www.armlinux.org.uk/developer/patches/ FTTC broadband for

[PATCH net-next 0/5] marvell10g updates

+++ drivers/net/phy/phy-c45.c| 33 + drivers/net/phy/phy-core.c | 43 + include/linux/phy.h | 3 ++ 4 files changed, 148 insertions(+), 41 deletions(-) -- RMK's Patch system: http://www.armlinux.org.uk/developer/patches

[PATCH net-next 0/7] Resolve races in phy accessors

+-- drivers/net/phy/phy-core.c | 216 - drivers/net/phy/phy_device.c | 50 + include/linux/mdio.h | 3 + include/linux/phy.h | 40 7 files changed, 487 insertions(+), 343 deletions(-) -- RMK's Patch system: http://www.armlinux.org.uk

[PATCH net-next A 0/5] further sfp/phylink updates

() drivers/net/phy/phylink.c | 15 +++ drivers/net/phy/sfp-bus.c | 101 +- drivers/net/phy/sfp.c | 24 +++ include/linux/sfp.h | 36 - 4 files changed, 114 insertions(+), 62 deletions(-) -- RMK's Patch system: http

Re: [PATCH net-next 5/6] arm64: dts: marvell: mcbin: enable the fourth network interface

On Fri, Dec 29, 2017 at 12:12:15PM +0100, Marcin Wojtas wrote: > Hi Russell, > > I see that I misspelled your email address, hence the series remained > unnoticed: > https://lkml.org/lkml/2017/12/18/216 > > In terms of the phylink support, I think the most important are: > * 3/8 >

Re: [PATCH net-next 5/6] arm64: dts: marvell: mcbin: enable the fourth network interface

On Thu, Dec 28, 2017 at 11:04:16AM +0100, Antoine Tenart wrote: > Hi Russell, > > On Wed, Dec 27, 2017 at 11:20:00PM +, Russell King - ARM Linux wrote: > > On Wed, Dec 27, 2017 at 11:42:52PM +0100, Antoine Tenart wrote: > > > > > > What do you suggest to d

Re: [PATCH net-next 5/6] arm64: dts: marvell: mcbin: enable the fourth network interface

; > >> On Wed, Dec 27, 2017 at 10:24:01PM +, Russell King - ARM Linux wrote: > > >>> On Wed, Dec 27, 2017 at 11:14:45PM +0100, Antoine Tenart wrote: > > >>>> > > >>>> +_eth2 { > > >>>> + /* CPS Lane 5 */ > >

Re: [PATCH net-next 5/6] arm64: dts: marvell: mcbin: enable the fourth network interface

On Wed, Dec 27, 2017 at 11:42:52PM +0100, Antoine Tenart wrote: > Hi Russell, > > On Wed, Dec 27, 2017 at 10:24:01PM +, Russell King - ARM Linux wrote: > > On Wed, Dec 27, 2017 at 11:14:45PM +0100, Antoine Tenart wrote: > > > > > > +_eth2 { > > >

Re: [PATCH net-next 5/6] arm64: dts: marvell: mcbin: enable the fourth network interface

On Wed, Dec 27, 2017 at 11:14:45PM +0100, Antoine Tenart wrote: > This patch enables the fourth network interface on the Marvell > Macchiatobin. It is configured in the 2500Base-X PHY mode. > > Signed-off-by: Antoine Tenart > --- >

  1   2   3   4   >