| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
The functionality of ext3 is fully supported by ext4 driver. Major
distributions (SUSE, RedHat) already use ext4 driver to handle ext3
filesystems for quite some time. There is some ugliness in mm resulting
from jbd cleaning buffers in a dirty page without cleaning page dirty
bit and also support for buffer bouncing in the block layer when stable
pages are required is there only because of jbd. So let's remove the
ext3 driver. This saves us some 28k lines of duplicated code.
Acked-by: Theodore Ts'o <tytso@mit.edu>
Signed-off-by: Jan Kara <jack@suse.cz>
|
| |
|
|
|
|
|
|
|
|
| |
Documentation of journalling layer in
Documentation/DocBook/filesystems.tmpl speaks about JBD layer. Since
that is going away, update the documentation to speak about JBD2. Also
update the parts that have changed since someone last touched the
document and remove some parts which are just misleading and outdated.
Signed-off-by: Jan Kara <jack@suse.com>
|
| |
|
|
|
|
|
|
|
|
| |
dquot_initialize() can now return error. Handle it where possible
Slightly modified by Dave Kleikamp due to needed jfs_rename() error path
fix.
Signed-off-by: Jan Kara <jack@suse.com>
Reviewed-by: Dave Kleikamp <dave.kleikamp@oracle.com>
|
| |
|
|
|
|
| |
dquot_initialize() can now return error. Handle it where possible.
Signed-off-by: Jan Kara <jack@suse.com>
|
| |
|
|
|
|
|
| |
dquot_initialize() can now return error. Handle it where possible.
Reviewed-by: Junxiao Bi <junxiao.bi@oracle.com>
Signed-off-by: Jan Kara <jack@suse.com>
|
| |
|
|
|
|
|
| |
dquot_initialize() can now return error. Handle it where possible.
Acked-by: Theodore Ts'o <tytso@mit.edu>
Signed-off-by: Jan Kara <jack@suse.com>
|
| |
|
|
|
|
| |
dquot_initialize() can now return error. Handle it where possible.
Signed-off-by: Jan Kara <jack@suse.com>
|
| |
|
|
|
|
|
|
|
|
| |
Currently when some error happened in ->acquire_dquot(), dqget() just
returned NULL. That was indistinguishable from a case when e.g. someone
run quotaoff and so was generally silently ignored. However
->acquire_dquot() can fail because of ENOSPC or EIO in which case user
should better know. So propagate error up from ->acquire_dquot properly.
Signed-off-by: Jan Kara <jack@suse.cz>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This reverts commit a2673b6e040663bf16a552f8619e6bde9f4b9acf.
Kinglong Mee reports a memory leak with that patch, and Jan Kara confirms:
"Thanks for report! You are right that my patch introduces a race
between fsnotify kthread and fsnotify_destroy_group() which can result
in leaking inotify event on group destruction.
I haven't yet decided whether the right fix is not to queue events for
dying notification group (as that is pointless anyway) or whether we
should just fix the original problem differently... Whenever I look
at fsnotify code mark handling I get lost in the maze of locks, lists,
and subtle differences between how different notification systems
handle notification marks :( I'll think about it over night"
and after thinking about it, Jan says:
"OK, I have looked into the code some more and I found another
relatively simple way of fixing the original oops. It will be IMHO
better than trying to fixup this issue which has more potential for
breakage. I'll ask Linus to revert the fsnotify fix he already merged
and send a new fix"
Reported-by: Kinglong Mee <kinglongmee@gmail.com>
Requested-by: Jan Kara <jack@suse.cz>
Cc: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
| |\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl
Pull pin control fixes from Linus Walleij:
"Here are some overly ripe pin control fixes for the v4.2 series.
They got delayed because of various crap commits and having to clean
and rinse the patch stack a few times. Now they are however looking
good.
- some dead defines dropped from the Samsung driver, was targeted for
-rc2 but got delayed
- drop the strict mode from abx500, this was too strict
- fix the R-Car sparse IRQs code to work as intended
- fix the IRQ code for the pinctrl-single GPIO backend to not enforce
threaded IRQs
- clear the latched events/IRQs for the Broadcom BCM2835 driver
- fix up debugfs for the Freescale imx1 driver
- fix a typo bug in the Schmitt Trigger setup in the LPC18xx driver"
* tag 'pinctrl-v4.2-2' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl:
pinctrl: lpc18xx: fix schmitt trigger setup
Subject: pinctrl: imx1-core: Fix debug output in .pin_config_set callback
pinctrl: bcm2835: Clear the event latch register when disabling interrupts
pinctrl: single: ensure pcs irq will not be forced threaded
sh-pfc: fix sparse GPIOs for R-Car SoCs
pinctrl: abx500: remove strict mode
pinctrl: samsung: Remove old unused defines
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The param_val variable is what determines if schmitt
trigger is enabled on a pin or not. A typo here mean
that schmitt trigger was always enabled for standard
and i2c pins.
Signed-off-by: Joachim Eastwood <manabian@gmail.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
imx1_pinconf_set assumes that the array of pins in struct
imx1_pinctrl_soc_info can be indexed by pin id to get the
pinctrl_pin_desc for a pin. This used to be correct up to commit
607af165c047 which removed some entries from the array and so made it
wrong to access the array by pin id.
The result of this bug is a wrong pin name in the output for small pin
ids and an oops for the bigger ones.
This patch is the result of a discussion that includes patches by Markus
Pargmann and Chris Ruehl.
Fixes: 607af165c047 ("pinctrl: i.MX27: Remove nonexistent pad definitions")
Cc: stable@vger.kernel.org
Reported-by: Chris Ruehl <chris.ruehl@gtsys.com.hk>
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Reviewed-by: Markus Pargmann <mpa@pengutronix.de>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
It's possible to hit a race condition if interrupts are generated on a GPIO
pin when the IRQ line in question is being disabled.
If the interrupt is freed, bcm2835_gpio_irq_disable() is called which
disables the event generation sources (edge, level). If an event occurred
between the last disabling of hard IRQs and the write to the event
source registers, a bit would be set in the GPIO event detect register
(GPEDSn) which goes unacknowledged by bcm2835_gpio_irq_handler()
so Linux complains loudly.
There is no per-GPIO mask register, so when disabling GPIO interrupts
write 1 to the relevant bit in GPEDSn to clear out any stale events.
Signed-off-by: Jonathan Bell <jonathan@raspberrypi.org>
Acked-by: Stephen Warren <swarren@wwwdotorg.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The PSC IRQ is requested using request_irq() API and as result it can
be forced to be threaded IRQ in RT-Kernel if PCS_QUIRK_HAS_SHARED_IRQ
is enabled for pinctrl domain.
As result, following 'possible irq lock inversion dependency' report
can be seen:
=========================================================
[ INFO: possible irq lock inversion dependency detected ]
3.14.43-rt42-00360-g96ff499-dirty #24 Not tainted
---------------------------------------------------------
irq/369-pinctrl/927 just changed the state of lock:
(&pcs->lock){+.....}, at: [<c0375b54>] pcs_irq_handle+0x48/0x9c
but this lock was taken by another, HARDIRQ-safe lock in the past:
(&irq_desc_lock_class){-.....}
and interrupts could create inverse lock ordering between them.
other info that might help us debug this:
Possible interrupt unsafe locking scenario:
CPU0 CPU1
---- ----
lock(&pcs->lock);
local_irq_disable();
lock(&irq_desc_lock_class);
lock(&pcs->lock);
<Interrupt>
lock(&irq_desc_lock_class);
*** DEADLOCK ***
no locks held by irq/369-pinctrl/927.
the shortest dependencies between 2nd lock and 1st lock:
-> (&irq_desc_lock_class){-.....} ops: 58724 {
IN-HARDIRQ-W at:
[<c0090040>] lock_acquire+0x9c/0x158
[<c07065c8>] _raw_spin_lock+0x48/0x58
[<c009edac>] handle_fasteoi_irq+0x24/0x15c
[<c009abb0>] generic_handle_irq+0x3c/0x4c
[<c000f83c>] handle_IRQ+0x50/0xa0
[<c0008674>] gic_handle_irq+0x3c/0x6c
[<c0707a04>] __irq_svc+0x44/0x8c
[<c000fc44>] arch_cpu_idle+0x40/0x4c
[<c009aadc>] cpu_startup_entry+0x270/0x2e0
[<c06fcbf8>] rest_init+0xd4/0xe4
[<c0a44bfc>] start_kernel+0x3d0/0x3dc
[<80008084>] 0x80008084
INITIAL USE at:
[<c0090040>] lock_acquire+0x9c/0x158
[<c070674c>] _raw_spin_lock_irqsave+0x54/0x68
[<c009aff8>] __irq_get_desc_lock+0x64/0xa4
[<c009e38c>] irq_set_chip+0x30/0x78
[<c009ec30>] irq_set_chip_and_handler_name+0x24/0x3c
[<c036ca10>] gic_irq_domain_map+0x48/0xb4
[<c00a0a80>] irq_domain_associate+0x84/0x1d4
[<c00a1154>] irq_create_mapping+0x80/0x11c
[<c00a1270>] irq_create_of_mapping+0x80/0x120
[<c05cdaa8>] irq_of_parse_and_map+0x34/0x3c
[<c0a4ea24>] omap_dm_timer_init_one+0x90/0x30c
[<c0a4eef0>] omap5_realtime_timer_init+0x8c/0x48c
[<c0a486b0>] time_init+0x28/0x38
[<c0a44a6c>] start_kernel+0x240/0x3dc
[<80008084>] 0x80008084
}
... key at: [<c1049ce0>] irq_desc_lock_class+0x0/0x8
... acquired at:
[<c07065c8>] _raw_spin_lock+0x48/0x58
[<c0375a90>] pcs_irq_unmask+0x58/0xa0
[<c009ea48>] irq_enable+0x38/0x48
[<c009ead0>] irq_startup+0x78/0x7c
[<c009d440>] __setup_irq+0x4a8/0x4f4
[<c009d5dc>] request_threaded_irq+0xb8/0x138
[<c0415a5c>] omap_8250_startup+0x4c/0x148
[<c041276c>] serial8250_startup+0x24/0x30
[<c040d0ec>] uart_startup.part.9+0x5c/0x1b4
[<c040dbcc>] uart_open+0xf4/0x16c
[<c03f0540>] tty_open+0x170/0x61c
[<c0157028>] chrdev_open+0xbc/0x1b4
[<c0150494>] do_dentry_open+0x1e8/0x2bc
[<c0150a84>] finish_open+0x44/0x5c
[<c0160d50>] do_last.isra.47+0x710/0xca0
[<c01613a4>] path_openat+0xc4/0x640
[<c0162904>] do_filp_open+0x3c/0x98
[<c0151bdc>] do_sys_open+0x114/0x1d8
[<c0151cc8>] SyS_open+0x28/0x2c
[<c0a44d70>] kernel_init_freeable+0x168/0x1e4
[<c06fcc24>] kernel_init+0x1c/0xf8
[<c000eee8>] ret_from_fork+0x14/0x20
-> (&pcs->lock){+.....} ops: 65 {
HARDIRQ-ON-W at:
[<c0090040>] lock_acquire+0x9c/0x158
[<c07065c8>] _raw_spin_lock+0x48/0x58
[<c0375b54>] pcs_irq_handle+0x48/0x9c
[<c0375c5c>] pcs_irq_handler+0x1c/0x28
[<c009c458>] irq_forced_thread_fn+0x30/0x74
[<c009c784>] irq_thread+0x158/0x1c4
[<c0063fc4>] kthread+0xd4/0xe8
[<c000eee8>] ret_from_fork+0x14/0x20
INITIAL USE at:
[<c0090040>] lock_acquire+0x9c/0x158
[<c070674c>] _raw_spin_lock_irqsave+0x54/0x68
[<c0375344>] pcs_enable+0x7c/0xe8
[<c0372a44>] pinmux_enable_setting+0x178/0x220
[<c036fecc>] pinctrl_select_state+0x110/0x194
[<c04732dc>] pinctrl_bind_pins+0x7c/0x108
[<c045853c>] driver_probe_device+0x70/0x254
[<c0458810>] __driver_attach+0x9c/0xa0
[<c045674c>] bus_for_each_dev+0x78/0xac
[<c0458030>] driver_attach+0x2c/0x30
[<c0457c78>] bus_add_driver+0x15c/0x204
[<c0458ee0>] driver_register+0x88/0x108
[<c045a168>] __platform_driver_register+0x64/0x6c
[<c0a8170c>] omap_hsmmc_driver_init+0x1c/0x20
[<c0008a94>] do_one_initcall+0x110/0x170
[<c0a44d48>] kernel_init_freeable+0x140/0x1e4
[<c06fcc24>] kernel_init+0x1c/0xf8
[<c000eee8>] ret_from_fork+0x14/0x20
}
... key at: [<c1088a8c>] __key.18572+0x0/0x8
... acquired at:
[<c008cdd4>] mark_lock+0x388/0x76c
[<c008df40>] __lock_acquire+0x6d0/0x1f98
[<c0090040>] lock_acquire+0x9c/0x158
[<c07065c8>] _raw_spin_lock+0x48/0x58
[<c0375b54>] pcs_irq_handle+0x48/0x9c
[<c0375c5c>] pcs_irq_handler+0x1c/0x28
[<c009c458>] irq_forced_thread_fn+0x30/0x74
[<c009c784>] irq_thread+0x158/0x1c4
[<c0063fc4>] kthread+0xd4/0xe8
[<c000eee8>] ret_from_fork+0x14/0x20
stack backtrace:
CPU: 1 PID: 927 Comm: irq/369-pinctrl Not tainted 3.14.43-rt42-00360-g96ff499-dirty #24
[<c00177e0>] (unwind_backtrace) from [<c00130b0>] (show_stack+0x20/0x24)
[<c00130b0>] (show_stack) from [<c0702958>] (dump_stack+0x84/0xd0)
[<c0702958>] (dump_stack) from [<c008bcfc>] (print_irq_inversion_bug+0x1d0/0x21c)
[<c008bcfc>] (print_irq_inversion_bug) from [<c008bf18>] (check_usage_backwards+0xb4/0x11c)
[<c008bf18>] (check_usage_backwards) from [<c008cdd4>] (mark_lock+0x388/0x76c)
[<c008cdd4>] (mark_lock) from [<c008df40>] (__lock_acquire+0x6d0/0x1f98)
[<c008df40>] (__lock_acquire) from [<c0090040>] (lock_acquire+0x9c/0x158)
[<c0090040>] (lock_acquire) from [<c07065c8>] (_raw_spin_lock+0x48/0x58)
[<c07065c8>] (_raw_spin_lock) from [<c0375b54>] (pcs_irq_handle+0x48/0x9c)
[<c0375b54>] (pcs_irq_handle) from [<c0375c5c>] (pcs_irq_handler+0x1c/0x28)
[<c0375c5c>] (pcs_irq_handler) from [<c009c458>] (irq_forced_thread_fn+0x30/0x74)
[<c009c458>] (irq_forced_thread_fn) from [<c009c784>] (irq_thread+0x158/0x1c4)
[<c009c784>] (irq_thread) from [<c0063fc4>] (kthread+0xd4/0xe8)
[<c0063fc4>] (kthread) from [<c000eee8>] (ret_from_fork+0x14/0x20)
To fix it use IRQF_NO_THREAD to ensure that pcs irq will not be forced threaded.
Cc: Tony Lindgren <tony@atomide.com>
Cc: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
Acked-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The PFC driver causes the kernel to hang on the R-Car gen2 SoC based boards
when the CPU_ALL_PORT() macro is fixed to reflect the reality, i.e. when the
GPIO space becomes actually sparse. This happens because the _GP_GPIO() macro
includes an indexed initializer which causes the "holes" (array entries filled
with all 0s) between the groups of the existing GPIOs; and the driver can't
cope with that. There seems to be no reason to use the indexed initializer,
so we can remove the index specifier and so avoid the "holes".
Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Tested-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Commit a21763a0b1e5a5ab8310f581886d04beadc16616
"pinctrl: nomadik: activate strict mux mode"
put all Nomadik pin controllers to strict mode. This was
not good on the Snowball platform: the muxing of GPIOs to
different pins is done with hogs in the DTS file, and then
these GPIOs are used by offset, relying on hogs to mux the
pins. Since that means the pin controller "owns" the pins
and at the same time we have a GPIO user, this pin controller
is by definition not strict.
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Since 9a2c1c3b91aa ("pinctrl: samsung: Allow grouping multiple
pinmux/pinconf nodes") the defines for GPIO group and function names are
not used anywhere in the driver.
Signed-off-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Inspired-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
| |\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
git://git.kernel.org/pub/scm/linux/kernel/git/jack/linux-fs
Pull UDF fix from Jan Kara:
"A fix for UDF corruption when certain disk-format feature is enabled"
* 'for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jack/linux-fs:
udf: Don't corrupt unalloc spacetable when writing it
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
For a UDF filesystem configured with an Unallocated Space Table,
a filesystem operation that triggers an update to the table results
in on-disk corruption that prevents remounting:
udf_read_tagged: tag version 0x0000 != 0x0002 || 0x0003, block 274
For example:
1. Create a filesystem
$ mkudffs --media-type=hd --blocksize=512 --lvid=BUGTEST \
--vid=BUGTEST --fsid=BUGTEST --space=unalloctable \
/dev/mmcblk0
2. Mount it
# mount /dev/mmcblk0 /mnt
3. Create a file
$ echo "No corruption, please" > /mnt/new.file
4. Umount
# umount /mnt
5. Attempt remount
# mount /dev/mmcblk0 /mnt
This appears to be a longstanding bug caused by zero-initialization of
the Unallocated Space Entry block buffer and only partial repopulation
of required fields before writing to disk.
Commit 0adfb339fd64 ("udf: Fix unalloc space handling in udf_update_inode")
addressed one such field, but several others are required.
Signed-off-by: Steven J. Magnani <steve@digidescorp.com>
Signed-off-by: Jan Kara <jack@suse.com>
|
| |\ \ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace
Pull tracing sample code fix from Steven Rostedt:
"He Kuang noticed that the sample code using the trace_event helper
function __get_dynamic_array_len() is broken.
This only changes the sample code, and I'm pushing this now instead of
later because I don't want others using the broken code as an example
when using it for real"
* tag 'trace-v4.2-rc2-fix2' of git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace:
tracing: Fix sample output of dynamic arrays
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
He Kuang noticed that the trace event samples for arrays was broken:
"The output result of trace_foo_bar event in traceevent samples is
wrong. This problem can be reproduced as following:
(Build kernel with SAMPLE_TRACE_EVENTS=m)
$ insmod trace-events-sample.ko
$ echo 1 > /sys/kernel/debug/tracing/events/sample-trace/foo_bar/enable
$ cat /sys/kernel/debug/tracing/trace
event-sample-980 [000] .... 43.649559: foo_bar: foo hello 21 0x15
BIT1|BIT3|0x10 {0x1,0x6f6f6e53,0xff007970,0xffffffff} Snoopy
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
The array length is not right, should be {0x1}.
(ffffffff,ffffffff)
event-sample-980 [000] .... 44.653827: foo_bar: foo hello 22 0x16
BIT2|BIT3|0x10
{0x1,0x2,0x646e6147,0x666c61,0xffffffff,0xffffffff,0x750aeffe,0x7}
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
The array length is not right, should be {0x1,0x2}.
Gandalf (ffffffff,ffffffff)"
This was caused by an update to have __print_array()'s second parameter
be the count of items in the array and not the size of the array.
As there is already users of __print_array(), it can not change. But
the sample code can and we can also improve on the documentation about
__print_array() and __get_dynamic_array_len().
Link: http://lkml.kernel.org/r/1436839171-31527-2-git-send-email-hekuang@huawei.com
Fixes: ac01ce1410fc2 ("tracing: Make ftrace_print_array_seq compute buf_len")
Reported-by: He Kuang <hekuang@huawei.com>
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
|
| |\ \ \ \
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux
Pull s390 fix from Martin Schwidefsky:
"Fast path fix for the thread_struct breakage"
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux:
s390: adapt entry.S to the move of thread_struct
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
git commit 0c8c0f03e3a292e031596484275c14cf39c0ab7a
"x86/fpu, sched: Dynamically allocate 'struct fpu'"
moved the thread_struct to the end of the task_struct.
This causes some of the offsets used in entry.S to overflow their
instruction operand field. To fix this use aghi to create a
dedicated pointer for the thread_struct.
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
|
| |\ \ \ \ \
| |/ / / /
|/| | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
git://git.kernel.org/pub/scm/linux/kernel/git/egtvedt/linux-avr32
Pull AVR32 update from Hans-Christian Egtvedt.
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/egtvedt/linux-avr32:
AVR32/time: Migrate to new 'set-state' interface
|
| |/ / / /
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Migrate avr32 driver to the new 'set-state' interface provided by
clockevents core, the earlier 'set-mode' interface is marked obsolete
now.
This also enables us to implement callbacks for new states of clockevent
devices, for example: ONESHOT_STOPPED.
We want to call cpu_idle_poll_ctrl() in shutdown only if we were in
oneshot or resume state earlier. Create another variable to save this
information and check that in shutdown callback.
Cc: Haavard Skinnemoen <hskinnemoen@gmail.com>
Cc: Hans-Christian Egtvedt <egtvedt@samfundet.no>
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Acked-by: Hans-Christian Egtvedt <egtvedt@samfundet.no>
|
| | | | | |
|
| |\ \ \ \
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi
Pull SCSI fixes from James Bottomley:
"Two fairly simple fixes: one is a change that causes us to have a very
low queue depth leading to performance issues and the other is a null
deref occasionally in tapes thanks to use after put"
* tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi:
scsi: fix host max depth checking for the 'queue_depth' sysfs interface
st: null pointer dereference panic caused by use after kref_put by st_open
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Commit 1e6f2416044c0 changed the scsi sysfs 'queue_depth' code to
rejects depths higher than the scsi host template setting. But lots
of hosts set this to 1, and update the settings in the scsi host
when the controller/devices probing happens.
This breaks (at least) mpt2sas and mpt3sas runtime setting of queue
depth, returning EINVAL for all settings but '1'. And once it's set to
1, there's no way to go back up.
Cc: stable@vger.kernel.org
Fixes: 1e6f2416044c0 "scsi: don't allow setting of queue_depth bigger than can_queue"
Signed-off-by: Jens Axboe <axboe@fb.com>
Reviewed-by: Martin K. Petersen <martin.petersen@oracle.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: James Bottomley <JBottomley@Odin.com>
|
| | | |_|/
| |/| |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Two SLES11 SP3 servers encountered similar crashes simultaneously
following some kind of SAN/tape target issue:
...
qla2xxx [0000:81:00.0]-801c:3: Abort command issued nexus=3:0:2 -- 1 2002.
qla2xxx [0000:81:00.0]-801c:3: Abort command issued nexus=3:0:2 -- 1 2002.
qla2xxx [0000:81:00.0]-8009:3: DEVICE RESET ISSUED nexus=3:0:2 cmd=ffff882f89c2c7c0.
qla2xxx [0000:81:00.0]-800c:3: do_reset failed for cmd=ffff882f89c2c7c0.
qla2xxx [0000:81:00.0]-800f:3: DEVICE RESET FAILED: Task management failed nexus=3:0:2 cmd=ffff882f89c2c7c0.
qla2xxx [0000:81:00.0]-8009:3: TARGET RESET ISSUED nexus=3:0:2 cmd=ffff882f89c2c7c0.
qla2xxx [0000:81:00.0]-800c:3: do_reset failed for cmd=ffff882f89c2c7c0.
qla2xxx [0000:81:00.0]-800f:3: TARGET RESET FAILED: Task management failed nexus=3:0:2 cmd=ffff882f89c2c7c0.
qla2xxx [0000:81:00.0]-8012:3: BUS RESET ISSUED nexus=3:0:2.
qla2xxx [0000:81:00.0]-802b:3: BUS RESET SUCCEEDED nexus=3:0:2.
qla2xxx [0000:81:00.0]-505f:3: Link is operational (8 Gbps).
qla2xxx [0000:81:00.0]-8018:3: ADAPTER RESET ISSUED nexus=3:0:2.
qla2xxx [0000:81:00.0]-00af:3: Performing ISP error recovery - ha=ffff88bf04d18000.
rport-3:0-0: blocked FC remote port time out: removing target and saving binding
qla2xxx [0000:81:00.0]-505f:3: Link is operational (8 Gbps).
qla2xxx [0000:81:00.0]-8017:3: ADAPTER RESET SUCCEEDED nexus=3:0:2.
rport-2:0-0: blocked FC remote port time out: removing target and saving binding
sg_rq_end_io: device detached
BUG: unable to handle kernel NULL pointer dereference at 00000000000002a8
IP: [<ffffffff8133b268>] __pm_runtime_idle+0x28/0x90
PGD 7e6586f067 PUD 7e5af06067 PMD 0 [1739975.390354] Oops: 0002 [#1] SMP
CPU 0
...
Supported: No, Proprietary modules are loaded [1739975.390463]
Pid: 27965, comm: ABCD Tainted: PF X 3.0.101-0.29-default #1 HP ProLiant DL580 Gen8
RIP: 0010:[<ffffffff8133b268>] [<ffffffff8133b268>] __pm_runtime_idle+0x28/0x90
RSP: 0018:ffff8839dc1e7c68 EFLAGS: 00010202
RAX: 0000000000000000 RBX: ffff883f0592fc00 RCX: 0000000000000090
RDX: 0000000000000000 RSI: 0000000000000004 RDI: 0000000000000138
RBP: 0000000000000138 R08: 0000000000000010 R09: ffffffff81bd39d0
R10: 00000000000009c0 R11: ffffffff81025790 R12: 0000000000000001
R13: ffff883022212b80 R14: 0000000000000004 R15: ffff883022212b80
FS: 00007f8e54560720(0000) GS:ffff88407f800000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
CR2: 00000000000002a8 CR3: 0000007e6ced6000 CR4: 00000000001407f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process ABCD (pid: 27965, threadinfo ffff8839dc1e6000, task ffff883592e0c640)
Stack:
ffff883f0592fc00 00000000fffffffa 0000000000000001 ffff883022212b80
ffff883eff772400 ffffffffa03fa309 0000000000000000 0000000000000000
ffffffffa04003a0 ffff883f063196c0 ffff887f0379a930 ffffffff8115ea1e
Call Trace:
[<ffffffffa03fa309>] st_open+0x129/0x240 [st]
[<ffffffff8115ea1e>] chrdev_open+0x13e/0x200
[<ffffffff811588a8>] __dentry_open+0x198/0x310
[<ffffffff81167d74>] do_last+0x1f4/0x800
[<ffffffff81168fe9>] path_openat+0xd9/0x420
[<ffffffff8116946c>] do_filp_open+0x4c/0xc0
[<ffffffff8115a00f>] do_sys_open+0x17f/0x250
[<ffffffff81468d92>] system_call_fastpath+0x16/0x1b
[<00007f8e4f617fd0>] 0x7f8e4f617fcf
Code: eb d3 90 48 83 ec 28 40 f6 c6 04 48 89 6c 24 08 4c 89 74 24 20 48 89 fd 48 89 1c 24 4c 89 64 24 10 41 89 f6 4c 89 6c 24 18 74 11 <f0> ff 8f 70 01 00 00 0f 94 c0 45 31 ed 84 c0 74 2b 4c 8d a5 a0
RIP [<ffffffff8133b268>] __pm_runtime_idle+0x28/0x90
RSP <ffff8839dc1e7c68>
CR2: 00000000000002a8
Analysis reveals the cause of the crash to be due to STp->device
being NULL. The pointer was NULLed via scsi_tape_put(STp) when it
calls scsi_tape_release(). In st_open() we jump to err_out after
scsi_block_when_processing_errors() completes and returns the
device as offline (sdev_state was SDEV_DEL):
1180 /* Open the device. Needs to take the BKL only because of incrementing the SCSI host
1181 module count. */
1182 static int st_open(struct inode *inode, struct file *filp)
1183 {
1184 int i, retval = (-EIO);
1185 int resumed = 0;
1186 struct scsi_tape *STp;
1187 struct st_partstat *STps;
1188 int dev = TAPE_NR(inode);
1189 char *name;
...
1217 if (scsi_autopm_get_device(STp->device) < 0) {
1218 retval = -EIO;
1219 goto err_out;
1220 }
1221 resumed = 1;
1222 if (!scsi_block_when_processing_errors(STp->device)) {
1223 retval = (-ENXIO);
1224 goto err_out;
1225 }
...
1264 err_out:
1265 normalize_buffer(STp->buffer);
1266 spin_lock(&st_use_lock);
1267 STp->in_use = 0;
1268 spin_unlock(&st_use_lock);
1269 scsi_tape_put(STp); <-- STp->device = 0 after this
1270 if (resumed)
1271 scsi_autopm_put_device(STp->device);
1272 return retval;
The ref count for the struct scsi_tape had already been reduced
to 1 when the .remove method of the st module had been called.
The kref_put() in scsi_tape_put() caused scsi_tape_release()
to be called:
0266 static void scsi_tape_put(struct scsi_tape *STp)
0267 {
0268 struct scsi_device *sdev = STp->device;
0269
0270 mutex_lock(&st_ref_mutex);
0271 kref_put(&STp->kref, scsi_tape_release); <-- calls this
0272 scsi_device_put(sdev);
0273 mutex_unlock(&st_ref_mutex);
0274 }
In scsi_tape_release() the struct scsi_device in the struct
scsi_tape gets set to NULL:
4273 static void scsi_tape_release(struct kref *kref)
4274 {
4275 struct scsi_tape *tpnt = to_scsi_tape(kref);
4276 struct gendisk *disk = tpnt->disk;
4277
4278 tpnt->device = NULL; <<<---- where the dev is nulled
4279
4280 if (tpnt->buffer) {
4281 normalize_buffer(tpnt->buffer);
4282 kfree(tpnt->buffer->reserved_pages);
4283 kfree(tpnt->buffer);
4284 }
4285
4286 disk->private_data = NULL;
4287 put_disk(disk);
4288 kfree(tpnt);
4289 return;
4290 }
Although the problem was reported on SLES11.3 the problem appears
in linux-next as well.
The crash is fixed by reordering the code so we no longer access
the struct scsi_tape after the kref_put() is done on it in st_open().
Signed-off-by: Shane Seymour <shane.seymour@hp.com>
Signed-off-by: Darren Lavender <darren.lavender@hp.com>
Reviewed-by: Johannes Thumshirn <jthumshirn@suse.com>
Acked-by: Kai Mäkisara <kai.makisara@kolumbus.fi>
Cc: stable@vger.kernel.org
Signed-off-by: James Bottomley <JBottomley@Odin.com>
|
| |\ \ \ \
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Pull MIPS fixes from Ralf Baechle:
"Another round of MIPS fixes for 4.2.
Things are looking quite decent at this stage but the recent work on
the FPU support took its toll:
- fix an incorrect overly restrictive ifdef
- select O32 64-bit FP support for O32 binary compatibility
- remove workarounds for Sibyte SB1250 Pass1 parts. There are rare
fixing the workarounds is not worth the effort.
- patch up an outdated and now incorrect comment"
* 'upstream' of git://git.linux-mips.org/pub/scm/ralf/upstream-linus:
MIPS: fpu.h: Allow 64-bit FPU on a 64-bit MIPS R6 CPU
MIPS: SB1: Remove support for Pass 1 parts.
MIPS: Require O32 FP64 support for MIPS64 with O32 compat
MIPS: asm-offset.c: Patch up various comments refering to the old filename.
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Commit 6134d94923d0 ("MIPS: asm: fpu: Allow 64-bit FPU on MIPS32 R6")
added support for 64-bit FPU on a 32-bit MIPS R6 processor but it missed
the 64-bit CPU case leading to FPU failures when requesting FR=1 mode
(which is always the case for MIPS R6 userland) when running a 32-bit
kernel on a 64-bit CPU. We also fix the MIPS R2 case.
Signed-off-by: Markos Chandras <markos.chandras@imgtec.com>
Fixes: 6134d94923d0 ("MIPS: asm: fpu: Allow 64-bit FPU on MIPS32 R6")
Reviewed-by: Paul Burton <paul.burton@imgtec.com>
Cc: <stable@vger.kernel.org> # 4.0+
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/10734/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Pass 1 parts had a number of significant erratas and were only available
in small numbers and under NDA. Full support also required the use of a
special toolchain that kept branches properly aligned. These workarounds
were never upstreamed and the only toolchain known to have them is
Montavista's GCC 3.0-based toolchain which completly obsoleted if not
useless these days.
So now that automated testing has tripped over the user of the
-msb1-pass1-workarounds option, rather than fixing it remove support for
pass 1 parts.
Probably nobody will notice. I seem to own the last know pass 1 board
and I haven't noticed another one in the wild in the past decade, at
least.
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
MIPS32r6 code requires FP64 (ie. FR=1) support. Building a kernel with
support for MIPS32r6 binaries but without support for O32 with FP64 is
therefore a problem which can lead to incorrectly executed userland.
CONFIG_MIPS_O32_FP64_SUPPORT is already selected when the kernel is
configured for MIPS32r6, but not when the kernel is configured for
MIPS64r6 with O32 compat support. Select CONFIG_MIPS_O32_FP64_SUPPORT in
such configurations to prevent building kernels which execute MIPS32r6
userland incorrectly.
Signed-off-by: Paul Burton <paul.burton@imgtec.com>
Cc: Markos Chandras <markos.chandras@imgtec.com>
Cc: <stable@vger.kernel.org> # v4.0-
Cc: linux-mips@linux-mips.org
Cc: Matthew Fortune <matthew.fortune@imgtec.com>
Cc: stable@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Patchwork: https://patchwork.linux-mips.org/patch/10674/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
|
| | |/ / /
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
arch/mips/tools/offset.c was renamed to arch/mips/kernel/asm-offsets.c
for v2.6.14.
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
|
| |\ \ \ \
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux
Pull parisc fix from Helge Deller:
"A memory leak fix from Christophe Jaillet which was introduced with
kernel 4.0 and which leads to kernel crashes on parisc after 1-3 days"
* 'parisc-4.2-2' of git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux:
parisc: mm: Fix a memory leak related to pmd not attached to the pgd
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Commit 0e0da48dee8d ("parisc: mm: don't count preallocated pmds")
introduced a memory leak.
After this commit, the 'return' statement in pmd_free is executed in all
cases. Even for pmd that are not attached to the pgd. So 'free_pages'
can never be called anymore, leading to a memory leak.
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Acked-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Acked-by: Mikulas Patocka <mpatocka@redhat.com>
Acked-by: Helge Deller <deller@gmx.de>
Cc: stable@vger.kernel.org # v4.0+
Signed-off-by: Helge Deller <deller@gmx.de>
|
| |\ \ \ \ \
| |/ / / /
|/| | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc
Pull ARM SoC fixes from Olof Johansson:
"By far most of the fixes here are updates to DTS files to deal with
some mostly minor bugs.
There's also a fix to deal with non-PM kernel configs on i.MX, a
regression fix for ethernet on PXA platforms and a dependency fix for
OMAP"
* tag 'armsoc-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc:
ARM: keystone: dts: rename pcie nodes to help override status
ARM: keystone: dts: fix dt bindings for PCIe
ARM: pxa: fix dm9000 platform data regression
ARM: dts: Correct audio input route & set mic bias for am335x-pepper
ARM: OMAP2+: Add HAVE_ARM_SCU for AM43XX
MAINTAINERS: digicolor: add dts files
ARM: ux500: fix MMC/SD card regression
ARM: ux500: define serial port aliases
ARM: dts: OMAP5: Add #iommu-cells property to IOMMUs
ARM: dts: OMAP4: Add #iommu-cells property to IOMMUs
ARM: dts: Fix frequency scaling on Gumstix Pepper
ARM: dts: configure regulators for Gumstix Pepper
ARM: dts: omap3: overo: Update LCD panel names
ARM: dts: cros-ec-keyboard: Add support for some Japanese keys
ARM: imx6: gpc: always enable PU domain if CONFIG_PM is not set
ARM: dts: imx53-qsb: fix TVE entry
ARM: dts: mx23: fix iio-hwmon support
ARM: dts: imx27: Adjust the GPT compatible string
ARM: socfpga: dts: Fix entries order
ARM: socfpga: dts: Fix adxl34x formating and compatible string
|
| | |\ \ \ \
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Merge "pxa fixes for v4.2" from Robert Jarzmik:
ARM: pxa: fixes for v4.2-rc2
This single fix reenables ethernet cards for several pxa boards,
broken by regulator addition to dm9000 driver.
* tag 'pxa-fixes-v4.2-rc2' of https://github.com/rjarzmik/linux:
ARM: pxa: fix dm9000 platform data regression
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Since dm9000 driver added support for a vcc regulator, platform data
based platforms have their ethernet broken, as the regulator claiming
returns -EPROBE_DEFER and prevents dm9000 loading.
This patch fixes this for all pxa boards using dm9000, by using the
specific regulator_has_full_constraints() function.
This was discovered and tested on the cm-x300 board.
Fixes: 7994fe55a4a2 ("dm9000: Add regulator and reset support to dm9000")
Signed-off-by: Robert Jarzmik <robert.jarzmik@free.fr>
Acked-by: Igor Grinberg <grinberg@compulab.co.il>
|
| | |\ \ \ \ \
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
git://git.kernel.org/pub/scm/linux/kernel/git/ssantosh/linux-keystone into fixes
Merge "ARM: Couple of dts fixes for v4.2-rcx" from Santosh Shilimkar:
Couple of DTS fixes 4.2-rcx for Keystone EVMs:
K2E EVM boot hangs because of missing serdes driver which is needed to bring up
PCIe on K2E. These couple of fixes makes the PCIE disabled on common default and
let the specific board DTS to enable it.
* tag 'keystone-dts-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/ssantosh/linux-keystone:
ARM: keystone: dts: rename pcie nodes to help override status
ARM: keystone: dts: fix dt bindings for PCIe
Signed-off-by: Olof Johansson <olof@lixom.net>
|
| | | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
Now that PCIe DT binding is disabled in SoC specific DTS,
we need a way to override it in a board specific DTS. So
rename the PCIe nodes accordingly.
Signed-off-by: Murali Karicheri <m-karicheri2@ti.com>
Signed-off-by: Santosh Shilimkar <ssantosh@kernel.org>
|
| | | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
Currently PCIe DT bindings are broken. PCIe driver can't function
without having a SerDes driver that provide the phy configuration.
On K2E EVM, this causes problem since the EVM has Marvell SATA
controller present and with default values in the SerDes register,
it seems to pass the PCIe link check, but causes issues since
the configuration is not correct. The manifestation is that when
EVM is booted with NFS rootfs, the boot hangs. We shouldn't enable
PCIe on this EVM since to work, SerDes driver has to be present as
well. So by default, the PCIe DT binding should be disabled in SoC
specific DTS. It can be enabled in the board specific DTS when the
SerDes device driver is also present.
So fix the status of PCIe DT bindings in the SoC specific DTS to
"disabled". To enable PCIe, the status should be set to "ok" in
the EVM DTS file when SerDes driver support becomes available in
the upstream tree.
Signed-off-by: Murali Karicheri <m-karicheri2@ti.com>
Signed-off-by: Santosh Shilimkar <ssantosh@kernel.org>
|
| | |\ \ \ \ \ \
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | | |
git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap into fixes
Fixes for omaps, all dts changes except for one:
- Fix up LCD panel name for overo boards
- Three fixes for pepper board for regulators, freqeuncy
scaling and audio input. Note that there is still one
issue being worked on for booting with multi_v7_defconfig
- Add missing #iommu-cells for omap4 and 5
- Add missing HAVE_ARM_SCU for am43xx
* tag 'omap-for-v4.2/fixes-rc2-v2' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap: (210 commits)
ARM: dts: Correct audio input route & set mic bias for am335x-pepper
ARM: OMAP2+: Add HAVE_ARM_SCU for AM43XX
ARM: dts: OMAP5: Add #iommu-cells property to IOMMUs
ARM: dts: OMAP4: Add #iommu-cells property to IOMMUs
ARM: dts: Fix frequency scaling on Gumstix Pepper
ARM: dts: configure regulators for Gumstix Pepper
ARM: dts: omap3: overo: Update LCD panel names
+ Linux 4.2-rc2
Signed-off-by: Olof Johansson <olof@lixom.net>
|
| | | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | | |
Audio-in was incorrectly routed to Line In. It should be Mic3L as per
schematic.
Using mic-bias voltage at 2.0v (<0x1>) does not work for some reason. There
is no voltage seen on micbias (R127). Mic-bias voltage of 2.5v (<0x2>) works.
I see voltage of 2.475v across GND and micbias.
With these changes, I can record audio with a pair of proliferate TRRS earbuds.
Signed-off-by: Adam YH Lee <adam.yh.lee@gmail.com>
Acked-by: Ash Charles <ashcharles@gmail.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
|
| | | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | | |
CONFIG_HAVE_ARM_SCU only gets selected if CONFIG_SMP is selected in an OMAP
system, however AM43XX needs this option regardless of CONFIG_SMP and also
for an AM43XX only build as it is important for controlling power in the SoC.
Without this we cannot suspend the CPU for SoC suspend or cpuidle. The
ARM Cortex A9 needs SCU CPU Power Status bits to be set to off mode in order
for the PRCM to transition the MPU to low power modes.
Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
|
| | | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | | |
Add missing #iommu-cells property to the DSP and IPU IOMMU nodes
for OMAP5 platforms. This property is required as per the generic
iommu binding.
Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
|
| | | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | | |
Add missing #iommu-cells property to the DSP and IPU IOMMU nodes
for OMAP4 platforms. This property is required as per the generic
iommu binding.
Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
|
| | | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | | |
The device tree for Gumstix Pepper has DCDC2 and
DCDC3 correctly labelled but the upper limit values
are wrong. The confusion is due to the hardware
quirk where the DCDC2 and DCDC3 wires are flipped
in Pepper.
Signed-off-by: Arun Bharadwaj <arun@gumstix.com>
Tested-by: Ash Charles <ashcharles@gmail.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
|
| | | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | | |
Boot process is halting in midway because some of the necessary voltage
regulators are deemed unused and subsequently powered off, leading to
a completely unresponsive system.
Most of the device nodes had correct voltage regulator attachments.
Yet these nodes had to set stricter enforcement on them through
'regulator-boot-on' and 'regulator-always-on' to function correctly.
The consumers of the regulators this commit affect are the followings:
DCDC1: vdd_1v8 system supply, USB-PHY, and ADC
DCDC2: Core domain
DCDC3: MPU core domain
LDO1: RTC
LDO2: 3v3 IO domain
LDO3: USB-PHY; not a boot-time requirement
LDO4: LCD [16:23]
All but LDO3 need to be always-on for the system to be functional.
Additionally regulator-name properties have been added for the kernel to
display the name from the schematic. This will improve diagnostics.
Signed-off-by: Adam YH Lee <adam.yh.lee@gmail.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
|
| | | | |_|/ / /
| | |/| | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
For Gumstix Overo COMs, the u-boot bootloader typically passes an
argument specifying the default display via the omapdss.def_disp
parameter. When a default display is specified, DSS2 tries to match
this name with either the device tree label (e.g. label=dvi) or,
failing this, the device tree alias (e.g. label=display0). Update the
panel names for the 'lcd43' and 'lcd35' displays in the device tree
such that they match the names passed by u-boot.
Signed-off-by: Ash Charles <ashcharles@gmail.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
|
