- 12 7月, 2012 7 次提交
-
-
由 Kevin Hilman 提交于
Requesting a threaded interrupt without a primary handler and without IRQF_ONESHOT is dangerous, and after commit 1c6c6952 ("genirq: Reject bogus threaded irq requests"), these requests are rejected. This causes ->probe() to fail, and the RTC driver not to be availble. To fix, add IRQF_ONESHOT to the IRQ flags. Tested on OMAP3730/OveroSTORM and OMAP4430/Panda board using rtcwake to wake from system suspend multiple times. Signed-off-by: NKevin Hilman <khilman@ti.com> Cc: Alessandro Zummo <a.zummo@towertech.it> Cc: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
由 Dan Carpenter 提交于
The code here has a nested spin_lock_irqsave(). It's not needed since IRQs are already disabled and it causes a problem because it means that IRQs won't be enabled again at the end. The second call to spin_lock_irqsave() will overwrite the value of irq_flags and we can't restore the proper settings. Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com> Signed-off-by: NRobin Holt <holt@sgi.com> Cc: Jack Steiner <steiner@sgi.com> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
由 Benoît Thébaudeau 提交于
Fixes WARNING: at irq/handle.c:146 handle_irq_event_percpu+0x19c/0x1b8() irq 25 handler mxc_rtc_interrupt+0x0/0xac enabled interrupts Modules linked in: (unwind_backtrace+0x0/0xf0) from (warn_slowpath_common+0x4c/0x64) (warn_slowpath_common+0x4c/0x64) from (warn_slowpath_fmt+0x30/0x40) (warn_slowpath_fmt+0x30/0x40) from (handle_irq_event_percpu+0x19c/0x1b8) (handle_irq_event_percpu+0x19c/0x1b8) from (handle_irq_event+0x28/0x38) (handle_irq_event+0x28/0x38) from (handle_level_irq+0x80/0xc4) (handle_level_irq+0x80/0xc4) from (generic_handle_irq+0x24/0x38) (generic_handle_irq+0x24/0x38) from (handle_IRQ+0x30/0x84) (handle_IRQ+0x30/0x84) from (avic_handle_irq+0x2c/0x4c) (avic_handle_irq+0x2c/0x4c) from (__irq_svc+0x40/0x60) Exception stack(0xc050bf60 to 0xc050bfa8) bf60: 00000001 00000000 003c4208 c0018e20 c050a000 c050a000 c054a4c8 c050a000 bf80: c05157a8 4117b363 80503bb4 00000000 01000000 c050bfa8 c0018e2c c000e808 bfa0: 60000013 ffffffff (__irq_svc+0x40/0x60) from (default_idle+0x1c/0x30) (default_idle+0x1c/0x30) from (cpu_idle+0x68/0xa8) (cpu_idle+0x68/0xa8) from (start_kernel+0x22c/0x26c) Signed-off-by: NBenoît Thébaudeau <benoit.thebaudeau@advansee.com> Cc: Alessandro Zummo <a.zummo@towertech.it> Cc: Sascha Hauer <kernel@pengutronix.de> Acked-by: NUwe Kleine-König <u.kleine-koenig@pengutronix.de> Cc: <stable@vger.kernel.org> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
由 Lee Jones 提交于
Without this patch, if Device Tree is enabled the AB8500 RTC wouldn't get probed at all, as there is no reference to it from platform code. This patch ensures the driver is probed during normal DT start-up. [akpm@linux-foundation.org: checkpatch fixes] Signed-off-by: NLee Jones <lee.jones@linaro.org> Cc: Alessandro Zummo <a.zummo@towertech.it> Acked-by: NLinus Walleij <linus.walleij@linaro.org> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
由 Lee Jones 提交于
This driver's IRQ registration is failing because the kernel now forces IRQs to be ONESHOT if no IRQ handler is passed. Signed-off-by: NLee Jones <lee.jones@linaro.org> Cc: Alessandro Zummo <a.zummo@towertech.it> Cc: <stable@vger.kernel.org> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
由 Devendra Naga 提交于
`config' is freed and is then used in the rtc_device_unregister() call, causing a kernel panic. Signed-off-by: NDevendra Naga <devendra.aaru@gmail.com> Reviewed-by: NViresh Kumar <viresh.linux@gmail.com> Cc: Alessandro Zummo <a.zummo@towertech.it> Cc: <stable@vger.kernel.org> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
由 Javier Martin 提交于
Do not use MX2_CAMERA_SWAP16 and MX2_CAMERA_PACK_DIR_MSB flags. The driver must negotiate with the attached sensor whether the mbus format is UYUV or YUYV and set CSICR1 configuration accordingly. This is needed for the video function on mach-imx27_visstrim_m10.c to perform properly, since an earlier version of this patch has been proven wrong and has been reverted and a commit, depending on it: "[media] i.MX27: visstrim_m10: Remove use of MX2_CAMERA_SWAP16" is in the mainline. Signed-off-by: NJavier Martin <javier.martin@vista-silicon.com> Reviewed-by: NMauro Carvalho Chehab <mchehab@redhat.com> Acked-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com> [ g.liakhovetski@gmx.de: move a macro definition to a more logical place ] Signed-off-by: NGuennadi Liakhovetski <g.liakhovetski@gmx.de> [ Applying directly because Mauro is on vacation - Linus ] Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
- 11 7月, 2012 7 次提交
-
-
由 Guennadi Liakhovetski 提交于
Fix a boot regression on Mackerel boards with sh_mobile_sdhi in existing kernels causing: genirq: Threaded irq requested with handler=NULL and !ONESHOT for irq XXX caused by 1c6c6952 (genirq: Reject bogus threaded irq requests). This is backported from Guennadi's patch: "mmc: extend and rename cd-gpio helpers to handle more slot GPIO functions" Reported-by: NRafael J. Wysocki <rjw@sisk.pl> Signed-off-by: NGuennadi Liakhovetski <g.liakhovetski@gmx.de> Signed-off-by: NChris Ball <cjb@laptop.org>
-
由 Venkatraman S 提交于
This reverts commit 3d93576e(skip card initialization if power class selection fails). Problem has been reported when this is used with eMMC4.41 card with Tegra Platform. Till the issue is root caused, bus width selection failure should not be treated as fatal. Reported-by: NMarc Dietrich <marvin24@gmx.de> Signed-Off-by: NVenkatraman S <svenkatr@ti.com> CC: Ulf Hansson <ulf.hansson@stericsson.com> CC: Subhash Jadavani <subhashj@codeaurora.org> CC: Saugata Das <saugata.das@linaro.org> Signed-off-by: NChris Ball <cjb@laptop.org>
-
由 Jerry Snitselaar 提交于
commit 626f9914 added code to initialize gpio_chip.of_node, but if CONFIG_OF_GPIO is not defined gps-tps65910 fails to build with an error complaining gpio_chip has no member of_node. I ran into this while doing a allyesconfig build on linux-next. Signed-off-by: NGerard Snitselaar <dev@snitselaar.org> Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
-
由 Jonathan Nieder 提交于
This is an old suspend/resume lockup fix: commit 2780cc4660e1 Author: Len Brown <len.brown@intel.com> Date: Thu Dec 23 13:43:30 2004 -0500 [ACPI] Fix suspend/resume lockup issue by leaving Bus Master Arbitration enabled. The ACPI spec mandates it be disabled only for C3. http://bugzilla.kernel.org/show_bug.cgi?id=3599Signed-off-by: NDavid Shaohua Li <shaohua.li@intel.com> Signed-off-by: NLen Brown <len.brown@intel.com> The bug snuck back in in commit 2feec47d (ACPICA: ACPI 5: Support for new FADT SleepStatus, SleepControl registers, 2012-02-14), presumably by copy/pasting a copy of the code without that fix for the legacy case. On affected machines, after that commit, the machine locks up hard on resume from suspend. The same fix as seven years ago still works. Addresses <https://bugzilla.kernel.org/show_bug.cgi?id=43641>. Reported-bisected-and-tested-by: NOctavio Alvarez <alvarezp@alvarezp.com> Reported-by: NAdrian Knoth <adi@drcomp.erfurt.thur.de> Signed-off-by: NJonathan Nieder <jrnieder@gmail.com> Cc: stable@vger.kernel.org Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
-
由 Linus Torvalds 提交于
This reverts commit 107a84e6. Meelis Roos reports a regression since 3.5-rc5 that stops Sun Fire V100 and Sun Netra X1 sparc64 machines from booting, hanging after enabling serial console. He bisected it to commit 107a84e6. Rob Herring explains: "The problem is match combinations of compatible plus name and/or type fail to match correctly. I have a fix for this, but given how late it is for 3.5 I think it is best to revert this for now. There could be other cases that rely on the current although wrong behavior. I will post an updated version for 3.6." Bisected-and-reported-by: NMeelis Roos <mroos@linux.ee> Requested-by: NRob Herring <rob.herring@calxeda.com> Cc: Thierry Reding <thierry.reding@avionic-design.de> Cc: Grant Likely <grant.likely@secretlab.ca> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
由 Tomas Winkler 提交于
when the default irq quick handler is used then IRQF_ONESHOT must be set otherwise the request fails and following error is displayed: mei 0000:00:16.0: irq 48 for MSI/MSI-X genirq: Threaded irq requested with handler=NULL and !ONESHOT for irq 48 mei 0000:00:16.0: request_threaded_irq failed: irq = 48. dpm_run_callback(): pci_pm_resume+0x0/0x140 returns -22 PM: Device 0000:00:16.0 failed to resume async: error -22 Reported-by: NPeter Wu <lekensteyn@gmail.com> Signed-off-by: NTomas Winkler <tomas.winkler@intel.com> Tested-by: NPeter Wu <lekensteyn@gmail.com> Signed-off-by: NRoland Dreier <roland@purestorage.com> Cc: stable <stable@vger.kernel.org> # 3.5 Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Alan Stern 提交于
Quite a few ASUS computers experience a nasty problem, related to the EHCI controllers, when going into system suspend. It was observed that the problem didn't occur if the controllers were not put into the D3 power state before starting the suspend, and commit 151b6128 (USB: EHCI: fix crash during suspend on ASUS computers) was created to do this. It turned out this approach messed up other computers that didn't have the problem -- it prevented USB wakeup from working. Consequently commit c2fb8a3f (USB: add NO_D3_DURING_SLEEP flag and revert 151b6128) was merged; it reverted the earlier commit and added a whitelist of known good board names. Now we know the actual cause of the problem. Thanks to AceLan Kao for tracking it down. According to him, an engineer at ASUS explained that some of their BIOSes contain a bug that was added in an attempt to work around a problem in early versions of Windows. When the computer goes into S3 suspend, the BIOS tries to verify that the EHCI controllers were first quiesced by the OS. Nothing's wrong with this, but the BIOS does it by checking that the PCI COMMAND registers contain 0 without checking the controllers' power state. If the register isn't 0, the BIOS assumes the controller needs to be quiesced and tries to do so. This involves making various MMIO accesses to the controller, which don't work very well if the controller is already in D3. The end result is a system hang or memory corruption. Since the value in the PCI COMMAND register doesn't matter once the controller has been suspended, and since the value will be restored anyway when the controller is resumed, we can work around the BIOS bug simply by setting the register to 0 during system suspend. This patch (as1590) does so and also reverts the second commit mentioned above, which is now unnecessary. In theory we could do this for every PCI device. However to avoid introducing new problems, the patch restricts itself to EHCI host controllers. Finally the affected systems can suspend with USB wakeup working properly. Reference: https://bugzilla.kernel.org/show_bug.cgi?id=37632 Reference: https://bugzilla.kernel.org/show_bug.cgi?id=42728Based-on-patch-by: NAceLan Kao <acelan.kao@canonical.com> Signed-off-by: NAlan Stern <stern@rowland.harvard.edu> Tested-by: NDâniel Fraga <fragabr@gmail.com> Tested-by: NJavier Marcet <jmarcet@gmail.com> Tested-by: NAndrey Rahmatullin <wrar@wrar.name> Tested-by: NOleksij Rempel <bug-track@fisher-privat.net> Tested-by: NPavel Pisa <pisa@cmp.felk.cvut.cz> Cc: stable <stable@vger.kernel.org> Acked-by: NBjorn Helgaas <bhelgaas@google.com> Acked-by: NRafael J. Wysocki <rjw@sisk.pl> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
- 10 7月, 2012 2 次提交
-
-
由 Benjamin Herrenschmidt 提交于
udbg_init_debug_opal() should be udbg_init_debug_opal_raw() as the caller in arch/powerpc/kernel/udbg.c expects Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
-
由 Hans de Goede 提交于
Don't call v4l2_ctrl_g_ctrl on ctrls which the model cam in question does not have. Reported-by: NFrank Schäfer <fschaefer.oss@googlemail.com> Signed-off-by: NHans de Goede <hdegoede@redhat.com> [ Taken directly, since Mauro is on vacation ] Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
- 09 7月, 2012 9 次提交
-
-
由 Michael S. Tsirkin 提交于
Since ee7cd898 'virtio: expose added descriptors immediately.', in virtio balloon virtqueue_get_buf might now run concurrently with virtqueue_kick. I audited both and this seems safe in practice but this is not guaranteed by the API. Additionally, a spurious interrupt might in theory make virtqueue_get_buf run in parallel with virtqueue_add_buf, which is racy. While we might try to protect against spurious callbacks it's easier to fix the driver: balloon seems to be the only one (mis)using the API like this, so let's just fix balloon. Signed-off-by: NMichael S. Tsirkin <mst@redhat.com> Signed-off-by: Rusty Russell <rusty@rustcorp.com.au> (removed unused var)
-
由 Graeme Gregory 提交于
During conversion to regmap_irq this hunk was missing being moved to MFD driver to put the chip into clear on read mode. Also as slave is now set use it to determine which slave for the register call. Signed-off-by: NGraeme Gregory <gg@slimlogic.co.uk> Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>
-
由 Graeme Gregory 提交于
Due to a merge error the section of code passing the pdata for the regulator driver to the mfd_add_devices via the children structure was missing. This corrects this problem. Signed-off-by: NGraeme Gregory <gg@slimlogic.co.uk> Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>
-
由 Russ Dill 提交于
'ARM: OMAP3: USB: Fix the EHCI ULPI PHY reset issue' (1fcb57d0) fixes an issue where the ULPI PHYs were not held in reset while initializing the EHCI controller. However, it also changes behavior in omap-usb-host.c omap_usbhs_init by releasing reset while the configuration in that function was done. This change caused a regression on BB-xM where USB would not function if 'usb start' had been run from u-boot before booting. A change was made to release reset a little bit earlier which fixed the issue on BB-xM and did not cause any regressions on 3430 sdp, the board for which the fix was originally made. This new fix, 'USB: EHCI: OMAP: Finish ehci omap phy reset cycle before adding hcd.', (3aa2ae74) caused a regression on OMAP5. The original fix to hold the EHCI controller in reset during initialization was correct, however it appears that changing omap_usbhs_init to not hold the PHYs in reset during it's configuration was incorrect. This patch first reverts both fixes, and then changes ehci_hcd_omap_probe in ehci-omap.c to hold the PHYs in reset as the original patch had done. It also is sure to incorporate the _cansleep change that has been made in the meantime. I've tested this on Beagleboard xM, I'd really like to get an ack from the 3430 sdp and OMAP5 guys before getting this merged. v3 - Brown paper bag its too early in the morning actually run git commit amend fix v2 - Put cansleep gpiolib call outside of spinlock Acked-by: NMantesh Sarashetti <mantesh@ti.com> Tested-by: NMantesh Sarashetti <mantesh@ti.com> Acked-by: NKeshava Munegowda <keshava_mgowda@ti.com> Tested-by: NKeshava Munegowda <keshava_mgowda@ti.com> Signed-off-by: NRuss Dill <Russ.Dill@gmail.com> Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>
-
由 Peter Ujfalusi 提交于
twl6040 needs CONFIG_IRQ_DOMAIN to compile, without this we have: drivers/mfd/twl6040-irq.c: In function 'twl6040_irq_init': drivers/mfd/twl6040-irq.c:164:2: error: implicit declaration of function 'irq_domain_add_legacy' drivers/mfd/twl6040-irq.c:165:11: error: 'irq_domain_simple_ops' undeclared (first use in this function) drivers/mfd/twl6040-irq.c:165:11: note: each undeclared identifier is reported only once for each function it appears in Reported-by: NRandy Dunlap <rdunlap@xenotime.net> Signed-off-by: NPeter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>
-
由 Paul Bolle 提交于
Commit 72fb9220 ("mfd/ab5500: delete AB5500 support") deleted all files that used ab5500-core.h. That file apparently was simply overlooked. Delete it too. Acked-by: NLinus Walleij <linus.walleij@linaro.org> Signed-off-by: NPaul Bolle <pebolle@tiscali.nl> Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>
-
由 Philippe Rétornaz 提交于
The MC13xxx PMIC is mainly used on i.Mx SoC. On those SoC the SPI hardware will deassert CS line as soon as the SPI FIFO is empty. The MC13xxx hardware is very sensitive to CS line change as it corrupts the transfer if CS is deasserted in the middle of a register read or write. It is not possible to use the CS line as a GPIO on some SoC, so we need to workaround this by implementing a single SPI transfer to access the PMIC. Reviewed-by: NMark Brown <broonie@opensource.wolfsonmicro.com> Acked-by: NMarc Reilly <marc@cpdesign.com.au> Signed-off-by: NPhilippe Rétornaz <philippe.retornaz@epfl.ch> Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>
-
由 Philippe Rétornaz 提交于
This fix the SPI regmap configuration, the wrong write flag was used. Also, bits_per_word should not be set as the regmap spi implementation uses a 8bits transfert granularity. Signed-off-by: NPhilippe Rétornaz <philippe.retornaz@epfl.ch> Tested-by: NFabio Estevam <fabio.estevam@freescale.com> Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>
-
由 Axel Lin 提交于
The i2c_device_id table is supposed to be zero-terminated. Signed-off-by: NAxel Lin <axel.lin@gmail.com> Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>
-
- 08 7月, 2012 5 次提交
-
-
由 Tomi Valkeinen 提交于
If runtime PM is not enabled in the kernel config, pm_runtime_get_sync() will always return 1 and pm_runtime_put_sync() will always return -ENOSYS. pm_runtime_get_sync() returning 1 presents no problem to the driver, but -ENOSYS from pm_runtime_put_sync() causes the driver to print a warning. One option would be to ignore errors returned by pm_runtime_put_sync() totally, as they only say that the call was unable to put the hardware into suspend mode. However, I chose to ignore the returned -ENOSYS explicitly, and print a warning for other errors, as I think we should get notified if the HW failed to go to suspend properly. Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com> Cc: Jassi Brar <jaswinder.singh@linaro.org> Cc: Grazvydas Ignotas <notasas@gmail.com> Signed-off-by: NArchit Taneja <archit@ti.com> Signed-off-by: NFlorian Tobias Schandinat <FlorianSchandinat@gmx.de>
-
由 Tomi Valkeinen 提交于
The current way how omapdss handles system suspend and resume is that omapdss device (a platform device, which is not part of the device hierarchy of the DSS HW devices, like DISPC and DSI, or panels.) uses the suspend and resume callbacks from platform_driver to handle system suspend. It does this by disabling all enabled panels on suspend, and resuming the previously disabled panels on resume. This presents a few problems. One is that as omapdss device is not related to the panel devices or the DSS HW devices, there's no ordering in the suspend process. This means that suspend could be first ran for DSS HW devices and panels, and only then for omapdss device. Currently this is not a problem, as DSS HW devices and panels do not handle suspend. Another, more pressing problem, is that when suspending or resuming, the runtime PM functions return -EACCES as runtime PM is disabled during system suspend. This causes the driver to print warnings, and operations to fail as they think that they failed to bring up the HW. This patch changes the omapdss suspend handling to use PM notifiers, which are called before suspend and after resume. This way we have a normally functioning system when we are suspending and resuming the panels. This patch, I believe, creates a problem that somebody could enable or disable a panel between PM_SUSPEND_PREPARE and the system suspend, and similarly the other way around in resume. I choose to ignore the problem for now, as it sounds rather unlikely, and if it happens, it's not fatal. In the long run the system suspend handling of omapdss and panels should be thought out properly. The current approach feels rather hacky. Perhaps the panel drivers should handle system suspend, or the users of omapdss (omapfb, omapdrm) should handle system suspend. Note that after this patch we could probably revert 0eaf9f52 (OMAPDSS: use sync versions of pm_runtime_put). But as I said, this patch may be temporary, so let's leave the sync version still in place. Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com> Reported-by: NJassi Brar <jaswinder.singh@linaro.org> Tested-by: NJassi Brar <jaswinder.singh@linaro.org> Tested-by: NJoe Woodward <jw@terrafix.co.uk> Signed-off-by: NArchit Taneja <archit@ti.com> [fts: fixed 2 brace coding style issues] Signed-off-by: NFlorian Tobias Schandinat <FlorianSchandinat@gmx.de>
-
由 Eddie Wai 提交于
The netdev->base_addr parameter has been deprecated in the L2 bnx2 driver. This is used by bnx2i for the BARn iomapping. This patch will directly reference the pci_resource_start instead of using the deprecated netdev->base_addr. This patch is actually a critical bug fix as the 1G bnx2 driver no longer supports the netdev->base_addr in the current kernel of the scsi tree. This means that Broadcom's 1G Linux iSCSI offload solution would not work at all without this patch. Signed-off-by: NEddie Wai <eddie.wai@broadcom.com> Reviewed-by: NMike Christie <michaelc@cs.wisc.edu> Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>
-
由 Dan Williams 提交于
fill_result_tf() grabs the taskfile flags from the originating qc which sas_ata_qc_fill_rtf() promptly overwrites. The presence of an ata_taskfile in the sata_device makes it tempting to just copy the full contents in sas_ata_qc_fill_rtf(). However, libata really only wants the fis contents and expects the other portions of the taskfile to not be touched by ->qc_fill_rtf. To that end store a fis buffer in the sata_device and use ata_tf_from_fis() like every other ->qc_fill_rtf() implementation. Cc: <stable@vger.kernel.org> Reported-by: NPraveen Murali <pmurali@logicube.com> Tested-by: NPraveen Murali <pmurali@logicube.com> Signed-off-by: NDan Williams <dan.j.williams@intel.com> Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>
-
由 Shinya Kuribayashi 提交于
Commit 300bab97 (hwspinlock/core: register a bank of hwspinlocks in a single API call, 2011-09-06) introduced 'hwspin_lock_register_single()' to register numerous (a bank of) hwspinlock instances in a single API, 'hwspin_lock_register()'. At which time, 'hwspin_lock_register()' accidentally passes 'local IDs' to 'hwspin_lock_register_single()', despite that ..._single() requires 'global IDs' to register hwspinlocks. We have to convert into global IDs by supplying the missing 'base_id'. Cc: stable <stable@vger.kernel.org> Signed-off-by: NShinya Kuribayashi <shinya.kuribayashi.px@renesas.com> [ohad: fix error path of hwspin_lock_register, too] Signed-off-by: NOhad Ben-Cohen <ohad@wizery.com>
-
- 07 7月, 2012 3 次提交
-
-
由 Alan Cox 提交于
Based upon Alan's patch from Coverity scan id 793583, these debug messages in qlt_async_event() should be starting from byte 0, which is always the Asynchronous Event Status Code from the parent switch statement. Also, rename reason_code -> login_code following the language used in 2500 FW spec for Port Database Changed (0x8014) -> Port Database Changed Event Mailbox Register for mailbox[2]. Signed-off-by: NAlan Cox <alan@linux.intel.com> Cc: Chad Dupuis <chad.dupuis@qlogic.com> Cc: Giridhar Malavali <giridhar.malavali@qlogic.com> Signed-off-by: NNicholas Bellinger <nab@linux-iscsi.org>
-
由 Mark Rustad 提交于
Use rcu_dereference_protected to tell rcu that the ft_lport_lock is held during ft_lport_create. This resolved "suspicious RCU usage" warnings when debugging options are turned on. Signed-off-by: NMark Rustad <mark.d.rustad@intel.com> Tested-by: NRoss Brattain <ross.b.brattain@intel.com> Cc: <stable@vger.kernel.org> Signed-off-by: NNicholas Bellinger <nab@linux-iscsi.org>
-
由 Lee Jones 提交于
Sometimes it doesn't make any sense for a node to have an address. In this case device lookup will always be unsuccessful because we currently assume every node will have a reg property. This patch changes the semantics so that the resource address and the lookup address will only be compared if one exists. Things like AUXDATA() rely on of_dev_lookup to return the lookup entry of a particular device in order to do things like apply platform_data to a device. However, this is currently broken for nodes which do not have a reg property, meaning that platform_data can not be passed in those cases. Acked-by: NRob Herring <rob.herring@calxeda.com> Acked-by: NArnd Bergmann <arnd@arndb.de> Signed-off-by: NLee Jones <lee.jones@linaro.org>
-
- 06 7月, 2012 7 次提交
-
-
We don't need to open code the divide function, just use div_u64 that already exists and do the same job. While this is a straightforward clean up, there is more to that, the real motivation for this. While building on a cross compiling environment in armel, using gcc 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5), I was getting the following build error: ERROR: "__aeabi_uldivmod" [drivers/mtd/nand/nandsim.ko] undefined! After investigating with objdump and hand built assembly version generated with the compiler, I narrowed __aeabi_uldivmod as being generated from the divide function. When nandsim.c is built with -fno-inline-functions-called-once, that happens when CONFIG_DEBUG_SECTION_MISMATCH is enabled, the do_div optimization in arch/arm/include/asm/div64.h doesn't work as expected with the open coded divide function: even if the do_div we are using doesn't have a constant divisor, the compiler still includes the else parts of the optimized do_div macro, and translates the divisions there to use __aeabi_uldivmod, instead of only calling __do_div_asm -> __do_div64 and optimizing/removing everything else out. So to reproduce, gcc 4.6 plus CONFIG_DEBUG_SECTION_MISMATCH=y and CONFIG_MTD_NAND_NANDSIM=m should do it, building on armel. After this change, the compiler does the intended thing even with -fno-inline-functions-called-once, and optimizes out as expected the constant handling in the optimized do_div on arm. As this also avoids a build issue, I'm marking for Stable, as I think is applicable for this case. Signed-off-by: NHerton Ronaldo Krzesinski <herton.krzesinski@canonical.com> Cc: stable@vger.kernel.org Acked-by: NNicolas Pitre <nico@linaro.org> Signed-off-by: NArtem Bityutskiy <artem.bityutskiy@linux.intel.com> Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>
-
由 Sascha Hauer 提交于
The gpmi-nand driver uses virt_addr_valid() to check whether a buffer is suitable for dma. If it's not, a driver allocated buffer is used instead. Then after a page read the driver allocated buffer must be copied to the user supplied buffer. This does not happen since commit 7725cc85. This patch fixes the issue. The bug is encountered with UBI which uses a vmalloced buffer for the volume table. Signed-off-by: NSascha Hauer <s.hauer@pengutronix.de> Tested-by: snijsure@grid-net.com Acked-by: NHuang Shijie <b32955@freescale.com> Signed-off-by: NArtem Bityutskiy <artem.bityutskiy@linux.intel.com> Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>
-
由 Sascha Hauer 提交于
The following commit changes the function used to copy from/to the hardware buffer to memcpy_[from|to]io. This does not work since the hardware cannot handle the byte accesses used by these functions. Instead of reverting this patch introduce 32bit correspondents of these functions. | commit 5775ba36ea9c760c2d7e697dac04f2f7fc95aa62 | Author: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> | Date: Tue Apr 24 10:05:22 2012 +0200 | | mtd: mxc_nand: fix several sparse warnings about incorrect address space | | Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> | Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com> Signed-off-by: NSascha Hauer <s.hauer@pengutronix.de> Cc: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: NArtem Bityutskiy <artem.bityutskiy@linux.intel.com> Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>
-
由 Dan Carpenter 提交于
The intent here was clearly to set result to true if the 0x40000000 flag was set. But instead there was a | vs & typo and we always set result to true. Artem: check the spec at wiki.laptop.org/images/5/5c/88ALP01_Datasheet_July_2007.pdf and this fix looks correct. Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com> Cc: stable@vger.kernel.org Signed-off-by: NArtem Bityutskiy <artem.bityutskiy@linux.intel.com> Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>
-
由 Bjørn Mork 提交于
Clear the WDM_READ flag on empty reads to avoid running forever in an infinite tight loop, causing lockups: Jul 1 21:58:11 nemi kernel: [ 3658.898647] qmi_wwan 2-1:1.2: Unexpected error -71 Jul 1 21:58:36 nemi kernel: [ 3684.072021] BUG: soft lockup - CPU#0 stuck for 23s! [qmi.pl:12235] Jul 1 21:58:36 nemi kernel: [ 3684.072212] CPU 0 Jul 1 21:58:36 nemi kernel: [ 3684.072355] Jul 1 21:58:36 nemi kernel: [ 3684.072367] Pid: 12235, comm: qmi.pl Tainted: P O 3.5.0-rc2+ #13 LENOVO 2776LEG/2776LEG Jul 1 21:58:36 nemi kernel: [ 3684.072383] RIP: 0010:[<ffffffffa0635008>] [<ffffffffa0635008>] spin_unlock_irq+0x8/0xc [cdc_wdm] Jul 1 21:58:36 nemi kernel: [ 3684.072388] RSP: 0018:ffff88022dca1e70 EFLAGS: 00000282 Jul 1 21:58:36 nemi kernel: [ 3684.072393] RAX: ffff88022fc3f650 RBX: ffffffff811c56f7 RCX: 00000001000ce8c1 Jul 1 21:58:36 nemi kernel: [ 3684.072398] RDX: 0000000000000010 RSI: 000000000267d810 RDI: ffff88022fc3f650 Jul 1 21:58:36 nemi kernel: [ 3684.072403] RBP: ffff88022dca1eb0 R08: ffffffffa063578e R09: 0000000000000000 Jul 1 21:58:36 nemi kernel: [ 3684.072407] R10: 0000000000000008 R11: 0000000000000246 R12: 0000000000000002 Jul 1 21:58:36 nemi kernel: [ 3684.072412] R13: 0000000000000246 R14: ffffffff00000002 R15: ffff8802281d8c88 Jul 1 21:58:36 nemi kernel: [ 3684.072418] FS: 00007f666a260700(0000) GS:ffff88023bc00000(0000) knlGS:0000000000000000 Jul 1 21:58:36 nemi kernel: [ 3684.072423] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 Jul 1 21:58:36 nemi kernel: [ 3684.072428] CR2: 000000000270d9d8 CR3: 000000022e865000 CR4: 00000000000007f0 Jul 1 21:58:36 nemi kernel: [ 3684.072433] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 Jul 1 21:58:36 nemi kernel: [ 3684.072438] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 Jul 1 21:58:36 nemi kernel: [ 3684.072444] Process qmi.pl (pid: 12235, threadinfo ffff88022dca0000, task ffff88022ff76380) Jul 1 21:58:36 nemi kernel: [ 3684.072448] Stack: Jul 1 21:58:36 nemi kernel: [ 3684.072458] ffffffffa063592e 0000000100020000 ffff88022fc3f650 ffff88022fc3f6a8 Jul 1 21:58:36 nemi kernel: [ 3684.072466] 0000000000000200 0000000100000000 000000000267d810 0000000000000000 Jul 1 21:58:36 nemi kernel: [ 3684.072475] 0000000000000000 ffff880212cfb6d0 0000000000000200 ffff880212cfb6c0 Jul 1 21:58:36 nemi kernel: [ 3684.072479] Call Trace: Jul 1 21:58:36 nemi kernel: [ 3684.072489] [<ffffffffa063592e>] ? wdm_read+0x1a0/0x263 [cdc_wdm] Jul 1 21:58:36 nemi kernel: [ 3684.072500] [<ffffffff8110adb7>] ? vfs_read+0xa1/0xfb Jul 1 21:58:36 nemi kernel: [ 3684.072509] [<ffffffff81040589>] ? alarm_setitimer+0x35/0x64 Jul 1 21:58:36 nemi kernel: [ 3684.072517] [<ffffffff8110aec7>] ? sys_read+0x45/0x6e Jul 1 21:58:36 nemi kernel: [ 3684.072525] [<ffffffff813725f9>] ? system_call_fastpath+0x16/0x1b Jul 1 21:58:36 nemi kernel: [ 3684.072557] Code: <66> 66 90 c3 83 ff ed 89 f8 74 16 7f 06 83 ff a1 75 0a c3 83 ff f4 The WDM_READ flag is normally cleared by wdm_int_callback before resubmitting the read urb, and set by wdm_in_callback when this urb returns with data or an error. But a crashing device may cause both a read error and cancelling all urbs. Make sure that the flag is cleared by wdm_read if the buffer is empty. We don't clear the flag on errors, as there may be pending data in the buffer which should be processed. The flag will instead be cleared on the next wdm_read call. Cc: stable <stable@vger.kernel.org> Signed-off-by: NBjørn Mork <bjorn@mork.no> Acked-by: NOliver Neukum <oneukum@suse.de> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Johan Hovold 提交于
Do not set low_latency flag at open as tty_flip_buffer_push must not be called in IRQ context with low_latency set. Cc: stable@vger.kernel.org Signed-off-by: NJohan Hovold <jhovold@gmail.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Gaosen Zhang 提交于
Signed-off-by: NGaosen Zhang <gaosen.zhang@mediatek.com> Cc: stable <stable@vger.kernel.org> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-