On 24.02.2019 22:26, Florian Fainelli wrote:
>
>
> On February 24, 2019 9:04:55 AM PST, Andrew Lunn wrote:
>>> The added difficulty here and the reason why Andrew went with the
>>> approach that is used by the code currently is because neither do the
>>> CPU or DSA ports are backed by a net_devi
On February 24, 2019 9:04:55 AM PST, Andrew Lunn wrote:
>> The added difficulty here and the reason why Andrew went with the
>> approach that is used by the code currently is because neither do the
>> CPU or DSA ports are backed by a net_device. It is somewhere on my
>TODO
>> to permit the use
On Sun, Feb 24, 2019 at 06:28:48PM +0100, Andrew Lunn wrote:
> On Sun, Feb 24, 2019 at 03:31:26PM +, Russell King - ARM Linux admin
> wrote:
> > On Sun, Feb 24, 2019 at 12:42:35AM +0100, Andrew Lunn wrote:
> > > Looking forward, at some point we are going to have to make fixed-link
> > > suppo
On Sun, Feb 24, 2019 at 03:31:26PM +, Russell King - ARM Linux admin wrote:
> On Sun, Feb 24, 2019 at 12:42:35AM +0100, Andrew Lunn wrote:
> > Looking forward, at some point we are going to have to make fixed-link
> > support higher speeds. That probably means we need a swphy-c45 which
> > emul
> The added difficulty here and the reason why Andrew went with the
> approach that is used by the code currently is because neither do the
> CPU or DSA ports are backed by a net_device. It is somewhere on my TODO
> to permit the use of PHYLINK without the need of a net_device to cover
> those spec
Le 2/24/19 à 7:49 AM, Russell King - ARM Linux admin a écrit :
> On Sun, Feb 24, 2019 at 04:39:30PM +0100, Heiner Kallweit wrote:
>> On 24.02.2019 16:34, Russell King - ARM Linux admin wrote:
>>> On Sun, Feb 24, 2019 at 04:28:32PM +0100, Heiner Kallweit wrote:
On 24.02.2019 16:15, Russell King
On Sun, Feb 24, 2019 at 04:39:30PM +0100, Heiner Kallweit wrote:
> On 24.02.2019 16:34, Russell King - ARM Linux admin wrote:
> > On Sun, Feb 24, 2019 at 04:28:32PM +0100, Heiner Kallweit wrote:
> >> On 24.02.2019 16:15, Russell King - ARM Linux admin wrote:
> >>> On Sun, Feb 24, 2019 at 04:04:03PM
On 24.02.2019 16:34, Russell King - ARM Linux admin wrote:
> On Sun, Feb 24, 2019 at 04:28:32PM +0100, Heiner Kallweit wrote:
>> On 24.02.2019 16:15, Russell King - ARM Linux admin wrote:
>>> On Sun, Feb 24, 2019 at 04:04:03PM +0100, Andrew Lunn wrote:
> I think what's not correct is that phyde
On Sun, Feb 24, 2019 at 04:28:32PM +0100, Heiner Kallweit wrote:
> On 24.02.2019 16:15, Russell King - ARM Linux admin wrote:
> > On Sun, Feb 24, 2019 at 04:04:03PM +0100, Andrew Lunn wrote:
> >>> I think what's not correct is that phydev->autoneg is set
> >>> (by phy_device_create) for a fixed lin
On Sun, Feb 24, 2019 at 12:42:35AM +0100, Andrew Lunn wrote:
> Looking forward, at some point we are going to have to make fixed-link
> support higher speeds. That probably means we need a swphy-c45 which
> emulates the standard registers for 2.5G, 5G and 10G. At that point
> genphy will not work..
On 24.02.2019 16:15, Russell King - ARM Linux admin wrote:
> On Sun, Feb 24, 2019 at 04:04:03PM +0100, Andrew Lunn wrote:
>>> I think what's not correct is that phydev->autoneg is set
>>> (by phy_device_create) for a fixed link.
>>
>> Fixed-link tries to emulate auto-neg:
>>
>> bmsr
On Sun, Feb 24, 2019 at 04:04:03PM +0100, Andrew Lunn wrote:
> > I think what's not correct is that phydev->autoneg is set
> > (by phy_device_create) for a fixed link.
>
> Fixed-link tries to emulate auto-neg:
>
> bmsr |= BMSR_LSTATUS | BMSR_ANEGCOMPLETE;
>
> Maybe it needs bette
> I think what's not correct is that phydev->autoneg is set
> (by phy_device_create) for a fixed link.
Fixed-link tries to emulate auto-neg:
bmsr |= BMSR_LSTATUS | BMSR_ANEGCOMPLETE;
Maybe it needs better emulation of auto-neg?
Andrew
On 24.02.2019 00:42, Andrew Lunn wrote:
>> it took me quite some time to debug this issue ..
>>
>> At first a bisect pointed to one of my commits:
>> 5502b218e001 ("net: phy: use phy_resolve_aneg_linkmode in
>> genphy_read_status")
>>
>> Further digging lead me to some suspicious dsa code:
>> In d
Le 2/23/19 à 1:48 PM, Heiner Kallweit a écrit :
> On 18.02.2019 19:21, Andrew Lunn wrote:
Hi Heiner
Watch out for boot vs reboot, and when rebooting if port 8 had link or
not before you reboot.
>>> Will do. Is there some known issue or bug?
>>
>> Hi Heiner
>>
>> No, but it
> it took me quite some time to debug this issue ..
>
> At first a bisect pointed to one of my commits:
> 5502b218e001 ("net: phy: use phy_resolve_aneg_linkmode in genphy_read_status")
>
> Further digging lead me to some suspicious dsa code:
> In dsa_port_fixed_link_register_of() there's a call t
On 18.02.2019 19:21, Andrew Lunn wrote:
>>> Hi Heiner
>>>
>>> Watch out for boot vs reboot, and when rebooting if port 8 had link or
>>> not before you reboot.
>>>
>> Will do. Is there some known issue or bug?
>
> Hi Heiner
>
> No, but it is a variable which can make a difference. The fix i made
> > Hi Heiner
> >
> > Watch out for boot vs reboot, and when rebooting if port 8 had link or
> > not before you reboot.
> >
> Will do. Is there some known issue or bug?
Hi Heiner
No, but it is a variable which can make a difference. The fix i made
for the Freescale GPIO controller was not an is
On 17.02.2019 18:10, Andrew Lunn wrote:
>> Sorry, I may have been too fast with this statement. With this patch
>> reverted it worked, but now I have a build with this patch still included,
>> and it works too. Need to dig deeper ..
>
> Hi Heiner
>
> Watch out for boot vs reboot, and when rebooti
> Sorry, I may have been too fast with this statement. With this patch
> reverted it worked, but now I have a build with this patch still included,
> and it works too. Need to dig deeper ..
Hi Heiner
Watch out for boot vs reboot, and when rebooting if port 8 had link or
not before you reboot.
On 17.02.2019 17:57, Andrew Lunn wrote:
>> There haven't been that many changes to mv88e8xxx since 5.0-rc6.
>> I reverted 7c0db24cc431 ("dsa: mv88e6xxx: Ensure all pending interrupts
>> are handled prior to exit") who looked like a candidate and bingo:
>> network is working again. Obviously somethi
> There haven't been that many changes to mv88e8xxx since 5.0-rc6.
> I reverted 7c0db24cc431 ("dsa: mv88e6xxx: Ensure all pending interrupts
> are handled prior to exit") who looked like a candidate and bingo:
> network is working again. Obviously something is wrong with this patch.
O.K. I tested
On 17.02.2019 16:50, Heiner Kallweit wrote:
> On 17.02.2019 16:40, Russell King - ARM Linux admin wrote:
>> On Sun, Feb 17, 2019 at 04:34:32PM +0100, Heiner Kallweit wrote:
>>> When testing latest linux-next on the ZII DTU I face the issue that no
>>> traffic is flowing over the switch ports, even
On 17.02.2019 16:57, Andrew Lunn wrote:
>> In linux-next from Feb 15th this patch is included already.
>
> So why is port 8 not clearing its interrupt?
>
> Maybe put a printk in m88e1121_did_interrupt(),
> marvell_ack_interrupt(), and marvell_config_intr() and see if they are
> getting called.
>
> In linux-next from Feb 15th this patch is included already.
So why is port 8 not clearing its interrupt?
Maybe put a printk in m88e1121_did_interrupt(),
marvell_ack_interrupt(), and marvell_config_intr() and see if they are
getting called.
Andrew
On 17.02.2019 16:51, Andrew Lunn wrote:
>> 36:2030566 mscm-ir 79 Edge 400d1000.ethernet
>> 38:1010437 gpio-vf610 2 Level 400d1000.ethernet-1:00
>> 42: 0 mv88e6xxx-g1 3 Edge mv88e6xxx-g1-atu-prob
>> 44: 0 mv88e6xxx-g1 5 Edge mv88e6xxx-g1-vt
> 36:2030566 mscm-ir 79 Edge 400d1000.ethernet
> 38:1010437 gpio-vf610 2 Level 400d1000.ethernet-1:00
> 42: 0 mv88e6xxx-g1 3 Edge mv88e6xxx-g1-atu-prob
> 44: 0 mv88e6xxx-g1 5 Edge mv88e6xxx-g1-vtu-prob
> 46:1010435 mv88e6xxx-g1 7 E
On 17.02.2019 16:45, Andrew Lunn wrote:
> On Sun, Feb 17, 2019 at 04:34:32PM +0100, Heiner Kallweit wrote:
>> When testing latest linux-next on the ZII DTU I face the issue that no
>> traffic is flowing over the switch ports, even though in dmesg
>> everything looks good. Also PHY properly establis
On 17.02.2019 16:40, Russell King - ARM Linux admin wrote:
> On Sun, Feb 17, 2019 at 04:34:32PM +0100, Heiner Kallweit wrote:
>> When testing latest linux-next on the ZII DTU I face the issue that no
>> traffic is flowing over the switch ports, even though in dmesg
>> everything looks good. Also PH
On Sun, Feb 17, 2019 at 04:34:32PM +0100, Heiner Kallweit wrote:
> When testing latest linux-next on the ZII DTU I face the issue that no
> traffic is flowing over the switch ports, even though in dmesg
> everything looks good. Also PHY properly establishes the link.
Hi Heiner
Do you have
commit
On Sun, Feb 17, 2019 at 04:34:32PM +0100, Heiner Kallweit wrote:
> When testing latest linux-next on the ZII DTU I face the issue that no
> traffic is flowing over the switch ports, even though in dmesg
> everything looks good. Also PHY properly establishes the link.
>
> With 4.20.10 I don't have
When testing latest linux-next on the ZII DTU I face the issue that no
traffic is flowing over the switch ports, even though in dmesg
everything looks good. Also PHY properly establishes the link.
With 4.20.10 I don't have the issue and with 5.0-rc6 also not.
However on 5.0-rc6 I got the following
On Thu, Apr 5, 2018 at 11:46 PM, Andrew Lunn wrote:
>> > Hi Ran
>> >
>> > The Marvell driver makes each port act like a normal Linux network
>> > interface. So if you want to enable a port, do
>> >
>> > ip link set lan0 up
>> >
>> > Want to add an ip address to a port
>> >
>> > ip addr add 10.42.4
On Thu, Apr 5, 2018 at 11:46 PM, Andrew Lunn wrote:
>> > Hi Ran
>> >
>> > The Marvell driver makes each port act like a normal Linux network
>> > interface. So if you want to enable a port, do
>> >
>> > ip link set lan0 up
>> >
>> > Want to add an ip address to a port
>> >
>> > ip addr add 10.42.4
> > Hi Ran
> >
> > The Marvell driver makes each port act like a normal Linux network
> > interface. So if you want to enable a port, do
> >
> > ip link set lan0 up
> >
> > Want to add an ip address to a port
> >
> > ip addr add 10.42.42.42/24 dev lan0
> >
> > Want to bridge two ports
> >
> > ip li
On Thu, Apr 05, 2018 at 05:26:37PM +, Ran Shalit wrote:
> בתאריך יום ה׳, 5 באפר׳ 2018, 19:09, מאת Andrew Lunn :
>
> > > Is there a wiki which explains switch configuration ?
> >
> > Nope. The whole idea is that they behave like normal linux
> > interfaces. So there is no need to document them
> Is there a wiki which explains switch configuration ?
Nope. The whole idea is that they behave like normal linux
interfaces. So there is no need to document them. You already know how
to use them.
> Is it possible to open socket and send/recieve on switch ports (lan0
> for example) ?
Sure. It
On Thu, Apr 5, 2018 at 3:22 PM, Andrew Lunn wrote:
> On Thu, Apr 05, 2018 at 05:47:24AM +0300, Ran Shalit wrote:
>> Hello,
>>
>> I am trying to use marvell switch in linux,
>> Is it that the kernel drivers from marvell switch are used just to
>> enable all ports
On Thu, Apr 05, 2018 at 05:47:24AM +0300, Ran Shalit wrote:
> Hello,
>
> I am trying to use marvell switch in linux,
> Is it that the kernel drivers from marvell switch are used just to
> enable all ports, or do they also provide APIs to userspace to enable
> specific ports
Hello,
I am trying to use marvell switch in linux,
Is it that the kernel drivers from marvell switch are used just to
enable all ports, or do they also provide APIs to userspace to enable
specific ports only.
I have not find examples or wiki for marvell switch, so I am not too
sure as what are
Hi Gregory,
On 08/03/17 06:10, Gregory CLEMENT wrote:
> Hi Chris,
>
> On jeu., févr. 16 2017, Chris Packham
> wrote:
>
>> Shortly after I posted my last series I got access to a more recent
>> Marvell SDK which had some device tree support for the switch SoCs I'd
>> been wanting. It was still b
Hi Chris,
On jeu., févr. 16 2017, Chris Packham
wrote:
> Shortly after I posted my last series I got access to a more recent
> Marvell SDK which had some device tree support for the switch SoCs I'd
> been wanting. It was still based on an older kernel but it was a huge
> improvement over what
Shortly after I posted my last series I got access to a more recent
Marvell SDK which had some device tree support for the switch SoCs I'd
been wanting. It was still based on an older kernel but it was a huge
improvement over what came before.
Patch 1/6 is a typo I noticed after my initial series
Shortly after I posted my last series I got access to a more recent
Marvell SDK which had some device tree support for the switch SoCs I'd
been wanting. It was still based on an older kernel but it was a huge
improvement over what came before.
Patch 1/6 is a typo I noticed after my initial series
Shortly after I posted my last series I got access to a more recent
Marvell SDK which had some device tree support for the switch SoCs I'd
been wanting. It was still based on an older kernel but it was a huge
improvement over what came before.
Patch 1/4 is a bit of a cleanup. I did initially strug
45 matches
Mail list logo
