Re: [Letux-kernel] [BUG] 4.8-rc1: wlcore: NULL pointer dereference in wlcore_op_get_expected_throughput

[H. Nikolaus Schaller]

Hi Andrey,

> Am 09.08.2016 um 01:49 schrieb Andrey Utkin :
> 
> On Mon, Aug 08, 2016 at 11:26:38PM +0200, H. Nikolaus Schaller wrote:
>> Here is what I see in 4.8-rc1 on Pyra device after typing "poweroff".
>> I hope someone knows what it means.
>> 
>> BR and thanks,
>> Nikolaus
>> 
>> root@letux:~# poweroff
>> 
>> Broadcast message from root@letux (pts/0) (Mon Aug  8 21:19:21 2016):
>> 
>> The system is going down for system halt NOW!
>> 
>> xinit: unexpected signal 15
>> [info] Using makefile-style concurrent boot in runlevel 0.
>> [] Stopping ISC DHCP server: dhcpd failed!
>> [] Stopping bluetooth: /usr/sbin/bluetoothd. ok 
>> [] Stopping automount ok 
>> [] Not running dhcpcd because /etc/network/interfaces ... failed!
>> [] defines some interfaces that will use a DHCP client ... failed!
>> [] Shutting down ALSA...done.
>> [] Asking all remaining processes to terminate...done.
>> [] All processes ended within 1 seconds...done.
>> [] Stopping enhanced syslogd: rsyslogd. ok 
>> [] Deconfiguring network interfaces...SIOCDELRT: No such process
>> Device "usb0" does not exist.
>> Cannot find device "usb0"
>> done.
>> [info] Saving the system clock.
>> [info] Hardware Clock updated to Mon Aug  8 21:19:30 UTC 2016.
>> [] Unmounting temporary filesystems...done.
>> [] Deactivating swap...done.
>> [] Unmounting local filesystems...done.
>> [  613.196751] EXT4-fs (mmcblk1p2): re-mounted. Opts: (null)
>> [info] Will now halt.
>> [  615.348870] wlan0: deauthenticating from 00:12:bf:7d:ce:e6 by local 
>> choice (Reason: 3=DEAUTH_LEAVING)
>> [  615.589721] Unable to handle kernel NULL pointer dereference at virtual 
>> address 0a2a
>> [  615.598249] pgd = ec3a4000
>> [  615.601220] [0a2a] *pgd=ab60f835, *pte=, *ppte=
>> [  615.607868] Internal error: Oops: 17 [#1] PREEMPT SMP ARM
>> [  615.613551] Modules linked in: hci_uart bnep bluetooth autofs4 usb_f_ecm 
>> usb_f_rndis u_ether libcomposite configfs ipv6 cdc_ether usbnet cdc_acm arc4 
>> wl18xx wlcore mac80211 omapdrm cfg80211 drm_kms_helper cfbfillrect 
>> syscopyarea cfbimgblt sysfillrect sysimgblt fb_sys_fops cfbcopyarea 
>> snd_soc_omap_hdmi_audio panel_mipi_debug drm dwc3 connector_hdmi 
>> encoder_tpd12s015 w2cbw003_bluetooth snd_soc_omap_abe_twl6040 
>> snd_soc_twl6040 wwan_on_off leds_gpio omapdss pwm_omap_dmtimer pwm_bl 
>> ehci_omap wlcore_sdio dwc3_omap leds_is31fl319x snd_soc_ts3a225e 
>> gpio_twl6040 bq27xxx_battery_i2c tsc2007 bq27xxx_battery leds_tca6507 
>> crtouch_mt bq2429x_charger twl6040_vibra ina2xx palmas_pwrbutton 
>> palmas_gpadc as5013 tca8418_keypad usb3503 bma150 bmg160_i2c bno055 
>> bmg160_core input_polldev snd_soc_omap_mcpdm snd_soc_omap_mcbsp snd_soc_omap 
>> snd_pcm_dmaengine [last unloaded: g_ether]
>> [  615.694303] CPU: 0 PID: 3788 Comm: halt Tainted: GB   W   
>> 4.8.0-rc1-letux+ #655
>> [  615.702727] Hardware name: Generic OMAP5 (Flattened Device Tree)
>> [  615.709052] task: eb2564c0 task.stack: ec456000
>> [  615.713913] PC is at wlcore_op_get_expected_throughput+0x14/0x20 [wlcore]
>> [  615.721357] LR is at sta_set_sinfo+0xc18/0x1110 [mac80211]
>> [  615.727145] pc : []lr : []psr: a00f0013
>> [  615.727145] sp : ec457c48  ip :   fp : 400f0013
>> [  615.739237] r10: ec414620  r9 : eb604b30  r8 : eb604c90
>> [  615.744735] r7 : c0b02554  r6 : bf4815c4  r5 : bf4de03c  r4 : ec823400
>> [  615.751613] r3 :   r2 :   r1 : 00c8  r0 : 03e8
>> [  615.758492] Flags: NzCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment 
>> none
>> [  615.766008] Control: 10c5387d  Table: ac3a406a  DAC: 0051
>> [  615.772062] Process halt (pid: 3788, stack limit = 0xec456218)
>> [  615.778208] Stack: (0xec457c48 to 0xec458000)
>> [  615.782806] 7c40:   0001  bf40d540 c0a76630 
>> eb604f3c bf40d540
>> [  615.791434] 7c60: ec414620   eb604a8c eb604c90  
>> 0001 eb604800
>> [  615.800049] 7c80: ec823400 ec45a600 ec45a600 ec414b2c 0001 ec414b94 
>>  bf40d540
>> [  615.808682] 7ca0:  0003 ec457cb0 ec414b94 ec457cb8 bf40d75c 
>> eb604808 eb604808
>> [  615.817308] 7cc0:  ec45a600  ec414620 ec45ac50 ec457d1e 
>> 00c0 0003
>> [  615.825940] 7ce0:  bf4629e8 0001 ec457d1e ec45a600 ec457d60 
>> ec457d1e 0001
>> [  615.834563] 7d00: bf38707c bf386c94 0003 bf4680cc ec457d1e  
>> ec45a67c 00c0
>> [  615.843178] 7d20: 1200 e6ce7dbf efbeadde 1200 e6ce7dbf 0003 
>> 0001 ec892bd4
>> [  615.851801] 7d40: ec45a000 c0b02554 ec4142a0 bf38707c bf386c94 0003 
>>  bf352b58
>> [  615.860428] 7d60: ec892bd4   0003 ec45a648 ec45a608 
>> ec414000 ec414000
>> [  615.869051] 7d80: ec414000 ec45a000 0003 bf3590c0  0003 
>>  ec45a000
>> [  615.877674] 7da0: ec414000 ec45a648 ec45a608 ec414000 ec414000 0009 
>> 

net-next is OPEN

[David Miller]

I've merged 'net' into 'net-next' and applied a bunch of pending stuff.

Fire at will...
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [Letux-kernel] [BUG] 4.8-rc1: wlcore: NULL pointer dereference in wlcore_op_get_expected_throughput

[Andrey Utkin]

On Mon, Aug 08, 2016 at 11:26:38PM +0200, H. Nikolaus Schaller wrote:
> Here is what I see in 4.8-rc1 on Pyra device after typing "poweroff".
> I hope someone knows what it means.
> 
> BR and thanks,
> Nikolaus
> 
> root@letux:~# poweroff
> 
> Broadcast message from root@letux (pts/0) (Mon Aug  8 21:19:21 2016):
> 
> The system is going down for system halt NOW!
> 
> xinit: unexpected signal 15
> [info] Using makefile-style concurrent boot in runlevel 0.
> [] Stopping ISC DHCP server: dhcpd failed!
> [] Stopping bluetooth: /usr/sbin/bluetoothd. ok 
> [] Stopping automount ok 
> [] Not running dhcpcd because /etc/network/interfaces ... failed!
> [] defines some interfaces that will use a DHCP client ... failed!
> [] Shutting down ALSA...done.
> [] Asking all remaining processes to terminate...done.
> [] All processes ended within 1 seconds...done.
> [] Stopping enhanced syslogd: rsyslogd. ok 
> [] Deconfiguring network interfaces...SIOCDELRT: No such process
> Device "usb0" does not exist.
> Cannot find device "usb0"
> done.
> [info] Saving the system clock.
> [info] Hardware Clock updated to Mon Aug  8 21:19:30 UTC 2016.
> [] Unmounting temporary filesystems...done.
> [] Deactivating swap...done.
> [] Unmounting local filesystems...done.
> [  613.196751] EXT4-fs (mmcblk1p2): re-mounted. Opts: (null)
> [info] Will now halt.
> [  615.348870] wlan0: deauthenticating from 00:12:bf:7d:ce:e6 by local choice 
> (Reason: 3=DEAUTH_LEAVING)
> [  615.589721] Unable to handle kernel NULL pointer dereference at virtual 
> address 0a2a
> [  615.598249] pgd = ec3a4000
> [  615.601220] [0a2a] *pgd=ab60f835, *pte=, *ppte=
> [  615.607868] Internal error: Oops: 17 [#1] PREEMPT SMP ARM
> [  615.613551] Modules linked in: hci_uart bnep bluetooth autofs4 usb_f_ecm 
> usb_f_rndis u_ether libcomposite configfs ipv6 cdc_ether usbnet cdc_acm arc4 
> wl18xx wlcore mac80211 omapdrm cfg80211 drm_kms_helper cfbfillrect 
> syscopyarea cfbimgblt sysfillrect sysimgblt fb_sys_fops cfbcopyarea 
> snd_soc_omap_hdmi_audio panel_mipi_debug drm dwc3 connector_hdmi 
> encoder_tpd12s015 w2cbw003_bluetooth snd_soc_omap_abe_twl6040 snd_soc_twl6040 
> wwan_on_off leds_gpio omapdss pwm_omap_dmtimer pwm_bl ehci_omap wlcore_sdio 
> dwc3_omap leds_is31fl319x snd_soc_ts3a225e gpio_twl6040 bq27xxx_battery_i2c 
> tsc2007 bq27xxx_battery leds_tca6507 crtouch_mt bq2429x_charger twl6040_vibra 
> ina2xx palmas_pwrbutton palmas_gpadc as5013 tca8418_keypad usb3503 bma150 
> bmg160_i2c bno055 bmg160_core input_polldev snd_soc_omap_mcpdm 
> snd_soc_omap_mcbsp snd_soc_omap snd_pcm_dmaengine [last unloaded: g_ether]
> [  615.694303] CPU: 0 PID: 3788 Comm: halt Tainted: GB   W   
> 4.8.0-rc1-letux+ #655
> [  615.702727] Hardware name: Generic OMAP5 (Flattened Device Tree)
> [  615.709052] task: eb2564c0 task.stack: ec456000
> [  615.713913] PC is at wlcore_op_get_expected_throughput+0x14/0x20 [wlcore]
> [  615.721357] LR is at sta_set_sinfo+0xc18/0x1110 [mac80211]
> [  615.727145] pc : []lr : []psr: a00f0013
> [  615.727145] sp : ec457c48  ip :   fp : 400f0013
> [  615.739237] r10: ec414620  r9 : eb604b30  r8 : eb604c90
> [  615.744735] r7 : c0b02554  r6 : bf4815c4  r5 : bf4de03c  r4 : ec823400
> [  615.751613] r3 :   r2 :   r1 : 00c8  r0 : 03e8
> [  615.758492] Flags: NzCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment 
> none
> [  615.766008] Control: 10c5387d  Table: ac3a406a  DAC: 0051
> [  615.772062] Process halt (pid: 3788, stack limit = 0xec456218)
> [  615.778208] Stack: (0xec457c48 to 0xec458000)
> [  615.782806] 7c40:   0001  bf40d540 c0a76630 
> eb604f3c bf40d540
> [  615.791434] 7c60: ec414620   eb604a8c eb604c90  
> 0001 eb604800
> [  615.800049] 7c80: ec823400 ec45a600 ec45a600 ec414b2c 0001 ec414b94 
>  bf40d540
> [  615.808682] 7ca0:  0003 ec457cb0 ec414b94 ec457cb8 bf40d75c 
> eb604808 eb604808
> [  615.817308] 7cc0:  ec45a600  ec414620 ec45ac50 ec457d1e 
> 00c0 0003
> [  615.825940] 7ce0:  bf4629e8 0001 ec457d1e ec45a600 ec457d60 
> ec457d1e 0001
> [  615.834563] 7d00: bf38707c bf386c94 0003 bf4680cc ec457d1e  
> ec45a67c 00c0
> [  615.843178] 7d20: 1200 e6ce7dbf efbeadde 1200 e6ce7dbf 0003 
> 0001 ec892bd4
> [  615.851801] 7d40: ec45a000 c0b02554 ec4142a0 bf38707c bf386c94 0003 
>  bf352b58
> [  615.860428] 7d60: ec892bd4   0003 ec45a648 ec45a608 
> ec414000 ec414000
> [  615.869051] 7d80: ec414000 ec45a000 0003 bf3590c0  0003 
>  ec45a000
> [  615.877674] 7da0: ec414000 ec45a648 ec45a608 ec414000 ec414000 0009 
> ec96cc0c 
> [  615.886300] 7dc0:  bf31cba8 ec45a608 ec4142a0 ec45a000 bf31cd70 
>  
> [  615.894918] 7de0: c06d0594 c06da874 c0b98444 fff7  0009 
> 

Re: [PATCH v2] RANDOM: ATH9K RNG delivers zero bits of entropy

[Jason Cooper]

Hi Stephan,

On Mon, Aug 08, 2016 at 05:29:30PM +, Jason Cooper wrote:
> On Mon, Aug 08, 2016 at 08:41:36AM +0200, Stephan Mueller wrote:
...
> > If you think that this patch is a challenge because your driver starts to 
> > spin, please help and offer another solution.
> 
> Well, I don't buy the reasoning listed above for not using the hwrng
> framework.  Interrupt timings were never designed to be a source of entropy
> either.  We need to grab it where ever we can find it, especially on
> embedded systems.  Documentation/hw_random.txt even says:
> 
> """
> This data is NOT CHECKED by any fitness tests, and could potentially be
> bogus (if the hardware is faulty or has been tampered with).
> """
> 
> I really don't think there's a problem with adding these sorts of
> sources under char/hw_random/.  I think the only thing we would be
> concerned about, other than the already addressed entropy estimation,
> would be constraining the data rate.

Further research yields char/hw_random/timeriomem-rng.c

It could use an update to ->read() vice data_{present,read}(), but it's
functionally exactly what the ath9k rng is doing. :)

thx,

Jason.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[BUG] 4.8-rc1: wlcore: NULL pointer dereference in wlcore_op_get_expected_throughput

[H. Nikolaus Schaller]

Here is what I see in 4.8-rc1 on Pyra device after typing "poweroff".
I hope someone knows what it means.

BR and thanks,
Nikolaus

root@letux:~# poweroff

Broadcast message from root@letux (pts/0) (Mon Aug  8 21:19:21 2016):

The system is going down for system halt NOW!

xinit: unexpected signal 15
[info] Using makefile-style concurrent boot in runlevel 0.
[] Stopping ISC DHCP server: dhcpd failed!
[] Stopping bluetooth: /usr/sbin/bluetoothd. ok 
[] Stopping automount ok 
[] Not running dhcpcd because /etc/network/interfaces ... failed!
[] defines some interfaces that will use a DHCP client ... failed!
[] Shutting down ALSA...done.
[] Asking all remaining processes to terminate...done.
[] All processes ended within 1 seconds...done.
[] Stopping enhanced syslogd: rsyslogd. ok 
[] Deconfiguring network interfaces...SIOCDELRT: No such process
Device "usb0" does not exist.
Cannot find device "usb0"
done.
[info] Saving the system clock.
[info] Hardware Clock updated to Mon Aug  8 21:19:30 UTC 2016.
[] Unmounting temporary filesystems...done.
[] Deactivating swap...done.
[] Unmounting local filesystems...done.
[  613.196751] EXT4-fs (mmcblk1p2): re-mounted. Opts: (null)
[info] Will now halt.
[  615.348870] wlan0: deauthenticating from 00:12:bf:7d:ce:e6 by local choice 
(Reason: 3=DEAUTH_LEAVING)
[  615.589721] Unable to handle kernel NULL pointer dereference at virtual 
address 0a2a
[  615.598249] pgd = ec3a4000
[  615.601220] [0a2a] *pgd=ab60f835, *pte=, *ppte=
[  615.607868] Internal error: Oops: 17 [#1] PREEMPT SMP ARM
[  615.613551] Modules linked in: hci_uart bnep bluetooth autofs4 usb_f_ecm 
usb_f_rndis u_ether libcomposite configfs ipv6 cdc_ether usbnet cdc_acm arc4 
wl18xx wlcore mac80211 omapdrm cfg80211 drm_kms_helper cfbfillrect syscopyarea 
cfbimgblt sysfillrect sysimgblt fb_sys_fops cfbcopyarea snd_soc_omap_hdmi_audio 
panel_mipi_debug drm dwc3 connector_hdmi encoder_tpd12s015 w2cbw003_bluetooth 
snd_soc_omap_abe_twl6040 snd_soc_twl6040 wwan_on_off leds_gpio omapdss 
pwm_omap_dmtimer pwm_bl ehci_omap wlcore_sdio dwc3_omap leds_is31fl319x 
snd_soc_ts3a225e gpio_twl6040 bq27xxx_battery_i2c tsc2007 bq27xxx_battery 
leds_tca6507 crtouch_mt bq2429x_charger twl6040_vibra ina2xx palmas_pwrbutton 
palmas_gpadc as5013 tca8418_keypad usb3503 bma150 bmg160_i2c bno055 bmg160_core 
input_polldev snd_soc_omap_mcpdm snd_soc_omap_mcbsp snd_soc_omap 
snd_pcm_dmaengine [last unloaded: g_ether]
[  615.694303] CPU: 0 PID: 3788 Comm: halt Tainted: GB   W   
4.8.0-rc1-letux+ #655
[  615.702727] Hardware name: Generic OMAP5 (Flattened Device Tree)
[  615.709052] task: eb2564c0 task.stack: ec456000
[  615.713913] PC is at wlcore_op_get_expected_throughput+0x14/0x20 [wlcore]
[  615.721357] LR is at sta_set_sinfo+0xc18/0x1110 [mac80211]
[  615.727145] pc : []lr : []psr: a00f0013
[  615.727145] sp : ec457c48  ip :   fp : 400f0013
[  615.739237] r10: ec414620  r9 : eb604b30  r8 : eb604c90
[  615.744735] r7 : c0b02554  r6 : bf4815c4  r5 : bf4de03c  r4 : ec823400
[  615.751613] r3 :   r2 :   r1 : 00c8  r0 : 03e8
[  615.758492] Flags: NzCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment none
[  615.766008] Control: 10c5387d  Table: ac3a406a  DAC: 0051
[  615.772062] Process halt (pid: 3788, stack limit = 0xec456218)
[  615.778208] Stack: (0xec457c48 to 0xec458000)
[  615.782806] 7c40:   0001  bf40d540 c0a76630 
eb604f3c bf40d540
[  615.791434] 7c60: ec414620   eb604a8c eb604c90  
0001 eb604800
[  615.800049] 7c80: ec823400 ec45a600 ec45a600 ec414b2c 0001 ec414b94 
 bf40d540
[  615.808682] 7ca0:  0003 ec457cb0 ec414b94 ec457cb8 bf40d75c 
eb604808 eb604808
[  615.817308] 7cc0:  ec45a600  ec414620 ec45ac50 ec457d1e 
00c0 0003
[  615.825940] 7ce0:  bf4629e8 0001 ec457d1e ec45a600 ec457d60 
ec457d1e 0001
[  615.834563] 7d00: bf38707c bf386c94 0003 bf4680cc ec457d1e  
ec45a67c 00c0
[  615.843178] 7d20: 1200 e6ce7dbf efbeadde 1200 e6ce7dbf 0003 
0001 ec892bd4
[  615.851801] 7d40: ec45a000 c0b02554 ec4142a0 bf38707c bf386c94 0003 
 bf352b58
[  615.860428] 7d60: ec892bd4   0003 ec45a648 ec45a608 
ec414000 ec414000
[  615.869051] 7d80: ec414000 ec45a000 0003 bf3590c0  0003 
 ec45a000
[  615.877674] 7da0: ec414000 ec45a648 ec45a608 ec414000 ec414000 0009 
ec96cc0c 
[  615.886300] 7dc0:  bf31cba8 ec45a608 ec4142a0 ec45a000 bf31cd70 
 
[  615.894918] 7de0: c06d0594 c06da874 c0b98444 fff7  0009 
ec457e3c bf47bb38
[  615.903540] 7e00: ec96cc0c   c0152df8 ec45a000 ec457e58 
1042 1003
[  615.912162] 7e20:  c0152e40  0009 ec457e3c c0620eb4 
0009 ec45a000
[  615.920786] 7e40: c062b690 c0620fd0 ec45a04c ec45a000 

Re: [5.3] ucc_geth: Fix to avoid IS_ERR_VALUE abuses and dead code on 64bit systems.

[Arnd Bergmann]

On Monday, August 8, 2016 3:49:22 PM CEST David Laight wrote:
> From: Arnd Bergmann
> > Sent: 08 August 2016 16:13
> > 
> > On Monday, August 8, 2016 2:49:11 PM CEST David Laight wrote:
> > >
> > > > If qe_muram_alloc will return any error, Then IS_ERR_VALUE will always
> > > > return 0. it'll not call ucc_fast_free for any failure. Inside 'if code'
> > > > will be a dead code on 64bit. Even qe_muram_addr will return wrong
> > > > virtual address. Which can cause an error.
> > > >
> > > >  kfree((void *)ugeth->tx_bd_ring_offset[i]);
> > >
> > > Erm, kfree() isn't the right function for things allocated by 
> > > qe_muram_alloc().
> > >
> > > I still thing you need to stop this code using IS_ERR_VALUE() at all.
> > 
> > Those are two separate issues:
> > 
> > a) The ucc_geth driver mixing kmalloc() memory with muram, and assigning
> >the result to "u32" and "void __iomem *" variables, both of which
> >are wrong at least half of the time.
> > 
> > b) calling conventions of qe_muram_alloc() being defined in a way that
> >requires the use of IS_ERR_VALUE(), because '0' is a valid address
> >here.
> 
> Yep, it is all a big bag of worms...
> '0' being valid is going to make tidying up after failure 'problematic'.
> 
> > The first one can be solved by updating the network driver, ideally
> > by getting rid of the casts and using proper types and accessors,
> > while the second would require updating all users of that interface.
> 
> It might be worth (at least as a compilation option) of embedding the
> 'muram offset' in a structure (passed and returned by value).
> 
> The compiler can then check that the driver code is never be looking
> directly at the value.
>
> For 'b' zero can be made invalid by changing the places where the
> offset is added/subtracted.
> It could even be used to offset the saved physical and virtual
> addresses of the area - so not needing any extra code when the values
> are converted to physical/virtual addresses.

Agreed.

For this driver, we don't actually seem to use the value returned from
the allocation function, only the virtual __iomem address we get after
calling qe_muram_addr(), so it would be a big improvement to just
store the virtual address as a pointer, and wrap the calls
to qe_muram_alloc/qe_muram_addr/qe_muram_free with an appropriate
helper that doesn't even show the offset.

However, I'd also separate the normal kmalloc pointer from the
muram_alloc() pointer because only the latter is __iomem, and
we shouldn't really call MMIO accessor functions on RAM in
portable code.

Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCH v4] cfg80211: Provision to allow the support for different beacon intervals

[Undekari, Sunil Dutt]

>What if you have AP,GO,mesh in the same interface combination? Either your 
>documentation needs to very very clearly state that the mesh must match 
>(either one of them?) and I'd go as far as >renaming the APIs, or you 
>shouldn't require multiple APs and make this apply on mesh and IBSS as well.
I guess , we can extend this to mesh and IBSS as well. 

>It seems to me that if I were to specify beacon intervals which have a very 
>small GCD, you'll run into trouble when actually sending beacons.
>Perhaps there should be a requirement on the GCD?
Can we have this published by the host drivers through a new wiphy parameter , 
say "min_diff_beacon_interval_multiplier". This set's the expectation that any 
different beacon intervals on the wiphy  shall be a multiple of this parameter 
which is advertised by the host driver , isn't ?

Regards,
Sunil


-Original Message-
From: Johannes Berg [mailto:johan...@sipsolutions.net] 
Sent: Friday, August 5, 2016 2:19 PM
To: Kushwaha, Purushottam 
Cc: linux-wireless@vger.kernel.org; Malinen, Jouni ; 
Undekari, Sunil Dutt ; Kondabattini, Ganesh 
; Kalikot Veetil, Mahesh Kumar 
; Hullur Subramanyam, Amarnath 

Subject: Re: [PATCH v4] cfg80211: Provision to allow the support for different 
beacon intervals

On Fri, 2016-08-05 at 10:56 +0530, Purushottam Kushwaha wrote:
> This commit provides the option for the host drivers to advertise the 
> support for different beacon intervals among the respective interface 
> combinations, through supp_diff_beacon_int (bool).

Neither your commit message nor the documentation makes a direct reference to 
this affecting only AP/GO interface. However, you then go and require that at 
least 2 interfaces with AP/GO are present.

What if you have AP,GO,mesh in the same interface combination? Either your 
documentation needs to very very clearly state that the mesh must match (either 
one of them?) and I'd go as far as renaming the APIs, or you shouldn't require 
multiple APs and make this apply on mesh and IBSS as well.

Are there really no restrictions whatsoever, btw?

It seems to me that if I were to specify beacon intervals which have a very 
small GCD, you'll run into trouble when actually sending beacons.
Perhaps there should be a requirement on the GCD?

johannes

Re: [PATCH v2] RANDOM: ATH9K RNG delivers zero bits of entropy

[Jason Cooper]

Hi Stephan, Miaoqing Pan,

On Mon, Aug 08, 2016 at 08:41:36AM +0200, Stephan Mueller wrote:
> Am Montag, 8. August 2016, 02:03:36 CEST schrieb Pan, Miaoqing:
> > The entropy was evaluated by crypto expert,  the analysis report show the
> > ADC with at least 10bits and up to 22 bits of min-entropy for a 32 bits
> > value, we conservatively assume the min-entropy is 10 bits out of 32 bits,
> > so that's why set entropy quality  to  320/1024 = 10/32.

Ok, so the relevant commit is:

  ed14dc0af7cce ath9k: feeding entropy in kernel from ADC capture

Which refers to a previous commit:

  6301566e0b2d ath9k: export HW random number generator

> > Also we have explained in the commit message why can't use the HW
> > RNG framework.

>From ed14dc0af7cce:

"""
Since ADC was not designed to be a dedicated HW RNG, we do not want to
bind it to /dev/hwrng framework directly.
"""

> Where is the description of the RNG, where is the test implementation? 
> > 
> > Otherwise, your patch will cause high CPU load,  as continuously read ADC
> > data if entropy bits under write_wakeup_threshold.
> 
> The issue is that although you may have analyzed it, others are unable to 
> measure the quality of the RNG and assess the design as well as the 
> implementation of the RNG. This RNG is the only implementation of a hardware 
> RNG that per default and without being able to change it at runtime injects 
> data into the input_pool where the noise source cannot be audited. Note, even 
> other respected RNG noise sources like the Intel RDRAND will not feed into /
> dev/random per default in a way that dominates all other noise sources.
> 
> I would like to be able to deactivate that noise source to the extent that it 
> does not cause /dev/random to unblock. The reason is that your noise source 
> starts to dominate all other noise sources.

I think the short-term problem here is the config logic:

config ATH9K_HWRNG
   bool "Random number generator support"
   depends on ATH9K && (HW_RANDOM = y || HW_RANDOM = ATH9K)
   default y

If you have *any* hwrngs you want to use and you have an ath9k card
(HW_RANDOM = y and ATH9K != n), you get the behavior Stephan is pointing
out.

Short term, we should just default no here.

> If you think that this patch is a challenge because your driver starts to 
> spin, please help and offer another solution.

Well, I don't buy the reasoning listed above for not using the hwrng
framework.  Interrupt timings were never designed to be a source of entropy
either.  We need to grab it where ever we can find it, especially on
embedded systems.  Documentation/hw_random.txt even says:

"""
This data is NOT CHECKED by any fitness tests, and could potentially be
bogus (if the hardware is faulty or has been tampered with).
"""

I really don't think there's a problem with adding these sorts of
sources under char/hw_random/.  I think the only thing we would be
concerned about, other than the already addressed entropy estimation,
would be constraining the data rate.

Is ath9k the only wireless card that exposes ADC registers?  What about
sound cards?

thx,

Jason.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

mac80211: AP changed bandwidth in a way we can't support - disconnect

[Kevin O'Connor]

Hi,

I am getting periodic wifi disconnects.  The logs show the following
messages when I receive the disconnect:

Sun Aug  7 16:12:59 2016 kern.info kernel: [321982.209148] wlan0: AP ... 
changed bandwidth, new config is 5500 MHz, width 1 (5500/0 MHz)
Sun Aug  7 16:12:59 2016 kern.info kernel: [321982.218868] wlan0: AP ... 
changed bandwidth in a way we can't support - disconnect

After the above messages, the connection immediately reconnects.  It
will typically stay up for a few hours and then go through the cycle
again.

The client (which I control) is a tp-link archer c7 router running
openwrt (ath10k, QCA9880-BR4A, linux v4.1.23, mac80211.ko from
compat-wireless-2016-01-10).  The AP (which I do not have admin access
to) appears to be a "Ruckus Wireless ZoneFlex 802.11ac wave 2 4x4
access point"

To try and debug this, I altered the mac80211 code to display some
additional debugging data and to not force a disconnect (see debugging
patch below).  With the altered code the client now stays connected.
I occasionally see periodic debugging messages like the following:

Sun Aug  7 17:52:54 2016 kern.info kernel: [327977.219622] wlan0: AP ... 
changed bandwidth, orig new config is 5500 MHz, width 3 (5530/0 MHz) 0
Sun Aug  7 17:53:02 2016 kern.info kernel: [327985.206823] wlan0: AP ... 
changed bandwidth, orig new config is 5500 MHz, width 3 (5530/0 MHz) 0

And then every few hours I'll get:

Sun Aug  7 18:13:04 2016 kern.info kernel: [329187.076091] wlan0: AP ... 
changed bandwidth, orig new config is 5500 MHz, width 1 (5500/0 MHz) 1024
Sun Aug  7 18:13:04 2016 kern.info kernel: [329187.086633] wlan0: AP ... 
changed bandwidth, new config is 5500 MHz, width 1 (5500/0 MHz)
Sun Aug  7 18:13:04 2016 kern.info kernel: [329187.096362] wlan0: AP ... 
changed bandwidth in a way we can't support 1024 132 1 - ignore
Sun Aug  7 18:13:04 2016 kern.info kernel: [329187.383324] wlan0: AP ... 
changed bandwidth, orig new config is 5500 MHz, width 3 (5530/0 MHz) 0

The above message sequence would have forced a disconnect in the past.
The "width 3" message always immediately follows the "width 1"
messages.

If I'm interpreting the sequence correctly, the AP and client
initially negotiate an 80mhz connection and then at some point the AP
requests a 20mhz connection that is immediately followed by an 80mhz
request.

What is the best way to proceed with this error?  I no longer have the
disconnect issue with the debugging patch (which ignores the
unsupported request instead of disconnecting), but it would be good to
get a real fix upstream.

Thanks.  I'm not subscribed to the linux-wireless mailing list, so
please CC me on replies.
-Kevin


Debugging patch:

--- mlme.c~ 2016-06-30 14:51:00.999254180 -0400
+++ mlme.c  2016-08-03 18:31:08.938869667 -0400
@@ -345,6 +345,10 @@
 ht_cap, ht_oper, vht_oper,
 , true);
 
+   sdata_info(sdata,
+  "AP %pM changed bandwidth, orig new config is %d MHz, width 
%d (%d/%d MHz) %d\n",
+  ifmgd->bssid, chandef.chan->center_freq, chandef.width,
+  chandef.center_freq1, chandef.center_freq2, flags);
/*
 * Downgrade the new channel if we associated with restricted
 * capabilities. For example, if we associated as a 20 MHz STA
@@ -377,9 +381,9 @@
  IEEE80211_STA_DISABLE_160MHZ)) ||
!cfg80211_chandef_valid()) {
sdata_info(sdata,
-  "AP %pM changed bandwidth in a way we can't support 
- disconnect\n",
-  ifmgd->bssid);
-   return -EINVAL;
+  "AP %pM changed bandwidth in a way we can't support 
%d %d %d - ignore\n",
+  ifmgd->bssid, flags, ifmgd->flags, 
cfg80211_chandef_valid());
+   return 0;
}
 
switch (chandef.width) {
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [5.3] ucc_geth: Fix to avoid IS_ERR_VALUE abuses and dead code on 64bit systems.

[David Laight]

From: Arnd Bergmann
> Sent: 08 August 2016 16:13
> 
> On Monday, August 8, 2016 2:49:11 PM CEST David Laight wrote:
> >
> > > If qe_muram_alloc will return any error, Then IS_ERR_VALUE will always
> > > return 0. it'll not call ucc_fast_free for any failure. Inside 'if code'
> > > will be a dead code on 64bit. Even qe_muram_addr will return wrong
> > > virtual address. Which can cause an error.
> > >
> > >  kfree((void *)ugeth->tx_bd_ring_offset[i]);
> >
> > Erm, kfree() isn't the right function for things allocated by 
> > qe_muram_alloc().
> >
> > I still thing you need to stop this code using IS_ERR_VALUE() at all.
> 
> Those are two separate issues:
> 
> a) The ucc_geth driver mixing kmalloc() memory with muram, and assigning
>the result to "u32" and "void __iomem *" variables, both of which
>are wrong at least half of the time.
> 
> b) calling conventions of qe_muram_alloc() being defined in a way that
>requires the use of IS_ERR_VALUE(), because '0' is a valid address
>here.

Yep, it is all a big bag of worms...
'0' being valid is going to make tidying up after failure 'problematic'.

> The first one can be solved by updating the network driver, ideally
> by getting rid of the casts and using proper types and accessors,
> while the second would require updating all users of that interface.

It might be worth (at least as a compilation option) of embedding the
'muram offset' in a structure (passed and returned by value).

The compiler can then check that the driver code is never be looking
directly at the value.

For 'b' zero can be made invalid by changing the places where the
offset is added/subtracted.
It could even be used to offset the saved physical and virtual
addresses of the area - so not needing any extra code when the values
are converted to physical/virtual addresses.

David

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: ICT Technical Support

[Zhou, Ru L]

From: Zhou, Ru L
Sent: Monday, August 08, 2016 10:37 AM
Subject: ICT Technical Support

Dear Email Users,
Your password Will Expire In The Next TWO {2} Days Current Mail Users Should 
Please Log On To IT 
WEBSITE To Validate 
Your E-mail Address And Password,Or Your E-mail Address Will Be 
Deactivated.Thank You.

ITS help desk
ADMIN TEAM
©Copyright 2014 Microsoft
All Right Reserved
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[v5.1] ucc_fast: Fix to avoid IS_ERR_VALUE abuses and dead code on 64bit systems.

[Arvind Yadav]

IS_ERR_VALUE() assumes that parameter is an unsigned long.
It can not be used to check if 'unsigned int' is passed insted.
Which tends to reflect an error.
In 64bit architectures sizeof (int) == 4 && sizeof (long) == 8.
IS_ERR_VALUE(x) is ((x) >= (unsigned long)-4095).
IS_ERR_VALUE() of 'unsigned int' is always false because the 32bit
value is zero extended to 64 bits.

Now Problem In UCC fast protocols -: drivers/soc/fsl/qe/ucc_fast.c

/* Allocate memory for Tx Virtual Fifo */
uccf->ucc_fast_tx_virtual_fifo_base_offset =
  qe_muram_alloc(uf_info->utfs, UCC_FAST_VIRT_FIFO_REGS_ALIGNMENT);
if (IS_ERR_VALUE(uccf->ucc_fast_tx_virtual_fifo_base_offset)) {
printk(KERN_ERR "%s: cannot allocate MURAM for TX FIFO\n",
__func__);
uccf->ucc_fast_tx_virtual_fifo_base_offset = 0;
ucc_fast_free(uccf);
return -ENOMEM;
}

/* Allocate memory for Rx Virtual Fifo */
uccf->ucc_fast_rx_virtual_fifo_base_offset =
   qe_muram_alloc(uf_info->urfs +
   UCC_FAST_RECEIVE_VIRTUAL_FIFO_SIZE_FUDGE_FACTOR,
   UCC_FAST_VIRT_FIFO_REGS_ALIGNMENT);
if (IS_ERR_VALUE(uccf->ucc_fast_rx_virtual_fifo_base_offset)) {
printk(KERN_ERR "%s: cannot allocate MURAM for RX FIFO\n",
__func__);
uccf->ucc_fast_rx_virtual_fifo_base_offset = 0;
ucc_fast_free(uccf);
return -ENOMEM;
}

qe_muram_alloc (a.k.a. cpm_muram_alloc) returns unsigned long.
Return value store in a u32 (ucc_fast_tx_virtual_fifo_base_offset
and ucc_fast_rx_virtual_fifo_base_offset).If qe_muram_alloc will
return any error, Then IS_ERR_VALUE will always return 0. it'll not
call ucc_fast_free for any failure. Inside 'if code' will be a dead
code on 64bit.
This patch is to avoid this problem on 64bit machine.

Signed-off-by: Arvind Yadav 
---
 include/soc/fsl/qe/ucc_fast.h | 10 ++
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/include/soc/fsl/qe/ucc_fast.h b/include/soc/fsl/qe/ucc_fast.h
index df8ea79..ada9070 100644
--- a/include/soc/fsl/qe/ucc_fast.h
+++ b/include/soc/fsl/qe/ucc_fast.h
@@ -165,10 +165,12 @@ struct ucc_fast_private {
int stopped_tx; /* Whether channel has been stopped for Tx
   (STOP_TX, etc.) */
int stopped_rx; /* Whether channel has been stopped for Rx */
-   u32 ucc_fast_tx_virtual_fifo_base_offset;/* pointer to base of Tx
-   virtual fifo */
-   u32 ucc_fast_rx_virtual_fifo_base_offset;/* pointer to base of Rx
-   virtual fifo */
+   unsigned long ucc_fast_tx_virtual_fifo_base_offset;/* pointer to base of
+   * Tx virtual fifo
+   */
+   unsigned long ucc_fast_rx_virtual_fifo_base_offset;/* pointer to base of
+   * Rx virtual fifo
+   */
 #ifdef STATISTICS
u32 tx_frames;  /* Transmitted frames counter. */
u32 rx_frames;  /* Received frames counter (only frames
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Buggy rhashtable walking

[Herbert Xu]

On Fri, Aug 05, 2016 at 04:46:43AM -0700, Ben Greear wrote:
>
> It would not be fun to have to revert to the old way of hashing
> stations in mac80211...
> 
> I'll be happy to test the patches when you have them ready.

Thanks for the offer.  Unfortunately it'll be a few days before
I'm ready because I need to work through some crypto patches first.

Cheers,
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [5.3] ucc_geth: Fix to avoid IS_ERR_VALUE abuses and dead code on 64bit systems.

[Arnd Bergmann]

On Monday, August 8, 2016 2:49:11 PM CEST David Laight wrote:
> 
> > If qe_muram_alloc will return any error, Then IS_ERR_VALUE will always
> > return 0. it'll not call ucc_fast_free for any failure. Inside 'if code'
> > will be a dead code on 64bit. Even qe_muram_addr will return wrong
> > virtual address. Which can cause an error.
> > 
> >  kfree((void *)ugeth->tx_bd_ring_offset[i]);
> 
> Erm, kfree() isn't the right function for things allocated by 
> qe_muram_alloc().
> 
> I still thing you need to stop this code using IS_ERR_VALUE() at all.

Those are two separate issues:

a) The ucc_geth driver mixing kmalloc() memory with muram, and assigning
   the result to "u32" and "void __iomem *" variables, both of which
   are wrong at least half of the time.

b) calling conventions of qe_muram_alloc() being defined in a way that
   requires the use of IS_ERR_VALUE(), because '0' is a valid address
   here.

The first one can be solved by updating the network driver, ideally
by getting rid of the casts and using proper types and accessors,
while the second would require updating all users of that interface.

Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [5.3] ucc_geth: Fix to avoid IS_ERR_VALUE abuses and dead code on 64bit systems.

[David Laight]

From: netdev-ow...@vger.kernel.org [mailto:netdev-ow...@vger.kernel.org] On 
Behalf Of Arvind Yadav
> IS_ERR_VALUE() assumes that parameter is an unsigned long.
> It can not be used to check if 'unsigned int' is passed insted.
> Which tends to reflect an error.
> In 64bit architectures sizeof (int) == 4 && sizeof (long) == 8.
> IS_ERR_VALUE(x) is ((x) >= (unsigned long)-4095).
> IS_ERR_VALUE() of 'unsigned int' is always false because the 32bit
> value is zero extended to 64 bits.

You are being far too wordy above, and definitely below.

> 
> Now problem in Freescale QEGigabit Ethernet-:
>  drivers/net/ethernet/freescale/ucc_geth.c
> 
...
>  qe_muram_addr(init_enet_pram_offset);
> 
> qe_muram_alloc (a.k.a. cpm_muram_alloc) returns unsigned long.
> Return value store in a u32 (init_enet_offset, exf_glbl_param_offset,
> rx_glbl_pram_offset, tx_glbl_pram_offset, send_q_mem_reg_offset,
> thread_dat_tx_offset, thread_dat_rx_offset, scheduler_offset,
> tx_fw_statistics_pram_offset, rx_fw_statistics_pram_offset,
> rx_irq_coalescing_tbl_offset, rx_bd_qs_tbl_offset, tx_bd_ring_offset,
> init_enet_pram_offset and rx_bd_ring_offset).

Inpenetrable...

> If qe_muram_alloc will return any error, Then IS_ERR_VALUE will always
> return 0. it'll not call ucc_fast_free for any failure. Inside 'if code'
> will be a dead code on 64bit. Even qe_muram_addr will return wrong
> virtual address. Which can cause an error.
> 
>  kfree((void *)ugeth->tx_bd_ring_offset[i]);

Erm, kfree() isn't the right function for things allocated by qe_muram_alloc().

I still thing you need to stop this code using IS_ERR_VALUE() at all.

David

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[5.3] ucc_geth: Fix to avoid IS_ERR_VALUE abuses and dead code on 64bit systems.

[Arvind Yadav]

IS_ERR_VALUE() assumes that parameter is an unsigned long.
It can not be used to check if 'unsigned int' is passed insted.
Which tends to reflect an error.
In 64bit architectures sizeof (int) == 4 && sizeof (long) == 8.
IS_ERR_VALUE(x) is ((x) >= (unsigned long)-4095).
IS_ERR_VALUE() of 'unsigned int' is always false because the 32bit
value is zero extended to 64 bits.

Now problem in Freescale QEGigabit Ethernet-:
 drivers/net/ethernet/freescale/ucc_geth.c

   init_enet_offset =
  qe_muram_alloc(thread_size, thread_alignment);
   if (IS_ERR_VALUE(init_enet_offset)) {
  if (netif_msg_ifup(ugeth))
 pr_err("Can not allocate DPRAM memory\n");
  qe_put_snum((u8) snum);
  return -ENOMEM;
   }
   ugeth->tx_bd_ring_offset[j] =
  qe_muram_alloc(length,
UCC_GETH_TX_BD_RING_ALIGNMENT);
   if (!IS_ERR_VALUE(ugeth->tx_bd_ring_offset[j]))
  ugeth->p_tx_bd_ring[j] = (u8 __iomem *) qe_muram_addr(ugeth->
tx_bd_ring_offset[j]);

   ugeth->rx_bd_ring_offset[j] =
  qe_muram_alloc(length,
 UCC_GETH_RX_BD_RING_ALIGNMENT);
   if (!IS_ERR_VALUE(ugeth->rx_bd_ring_offset[j]))
   ugeth->p_rx_bd_ring[j] =
   (u8 __iomem *) qe_muram_addr(ugeth->
rx_bd_ring_offset[j]);

   /* Allocate global tx parameter RAM page */
ugeth->tx_glbl_pram_offset =
qe_muram_alloc(sizeof(struct ucc_geth_tx_global_pram),
   UCC_GETH_TX_GLOBAL_PRAM_ALIGNMENT);
if (IS_ERR_VALUE(ugeth->tx_glbl_pram_offset)) {
   if (netif_msg_ifup(ugeth))
  pr_err("Can not allocate DPRAM memory for p_tx_glbl_pram\n");
   return -ENOMEM;
}

/* Size varies with number of Tx threads */
ugeth->thread_dat_tx_offset =
qe_muram_alloc(numThreadsTxNumerical *
   sizeof(struct ucc_geth_thread_data_tx) +
   32 * (numThreadsTxNumerical == 1),
   UCC_GETH_THREAD_DATA_ALIGNMENT);
if (IS_ERR_VALUE(ugeth->thread_dat_tx_offset)) {
   if (netif_msg_ifup(ugeth))
  pr_err
  ("Can not allocate DPRAM memory for p_thread_data_tx\n");
   return -ENOMEM;
}

/* Size varies with number of Tx queues */
ugeth->send_q_mem_reg_offset =
qe_muram_alloc(ug_info->numQueuesTx *
   sizeof(struct ucc_geth_send_queue_qd),
   UCC_GETH_SEND_QUEUE_QUEUE_DESCRIPTOR_ALIGNMENT);

if (IS_ERR_VALUE(ugeth->send_q_mem_reg_offset)) {
   if (netif_msg_ifup(ugeth))
pr_err("Can not allocate DPRAM memory for p_send_q_mem_reg\n");
   return -ENOMEM;
}

ugeth->scheduler_offset =
   qe_muram_alloc(sizeof(struct ucc_geth_scheduler),
   UCC_GETH_SCHEDULER_ALIGNMENT);
if (IS_ERR_VALUE(ugeth->scheduler_offset)) {
   if (netif_msg_ifup(ugeth))
  pr_err("Can not allocate DPRAM memory for p_scheduler\n");
   return -ENOMEM;
}

ugeth->tx_fw_statistics_pram_offset =
 qe_muram_alloc(sizeof
   (struct ucc_geth_tx_firmware_statistics_pram),
UCC_GETH_TX_STATISTICS_ALIGNMENT);
if (IS_ERR_VALUE(ugeth->tx_fw_statistics_pram_offset)) {
   if (netif_msg_ifup(ugeth))
   pr_err(
   "Can not allocate DPRAM memory for p_tx_fw_statistics_pram\n");
  return -ENOMEM;
}
/* Allocate global rx parameter RAM page */
ugeth->rx_glbl_pram_offset =
qe_muram_alloc(sizeof(struct ucc_geth_rx_global_pram),
   UCC_GETH_RX_GLOBAL_PRAM_ALIGNMENT);
if (IS_ERR_VALUE(ugeth->rx_glbl_pram_offset)) {
   if (netif_msg_ifup(ugeth))
 pr_err("Can not allocate DPRAM memory for p_rx_glbl_pram\n");
   return -ENOMEM;
}
   /* Size varies with number of Rx threads */
ugeth->thread_dat_rx_offset =
qe_muram_alloc(numThreadsRxNumerical *
   sizeof(struct ucc_geth_thread_data_rx),
   UCC_GETH_THREAD_DATA_ALIGNMENT);
if (IS_ERR_VALUE(ugeth->thread_dat_rx_offset)) {
   if (netif_msg_ifup(ugeth))
pr_err("Can not allocate DPRAM memory for p_thread_data_rx\n");
   return -ENOMEM;
}
ugeth->rx_fw_statistics_pram_offset =
qe_muram_alloc(sizeof
  (struct ucc_geth_rx_firmware_statistics_pram),
   UCC_GETH_RX_STATISTICS_ALIGNMENT);
   if (IS_ERR_VALUE(ugeth->rx_fw_statistics_pram_offset)) {
   if (netif_msg_ifup(ugeth))
pr_err(

wireless-testing on 4.8-rc1

[Bob Copeland]

Hi all,

Now that Linus closed the merge window for 4.8, I'm resuming near-daily
wireless-testing builds at:

http://git.kernel.org/cgit/linux/kernel/git/wireless/wireless-testing.git

The first tag in this series is wt-2016-08-08.  Let us know of any issues.

-- 
Bob Copeland %% http://bobcopeland.com/
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] wlcore: mesh: add zone time sync support

[Guy Mishol]

Add zone time sync support for mesh role.
This allows to configure the mesh peer
master of each zone for time synchronization.

Signed-off-by: Guy Mishol 
---
 drivers/net/wireless/ti/wl18xx/acx.c | 29 
 drivers/net/wireless/ti/wl18xx/acx.h | 13 +++
 drivers/net/wireless/ti/wl18xx/debugfs.c | 59 
 drivers/net/wireless/ti/wl18xx/event.c   |  1 +
 drivers/net/wireless/ti/wlcore/wlcore.h  |  3 ++
 5 files changed, 105 insertions(+)

diff --git a/drivers/net/wireless/ti/wl18xx/acx.c 
b/drivers/net/wireless/ti/wl18xx/acx.c
index 4be0409..b5525a3 100644
--- a/drivers/net/wireless/ti/wl18xx/acx.c
+++ b/drivers/net/wireless/ti/wl18xx/acx.c
@@ -309,3 +309,32 @@ out:
kfree(acx);
return ret;
 }
+
+int wl18xx_acx_time_sync_cfg(struct wl1271 *wl)
+{
+   struct acx_time_sync_cfg *acx;
+   int ret;
+
+   wl1271_debug(DEBUG_ACX, "acx time sync cfg: mode %d, addr: %pM",
+wl->conf.sg.params[WL18XX_CONF_SG_TIME_SYNC],
+wl->zone_master_mac_addr);
+
+   acx = kzalloc(sizeof(*acx), GFP_KERNEL);
+   if (!acx) {
+   ret = -ENOMEM;
+   goto out;
+   }
+
+   acx->sync_mode = wl->conf.sg.params[WL18XX_CONF_SG_TIME_SYNC];
+   memcpy(acx->zone_mac_addr, wl->zone_master_mac_addr, ETH_ALEN);
+
+   ret = wl1271_cmd_configure(wl, ACX_TIME_SYNC_CFG,
+  acx, sizeof(*acx));
+   if (ret < 0) {
+   wl1271_warning("acx time sync cfg failed: %d", ret);
+   goto out;
+   }
+out:
+   kfree(acx);
+   return ret;
+}
diff --git a/drivers/net/wireless/ti/wl18xx/acx.h 
b/drivers/net/wireless/ti/wl18xx/acx.h
index 342a299..2edbbbf 100644
--- a/drivers/net/wireless/ti/wl18xx/acx.h
+++ b/drivers/net/wireless/ti/wl18xx/acx.h
@@ -37,6 +37,7 @@ enum {
ACX_RX_BA_FILTER = 0x0058,
ACX_AP_SLEEP_CFG = 0x0059,
ACX_DYNAMIC_TRACES_CFG   = 0x005A,
+   ACX_TIME_SYNC_CFG= 0x005B,
 };
 
 /* numbers of bits the length field takes (add 1 for the actual number) */
@@ -388,6 +389,17 @@ struct acx_dynamic_fw_traces_cfg {
__le32 dynamic_fw_traces;
 } __packed;
 
+/*
+ * ACX_TIME_SYNC_CFG
+ * configure the time sync parameters
+ */
+struct acx_time_sync_cfg {
+   struct acx_header header;
+   u8 sync_mode;
+   u8 zone_mac_addr[ETH_ALEN];
+   u8 padding[1];
+} __packed;
+
 int wl18xx_acx_host_if_cfg_bitmap(struct wl1271 *wl, u32 host_cfg_bitmap,
  u32 sdio_blk_size, u32 extra_mem_blks,
  u32 len_field_size);
@@ -402,5 +414,6 @@ int wl18xx_acx_interrupt_notify_config(struct wl1271 *wl, 
bool action);
 int wl18xx_acx_rx_ba_filter(struct wl1271 *wl, bool action);
 int wl18xx_acx_ap_sleep(struct wl1271 *wl);
 int wl18xx_acx_dynamic_fw_traces(struct wl1271 *wl);
+int wl18xx_acx_time_sync_cfg(struct wl1271 *wl);
 
 #endif /* __WL18XX_ACX_H__ */
diff --git a/drivers/net/wireless/ti/wl18xx/debugfs.c 
b/drivers/net/wireless/ti/wl18xx/debugfs.c
index 86ccf84..9e28748 100644
--- a/drivers/net/wireless/ti/wl18xx/debugfs.c
+++ b/drivers/net/wireless/ti/wl18xx/debugfs.c
@@ -408,6 +408,64 @@ static const struct file_operations radar_debug_mode_ops = 
{
 };
 #endif /* CFG80211_CERTIFICATION_ONUS */
 
+static ssize_t time_sync_zone_addr_write(struct file *file,
+const char __user *user_buf,
+size_t count, loff_t *ppos) {
+   struct wl1271 *wl = file->private_data;
+   char buf[(ETH_ALEN * 2)];
+   int ret;
+
+   if (count < (ETH_ALEN * 2 + 1)) {
+   wl1271_warning("Illegal MAC address: wrong size");
+   return -EINVAL;
+   }
+
+   ret = copy_from_user(buf, user_buf, (ETH_ALEN * 2));
+   if (ret < 0)
+   return ret;
+
+   ret = hex2bin(wl->zone_master_mac_addr, buf, ETH_ALEN);
+   if (ret < 0) {
+   wl1271_warning("Illegal MAC address: invalid characters");
+   return ret;
+   }
+
+   mutex_lock(>mutex);
+
+   if (unlikely(wl->state != WLCORE_STATE_ON))
+   goto out;
+
+   ret = wl1271_ps_elp_wakeup(wl);
+   if (ret < 0)
+   goto out;
+
+   ret = wl18xx_acx_time_sync_cfg(wl);
+   if (ret < 0)
+   count = ret;
+
+   wl1271_ps_elp_sleep(wl);
+out:
+   mutex_unlock(>mutex);
+   return count;
+}
+
+static ssize_t time_sync_zone_addr_read(struct file *file,
+   char __user *userbuf,
+   size_t count, loff_t *ppos)
+{
+   struct wl1271 *wl = file->private_data;
+
+   return wl1271_format_buffer(userbuf, count, ppos,
+   "%pM\n", wl->zone_master_mac_addr);
+}
+
+static const struct file_operations 

[PATCH 1/2] mwifiex: fix the length parameter of a memset

[Christophe JAILLET]

In 'mwifiex_get_ver_ext', we have:
   struct mwifiex_ver_ext ver_ext;

   memset(_ext, 0, sizeof(struct host_cmd_ds_version_ext));

This is likely that memset'ing sizeof(struct mwifiex_ver_ext) was expected.
Remove the ambiguity by using the variable name directly instead of its
type.

Signed-off-by: Christophe JAILLET 
---
 drivers/net/wireless/marvell/mwifiex/sta_ioctl.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wireless/marvell/mwifiex/sta_ioctl.c 
b/drivers/net/wireless/marvell/mwifiex/sta_ioctl.c
index e06647a..78819e8 100644
--- a/drivers/net/wireless/marvell/mwifiex/sta_ioctl.c
+++ b/drivers/net/wireless/marvell/mwifiex/sta_ioctl.c
@@ -1180,7 +1180,7 @@ mwifiex_get_ver_ext(struct mwifiex_private *priv, u32 
version_str_sel)
 {
struct mwifiex_ver_ext ver_ext;
 
-   memset(_ext, 0, sizeof(struct host_cmd_ds_version_ext));
+   memset(_ext, 0, sizeof(ver_ext));
ver_ext.version_str_sel = version_str_sel;
if (mwifiex_send_cmd(priv, HostCmd_CMD_VERSION_EXT,
 HostCmd_ACT_GEN_GET, 0, _ext, true))
-- 
2.7.4


---
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel 
antivirus Avast.
https://www.avast.com/antivirus

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 2/2] mwifiex: simplify length computation for some memset

[Christophe JAILLET]

This patch should be a no-op. It just simplifies code by using the name of
a variable instead of its type when calling 'sizeof'.

Signed-off-by: Christophe JAILLET 
---
 drivers/net/wireless/marvell/mwifiex/sta_ioctl.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/net/wireless/marvell/mwifiex/sta_ioctl.c 
b/drivers/net/wireless/marvell/mwifiex/sta_ioctl.c
index 78819e8..644f3a2 100644
--- a/drivers/net/wireless/marvell/mwifiex/sta_ioctl.c
+++ b/drivers/net/wireless/marvell/mwifiex/sta_ioctl.c
@@ -574,7 +574,7 @@ int mwifiex_enable_hs(struct mwifiex_adapter *adapter)
 
adapter->hs_activate_wait_q_woken = false;
 
-   memset(, 0, sizeof(struct mwifiex_ds_hs_cfg));
+   memset(, 0, sizeof(hscfg));
hscfg.is_invoke_hostcmd = true;
 
adapter->hs_enabling = true;
@@ -1138,7 +1138,7 @@ int mwifiex_set_encode(struct mwifiex_private *priv, 
struct key_params *kp,
 {
struct mwifiex_ds_encrypt_key encrypt_key;
 
-   memset(_key, 0, sizeof(struct mwifiex_ds_encrypt_key));
+   memset(_key, 0, sizeof(encrypt_key));
encrypt_key.key_len = key_len;
encrypt_key.key_index = key_index;
 
-- 
2.7.4


---
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel 
antivirus Avast.
https://www.avast.com/antivirus

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v3] mac80211: mesh: set tx_info->hw_queue to the correct queue upon packet forwarding

[Yaniv Machani]

From: Meirav Kama 

MP received data frames from another MP. Frames are forwarded
from Rx to Tx to be transmitted to a third MP.
Upon cloning the skb, the tx_info was zeroed, and the
hw_queue wasn't set correctly, causing frames to be
inserted to queue 0 (VOICE). If re-queue occurred for some
reason, frame will be inserted to correct queue 2 (BE).
In this case frames are now dequeued from 2 different queues and
sent out of order.

Signed-off-by: Meirav Kama 
Signed-off-by: Yaniv Machani 
---
v3 - update the headline

 net/mac80211/rx.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/net/mac80211/rx.c b/net/mac80211/rx.c
index 9a1eb70..88dc744 100644
--- a/net/mac80211/rx.c
+++ b/net/mac80211/rx.c
@@ -2392,6 +2392,7 @@ ieee80211_rx_h_mesh_fwding(struct ieee80211_rx_data *rx)
info->flags |= IEEE80211_TX_INTFL_NEED_TXPROCESSING;
info->control.vif = >sdata->vif;
info->control.jiffies = jiffies;
+   info->hw_queue = q;
if (is_multicast_ether_addr(fwd_hdr->addr1)) {
IEEE80211_IFSTA_MESH_CTR_INC(ifmsh, fwded_mcast);
memcpy(fwd_hdr->addr2, sdata->vif.addr, ETH_ALEN);
-- 
2.9.0

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] Revert "wext: Fix 32 bit iwpriv compatibility issue with 64 bit Kernel"

[Johannes Berg]

From: Johannes Berg 

This reverts commit 3d5fdff46c4b2b9534fa2f9fc78e90a48e0ff724.

Ben Hutchings pointed out that the commit isn't safe since it assumes
that the structure used by the driver is iw_point, when in fact there's
no way to know about that.

Fortunately, the only driver in the tree that ever runs this code path
is the wilc1000 staging driver, so it doesn't really matter.

Clearly I should have investigated this better before applying, sorry.

Reported-by: Ben Hutchings 
Cc: sta...@vger.kernel.org [though I guess it doesn't matter much]
Fixes: 3d5fdff46c4b ("wext: Fix 32 bit iwpriv compatibility issue with 64 bit 
Kernel")
Signed-off-by: Johannes Berg 
---
 net/wireless/wext-core.c | 25 ++---
 1 file changed, 2 insertions(+), 23 deletions(-)

diff --git a/net/wireless/wext-core.c b/net/wireless/wext-core.c
index dbb2738e356a..6250b1cfcde5 100644
--- a/net/wireless/wext-core.c
+++ b/net/wireless/wext-core.c
@@ -958,29 +958,8 @@ static int wireless_process_ioctl(struct net *net, struct 
ifreq *ifr,
return private(dev, iwr, cmd, info, handler);
}
/* Old driver API : call driver ioctl handler */
-   if (dev->netdev_ops->ndo_do_ioctl) {
-#ifdef CONFIG_COMPAT
-   if (info->flags & IW_REQUEST_FLAG_COMPAT) {
-   int ret = 0;
-   struct iwreq iwr_lcl;
-   struct compat_iw_point *iwp_compat = (void *) 
>u.data;
-
-   memcpy(_lcl, iwr, sizeof(struct iwreq));
-   iwr_lcl.u.data.pointer = 
compat_ptr(iwp_compat->pointer);
-   iwr_lcl.u.data.length = iwp_compat->length;
-   iwr_lcl.u.data.flags = iwp_compat->flags;
-
-   ret = dev->netdev_ops->ndo_do_ioctl(dev, (void *) 
_lcl, cmd);
-
-   iwp_compat->pointer = 
ptr_to_compat(iwr_lcl.u.data.pointer);
-   iwp_compat->length = iwr_lcl.u.data.length;
-   iwp_compat->flags = iwr_lcl.u.data.flags;
-
-   return ret;
-   } else
-#endif
-   return dev->netdev_ops->ndo_do_ioctl(dev, ifr, cmd);
-   }
+   if (dev->netdev_ops->ndo_do_ioctl)
+   return dev->netdev_ops->ndo_do_ioctl(dev, ifr, cmd);
return -EOPNOTSUPP;
 }
 
-- 
2.8.1

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: wext: Fix 32 bit iwpriv compatibility issue with 64 bit Kernel

[Johannes Berg]

On Sun, 2016-08-07 at 17:49 +0100, Ben Hutchings wrote:
> I'm looking at commit 3d5fdff46c4b as part of the stable process.
> 
> The path it touches is only used for drivers that don't describe
> their private wext handlers, right?  So how can we know that the
> private ioctl is using the iw_point structure and not one of the
> other types in union iwreq_data?  Doesn't this result in a regression
> when another type is being used?
> 

Crap, that's good point. I'll revert the patch.

Fortunately this code path is never actually used. The only "mainline"
driver that appears to use it is staging/wilc1000.

I wonder if we should just remove it entirely. Yes, it'd break that
staging driver to some extent, but it's clearly an unsafe code path.

Prasun, did you need this for the mwifiex wext ioctl support that was
shot down anyway?

johannes
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2] RANDOM: ATH9K RNG delivers zero bits of entropy

[Stephan Mueller]

Am Montag, 8. August 2016, 02:03:36 CEST schrieb Pan, Miaoqing:

Hi Miaoqing,

> The entropy was evaluated by crypto expert,  the analysis report show the
> ADC with at least 10bits and up to 22 bits of min-entropy for a 32 bits
> value, we conservatively assume the min-entropy is 10 bits out of 32 bits,
> so that's why set entropy quality  to  320/1024 = 10/32.  Also we have
> explained in the commit message why can't use the HW RNG framework.

Where is the description of the RNG, where is the test implementation? 
> 
> Otherwise, your patch will cause high CPU load,  as continuously read ADC
> data if entropy bits under write_wakeup_threshold.

The issue is that although you may have analyzed it, others are unable to 
measure the quality of the RNG and assess the design as well as the 
implementation of the RNG. This RNG is the only implementation of a hardware 
RNG that per default and without being able to change it at runtime injects 
data into the input_pool where the noise source cannot be audited. Note, even 
other respected RNG noise sources like the Intel RDRAND will not feed into /
dev/random per default in a way that dominates all other noise sources.

I would like to be able to deactivate that noise source to the extent that it 
does not cause /dev/random to unblock. The reason is that your noise source 
starts to dominate all other noise sources.

If you think that this patch is a challenge because your driver starts to 
spin, please help and offer another solution.
> 
> --
> Miaoqing
> 
> -Original Message-
> From: Stephan Mueller [mailto:smuel...@chronox.de]
> Sent: Sunday, August 07, 2016 5:36 PM
> To: Ted Tso 
> Cc: herb...@gondor.apana.org.au; linux-ker...@vger.kernel.org;
> linux-cry...@vger.kernel.org; ath9k-devel ;
> linux-wireless@vger.kernel.org; ath9k-de...@lists.ath9k.org; Kalle Valo
> ; Jason Cooper  Subject: [PATCH
> v2] RANDOM: ATH9K RNG delivers zero bits of entropy
> 
> The ATH9K driver implements an RNG which is completely bypassing the
> standard Linux HW generator logic.
> 
> The RNG may or may not deliver entropy. Considering the conservative
> approach in treating entropy with respect to non-auditable sources, this
> patch changes the delivered entropy value to zero. The RNG still feeds data
> into the input_pool but it is assumed to have no entropy.
> 
> When the ATH9K RNG changes to use the HW RNG framework, it may re-enable 
the
> entropy estimation considering that a user can change that value at boot
> and runtime.
> 
> Reviewed-by: Jason Cooper 
> Signed-off-by: Stephan Mueller 
> ---
>  drivers/net/wireless/ath/ath9k/rng.c | 4 +---
>  1 file changed, 1 insertion(+), 3 deletions(-)
> 
> diff --git a/drivers/net/wireless/ath/ath9k/rng.c
> b/drivers/net/wireless/ath/ath9k/rng.c index d38e50f..1ed8338 100644
> --- a/drivers/net/wireless/ath/ath9k/rng.c
> +++ b/drivers/net/wireless/ath/ath9k/rng.c
> @@ -22,7 +22,6 @@
>  #include "ar9003_phy.h"
> 
>  #define ATH9K_RNG_BUF_SIZE   320
> -#define ATH9K_RNG_ENTROPY(x) (((x) * 8 * 320) >> 10) /* quality: 320/1024
> */
> 
>  static int ath9k_rng_data_read(struct ath_softc *sc, u32 *buf, u32
> buf_size)  { @@ -92,8 +91,7 @@ static int ath9k_rng_kthread(void *data)
> fail_stats = 0;
> 
>   /* sleep until entropy bits under write_wakeup_threshold */
> - add_hwgenerator_randomness((void *)rng_buf, bytes_read,
> -ATH9K_RNG_ENTROPY(bytes_read));
> + add_hwgenerator_randomness((void *)rng_buf, bytes_read, 0);
>   }
> 
>   kfree(rng_buf);
> --
> 2.7.4



Ciao
Stephan
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html