On 16.5.2018 15:17, Andrew Lunn wrote:
So as the fixed-link subnode is optional we still should force some sensible
defaults if it is not used. Same as Marvell drives does. Can I say that we
agreed that the current CPU port setting is not correct and the fastest link
speed and duplex supported by
> So as the fixed-link subnode is optional we still should force some sensible
> defaults if it is not used. Same as Marvell drives does. Can I say that we
> agreed that the current CPU port setting is not correct and the fastest link
> speed and duplex supported by the chip should be set as a defa
On 15.5.2018 18:17, Florian Fainelli wrote:
I would like to have confirmed that I understand it correctly and that
the problem is really in the driver not handling fixed-link.
I would actually skip fixed-link, if you don't need it. Just hardwire
the CPU port, like the Marvell driver does:
http
On 05/15/2018 09:08 AM, Andrew Lunn wrote:
> On Tue, May 15, 2018 at 04:25:49PM +0200, Michal Vokáč wrote:
>> On 10.5.2018 16:29, Andrew Lunn wrote:
>>> I would probably add code to dump all the qca8k registers. Compare the
>>> values for your working setup and your non-working setup. Hopefully
>>>
On Tue, May 15, 2018 at 04:25:49PM +0200, Michal Vokáč wrote:
> On 10.5.2018 16:29, Andrew Lunn wrote:
> >I would probably add code to dump all the qca8k registers. Compare the
> >values for your working setup and your non-working setup. Hopefully
> >they are not too different, and you can quickly
On 10.5.2018 16:29, Andrew Lunn wrote:
I would probably add code to dump all the qca8k registers. Compare the
values for your working setup and your non-working setup. Hopefully
they are not too different, and you can quickly get to the bits which
matter.
Perfect! Thanks to your suggestion I di
> So both the CPU and the switch are trying to talk to each other but their
> frames are not delivered. This still looks like RGMII configuration problem.
Yes, i would say it is.
> As it works with my old PHY driver I suspect the problem is at the switches
> side somewhere in qca8k_set_pad_ctrl o
On 4.5.2018 15:30, Andrew Lunn wrote:
I am out of ideas how to further debug this.
Any additional adivce will be much appreciated.
I would suggest looking at the statistics counters. ethtool -S. Try
it for both the slave interfaces, and the master interface. The master
interfaces statistics sh
> Some RGMII delay tunning attempts with v4.17-rc2:
>
> phy-mode (fec)Rx/Tx delay result
> --
> rgmii 0/0 NOT OK
> rgmii 1/1 NOT OK
> rgmii 2/2 NOT OK
> rgmii 3/3 NOT OK
On 30.4.2018 15:20, Andrew Lunn wrote:
Using rgmii-id for the port is not valid as the qca8k driver does not support
that mode. It only supports rgmii and sgmii. I think this is actually not
correct. When phy-mode is set to rgmii for port the qca8k driver configures
internal delays in the switch.
> Using rgmii-id for the port is not valid as the qca8k driver does not support
> that mode. It only supports rgmii and sgmii. I think this is actually not
> correct. When phy-mode is set to rgmii for port the qca8k driver configures
> internal delays in the switch. So it behaves like rgmii-id I th
On 26.4.2018 16:06, Andrew Lunn wrote:
On Thu, Apr 26, 2018 at 03:37:33PM +0200, Michal Vokáč wrote:
- Linux 4.9.84 (Freescale 4.9-1.0.x-imx branch)
Hi Michal
Please use mainline, not the freescale fork. For DSA, there is nothing
you need in the freescale fork. Once it works with mainline,
On Thu, Apr 26, 2018 at 03:37:33PM +0200, Michal Vokáč wrote:
>
> - Linux 4.9.84 (Freescale 4.9-1.0.x-imx branch)
Hi Michal
Please use mainline, not the freescale fork. For DSA, there is nothing
you need in the freescale fork. Once it works with mainline, you can
then figure out what needs to b
Ahoj,
Sorry for bothering you guys but I could not come up with a more appropriate
place to ask my question.
I would very much appreciate some adivce to the DSA/QCA8K driver usage.
I am not (yet) very educated in networking internals so my wording may not be
right and my expectations may be wron
14 matches
Mail list logo
