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] [day] [month] [year] [list]
Date:   Fri, 02 Sep 2016 21:23:01 +0300
From:   Kalle Valo <kvalo@...eaurora.org>
To:     Bjorn Andersson <bjorn.andersson@...aro.org>
Cc:     Eugene Krasnikov <k.eugene.e@...il.com>,
        wcn36xx@...ts.infradead.org, linux-wireless@...r.kernel.org,
        netdev@...r.kernel.org, linux-kernel@...r.kernel.org,
        linux-arm-msm@...r.kernel.org
Subject: Re: [PATCH v3 1/2] wcn36xx: Transition driver to SMD client

Bjorn Andersson <bjorn.andersson@...aro.org> writes:

> On Fri 02 Sep 09:24 PDT 2016, Kalle Valo wrote:
>
>> Bjorn Andersson <bjorn.andersson@...aro.org> writes:
>> 
>> > --- a/drivers/net/wireless/ath/wcn36xx/Kconfig
>> > +++ b/drivers/net/wireless/ath/wcn36xx/Kconfig
>> > @@ -1,6 +1,6 @@
>> >  config WCN36XX
>> >  	tristate "Qualcomm Atheros WCN3660/3680 support"
>> > -	depends on MAC80211 && HAS_DMA
>> > +	depends on MAC80211 && HAS_DMA && QCOM_SMD
>> 
>> While I had this patch on my pending branch I noticed that I can't
>> compile wcn36xx on x86 anymore. This is actually quite inconvenient, for
>> example then it's easy to miss mac80211 API changes etc. Is there any
>> way we could continue build testing wcn36xx on x86 (or all) platforms?
>> 
>
> Sorry about that, we should at least be able to COMPILE_TEST it in
> non-qcom builds. Thanks for letting me know.

Yeah, that would be better. Even though it's a bit shame that
COMPILE_TEST disables DEBUG_INFO (I use the same build also for
development) so I need to toggle it on and off whenever I need debug
symbols. Oh well...

> And the driver should also depend on QCOM_WCNSS_CTRL, in the normal
> case.
>
> I'll respin this, unless you prefer an incremental patch for those
> changes(?)

Yes, please respin.

>> Also what about older platforms? Earlier I used wcn36xx on my Nexus 4
>> with help of backports project. I can't do that anymore, right?
>> 
>
> This has been tested on 8064, 8974 and 8916. So your Nexus 4 is covered.
>
> Unfortunately I don't have a Nexus 4, but we currently have Nexus 7
> (the 8064 version), Xperia Z, Xperia Z1 and DB410c using this chip and
> all four has been tested with this code.

Actually I meant running wcn36xx on older kernels, where your QCOM_SMD
is not yet supported.

> I've staged the PIL/remoteproc (firmware "loader") driver for v4.9, so
> with this patch the only thing missing to fill in the dts files is one
> clock from the RPM.

Nice.

> JFYI, There seems to be some race in the removal path, which I will look
> into. But I would prefer if we could merge this to make the driver
> usable, and more accessible to work on.

Sure, a race like that isn't that big of a deal compared to the benefits
your work brings. But it's good to document knows regressions to the
commit log anyway so that others can be prepared if they test it.

-- 
Kalle Valo

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ