{"shas":[["c30aa39c233ca1df8397eb9e9c8b40a397ce72bb","b6ffd6973e972cb999e8e535ab74da7fee0c035f@gmail.com","hwmon: (twl4030-madc-hwmon) Return proper error if hwmon_device_register fails\n\nThe driver did not return an error if the call to hwmon_device_register failed.\nFix by returning the error reported from hwmon_device_register.\n\nSigned-off-by: Axel Lin <axel.lin@gmail.com>\nSigned-off-by: Guenter Roeck <guenter.roeck@ericsson.com>","Axel Lin"],["a6e5e2be44616c8400f9ec2f635b10f8e579217c","49ad6a9f5aa17024c23048df346d55bda6837e01@linux-fr.org","i2c-i801: Move device ID definitions to driver\n\nMove the SMBus device ID definitions of recent devices from pci_ids.h\nto the i2c-i801.c driver file. They don't have to be shared, as they\nare clearly identified and only used in this driver. In the future,\nsuch IDs will go to i2c-i801 directly. This will make adding support\nfor new devices much faster and easier, as it will avoid cross-\nsubsystem patch sets and merge conflicts.\n\nSigned-off-by: Jean Delvare <khali@linux-fr.org>\nCc: Seth Heasley <seth.heasley@intel.com>\nAcked-by: Jesse Barnes <jbarnes@virtuousgeek.org>","Jean Delvare"],["56acc7a39ac4ac7638cdc32cd3d0832ebbc834e4","49ad6a9f5aa17024c23048df346d55bda6837e01@linux-fr.org","i2c-parport: Fix adapter list handling\n\nUse a standard list with proper locking to handle the list of\nadapters. Thankfully it only matters on systems with more than one\nparallel port, which are very rare.\n\nThanks to Lukasz Kapiec for reporting the problem to me.\n\nSigned-off-by: Jean Delvare <khali@linux-fr.org>\nCc: stable@kernel.org","Jean Delvare"],["e20a2d205c05cef6b5783df339a7d54adeb50962","d63e63e827a90cc302fb1ca9715a3ec2b01e6461@amd64.org","x86, AMD: Fix APIC timer erratum 400 affecting K8 Rev.A-E processors\n\nOlder AMD K8 processors (Revisions A-E) are affected by erratum\n400 (APIC timer interrupts don't occur in C states greater than\nC1). This, for example, means that X86_FEATURE_ARAT flag should\nnot be set for these parts.\n\nThis addresses regression introduced by commit\nb87cf80af3ba4b4c008b4face3c68d604e1715c6 (\"x86, AMD: Set ARAT\nfeature on AMD processors\") where the system may become\nunresponsive until external interrupt (such as keyboard input)\noccurs. This results, for example, in time not being reported\ncorrectly, lack of progress on the system and other lockups.\n\nReported-by: Joerg-Volker Peetz <jvpeetz@web.de>\nTested-by: Joerg-Volker Peetz <jvpeetz@web.de>\nAcked-by: Borislav Petkov <borislav.petkov@amd.com>\nSigned-off-by: Boris Ostrovsky <Boris.Ostrovsky@amd.com>\nCc: stable@kernel.org\nLink: http://lkml.kernel.org/r/1304113663-6586-1-git-send-email-ostr@amd64.org\nSigned-off-by: Ingo Molnar <mingo@elte.hu>","Boris Ostrovsky"],["2be19102b71c1a45d37fec50303791daa1a06869","0674548f4d596393408a51d6287a76ebba2f42aa@kernel.org","x86, NUMA: Fix empty memblk detection in numa_cleanup_meminfo()\n\nnuma_cleanup_meminfo() trims each memblk between low (0) and\nhigh (max_pfn) limits and discards empty ones.  However, the\nemptiness detection incorrectly used equality test.  If the\nstart of a memblk is higher than max_pfn, it is empty but fails\nthe equality test and doesn't get discarded.\n\nThe condition triggers when max_pfn is lower than start of a\nNUMA node and results in memory misconfiguration - leading to\nWARN_ON()s and other funnies.  The bug was discovered in devel\nbranch where 32bit too uses this code path for NUMA init.  If a\nnode is above the addressing limit, max_pfn ends up lower than\nthe node triggering this problem.\n\nThe failure hasn't been observed on x86-64 but is still possible\nwith broken hardware e820/NUMA info.  As the fix is very low\nrisk, it would be better to apply it even for 64bit.\n\nFix it by using >= instead of ==.\n\nSigned-off-by: Yinghai Lu <yinghai@kernel.org>\n[ Extracted the actual fix from the original patch and rewrote patch description. ]\nSigned-off-by: Tejun Heo <tj@kernel.org>\nLink: http://lkml.kernel.org/r/20110501171204.GO29280@htj.dyndns.org\nSigned-off-by: Ingo Molnar <mingo@elte.hu>","Yinghai Lu"],["a05d2ad1c1f391c7f514a1d1e09b5417968a7d07","8a741aa8cbd77ebc4a56ddb528ce9fd15d42f034@xmission.com","af_unix: Only allow recv on connected seqpacket sockets.\n\nThis fixes the following oops discovered by Dan Aloni:\n> Anyway, the following is the output of the Oops that I got on the\n> Ubuntu kernel on which I first detected the problem\n> (2.6.37-12-generic). The Oops that followed will be more useful, I\n> guess.\n\n>[ 5594.669852] BUG: unable to handle kernel NULL pointer dereference\n> at           (null)\n> [ 5594.681606] IP: [<ffffffff81550b7b>] unix_dgram_recvmsg+0x1fb/0x420\n> [ 5594.687576] PGD 2a05d067 PUD 2b951067 PMD 0\n> [ 5594.693720] Oops: 0002 [#1] SMP\n> [ 5594.699888] last sysfs file:\n\nThe bug was that unix domain sockets use a pseduo packet for\nconnecting and accept uses that psudo packet to get the socket.\nIn the buggy seqpacket case we were allowing unconnected\nsockets to call recvmsg and try to receive the pseudo packet.\n\nThat is always wrong and as of commit 7361c36c5 the pseudo\npacket had become enough different from a normal packet\nthat the kernel started oopsing.\n\nDo for seqpacket_recv what was done for seqpacket_send in 2.5\nand only allow it on connected seqpacket sockets.\n\nCc: stable@kernel.org\nTested-by: Dan Aloni <dan@aloni.org>\nSigned-off-by: Eric W. Biederman <ebiederm@xmission.com>\nSigned-off-by: David S. Miller <davem@davemloft.net>","Eric W. Biederman"],["7cfd260910b881250cde76ba92ebe3cbf8493a8f","b99bff5923d24d2fb8e844db9dac7cd59203da1d@gmail.com","ipv4: don't spam dmesg with \"Using LC-trie\" messages\n\nfib_trie_table() is called during netns creation and\nChromium uses clone(CLONE_NEWNET) to sandbox renderer process.\n\nDon't print anything.\n\nSigned-off-by: Alexey Dobriyan <adobriyan@gmail.com>\nSigned-off-by: David S. Miller <davem@davemloft.net>","Alexey Dobriyan"],["ebb47241ea0eac6a5a23404821a2d62f64c68496","4596b3305151c7ee743192a95d394341e3d3b644@suse.de","Revert \"ALSA: hda - Fix pin-config of Gigabyte mobo\"\n\nThis reverts commit c6b358748e19ce7e230b0926ac42696bc485a562.\n\nIt turned out that there are different pin configurations for this\nPCI SSID, including multi-channel modes.  And more proper fix for\nallowing line-out mutes will come up in 2.6.40 tree, so we won't need\nthis fixup any more there.\n\nReported-by: Andrew Clayton <andrew@digital-domain.net>\nReported-by: Emmanuel Benisty <benisty.e@gmail.com>\nCc: <stable@kernel.org>\nSigned-off-by: Takashi Iwai <tiwai@suse.de>","Takashi Iwai"],["383cf4e8d47f902600263191f8f167379c376985","12ec1bb77030d67fad9a26e362b71e2dfbcda22a@gmail.com","usb: musb: omap2430: Fix retention idle on musb peripheral only boards\n\nRecent runtime pm and hwmod conversions for 2.6.39 broke the musb peripheral\nmode OMAP retention idle on boards where the board mode in struct\nmusb_hdrc_platform_data is set to MUSB_PERIPHERAL.\n\nThese conversions changed the way how the OTG_SYSCONFIG register is\nconfigured and used in runtime. Before 2.6.39 smart standby/idle modes were\nactivated statically in OTG_SYSCONFIG. Those modes allow that the musb is\nable to idle when peripheral device is not connected to host.\n\nIn 2.6.39 the OTG_SYSCONFIG is updated runtime depending on VBUS status.\nNo standby/idle modes are used when device is connected and force\nstandby/idle when disconnected.\n\nUnfortunately VBUS disconnect event that handles the disconnect case lets\nthe peripheral musb to idle only when board mode is MUSB_OTG. Fix this by\nchecking the peripheral mode also.\n\nSigned-off-by: Jarkko Nikula <jhnikula@gmail.com>\nSigned-off-by: Felipe Balbi <balbi@ti.com>","Jarkko Nikula"],["cdefce169594742ace29a2016dfa381755428ab5","12ec1bb77030d67fad9a26e362b71e2dfbcda22a@gmail.com","usb: musb: gadget: Fix out-of-sync runtime pm calls\n\nIf cable is not connected to peripheral only board when initializing the\ngadget driver, then runtime pm calls are out-of-sync and the musb cannot\nidle with omap2430.c. This was noted on Nokia N900 where musb prevented the\nCPU to be able to enter deeper retention idle state.\n\nThis was working in 2.6.38 before runtime pm conversions but there musb\nsmart standby/idle modes were configured statically where they are now\nupdated runtime depending on use and cable status.\n\nReason for out-of-sync is that runtime pm is activated in function\nmusb_gadget.c: usb_gadget_probe_driver but suspended only in OTG mode if\ncable is not connected when initializing. In peripheral only mode this leads\nto out-of-sync runtime pm since runtime pm remain active and is activated\nanother time in omap2430.c: musb_otg_notifications for VBUS Connect event\nand thus cannot suspend for VBUS Disconnect event since the use count remains\nactive.\n\nFix this by moving cable status check and pm_runtime_put call in\nusb_gadget_probe_driver out of is_otg_enabled block.\n\nSigned-off-by: Jarkko Nikula <jhnikula@gmail.com>\nSigned-off-by: Felipe Balbi <balbi@ti.com>","Jarkko Nikula"],["d11536e4e0e99c26d33c849b44cd279cdd67b032","b6ffd6973e972cb999e8e535ab74da7fee0c035f@gmail.com","mfd: Fix usbhs_enable error handling\n\nIn the case of missing platform_data we do not hold a spin_lock,\nthus we should not call spin_unlock_irqrestore in the error path.\n\nAlso simplify the error handling by separating the successful path\nfrom error path. I think this change improves readability.\n\nSigned-off-by: Axel Lin <axel.lin@gmail.com>\nTested-by: Steve Calfee <stevecalfee@gmail.com>\nSigned-off-by: Felipe Balbi <balbi@ti.com>","Axel Lin"],["24af2b1cc418d6791b1d9e56bf6070cccb752db3","4596b3305151c7ee743192a95d394341e3d3b644@suse.de","ALSA: hda - Fix Realtek's chained fixup checks\n\nThe check of chained fixup list entry was done against the wrong element.\nA stupid mistake during refactoring.\n\nCc: <stable@kernel.org>\nSigned-off-by: Takashi Iwai <tiwai@suse.de>","Takashi Iwai"],["6e3d4bec6b1e0829ed8b23be750762255f225019","a6afae2ef589a86998728d79a7f937682afa595e@ti.com","omap:usb: add regulator support for EHCI\n\nin case of ehci phy mode; regulator of phy\nshould be enabled before initializing the\nusbhs core driver.\n\nSigned-off-by: Keshava Munegowda <keshava_mgowda@ti.com>\nTested-by: Steve Calfee <stevecalfee@gmail.com>\nSigned-off-by: Felipe Balbi <balbi@ti.com>","Keshava Munegowda"],["646032e3b05b32d3f20cb108a030593d9d792eb5","54c4a333fa12d5afeed41b942e93e34dc37c3466@tukaani.org","XZ decompressor: Fix decoding of empty LZMA2 streams\n\nThe old code considered valid empty LZMA2 streams to be corrupt.\nNote that a typical empty .xz file has no LZMA2 data at all,\nand thus most .xz files having no uncompressed data are handled\ncorrectly even without this fix.\n\nSigned-off-by: Lasse Collin <lasse.collin@tukaani.org>\nSigned-off-by: Linus Torvalds <torvalds@linux-foundation.org>","Lasse Collin"],["bc9be57f85d465506d0d4a8951275dae4e694f16","69652caca27c8b940640ad396ab71f93cacec34f@linux-foundation.org","Merge branch 'i2c-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jdelvare/staging\n\n* 'i2c-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jdelvare/staging:\n  i2c-parport: Fix adapter list handling\n  i2c-i801: Move device ID definitions to driver","Linus Torvalds"],["fa515888821d307a79cb8d1e8e052b7aff39d844","69652caca27c8b940640ad396ab71f93cacec34f@linux-foundation.org","Merge branch 'hwmon-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/groeck/staging\n\n* 'hwmon-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/groeck/staging:\n  hwmon: (twl4030-madc-hwmon) Return proper error if hwmon_device_register fails","Linus Torvalds"],["96f3ee280549ebf62818ef71603061a3b3230eb9","69652caca27c8b940640ad396ab71f93cacec34f@linux-foundation.org","Merge branch 'for-linus' of git://git390.marist.edu/pub/scm/linux-2.6\n\n* 'for-linus' of git://git390.marist.edu/pub/scm/linux-2.6:\n  [S390] irqstats: fix counting of pfault, dasd diag and virtio irqs\n  [S390] prng: fix pointer arithmetic","Linus Torvalds"],["c7bcecbe98fe29e87ac7d01c70c5998806e0989f","69652caca27c8b940640ad396ab71f93cacec34f@linux-foundation.org","Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound-2.6\n\n* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound-2.6:\n  ALSA: hda - Fix Realtek's chained fixup checks\n  Revert \"ALSA: hda - Fix pin-config of Gigabyte mobo\"\n  ALSA: HDA: Fix automute for Gateway NV79\n  ALSA: hda: add beep quirk for Realtek 0x1043:831a\n  ALSA: usb-audio - Terratec Aureon 7.1 USB ID as C-Media cm6206 quirks\n  ALSA: hda - VIA: Fix notify_aa_path_ctls() invalid issue.\n  ALSA - au88x0 - Add buffer bytes constraints","Linus Torvalds"],["b50b9f408502a2ea90459ae36ba8cdc9cc005cfe","19b5733dcea388885746d36043d3568bba5b4df7@nokia.com","UBIFS: do not free write-buffers when in R/O mode\n\nCurrently UBIFS has a small optimization - it frees write-buffers when it is\nre-mounted from R/W mode to R/O mode. Of course, when it is mounted R/O, it\ndoes not allocate write-buffers as well.\n\nThis optimization is nice but it leads to subtle problems and complications\nin recovery, which I can reproduce using the integck test. The symptoms are\nthat after a power cut the file-system cannot be mounted if we first mount\nit R/O, and then re-mount R/W - 'ubifs_rcvry_gc_commit()' prints:\n\nUBIFS error (pid 34456): could not find an empty LEB\n\nAnalysis of the  problem.\n\nWhen mounting R/W, the reply process sets journal heads to buds [1], but\nwhen mounting R/O - it does not do this, because the write-buffers are not\nallocated. So 'ubifs_rcvry_gc_commit()' works completely differently for the\nsame file-system but for the following 2 cases:\n\n1. mounting R/W after a power cut and recover\n2. mounting R/O after a power cut, re-mounting R/W and run deferred recovery\n\nIn the former case, we have journal heads seeked to the a bud, in the latter\ncase, they are non-seeked (wbuf->lnum == -1). So in the latter case we do not\ntry to recover the GC LEB by garbage-collecting to the GC head, but we just\ntry to find an empty LEB, and there may be no empty LEBs, so we just fail.\nOn the other hand, in the former case (mount R/W), we are able to make a GC LEB\n(@c->gc_lnum) by garbage-collecting.\n\nThus, let's remove this small nice optimization and always allocate\nwrite-buffers. This should not make too big difference - we have only 3\nof them, each of max. write unit size, which is usually 2KiB. So this is\nabout 6KiB of RAM for the typical case, and only when mounted R/O.\n\n[1]: Note, currently the replay process is setting (seeking) the journal heads\nto _some_ buds, not necessarily to the buds which had been the journal heads\nbefore the power cut happened. This will be fixed separately.\n\nSigned-off-by: Artem Bityutskiy <Artem.Bityutskiy@nokia.com>\nCc: stable@kernel.org","Artem Bityutskiy"],["52c6e6f990669deac3f370f1603815adb55a1dbd","19b5733dcea388885746d36043d3568bba5b4df7@nokia.com","UBIFS: seek journal heads to the latest bud in replay\n\nThis is the second fix of the following symptom:\n\nUBIFS error (pid 34456): could not find an empty LEB\n\nwhich sometimes happens after power cuts when we mount the file-system - UBIFS\nrefuses it with the above error message which comes from the\n'ubifs_rcvry_gc_commit()' function. I can reproduce this using the integck test\nwith the UBIFS power cut emulation enabled.\n\nAnalysis of the problem.\n\nCurrently UBIFS replay seeks the journal heads to the last _replayed_ bud.\nBut the buds are replayed out-of-order, so the replay basically seeks journal\nheads to the \"random\" bud belonging to this head, and not to the _last_ one.\n\nThe result of this is that the GC head may be seeked to a full LEB with no free\nspace, or very little free space. And 'ubifs_rcvry_gc_commit()' tries to find a\nfully or mostly dirty LEB to match the current GC head (because we need to\ngarbage-collect that dirty LEB at one go, because we do not have @c->gc_lnum).\nSo 'ubifs_find_dirty_leb()' fails and we fall back to finding an empty LEB and\nalso fail. As a result - recovery fails and mounting fails.\n\nThis patch teaches the replay to initialize the GC heads exactly to the latest\nbuds, i.e. the buds which have the largest sequence number in corresponding\nlog reference nodes.\n\nSigned-off-by: Artem Bityutskiy <Artem.Bityutskiy@nokia.com>\nCc: stable@kernel.org","Artem Bityutskiy"]],"repo":"nikai3d/linux-2.6","actor":"nikai3d","ref":"refs/heads/master","size":65,"head":"bfd412db9e7b0d8f7b9c09d12d07aa2ac785f1d0","actor_gravatar":"fc961dbae07fe5d345d581fdd96a9a78","push_id":30716783}