summaryrefslogtreecommitdiff
path: root/dissector_80211.h
blob: 31e19653cfe21f1a800f6fef2cd32a75372a1f74 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
/*
 * netsniff-ng - the packet sniffing beast
 * Copyright 2009, 2010 Daniel Borkmann.
 * Subject to the GPL, version 2.
 */

#ifndef DISSECTOR_80211_H
#define DISSECTOR_80211_H

#include "hash.h"
#include "proto.h"
#include "protos.h"
#include "tprintf.h"
#include "oui.h"

extern struct hash_table ieee80211_lay2;

extern void dissector_init_ieee80211(int fnttype);
extern void dissector_cleanup_ieee80211(void);

#ifdef HAVE_DISSECTOR_PROTOS
static inline struct protocol *dissector_get_ieee80211_entry_point(void)
{
	return &ieee80211_ops;
}

static inline struct protocol *dissector_get_ieee80211_exit_point(void)
{
	return &none_ops;
}
#else
static inline struct protocol *dissector_get_ieee80211_entry_point(void)
{
	return NULL;
}

static inline struct protocol *dissector_get_ieee80211_exit_point(void)
{
	return NULL;
}
#endif
#endif /* DISSECTOR_80211_H */
id'>1001354ca34179f3db924eb66672442a173147dc (diff)
spi: change post transfer udelay() to usleep_range() for long delays
The spi_transfer parameter delay_usecs allows specifying a time to wait after transferring a spi message. This wait can be quite long - some devices, such as some Chrome OS ECs, require as much as 2000 usecs after a SPI transaction, before it can respond. (cf: arch/arm64/boot/dts/nvidia/tegra132-norrin.dts: google,cros-ec-spi-msg-delay = <2000> ) Blocking a CPU for 2 msecs in a busy loop like this doesn't seem very friendly to other processes, so change the blocking delay to a sleep to allow other things to use this CPU (or so it can sleep). This should be safe to do, because: (a) A post-transaction delay like this is always specified as a minimum wait time (b) A delay here is most likely not very time sensitive, as it occurs after all data has been transferred (c) This delay occurs in a non-critical section of the spi worker thread so where it is safe to sleep. Two caveats: 1) To avoid penalizing short delays, still use udelay for delays < 10us. 2) usleep_range() very often picks the upper bound, an upper bounds 10% should be plenty. Signed-off-by: Daniel Kurtz <djkurtz@chromium.org> Signed-off-by: Mark Brown <broonie@kernel.org>
Diffstat (limited to 'Documentation')