On Fri, Feb 03, 2017 at 02:05:13PM +, Robin Murphy wrote:
> AFAICS, even that shouldn't really be necessary - for all VA/PA
> combinations of 32/32, 32/40 and 64/40, storing virt_to_phys() of the
> SKB VA won't overflow 40 bits, so a corresponding phys_to_virt() at the
> other end can't go wron
On Thu, Feb 02, 2017 at 05:56:50PM +0100, Thomas Petazzoni wrote:
> For PPv2.2, we wanted to simplify a little bit the register mappings,
> and simply reflect the memory map of the SoC. In the SoC datasheet,
> there are two memory areas for the networking subsystem, which are the
> two areas reflec
On Mon, Feb 06, 2017 at 04:01:27PM -0800, Florian Fainelli wrote:
> On 01/30/2017 07:29 PM, Florian Fainelli wrote:
> > Introduce a new configuration symbol: MDIO_DEVICE which allows building
> > the MDIO devices and bus code, without pulling in the entire Ethernet
> > PHY library and devices code.
On Mon, Feb 06, 2017 at 04:11:12PM -0800, Florian Fainelli wrote:
> Introduce a new configuration symbol: MDIO_DEVICE which allows building
> the MDIO devices and bus code, without pulling in the entire Ethernet
> PHY library and devices code.
>
> PHYLIB nows select MDIO_DEVICE and the relevant Ma
On Sat, Mar 04, 2017 at 11:11:32AM +0100, Philippe Reynes wrote:
>
> // lp->port = cmd->port;
Hi,
Review looks good. However, please also update the above comment as
well.
Thanks.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line
On Thu, Jan 12, 2017 at 09:31:27PM +, Kwok, WingMan wrote:
>
> > > I double checked that ours is actually a 88E1514. According
> > > to Marvell's brief description, it seems that it does support
> > > fiber.
> > >
> > > Reading page 18 reg 30 returns 6.
> >
> > O.K, that is consistent. Lookin
On Thu, Jan 12, 2017 at 10:49:41PM +0100, Andrew Lunn wrote:
> How are you using the PHY. What phy-mode do you have set? Do you
> happen to be using it as an RGMII to SERDES/SGMII bridge? This is what
> Russell King is doing, i think.
No - the 88E1512 here is connected to the ethernet host via SG
y/phy-core.c| 101 ++
drivers/net/phy/phy.c | 110 --
drivers/net/phy/phy_device.c | 4 +-
drivers/net/usb/lan78xx.c | 10 ++--
include/linux/phy.h | 56 +
11 files changed
y to build
> with
> - * -ffreestanding and include 'stdint.h' (such as when you include
> 'arm_neon.h'
> - * in order to use NEON intrinsics)
> - *
> - * As the typedefs for these types in 'stdint.h' are based on builtin defines
> - * supplied by
s and IFNAMSIZ.
Add linux/if.h for IFNAMSIZ, declarations for the structures, phy.h to
mv88e6xxx.h as it needs it for phy_interface_t, and remove both phy.h
and phy_fixed.h from net/dsa.h.
This patch reduces from around 800 files rebuilt to around 40 - even
with ccache, the time difference is noti
On Wed, Jan 18, 2017 at 04:37:14PM -0500, David Miller wrote:
> From: Russell King - ARM Linux
> Date: Wed, 18 Jan 2017 00:14:03 +
>
> > Including phy.h and phy_fixed.h into net/dsa.h causes phy*.h to be an
> > unnecessary dependency for quite a large amount of the kern
On Thu, Jan 19, 2017 at 05:30:13PM +0100, Greg KH wrote:
> On Thu, Jan 19, 2017 at 03:53:15PM +0100, Andrew Lunn wrote:
> > > > > struct dsa_platform_data {
> > > > > /*
> > > > > * Reference to a Linux network interface that conne
(This is mainly for Greg's benefit to help him understand the issue.)
I think the diagram you gave initially made this confusing, as it
talks about a CPU(sic) producing the "RGMII" and "MII-MGMT".
Let's instead show a better representation that hopefully helps Greg
understand networking. :)
C
On Thu, Jan 19, 2017 at 11:42:47AM -0800, Florian Fainelli wrote:
> On 01/13/2017 07:20 AM, Russell King - ARM Linux wrote:
> > This series cleans up phylib's MMD accessors, so that we have a common
> > way of accessing the Clause 45 register set.
> >
> > The cur
On Mon, Nov 28, 2016 at 09:54:28AM -0800, Florian Fainelli wrote:
> If we start supporting generic "enable", "disable" type of properties
> with values that map directly to register definitions of the HW, we
> leave too much room for these properties to be utilized to implement a
> specific policy,
On Fri, Jan 06, 2017 at 11:11:36AM +0100, Jerome Brunet wrote:
> The purpose of this patch is to provide a way to mark as broken a
> particular eee mode. At first, it had nothing to do with "set_eee" but,
> as Florian rightly pointed out, users shouldn't be able to re-enable a
> broken mode.
I thi
On Fri, Jan 06, 2017 at 06:42:24AM +0100, Yegor Yefremov wrote:
> On Fri, Jan 6, 2017 at 12:25 AM, Russell King - ARM Linux
> wrote:
> > Another concern with this patch is that the existing phylib "set_eee"
> > code is horribly buggy - it just translates the modes
On Wed, Dec 28, 2016 at 05:45:58PM +0100, Thomas Petazzoni wrote:
> When configuring the MVPP2_ISR_RX_THRESHOLD_REG with the RX coalescing
> time threshold, we do not check for the maximum allowed value supported
> by the driver, which means we might overflow and use a bogus value. This
> commit ad
On Wed, Dec 28, 2016 at 05:46:05PM +0100, Thomas Petazzoni wrote:
> Some of the MVPP2_PRS_RI_* definitions use the ~(value) syntax, which
> doesn't compile nicely on 64-bit. Moreover, those definitions are in
> fact unneeded, since they are always used in combination with a bit
> mask that ensures
On Wed, Dec 28, 2016 at 05:46:21PM +0100, Thomas Petazzoni wrote:
> This commit adds the definition of the PPv2.2 HW descriptors, adjusts
> the mvpp2_tx_desc and mvpp2_rx_desc structures accordingly, and adapts
> the accessors to work on both PPv2.1 and PPv2.2.
>
> Signed-off-by: Thomas Petazzoni
On Wed, Dec 28, 2016 at 05:46:22PM +0100, Thomas Petazzoni wrote:
> +#ifdef CONFIG_ARCH_DMA_ADDR_T_64BIT
> + if (priv->hw_version == MVPP22) {
Maybe
if (sizeof(dma_addr_t) > sizeof(u32) && priv->hw_version == MVPP22) {
to get better compile coverage?
> + u32 val;
> +
On Wed, Dec 28, 2016 at 05:46:26PM +0100, Thomas Petazzoni wrote:
> This commit adjusts the mvpp2 driver register mapping and access logic
> to support PPv2.2, to handle a number of differences.
>
> Due to how the registers are laid out in memory, the Device Tree binding
> for the "reg" property i
(quick reply...)
On Fri, Jan 06, 2017 at 02:50:21PM +0100, Jerome Brunet wrote:
> So I'm not sure I understand, are you against EEE integration in phylib
> entirely, or specifically against the test I added in set_eee to filter
> out broken modes ?
I'm happy to see EEE integrated into phylib, but
_unprepare(priv->mg_clk);
> err_gop_clk:
> clk_disable_unprepare(priv->gop_clk);
> err_pp_clk:
> @@ -6969,6 +6985,7 @@ static int mvpp2_remove(struct platform_device *pdev)
> aggr_txq->descs_phys);
> }
>
> + clk_disable_unprepar
On Wed, Dec 28, 2016 at 05:46:17PM +0100, Thomas Petazzoni wrote:
> @@ -31,7 +43,7 @@ Optional properties (port):
>then fixed link is assumed, and the 'fixed-link' property is
>mandatory.
Not directly related to this patch, but this context is wrong. The
PP2 driver _requires_ a PHY. It d
On Wed, Dec 28, 2016 at 05:46:27PM +0100, Thomas Petazzoni wrote:
> @@ -6511,7 +6515,9 @@ static int mvpp2_port_probe(struct platform_device
> *pdev,
> dev_err(&pdev->dev, "failed to init port %d\n", id);
> goto err_free_stats;
> }
> - mvpp2_port_power_up(port
On Wed, Dec 28, 2016 at 05:46:27PM +0100, Thomas Petazzoni wrote:
> +#define MVPP22_SMI_MISC_CFG_REG 0x2a204
> +#define MVPP22_SMI_POLLING_EN BIT(10)
> +
...
> + if (priv->hw_version == MVPP21) {
> + val = readl(priv->lms_base + MVPP2_PHY_AN_CFG0_
This patch series fixes some issues identified while reviewing the
mvpp2 driver changes recently posted by Thomas. I've left the clock
issue, and the question over whether this should be separate out of
this series, concentrating on the resource size / interrupt issue.
This series updates the bin
; and updates MAC registers of each port independently. I was able to
> use those successfully in other implementations.
>
> However we are supposed to use libphy in Linux and I'm afraid we have
> to use single instance that controls single SMI bus - I think current
> implementation
On Sat, Jan 07, 2017 at 09:38:34AM +, Russell King - ARM Linux wrote:
> On Wed, Dec 28, 2016 at 05:46:27PM +0100, Thomas Petazzoni wrote:
> > @@ -6511,7 +6515,9 @@ static int mvpp2_port_probe(struct platform_device
> > *pdev,
> > dev_err(&pdev->dev, &q
On Mon, Jan 09, 2017 at 12:33:02PM +0100, Arnd Bergmann wrote:
> On Friday, January 6, 2017 10:43:53 AM CET Nicolas Dichtel wrote:
> >
> > diff --git a/arch/arm/include/asm/types.h b/arch/arm/include/asm/types.h
> > index a53cdb8f068c..c48fee3d7b3b 100644
> > --- a/arch/arm/include/asm/types.h
> >
On Fri, Jan 06, 2017 at 10:43:59AM +0100, Nicolas Dichtel wrote:
> diff --git a/arch/arm/include/uapi/asm/Kbuild
> b/arch/arm/include/uapi/asm/Kbuild
> index 46a76cd6acb6..607f702c2d62 100644
> --- a/arch/arm/include/uapi/asm/Kbuild
> +++ b/arch/arm/include/uapi/asm/Kbuild
> @@ -1,23 +1,6 @@
> #
On Thu, Feb 02, 2017 at 04:51:29PM +0100, Thomas Petazzoni wrote:
> David,
>
> This series contains a number of misc improvements and preparation
> patches for an upcoming series that adds support for the new PPv2.2
> network controller to the mvpp2 driver.
>
> Sorry for the long delay since v2,
y because with no data being transferred, little
non-swapable resources are used. You can control the maximum number
of connections allowed from a host with your firewall software
(like iptables).
Cheers,
Dick Johnson
Penguin : Linux version 2.6.16.4 on an i686 machine (5592.86 BogoMips).
New book: h
more and more of the networking code inside the
network board. The CPU get interrupted after most things (like
network handshakes) are complete.
Cheers,
Dick Johnson
Penguin : Linux version 2.6.16.4 on an i686 machine (5592.89 BogoMips).
Warning : 98.36% of all statistics are fiction, book release in
uot;send these data to that address" or "fill this buffer
with data from that address". All the networking could be done
on the board, perhaps with a dedicated CPU (as is now done) or
all in silicon.
So, the driver end of the net
On Mon, 24 Apr 2006, Auke Kok wrote:
> linux-os (Dick Johnson) wrote:
>> On Mon, 24 Apr 2006, Auke Kok wrote:
>>
>>> Ingo Oeser wrote:
>>>> On Saturday, 22. April 2006 15:49, Jörn Engel wrote:
>>>>> That was another main point, yes. And th
rst checking the legal
>> ramifications is a good way to torpedo Linux.
>>
>> Far too many people have a careless "U.S.A. laws suck, merge it anyway"
>> attitude.
>
> Independent of this issue:
>
> An interesting question is how to handle legal issues prop
call pci_enable_device() in order to make the
returned IRQ values valid. This has been reported numerious
times and has not been fixed. Basically, in order to get
the correct value, one needs to disable the board in some
unspecified way so it is
> Also, if the driver handles setting mac address, it could have prevented
> you from using a multicast address.
>
> Something like this is needed (untested, I don't have that hardware).
>
>
> --- linux-2.6/drivers/net/3c59x.c.orig 2006-03-13 09:58:25.0
>
roup assigned by IEEE. Failure to follow this
>> simple protocol can (will) cause an entire network to fail. If you
>> don't care, then you certainly don't care about multicast bits either,
>> basically let them set it to all ones as well.
>
>> Cheers,
>> Dic
inistered MAC addresses.
>
> Yes. My 12:34:56 OUI scheme will work for this project but it is
> definitely not good for the long term. I really really hope I have to
> spend some money with the IEEE soon to support lots and lots of
> rollouts. :)
>
> - Greg Scott
>
>
&g
On Tue, 14 Mar 2006, Bart Samwel wrote:
> linux-os (Dick Johnson) wrote:
>> On Mon, 13 Mar 2006, Greg Scott wrote:
>> Bst... Not! There are not any MAC addresses associated with any
>> of the intercity links, usually not even in WANs! MAC is for
>> Ethernet! Onc
the kernel
for hardware configuration is via ioctl(). For logic, sockets.
If the user-level tools suck, then they should be fixed. It
really doesn't have anything to do with the kernel.
Cheers,
Dick Johnson
Penguin : Linux version 2.6.13.4 on an i686 machine (5589.44 BogoMips).
Warning : 9
On Thu, Jul 07, 2016 at 04:03:02PM +0200, Andrew Lunn wrote:
> > Wed, Jul 06, 2016 at 04:44:44PM -0700, Iyappan Subramanian wrote:
> > Hi Andrew,
> >
> > On Tue, Jul 5, 2016 at 6:49 AM, Andrew Lunn wrote:
> > > On Mon, Jun 06, 2016 at 10:12:35AM -0700, Iyappan Subramanian wrote:
> > >> Hi Andrew,
On Thu, Aug 25, 2016 at 08:02:35PM +0200, Robert Jarzmik wrote:
> Arnd Bergmann writes:
>
> > On Thursday, August 25, 2016 4:43:04 PM CEST Arnd Bergmann wrote:
> >> drivers/net/ethernet/smsc/smc91x.h | 50
> >> +++---
> >> 1 file changed, 30 insertions(+), 20 del
On Thu, Aug 25, 2016 at 04:46:20PM +0200, Arnd Bergmann wrote:
> +#define SMC_out16(x, ioaddr, reg) \
> +do { \
> + if (SMC_CAN_USE_8BIT && !SMC_16BIT(lp)) {\
On Fri, Aug 26, 2016 at 11:41:21AM +0200, Arnd Bergmann wrote:
> On Thursday, August 25, 2016 11:37:43 PM CEST Russell King - ARM Linux wrote:
> > On Thu, Aug 25, 2016 at 08:02:35PM +0200, Robert Jarzmik wrote:
> > > Arnd Bergmann writes:
> > /*
> > + * Any 16-bit
On Fri, Aug 26, 2016 at 12:38:48PM +0100, Russell King - ARM Linux wrote:
> On Fri, Aug 26, 2016 at 11:41:21AM +0200, Arnd Bergmann wrote:
> > On Thursday, August 25, 2016 11:37:43 PM CEST Russell King - ARM Linux
> > wrote:
> > > On Thu, Aug 25, 2016 at 08:02:35PM +02
On Sat, Aug 27, 2016 at 05:30:42PM +0200, Robert Jarzmik wrote:
> Hi Russell,
>
> With your patch :
> - lubbock, mainstone and zylonite boards are working correctly
>=> ie. all my boards are working correctly
>
> - the message "ifconfig: SIOCSIFHWADDR: Device or resource busy" is still
> t
++-
drivers/net/irda/sa1100_ir.c | 91 ---
include/linux/platform_data/irda-sa11x0.h | 20 ---
include/linux/sa11x0-dma.h| 24
10 files changed, 127 insertions(+), 229 deletions(-)
delete mode 100644 include/linux/platform_data
This mini-series (which follows several other series on which it
depends) gets rid of the Assabet/Neponset hack in the smc91x driver.
In order to do that, we need to get several pieces in place first:
* gpiolib support throughout SA11x0/Assabet/Neponset so that we can
represent control signals t
On Thu, Sep 01, 2016 at 04:32:41PM -0700, David Miller wrote:
> From: Russell King - ARM Linux
> Date: Tue, 30 Aug 2016 11:51:17 +0100
>
> > Please ack these changes; due to the dependencies, I wish to merge
> > them through my tree. Thanks.
>
> Acked-by: David S.
On Mon, Oct 24, 2016 at 08:04:47AM -0400, Alexander Duyck wrote:
> The use of DMA_ATTR_SKIP_CPU_SYNC was not consistent across all of the DMA
> APIs in the arch/arm folder. This change is meant to correct that so that
> we get consistent behavior.
I'm really not convinced that this is anywhere cl
On Fri, Sep 23, 2016 at 10:19:50AM -0700, Eric Nelson wrote:
> Oddly, it does prevent the vast majority (90%+) of the alignment errors.
>
> I believe this is because the compiler is generating an ldm instruction
> when the ntohl() call is used, but I'm stumped about why these aren't
> generating f
On Fri, Sep 23, 2016 at 08:13:01PM +0200, Andrew Lunn wrote:
> > Since the hardware requires longword alignment for its' DMA transfers,
> > aligning the IP header will require a memcpy, right?
>
> The vf610 FEC has an SHIFT16 bit in register ENETx_TACC, which inserts
> two padding bits on transmit
I had a quick look at this, and although Eric's idea may be a good
idea, it doesn't contain enough details for me to be able to
implement it - eg, I've no idea how to attach the 128-byte skb to the
beginning of a previously allocated skb containing the rest of the
packet. I'
On Wed, Sep 28, 2016 at 10:14:52AM -0700, Eric Nelson wrote:
> Thanks David,
>
> On 09/28/2016 09:42 AM, David Laight wrote:
> > From reading this it seems that the effect of FEC_RACC_SHIFT16 is to
> > add two bytes of 'junk' to the start of every receive frame.
>
> That's right. Two bytes of jun
On Fri, Sep 30, 2016 at 07:16:12AM -0700, Eric Nelson wrote:
> On ARM, the CPU can't handle misaligned memory cycles without
> taking an alignment fault and NET_IP_ALIGN is set to 2.
Let's get this right... With Linux on MMU parts:
On ARMv6+, unaligned memory cycles using t
On Mon, Oct 03, 2016 at 04:46:25PM +0100, Mark Rutland wrote:
> On Mon, Oct 03, 2016 at 11:05:53AM +0200, Robert Jarzmik wrote:
> > Add a workaround for mainstone, idp and stargate2 boards, for u16 writes
> > which must be aligned on 32 bits addresses.
> >
> > Signed-off-by: Robert Jarzmik
> > --
On Sat, Dec 10, 2016 at 01:32:34PM +0100, Pablo Neira Ayuso wrote:
> Hi Arnd,
>
> On Sat, Dec 10, 2016 at 11:36:34AM +0100, Arnd Bergmann wrote:
> > A change to the netfilter code in net-next introduced the first caller of
> > cmpxchg64 that can get built on ARMv7-M, leading to an error from the
>
l RCU state,
rather than detecting it when we actually schedule - Paul?
===
[ INFO: suspicious RCU usage. ]
4.7.0+ #98 Not tainted
---
include/linux/rcupdate.h:554 Illegal context switch in RCU read-side critical
section!
other info that might
On Tue, Sep 20, 2016 at 03:38:33PM +0200, Andrew Lunn wrote:
> On Tue, Sep 20, 2016 at 11:26:12AM +0100, Russell King - ARM Linux wrote:
> > Issuing "bridge vlan show" on clearfog provokes a "suspicious RCU usage"
> > warning from the kernel (see below).
> &g
Hi,
I seem to have found a severe performance issue somewhere in the
networking code.
This involves ZenIV.linux.org.uk, which is a qemu-kvm guest instance
on ZenV, which is configured to use macvtap for ZenIV to gain its
network access, with ZenIV using the 8139cp driver.
My initial testing was
On Fri, Nov 11, 2016 at 09:23:43PM +, David Woodhouse wrote:
> On Fri, 2016-11-11 at 21:05 +, Russell King - ARM Linux wrote:
> >
> > 18:59:38.782818 IP (tos 0x0, ttl 52, id 35619, offset 0, flags [DF], proto
> > TCP (6), length 60)
> > 84.xx.xxx.196.61236
On Fri, Nov 11, 2016 at 09:23:43PM +, David Woodhouse wrote:
> It's also *fairly* unlikely that the kernel in the guest has developed
> a bug and isn't setting gso_size sanely. I'm more inclined to suspect
> that qemu isn't properly emulating those bits. But at first glance at
> the code, it lo
Hi,
I'm seeing really poor IPv6 performance compared to IPv4. I've
checked using two different ARM platforms - an iMX6 platform using
the FEC driver, and an Armada 38x using mvneta.
The following was captured using iperf between the target system
and my laptop. The problem only occurs one-way.
On Fri, Oct 02, 2015 at 04:37:51PM +0200, Nicolas Schichan wrote:
> @@ -125,7 +125,7 @@ static u64 jit_get_skb_w(struct sk_buff *skb, int offset)
> }
>
> /*
> - * Wrapper that handles both OABI and EABI and assures Thumb2 interworking
> + * Wrappers that handles both OABI and EABI and assures T
1
> RX packets:2 errors:0 dropped:0 overruns:0 frame:0
> TX packets:8 errors:0 dropped:0 overruns:0 carrier:0
> collisions:0 txqueuelen:532
> RX bytes:497 (497.0 B) TX bytes:648 (648.0 B)
> Interrupt:27
>
> I'm guess
On Thu, Oct 08, 2015 at 05:32:57PM +0200, Andrew Lunn wrote:
> > > This would suggest the driver is not clearing the statistics when it
> > > loads. Should it?
> >
> > That's an interesting question, one which I have no answer for.
>
> So i took a look at the other Marvell drivers. mv643xx_eth.c,
On Mon, Jun 15, 2015 at 04:27:22PM +0200, Simon Guinot wrote:
> This patch introduces the tx_csum_limit DT property. This allows to
> configure the maximum frame size for which the Ethernet controller is
> able to perform TCP/IP checksumming. If MTU is set to a value greater
> than tx_csum_limit, t
| 1235 +++++
drivers/net/phy/swphy.c | 179 +
drivers/net/phy/swphy.h |9 +
include/linux/phy.h |4 +
include/linux/phy_fixed.h |9 -
include/linux/phylink.h | 102 +++
On Tue, Dec 08, 2015 at 10:15:08AM -0800, Florian Fainelli wrote:
> On 07/12/15 09:38, Russell King wrote:
> > Add an I2C MDIO bus bridge library, to allow phylib to access PHYs which
> > are connected to an I2C bus instead of the more conventional MDIO bus.
> > Such PHYs can be found in SFP adapte
On Fri, Dec 11, 2015 at 11:21:30AM +0100, Sascha Hauer wrote:
> On Fri, Dec 11, 2015 at 10:40:22AM +0100, Gregory CLEMENT wrote:
> > So I see 2 options:
> >
> > - leaving the phy-reset-gpios property in the ethernet node. Thanks to
> > this we can use the gpiod functions, and it is still possibl
On Mon, Nov 09, 2015 at 08:56:10PM +0900, Tetsuo Handa wrote:
> There are many locations that do
>
> if (memory_was_allocated_by_vmalloc)
> vfree(ptr);
> else
> kfree(ptr);
>
> but kvfree() can handle both kmalloc()ed memory and vmalloc()ed memory
> using is_vmalloc_addr(). Unless cal
On Mon, Nov 09, 2015 at 05:57:43PM +0100, Arnd Bergmann wrote:
> I'm not sure what you are asking. A lot of DT bindings have both
> optional and mandatory properties. For mvneta, the "phy" and "phy-mode"
> properties are listed as mandatory, so the driver can safely assume
> that they are always pr
On Mon, Nov 09, 2015 at 06:12:02PM +0100, Arnd Bergmann wrote:
> On Monday 09 November 2015 17:08:34 Russell King - ARM Linux wrote:
> > They are "optional" because when you're using a DSA switch, you don't
> > specify a PHY (because, there isn't one). For
On Mon, Nov 09, 2015 at 06:08:49PM +0100, Andrew Lunn wrote:
> You use fixed-phy when the MAC is connected to a switch, not a phy. Or
> when the MAC is connected to an SFP module.
... hopefully not for much longer. Once -rc1 is out, I'll sort out
posting my phylink and SFP module hotplug support
Hi,
While trying to track down instability in the FEC driver, I've come
across this question: what is the correct way to access the MDIO bus?
Is it via:
bus->write()
where 'bus' is a struct mii_bus, or should it be via mdiobus_write()?
What I'm seeing in the FEC driver is two thread tr
On Tue, Aug 25, 2015 at 07:08:24AM -0700, Florian Fainelli wrote:
> Le 08/25/15 01:49, Russell King a écrit :
> > The phy layer is missing locking for the above two functions - it
> > has been observed that two threads (userspace and the phy worker
> > thread) can race, entering the bus ->write or
On Wed, Sep 02, 2015 at 11:40:15AM +0200, Philippe De Muyter wrote:
> On Wed, Sep 02, 2015 at 05:24:14PM +0800, Fugang Duan wrote:
> > From: Russell King
> >
> > The patch just to re-submit the patch "db3421c114cfa6326" because the
> > patch "4d494cdc92b3b9a0" remove the change.
>
> I think you
I have a recent Marvell Armada 388 board here which uses the mvneta
driver. I'm seeing some weird effects with NFS with it acting as a
client. Unfortunately, the board does not have a functional RTC.
The NFS server is the same NFS server that I've used for years with
multiple other clients (it's
On Fri, Sep 11, 2015 at 06:04:51AM -0700, Eric Dumazet wrote:
> On Fri, 2015-09-11 at 12:38 +0100, Russell King - ARM Linux wrote:
> > I have a recent Marvell Armada 388 board here which uses the mvneta
> > driver. I'm seeing some weird effects with NFS with it ac
On Fri, Sep 11, 2015 at 06:04:51AM -0700, Eric Dumazet wrote:
> On Fri, 2015-09-11 at 12:38 +0100, Russell King - ARM Linux wrote:
> > Running tcpdump on the NFS server, and then dumping the captured
> > packets
> > with tshark (because tcpdump appears not to understand
On Fri, Sep 11, 2015 at 03:33:47PM +0100, Russell King - ARM Linux wrote:
> It looks like 0c78789e3a030615c6650fde89546cadf40ec2cc might be relevant
> too, but I don't see that solving the multiple _concurrent_ connection
> attempts with the same port number - presumably it'
On Fri, Sep 11, 2015 at 08:18:43AM -0700, Eric Dumazet wrote:
> On Fri, 2015-09-11 at 16:06 +0100, Russell King - ARM Linux wrote:
> > On Fri, Sep 11, 2015 at 03:33:47PM +0100, Russell King - ARM Linux wrote:
> > > It looks like 0c78789e3a030615c6650fde89546cadf40ec2cc might be
On Fri, Sep 11, 2015 at 05:24:17PM +0100, Russell King - ARM Linux wrote:
> On Fri, Sep 11, 2015 at 08:18:43AM -0700, Eric Dumazet wrote:
> > On Fri, 2015-09-11 at 16:06 +0100, Russell King - ARM Linux wrote:
> > > On Fri, Sep 11, 2015 at 03:33:47PM +0100, Russell King
I've been bringing up the mainline kernel on a new board, which has
an Marvell SoC with a mvneta interface connected to a Marvell DSA
switch. The DSA switch is a 88E6176.
In the DT block for the interface, I specify:
ethernet@... {
phy-mode = "sgmii";
stat
Andrew,
I think you're the current maintainer of the Marvell DSA code, as being
the most recent author of changes to it. :)
I've noticed in my testing that the Marvell DSA code seems to poll the
internal phy link status in mv88e6xxx_poll_link(), and set the network
device carrier status according
On Mon, Sep 14, 2015 at 02:06:13PM +0300, Stas Sergeev wrote:
> 14.09.2015 13:32, Russell King - ARM Linux пишет:
> >I've been bringing up the mainline kernel on a new board, which has
> >an Marvell SoC with a mvneta interface connected to a Marvell DSA
> >switch. T
On Mon, Sep 14, 2015 at 10:28:55AM -0700, Florian Fainelli wrote:
> Just my 2 cents here, I suspect the original intention behind this code
> was to help utilize the switch's built-in PHY polling unit when
> available, and use the HW to collect the state of all PHYs in fewer
> register to read, ins
On Fri, Sep 11, 2015 at 05:49:38PM +0100, Russell King - ARM Linux wrote:
> Following that idea, I just tried the patch below, and it seems to work.
> I don't know whether it handles all cases after a call to kernel_connect(),
> but it stops the multiple connection attempts:
>
On Wed, Sep 16, 2015 at 06:53:57AM +, Damien Thébault wrote:
> On Fri, 2015-09-11 at 12:38 +0100, Russell King - ARM Linux wrote:
> > I have a recent Marvell Armada 388 board here which uses the mvneta
> > driver. I'm seeing some weird effects with NFS with it ac
On Thu, Sep 17, 2015 at 01:37:22PM -0700, David Miller wrote:
> From: Robert Jarzmik
> Date: Wed, 16 Sep 2015 11:41:54 +0200
>
> > David Miller writes:
> >
> >> From: Robert Jarzmik
> >> Date: Thu, 10 Sep 2015 21:26:04 +0200
> >>
> >>> Convert the dma transfers to be dmaengine based, now pxa h
On Thu, Sep 17, 2015 at 10:18:29AM -0400, Trond Myklebust wrote:
> Hi Russell,
>
> On Thu, 2015-09-17 at 14:57 +0100, Russell King - ARM Linux wrote:
> > On Fri, Sep 11, 2015 at 05:49:38PM +0100, Russell King - ARM Linux
> > wrote:
> > > Following that idea, I just
On Thu, Sep 17, 2015 at 03:12:47PM -0700, David Miller wrote:
> From: Russell King - ARM Linux
> Date: Mon, 14 Sep 2015 12:42:09 +0100
>
> > Thanks, I think that will solve it. I have to wonder why that patch
> > (f8af8e6eb9509 in mainline) didn't made it into v4.2 tho
On Thu, Sep 17, 2015 at 04:36:44PM -0700, Florian Fainelli wrote:
> On 17/09/15 16:14, Russell King - ARM Linux wrote:
>
> [snip]
>
> >with _no_ phy node.
> >
> > 4. Going back to the SFP problem, the link is only up when the SFP
> >module pins indica
| 19 ---
drivers/net/phy/mdio_bus.c| 24 ++---
drivers/net/phy/phy_device.c | 62 ++-
drivers/of/of_mdio.c | 27 ++++--
include/linux/phy.h | 6 ++-
12 files
Sorry guys, some of you will get the patches twice, as Sören's name
in the header caused vger to reject all the patches.
--
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the
On Fri, Sep 18, 2015 at 02:29:34PM +0300, Stas Sergeev wrote:
> 18.09.2015 02:14, Russell King - ARM Linux пишет:
> > _But_ using the in-band status
> >property fundamentally requires this for mvneta to behave correctly:
> >
> > phy-mode = "sgmii
301 - 400 of 1206 matches
Mail list logo
