Operations which modify extended attributes may need extra journal
credits if inline data is used, since there is a chance that some
extended attributes may need to get pushed to an external attribute
block.
Changes to reflect this was made in xattr.c, but they were missed in
fs/ext4/acl.c. To fix this, abstract the calculation of the number of
credits needed for xattr operations to an inline function defined in
ext4_jbd2.h, and use it in acl.c and xattr.c.
Also move the function declarations used in inline.c from xattr.h
(where they are non-obviously hidden, and caused problems since
ext4_jbd2.h needs to use the function ext4_has_inline_data), and move
them to ext4.h.
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Reviewed-by: Tao Ma <boyu.mt@taobao.com>
Reviewed-by: Jan Kara <jack@suse.cz>
The ext4_unlink() and ext4_rmdir() don't actually release the blocks
associated with the file/directory. This gets done in a separate jbd2
handle called via ext4_evict_inode(). Thus, we don't need to reserve
lots of journal credits for the truncate.
Note that using too many journal credits is non-optimal because it can
leading to the journal transmit getting closed too early, before it is
strictly necessary.
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Reviewed-by: Jan Kara <jack@suse.cz>
i2400m_net_wake_tx() sets ->wake_tx_skb with the given skb if
->wake_tx_ws is not pending; however, i2400m_wake_tx_work() could have
just started execution and haven't fetched -><wake_tx_skb yet. The
previous packet will be leaked.
Update ->wake_tx_skb handling.
* i2400m_net_wake_tx() now tests whether the previous ->wake_tx_skb
has been consumed by ->wake_tx_ws instead of testing work_pending().
* i2400m_net_wake_stop() is simplified similarly. It always puts
->wake_tx_skb if non-NULL.
* Spurious ->wake_tx_skb dereference outside critical section dropped
from i2400m_wake_tx_work().
Only compile tested.
Signed-off-by: Tejun Heo <tj@kernel.org>
Acked-by: Dan Williams <dcbw@redhat.com>
Cc: Inaky Perez-Gonzalez <inaky.perez-gonzalez@intel.com>
Cc: linux-wimax@intel.com
Cc: wimax@linuxwimax.org
wait_for_kprobe_optimizer() seems largely broken. It uses
optimizer_comp which is never re-initialized, so
wait_for_kprobe_optimizer() will never wait for anything once
kprobe_optimizer() finishes all pending jobs for the first time.
Also, aside from completion, delayed_work_pending() is %false once
kprobe_optimizer() starts execution and wait_for_kprobe_optimizer()
won't wait for it.
Reimplement it so that it flushes optimizing_work until
[un]optimizing_lists are empty. Note that this also makes
optimizing_work execute immediately if someone's waiting for it, which
is the nicer behavior.
Only compile tested.
Signed-off-by: Tejun Heo <tj@kernel.org>
Acked-by: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
Cc: Ananth N Mavinakayanahalli <ananth@in.ibm.com>
Cc: Anil S Keshavamurthy <anil.s.keshavamurthy@intel.com>
Cc: "David S. Miller" <davem@davemloft.net>
* Drop unnesssary delayd_work_pending() tests.
* Unify scan_event_{now|later} by using mod_delayed_work() w/ 0 delay
for scan_event_now.
* Make ipw2200 scan_event handling match ipw2100 - use
mod_delayed_work() w/ 0 delay for immediate scanning.
Only compile tested.
Signed-off-by: Tejun Heo <tj@kernel.org>
Acked-by: Stanislav Yakovlev <stas.yakovlev@gmail.com>
Cc: linux-wireless@vger.kernel.org
The migration ioctl creates a temporary inode. Since this inode is
never linked to a directory, we don't need to reserve journal credits
required for modifying the directory.
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Reviewed-by: Jan Kara <jack@suse.cz>
Update the da8xx_restart() function to support machine reboot
when booting using DT. Have the function search for the watchdog
platform device instead of always using "da8xx_wdt_device" which
is never registered in DT case.
While at it, also make da8xx_wdt_device static since there is no need
for it to be globally visible.
Tested machine reboot with both DT and non-DT boot on DA850 EVM.
Signed-off-by: Kumar, Anil <anilkumar.v@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
Add I2C0 device tree and pin muxing information to da850-evm.
Also, add OF_DEV_AUXDATA for I2C0 controller driver in da850
board dt file to use I2C0 clock.
Verified i2c0 node gets created in sys class interface as
"/sys/class/i2c-dev/i2c-0/subsystem/i2c-0".
nsekhar@ti.com: tested using i2cdetect and i2cdump.
Signed-off-by: Vishwanathrao Badarkhe, Manish <manishv.b@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
Partly a case of removing unused headers and partly a case
of ifdefing out the iio_trigger_ops structures. This has
come about because of an 'unusual' separation of code in this
driver.
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Reported-by: Randy Dunlap <rdunlap@infradead.org>
Acked-by: Denis Ciocca <denis.ciocca@st.com>
Also include a couple of forward defs of struct iio_trigger and struct
iio_trigger_ops to avoid doing this in each driver.
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Reported-by: Randy Dunlap <rdunlap@infradead.org>
Acked-by: Denis Ciocca <denis.ciocca@st.com>
Don't start the jbd2 transaction handle until after the directory
entry has been found, to minimize the amount of time that a handle is
held active.
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Reviewed-by: Jan Kara <jack@suse.cz>
Don't start the jbd2 transaction handle until after the directory
entry has been found, to minimize the amount of time that a handle is
held active.
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Reviewed-by: Jan Kara <jack@suse.cz>
The grab_cache_page_write_begin() function can potentially sleep for a
long time, since it may need to do memory allocation which can block
if the system is under significant memory pressure, and because it may
be blocked on page writeback. If it does take a long time to grab the
page, it's better that we not hold an active jbd2 handle.
So grab a handle on the page first, and _then_ start the transaction
handle.
This commit fixes the following long transaction handle hold time:
postmark-2917 [000] .... 196.435786: jbd2_handle_stats: dev 254,32
tid 570 type 2 line_no 2541 interval 311 sync 0 requested_blocks 1
dirtied_blocks 0
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Reviewed-by: Jan Kara <jack@suse.cz>
In two places, we check !CONFIG_MMU_SUN3 while we should check
CONFIG_HAS_DMA instead.
While fixing this, the check in <asm/dma-mapping.h> became redundant
(<linux/dma-mapping.h> already handles this case), so just remove it.
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
With the recent changes in cpufreq core, we just need to set mask of all
possible cpus into policy->cpus. Rest would be done by core.
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
The Marvell Kirkwood SoCs have simple cpufreq support in hardware. The
CPU can either use the a high speed cpu clock, or the slower DDR
clock. Add a driver to swap between these two clock sources.
Signed-off-by: Andrew Lunn <andrew@lunn.ch>
Acked-by: Jason Cooper <jason@lakedaemon.net>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Add a P-state driver for the Intel Sandy bridge processor. In cpufreq
terminology this driver implements a scaling driver with an internal
governor.
When built into the the kernel this driver will be the preferred
scaling driver for Sandy bridge processors.
In addition to the interfaces provided by the cpufreq subsystem for
controlling scaling drivers. The user may control the behavior of the
driver via three sysfs files located in
"/sys/devices/system/cpu/intel_pstate".
max_perf_pct: limits the maximum P state that will be requested by
the driver stated as a percentage of the avail performance.
min_perf_pct: limits the minimum P state that will be requested by
the driver stated as a percentage of the avail performance.
no_turbo: limits the driver to selecting P states below the turbo
frequency range.
Signed-off-by: Dirk Brandewie <dirk.j.brandewie@intel.com>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
The sysfs files for cpufreq_stats are created in cpufreq_stats_create_table()
called from cpufreq_stat_notifier_policy() when a policy is added to
the cpu. cpufreq_stats_create_table() will not be called if the
scaling driver does not export a frequency table to cpufreq. Use the
same fence on tear down.
Signed-off-by: Dirk Brandewie <dirk.j.brandewie@intel.com>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Scaling drivers that implement internal governors do not have governor
structures assocaited with them. Only track the name of the governor
associated with the CPU if the driver does not implement
cpufreq_driver.setpolicy()
Signed-off-by: Dirk Brandewie <dirk.j.brandewie@intel.com>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Scaling drivers that implement cpufreq_driver.setpolicy() have
internal governors that do not signal changes via
cpufreq_notify_transition() so the frequncy in the policy will almost
certainly be different than the current frequncy. Only call
cpufreq_out_of_sync() when the underlying driver implements
cpufreq_driver.target()
Signed-off-by: Dirk Brandewie <dirk.j.brandewie@intel.com>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Scaling drivers that implement the cpufreq_driver.setpolicy() versus
the cpufreq_driver.target() interface do not set policy->cur.
Normally policy->cur is set during the call to cpufreq_driver.target()
when the frequnecy request is made by the governor.
If the scaling driver implements cpufreq_driver.setpolicy() and
cpufreq_driver.get() interfaces use cpufreq_driver.get() to retrieve
the current frequency.
Signed-off-by: Dirk Brandewie <dirk.j.brandewie@intel.com>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Use the new spi_sync_transfer() helper function instead of open-coding it.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Use the new spi_sync_transfer() helper function instead of open-coding it.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Quite often the pattern used for setting up and transferring a synchronous SPI
transaction looks very much like the following:
struct spi_message msg;
struct spi_transfer xfers[] = {
...
};
spi_message_init(&msg);
spi_message_add_tail(&xfers[0], &msg);
...
spi_message_add_tail(&xfers[ARRAY_SIZE(xfers) - 1], &msg);
ret = spi_sync(&msg);
This patch adds two new helper functions for handling this case. The first
helper function spi_message_init_with_transfers() takes a spi_message and an
array of spi_transfers. It will initialize the message and then call
spi_message_add_tail() for each transfer in the array. E.g. the following
spi_message_init(&msg);
spi_message_add_tail(&xfers[0], &msg);
...
spi_message_add_tail(&xfers[ARRAY_SIZE(xfers) - 1], &msg);
can be rewritten as
spi_message_init_with_transfers(&msg, xfers, ARRAY_SIZE(xfers));
The second function spi_sync_transfer() takes a SPI device and an array of
spi_transfers. It will allocate a new spi_message (on the stack) and add all
transfers in the array to the message. Finally it will call spi_sync() on the
message.
E.g. the follwing
struct spi_message msg;
struct spi_transfer xfers[] = {
...
};
spi_message_init(&msg);
spi_message_add_tail(&xfers[0], &msg);
...
spi_message_add_tail(&xfers[ARRAY_SIZE(xfers) - 1], &msg);
ret = spi_sync(spi, &msg);
can be rewritten as
struct spi_transfer xfers[] = {
...
};
ret = spi_sync_transfer(spi, xfers, ARRAY_SIZE(xfers));
A coccinelle script to find such instances will follow.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Reviewed-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
The following warning is generated by sparse:
drivers/staging/iio/adc/mxs-lradc.c:118:47: warning: duplicate const
Remove the duplicate const.
Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Re-implement gpiochip_find_base using the list of chips instead of the
global gpio_desc[] array. This makes it both simpler and more efficient,
and is needed to remove the global descriptors array.
The new code should preserve the exact same GPIO number assignment
policy as the code it is replacing. There shouldn't be any visible
change to the assigned GPIO numbers.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
[grant.likely: Added comment about assignment policy]
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
This makes the code both simpler and faster compared to parsing the GPIO
number space.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
Add a list member to gpio_chip that allows all chips to be parsed
quickly. The current method requires parsing the entire GPIO integer
space, which is painfully slow. Using a list makes many chip operations
that involve lookup or parsing faster, and also simplifies the code. It
is also necessary to eventually get rid of the global gpio_desc[] array.
The list of gpio_chips is always ordered by base GPIO number to ensure
chips traversal is done in the right order.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
So we can better understand what bits of ext4 are responsible for
long-running jbd2 handles, use jbd2__journal_start() so we can pass
context information for logging purposes.
The recommended way for finding the longer-running handles is:
T=/sys/kernel/debug/tracing
EVENT=$T/events/jbd2/jbd2_handle_stats
echo "interval > 5" > $EVENT/filter
echo 1 > $EVENT/enable
./run-my-fs-benchmark
cat $T/trace > /tmp/problem-handles
This will list handles that were active for longer than 20ms. Having
longer-running handles is bad, because a commit started at the wrong
time could stall for those 20+ milliseconds, which could delay an
fsync() or an O_SYNC operation. Here is an example line from the
trace file describing a handle which lived on for 311 jiffies, or over
1.2 seconds:
postmark-2917 [000] .... 196.435786: jbd2_handle_stats: dev 254,32
tid 570 type 2 line_no 2541 interval 311 sync 0 requested_blocks 1
dirtied_blocks 0
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
randconfig complains about:
drivers/power/da9030_battery.c:113: error: field ‘nb’ has incomplete type
because there is no direct include for notifier.h which defines
struct notifier_block.
Signed-off-by: Michal Hocko <mhocko@suse.cz>
Signed-off-by: Anton Vorontsov <anton@enomsg.org>
>From: Roland Eggner <edvx1@systemanalysen.net>
More reasonable labels of function keys line. Rename labels and keep menu
width, as required for fitting on COLUMNS=80 terminals:
• s/Insts/Help 2/
• s/Config/ShowAll/
Signed-off-by: Roland Eggner <edvx1@systemanalysen.net>
Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
>From: Roland Eggner <edvx1@systemanalysen.net>
Rewrite all help texts. During several years lazy (incomplete) updates have
left behind a rather thick layer of dust. Intentions:
(1) Global help called by <F1> should document all _currently_ implemented
keybindings.
(2) Different help texts called by <F3> resp. <F8><F1> should be consistent
with (1) and with implementation:
• on plain menu entry
• in radiolist window
• in input windows for text, decimal or hexadecimal values
• in filename selection windows <F6> <F7>
• SymSearch specific help called by <F8> followed by <F1>
(3) More reasonable window titles:
Rename window title s/README/Global help/
Rename variable s/nconf_readme/nconf_global_help/
Rename window title s/Instructions/Short help/
(4) Consider which hints are most useful for first-time-users.
Signed-off-by: Roland Eggner <edvx1@systemanalysen.net>
Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
[yann.morin.1998@free.fr: a few additional fixes]
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Remove the assumption that cstate_tables are
indexed by MWAIT flag values. Each entry
identifies itself via its own flags value.
This change is needed to support multiple states
that share the same MWAIT flags.
Note that this can have an effect on what state is described
by 'N' on cmdline intel_idle.max_cstate=N on some systems.
intel_idle.max_cstate=0 still disables the driver
intel_idle.max_cstate=1 still results in just C1(E)
However, "place holders" in the sparse C-state name-space
(eg. Atom) have been removed.
Signed-off-by: Len Brown <len.brown@intel.com>
Cosmetic only.
Replace use of MWAIT_MAX_NUM_CSTATES with CPUIDLE_STATE_MAX.
They are both 8, so this patch has no functional change.
The reason to change is that intel_idle will soon be able
to export more than the 8 "major" states supported by MWAIT.
When we hit that limit, it is important to know
where the limit comes from.
Signed-off-by: Len Brown <len.brown@intel.com>
When verbose is enabled, print the C1E-Enable
bit in MSR_IA32_POWER_CTL.
also delete some redundant tests on the verbose variable.
Signed-off-by: Len Brown <len.brown@intel.com>
This patch enables turbostat to run properly on the
next-generation Intel(R) Microarchitecture, code named "Haswell" (HSW).
HSW supports the BCLK and counters found in SNB.
Signed-off-by: Len Brown <len.brown@intel.com>
This patch enables intel_idle to run on the
next-generation Intel(R) Microarchitecture code named "Haswell".
Signed-off-by: Len Brown <len.brown@intel.com>
cpufreq core uses two locks:
- cpufreq_driver_lock: General lock for driver and cpufreq_cpu_data array.
- cpu_policy_rwsemfix locking: per CPU reader-writer semaphore designed to cure
all cpufreq/hotplug/workqueue/etc related lock issues.
These locks were not used properly and are placed against their principle
(present before their definition) at various places. This patch is an attempt to
fix their use.
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
On the lines of macro: lock_policy_rwsem, we can create another macro for
unlock_policy_rwsem. Lets do it.
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Because the sibling cpu of any online cpu is identified very early in
cpufreq_add_dev(), below code is never executed. And so can be removed.
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
On multi-policy systems there is a single instance of governor for both the
policies (if same governor is chosen for both policies). With the code update
from following patches:
8eeed09 cpufreq: governors: Get rid of dbs_data->enable field
b394058 cpufreq: governors: Reset tunables only for cpufreq_unregister_governor()
We are creating/removing sysfs directory of governor for for every call to
GOV_START and STOP. This would fail for multi-policy system as there is a
per-policy call to START/STOP.
This patch reuses the governor->initialized variable to detect total users of
governor.
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
In order to avoid the calculation of up_threshold - down_differential
every time that the frequency must be decreased, we replace the
down_differential tuner with the adj_up_threshold which keeps the
difference across multiple checks.
Update the adj_up_threshold only when the up_theshold is also updated.
Signed-off-by: Stratos Karafotis <stratosk@semaphore.gr>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>