summaryrefslogtreecommitdiffstats
path: root/drivers
AgeCommit message (Collapse)Author
2013-07-16Thermal: x86_pkg_temp: Limit number of pkg temp zonesSrinivas Pandruvada
Although it is unlikley that physical package id is set to some arbitary number, it is better to prevent in anycase. Since package temp zones use this in thermal zone type and for allocation, added a limit. Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Signed-off-by: Zhang Rui <rui.zhang@intel.com>
2013-07-16uvesafb: Really allow mtrr being 0, as documented and warn()edSylvain 'ythier' Hitier
Fixup for commit "uvesafb: Clean up MTRR code" (63e28a7a5ffce59b645ca9cbcc01e1e8be56bd75) Signed-off-by: Sylvain "ythier" Hitier <sylvain.hitier@gmail.com> Acked-by: Andy Lutomirski <luto@amacapital.net> Also-spotted-by: Torsten Kaiser <just.for.lkml@googlemail.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
2013-07-16Merge branch 'drm-fixes-3.11' of git://people.freedesktop.org/~agd5f/linuxDave Airlie
More DPM fixes, r6xx DMA fix for bo moving, UVD fixes, one major regression fix on bootup on some machine (ttm backoff missing) * 'drm-fixes-3.11' of git://people.freedesktop.org/~agd5f/linux: radeon kms: do not flush uninitialized hotplug work drm/radeon/dpm/sumo: handle boost states properly when forcing a perf level drm/radeon: align VM PTBs (Page Table Blocks) to 32K drm/radeon: allow selection of alignment in the sub-allocator drm/radeon: never unpin UVD bo v3 drm/radeon: fix UVD fence emit drm/radeon: add fault decode function for CIK drm/radeon: add fault decode function for SI (v2) drm/radeon: add fault decode function for cayman/TN (v2) drm/radeon: use radeon device for request firmware drm/radeon: add missing ttm_eu_backoff_reservation to radeon_bo_list_validate drm/radeon: use CP DMA on r6xx for bo moves drm/radeon: implement bo copy callback using CP DMA (v2) drm/radeon: Disable dma rings for bo moves on r6xx drm/radeon/dpm: disable gfx PG on PALM drm/radeon/hdmi: make sure we have an afmt block assigned
2013-07-15Merge tag 'regmap-v3.11-rc1' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap Pull regmap fix from Mark Brown: "Fix regmap crash for async operation on busless maps This fixes a crash if something tries to do an asynchronous operation on busless maps which was introduced during the merge window" * tag 'regmap-v3.11-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap: regmap: cache: bail in regmap_async_complete() for bus-less maps
2013-07-15staging: line6: Fix unlocked snd_pcm_stop() callTakashi Iwai
snd_pcm_stop() must be called in the PCM substream lock context. Cc: <stable@vger.kernel.org> Signed-off-by: Takashi Iwai <tiwai@suse.de>
2013-07-15[media] saa7134: Fix unlocked snd_pcm_stop() callTakashi Iwai
snd_pcm_stop() must be called in the PCM substream lock context. Cc: <stable@vger.kernel.org> Signed-off-by: Takashi Iwai <tiwai@suse.de>
2013-07-15radeon kms: do not flush uninitialized hotplug workSergey Senozhatsky
Fix a warning from lockdep caused by calling flush_work() for uninitialized hotplug work. Initialize hotplug_work, audio_work and reset_work upon successful radeon_irq_kms_init() completion and thus perform hotplug flush_work only when rdev->irq.installed is true. [ 4.790019] [drm] Loading CEDAR Microcode [ 4.790943] r600_cp: Failed to load firmware "radeon/CEDAR_smc.bin" [ 4.791152] [drm:evergreen_startup] *ERROR* Failed to load firmware! [ 4.791330] radeon 0000:01:00.0: disabling GPU acceleration [ 4.792633] INFO: trying to register non-static key. [ 4.792792] the code is fine but needs lockdep annotation. [ 4.792953] turning off the locking correctness validator. [ 4.793114] CPU: 2 PID: 1 Comm: swapper/0 Not tainted 3.11.0-rc0-dbg-10676-gfe56456-dirty #1816 [ 4.793314] Hardware name: Acer Aspire 5741G /Aspire 5741G , BIOS V1.20 02/08/2011 [ 4.793507] ffffffff821fd810 ffff8801530b9a18 ffffffff8160434e 0000000000000002 [ 4.794155] ffff8801530b9ad8 ffffffff810b8404 ffff8801530b0798 ffff8801530b0000 [ 4.794789] ffff8801530b9b00 0000000000000046 00000000000004c0 ffffffff00000000 [ 4.795418] Call Trace: [ 4.795573] [<ffffffff8160434e>] dump_stack+0x4e/0x82 [ 4.795731] [<ffffffff810b8404>] __lock_acquire+0x1a64/0x1d30 [ 4.795893] [<ffffffff814a87f0>] ? dev_vprintk_emit+0x50/0x60 [ 4.796034] [<ffffffff810b8fb4>] lock_acquire+0xa4/0x200 [ 4.796216] [<ffffffff8106cd75>] ? flush_work+0x5/0x280 [ 4.796375] [<ffffffff8106cdad>] flush_work+0x3d/0x280 [ 4.796520] [<ffffffff8106cd75>] ? flush_work+0x5/0x280 [ 4.796682] [<ffffffff810b659d>] ? trace_hardirqs_on_caller+0xfd/0x1c0 [ 4.796862] [<ffffffff8131d775>] ? delay_tsc+0x95/0xf0 [ 4.797024] [<ffffffff8141bb8b>] radeon_irq_kms_fini+0x2b/0x70 [ 4.797186] [<ffffffff814557c9>] evergreen_init+0x2a9/0x2e0 [ 4.797347] [<ffffffff813ebb1f>] radeon_device_init+0x5ef/0x700 [ 4.797511] [<ffffffff81335bc7>] ? pci_find_capability+0x47/0x50 [ 4.797672] [<ffffffff813edaed>] radeon_driver_load_kms+0x8d/0x150 [ 4.797843] [<ffffffff813ce426>] drm_get_pci_dev+0x166/0x280 [ 4.798007] [<ffffffff8116cff5>] ? kfree+0xf5/0x2e0 [ 4.798168] [<ffffffff813ea298>] ? radeon_pci_probe+0x98/0xd0 [ 4.798329] [<ffffffff813ea2aa>] radeon_pci_probe+0xaa/0xd0 [ 4.798489] [<ffffffff81339404>] pci_device_probe+0x84/0xe0 [ 4.798644] [<ffffffff814ac7d6>] driver_probe_device+0x76/0x240 [ 4.798805] [<ffffffff814aca73>] __driver_attach+0x93/0xa0 [ 4.798948] [<ffffffff814ac9e0>] ? __device_attach+0x40/0x40 [ 4.799126] [<ffffffff814aa82b>] bus_for_each_dev+0x6b/0xb0 [ 4.799272] [<ffffffff814ac2be>] driver_attach+0x1e/0x20 [ 4.799434] [<ffffffff814abec0>] bus_add_driver+0x1f0/0x280 [ 4.799596] [<ffffffff814ad0e4>] driver_register+0x74/0x150 [ 4.799758] [<ffffffff8133923d>] __pci_register_driver+0x5d/0x60 [ 4.799936] [<ffffffff81d16efc>] ? ttm_init+0x67/0x67 [ 4.800081] [<ffffffff813ce655>] drm_pci_init+0x115/0x130 [ 4.800243] [<ffffffff81d16efc>] ? ttm_init+0x67/0x67 [ 4.800405] [<ffffffff81d16f98>] radeon_init+0x9c/0xba [ 4.800586] [<ffffffff810002ca>] do_one_initcall+0xfa/0x150 [ 4.800746] [<ffffffff81073f60>] ? parse_args+0x120/0x330 [ 4.800909] [<ffffffff81cdafae>] kernel_init_freeable+0x111/0x191 [ 4.801052] [<ffffffff81cda87a>] ? do_early_param+0x88/0x88 [ 4.801233] [<ffffffff815fb670>] ? rest_init+0x140/0x140 [ 4.801393] [<ffffffff815fb67e>] kernel_init+0xe/0x180 [ 4.801556] [<ffffffff8160dcac>] ret_from_fork+0x7c/0xb0 [ 4.801718] [<ffffffff815fb670>] ? rest_init+0x140/0x140 Signed-off-by: Sergey Senozhatsky <sergey.senozhatsky@gmail.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
2013-07-15drm/radeon/dpm/sumo: handle boost states properly when forcing a perf levelAlex Deucher
Need to properly enable/disable boost states when forcing a performance level. Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2013-07-15drm/radeon: align VM PTBs (Page Table Blocks) to 32KAlex Deucher
Covers requirements of all current asics. Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
2013-07-15Merge remote-tracking branch 'spi/fix/xilinx' into spi-linusMark Brown
2013-07-15Merge remote-tracking branch 'spi/fix/setup' into spi-linusMark Brown
2013-07-15Merge remote-tracking branch 'spi/fix/s3c64xx' into spi-linusMark Brown
2013-07-15usb: phy: omap-usb3: fix dpll clock indexRuchika Kharwar
Correction of the omap_usb3_dpll_params array when the sys_clk_rate is 20MHz. Signed-off-by: Nikhil Devshatwar <nikhil.nd@ti.com> Signed-off-by: Ruchika Kharwar <ruchika@ti.com> Signed-off-by: Felipe Balbi <balbi@ti.com>
2013-07-15usb: phy: samsung: Fix an error message typoSachin Kamat
The error message is common to both clk_get functions. Update it accordingly. Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org> Signed-off-by: Felipe Balbi <balbi@ti.com>
2013-07-15usb: gadget: don't fail when DMA isn't presentAlan Stern
When CONFIG_HAS_DMA isn't enabled, the UDC core gets build errors: drivers/built-in.o: In function `dma_set_coherent_mask': include/linux/dma-mapping.h:93: undefined reference to `dma_supported' include/linux/dma-mapping.h:93: undefined reference to `dma_supported' drivers/built-in.o: In function `usb_gadget_unmap_request': drivers/usb/gadget/udc-core.c:91: undefined reference to `dma_unmap_sg' drivers/usb/gadget/udc-core.c:96: undefined reference to `dma_unmap_single' drivers/built-in.o: In function `usb_gadget_map_request': drivers/usb/gadget/udc-core.c:62: undefined reference to `dma_map_sg' drivers/usb/gadget/udc-core.c:71: undefined reference to `dma_map_single' drivers/usb/gadget/udc-core.c:74: undefined reference to `dma_mapping_error' Prevent this by protecting the DMA API routines with preprocessor tests. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> CC: Geert Uytterhoeven <geert@linux-m68k.org> Acked-by: Alexander Shishkin <alexander.shishkin@linux.intel.com> Signed-off-by: Felipe Balbi <balbi@ti.com>
2013-07-15usb: gadget: USB_MV_U3D should depend on HAS_DMAGeert Uytterhoeven
If NO_DMA=y: drivers/built-in.o: In function `mv_u3d_done': drivers/usb/gadget/mv_u3d_core.c:206: undefined reference to `dma_pool_free' drivers/usb/gadget/mv_u3d_core.c:209: undefined reference to `dma_unmap_single' drivers/built-in.o: In function `mv_u3d_build_trb_one': drivers/usb/gadget/mv_u3d_core.c:311: undefined reference to `dma_pool_alloc' drivers/built-in.o: In function `mv_u3d_req_to_trb': drivers/usb/gadget/mv_u3d_core.c:480: undefined reference to `dma_map_single' drivers/built-in.o: In function `mv_u3d_remove': drivers/usb/gadget/mv_u3d_core.c:1770: undefined reference to `dma_pool_destroy' drivers/usb/gadget/mv_u3d_core.c:1773: undefined reference to `dma_free_coherent' drivers/built-in.o: In function `mv_u3d_probe': drivers/usb/gadget/mv_u3d_core.c:1880: undefined reference to `dma_alloc_coherent' drivers/usb/gadget/mv_u3d_core.c:1890: undefined reference to `dma_pool_create' drivers/usb/gadget/mv_u3d_core.c:1984: undefined reference to `dma_pool_destroy' drivers/usb/gadget/mv_u3d_core.c:1986: undefined reference to `dma_free_coherent' Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by: Felipe Balbi <balbi@ti.com>
2013-07-15usb: gadget: USB_FOTG210_UDC should depend on HAS_DMAGeert Uytterhoeven
If NO_DMA=y: drivers/built-in.o: In function `fotg210_start_dma': drivers/usb/gadget/fotg210-udc.c:354: undefined reference to `dma_map_single' drivers/usb/gadget/fotg210-udc.c:357: undefined reference to `dma_mapping_error' drivers/usb/gadget/fotg210-udc.c:362: undefined reference to `dma_sync_single_for_cpu' drivers/usb/gadget/fotg210-udc.c:376: undefined reference to `dma_unmap_single' Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by: Felipe Balbi <balbi@ti.com>
2013-07-15usb: gadget: USB_MV_UDC should depend on HAS_DMAGeert Uytterhoeven
If NO_DMA=y: drivers/built-in.o: In function `done': drivers/usb/gadget/mv_udc_core.c:239: undefined reference to `dma_pool_free' drivers/built-in.o: In function `build_dtd': drivers/usb/gadget/mv_udc_core.c:371: undefined reference to `dma_pool_alloc' drivers/built-in.o: In function `udc_prime_status': drivers/usb/gadget/mv_udc_core.c:1465: undefined reference to `dma_map_single' drivers/built-in.o: In function `mv_udc_remove': drivers/usb/gadget/mv_udc_core.c:2087: undefined reference to `dma_pool_destroy' drivers/usb/gadget/mv_udc_core.c:2090: undefined reference to `dma_free_coherent' drivers/built-in.o: In function `mv_udc_probe': drivers/usb/gadget/mv_udc_core.c:2190: undefined reference to `dma_alloc_coherent' drivers/usb/gadget/mv_udc_core.c:2201: undefined reference to `dma_pool_create' drivers/usb/gadget/mv_udc_core.c:2315: undefined reference to `dma_pool_destroy' drivers/usb/gadget/mv_udc_core.c:2317: undefined reference to `dma_free_coherent' Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by: Felipe Balbi <balbi@ti.com>
2013-07-15usb: dwc3: USB_DWC3 should depend on HAS_DMAGeert Uytterhoeven
If NO_DMA=y: drivers/built-in.o: In function `dwc3_free_one_event_buffer': drivers/usb/dwc3/core.c:132: undefined reference to `dma_free_coherent' drivers/built-in.o: In function `dwc3_alloc_one_event_buffer': drivers/usb/dwc3/core.c:154: undefined reference to `dma_alloc_coherent' drivers/built-in.o: In function `dma_set_coherent_mask': include/linux/dma-mapping.h:93: undefined reference to `dma_supported' drivers/built-in.o: In function `dwc3_free_trb_pool': drivers/usb/dwc3/gadget.c:407: undefined reference to `dma_free_coherent' drivers/built-in.o: In function `dwc3_gadget_exit': drivers/usb/dwc3/gadget.c:2693: undefined reference to `dma_free_coherent' drivers/built-in.o: In function `dwc3_alloc_trb_pool': drivers/usb/dwc3/gadget.c:391: undefined reference to `dma_alloc_coherent' drivers/built-in.o: In function `dwc3_gadget_init': drivers/usb/dwc3/gadget.c:2598: undefined reference to `dma_alloc_coherent' drivers/usb/dwc3/gadget.c:2667: undefined reference to `dma_free_coherent' drivers/usb/dwc3/gadget.c:2674: undefined reference to `dma_free_coherent' drivers/usb/dwc3/gadget.c:2678: undefined reference to `dma_free_coherent' Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by: Felipe Balbi <balbi@ti.com>
2013-07-15usb: gadget: Kconfig: Fix configfs-based RNDIS function buildAndrzej Pietrasiewicz
USB_CONFIGFS_RNDIS depends on USB_U_RNDIS. Select it. Acked-by: Michal Nazarewicz <mina86@mina86.com> Reported-by: Fengguang Wu <fengguang.wu@intel.com> Signed-off-by: Andrzej Pietrasiewicz <andrzej.p@samsung.com> Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com> Signed-off-by: Felipe Balbi <balbi@ti.com>
2013-07-15usb: renesas_usbhs: gadget: remove extra check on udc_stopKuninori Morimoto
usb_gadget_ops :: udc_stop might be called with driver = NULL since 511f3c5326eabe1ece35202a404c24c0aeacc246 (usb: gadget: udc-core: fix a regression during gadget driver unbinding) Because of that, 2nd times insmod goes fail. This patch fixes it up. Reported-by: Yusuke Goda <yusuke.goda.sx@renesas.com> Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Signed-off-by: Felipe Balbi <balbi@ti.com>
2013-07-15usb: gadget: mv_u3d_core: fix to pass correct device identity to free_irq()Wei Yongjun
free_irq() expects the same device identity that was passed to corresponding request_irq(), otherwise the IRQ is not freed. Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn> Signed-off-by: Felipe Balbi <balbi@ti.com>
2013-07-15usb: dwc3: fix the error returned with usb3_phy failureRuchika Kharwar
When there is an error with the usb3_phy probe or absence, the error returned is erroneously for usb2_phy. Cc: <stable@vger.kernel.org> Signed-off-by: Ruchika Kharwar <ruchika@ti.com> Signed-off-by: Felipe Balbi <balbi@ti.com>
2013-07-15usb: dwc3: fix wrong bit mask in dwc3_event_typeHuang Rui
Per dwc3 2.50a spec, the is_devspec bit is used to distinguish the Device Endpoint-Specific Event or Device-Specific Event (DEVT). If the bit is 1, the event is represented Device-Specific Event, then use [7:1] bits as Device Specific Event to marked the type. It has 7 bits, and we can see the reserved8_31 variable name which means from 8 to 31 bits marked reserved, actually there are 24 bits not 25 bits between that. And 1 + 7 + 24 = 32, the event size is 4 byes. So in dwc3_event_type, the bit mask should be: is_devspec [0] 1 bit type [7:1] 7 bits reserved8_31 [31:8] 24 bits This patch should be backported to kernels as old as 3.2, that contain the commit 72246da40f3719af3bfd104a2365b32537c27d83 "usb: Introduce DesignWare USB3 DRD Driver". Cc: <stable@vger.kernel.org> Signed-off-by: Huang Rui <ray.huang@amd.com> Signed-off-by: Felipe Balbi <balbi@ti.com>
2013-07-15usb: gadget: at91_udc: prepare clk before calling enableBoris BREZILLON
Replace clk_enable/disable with clk_prepare_enable/disable_unprepare to avoid common clk framework warnings. Signed-off-by: Boris BREZILLON <b.brezillon@overkiz.com> Signed-off-by: Felipe Balbi <balbi@ti.com>
2013-07-15usb: gadget: fotg210-udc: remove __init and __exitYuan-Hsin Chen
Remove __init and __exit from probe() and remove() and would also fix the section mismatch issue. Signed-off-by: Yuan-Hsin Chen <yhchen@faraday-tech.com> Signed-off-by: Felipe Balbi <balbi@ti.com>
2013-07-15usb: gadget: at91_udc: call at91udc_of_init only when neededArnd Bergmann
This avoids a build error in at91sam9261_9g10_defconfig: drivers/usb/gadget/at91_udc.c: In function 'at91udc_probe': drivers/usb/gadget/at91_udc.c:1685:34: warning: 'flags' may be used uninitialized in this function [-Wmaybe-uninitialized] board->vbus_active_low = (flags & OF_GPIO_ACTIVE_LOW) ? 1 : 0; ^ drivers/usb/gadget/at91_udc.c:1678:21: note: 'flags' was declared here enum of_gpio_flags flags; ^ Making the call to at91udc_of_init conditinal also reduces the object code size without sacrificing build coverage. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Cc: Felipe Balbi <balbi@ti.com> Cc: Nicolas Ferre <nicolas.ferre@atmel.com> Signed-off-by: Felipe Balbi <balbi@ti.com>
2013-07-15usb: dwc3: gadget: don't prevent gadget from being probed if we failFelipe Balbi
In case we fail our ->udc_start() callback, we should be ready to accept another modprobe following the failed one. We had forgotten to clear dwc->gadget_driver back to NULL and, because of that, we were preventing gadget driver modprobe from being retried. Cc: <stable@vger.kernel.org> Signed-off-by: Felipe Balbi <balbi@ti.com>
2013-07-15Thermal: x86_pkg_temp: fix krealloc() misuse in in pkg_temp_thermal_device_add()Wei Yongjun
If krealloc() returns NULL, it doesn't free the original. So any code of the form 'foo = krealloc(foo, ...);' is almost certainly a bug. Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn> Signed-off-by: Zhang Rui <rui.zhang@intel.com>
2013-07-15Thermal: x86 package temp thermal crashSrinivas Pandruvada
On systems with no package MSR support this caused crash as there is a bug in the logic to check presence of DTHERM and PTS feature together. Added a change so that when there is no PTS support, module doesn't get loaded. Even if some CPU comes online with the PTS feature disabled, and other CPUs has this support, this patch will still prevent such MSR accesses. Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Reported-by: Daniel Walker <dwalker@fifo99.com> Signed-off-by: Zhang Rui <rui.zhang@intel.com>
2013-07-14drivers: delete __cpuinit usage from all remaining drivers filesPaul Gortmaker
The __cpuinit type of throwaway sections might have made sense some time ago when RAM was more constrained, but now the savings do not offset the cost and complications. For example, the fix in commit 5e427ec2d0 ("x86: Fix bit corruption at CPU resume time") is a good example of the nasty type of bugs that can be created with improper use of the various __init prefixes. After a discussion on LKML[1] it was decided that cpuinit should go the way of devinit and be phased out. Once all the users are gone, we can then finally remove the macros themselves from linux/init.h. This removes all the remaining one-off uses of the __cpuinit macros from all C files in the drivers/* directory. [1] https://lkml.org/lkml/2013/5/20/589 Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
2013-07-14acpi: delete __cpuinit usage from all acpi filesPaul Gortmaker
The __cpuinit type of throwaway sections might have made sense some time ago when RAM was more constrained, but now the savings do not offset the cost and complications. For example, the fix in commit 5e427ec2d0 ("x86: Fix bit corruption at CPU resume time") is a good example of the nasty type of bugs that can be created with improper use of the various __init prefixes. After a discussion on LKML[1] it was decided that cpuinit should go the way of devinit and be phased out. Once all the users are gone, we can then finally remove the macros themselves from linux/init.h. This removes all the drivers/acpi uses of the __cpuinit macros from all C files. [1] https://lkml.org/lkml/2013/5/20/589 Cc: Len Brown <lenb@kernel.org> Cc: "Rafael J. Wysocki" <rjw@sisk.pl> Cc: linux-acpi@vger.kernel.org Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
2013-07-14hwmon: delete __cpuinit usage from all hwmon filesPaul Gortmaker
The __cpuinit type of throwaway sections might have made sense some time ago when RAM was more constrained, but now the savings do not offset the cost and complications. For example, the fix in commit 5e427ec2d0 ("x86: Fix bit corruption at CPU resume time") is a good example of the nasty type of bugs that can be created with improper use of the various __init prefixes. After a discussion on LKML[1] it was decided that cpuinit should go the way of devinit and be phased out. Once all the users are gone, we can then finally remove the macros themselves from linux/init.h. This removes all the drivers/hwmon uses of the __cpuinit macros from all C files. [1] https://lkml.org/lkml/2013/5/20/589 Cc: Fenghua Yu <fenghua.yu@intel.com> Cc: lm-sensors@lm-sensors.org Acked-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
2013-07-14cpufreq: delete __cpuinit usage from all cpufreq filesPaul Gortmaker
The __cpuinit type of throwaway sections might have made sense some time ago when RAM was more constrained, but now the savings do not offset the cost and complications. For example, the fix in commit 5e427ec2d0 ("x86: Fix bit corruption at CPU resume time") is a good example of the nasty type of bugs that can be created with improper use of the various __init prefixes. After a discussion on LKML[1] it was decided that cpuinit should go the way of devinit and be phased out. Once all the users are gone, we can then finally remove the macros themselves from linux/init.h. This removes all the drivers/cpufreq uses of the __cpuinit macros from all C files. [1] https://lkml.org/lkml/2013/5/20/589 [v2: leave 2nd lines of args misaligned as requested by Viresh] Cc: "Rafael J. Wysocki" <rjw@sisk.pl> Cc: Viresh Kumar <viresh.kumar@linaro.org> Cc: cpufreq@vger.kernel.org Cc: linux-pm@vger.kernel.org Acked-by: Dirk Brandewie <dirk.j.brandewie@intel.com> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
2013-07-14clocksource+irqchip: delete __cpuinit usage from all related filesPaul Gortmaker
The __cpuinit type of throwaway sections might have made sense some time ago when RAM was more constrained, but now the savings do not offset the cost and complications. For example, the fix in commit 5e427ec2d0 ("x86: Fix bit corruption at CPU resume time") is a good example of the nasty type of bugs that can be created with improper use of the various __init prefixes. After a discussion on LKML[1] it was decided that cpuinit should go the way of devinit and be phased out. Once all the users are gone, we can then finally remove the macros themselves from linux/init.h. This removes all the drivers/clocksource and drivers/irqchip uses of the __cpuinit macros from all C files. [1] https://lkml.org/lkml/2013/5/20/589 Cc: John Stultz <john.stultz@linaro.org> Cc: Thomas Gleixner <tglx@linutronix.de> Acked-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
2013-07-15cpufreq: s3c24xx: rename CONFIG_CPU_FREQ_S3C24XX_DEBUGFSPaul Bolle
The Kconfig symbol CPU_FREQ_S3C24XX_DEBUGFS was renamed to ARM_S3C24XX_CPUFREQ_DEBUGFS in commit f023f8dd59 ("cpufreq: s3c24xx: move cpufreq driver to drivers/cpufreq"). But that commit missed one instance of its macro CONFIG_CPU_FREQ_S3C24XX_DEBUGFS. Rename it too. Signed-off-by: Paul Bolle <pebolle@tiscali.nl> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-07-15cpufreq: Revert commit a66b2e to fix suspend/resume regressionSrivatsa S. Bhat
commit a66b2e (cpufreq: Preserve sysfs files across suspend/resume) has unfortunately caused several things in the cpufreq subsystem to break subtly after a suspend/resume cycle. The intention of that patch was to retain the file permissions of the cpufreq related sysfs files across suspend/resume. To achieve that, the commit completely removed the calls to cpufreq_add_dev() and __cpufreq_remove_dev() during suspend/resume transitions. But the problem is that those functions do 2 kinds of things: 1. Low-level initialization/tear-down that are critical to the correct functioning of cpufreq-core. 2. Kobject and sysfs related initialization/teardown. Ideally we should have reorganized the code to cleanly separate these two responsibilities, and skipped only the sysfs related parts during suspend/resume. Since we skipped the entire callbacks instead (which also included some CPU and cpufreq-specific critical components), cpufreq subsystem started behaving erratically after suspend/resume. So revert the commit to fix the regression. We'll revisit and address the original goal of that commit separately, since it involves quite a bit of careful code reorganization and appears to be non-trivial. (While reverting the commit, note that another commit f51e1eb (cpufreq: Fix cpufreq regression after suspend/resume) already reverted part of the original set of changes. So revert only the remaining ones). Signed-off-by: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Tested-by: Paul Bolle <pebolle@tiscali.nl> Cc: 3.10+ <stable@vger.kernel.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-07-15ACPI / memhotplug: Fix a stale pointer in error pathToshi Kani
device->driver_data needs to be cleared when releasing its data, mem_device, in an error path of acpi_memory_device_add(). The function evaluates the _CRS of memory device objects, and fails when it gets an unexpected resource or cannot allocate memory. A kernel crash or data corruption may occur when the kernel accesses the stale pointer. Signed-off-by: Toshi Kani <toshi.kani@hp.com> Reviewed-by: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com> Cc: 2.6.32+ <stable@vger.kernel.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-07-15ACPI / scan: Always call acpi_bus_scan() for bus check notificationsRafael J. Wysocki
An ACPI_NOTIFY_BUS_CHECK notification means that we should scan the entire namespace starting from the given handle even if the device represented by that handle is present (other devices below it may just have appeared). For this reason, modify acpi_scan_bus_device_check() to always run acpi_bus_scan() if the notification being handled is of type ACPI_NOTIFY_BUS_CHECK. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Toshi Kani <toshi.kani@hp.com> Cc: 3.10+ <stable@vger.kernel.org>
2013-07-15ACPI / scan: Do not try to attach scan handlers to devices having themRafael J. Wysocki
In acpi_bus_device_attach(), if there is an ACPI device object for the given handle and that device object has a scan handler attached to it already, there's nothing more to do for that handle. Moreover, if acpi_scan_attach_handler() is called then, it may execute the .attach() callback of the ACPI scan handler already attached to the device object and that may lead to interesting breakage. For this reason, make acpi_bus_device_attach() return success immediately when the handle's device object has a scan handler attached to it. Reported-by: Toshi Kani <toshi.kani@hp.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Toshi Kani <toshi.kani@hp.com> Cc: 3.10+ <stable@vger.kernel.org>
2013-07-14hwmon: (abx500) Staticize abx500_temp_attributesSachin Kamat
abx500_temp_attributes is used only in this file. Make it static. Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2013-07-14Linux 3.11-rc1v3.11-rc1Linus Torvalds
2013-07-14drm/radeon: allow selection of alignment in the sub-allocatorAlex Deucher
There are cases where we need more than 4k alignment. No functional change with this commit. Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
2013-07-14drm/radeon: never unpin UVD bo v3Christian König
Changing the UVD BOs offset on suspend/resume doesn't work because the VCPU internally keeps pointers to it. Just keep it always pinned and save the content manually. Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=66425 v2: fix compiler warning v3: fix CIK support Note: a version of this patch needs to go to stable. Signed-off-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2013-07-14drm/radeon: fix UVD fence emitChristian König
Currently doesn't matter cause we allocate the fence in the lower 265MB anyway. Reported-by: Frank Huang <FrankR.Huang@amd.com> Signed-off-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
2013-07-14drm/radeon: add fault decode function for CIKAlex Deucher
Helpful for debugging GPUVM errors as we can see what hw block and page generated the fault in the log. Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2013-07-14drm/radeon: add fault decode function for SI (v2)Alex Deucher
Helpful for debugging GPUVM errors as we can see what hw block and page generated the fault in the log. v2: simplify fault decoding Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com>
2013-07-14drm/radeon: add fault decode function for cayman/TN (v2)Alex Deucher
Helpful for debugging GPUVM errors as we can see what hw block and page generated the fault in the log. v2: simplify fault decoding Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com>
2013-07-14drm/radeon: use radeon device for request firmwareJerome Glisse
Avoid creating temporary platform device that will lead to issue when several radeon gpu are in same computer. Instead directly use the radeon device for requesting firmware. Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Jerome Glisse <jglisse@redhat.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2013-07-14drm/radeon: add missing ttm_eu_backoff_reservation to radeon_bo_list_validateMaarten Lankhorst
Op 10-07-13 12:03, Markus Trippelsdorf schreef: > On 2013.07.10 at 11:56 +0200, Maarten Lankhorst wrote: >> Op 10-07-13 11:46, Markus Trippelsdorf schreef: >>> On 2013.07.10 at 11:29 +0200, Maarten Lankhorst wrote: >>>> Op 10-07-13 11:22, Markus Trippelsdorf schreef: >>>>> By simply copy/pasting a big document under LibreOffice my system hangs >>>>> itself up. Only a hard reset gets it working again. >>>>> see also: https://bugs.freedesktop.org/show_bug.cgi?id=66551 >>>>> >>>>> I've bisected the issue to: >>>>> >>>>> commit ecff665f5e3f1c6909353e00b9420e45ae23d995 >>>>> Author: Maarten Lankhorst <m.b.lankhorst@gmail.com> >>>>> Date: Thu Jun 27 13:48:17 2013 +0200 >>>>> >>>>> drm/ttm: make ttm reservation calls behave like reservation calls >>>>> >>>>> This commit converts the source of the val_seq counter to >>>>> the ww_mutex api. The reservation objects are converted later, >>>>> because there is still a lockdep splat in nouveau that has to >>>>> resolved first. >>>>> >>>>> Signed-off-by: Maarten Lankhorst <maarten.lankhorst@canonical.com> >>>>> Reviewed-by: Jerome Glisse <jglisse@redhat.com> >>>>> Signed-off-by: Dave Airlie <airlied@redhat.com> >>>> Hey, >>>> >>>> Can you try current head with CONFIG_PROVE_LOCKING set and post the >>>> lockdep splat from dmesg, if any? If there is any locking issue >>>> lockdep should warn about it. Lockdep will turn itself off after the >>>> first splat, so if the lockdep splat happens before running the >>>> affected parts those will have to be fixed first. >>> There was an unrelated EDAC lockdep splat, so I simply disabled it. >>> >>> This is what I get: >>> >>> Jul 10 11:40:44 x4 kernel: ================================================ >>> Jul 10 11:40:44 x4 kernel: [ BUG: lock held when returning to user space! ] >>> Jul 10 11:40:44 x4 kernel: 3.10.0-08587-g496322b #35 Not tainted >>> Jul 10 11:40:44 x4 kernel: ------------------------------------------------ >>> Jul 10 11:40:44 x4 kernel: X/211 is leaving the kernel with locks still held! >>> Jul 10 11:40:44 x4 kernel: 2 locks held by X/211: >>> Jul 10 11:40:44 x4 kernel: #0: (reservation_ww_class_acquire){+.+.+.}, at: [<ffffffff813279f0>] radeon_bo_list_validate+0x20/0xd0 >>> Jul 10 11:40:44 x4 kernel: #1: (reservation_ww_class_mutex){+.+.+.}, at: [<ffffffff81309306>] ttm_eu_reserve_buffers+0x126/0x4b0 >>> Jul 10 11:40:52 x4 kernel: SysRq : Emergency Sync >>> Jul 10 11:40:53 x4 kernel: Emergency Sync complete >>> >> Thanks, exactly what I thought. I missed a backoff somewhere.. >> >> Does the below patch fix it? > Yes. Thank you for your quick reply. 8<------ If radeon_cs_parser_relocs fails ttm_eu_backoff_reservation doesn't get called. This left open a bug where ttm_eu_reserve_buffers succeeded but the bo's were not unlocked afterwards: Jul 10 11:40:44 x4 kernel: ================================================ Jul 10 11:40:44 x4 kernel: [ BUG: lock held when returning to user space! ] Jul 10 11:40:44 x4 kernel: 3.10.0-08587-g496322b #35 Not tainted Jul 10 11:40:44 x4 kernel: ------------------------------------------------ Jul 10 11:40:44 x4 kernel: X/211 is leaving the kernel with locks still held! Jul 10 11:40:44 x4 kernel: 2 locks held by X/211: Jul 10 11:40:44 x4 kernel: #0: (reservation_ww_class_acquire){+.+.+.}, at: [<ffffffff813279f0>] radeon_bo_list_validate+0x20/0xd0 Jul 10 11:40:44 x4 kernel: #1: (reservation_ww_class_mutex){+.+.+.}, at: [<ffffffff81309306>] ttm_eu_reserve_buffers+0x126/0x4b0 Jul 10 11:40:52 x4 kernel: SysRq : Emergency Sync Jul 10 11:40:53 x4 kernel: Emergency Sync complete This is a regression caused by commit ecff665f5e. "drm/ttm: make ttm reservation calls behave like reservation calls" Reported-by: Markus Trippelsdorf <markus@trippelsdorf.de> Tested-by: Markus Trippelsdorf <markus@trippelsdorf.de> Signed-off-by: Maarten Lankhorst <maarten.lankhorst@canonical.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>