{"shas":[["16b7ff08f276f31ffda6f3de02e38062a3086649","11a453fd6f665d48a9bc4594a11670a1de72c263@denx.de","USB: serial: add IDs for WinChipHead USB->RS232 adapter\n\ncommit 026dfaf18973404a01f488d6aa556a8c466e06a4 upstream.\n\nAdd ID 4348:5523 for WinChipHead USB->RS 232 adapter with\nProlifec PL2303 chipset\n\nSigned-off-by: Wolfgang Denk <wd@denx.de>\nSigned-off-by: Greg Kroah-Hartman <gregkh@suse.de>","Wolfgang Denk"],["1138473c4a69e0f49d44a0c07fffe90c3dd95824","e3b68a24fc9500c3d2517c22ec1132efd7c9aba7@canonical.com","mmc: Added quirks for Ricoh 1180:e823 lower base clock frequency\n\ncommit 15bed0f2fa8e1d7db201692532c210a7823d2d21 upstream.\n\nRicoh 1180:e823 does not recognize certain types of SD/MMC cards,\nas reported at http://launchpad.net/bugs/773524.  Lowering the SD\nbase clock frequency from 200Mhz to 50Mhz fixes this issue. This\nsolution was suggest by Koji Matsumuro, Ricoh Company, Ltd.\n\nThis change has no negative performance effect on standard SD\ncards, though it's quite possible that there will be one on\nUHS-1 cards.\n\nSigned-off-by: Manoj Iyer <manoj.iyer@canonical.com>\nTested-by: Daniel Manrique <daniel.manrique@canonical.com>\nCc: Koji Matsumuro <matsumur@nts.ricoh.co.jp>\nAcked-by: Jesse Barnes <jbarnes@virtuousgeek.org>\nSigned-off-by: Chris Ball <cjb@laptop.org>\nSigned-off-by: Greg Kroah-Hartman <gregkh@suse.de>","Manoj Iyer"],["fbbc165db18d24de056e50d8ae7d6f1aa3b198fe","912cf7eb7d8018e2943586ae6657d21fd4e38239@linaro.org","mmc: sdhci-esdhc-imx: SDHCI_CARD_PRESENT does not get cleared\n\ncommit 803862a6f7de4939e0a557214e5e4b37e36f87ff upstream.\n\nThe function esdhc_readl_le intends to clear bit SDHCI_CARD_PRESENT,\nwhen the card detect gpio tells there is no card.  But it does not\nclear the bit actually.  The patch gives a fix on that.\n\nSigned-off-by: Shawn Guo <shawn.guo@linaro.org>\nAcked-by: Wolfram Sang <w.sang@pengutronix.de>\nSigned-off-by: Chris Ball <cjb@laptop.org>\nSigned-off-by: Greg Kroah-Hartman <gregkh@suse.de>","Shawn Guo"],["bde99f604b42182e590ac4b7176b5235321bc94c","a072e933f45880fe04500ea083d5c7f6e81a06f0@vyatta.com","bridge: send proper message_age in config BPDU\n\ncommit 0c03150e7ea8f7fcd03cfef29385e0010b22ee92 upstream.\n\nA bridge topology with three systems:\n\n      +------+  +------+\n      | A(2) |--| B(1) |\n      +------+  +------+\n           \\    /\n          +------+\n          | C(3) |\n          +------+\n\nWhat is supposed to happen:\n * bridge with the lowest ID is elected root (for example: B)\n * C detects that A->C is higher cost path and puts in blocking state\n\nWhat happens. Bridge with lowest id (B) is elected correctly as\nroot and things start out fine initially. But then config BPDU\ndoesn't get transmitted from A -> C. Because of that\nthe link from A-C is transistioned to the forwarding state.\n\nThe root cause of this is that the configuration messages\nis generated with bogus message age, and dropped before\nsending.\n\nIn the standardmessage_age is supposed to be:\n  the time since the generation of the Configuration BPDU by\n  the Root that instigated the generation of this Configuration BPDU.\n\nReimplement this by recording the timestamp (age + jiffies) when\nrecording config information. The old code incorrectly used the time\nelapsed on the ageing timer which was incorrect.\n\nSee also:\n  https://bugzilla.vyatta.com/show_bug.cgi?id=7164\n\nSigned-off-by: Stephen Hemminger <shemminger@vyatta.com>\nSigned-off-by: David S. Miller <davem@davemloft.net>\nSigned-off-by: Greg Kroah-Hartman <gregkh@suse.de>","stephen hemminger"],["97edbc901240090ca75b81aa8955bcef8d570434","ef65de1c7be0aa837fe7b25ba9a7739905af6a55@gondor.apana.org.au","gro: Only reset frag0 when skb can be pulled\n\ncommit 17dd759c67f21e34f2156abcf415e1f60605a188 upstream.\n\nCurrently skb_gro_header_slow unconditionally resets frag0 and\nfrag0_len.  However, when we can't pull on the skb this leaves\nthe GRO fields in an inconsistent state.\n\nThis patch fixes this by only resetting those fields after the\npskb_may_pull test.\n\nSigned-off-by: Herbert Xu <herbert@gondor.apana.org.au>\nSigned-off-by: David S. Miller <davem@davemloft.net>\nSigned-off-by: Greg Kroah-Hartman <gregkh@suse.de>","Herbert Xu"],["efa73f1334e339902993bb4894da47242f0c4173","9249c549618448e4c699e8032ba6c7f0d7fd4b7f@distanz.ch","Staging: usbip: vhci-hcd: Do not kill already dead RX/TX kthread\n\ncommit 8547d4cc2b616e4f1dafebe2c673fc986422b506 upstream.\n\nWhen unbinding a device on the host which was still attached on the\nclient, I got a NULL pointer dereference on the client. This turned out\nto be due to kthread_stop() being called on an already dead kthread.\n\nHere is how I was able to reproduce the problem:\n\n server:# usbip bind -b 1-2\n                                client:# usbip attach -h server -b 1-2\n server:# usbip unbind -b 1-2\n\nThis patch fixes the problem by checking the kthread before attempting\nto kill it, as it is done on the opposite side in\nstub_shutdown_connection().\n\nSigned-off-by: Tobias Klauser <tklauser@distanz.ch>\nSigned-off-by: Greg Kroah-Hartman <gregkh@suse.de>","Tobias Klauser"],["565af28bfba187fabda9bccf065e2009356aaae5","ed0f1d78b8c21b2970494a178da4bdfa8beba2a7@lwfinger.net","staging: r8192e_pci: Handle duplicate PCI ID 0x10ec:0x8192 conflict with rtl8192se\n\ncommit 1c50bf7e415cf6ce9545dbecc2ac0d89d3916c53 upstream.\n\nThere are two devices with PCI ID 0x10ec:0x8192, namely RTL8192E and\nRTL8192SE. The method of distinguishing them is by the revision ID\nat offset 0x8 of the PCI configuration space. If the value is 0x10,\nthen the device uses rtl8192se for a driver.\n\nSigned-off-by: Larry Finger <Larry.Finger@lwfinger.net>\nSigned-off-by: Greg Kroah-Hartman <gregkh@suse.de>","Larry Finger"],["13949a7b5f9a9da49a7426795716aa3b68f7b13c","942b402b07c522a8271785df04894b4692262f69@openwall.com","staging: comedi: fix infoleak to userspace\n\ncommit 819cbb120eaec7e014e5abd029260db1ca8c5735 upstream.\n\ndriver_name and board_name are pointers to strings, not buffers of size\nCOMEDI_NAMELEN.  Copying COMEDI_NAMELEN bytes of a string containing\nless than COMEDI_NAMELEN-1 bytes would leak some unrelated bytes.\n\nSigned-off-by: Vasiliy Kulikov <segoon@openwall.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@suse.de>","Vasiliy Kulikov"],["f9211c1f7562b1057dcb6e57a9a4e96c8b853248","bcbf172338421f26297a2592698edf8cc84ecbef@microsoft.com","Staging: hv: storvsc: Increase the timeout value in the storvsc driver\n\ncommit 46d2eb6d82ef44be58ae192c35e8cd52485f02eb upstream.\n\nOn some loaded windows hosts, we have discovered that the host may not\nrespond to guest requests within the specified time (one second)\nas evidenced by the guest timing out. Fix this problem by increasing\nthe timeout to 5 seconds.\n\nIt may be useful to apply this patch to the 3.0 kernel as well.\nthe 3.0 kernel as well.\n\nSigned-off-by: K. Y. Srinivasan <kys@microsoft.com>\nSigned-off-by: Haiyang Zhang <haiyangz@microsoft.com>\nSigned-off-by: Hank Janssen <hjanssen@microsoft.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@suse.de>","K. Y. Srinivasan"],["3c22382d9b35d1a8d012442315a8493bbac3b5d4","bcbf172338421f26297a2592698edf8cc84ecbef@microsoft.com","Staging: hv: vmbus: Increase the timeout value in the vmbus driver\n\ncommit 2dfde9644fe8c4a77f9c73f95b25d6300ca23b5d upstream.\n\nOn some loaded windows hosts, we have discovered that the host may not\nrespond to guest requests within the specified time (one second)\nas evidenced by the guest timing out. Fix this problem by increasing\nthe timeout to 5 seconds.\n\nIt may be useful to apply this patch to the 3.0 kernel as well.\n\nSigned-off-by: K. Y. Srinivasan <kys@microsoft.com>\nSigned-off-by: Haiyang Zhang <haiyangz@microsoft.com>\nSigned-off-by: Hank Janssen <hjanssen@microsoft.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@suse.de>","K. Y. Srinivasan"],["7cf375c453097d0dab7aee0c66fc6b7c1fbae763","bcbf172338421f26297a2592698edf8cc84ecbef@microsoft.com","Staging: hv: netvsc: Increase the timeout value in the netvsc driver\n\ncommit 5c5781b3f88567211ecaaada13431af15c8c6003 upstream.\n\nOn some loaded windows hosts, we have discovered that the host may not\nrespond to guest requests within the specified time (one second)\nas evidenced by the guest timing out. Fix this problem by increasing\nthe timeout to 5 seconds.\n\nIt may be useful to apply this patch to the 3.0 kernel as well.\n\nSigned-off-by: K. Y. Srinivasan <kys@microsoft.com>\nSigned-off-by: Haiyang Zhang <haiyangz@microsoft.com>\nSigned-off-by: Hank Janssen <hjanssen@microsoft.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@suse.de>","K. Y. Srinivasan"],["d05dcfcd0fea25eefa8b85926792b161239ac6b1","75ea6bb7bfc1186f92d26164de5f9268c9a45b59@rowland.harvard.edu","USB: OHCI: fix another regression for NVIDIA controllers\n\ncommit 6ea12a04d295235ed67010a09fdea58c949e3eb0 upstream.\n\nThe NVIDIA series of OHCI controllers continues to be troublesome.  A\nfew people using the MCP67 chipset have reported that even with the\nmost recent kernels, the OHCI controller fails to handle new\nconnections and spams the system log with \"unable to enumerate USB\nport\" messages.  This is different from the other problems previously\nreported for NVIDIA OHCI controllers, although it is probably related.\n\nIt turns out that the MCP67 controller does not like to be kept in the\nRESET state very long.  After only a few seconds, it decides not to\nwork any more.  This patch (as1479) changes the PCI initialization\nquirk code so that NVIDIA controllers are switched into the SUSPEND\nstate after 50 ms of RESET.  With no interrupts enabled and all the\ndownstream devices reset, and thus unable to send wakeup requests,\nthis should be perfectly safe (even for non-NVIDIA hardware).\n\nThe removal code in ohci-hcd hasn't been changed; it will still leave\nthe controller in the RESET state.  As a result, if someone unloads\nohci-hcd and then reloads it, the controller won't work again until\nthe system is rebooted.  If anybody complains about this, the removal\ncode can be updated similarly.\n\nThis fixes Bugzilla #22052.\n\nTested-by: Larry Finger <Larry.Finger@lwfinger.net>\nSigned-off-by: Alan Stern <stern@rowland.harvard.edu>\nSigned-off-by: Greg Kroah-Hartman <gregkh@suse.de>","Alan Stern"],["22007e1ddbe599373b116ecf3485ebf842405f73","75ea6bb7bfc1186f92d26164de5f9268c9a45b59@rowland.harvard.edu","USB: EHCI: go back to using the system clock for QH unlinks\n\ncommit 004c19682884d4f40000ce1ded53f4a1d0b18206 upstream.\n\nThis patch (as1477) fixes a problem affecting a few types of EHCI\ncontroller.  Contrary to what one might expect, these controllers\nautomatically stop their internal frame counter when no ports are\nenabled.  Since ehci-hcd currently relies on the frame counter for\ndetermining when it should unlink QHs from the async schedule, those\ncontrollers run into trouble: The frame counter stops and the QHs\nnever get unlinked.\n\nSome systems have also experienced other problems traced back to\ncommit b963801164618e25fbdc0cd452ce49c3628b46c8 (USB: ehci-hcd unlink\nspeedups), which made the original switch from using the system clock\nto using the frame counter.  It never became clear what the reason was\nfor these problems, but evidently it is related to use of the frame\ncounter.\n\nTo fix all these problems, this patch more or less reverts that commit\nand goes back to using the system clock.  But this can't be done\ncleanly because other changes have since been made to the scan_async()\nsubroutine.  One of these changes involved the tricky logic that tries\nto avoid rescanning QHs that have already been seen when the scanning\nloop is restarted, which happens whenever an URB is given back.\nSwitching back to clock-based unlinks would make this logic even more\ncomplicated.\n\nTherefore the new code doesn't rescan the entire async list whenever a\ngiveback occurs.  Instead it rescans only the current QH and continues\non from there.  This requires the use of a separate pointer to keep\ntrack of the next QH to scan, since the current QH may be unlinked\nwhile the scanning is in progress.  That new pointer must be global,\nso that it can be adjusted forward whenever the _next_ QH gets\nunlinked.  (uhci-hcd uses this same trick.)\n\nSimplification of the scanning loop removes a level of indentation,\nwhich accounts for the size of the patch.  The amount of code changed\nis relatively small, and it isn't exactly a reversion of the\nb963801164 commit.\n\nThis fixes Bugzilla #32432.\n\nSigned-off-by: Alan Stern <stern@rowland.harvard.edu>\nTested-by: Matej Kenda <matejken@gmail.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@suse.de>","Alan Stern"],["0f231ea4d4505adfcbe949e6716eb0d02e2c14a5","e07c675cf8f418a4c15b581efbf445af628cd457@ti.com","usb: musb: restore INDEX register in resume path\n\ncommit 3c5fec75e121b21a2eb35e5a6b44291509abba6f upstream.\n\nRestoring the missing INDEX register value in musb_restore_context().\nWithout this suspend resume functionality is broken with offmode\nenabled.\n\nAcked-by: Anand Gadiyar <gadiyar@ti.com>\nSigned-off-by: Ajay Kumar Gupta <ajay.gupta@ti.com>\nSigned-off-by: Felipe Balbi <balbi@ti.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@suse.de>","Ajay Kumar Gupta"],["cc4b6e7755a8c351d7ddf32b5f2e7f101cea5aa6","00e4cf8f46a57000a44449bf9dd8cbbcc209fd2a@linutronix.de","rtc: handle errors correctly in rtc_irq_set_state()\n\ncommit 2c4f57d12df7696d65b0247bfd57fd082a7719e6 upstream.\n\nThe code checks the correctness of the parameters, but unconditionally\narms/disarms the hrtimer.\n\nThe result is that a random task might arm/disarm rtc timer and surprise\nthe real owner by either generating events or by stopping them.\n\nSigned-off-by: Thomas Gleixner <tglx@linutronix.de>\nCc: John Stultz <john.stultz@linaro.org>\nCc: Ingo Molnar <mingo@elte.hu>\nCc: Ben Greear <greearb@candelatech.com>\nSigned-off-by: Andrew Morton <akpm@linux-foundation.org>\nSigned-off-by: Linus Torvalds <torvalds@linux-foundation.org>\nSigned-off-by: Greg Kroah-Hartman <gregkh@suse.de>","Thomas Gleixner"],["e9c5291ba063473a5560d3387773e9a6997bad65","00e4cf8f46a57000a44449bf9dd8cbbcc209fd2a@linutronix.de","rtc: fix hrtimer deadlock\n\ncommit b830ac1d9a2262093bb0f3f6a2fd2a1c8278daf5 upstream.\n\nBen reported a lockup related to rtc. The lockup happens due to:\n\nCPU0                                        CPU1\n\nrtc_irq_set_state()\t\t\t    __run_hrtimer()\n  spin_lock_irqsave(&rtc->irq_task_lock)    rtc_handle_legacy_irq();\n\t\t\t\t\t      spin_lock(&rtc->irq_task_lock);\n  hrtimer_cancel()\n    while (callback_running);\n\nSo the running callback never finishes as it's blocked on\nrtc->irq_task_lock.\n\nUse hrtimer_try_to_cancel() instead and drop rtc->irq_task_lock while\nwaiting for the callback.  Fix this for both rtc_irq_set_state() and\nrtc_irq_set_freq().\n\nSigned-off-by: Thomas Gleixner <tglx@linutronix.de>\nReported-by: Ben Greear <greearb@candelatech.com>\nCc: John Stultz <john.stultz@linaro.org>\nCc: Ingo Molnar <mingo@elte.hu>\nSigned-off-by: Andrew Morton <akpm@linux-foundation.org>\nSigned-off-by: Linus Torvalds <torvalds@linux-foundation.org>\nSigned-off-by: Greg Kroah-Hartman <gregkh@suse.de>","Thomas Gleixner"],["ec054bbddbd0841174f4d5c3a4685eca9f9a9f93","00e4cf8f46a57000a44449bf9dd8cbbcc209fd2a@linutronix.de","rtc: limit frequency\n\ncommit 431e2bcc371016824f419baa745f82388258f3ee upstream.\n\nDue to the hrtimer self rearming mode a user can DoS the machine simply\nbecause it's starved by hrtimer events.\n\nThe RTC hrtimer is self rearming.  We really need to limit the frequency\nto something sensible.\n\nSigned-off-by: Thomas Gleixner <tglx@linutronix.de>\nCc: John Stultz <john.stultz@linaro.org>\nCc: Ingo Molnar <mingo@elte.hu>\nCc: Ben Greear <greearb@candelatech.com>\nSigned-off-by: Andrew Morton <akpm@linux-foundation.org>\nSigned-off-by: Linus Torvalds <torvalds@linux-foundation.org>\nSigned-off-by: Greg Kroah-Hartman <gregkh@suse.de>","Thomas Gleixner"],["9ec4f65f5fa8211166e65854e8966d1bd5c4a180","181323dd666a182bc2d953e52d0ac3ab54cd8391@pengutronix.de","drivers/rtc/rtc-tegra.c: properly initialize spinlock\n\ncommit e57ee01750c4954fd0b5e3c6109cd4b870880eb9 upstream.\n\nUsing __SPIN_LOCK_UNLOCKED for a dynamically allocated lock is wrong and\nbreaks the build with PREEMPT_RT_FULL.\n\nSigned-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>\nCc: Andrew Chew <achew@nvidia.com>\nSigned-off-by: Andrew Morton <akpm@linux-foundation.org>\nSigned-off-by: Linus Torvalds <torvalds@linux-foundation.org>\nSigned-off-by: Greg Kroah-Hartman <gregkh@suse.de>","Uwe Kleine-König"],["307167f9ca9c669ac3b67719e6619b22586858db","9e6f8d6081ce24a2c1d8f777071cb7290aaf46a3@compulab.co.il","ARM: pxa/cm-x300: fix V3020 RTC functionality\n\ncommit 6c7b3ea52e345ab614edb91d3f0e9f3bb3713871 upstream.\n\nWhile in sleep mode the CS# and other V3020 RTC GPIOs must be driven\nhigh, otherwise V3020 RTC fails to keep the right time in sleep mode.\n\nSigned-off-by: Igor Grinberg <grinberg@compulab.co.il>\nSigned-off-by: Eric Miao <eric.y.miao@gmail.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@suse.de>","Igor Grinberg"],["6d1c18d3afe7b182f09402d41f82206544d9c3ff","6cf8da08ebf1f4a1f9d97028ec8f3f45dc6a035f@ti.com","ASoC: davinci: add missing break statement\n\ncommit 82d1d521036eb3f5aae48b847f939d99a44c18bb upstream.\n\nIn davinci_vcif_trigger() function, a break() statement was missing\ncausing the davinci_vcif_stop() function to be called as a fallback\nafter calling davinci_vcif_start().\n\nSigned-off-by: Rajashekhara, Sudhakar <sudhakar.raj@ti.com>\nAcked-by: Liam Girdwood <lrg@ti.com>\nSigned-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@suse.de>","Rajashekhara, Sudhakar"]],"ref":"refs/heads/pf-3.0","size":106,"head":"aed421c173ce44e112b1a694364abcf367ccf697","push_id":38734550}