iwlwifi: alloc memory dynamically also for DVM - net-next.git

diff options

author	Sara Sharon <sara.sharon@intel.com>	2017-01-30 12:34:32 +0200
committer	Kalle Valo <kvalo@codeaurora.org>	2017-01-31 09:10:24 +0200
commit	d546530e569463a7f0a4ead482d277b5ef42a3aa (patch)
tree	c4a60c65438d6b5a4af45e21ad9fc591e40bcc45 /net/atm/lec.c
parent	33e962c8871f015f5c8978384553dddcf5b81b22 (diff)

iwlwifi: alloc memory dynamically also for DVM

For old firmwares the memory wasn't allocated, resulting in panic. Make it dynamically allocated as well. Allow any order of functions call. Fixes: eef187a7b8a1 ("iwlwifi: enlarge number of ucode sections") Signed-off-by: Sara Sharon <sara.sharon@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Tested-by: Kalle Valo <kvalo@codeaurora.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>

Diffstat (limited to 'net/atm/lec.c')

0 files changed, 0 insertions, 0 deletions

D_ACCESS") was an off-the-cuff suggestion. Replaced with a much more careful design that's simultaneously faster and better. (My own invention, as there was noting suitable in the literature I could find. Comments welcome!) - Modify the hash_name() loop to skip the initial HASH_MIX(). This would let us salt the hash if we ever wanted to. - Sort out partial_name_hash(). The hash function is declared as using a long state, even though it's truncated to 32 bits at the end and the extra internal state contributes nothing to the result. And some callers do odd things: - fs/hfs/string.c only allocates 32 bits of state - fs/hfsplus/unicode.c uses it to hash 16-bit unicode symbols not bytes - Modify bytemask_from_count to handle inputs of 1..sizeof(long) rather than 0..sizeof(long)-1. This would simplify users other than full_name_hash" Special thanks to Bruce Fields for testing and finding bugs in v1. (I learned some humbling lessons about "obviously correct" code.) On the arch-specific front, the m68k assembly has been tested in a standalone test harness, I've been in contact with the Microblaze maintainers who mostly don't care, as the hardware multiplier is never omitted in real-world applications, and I haven't heard anything from the H8/300 world" * 'hash' of git://ftp.sciencehorizons.net/linux: h8300: Add <asm/hash.h> microblaze: Add <asm/hash.h> m68k: Add <asm/hash.h> <linux/hash.h>: Add support for architecture-specific functions fs/namei.c: Improve dcache hash function Eliminate bad hash multipliers from hash_32() and hash_64() Change hash_64() return value to 32 bits <linux/sunrpc/svcauth.h>: Define hash_str() in terms of hashlen_string() fs/namei.c: Add hashlen_string() function Pull out string hash to <linux/stringhash.h>

Diffstat (limited to 'drivers/usb/gadget')


context:
space:
mode: