gree...@candelatech.com wrote:
> The vdev-start-response message should cause the
> completion to fire, even in the error case. Otherwise,
> the user still gets no useful information and everything
> is blocked until the timeout period.
>
> Add some warning text to print out the invalid status
Sathishkumar Muruganandam wrote:
> To support dual-band variant of QCA9984, new extended board data (eBDF)
> is introduced since existing board data ran out of space.
>
> Below is the brief implementation & design detail,
>
>
> 1. New OTP
Niklas Cassel wrote:
> ATH10K_SNOC builds just fine with COMPILE_TEST, so make that possible.
>
> Signed-off-by: Niklas Cassel
> Signed-off-by: Kalle Valo
Patch applied to ath-next branch of ath.git, thanks.
f1908735f141 ath10k: allow ATH10K_SNOC with COMPILE_TEST
--
Wen Gong wrote:
> If there are some tx packets pending in firmware, and then system
> enters suspend, firmware will fail for wow enable. This will trigger
> mac80211 to stop ath10k and download firmware again, then it is
> non-wow suspend.
>
> After add the waiting htt tx complete, then
Brian Norris wrote:
> Devices may provide their own MAC address via system firmware (e.g.,
> device tree), especially in the case where the device doesn't have a
> useful EEPROM on which to store its MAC address (e.g., for integrated
> Wifi).
>
> Use the generic device helper to retrieve the
On 2018-08-06 20:18, Rakesh Pillai wrote:
WCN3990 is a 37-bit target but can address memory range
only upto 35 bits. The 36th bit is used to control the
smmu/iommu translation and the 37th bit is used by the
internal bus masters to access the wifi subsystem internal
SRAM. With the DMA mask set
WCN3990 is a 37-bit target but can address memory range
only upto 35 bits. The 36th bit is used to control the
smmu/iommu translation and the 37th bit is used by the
internal bus masters to access the wifi subsystem internal
SRAM. With the DMA mask set to 37i-bit, the host driver
can get 37-bit
While I'm being overly vague and general...
* Doing some form of ack compression (whether in the tcp stack or in
mac80211) seems useful. It's really
hard to fill 4Mbytes one way and the needed number of acks the other.
I'd also pointed out (on some thread on the make-wifi-fast list that I
can't
I have not been on this thread (I have had to shut down my wifi lab
and am not planning on doing any more wifi work in the future). But
for what it's worth:
* tcp_pacing_shift affects the performance of the tcp stack only. I
think 16ms is an outrageous amount, and I'm thinking we actually have
a
Johannes Berg writes:
> On Mon, 2018-09-03 at 13:11 +0200, Toke Høiland-Jørgensen wrote:
>
>> > 6 vs. 8, I think? But I didn't follow the full discussion.
>
> Err, I just realized that I was completely wrong - the default, of
> course, is 10. So smaller values mean more buffering.
>
> Most of my
On Mon, 2018-09-03 at 13:11 +0200, Toke Høiland-Jørgensen wrote:
> > 6 vs. 8, I think? But I didn't follow the full discussion.
Err, I just realized that I was completely wrong - the default, of
course, is 10. So smaller values mean more buffering.
Most of my argumentation was thus utter
Johannes Berg writes:
> On Thu, 2018-08-30 at 16:32 -0700, Grant Grundler wrote:
>> On Sun, Aug 12, 2018 at 10:37 PM Wen Gong wrote:
>> ...
>> > I have tested with your method for shift 6/8/10/7 all twice time in open
>> > air environment.
>>
>> I've attached the graphed data which Wen
Hi,
Sorry ... this got delayed again.
> I had introduced a change db3bdcb9c3ff (" mac80211: allow AP_VLAN
> operation on crypto controlled devices ") for supporting VLAN
> functionality on ath10k devices; this commit has broken 4 addr support
> on ath10k devices as I was advertising the
On Fri, 2018-08-31 at 15:29 +0300, Kalle Valo wrote:
> Too me this feels like a bad idea but I'm not familiar enough with
> mac80211 to really comment on this. What kind of implications does this
> have for Mesh or ATF, for example? Adding Johannes and Toke to hear
> about their opinion about
Anilkumar Kolli writes:
> On 2018-08-31 19:52, Toke Høiland-Jørgensen wrote:
>> Kalle Valo writes:
>>
>>> Anilkumar Kolli writes:
>>>
Mesh path metric needs txrate information from ieee80211_tx_status()
call but in ath10k there is no mechanism to report tx rate
information
On Thu, 2018-08-30 at 16:32 -0700, Grant Grundler wrote:
> On Sun, Aug 12, 2018 at 10:37 PM Wen Gong wrote:
> ...
> > I have tested with your method for shift 6/8/10/7 all twice time in open
> > air environment.
>
> I've attached the graphed data which Wen provided me and I made one
>
On Fri, 2018-08-31 at 12:56 -0700, Pradeep Kumar Chitrapu wrote:
>
> + * @ftm_responder: whether to enable fine timing measurement FTM
> functionality
missing "responder" somewhere there :)
> + * @ftmr_params: configurable lci/civic parameter when enabling FTM
> responder.
Perhaps the
> +struct cfg80211_ftm_responder_params {
> + u8 *lci;
> + u8 *civic;
These should be const
> + [NL80211_ATTR_FTM_RESPONDER] = { .type = NLA_FLAG},
missing a space, but didn't we also say it should be NLA_U8 or so
(allowing the values 0/1) in order to allow later updating this to
18 matches
Mail list logo
