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]
Message-ID:
 <PA4PR04MB9638451FA374CD3B5BB86A4AD1922@PA4PR04MB9638.eurprd04.prod.outlook.com>
Date: Mon, 2 Sep 2024 07:05:37 +0000
From: David Lin <yu-hao.lin@....com>
To: Sascha Hauer <s.hauer@...gutronix.de>
CC: Francesco Dolcini <francesco@...cini.it>, Calvin Owens
	<calvin@...nvd.org>, Brian Norris <briannorris@...omium.org>, Kalle Valo
	<kvalo@...nel.org>, "linux-wireless@...r.kernel.org"
	<linux-wireless@...r.kernel.org>, "linux-kernel@...r.kernel.org"
	<linux-kernel@...r.kernel.org>, "kernel@...gutronix.de"
	<kernel@...gutronix.de>
Subject: RE: [EXT] [RFC PATCH 0/4] mwifiex: add support for iw61x

> From: David Lin
> Sent: Monday, September 2, 2024 2:54 PM
> To: 'Sascha Hauer' <s.hauer@...gutronix.de>
> Cc: Francesco Dolcini <francesco@...cini.it>; Calvin Owens
> <calvin@...nvd.org>; Brian Norris <briannorris@...omium.org>; Kalle Valo
> <kvalo@...nel.org>; linux-wireless@...r.kernel.org;
> linux-kernel@...r.kernel.org; kernel@...gutronix.de
> Subject: RE: [EXT] [RFC PATCH 0/4] mwifiex: add support for iw61x
> 
> > From: Sascha Hauer <s.hauer@...gutronix.de>
> > Sent: Monday, September 2, 2024 2:41 PM
> > To: David Lin <yu-hao.lin@....com>
> > Cc: Francesco Dolcini <francesco@...cini.it>; Calvin Owens
> > <calvin@...nvd.org>; Brian Norris <briannorris@...omium.org>; Kalle
> > Valo <kvalo@...nel.org>; linux-wireless@...r.kernel.org;
> > linux-kernel@...r.kernel.org; kernel@...gutronix.de
> > Subject: Re: [EXT] [RFC PATCH 0/4] mwifiex: add support for 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 Mon, Sep 02, 2024 at 02:24:53AM +0000, David Lin wrote:
> > > > From: Sascha Hauer <s.hauer@...gutronix.de>
> > > > Sent: Monday, August 26, 2024 3:27 PM
> > > > To: Francesco Dolcini <francesco@...cini.it>
> > > > Cc: Calvin Owens <calvin@...nvd.org>; Brian Norris
> > > > <briannorris@...omium.org>; Kalle Valo <kvalo@...nel.org>; David
> > > > Lin <yu-hao.lin@....com>; linux-wireless@...r.kernel.org;
> > > > linux-kernel@...r.kernel.org; kernel@...gutronix.de; Sascha Hauer
> > > > <s.hauer@...gutronix.de>
> > > > Subject: [EXT] [RFC PATCH 0/4] mwifiex: add support for 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
> > > >
> > > >
> > > > This series adds support for the iw61x chips to the mwifiex driver.
> > > > There are a few things to address, hence the RFC status. See the
> > > > commit messages for details. The series is based on wireless-next/main.
> > > >
> > > > I am sending this now since people requested it here [1], but as
> > > > it's out now feel free to leave your comments to the issues
> > > > mentioned (or others I haven't mentioned ;)
> > > >
> > > > [1]
> > > > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2F
> > > > lo
> > > >
> >
> re.kern%2F&data=05%7C02%7Cyu-hao.lin%40nxp.com%7C6125c51da3704fe10
> > a5
> > > >
> >
> a08dccb1a24ef%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C6386
> > 08560
> > > >
> >
> 383160951%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV
> > 2luMz
> > > >
> >
> IiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=jfQ6FQimPpwr
> > nwUo
> > > > OCEhmpSadtrb15ymGiif%2B1UCdG0%3D&reserved=0
> > > >
> >
> el.org%2Fall%2F20240809094533.1660-1-yu-hao.lin%40nxp.com%2F&data=05
> > > >
> >
> %7C02%7Cyu-hao.lin%40nxp.com%7C184ab4fed58647150f8508dcc5a0789a%7
> > > >
> >
> C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C638602540229716119%
> > > >
> >
> 7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJB
> > > >
> >
> TiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=cACBHxaQvcOqu6ri
> > > > BoAlZDONRlGQ4j5DcglEV9T%2BpYU%3D&reserved=0
> > > >
> > > > Sascha
> > > >
> > > >
> > > > Sascha Hauer (4):
> > > >   wifi: mwifiex: release firmware at remove time
> > > >   wifi: mwifiex: handle VDLL
> > > >   wifi: mwifiex: wait longer for SDIO card status
> > > >   mwifiex: add iw61x support
> > > >
> > > >  drivers/net/wireless/marvell/mwifiex/cmdevt.c | 86
> > +++++++++++++++++++
> > > >  drivers/net/wireless/marvell/mwifiex/fw.h     | 16 ++++
> > > >  drivers/net/wireless/marvell/mwifiex/main.c   |  9 +-
> > > >  drivers/net/wireless/marvell/mwifiex/main.h   |  4 +
> > > >  drivers/net/wireless/marvell/mwifiex/sdio.c   | 81
> ++++++++++++++++-
> > > >  drivers/net/wireless/marvell/mwifiex/sdio.h   |  3 +
> > > >  .../net/wireless/marvell/mwifiex/sta_event.c  |  4
> > > > +  .../net/wireless/marvell/mwifiex/uap_event.c  |  4 +
> > > >  include/linux/mmc/sdio_ids.h                  |  3 +
> > > >  9 files changed, 205 insertions(+), 5 deletions(-)
> > > >
> > > > --
> > > > 2.39.2
> > >
> > > I think you ported VDLL related code from nxpwifi and you also
> > > traced our private/downstream MXM driver.
> >
> > I ported it from this repository:
> >
> > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith
> > ub.co
> >
> m%2Fnxp-imx%2Fmwifiex-iw612.git&data=05%7C02%7Cyu-hao.lin%40nxp.co
> >
> m%7C6125c51da3704fe10a5a08dccb1a24ef%7C686ea1d3bc2b4c6fa92cd99c5
> >
> c301635%7C0%7C0%7C638608560383172495%7CUnknown%7CTWFpbGZsb3d
> >
> 8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3
> >
> D%7C0%7C%7C%7C&sdata=5TgI0r4u2I9Pi1FATJx32Ubn7ufmbYsBR1XkpQLAIyQ
> > %3D&reserved=0
> >
> > Is that the one you are referring to as MXM driver?
> >
> 
> Yes.
> 
> > > If this is the case, I think you should know nxpwifi already cleaned
> > > up the porting VDLL code from MXM driver.
> > > I check your patch quickly. You ported the new SDIO data type
> > > (MWIFIEX_TYPE_VDLL) from nxpwifi, but you did not port the code to
> > > support this new data type from nxpwifi. In other word, you did not
> > > test your patch before submission (same as some of your patches).
> >
> > I did test it. It works with the iw61x as well as older chips. There
> > are likely details I haven't tested, but it generally works. If there
> > are details I should test additionally please let me know.
> >
> > >
> > > Another thing is that this new SDIO data type should be handled
> > > carefully with other existed SDIO data type.
> > >
> > > Nxpwifi only supports new SDIO mode, so the modification to support
> > > NXPWIFI_TYPE_VDLL can be clean and simple. If you want to port the
> > > code to Mwifiex, there is no one-to-one modification of the code.
> > >
> > > Another important thing is that you should consider if your
> > > modifications will affect existed devices or not.
> > > You need to check if you should check firmware version or chip type
> > > before adding some code.
> >
> > The VDLL code I added for the iw61x only reacts to the EVENT_VDLL_IND
> > event. So as long as a firmware doesn't send such an event nothing is
> > changed with this patch, and I haven't seen an older chip sending a VDLL
> event.
> >
> 
> How about IW61x? As I mentioned before, if you test IW61x on DFS channel,
> command timeout will happen.
> Without correct VDLL porting, you will encounter command timeout in some
> other test cases. But testing on DFS channel will be easier to reproduce the
> issue.
> 
> BTW, it is not a trivial job to port the support of VDLL data path from MXM
> driver to Mwifiex.
> 
> David

Another terrible thing is that driver can't load updated firmware of IW61x without correct VDLL porting.
Firmware will request VDLL after firmware is downloaded for updated version.
Because VDLL type for SDIO data path is working with existed SDIO data type. Some code are used to
let this new SDIO data type can work with existed SDIO data types. If missing of these code, the porting
will have issues too.

David

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ