{"push_id":1281307684,"size":10,"distinct_size":10,"ref":"refs/heads/new","head":"e40124e77aec613a1bc18784e281135cb5e3564c","before":"80df63ec1156f6296bbbcd0f0f2c71da282ecd63","commits":[{"sha":"9ade669ead377c7cefab72561f32d9526278aaf1","author":{"name":"tomascus","email":"b0cff599882a46363bdb899e3ff57539d8ae85f1@gmail.com"},"message":"drivers: qcom: mpm-of/rpm-smd: Use interruptible waits","distinct":true,"url":"https://api.github.com/repos/tunturn/codeaurora-caf/commits/9ade669ead377c7cefab72561f32d9526278aaf1"},{"sha":"edae46a11e1c7cba41ced27a00749bd2af3aaaea","author":{"name":"tomascus","email":"b0cff599882a46363bdb899e3ff57539d8ae85f1@gmail.com"},"message":"dts: aries: lower init brightness","distinct":true,"url":"https://api.github.com/repos/tunturn/codeaurora-caf/commits/edae46a11e1c7cba41ced27a00749bd2af3aaaea"},{"sha":"dd334b9d5c95c37ab522288f59205a59c91ee77f","author":{"name":"tomascus","email":"b0cff599882a46363bdb899e3ff57539d8ae85f1@gmail.com"},"message":"ARM: dts: msm: i2c: change clock rate to 19.2 MHz","distinct":true,"url":"https://api.github.com/repos/tunturn/codeaurora-caf/commits/dd334b9d5c95c37ab522288f59205a59c91ee77f"},{"sha":"7b74b23dd785c2e60c79a79124eeb1f34bd45caf","author":{"name":"tomascus","email":"b0cff599882a46363bdb899e3ff57539d8ae85f1@gmail.com"},"message":"dvb: don't build tuners","distinct":true,"url":"https://api.github.com/repos/tunturn/codeaurora-caf/commits/7b74b23dd785c2e60c79a79124eeb1f34bd45caf"},{"sha":"8e12bc61b2bfcb86cae3ceafee5201661faa0d30","author":{"name":"Theodore Ts'o","email":"27d72d8f7672ec04389c6b6ff53fcc4e9145bb77@mit.edu"},"message":"random: make 'add_interrupt_randomness()' do something sane\n\ncommit 775f4b297b780601e61787b766f306ed3e1d23eb upstream.\n\nWe've been moving away from add_interrupt_randomness() for various\nreasons: it's too expensive to do on every interrupt, and flooding the\nCPU with interrupts could theoretically cause bogus floods of entropy\nfrom a somewhat externally controllable source.\n\nThis solves both problems by limiting the actual randomness addition\nto just once a second or after 64 interrupts, whicever comes first.\nDuring that time, the interrupt cycle data is buffered up in a per-cpu\npool.  Also, we make sure the the nonblocking pool used by urandom is\ninitialized before we start feeding the normal input pool.  This\nassures that /dev/urandom is returning unpredictable data as soon as\npossible.\n\n(Based on an original patch by Linus, but significantly modified by\ntytso.)\n\nTested-by: Eric Wustrow <ewust@umich.edu>\nReported-by: Eric Wustrow <ewust@umich.edu>\nReported-by: Nadia Heninger <nadiah@cs.ucsd.edu>\nReported-by: Zakir Durumeric <zakir@umich.edu>\nReported-by: J. Alex Halderman <jhalderm@umich.edu>\nSigned-off-by: Linus Torvalds <torvalds@linux-foundation.org>\nSigned-off-by: \"Theodore Ts'o\" <tytso@mit.edu>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>\nSigned-off-by: Patrick Tjin <pattjin.google.com>","distinct":true,"url":"https://api.github.com/repos/tunturn/codeaurora-caf/commits/8e12bc61b2bfcb86cae3ceafee5201661faa0d30"},{"sha":"688f7ab1a5e95ac0a24515ce6416c7feb4b11176","author":{"name":"Theodore Ts'o","email":"27d72d8f7672ec04389c6b6ff53fcc4e9145bb77@mit.edu"},"message":"random: use lockless techniques in the interrupt path\n\ncommit 902c098a3663de3fa18639efbb71b6080f0bcd3c upstream.\n\nThe real-time Linux folks don't like add_interrupt_randomness() taking\na spinlock since it is called in the low-level interrupt routine.\nThis also allows us to reduce the overhead in the fast path, for the\nrandom driver, which is the interrupt collection path.\n\nSigned-off-by: \"Theodore Ts'o\" <tytso@mit.edu>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>\nSigned-off-by: Patrick Tjin <pattjin@google.com>","distinct":true,"url":"https://api.github.com/repos/tunturn/codeaurora-caf/commits/688f7ab1a5e95ac0a24515ce6416c7feb4b11176"},{"sha":"cfc15eb9b6665cda67c1b774c5e206beaf58d7be","author":{"name":"Linus Torvalds","email":"ead7104581934751970e9decb2db5deb20a9e407@linux-foundation.org"},"message":"random: create add_device_randomness() interface\n\ncommit a2080a67abe9e314f9e9c2cc3a4a176e8a8f8793 upstream.\n\nAdd a new interface, add_device_randomness() for adding data to the\nrandom pool that is likely to differ between two devices (or possibly\neven per boot).  This would be things like MAC addresses or serial\nnumbers, or the read-out of the RTC. This does *not* add any actual\nentropy to the pool, but it initializes the pool to different values\nfor devices that might otherwise be identical and have very little\nentropy available to them (particularly common in the embedded world).\n\n[ Modified by tytso to mix in a timestamp, since there may be some\n  variability caused by the time needed to detect/configure the hardware\n  in question. ]\n\nSigned-off-by: Linus Torvalds <torvalds@linux-foundation.org>\nSigned-off-by: \"Theodore Ts'o\" <tytso@mit.edu>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>\nSigned-off-by: Patrick Tjin <pattjin@google.com>","distinct":true,"url":"https://api.github.com/repos/tunturn/codeaurora-caf/commits/cfc15eb9b6665cda67c1b774c5e206beaf58d7be"},{"sha":"6187bb7f610273f88c6cd1ba52d552de72c69ac2","author":{"name":"Theodore Ts'o","email":"27d72d8f7672ec04389c6b6ff53fcc4e9145bb77@mit.edu"},"message":"random: use the arch-specific rng in xfer_secondary_pool\n\ncommit e6d4947b12e8ad947add1032dd754803c6004824 upstream.\n\nIf the CPU supports a hardware random number generator, use it in\nxfer_secondary_pool(), where it will significantly improve things and\nwhere we can afford it.\n\nAlso, remove the use of the arch-specific rng in\nadd_timer_randomness(), since the call is significantly slower than\nget_cycles(), and we're much better off using it in\nxfer_secondary_pool() anyway.\n\nSigned-off-by: \"Theodore Ts'o\" <tytso@mit.edu>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>\nSigned-off-by: Patrick Tjin <pattjin@google.com>","distinct":true,"url":"https://api.github.com/repos/tunturn/codeaurora-caf/commits/6187bb7f610273f88c6cd1ba52d552de72c69ac2"},{"sha":"8152f1b768547f8a5fd9343a5323c505b4a11323","author":{"name":"Theodore Ts'o","email":"27d72d8f7672ec04389c6b6ff53fcc4e9145bb77@mit.edu"},"message":"random: add new get_random_bytes_arch() function\n\ncommit c2557a303ab6712bb6e09447df828c557c710ac9 upstream.\n\nCreate a new function, get_random_bytes_arch() which will use the\narchitecture-specific hardware random number generator if it is\npresent.  Change get_random_bytes() to not use the HW RNG, even if it\nis avaiable.\n\nThe reason for this is that the hw random number generator is fast (if\nit is present), but it requires that we trust the hardware\nmanufacturer to have not put in a back door.  (For example, an\nincreasing counter encrypted by an AES key known to the NSA.)\n\nIt's unlikely that Intel (for example) was paid off by the US\nGovernment to do this, but it's impossible for them to prove otherwise\n  --- especially since Bull Mountain is documented to use AES as a\nwhitener.  Hence, the output of an evil, trojan-horse version of\nRDRAND is statistically indistinguishable from an RDRAND implemented\nto the specifications claimed by Intel.  Short of using a tunnelling\nelectronic microscope to reverse engineer an Ivy Bridge chip and\ndisassembling and analyzing the CPU microcode, there's no way for us\nto tell for sure.\n\nSince users of get_random_bytes() in the Linux kernel need to be able\nto support hardware systems where the HW RNG is not present, most\ntime-sensitive users of this interface have already created their own\ncryptographic RNG interface which uses get_random_bytes() as a seed.\nSo it's much better to use the HW RNG to improve the existing random\nnumber generator, by mixing in any entropy returned by the HW RNG into\n/dev/random's entropy pool, but to always _use_ /dev/random's entropy\npool.\n\nThis way we get almost of the benefits of the HW RNG without any\npotential liabilities.  The only benefits we forgo is the\nspeed/performance enhancements --- and generic kernel code can't\ndepend on depend on get_random_bytes() having the speed of a HW RNG\nanyway.\n\nFor those places that really want access to the arch-specific HW RNG,\nif it is available, we provide get_random_bytes_arch().\n\nSigned-off-by: \"Theodore Ts'o\" <tytso@mit.edu>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>\nSigned-off-by: Patrick Tjin <pattjin@google.com>","distinct":true,"url":"https://api.github.com/repos/tunturn/codeaurora-caf/commits/8152f1b768547f8a5fd9343a5323c505b4a11323"},{"sha":"e40124e77aec613a1bc18784e281135cb5e3564c","author":{"name":"Theodore Ts'o","email":"27d72d8f7672ec04389c6b6ff53fcc4e9145bb77@mit.edu"},"message":"random: remove rand_initialize_irq()\n\ncommit c5857ccf293968348e5eb4ebedc68074de3dcda6 upstream.\n\nWith the new interrupt sampling system, we are no longer using the\ntimer_rand_state structure in the irq descriptor, so we can stop\ninitializing it now.\n\n[ Merged in fixes from Sedat to find some last missing references to\n  rand_initialize_irq() ]\n\nSigned-off-by: \"Theodore Ts'o\" <tytso@mit.edu>\nSigned-off-by: Sedat Dilek <sedat.dilek@gmail.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>\nSigned-off-by: Patrick Tjin <pattjin@google.com>","distinct":true,"url":"https://api.github.com/repos/tunturn/codeaurora-caf/commits/e40124e77aec613a1bc18784e281135cb5e3564c"}]}
{"actor":{"display_login":"tunturn"}}