netdev - Re: i.MX6S/DL and QCA8334 switch using DSA driver

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Wed, 16 May 2018 14:50:46 +0200
From:   Michal Vokáč <vokac.m@...il.com>
To:     Florian Fainelli <f.fainelli@...il.com>,
        Andrew Lunn <andrew@...n.ch>
Cc:     netdev@...r.kernel.org,
        Vivien Didelot <vivien.didelot@...oirfairelinux.com>
Subject: Re: i.MX6S/DL and QCA8334 switch using DSA driver - CPU port not
 working

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:
>>
>> https://elixir.bootlin.com/linux/latest/source/drivers/net/dsa/mv88e6xxx/chip.c#L1780
>>
>> I would do it here:
>>
>> https://elixir.bootlin.com/linux/latest/source/drivers/net/dsa/qca8k.c#L518

Thanks for the references, I will look there.
> 
> Agreed with Andrew here, though if you can implement fixed-link, this
> should be more future proof.

I do not actually need fixed-link but I agree with Florian that it is much
better to have that option. I see it a as way to override defaults that
do not work for the user. That is what I was hoping for but it did not work.

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 default?

> As far as people using this driver, John submitted it, but we have not
> see many fixes/enhancements, so I am not clear who is actually using it
> these days... glad you are though!

Thanks.

To the compatibility of the driver with the QCA8334 that I use. I am not sure
what should be the correct way to deal with that. For example Marvell binding
uses only two compatible strings for a large range of chips in one family.
While Broadcom has one compatible string for each chip. As I mentioned earlier
in this thread the QCA8334 switch has four ports while the already supported
QCA8337 has seven ports. That is the only difference. Register address space
is the same.

Should I:
  - add a new compatible string "qualcomm,qca8334" and update the docs,
  - or just update the documentation and describe the compatibility?

As I need to update the docs I understand it should go as a separate patch.
Is it enough to CC devicetree list with the whole series? Any other
list/maintainer?

Thank you for your time,
Michal