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
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:
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
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,
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,
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
> >
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
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
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
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()
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
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
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
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
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
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
> >
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
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
>
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
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,
>
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
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
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
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
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
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
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
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
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:
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:
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
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
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[],
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
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
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
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
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
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:
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
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
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
>
On Fri, May 04, 2018 at 03:56:36PM +0200, Antoine Tenart wrote:
> This patch adds one more generic PHY mode to the phy_mode enum, to allow
> configuring generic PHYs to the 2.5G SGMII mode by using the set_mode
> callback.
>
> Signed-off-by: Antoine Tenart
> Acked-by:
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
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
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
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
Hi,
Yesterday, I noticed that one of my platforms had become unreachable
over IPv6. This platform is connected to a Clearfog, which uses
the Marvell 88e6176 switch.
The setup is:
(rest of network)
| | | | | | |
Source Netgear switch Clearfog switch
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
On Thu, Mar 29, 2018 at 05:58:43AM +, Yan Markman wrote:
> Hi Florian
> Please keep CCYelena Krivosheev
> for changes with drivers/net/ethernet/marvell/mvneta.c
> Thanks
We have a way to ensure such things happen - it's the MAINTAINERS
file. Please
On Wed, Mar 28, 2018 at 12:03:39PM -0700, Florian Fainelli wrote:
> From: Russell King
>
> Provide a pointer to the SFP bus in struct net_device, so that the
> ethtool module EEPROM methods can access the SFP directly, rather
> than needing every user to provide a
On Wed, Mar 28, 2018 at 12:03:38PM -0700, Florian Fainelli wrote:
> In preparation for having DSA transition entirely to PHYLINK, we need to pass
> a
> PHY interface type to the mac_link_{up,down} callbacks because we may have to
> make decisions on that (e.g: turn on/off RGMII interfaces etc.).
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
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,
On Sun, Mar 18, 2018 at 11:52:44AM -0700, Florian Fainelli wrote:
> In preparation for having DSA transition entirely to PHYLINK, we need to pass
> a
> PHY interface type to the mac_link_{up,down} callbacks because we may have to
> make decisions on that (e.g: turn on/off RGMII interfaces etc.).
On Mon, Mar 19, 2018 at 10:59:55AM -0700, Florian Fainelli wrote:
> Hi Andrew,
>
> On 03/18/2018 12:19 PM, Andrew Lunn wrote:
> >> +static int dsa_slave_nway_reset(struct net_device *dev)
> >> +{
> >> + struct dsa_port *dp = dsa_slave_to_port(dev);
> >> +
> >> + return
On Mon, Mar 19, 2018 at 01:19:24PM +, Stefan Chulski wrote:
>
>
> > -Original Message-
> > From: Andrew Lunn [mailto:and...@lunn.ch]
> > Sent: Monday, March 19, 2018 3:08 PM
> > To: Stefan Chulski <stef...@marvell.com>
> > Cc: Antoine Tenart
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:
>
>
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:
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
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)
> +{
> +
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 ++-
>
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
Included in this series are a further few updates for SFP support:
- Adding support for Fiberstore's non-standard BiDi modules operating
at 1310nm/1550nm wavelengths rather than the 1000BASE-BX standard of
1310nm/1490nm.
- Adding support for negotiating the PHY interface mode with the MAC,
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:
>
On Mon, Feb 05, 2018 at 10:48:55PM +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:
>
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
Do you think that the appropriate patches could be copied to the
appropriate people please?
On Thu, Jan 11, 2018 at 04:46:24PM -0800, Dan Williams wrote:
> Changes since v1 [1]:
> * fixup the ifence definition to use alternative_2 per recent AMD
> changes in tip/x86/pti (Tom)
>
> * drop
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
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
>
On Wed, Jan 10, 2018 at 06:03:06PM -0800, Kees Cook wrote:
> ARM does not carry FPU state in the thread structure, so it can declare
> no usercopy whitelist at all.
This comment seems to be misleading. We have stored FP state in the
thread structure for a long time - for example, VFP state is
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
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,
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
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
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
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
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
On Wed, Jan 03, 2018 at 04:20:36PM +0100, Andrew Lunn wrote:
> > @@ -4612,6 +4616,9 @@ static int mvpp22_comphy_init(struct mvpp2_port *port)
> > case PHY_INTERFACE_MODE_1000BASEX:
> > mode = PHY_MODE_SGMII;
> > break;
> > + case PHY_INTERFACE_MODE_2500BASEX:
> > +
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.
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
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
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
> > > >>> +++ b/include/linux/phy/phy.h
> > > >>> @@ -28,6 +28,7 @@ enum
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
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 - having discussed with
Andrew, we believe we're too close to the merge window to submit that
patch.
I've
Hi,
This series resolves races with various accesses to PHY registers.
The first five patches are necessary before we add phylink support
to mvneta, the remaining three are merely cleanups for unobserved
races, and hence are less critical.
There are two possible classes of races that can occur:
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
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
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
> >
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
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
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
Hi,
This series:
- adds MDI/MDIX reporting
- adds support for 10/100Mbps half-duplex link modes
- adds a comment describing the setup on VF610 ZII boards (where
the phy interface mode doesn't change.)
- cleans up the phy interace mode switching
drivers/net/phy/marvell10g.c | 110
Hi,
This series resolves races with various accesses to PHY registers.
The first five patches are necessary before we add phylink support
to mvneta, the remaining three are merely cleanups for unobserved
races, and hence are less critical.
There are two possible classes of races that can occur:
Hi,
This series:
- cleans up printing of module information
- improves the transceiver capability decoding, getting rid of the
guessing by connector type, improves direct-attach cable support
and adds support for 1G Base-PX and Base-BX10 modules.
- cleans up phylink_sfp_module_insert()
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
>
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
; > >> 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 */
> >
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 {
> > >
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 - 100 of 335 matches
Mail list logo