Message ID | 20240621075208.513497-1-yu-hao.lin@nxp.com (mailing list archive) |
---|---|
Headers | show |
Series | wifi: nxpwifi: create nxpwifi to support iw61x | expand |
On Fri, Jun 21, 2024 at 12:52 AM David Lin <yu-hao.lin@nxp.com> wrote: > This driver is a derivative of existing Mwifiex [1] and based on similar > full-MAC architecture [2]. For the record, mwifiex is a fairly awful driver. For one, its locking schemes are generally unhelpful or nonexistent, and sometimes placebo-like (as in, they look like they are protecting certain data, but they do a very poor job of it). So I'm not sure this is a promising start. It was just yesterday, in fact, that I was telling a colleague that if mwifiex was proposed for inclusion in mainline today, I would reject it. Also, I'm far from interested in reviewing a new driver here. My only interest in mwifiex is in making sure existing hardware (especially those used on Chromebooks) doesn't get significantly worse. That interest doesn't extend to "nxpwifi". I just want to be up-front about it, and that you might as well drop me from the CC list. (Of course, that's not a requirement. I can ignore email too.) Brian
On Fri, 2024-06-21 at 15:51 +0800, David Lin wrote: > > wifi: nxpwifi: add ioctl.h even the name here sounds questionable :) > 48 files changed, 34928 insertions(+) > This is ... huge. I don't know who could possibly review it at all. A quick look suggests that it's got a bunch of things we probably really don't want to do that way any more, like using semaphores in a wifi driver: > +#include <linux/semaphore.h> having a bunch of (sometimes wrong!) element definitions in a driver: > +struct ieee_types_aid { ... > + u16 aid; embedding a (default?) wireless_dev when clearly the driver supports more than one netdev/wdev: > + struct wireless_dev wdev; Having multiple own workqueues is probably also unreasonable: > + struct workqueue_struct *dfs_cac_workqueue; > + struct workqueue_struct *dfs_chan_sw_workqueue; > + struct workqueue_struct *workqueue; > + struct workqueue_struct *rx_workqueue; > + struct workqueue_struct *host_mlme_workqueue; as is a misnamed mutex, but really you could use wiphy work and likely not have a mutex at all: > + /* mutex for scan */ > + struct mutex async_mutex; (even mac80211 only has one mutex left, and that's for a specific case where otherwise we have some issues!) questionable locking schemes, as evidenced simply by "is something locked" variables existing: > + bool rx_locked; > + bool main_locked; locking code, rather than data? > + /* spin lock for main process */ > + spinlock_t main_proc_lock; but also simple things like not wanting to use ERR_PTR()? > +static int nxpwifi_register(void *card, struct device *dev, > + struct nxpwifi_if_ops *if_ops, void **padapter) (padapter is an out parameter) Why random numbers for cookies instead of just assigning from a static variable: > + *cookie = get_random_u32() | 1; Open-coding -EPERM? > + if (nxpwifi_deinit_priv_params(priv)) > + return -1; Using -EFAULT for FW errors seems like a really bad idea: > + if (nxpwifi_drv_get_data_rate(priv, &rate)) { > + nxpwifi_dbg(priv->adapter, ERROR, > + "getting data rate error\n"); > + return -EFAULT; But I really just scrolled through this briefly, this wasn't a real review. I don't know who could do a real review, but as is, it looks like someone _should_. johannes
Hi Johannes, > From: Johannes Berg <johannes@sipsolutions.net> > Sent: Saturday, June 22, 2024 2:20 AM > To: David Lin <yu-hao.lin@nxp.com>; linux-wireless@vger.kernel.org > Cc: linux-kernel@vger.kernel.org; briannorris@chromium.org; > kvalo@kernel.org; francesco@dolcini.it; Pete Hsieh > <tsung-hsien.hsieh@nxp.com> > Subject: [EXT] Re: [PATCH 00/43] wifi: nxpwifi: create nxpwifi to support iw61x > > Caution: This is an external email. Please take care when clicking links or > opening attachments. When in doubt, report the message using the 'Report > this email' button > > > On Fri, 2024-06-21 at 15:51 +0800, David Lin wrote: > > > > wifi: nxpwifi: add ioctl.h > > even the name here sounds questionable :) > > > 48 files changed, 34928 insertions(+) > > > > This is ... huge. I don't know who could possibly review it at all. > > A quick look suggests that it's got a bunch of things we probably really don't > want to do that way any more, like > > using semaphores in a wifi driver: > > > +#include <linux/semaphore.h> > > having a bunch of (sometimes wrong!) element definitions in a driver: > > > +struct ieee_types_aid { > ... > > + u16 aid; > > embedding a (default?) wireless_dev when clearly the driver supports more > than one netdev/wdev: > > > + struct wireless_dev wdev; > > Having multiple own workqueues is probably also unreasonable: > > > + struct workqueue_struct *dfs_cac_workqueue; > > + struct workqueue_struct *dfs_chan_sw_workqueue; > > + struct workqueue_struct *workqueue; > > + struct workqueue_struct *rx_workqueue; > > + struct workqueue_struct *host_mlme_workqueue; > > as is a misnamed mutex, but really you could use wiphy work and likely not > have a mutex at all: > > > + /* mutex for scan */ > > + struct mutex async_mutex; > > (even mac80211 only has one mutex left, and that's for a specific case where > otherwise we have some issues!) > > questionable locking schemes, as evidenced simply by "is something locked" > variables existing: > > > + bool rx_locked; > > + bool main_locked; > > locking code, rather than data? > > > + /* spin lock for main process */ > > + spinlock_t main_proc_lock; > > but also simple things like not wanting to use ERR_PTR()? > > > +static int nxpwifi_register(void *card, struct device *dev, > > + struct nxpwifi_if_ops *if_ops, void > > +**padapter) > > (padapter is an out parameter) > > Why random numbers for cookies instead of just assigning from a static > variable: > > > + *cookie = get_random_u32() | 1; > > Open-coding -EPERM? > > > + if (nxpwifi_deinit_priv_params(priv)) > > + return -1; > > Using -EFAULT for FW errors seems like a really bad idea: > > > + if (nxpwifi_drv_get_data_rate(priv, &rate)) { > > + nxpwifi_dbg(priv->adapter, ERROR, > > + "getting data rate error\n"); > > + return -EFAULT; > > > But I really just scrolled through this briefly, this wasn't a real review. I don't > know who could do a real review, but as is, it looks like someone _should_. > > Johannes Enhancement of nxpwifi based on your comments is ongoing. Thanks, David