summaryrefslogtreecommitdiff
path: root/rnd.h
blob: 154fccfb75a42fcd89e56c197b0de8f2d997371d (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
#ifndef RND_H
#define RND_H

#define HIG_ENTROPY_SOURCE	"/dev/random"
#define LOW_ENTROPY_SOURCE	"/dev/urandom"

/* secrand is not really secure, but the name only suggests it's better to use
 * than rand(3) when transferring bytes over the network in non-security
 * critical structure members. secrand() is only used to fill up salts actually.
 */
extern int secrand(void);
extern void gen_key_bytes(unsigned char *area, size_t len);

#endif /* RND_H */
me='dt' onchange='this.form.submit();'>
authorDavid S. Miller <davem@davemloft.net>2016-04-28 17:27:31 -0400
committerDavid S. Miller <davem@davemloft.net>2016-04-28 17:27:31 -0400
commitbd34cf66cc48a5fb17deb7a1494845c45d71ba8e (patch)
tree0c49b6362be9e3f3a528af84f83389c93782f12d /Documentation
parentbbdd09ebd7ce87d2122fcc7d97f35a4f8931bc55 (diff)
parent06cd6d6eda4bedbb826ed36e4c89734ea364ec4b (diff)
Merge branch 'cpsw-phy-handle-fixes'
David Rivshin says: ==================== drivers: net: cpsw: phy-handle fixes This series fixes a number of related issues around using phy-handle properties in cpsw emac nodes. Patch 1 fixes a bug if more than one slave is used, and either slave uses the phy-handle property in the devicetree. Patch 2 fixes a NULL pointer dereference which can occur if a phy-handle property is used and of_phy_connect() return NULL, such as with a bad devicetree. Patch 3 fixes an issue where the phy-mode property would be ignored if a phy-handle property was used. This also fixes a bogus error message that would be emitted. Patch 4 fixes makes the binding documentation more explicit that exactly one PHY property should be used, and also marks phy_id as deprecated. Patch 5 cleans up the fixed-link case to work like the now-fixed phy-handle case. I have tested on the following hardware configurations: - (EVMSK) dual emac, phy_id property in both slaves - (EVMSK) dual emac, phy-handle property in both slaves - (EVMSK) a bad phy-handle property pointing to &mmc1 - (EVMSK) phy_id property with incorrect PHY address - (BeagleBoneBlack) single emac, phy_id property - (custom) single emac, fixed-link subnode Andrew Goodbody reported testing v2 on a board that doesn't use dual_emac mode, but with 2 PHYs using phy-handle properties [1]. Nicolas Chauvet reported testing v2 on an HP t410 (dm8148). Markus Brunner reported testing v1 on the following [2]: - emac0 with phy_id and emac1 with fixed phy - emac0 with phy-handle and emac1 with fixed phy - emac0 with fixed phy and emac1 with fixed phy [1] https://lkml.org/lkml/2016/4/22/537 [2] http://www.spinics.net/lists/netdev/msg357890.html ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
Diffstat (limited to 'Documentation')