Re: [PATCH v5] Add new mac80211 driver mwlwifi.

[Maxime Bizon <mbizon@freebox.fr>]

On Tuesday 04 Aug 2015 à 18:11:29 (+0000), Chor Teck Law wrote:

Hi Chor,

> mwl8k was a driver for chips few generations older sponsored by
> Marvell. We did leverage part of driver framework that is still
> applicable. However, for the current development, the firmware API
> specs, chip capabilities and bandwidth requirements have changed in
> order to handle newer technologies and features.

this is a fullmac driver, what differs between them is:
 - how you boot the device / load firmware
 - how you send commands to it
 - datapath


from a quick glance at your new driver

 1) firmware loading works the same way

 2) "hostcmd" are used to communicate with the firmware, of course new
   commands are needed for newer standards, but a common API could be
   used for common basic operations

 3) rx datapath looks the same (look at struct mwl_rx_desc vs mwl8k_rxd_ap)

 4) AMPDU code is copied/pasted from mwl8k driver, even the original
   comments have not been updated:

+  /* Defer calling mwl8k_start_stream so that the current


> No, we are not treating the submission as dumping! We would not have
> responded with effort to meet the requests/feedback if so. We
> appreciate and have taken the feedbacks seriously to complete to
> patch6. In fact the submission was requested by some community
> members who has seen the benefit of its evolvement on openwrt
> github, and they would like to see the new driver consolidated into
> the wireless mainline.

judging from the mwl8k experience (hello, unhappy customer here),
mainline is indeed the goal, but after that, nothing.

driver & firmware left at version 1, unless customer (me in that case)
made an explicit bug report or feature request.

> Due to hardware, firmware, specs and requirements change over time,
> it is not feasible for us to revisit generations old products or
> making sure new changes are backward compatible with it. (If
> desired, we welcome the community to take any new useful changes
> that are independent of chip rev to other similar branches.)

no hardware specs, no firmware source or docs, community can only make
blind guesses.

also see my answer beyond.

> Lastly, I do not think we are creating a precedence with different
> generation of drivers supporting different families of chips.

these are firmware based chipsets, not hard-wired. having a common
driver for two completely different set of chipsets is indeed stupid,
and makes it unreadable.

but from my POV, your pattern is: build new chipset, obsolete previous
chipset, fork current firmware, make uncompatible changes to both
firmware & host driver to accomodate new chipset peculiarities.

and eventually, if a customer requests a mainline linux driver, then
write one... this is what I'd call "dumping"

-- 
Maxime