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
32 matches
Mail list logo
