| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm into gpio/next
|
|
commit cfadd838(powerpc/8xxx: Fix interrupt handling in MPC8xxx GPIO
driver) added an unconditional call of chip->irq_eoi() to the demux
handler.
This leads to a NULL pointer derefernce on MPC512x platforms which use
this driver as well.
Make it conditional.
Reported-by: Thomas Wucher <[email protected]>
Signed-off-by: Thomas Gleixner <[email protected]>
Cc: Felix Radensky <[email protected]>
Cc: Kumar Gala <[email protected]>
Cc: Grant Likely <[email protected]>
Cc: [email protected]
Signed-off-by: Grant Likely <[email protected]>
|
|
This patch adds device tree support for gpio-lpc32xx.c.
To register the various GPIO banks as (struct) gpio_chips via the same DT
gpio-controller, we utilize the adjusted of_xlate API to manipulate the
actually used struct gpio_chip.
Signed-off-by: Roland Stigge <[email protected]>
Reviewed-by: Arnd Bergmann <[email protected]>
Signed-off-by: Grant Likely <[email protected]>
|
|
This patch changes the of_xlate API to make it possible for multiple
gpio_chips to refer to the same device tree node. This is useful for
banked GPIO controllers that use multiple gpio_chips for a single
device. With this change the core code will try calling of_xlate on
each gpio_chip that references the device_node and will return the
gpio number for the first one to return 'true'.
Tested-by: Roland Stigge <[email protected]>
Acked-by: Arnd Bergmann <[email protected]>
Signed-off-by: Grant Likely <[email protected]>
|
|
Allow drivers to use the modern request and configure idiom together
with devres.
As with plain gpio_request() and gpio_request_one() we can't implement
the old school version in terms of _one() as this would force the
explicit selection of a direction in gpio_request() which could break
systems if we pick the wrong one. Implementing devm_gpio_request_one()
in terms of devm_gpio_request() would needlessly complicate things or
lead to duplication from the unmanaged version depending on how it's
done.
Signed-off-by: Mark Brown <[email protected]>
Acked-by: Linus Walleij <[email protected]>
Signed-off-by: Grant Likely <[email protected]>
|
|
Pullups are enabled when bits are set, not when cleared.
Signed-off-by: Peter Korsgaard <[email protected]>
Signed-off-by: Grant Likely <[email protected]>
|
|
This patch extends the PCA953x driver to support TI's TCA6424A 24 bit I2C I/O expander. The patch is based on code by Michele
Bevilacqua.
Changes in v2:
- Compare ngpio against 24 in both places, not >16
- Larger datatype now u32 instead of uint.
Bit fields not used for struct members since their address is taken.
- Be precise: TCA6424A (untested for older TCA6424)
Signed-off-by: Andreas Schallenberg<[email protected]>
Acked-by: Linus Walleij <[email protected]>
Signed-off-by: Grant Likely <[email protected]>
|
|
commit 1b1287032 (gpio/omap: fix missing check in *_runtime_suspend())
broke wakeups on level-triggered GPIOs by adding the enabled
non-wakeup GPIO check before the workaround that enables wakeups
on level-triggered IRQs, effectively disabling that workaround.
To fix, move the enabled non-wakeup GPIO check after the
level-triggered IRQ workaround.
Reported-by: Tony Lindgren <[email protected]>
Tested-by: Tony Lindgren <[email protected]>
Acked-by: Santosh Shilimkar <[email protected]>
Acked-by: Tarun Kanti DebBarma <[email protected]>
Tested-by: Tarun Kanti DebBarma <[email protected]>
Signed-off-by: Kevin Hilman <[email protected]>
|
|
The fix in commit 1b1287032 (gpio/omap: fix missing check in
*_runtime_suspend()) exposed another bug in the context restore path.
Currently, the per-bank context restore happens whenever the context
loss count is different in runtime suspend and runtime resume *and*
whenever the per-bank contex_loss_count == 0:
if (context_lost_cnt_after != bank->context_loss_count ||
!context_lost_cnt_after) {
omap_gpio_restore_context(bank);
Restoring context when the context_lost_cnt_after == 0 is clearly
wrong, since this will be true until the first off-mode transition
(which could be never, if off-mode is never enabled.) This check
causes the context to be restored on *every* runtime PM transition.
Before commit 1b1287032 (gpio/omap: fix missing check in
*_runtime_suspend()), this code was never executed in non-OFF mode, so
there were never spurious context restores happening. After that
change though, spurious context restores could happen.
To fix, simply remove the !context_lost_cnt_after check. It is not
needed.
This bug was found when noticing that the smc911x NIC on 3530/Overo
was not working, and git bisect tracked it down to this patch. It
seems that the spurious context restore was causing the smsc911x to
not be properly probed on this platform.
Tested-by: Tony Lindgren <[email protected]>
Acked-by: Tarun Kanti DebBarma <[email protected]>
Cc: Santosh Shilimkar <[email protected]>
Signed-off-by: Kevin Hilman <[email protected]>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm into gpio/next
|
|
We do checking for bank->enabled_non_wakeup_gpios in order
to skip redundant operations. Somehow, the check got missed
while doing the cleanup series.
Just to make sure that we do context restore correctly in
*_runtime_resume(), the bank->workaround_enabled check is
moved after context restore. Otherwise, it would prevent
context restore when bank->enabled_non_wakeup_gpios is 0.
Cc: Kevin Hilman <[email protected]>
Cc: Tony Lindgren <[email protected]>
Cc: Santosh Shilimkar <[email protected]>
Cc: Cousson, Benoit <[email protected]>
Cc: Grant Likely <[email protected]>
Signed-off-by: Tarun Kanti DebBarma <[email protected]>
Reviewed-by: Santosh Shilimkar <[email protected]>
Tested-by: Govindraj.R <[email protected]>
Signed-off-by: Kevin Hilman <[email protected]>
|
|
Add register offsets for GPIO_IRQSTATUS_RAW_0, GPIO_IRQSTATUS_RAW_0
which are present on OMAP4+ processors. Now we can distinguish
conditions applicable to OMAP4,5 and those specific to OMAP24xx
and OMAP3xxx.
Cc: Kevin Hilman <[email protected]>
Cc: Tony Lindgren <[email protected]>
Cc: Santosh Shilimkar <[email protected]>
Cc: Cousson, Benoit <[email protected]>
Cc: Grant Likely <[email protected]>
Signed-off-by: Tarun Kanti DebBarma <[email protected]>
Reviewed-by: Santosh Shilimkar <[email protected]>
Tested-by: Govindraj.R <[email protected]>
Signed-off-by: Kevin Hilman <[email protected]>
|
|
Both omap_gpio_suspend() and omap_gpio_resume() does programming
of wakeup_en register.
_gpio_rmw(base, bank->regs->wkup_en, 0xffffffff, 0);
_gpio_rmw(base, bank->regs->wkup_en, bank->context.wake_en, 1);
This is redundant in omap_gpio_suspend() because wakeup_en
register automatically gets initialized in _set_gpio_wakeup()
and set_gpio_trigger() while being called either from
chip.irq_set_wake() or chip.irq_set_type().
This is also redundant in omap_gpio_resume() because wakeup_en
register is programmed in omap_gpio_restore_context() called
which is called from runtime resume callback.
Cc: Kevin Hilman <[email protected]>
Cc: Tony Lindgren <[email protected]>
Cc: Santosh Shilimkar <[email protected]>
Cc: Cousson, Benoit <[email protected]>
Cc: Grant Likely <[email protected]>
Signed-off-by: Tarun Kanti DebBarma <[email protected]>
Reviewed-by: Santosh Shilimkar <[email protected]>
Tested-by: Govindraj.R <[email protected]>
Signed-off-by: Kevin Hilman <[email protected]>
|
|
commit 672e302e3c (ARM: OMAP: use edge/level handlers from generic IRQ
framework) removed retrigger support in favor of using generic IRQ
framework. This patch cleans up some unused remnants of that removal.
Cc: Kevin Hilman <[email protected]>
Cc: Tony Lindgren <[email protected]>
Cc: Santosh Shilimkar <[email protected]>
Cc: Cousson, Benoit <[email protected]>
Cc: Grant Likely <[email protected]>
Signed-off-by: Tarun Kanti DebBarma <[email protected]>
Reviewed-by: Santosh Shilimkar <[email protected]>
Acked-by: Felipe Balbi <[email protected]>
Tested-by: Govindraj.R <[email protected]>
Signed-off-by: Kevin Hilman <[email protected]>
|
|
There is no more need to have saved_wakeup because bank->context.wake_en
already holds that value. So getting rid of read/write operation associated
with this field.
Cc: Kevin Hilman <[email protected]>
Cc: Tony Lindgren <[email protected]>
Cc: Santosh Shilimkar <[email protected]>
Cc: Cousson, Benoit <[email protected]>
Cc: Grant Likely <[email protected]>
Signed-off-by: Tarun Kanti DebBarma <[email protected]>
Reviewed-by: Santosh Shilimkar <[email protected]>
Acked-by: Felipe Balbi <[email protected]>
Tested-by: Govindraj.R <[email protected]>
Signed-off-by: Kevin Hilman <[email protected]>
|
|
Since we already have bank->context.wake_en to keep track
of gpios which are wakeup enabled, there is no need to have
this field any more.
Cc: Kevin Hilman <[email protected]>
Cc: Tony Lindgren <[email protected]>
Cc: Santosh Shilimkar <[email protected]>
Cc: Cousson, Benoit <[email protected]>
Cc: Grant Likely <[email protected]>
Signed-off-by: Tarun Kanti DebBarma <[email protected]>
Reviewed-by: Santosh Shilimkar <[email protected]>
Acked-by: Felipe Balbi <[email protected]>
Tested-by: Govindraj.R <[email protected]>
Signed-off-by: Kevin Hilman <[email protected]>
|
|
Since we already have context.fallingdetect and context.risingdetect
there is no more need to have these additional fields. Also, getting
rid of extra reads associated with them.
Cc: Kevin Hilman <[email protected]>
Cc: Tony Lindgren <[email protected]>
Cc: Santosh Shilimkar <[email protected]>
Cc: Cousson, Benoit <[email protected]>
Cc: Grant Likely <[email protected]>
Signed-off-by: Tarun Kanti DebBarma <[email protected]>
Reviewed-by: Santosh Shilimkar <[email protected]>
Acked-by: Felipe Balbi <[email protected]>
Tested-by: Govindraj.R <[email protected]>
Signed-off-by: Kevin Hilman <[email protected]>
|
|
This cleanup got missed while implementing following:
25db711 gpio/omap: Fix IRQ handling for SPARSE_IRQ
384ebe1 gpio/omap: Add DT support to GPIO driver
Cc: Kevin Hilman <[email protected]>
Cc: Tony Lindgren <[email protected]>
Cc: Santosh Shilimkar <[email protected]>
Cc: Cousson, Benoit <[email protected]>
Cc: Grant Likely <[email protected]>
Signed-off-by: Tarun Kanti DebBarma <[email protected]>
Reviewed-by: Santosh Shilimkar <[email protected]>
Tested-by: Govindraj.R <[email protected]>
Signed-off-by: Kevin Hilman <[email protected]>
|
|
Rather than requiring architectures that use gpiolib but don't have any
need to define anything custom to copy an asm/gpio.h provide a Kconfig
symbol which architectures must select in order to include gpio.h and
for other architectures just provide the trivial implementation directly.
This makes it much easier to do gpiolib updates and is also a step towards
making gpiolib APIs available on every architecture.
For architectures with existing boilerplate code leave a stub header in
place which warns on direct inclusion of asm/gpio.h and includes
linux/gpio.h to catch code that's doing this. Direct inclusion of
asm/gpio.h has long been deprecated.
Signed-off-by: Mark Brown <[email protected]>
Acked-by: Jonas Bonn <[email protected]>
Acked-by: Tony Luck <[email protected]>
Acked-by: Linus Walleij <[email protected]>
Signed-off-by: Grant Likely <[email protected]>
|
|
Add gpio support for Intel MSIC chips found in Intel Medfield platforms.
MSIC supports totally 24 GPIOs with 16 low voltage and 8 high voltage pins.
Driver uses MSIC mfd interface for MSIC access.
(Updated comment to indicate why locking is actually safe)
Signed-off-by: Mathias Nyman <[email protected]>
Signed-off-by: Alan Cox <[email protected]>
Signed-off-by: Grant Likely <[email protected]>
|
|
Only code move, no functional change.
Main reason to do this was to get rid of the warnings:
drivers/gpio/gpio-samsung.c: In function 'samsung_gpiolib_init':
drivers/gpio/gpio-samsung.c:2974:1: warning: label 'err_ioremap4' defined but not used [-Wunused-label]
drivers/gpio/gpio-samsung.c:2722:47: warning: unused variable 'gpio_base4' [-Wunused-variable]
without adding more ifdef mess.
I think this whole file would do well being coverted over to a platform
driver and moving most of the tables out to SoC code and/or device trees,
but since that changes init ordering it needs to be done with some care,
i.e. not at this time.
Signed-off-by: Olof Johansson <[email protected]>
Acked-by: Kukjin Kim <[email protected]>
Signed-off-by: Grant Likely <[email protected]>
|
|
The IRQ status register should be re-read after each iteration.
Otherwise the loop misses the interrupt if it gets raised immediately
after handled.
Reported-by: Grant Likely <[email protected]>
Signed-off-by: Mika Westerberg <[email protected]>
Acked-by: Linus Walleij <[email protected]>
Signed-off-by: Grant Likely <[email protected]>
|
|
Initialization of irqenable, irqstatus registers is the common
operation done in this function for all OMAP platforms, viz. OMAP1,
OMAP2+. The latter _gpio_rmw()'s which supposedly got introduced
wrongly to take care of OMAP2+ platforms were overwriting initially
programmed OMAP1 value breaking functionality on OMAP1.
Somehow incorrect assumption was made that each _gpio_rmw()'s were
mutually exclusive. On close observation it is found that the first
_gpio_rmw() which is supposedly done to take care of OMAP1 platform
is generic enough and takes care of OMAP2+ platform as well.
Therefore remove the latter _gpio_rmw() to irqenable as they are
redundant now.
Writing to ctrl and debounce_en registers for OMAP2+ platforms are
modified to match the original(pre-cleanup) code where the registers
are initialized with 0. In the cleanup series since we are using
_gpio_rmw(reg, 0, 1), instead of __raw_writel(), we are just reading
and writing the same values to ctrl and debounce_en. This is not an
issue for debounce_en register because it has 0x0 as the default value.
But in the case of ctrl register the default value is 0x2 (GATINGRATIO
= 0x1) so that we end up writing 0x2 instead of intended 0 value.
Therefore changing back to __raw_writel() as this is sufficient for
this case besides simpler to understand.
Also, change irqstatus initalization logic that avoids comparison
with bool, besides making it fit in a single line.
Cc: [email protected]
Cc: Tony Lindgren <[email protected]>
Cc: Kevin Hilman <[email protected]>
Cc: Santosh Shilimkar <[email protected]>
Cc: Grant Likely <[email protected]>
Reported-by: Janusz Krzysztofik <[email protected]>
Tested-by: Janusz Krzysztofik <[email protected]>
Signed-off-by: Tarun Kanti DebBarma <[email protected]>
Signed-off-by: Kevin Hilman <[email protected]>
|
|
irq_domain already provides a facility to translate from hardware IRQ
numbers to Linux IRQ numbers so use that instead of open-coding the logic
in the driver.
Signed-off-by: Mika Westerberg <[email protected]>
Signed-off-by: Grant Likely <[email protected]>
|
|
Linux 3.4-rc6
|
|
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
Pull x86 fixes form Peter Anvin
* 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
intel_mid_powerbtn: mark irq as IRQF_NO_SUSPEND
arch/x86/platform/geode/net5501.c: change active_low to 0 for LED driver
x86, relocs: Remove an unused variable
asm-generic: Use __BITS_PER_LONG in statfs.h
x86/amd: Re-enable CPU topology extensions in case BIOS has disabled it
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/mason/linux-btrfs
Pull btrfs fixes from Chris Mason:
"The big ones here are a memory leak we introduced in rc1, and a
scheduling while atomic if the transid on disk doesn't match the
transid we expected. This happens for corrupt blocks, or out of date
disks.
It also fixes up the ioctl definition for our ioctl to resolve logical
inode numbers. The __u32 was a merging error and doesn't match what
we ship in the progs."
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mason/linux-btrfs:
Btrfs: avoid sleeping in verify_parent_transid while atomic
Btrfs: fix crash in scrub repair code when device is missing
btrfs: Fix mismatching struct members in ioctl.h
Btrfs: fix page leak when allocing extent buffers
Btrfs: Add properly locking around add_root_to_dirty_list
|
|
Setting TIF_IA32 in load_aout_binary() used to be enough; these days
TASK_SIZE is controlled by TIF_ADDR32 and that one doesn't get set
there. Switch to use of set_personality_ia32()...
Signed-off-by: Al Viro <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
|
|
verify_parent_transid needs to lock the extent range to make
sure no IO is underway, and so it can safely clear the
uptodate bits if our checks fail.
But, a few callers are using it with spinlocks held. Most
of the time, the generation numbers are going to match, and
we don't want to switch to a blocking lock just for the error
case. This adds an atomic flag to verify_parent_transid,
and changes it to return EAGAIN if it needs to block to
properly verifiy things.
Signed-off-by: Chris Mason <[email protected]>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/mattst88/alpha
Pull alpha fixes from Matt Turner:
"My alpha tree is back up (after taking quite some time to get my GPG
key signed). It contains just some simple fixes."
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mattst88/alpha:
alpha: silence 'const' warning in sys_marvel.c
alpha: include module.h to fix modpost on Tsunami
alpha: properly define get/set_rtc_time on Marvel/SMP
alpha: VGA_HOSE depends on VGA_CONSOLE
|
|
The test in pdc_console_tty_close '!tty->count' was always wrong
because tty->count is decremented after tty->ops->close is called and
thus can never be zero. Hence the 'then' branch was never executed and
the timer never deleted.
This did not matter until commit 5dd5bc40f3b6 ("TTY: pdc_cons, use
tty_port"). There we needed to set TTY in tty_port to NULL, but this
never happened due to the bug above.
So change the test to really trigger at the last close by changing the
condition to 'tty->count == 1'.
Well, the driver should not touch tty->count at all. It should use
tty_port->count and count open count there itself.
Signed-off-by: Jiri Slaby <[email protected]>
Reported-and-tested-by: Mikulas Patocka <[email protected]>
Cc: Kyle McMartin <[email protected]>
Cc: Helge Deller <[email protected]>
Cc: "James E.J. Bottomley" <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound
Pull sound sound fixes from Takashi Iwai:
"As good as nothing exciting here; just a few trivial fixes for various
ASoC stuff."
* tag 'sound-3.4' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound:
ASoC: omap-pcm: Free dma buffers in case of error.
ASoC: s3c2412-i2s: Fix dai registration
ASoC: wm8350: Don't use locally allocated codec struct
ASoC: tlv312aic23: unbreak resume
ASoC: bf5xx-ssm2602: Set DAI format
ASoC: core: check of_property_count_strings failure
ASoC: dt: sgtl5000.txt: Add description for 'reg' field
ASoC: wm_hubs: Make sure we don't disable differential line outputs
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux
Pull an ACPI patch from Len Brown:
"It fixes a D3 issue new in 3.4-rc1."
By Lin Ming via Len Brown:
* 'release' of git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux:
ACPI: Fix D3hot v D3cold confusion
|
|
Currently, we'll try mounting any device who's major device number is
UNNAMED_MAJOR as NFS root. This would happen for non-NFS devices as
well (such as 9p devices) but it wouldn't cause any issues since
mounting the device as NFS would fail quickly and the code proceeded to
doing the proper mount:
[ 101.522716] VFS: Unable to mount root fs via NFS, trying floppy.
[ 101.534499] VFS: Mounted root (9p filesystem) on device 0:18.
Commit 6829a048102a ("NFS: Retry mounting NFSROOT") introduced retries
when mounting NFS root, which means that now we don't immediately fail
and instead it takes an additional 90+ seconds until we stop retrying,
which has revealed the issue this patch fixes.
This meant that it would take an additional 90 seconds to boot when
we're not using a device type which gets detected in order before NFS.
This patch modifies the NFS type check to require device type to be
'Root_NFS' instead of requiring the device to have an UNNAMED_MAJOR
major. This makes boot process cleaner since we now won't go through
the NFS mounting code at all when the device isn't an NFS root
("/dev/nfs").
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
|
|
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/lrg/asoc into fix/asoc
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-linus
ASoC: Updates for 3.4
Nothing terribly exciting here, a bunch of small and simple fixes
scattered around the place.
|
|
Before this patch, ACPI_STATE_D3 incorrectly referenced D3hot
in some places, but D3cold in other places.
After this patch, ACPI_STATE_D3 always means ACPI_STATE_D3_COLD;
and all references to D3hot use ACPI_STATE_D3_HOT.
ACPI's _PR3 method is used to enter both D3hot and D3cold states.
What distinguishes D3hot from D3cold is the presence _PR3
(Power Resources for D3hot) If these resources are all ON,
then the state is D3hot. If _PR3 is not present,
or all _PR0 resources for the devices are OFF,
then the state is D3cold.
This patch applies after Linux-3.4-rc1.
A future syntax cleanup may remove ACPI_STATE_D3
to emphasize that it always means ACPI_STATE_D3_COLD.
Signed-off-by: Lin Ming <[email protected]>
Acked-by: Rafael J. Wysocki <[email protected]>
Reviewed-by: Aaron Lu <[email protected]>
Signed-off-by: Len Brown <[email protected]>
|
|
Commit ec81aecb2966 ("hfs: fix a potential buffer overflow") fixed a few
potential buffer overflows in the hfs filesystem. But as Timo Warns
pointed out, these changes also need to be made on the hfsplus
filesystem as well.
Reported-by: Timo Warns <[email protected]>
Acked-by: WANG Cong <[email protected]>
Cc: Alexey Khoroshilov <[email protected]>
Cc: Miklos Szeredi <[email protected]>
Cc: Sage Weil <[email protected]>
Cc: Eugene Teo <[email protected]>
Cc: Roman Zippel <[email protected]>
Cc: Al Viro <[email protected]>
Cc: Christoph Hellwig <[email protected]>
Cc: Alexey Dobriyan <[email protected]>
Cc: Dave Anderson <[email protected]>
Cc: stable <[email protected]>
Cc: Andrew Morton <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
Pull timer fix from Thomas Gleixner.
* 'timers-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
rtc: Fix possible null pointer dereference in rtc-mpc5121.c
|
|
Pull CIFS fixes from Steve French.
* git://git.samba.org/sfrench/cifs-2.6:
fs/cifs: fix parsing of dfs referrals
cifs: make sure we ignore the credentials= and cred= options
[CIFS] Update cifs version to 1.78
cifs - check S_AUTOMOUNT in revalidate
cifs: add missing initialization of server->req_lock
cifs: don't cap ra_pages at the same level as default_backing_dev_info
CIFS: Fix indentation in cifs_show_options
|
|
Remove myself as cpufreq maintainer.
x86 driver changes can go through the regular x86/ACPI trees.
ARM driver changes through the ARM trees.
cpufreq core changes are rare these days, and can just go to lkml/direct.
Signed-off-by: Dave Jones <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
|
|
The normal read_seqcount_begin() function will wait for any current
writers to exit their critical region by looping until the sequence
count is even.
That "wait for sequence count to stabilize" is the right thing to do if
the read-locker will just retry the whole operation on contention: no
point in doing a potentially expensive reader sequence if we know at the
beginning that we'll just end up re-doing it all.
HOWEVER. Some users don't actually retry the operation, but instead
will abort and do the operation with proper locking. So the sequence
count case may be the optimistic quick case, but in the presense of
writers you may want to do full locking in order to guarantee forward
progress. The prime example of this would be the RCU name lookup.
And in that case, you may well be better off without the "retry early",
and are in a rush to instead get to the failure handling. Thus this
"raw" interface that just returns the sequence number without testing it
- it just forces the low bit to zero so that read_seqcount_retry() will
always fail such a "active concurrent writer" scenario.
Signed-off-by: Linus Torvalds <[email protected]>
|
|
We really need to use a ACCESS_ONCE() on the sequence value read in
__read_seqcount_begin(), because otherwise the compiler might end up
reloading the value in between the test and the return of it. As a
result, it might end up returning an odd value (which means that a write
is in progress).
If the reader is then fast enough that that odd value is still the
current one when the read_seqcount_retry() is done, we might end up with
a "successful" read sequence, even despite the concurrent write being
active.
In practice this probably never really happens - there just isn't
anything else going on around the read of the sequence count, and the
common case is that we end up having a read barrier immediately
afterwards.
So the code sequence in which gcc might decide to reaload from memory is
small, and there's no reason to believe it would ever actually do the
reload. But if the compiler ever were to decide to do so, it would be
incredibly annoying to debug. Let's just make sure.
Cc: [email protected]
Signed-off-by: Linus Torvalds <[email protected]>
|
|
So that the power button still wakes up the platform.
Signed-off-by: Pierre Tardy <[email protected]>
Link: http://lkml.kernel.org/r/[email protected]
Tested-by: Kangkai Yin <[email protected]>
Tested-by: Yong Wang <[email protected]>
Signed-off-by: Kirill A. Shutemov <[email protected]>
Signed-off-by: Alan Cox <[email protected]>
Cc: Matthew Garrett <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: H. Peter Anvin <[email protected]>
|
|
It seems that there was an error with the active_low = 1 for the
LED, since it should be set to 0 (meaning that active is high,
since 0 is false, hence the confusion.
The wiki article about it confuses it, since it contradicts itself,
regarding what turns on the LED.
I have tested 3.4-rc2 on my net5501 with this patch, and it makes the LED
behave correctly, where "none" turns it off, and "default-on" turns it on,
when echoed onto the trigger "file" in /sys/class/leds.
Signed-off-by: Bjarke Istrup Pedersen <[email protected]>
Link: http://lkml.kernel.org/r/[email protected]
Cc: Philip Prindeville <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: H. Peter Anvin <[email protected]>
|
|
Fix that when scrub tries to repair an I/O or checksum error and one of
the devices containing the mirror is missing, it crashes in bio_add_page
because the bdev is a NULL pointer for missing devices.
Reported-by: Marco L. Crociani <[email protected]>
Signed-off-by: Stefan Behrens <[email protected]>
Signed-off-by: Chris Mason <[email protected]>
|
|
Fix the size members of btrfs_ioctl_ino_path_args and
btrfs_ioctl_logical_ino_args. The user space btrfs-progs utilities used
__u64 and the kernel headers used __u32 before.
Signed-off-by: Alexander Block <[email protected]>
Signed-off-by: Chris Mason <[email protected]>
|
|
If we happen to alloc a extent buffer and then alloc a page and notice that
page is already attached to an extent buffer, we will only unlock it and
free our existing eb. Any pages currently attached to that eb will be
properly freed, but we don't do the page_cache_release() on the page where
we noticed the other extent buffer which can cause us to leak pages and I
hope cause the weird issues we've been seeing in this area. Thanks,
Signed-off-by: Josef Bacik <[email protected]>
Signed-off-by: Chris Mason <[email protected]>
|