[v2,1/3] Move mvswitch 88E6060 driver to the ath25

The only user of the swconfig-based mvswitch driver is the ath25 target.
All other targets have been switched to the upstream DSA implementation.
ath25 can not be switched to the DSA implementation due to lack of the
DTS support. mvswitch is still required for ath25 to support such boards
as Fonera 2.0g (FON2202). So make it target specific to keep generic
config and patches clean.

Suggested-by: Felix Fietkau <nbd@nbd.name>
Signed-off-by: Sergey Ryazanov <ryazanov.s.a@gmail.com>
---
Changes in v2:
* new patch; earlier here was another patch that recovers mvswitch
  support under the v5.10 kernel

 .../files/drivers/net/phy/mvswitch.c          |  0
 .../files/drivers/net/phy/mvswitch.h          |  0
 .../patches-5.4/700-swconfig_mvswitch.patch   | 23 +++++++++++++++++++
 target/linux/generic/config-5.10              |  1 -
 target/linux/generic/config-5.4               |  1 -
 .../700-swconfig_switch_drivers.patch         |  9 ++------
 6 files changed, 25 insertions(+), 9 deletions(-)
 rename target/linux/{generic => ath25}/files/drivers/net/phy/mvswitch.c (100%)
 rename target/linux/{generic => ath25}/files/drivers/net/phy/mvswitch.h (100%)
 create mode 100644 target/linux/ath25/patches-5.4/700-swconfig_mvswitch.patch

Sergey Ryazanov <ryazanov.s.a@gmail.com> writes:

> ath25 can not be switched to the DSA implementation due to lack of the
> DTS support.

I fully understand and accept that this isn't made a priority.  But the
explanation is misleading. It's definitely *possible* to use a DSA
driver without DTS.  There are examples in mainline.  So "cannot" is
wrong.


Bjørn

Hello Bjørn,

On Sat, Dec 18, 2021 at 2:25 PM Bjørn Mork <bjorn@mork.no> wrote:
> Sergey Ryazanov <ryazanov.s.a@gmail.com> writes:
>> ath25 can not be switched to the DSA implementation due to lack of the
>> DTS support.
>
> I fully understand and accept that this isn't made a priority.  But the
> explanation is misleading. It's definitely *possible* to use a DSA
> driver without DTS.  There are examples in mainline.  So "cannot" is
> wrong.

Yep, I know that in general a DSA switch can be configured via the
platform data as any other device. But in this particular case, the
particular 88E6060 switch support can not be switched to the DSA
implementation because the DSA implementation does not support
configuration via the platform data.

I checked the kernel code and the OpenWrt patches and found the only
board with the 88E6060 switch and this board utilizes DTS for its
configuration:

openwrt $ grep -rn 'mv88e6060'
build_dir/target-mips_mips32_musl/linux-ath25/linux-5.10.87/arch/
openwrt $ grep -rn 'mv88e6060' target/linux/
target/linux/ath79/dts/ar9132_tplink_tl-wr941-v2.dts:68: compatible =
"marvell,mv88e6060";

So, I can not find which example you mean. But I may not have
understood your input. Please explain where I made a mistake?

Sergey Ryazanov <ryazanov.s.a@gmail.com> writes:

> board with the 88E6060 switch and this board utilizes DTS for its
> configuration:
>
> openwrt $ grep -rn 'mv88e6060'
> build_dir/target-mips_mips32_musl/linux-ath25/linux-5.10.87/arch/
> openwrt $ grep -rn 'mv88e6060' target/linux/
> target/linux/ath79/dts/ar9132_tplink_tl-wr941-v2.dts:68: compatible =
> "marvell,mv88e6060";
>
> So, I can not find which example you mean. But I may not have
> understood your input. Please explain where I made a mistake?

Maybe I misunderstood you. I was reading your message like DSA in
general cannot be used with board files. I don't know of any examples
using the mv88e6060 driver.

But if you want a generic example of DSA from board files, then there is
arch/arm/plat-orion/common.c using the mv88e6085 driver.



Bjørn

Sergey Ryazanov <ryazanov.s.a@gmail.com> writes:

>  But in this particular case, the
> particular 88E6060 switch support can not be switched to the DSA
> implementation because the DSA implementation does not support
> configuration via the platform data.

Sorry, I missed this part in my previous reply.  I could very well be
wrong, but I cannot see anything DT specific in the mv88e6060 driver. It
just calls dsa_register_switch() to load all the config, and that
function supports both platform data and device tree.

But again:  I don't expect you (or anyone else) to put a lot of work
into this. Just wanted to paint the bike shed red for christmas ;-)


Bjørn

On Sat, Dec 18, 2021 at 6:18 PM Bjørn Mork <bjorn@mork.no> wrote:
> Sergey Ryazanov <ryazanov.s.a@gmail.com> writes:
>>  But in this particular case, the
>> particular 88E6060 switch support can not be switched to the DSA
>> implementation because the DSA implementation does not support
>> configuration via the platform data.
>
> Sorry, I missed this part in my previous reply.  I could very well be
> wrong, but I cannot see anything DT specific in the mv88e6060 driver. It
> just calls dsa_register_switch() to load all the config, and that
> function supports both platform data and device tree.

Ouch! I totally forgot that DSA switches have a common platform data
structure (struct dsa_chip_data), and each DSA driver does not have to
provide its own configuration structure. In this case, it looks like
the ath25 kernel part can be easily switched to the DSA
implementation.

Now I can see that the patch description does look misguided. And I
should say sorry for taking a while to figure that out.

If someone of maintainers already took this patch, then please update
the commit message. Or I will send the patch with the updated message
tomorrow.

> But again:  I don't expect you (or anyone else) to put a lot of work
> into this. Just wanted to paint the bike shed red for christmas ;-)

Yes, that was perfectly clear from the first email :) I just wrongly
assumed that the mv88e6060 DSA driver can not be used with the
platform data. Now you have clearly shown that this is possible.
Thanks for this explanation!

Hi

On 2021-12-18, Sergey Ryazanov wrote:
> On Sat, Dec 18, 2021 at 2:25 PM Bjørn Mork <bjorn@mork.no> wrote:
> > Sergey Ryazanov <ryazanov.s.a@gmail.com> writes:
> >> ath25 can not be switched to the DSA implementation due to lack of the
> >> DTS support.
> >
> > I fully understand and accept that this isn't made a priority.  But the
> > explanation is misleading. It's definitely *possible* to use a DSA
> > driver without DTS.  There are examples in mainline.  So "cannot" is
> > wrong.
> 
> Yep, I know that in general a DSA switch can be configured via the
> platform data as any other device. But in this particular case, the
> particular 88E6060 switch support can not be switched to the DSA
> implementation because the DSA implementation does not support
> configuration via the platform data.
> 
> I checked the kernel code and the OpenWrt patches and found the only
> board with the 88E6060 switch and this board utilizes DTS for its
> configuration:

NET_DSA_MV88E6060 has already been used for this device (tl-wr941nd v2/
v3) in ar71xx, using platform data 


https://git.openwrt.org/?p=openwrt/openwrt.git;a=blob;f=target/linux/ar71xx/files/arch/mips/ath79/mach-tl-wr941nd.c;hb=refs/heads/openwrt-19.07
https://git.openwrt.org/?p=openwrt/openwrt.git;a=blob;f=target/linux/ar71xx/config-4.14;h=9a524fae4316caa10431bd6b3b4dadbe8660f14c;hb=refs/heads/openwrt-19.07#l433
https://git.openwrt.org/?p=openwrt/openwrt.git;a=blob;f=target/linux/ar71xx/base-files/etc/board.d/02_network;h=44fce970c0fd8b4811242fac0b53764a09244a2f;hb=refs/heads/openwrt-19.07#l324

so it should be possible for ath25 as well, although the effort might
not be worth it, considering the age and specifications of the target
devices.

Regards
	Stefan Lippers-Hollmann

Hello Stefan,

On Sun, Dec 19, 2021 at 12:12 AM Stefan Lippers-Hollmann <s.l-h@gmx.de> wrote:
> On 2021-12-18, Sergey Ryazanov wrote:
>> On Sat, Dec 18, 2021 at 2:25 PM Bjørn Mork <bjorn@mork.no> wrote:
>>> Sergey Ryazanov <ryazanov.s.a@gmail.com> writes:
>>>> ath25 can not be switched to the DSA implementation due to lack of the
>>>> DTS support.
>>>
>>> I fully understand and accept that this isn't made a priority.  But the
>>> explanation is misleading. It's definitely *possible* to use a DSA
>>> driver without DTS.  There are examples in mainline.  So "cannot" is
>>> wrong.
>>
>> Yep, I know that in general a DSA switch can be configured via the
>> platform data as any other device. But in this particular case, the
>> particular 88E6060 switch support can not be switched to the DSA
>> implementation because the DSA implementation does not support
>> configuration via the platform data.
>>
>> I checked the kernel code and the OpenWrt patches and found the only
>> board with the 88E6060 switch and this board utilizes DTS for its
>> configuration:
>
> NET_DSA_MV88E6060 has already been used for this device (tl-wr941nd v2/
> v3) in ar71xx, using platform data
>
>
> https://git.openwrt.org/?p=openwrt/openwrt.git;a=blob;f=target/linux/ar71xx/files/arch/mips/ath79/mach-tl-wr941nd.c;hb=refs/heads/openwrt-19.07
> https://git.openwrt.org/?p=openwrt/openwrt.git;a=blob;f=target/linux/ar71xx/config-4.14;h=9a524fae4316caa10431bd6b3b4dadbe8660f14c;hb=refs/heads/openwrt-19.07#l433
> https://git.openwrt.org/?p=openwrt/openwrt.git;a=blob;f=target/linux/ar71xx/base-files/etc/board.d/02_network;h=44fce970c0fd8b4811242fac0b53764a09244a2f;hb=refs/heads/openwrt-19.07#l324

Thank you. My mistake was that I was looking for a  88E6060 specific
structure. Bjorn was kind and explained that a common structure
(struct dsa_chip_data) is used to configure the DSA. Your example now
completes the picture!

The last link should be:
https://git.openwrt.org/?p=openwrt/openwrt.git;a=blob;f=target/linux/ar71xx/base-files/etc/board.d/02_network;h=44fce970c0fd8b4811242fac0b53764a09244a2f;hb=refs/heads/openwrt-19.07#l531

The 324 line contains a code for RB941-2ND, while the code for
TL-WR941ND begins on line 531.

> so it should be possible for ath25 as well, although the effort might
> not be worth it, considering the age and specifications of the target
> devices.

As it turned out, the kernel switching to the DSA is a relatively
simple task in itself. I see a couple additional complications related
to the building process, kernel initialization and user experience. To
properly support the DSA switch configuration, we need a board model
"autodetection" as well as per board image generation. At the moment
the ath25 have no framework for these tasks. It produces a single
generic image for all boards. So, we need to introduce per board image
generation and a kernel code for MIPS machines handling. Also the DSA
introduction will seriously disturb the user experience due to the
inability to smoothly update the network config. I just recall a lot
of talks after migration of other targets.

I personally no longer use ath25 devices and have no motivation to
deal with this not hard, but complex task. According to annual
discussions about the ath25 target decommission [1,2], there are
surprisingly a lot of users of these devices. Maybe someone of the
active users of these boards would like to get the ball rolling. So
our discussion today will be a good starting point for such a brave
man :)

1. https://www.mail-archive.com/openwrt-devel@lists.openwrt.org/msg60168.html
2. https://www.mail-archive.com/openwrt-devel@lists.openwrt.org/msg54812.html