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

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, >>

net-next is OPEN

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

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

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

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

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

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

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

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

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

>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

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

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

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

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:

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

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

RE: ICT Technical Support

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

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

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

Re: Buggy rhashtable walking

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

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

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 > >

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

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

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

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

wireless-testing on 4.8-rc1

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 %%

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

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 +++

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

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.

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

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

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

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

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

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

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

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

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

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