| Age | Commit message (Collapse) | Author |
|---|
|
Also update some commens in the area to make the code easier to read.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Mark Tinguely <tinguely@sgi.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Ben Myers <bpm@sgi.com>
|
|
Results in this assert failure in generic/090:
XFS: Assertion failed: *nmap >= 1, file: fs/xfs/xfs_bmap.c, line: 4363
.....
Call Trace:
[<ffffffff814680db>] xfs_bmapi_read+0x6b/0x370
[<ffffffff814b64b2>] xfs_rtbuf_get+0x42/0x130
[<ffffffff814b6f09>] xfs_rtget_summary+0x89/0x120
[<ffffffff814b7bfe>] xfs_rtallocate_extent_size+0xce/0x340
[<ffffffff814b89f0>] xfs_rtallocate_extent+0x240/0x290
[<ffffffff81462c1a>] xfs_bmap_rtalloc+0x1ba/0x340
[<ffffffff81463a65>] xfs_bmap_alloc+0x35/0x40
[<ffffffff8146f111>] xfs_bmapi_allocate+0xf1/0x350
[<ffffffff8146f9de>] xfs_bmapi_write+0x66e/0xa60
[<ffffffff8144538a>] xfs_iomap_write_direct+0x22a/0x3f0
[<ffffffff8143707b>] __xfs_get_blocks+0x38b/0x5d0
[<ffffffff814372d4>] xfs_get_blocks_direct+0x14/0x20
[<ffffffff811b0081>] do_blockdev_direct_IO+0xf71/0x1eb0
[<ffffffff811b1015>] __blockdev_direct_IO+0x55/0x60
[<ffffffff814355ca>] xfs_vm_direct_IO+0x11a/0x1e0
[<ffffffff8112d617>] generic_file_direct_write+0xd7/0x1b0
[<ffffffff8143e16c>] xfs_file_dio_aio_write+0x13c/0x320
[<ffffffff8143e6f2>] xfs_file_aio_write+0x1c2/0x1d0
[<ffffffff81174a07>] do_sync_write+0xa7/0xe0
[<ffffffff81175288>] vfs_write+0xa8/0x160
[<ffffffff81175702>] sys_pwrite64+0x92/0xb0
[<ffffffff81b68f69>] system_call_fastpath+0x16/0x1b
Signed-off-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Ben Myers <bpm@sgi.com>
|
|
If we try to print to the console device while its decoding is disabled,
the system will hang.
Reported-and-tested-by: Olof Johansson <olof@lixom.net>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Olof Johansson <olof@lixom.net>
|
|
cc: Eric Leblond <eric@regit.org>
Signed-off-by: Fengguang Wu <fengguang.wu@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
Yocto (Built by Poky 7.0) 1.2 root filesystems fail to boot,
at least over nfs, with:
Failed to mount /dev: No such device
Configuring DEVTMPFS fixes it.
Signed-off-by: Kim Phillips <kim.phillips@freescale.com>
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
|
|
run make savedefconfig on fsl defconfigs.
Signed-off-by: Kim Phillips <kim.phillips@freescale.com>
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
|
|
Small platform specific bug fixes for problems found in randconfig builds.
* randconfig/mach:
ARM: ux500: don't select LEDS_GPIO for snowball
ARM: imx: build i.MX6 functions only when needed
ARM: imx: select CPU_FREQ_TABLE when needed
ARM: imx: fix ksz9021rn_phy_fixup
ARM: imx: build pm-imx5 code only when PM is enabled
ARM: omap: allow building omap44xx without SMP
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
|
|
Using 'select' in Kconfig is hard, a platform cannot just
enable a driver without also making sure that its subsystem
is there. Also, there is no actual code dependency between
the platform and the gpio leds driver.
Without this patch, building without LEDS_CLASS esults in:
drivers/built-in.o: In function `create_gpio_led.part.2':
governor_userspace.c:(.devinit.text+0x5a58): undefined reference to `led_classdev_register'
drivers/built-in.o: In function `gpio_led_remove':
governor_userspace.c:(.devexit.text+0x6b8): undefined reference to `led_classdev_unregister'
This reverts 8733f53c6 "ARM: ux500: Kconfig: Compile in leds-gpio
support for Snowball" that introduced the regression and did not
provide a helpful explanation.
In order to leave the GPIO LED code still present in normal
builds, this also enables the symbol in u8500_defconfig, in addition
to the other LED drivers that are already selected there.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: Lee Jones <lee.jones@linaro.org>
|
|
The head-v7.S contains a call to the generic cpu_suspend function,
which is only available when selected by the i.MX6 code. As
pointed out by Shawn Guo, i.MX5 does not actually use any
functions defined in head-v7.S. It is also needed only for
the i.MX6 power management code and for the SMP code, so
we can restrict building this file to situations in which
at least one of those two is present.
Finally, other platforms with a similar file call it headsmp.S,
so we can rename it to the same for consistency.
Without this patch, building imx5 standalone results in:
arch/arm/mach-imx/built-in.o: In function `v7_cpu_resume':
arch/arm/mach-imx/head-v7.S:104: undefined reference to `cpu_resume'
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Shawn Guo <shawn.guo@linaro.org>
Cc: Eric Miao <eric.miao@linaro.org>
Cc: stable@vger.kernel.org
|
|
The i.MX cpufreq implementation uses the CPU_FREQ_TABLE helpers,
so it needs to select that code to be built. This problem has
apparently existed since the i.MX cpufreq code was first merged
in v2.6.37.
Building IMX without CPU_FREQ_TABLE results in:
arch/arm/plat-mxc/built-in.o: In function `mxc_cpufreq_exit':
arch/arm/plat-mxc/cpufreq.c:173: undefined reference to `cpufreq_frequency_table_put_attr'
arch/arm/plat-mxc/built-in.o: In function `mxc_set_target':
arch/arm/plat-mxc/cpufreq.c:84: undefined reference to `cpufreq_frequency_table_target'
arch/arm/plat-mxc/built-in.o: In function `mxc_verify_speed':
arch/arm/plat-mxc/cpufreq.c:65: undefined reference to `cpufreq_frequency_table_verify'
arch/arm/plat-mxc/built-in.o: In function `mxc_cpufreq_init':
arch/arm/plat-mxc/cpufreq.c:154: undefined reference to `cpufreq_frequency_table_cpuinfo'
arch/arm/plat-mxc/cpufreq.c:162: undefined reference to `cpufreq_frequency_table_get_attr'
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Shawn Guo <shawn.guo@linaro.org>
Cc: Sascha Hauer <s.hauer@pengutronix.de>
Cc: Yong Shen <yong.shen@linaro.org>
Cc: stable@vger.kernel.org
|
|
The ksz9021rn_phy_fixup and mx6q_sabrelite functions try to
set up an ethernet phy if they can. They do check whether
phylib is enabled, but unfortunately the functions can only
be called from platform code if phylib is builtin, not
if it is a module
Without this patch, building with a modular phylib results in:
arch/arm/mach-imx/mach-imx6q.c: In function 'imx6q_sabrelite_init':
arch/arm/mach-imx/mach-imx6q.c:120:5: error: 'ksz9021rn_phy_fixup' undeclared (first use in this function)
arch/arm/mach-imx/mach-imx6q.c:120:5: note: each undeclared identifier is reported only once for each function it appears in
The bug was originally reported by Artem Bityutskiy but only
partially fixed in ef441806 "ARM: imx6q: register phy fixup only when
CONFIG_PHYLIB is enabled".
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Shawn Guo <shawn.guo@linaro.org>
Cc: Artem Bityutskiy <dedekind1@gmail.com>
Cc: Sascha Hauer <s.hauer@pengutronix.de>
|
|
This moves the imx5 pm code out of the list of unconditionally
compiled files for imx5, mirroring what we already do for imx6
and how it was done before the code was move from mach-mx5 to
mach-imx in v3.3.
Without this patch, building with CONFIG_PM disabled results in:
arch/arm/mach-imx/pm-imx5.c:202:116: error: redefinition of 'imx51_pm_init'
arch/arm/mach-imx/include/mach-imx/common.h:154:91: note: previous definition of 'imx51_pm_init' was here
arch/arm/mach-imx/pm-imx5.c:209:116: error: redefinition of 'imx53_pm_init'
arch/arm/mach-imx/include/mach-imx/common.h:155:91: note: previous definition of 'imx53_pm_init' was here
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Shawn Guo <shawn.guo@linaro.org>
Cc: Sascha Hauer <s.hauer@pengutronix.de>
Cc: stable@vger.kernel.org
|
|
The new omap4 cpuidle implementation currently requires
ARCH_NEEDS_CPU_IDLE_COUPLED, which only works on SMP.
This patch makes it possible to build a non-SMP kernel
for that platform. This is not normally desired for
end-users but can be useful for testing.
Without this patch, building rand-0y2jSKT results in:
drivers/cpuidle/coupled.c: In function 'cpuidle_coupled_poke':
drivers/cpuidle/coupled.c:317:3: error: implicit declaration of function '__smp_call_function_single' [-Werror=implicit-function-declaration]
It's not clear if this patch is the best solution for
the problem at hand. I have made sure that we can now
build the kernel in all configurations, but that does
not mean it will actually work on an OMAP44xx.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Tested-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Cc: Kevin Hilman <khilman@ti.com>
Cc: Tony Lindgren <tony@atomide.com>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-stericsson into fixes
From Linus Walleij <linus.walleij@linaro.org>:
Here are two audio fixes for the ux500 found by Lee Jones.
* tag 'ux500-fixes-v3.6-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-stericsson:
ARM: ux500: Ensure probing of Audio devices when Device Tree is enabled
ARM: ux500: Fix merge error, no matching driver name for 'snd_soc_u8500'
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung into fixes
From Kukjin Kim <kgene.kim@samsung.com>:
For HDMI, already HDMI support for EXYNOS in mainline kernel is broken
because its configuration moved to platform data but regarding platform
data didn't support yet. And others are for fix warnings.
* 'v3.6-samsung-fixes-1' of git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung:
ARM: EXYNOS: Set HDMI platform data in Origen board
ARM: EXYNOS: Set HDMI platform data in SMDKV310
ARM: SAMSUNG: Add API to set platform data for s5p-tv driver
ARM: SAMSUNG: Set HDMI platform data for Exynos4x12 SoCs
ARM: Samsung: Make uart_save static in pm.c file
ARM: S3C24XX: Fix s3c2410_dma_enqueue parameters
ARM: S3C24XX: Add missing DMACH_DT_PROP
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
|
|
git://git.linaro.org/people/shawnguo/linux-2.6 into fixes
* 'imx/fixes-for-3.6' of git://git.linaro.org/people/shawnguo/linux-2.6:
ARM: dts: imx51-babbage: fix esdhc cd/wp properties
ARM: imx6: spin the cpu until hardware takes it down
ARM i.MX6q: Add virtual 1/3.5 dividers in the LDB clock path
Also updates to Linux 3.6-rc2
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
|
|
There are many reports (including 2 of my machines) that iTCO_wdt watchdog
driver fails to be initialized in 3.5 kernel with error message like:
[ 5.265175] ACPI Warning: 0x00001060-0x0000107f SystemIO conflicts with Region \_SB_.PCI0.LPCB.TCOI 1 (20120320/utaddress-251)
[ 5.265192] ACPI: If an ACPI driver is available for this device, you should use it instead of the native driver
[ 5.265206] lpc_ich: Resource conflict(s) found affecting iTCO_wdt
The root cause the iTCO_wdt driver in 3.4 probes the HW IO resource from
LPC's PCI config space, while in 3.5 kernel it relies on lpc_ich driver
for the probe, which adds a new acpi_check_resource_conflict() check, and
give up the probe if there is any conflict with ACPI.
Fix it by removing all the checks for iTCO_wdt to keep the same behavior as
3.4 kernel.
https://bugzilla.kernel.org/show_bug.cgi?id=44991
Actually the same check could be removed for the gpio-ich in lpc_ich.c,
but I'm not sure if it will cause problems.
Signed-off-by: Feng Tang <feng.tang@intel.com>
Cc: Aaron Sierra <asierra@xes-inc.com>
Cc: Wim Van Sebroeck <wim@iguana.be>
Cc: Len Brown <len.brown@intel.com>
Cc: Bob Moore <robert.moore@intel.com>
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
|
|
When we are finished with return PFNs to the hypervisor, then
populate it back, and also mark the E820 MMIO and E820 gaps
as IDENTITY_FRAMEs, we then call P2M to set areas that can
be used for ballooning. We were off by one, and ended up
over-writting a P2M entry that most likely was an IDENTITY_FRAME.
For example:
1-1 mapping on 40000->40200
1-1 mapping on bc558->bc5ac
1-1 mapping on bc5b4->bc8c5
1-1 mapping on bc8c6->bcb7c
1-1 mapping on bcd00->100000
Released 614 pages of unused memory
Set 277889 page(s) to 1-1 mapping
Populating 40200-40466 pfn range: 614 pages added
=> here we set from 40466 up to bc559 P2M tree to be
INVALID_P2M_ENTRY. We should have done it up to bc558.
The end result is that if anybody is trying to construct
a PTE for PFN bc558 they end up with ~PAGE_PRESENT.
CC: stable@vger.kernel.org
Reported-by-and-Tested-by: Andre Przywara <andre.przywara@amd.com>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211
|
|
If the controller has no PCIe module attached, accessing of the device
configuration space causes a data bus error. Avoid this by checking the
status of the PCIe link in advance, and indicate an error if the link
is down.
Signed-off-by: Gabor Juhos <juhosg@openwrt.org>
Cc: stable@vger.kernel.org
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/4293/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
|
|
The binding doc and dts use properties "fsl,{cd,wp}-internal" while
esdhc driver uses "fsl,{cd,wp}-controller". Fix binding doc and dts
to get them match driver code.
Reported-by: Chris Ball <cjb@laptop.org>
Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
Cc: <stable@vger.kernel.org>
Acked-by: Chris Ball <cjb@laptop.org>
|
|
Though commit 602bf40 (ARM: imx6: exit coherency when shutting down
a cpu) improves the stability of imx6q cpu hotplug a lot, there are
still hangs seen with a more stressful hotplug testing.
It's expected that once imx_enable_cpu(cpu, false) is called, the cpu
will be taken down by hardware immediately, and the code after that
will not get any chance to execute. However, this is not always the
case from the testing. The cpu could possibly be alive for a few
cycles before hardware actually takes it down. So rather than letting
cpu execute some code that could cause a hang in these cycles, let's
make the cpu spin there and wait for hardware to take it down.
Cc: <stable@vger.kernel.org>
Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
|
|
Remove the malformed "mem=" bootargs parameter in at91sam9g25ek.dts
Signed-off-by: Bo Shen <voice.shen@atmel.com>
Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
|
|
Fix PLLA overclock warning in relation with datasheet numbers.
Add new > 240 MHz and > 210 MHz SoC categories.
Reported-by: Jiri Prchal <jiri.prchal@aksignal.cz>
Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
|
|
AT91_ID_SYS as virq is incorrect because of spare irq support which
introduces NR_IRQS_LEGACY offset. It modifies rtc-at91sam9 driver in
order to get irq from resources.
Signed-off-by: Ludovic Desroches <ludovic.desroches@atmel.com>
Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
|
|
AT91_ID_SYS as virq is incorrect because of spare irq support which
introduces NR_IRQS_LEGACY offset.
Signed-off-by: Ludovic Desroches <ludovic.desroches@atmel.com>
Tested-by: Joachim Eastwood <joachim.eastwood@jotron.com>
Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
|
|
omapfb does not currently set pseudo palette correctly for color depths
above 16bpp, making red text invisible, command like
echo -e '\e[0;31mRED' > /dev/tty1
will display nothing on framebuffer console in 24bpp mode.
This is because temporary variable is declared incorrectly, fix it.
Signed-off-by: Grazvydas Ignotas <notasas@gmail.com>
Cc: stable@vger.kernel.org # v3.x
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Signed-off-by: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
|
|
Commit f476ae9dab3234532d41d36beb4ba7be838fa786 (OMAPDSS: APPLY: Remove
DISPC writes to manager's lcd parameters in interface) broke the SDI
output, as it causes the SDI PLL locking to fail.
LCLK and PCLK divisors are located in shadow registers, and we normally
write them to DISPC registers when enabling the output. However, SDI
uses pck-free as source clock for its PLL, and pck-free is affected by
the divisors. And as we need the PLL before enabling the output, we need
to write the divisors early.
It seems just writing to the DISPC register is enough, and we don't need
to care about the shadow register mechanism for pck-free. The exact
reason for this is unknown.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Reported-by: Aaro Koskinen <aaro.koskinen@iki.fi>
Signed-off-by: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
|
|
Do a sanity check on these before using them as divisors.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Acked-by: Anatolij Gustschin <agust@denx.de>
Signed-off-by: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
|
|
Using kfree to free data allocated with devm_kzalloc causes double frees.
The semantic patch that fixes this problem is as follows:
(http://coccinelle.lip6.fr/)
// <smpl>
@@
expression x;
@@
x = devm_kzalloc(...)
...
?-kfree(x);
// </smpl>
Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr>
Signed-off-by: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
|
|
Switch to kmalloc(,GFP_ATOMIC) in bit_putcs to fix below trace:
[ 9.771812] BUG: sleeping function called from invalid context at /usr/src/linux-git/mm/slub.c:943
[ 9.771814] in_atomic(): 1, irqs_disabled(): 1, pid: 1063, name: mount
[ 9.771818] Pid: 1063, comm: mount Not tainted 3.5.0-jupiter-00003-g8d858b1-dirty #2
[ 9.771819] Call Trace:
[ 9.771838] [<c104f79b>] __might_sleep+0xcb/0xe0
[ 9.771844] [<c10c00d4>] __kmalloc+0xb4/0x1c0
[ 9.771851] [<c1041d4a>] ? queue_work+0x1a/0x30
[ 9.771854] [<c1041dcf>] ? queue_delayed_work+0xf/0x30
[ 9.771862] [<c1205832>] ? bit_putcs+0xf2/0x3e0
[ 9.771865] [<c1041e01>] ? schedule_delayed_work+0x11/0x20
[ 9.771868] [<c1205832>] bit_putcs+0xf2/0x3e0
[ 9.771875] [<c12002b8>] ? get_color.clone.14+0x28/0x100
[ 9.771878] [<c1200d2f>] fbcon_putcs+0x11f/0x130
[ 9.771882] [<c1205740>] ? bit_clear+0xe0/0xe0
[ 9.771885] [<c1200f6d>] fbcon_redraw.clone.21+0x11d/0x160
[ 9.771889] [<c120383d>] fbcon_scroll+0x79d/0xe10
[ 9.771892] [<c12002b8>] ? get_color.clone.14+0x28/0x100
[ 9.771897] [<c124c0b4>] scrup+0x64/0xd0
[ 9.771900] [<c124c22b>] lf+0x2b/0x60
[ 9.771903] [<c124cc95>] vt_console_print+0x1d5/0x2f0
[ 9.771907] [<c124cac0>] ? register_vt_notifier+0x20/0x20
[ 9.771913] [<c102b335>] call_console_drivers.clone.5+0xa5/0xc0
[ 9.771916] [<c102c58e>] console_unlock+0x2fe/0x3c0
[ 9.771920] [<c102ca16>] vprintk_emit+0x2e6/0x300
[ 9.771924] [<c13f01ae>] printk+0x38/0x3a
[ 9.771931] [<c112e8fe>] reiserfs_remount+0x2ae/0x3e0
[ 9.771934] [<c112e650>] ? reiserfs_fill_super+0xb00/0xb00
[ 9.771939] [<c10ca0ab>] do_remount_sb+0xab/0x150
[ 9.771943] [<c1034476>] ? ns_capable+0x46/0x70
[ 9.771948] [<c10e059c>] do_mount+0x20c/0x6b0
[ 9.771955] [<c10a7044>] ? strndup_user+0x34/0x50
[ 9.771958] [<c10e0acc>] sys_mount+0x6c/0xa0
[ 9.771964] [<c13f2557>] sysenter_do_call+0x12/0x26
According to comment in bit_putcs() that kammloc() call only happens
when fbcon is drawing to a monochrome framebuffer (which is my case with
hid-picolcd).
Signed-off-by: Bruno Prémont <bonbons@linux-vserver.org>
Signed-off-by: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
|
|
Signed-off-by: Paul Cercueil <paul@crapouillou.net>
Signed-off-by: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
|
|
Commit 91f68c89d8f3 ("block: fix infinite loop in __getblk_slow")
is not good: a successful call to grow_buffers() cannot guarantee
that the page won't be reclaimed before the immediate next call to
__find_get_block(), which is why there was always a loop there.
Yesterday I got "EXT4-fs error (device loop0): __ext4_get_inode_loc:3595:
inode #19278: block 664: comm cc1: unable to read itable block" on console,
which pointed to this commit.
I've been trying to bisect for weeks, why kbuild-on-ext4-on-loop-on-tmpfs
sometimes fails from a missing header file, under memory pressure on
ppc G5. I've never seen this on x86, and I've never seen it on 3.5-rc7
itself, despite that commit being in there: bisection pointed to an
irrelevant pinctrl merge, but hard to tell when failure takes between
18 minutes and 38 hours (but so far it's happened quicker on 3.6-rc2).
(I've since found such __ext4_get_inode_loc errors in /var/log/messages
from previous weeks: why the message never appeared on console until
yesterday morning is a mystery for another day.)
Revert 91f68c89d8f3, restoring __getblk_slow() to how it was (plus
a checkpatch nitfix). Simplify the interface between grow_buffers()
and grow_dev_page(), and avoid the infinite loop beyond end of device
by instead checking init_page_buffers()'s end_block there (I presume
that's more efficient than a repeated call to blkdev_max_block()),
returning -ENXIO to __getblk_slow() in that case.
And remove akpm's ten-year-old "__getblk() cannot fail ... weird"
comment, but that is worrying: are all users of __getblk() really
now prepared for a NULL bh beyond end of device, or will some oops??
Signed-off-by: Hugh Dickins <hughd@google.com>
Cc: stable@vger.kernel.org # 3.0 3.2 3.4 3.5
Signed-off-by: Jens Axboe <axboe@kernel.dk>
|
|
This is already fixed for ILK and SNB in the below commit but somehow
IVB is missed.
commit ab2f9df10dd955f1fc0a8650e377588c98f1c029
Author: Jesse Barnes <jbarnes@virtuousgeek.org>
Date: Mon Feb 27 12:40:10 2012 -0800
drm/i915: fix color order for BGR formats on SNB
Had the wrong bits and field definitions.
Signed-off-by: Vijay Purushothaman <vijay.a.purushothaman@intel.com>
Reviewed-by: Antti Koskipää <antti.koskipaa@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
Wrong order of parameters passed-in when calling hdmi/adpa
/lvds_pipe_enabled(), 2nd and 3rd parameters are reversed.
This bug was indroduced by
commit 1519b9956eb4b4180fa3f47c73341463cdcfaa37
Author: Keith Packard <keithp@keithp.com>
Date: Sat Aug 6 10:35:34 2011 -0700
drm/i915: Fix PCH port pipe select in CPT disable paths
The reachable tag for this commit is v3.1-rc1-3-g1519b99
Signed-off-by: Anhua Xu <anhua.xu@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=44876
Tested-by: Daniel Schroeder <sec@dschroeder.info>
Cc: stable@vger.kernel.org
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
When IORESOURCE_IRQ_SHAREABLE is set, the irq handler may be called
even if the interupt of the USB module doesn't happen. So, it may
clear the interrupt flags by mistake. This patch fixes it.
Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
|
|
%pm already provides pretty print for mac addresses, let's
use that and drop homebrew mac address printing.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
|
|
usb_gadget_remove_driver() runs through a four-step sequence to shut down
the gadget driver. For the case of a composite gadget + at91 UDC, this
would look like:
udc->driver->disconnect(udc->gadget); // composite_disconnect()
usb_gadget_disconnect(udc->gadget); // at91_pullup(gadget, 0)
udc->driver->unbind(udc->gadget); // composite_unbind()
usb_gadget_udc_stop(udc->gadget, udc->driver); // at91_stop()
The UDC driver can receive SETUP packets from the host up until the
point when usb_gadget_disconnect() returns. On rare occasions, the
gadget driver may see this sequence:
udc->driver->disconnect(udc->gadget); // composite_disconnect()
udc->driver->setup(udc->gadget, &ctrl); // composite_setup()
udc->driver->unbind(udc->gadget); // composite_unbind()
Some gadget drivers, such as composite, assume this will never happen
and crash as a result.
The fix is to quiesce the UDC hardware (via usb_gadget_disconnect)
before running the gadget driver through the disconnect/unbind sequence.
Reviewed-by: Peter Chen <peter.chen@freescale.com>
Signed-off-by: Kevin Cernekee <cernekee@gmail.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
|
|
Acked-by: Michal Nazarewicz <mina86@mina86.com>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
|
|
The timeout values were 1000 and timeout issue occured many times on my
s3c6410 Soc based board (mostly when booting whith USB cable not
connected). This patch increase the values to 10000 to guarantee the
success of reset.
Having set timeout to 10000, I printed the remained timeout values
which could cause timeout issue before this change (tested several
times).
the first timeout value remained:
timeout = 8079
timeout = 8079
timeout = 8078
timeout = 8081
the second timeout value remained:
timeout = 7940
timeout = 7945
timeout = 7940
timeout = 7938
Seeing from above values, I think the value 10000 is big enough.
Signed-off-by: Du, Changbin <changbin.du@gmail.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
|
|
The lockdep hunter mentions a non consistent usage of spin_lock and
spin_lock_irqsafe in the composite_disconnect and usb_function_activate
function:
[ 15.700897] =================================
[ 15.705255] [ INFO: inconsistent lock state ]
[ 15.709617] 3.5.0-rc5+ #413 Not tainted
[ 15.713453] ---------------------------------
[ 15.717812] inconsistent {HARDIRQ-ON-W} -> {IN-HARDIRQ-W} usage.
[ 15.723822] uvc-gadget/116 [HC1[1]:SC0[0]:HE0:SE1] takes:
[ 15.729222] (&(&cdev->lock)->rlock){?.+...}, at: [<7f0049e8>] composite_disconnect+0x2c/0x74 [g_webcam]
[ 15.738797] {HARDIRQ-ON-W} state was registered at:
[ 15.743677] [<8006de3c>] mark_lock+0x148/0x688
[ 15.748325] [<8006ecb0>] __lock_acquire+0x934/0x1b74
[ 15.753481] [<8007047c>] lock_acquire+0x98/0x138
[ 15.758288] [<804c776c>] _raw_spin_lock+0x4c/0x84
[ 15.763188] [<7f006ae4>] usb_function_activate+0x28/0x94 [g_webcam]
[ 15.769652] [<7f00820c>] usb_ep_autoconfig_reset+0x78/0x98 [g_webcam]
[ 15.776287] [<7f0082a4>] uvc_v4l2_open+0x78/0x94 [g_webcam]
[ 15.782054] [<80366a38>] v4l2_open+0x104/0x130
[ 15.786697] [<800efd30>] chrdev_open+0xa0/0x170
[ 15.791423] [<800e9718>] do_dentry_open.isra.13+0x1e8/0x264
[ 15.797186] [<800ea5d4>] nameidata_to_filp+0x58/0x94
[ 15.802340] [<800fa29c>] do_last.isra.31+0x2a0/0x808
[ 15.807497] [<800faa40>] path_openat+0xc8/0x3e8
[ 15.812216] [<800fae90>] do_filp_open+0x3c/0x90
[ 15.816936] [<800ea6fc>] do_sys_open+0xec/0x184
[ 15.821655] [<800ea7c4>] sys_open+0x30/0x34
[ 15.826027] [<8000e5c0>] ret_fast_syscall+0x0/0x48
[ 15.831015] irq event stamp: 6048
[ 15.834330] hardirqs last enabled at (6047): [<804c81b8>] _raw_spin_unlock_irqrestore+0x40/0x54
[ 15.843132] hardirqs last disabled at (6048): [<8000e174>] __irq_svc+0x34/0x60
[ 15.850370] softirqs last enabled at (5940): [<80028380>] __do_softirq+0x188/0x270
[ 15.858043] softirqs last disabled at (5935): [<80028944>] irq_exit+0xa0/0xa8
[ 15.865195]
[ 15.865195] other info that might help us debug this:
[ 15.871724] Possible unsafe locking scenario:
[ 15.871724]
[ 15.877645] CPU0
[ 15.880091] ----
[ 15.882537] lock(&(&cdev->lock)->rlock);
[ 15.886659] <Interrupt>
[ 15.889278] lock(&(&cdev->lock)->rlock);
[ 15.893573]
[ 15.893573] *** DEADLOCK ***
[ 15.893573]
[ 15.899496] no locks held by uvc-gadget/116.
[ 15.903765]
[ 15.903765] stack backtrace:
[ 15.908125] Backtrace:
[ 15.910604] [<80012038>] (dump_backtrace+0x0/0x114) from [<804bf8a4>] (dump_stack+0x20/0x24)
[ 15.919043] r6:dfb8e6f0 r5:dfb8e400 r4:809717ec r3:60000193
[ 15.924766] [<804bf884>] (dump_stack+0x0/0x24) from [<804c0c0c>] (print_usage_bug+0x258/0x2c0)
[ 15.933388] [<804c09b4>] (print_usage_bug+0x0/0x2c0) from [<8006e240>] (mark_lock+0x54c/0x688)
[ 15.942006] [<8006dcf4>] (mark_lock+0x0/0x688) from [<8006edb8>] (__lock_acquire+0xa3c/0x1b74)
[ 15.950625] [<8006e37c>] (__lock_acquire+0x0/0x1b74) from [<8007047c>] (lock_acquire+0x98/0x138)
[ 15.959418] [<800703e4>] (lock_acquire+0x0/0x138) from [<804c78fc>] (_raw_spin_lock_irqsave+0x58/0x94)
[ 15.968736] [<804c78a4>] (_raw_spin_lock_irqsave+0x0/0x94) from [<7f0049e8>] (composite_disconnect+0x2c/0x74 [g_webcam])
[ 15.979605] r7:00000012 r6:df82b0c4 r5:ded755bc r4:ded75580
[ 15.985331] [<7f0049bc>] (composite_disconnect+0x0/0x74 [g_webcam]) from [<8033c170>] (_gadget_stop_activity+0xc4/0x120)
[ 15.996200] r6:df82b0c4 r5:df82b0c8 r4:df82b0d0 r3:7f0049bc
[ 16.001919] [<8033c0ac>] (_gadget_stop_activity+0x0/0x120) from [<8033e390>] (udc_irq+0x724/0xcb8)
[ 16.010877] r6:df82b010 r5:00000000 r4:df82b010 r3:00000000
[ 16.016595] [<8033dc6c>] (udc_irq+0x0/0xcb8) from [<8033baec>] (ci_irq+0x64/0xdc)
[ 16.024086] [<8033ba88>] (ci_irq+0x0/0xdc) from [<80086538>] (handle_irq_event_percpu+0x74/0x298)
[ 16.032958] r5:807fd414 r4:df38fdc0
[ 16.036566] [<800864c4>] (handle_irq_event_percpu+0x0/0x298) from [<800867a8>] (handle_irq_event+0x4c/0x6c)
[ 16.046315] [<8008675c>] (handle_irq_event+0x0/0x6c) from [<80089318>] (handle_level_irq+0xbc/0x11c)
[ 16.055447] r6:def04000 r5:807fd414 r4:807fd3c0 r3:00020000
[ 16.061166] [<8008925c>] (handle_level_irq+0x0/0x11c) from [<80085cc8>] (generic_handle_irq+0x38/0x4c)
[ 16.070472] r5:807f7f64 r4:8081e9f8
[ 16.074082] [<80085c90>] (generic_handle_irq+0x0/0x4c) from [<8000ef98>] (handle_IRQ+0x5c/0xbc)
[ 16.082788] [<8000ef3c>] (handle_IRQ+0x0/0xbc) from [<800085cc>] (tzic_handle_irq+0x6c/0x9c)
[ 16.091225] r8:00000000 r7:def059b0 r6:00000001 r5:00000000 r4:00000000
r3:00000012
[ 16.099141] [<80008560>] (tzic_handle_irq+0x0/0x9c) from [<8000e184>] (__irq_svc+0x44/0x60)
[ 16.107494] Exception stack(0xdef059b0 to 0xdef059f8)
[ 16.112550] 59a0: 00000001 00000001 00000000 dfb8e400
[ 16.120732] 59c0: 40000013 81a2e500 00000000 81a2e500 00000000 00000000 80862418 def05a0c
[ 16.128912] 59e0: def059c8 def059f8 80070e24 804c81bc 20000013 ffffffff
[ 16.135542] [<804c8178>] (_raw_spin_unlock_irqrestore+0x0/0x54) from [<8003d0ec>] (__queue_work+0x108/0x470)
[ 16.145369] r5:dfb1a30c r4:81b93c00
[ 16.148978] [<8003cfe4>] (__queue_work+0x0/0x470) from [<8003d4e0>] (queue_work_on+0x4c/0x54)
[ 16.157511] [<8003d494>] (queue_work_on+0x0/0x54) from [<8003d544>] (queue_work+0x30/0x34)
[ 16.165774] r6:df2e6900 r5:80e0c2f8 r4:dfb1a2c8 r3:def04000
[ 16.171495] [<8003d514>] (queue_work+0x0/0x34) from [<80493284>] (rpc_make_runnable+0x9c/0xac)
[ 16.180113] [<804931e8>] (rpc_make_runnable+0x0/0xac) from [<80493c88>] (rpc_execute+0x40/0xa8)
[ 16.188811] r5:def05ad4 r4:dfb1a2c8
[ 16.192426] [<80493c48>] (rpc_execute+0x0/0xa8) from [<8048c734>] (rpc_run_task+0xa8/0xb4)
[ 16.200690] r8:00000001 r7:df74f520 r6:ded75700 r5:def05ad4 r4:dfb1a2c8
r3:00000002
[ 16.208618] [<8048c68c>] (rpc_run_task+0x0/0xb4) from [<801f1608>] (nfs_initiate_read+0xb4/0xd4)
[ 16.217403] r5:df3e86c0 r4:00000000
[ 16.221015] [<801f1554>] (nfs_initiate_read+0x0/0xd4) from [<801f1c64>] (nfs_generic_pg_readpages+0x9c/0x114)
[ 16.230937] [<801f1bc8>] (nfs_generic_pg_readpages+0x0/0x114) from [<801f0744>] (__nfs_pageio_add_request+0xe8/0x214)
[ 16.241545] r8:000bf000 r7:00000000 r6:00000000 r5:deef4640 r4:def05c1c
r3:801f1bc8
[ 16.249463] [<801f065c>] (__nfs_pageio_add_request+0x0/0x214) from [<801f0e3c>] (nfs_pageio_add_request+0x28/0x54)
[ 16.259818] [<801f0e14>] (nfs_pageio_add_request+0x0/0x54) from [<801f1394>] (readpage_async_filler+0x114/0x170)
[ 16.269992] r5:def05c58 r4:80fd7300
[ 16.273607] [<801f1280>] (readpage_async_filler+0x0/0x170) from [<800bb418>] (read_cache_pages+0xa0/0x108)
[ 16.283259] r8:00200200 r7:00100100 r6:df74f654 r5:def05cd0 r4:80fd7300
[ 16.290034] [<800bb378>] (read_cache_pages+0x0/0x108) from [<801f218c>] (nfs_readpages+0xc4/0x168)
[ 16.298999] [<801f20c8>] (nfs_readpages+0x0/0x168) from [<800bb1d0>] (__do_page_cache_readahead+0x254/0x354)
[ 16.308833] [<800baf7c>] (__do_page_cache_readahead+0x0/0x354) from [<800bb5d0>] (ra_submit+0x38/0x40)
[ 16.318145] [<800bb598>] (ra_submit+0x0/0x40) from [<800bb6b0>] (ondemand_readahead+0xd8/0x3b0)
[ 16.326851] [<800bb5d8>] (ondemand_readahead+0x0/0x3b0) from [<800bba20>] (page_cache_async_readahead+0x98/0xa8)
[ 16.337043] [<800bb988>] (page_cache_async_readahead+0x0/0xa8) from [<800b2118>] (generic_file_aio_read+0x5b4/0x7c4)
[ 16.347565] r6:00000000 r5:df74f654 r4:80fd70a0
[ 16.352231] [<800b1b64>] (generic_file_aio_read+0x0/0x7c4) from [<801e82c0>] (nfs_file_read+0x7c/0xcc)
[ 16.361544] [<801e8244>] (nfs_file_read+0x0/0xcc) from [<800eab80>] (do_sync_read+0xb4/0xf4)
[ 16.369981] r9:00000000 r8:def05f70 r7:00000000 r6:00000000 r5:dec34900
r4:fffffdee
[ 16.377896] [<800eaacc>] (do_sync_read+0x0/0xf4) from [<800eb548>] (vfs_read+0xb4/0x144)
[ 16.385987] r8:00000000 r7:def05f70 r6:76a95008 r5:003e3dd6 r4:dec34900
[ 16.392761] [<800eb494>] (vfs_read+0x0/0x144) from [<800eb624>] (sys_read+0x4c/0x78)
[ 16.400504] r8:00000000 r7:00000003 r6:003e3dd6 r5:76a95008 r4:dec34900
[ 16.407279] [<800eb5d8>] (sys_read+0x0/0x78) from [<8000e5c0>] (ret_fast_syscall+0x0/0x48)
[ 16.415543] r9:def04000 r8:8000e864 r6:000086b4 r5:00000000 r4:00000000
[ 20.872729] gadget: high-speed config #1: Video
[ 20.877368] gadget: uvc_function_set_alt(0, 0)
[ 20.881908] gadget: uvc_function_set_alt(1, 0)
[ 20.891464] gadget: uvc_function_set_alt(1, 0)
Signed-off-by: Michael Grzeschik <m.grzeschik@pengutronix.de>
Signed-off-by: Felipe Balbi <balbi@ti.com>
|
|
Fix boot up hang when enable udc without otg enabled.
The root cause is that the clock will be shut down when probe routine is
finished because of clock gating. When a gadget driver is registered at
this time, it will call mv_udc_start which in turn will call
mv_udc_vbus_session. If there is no cable attached at the boot up time,
the vbus is low, so it will call stop_activity path without clock
enabled which will cause system hang then.
Actually, we need't go this path when clock is disabled, what we need to
do is just jump out.
Signed-off-by: Neil Zhang <zhangwm@marvell.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
|
|
Fix system hang in udc shutdown routine which caused by accessing usb
register when clock is disabled. So enable usb clock before access
register.
Signed-off-by: Yunfan Zhang <yfzhang@marvell.com>
Signed-off-by: Neil Zhang <zhangwm@marvell.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
|
|
In order to support iso, we need do the following things:
1. fix length for one dtd
2. allow req contains multiple packets for a ISO transfer
Signed-off-by: Chao Xie <chao.xie@marvell.com>
Signed-off-by: Yu Xu <yuxu@marvell.com>
Signed-off-by: Neil Zhang <zhangwm@marvell.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
|
|
According to ChipIdea's reference manual in section 8.5.2
"Non-streaming operational mode in device mode", we'd better enable stream
mode, especially that ISO endpoints are not supported when the SDIS bit
is set.
Signed-off-by: Neil Zhang <zhangwm@marvell.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
|
|
build_dtd() can be called when hold a spinlock, but GFP_KERNEL may cause
dma_pool_alloc() sleep, So we need use GFP_ATOMIC instead of GFP_KERNEL.
But using GFP_ATOMIC may cause failure when allocating memory, add error
handler to handle it.
Signed-off-by: Alexey Khoroshilov <khoroshilov@ispras.ru>
Signed-off-by: Neil Zhang <zhangwm@marvell.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
|
|
Clean unused code for mv_udc driver.
Signed-off-by: Neil Zhang <zhangwm@marvell.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
|
|
There are several places use udelay(LOOPS_USEC) to wait the status to be
changed, but the delay interval is a bit too long, so reduce it to
enhance the performance.
Signed-off-by: Neil Zhang <zhangwm@marvell.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
|
|
The old interface is bugged and reads the wrong sensor when retrieving
the reading for the chassis fan (it reads the CPU sensor); the new
interface works fine.
Reported-by: Göran Uddeborg <goeran@uddeborg.se>
Cc: stable@vger.kernel.org
Tested-by: Göran Uddeborg <goeran@uddeborg.se>
Signed-off-by: Luca Tettamanti <kronos.it@gmail.com>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
|
|
This patch fixes the name of the macro used to mask the
mmc interrupt: erroneously it was used: MMC_DEFAUL_MASK.
Signed-off-by: Giuseppe Cavallaro <peppe.cavallaro@st.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
