* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs-2.6:
FS: lookup_mnt() is only used in the core fs routines now
bfs: fix bitmap size argument to find_first_zero_bit()
fs: Use BUG_ON(!mnt) at dentry_open().
fs: devpts_pty_new() return -ENOMEM if dentry allocation failed
nfs: lock() vs unlock() typo
pstore: fix leaking ->i_private
introduce sys_syncfs to sync a single file system
Small typo fix...
Filesystem: fifo: Fixed coding style issue.
fs/inode: Fix kernel-doc format for inode_init_owner
select: remove unused MAX_SELECT_SECONDS
vfs: cleanup do_vfs_ioctl()
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/ieee1394/linux1394-2.6:
firewire: core: ignore link-active bit of new nodes, fix device recognition
firewire: sbp2: revert obsolete 'fix stall with "Unsolicited response"'
firewire: core: increase default SPLIT_TIMEOUT value
firewire: ohci: Misleading kfree in ohci.c::pci_probe/remove
firewire: ohci: omit IntEvent.busReset check rom AT queueing
firewire: ohci: prevent starting of iso contexts with empty queue
firewire: ohci: prevent iso completion callbacks after context stop
firewire: core: rename some variables
firewire: nosy: should work on Power Mac G4 PCI too
firewire: core: fix card->reset_jiffies overflow
firewire: cdev: remove unneeded reference
firewire: cdev: always wait for outbound transactions to complete
firewire: cdev: remove unneeded idr_find() from complete_transaction()
firewire: ohci: log dead DMA contexts
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/parisc-2.6:
[PARISC] Convert to new irq_chip functions
[PARISC] fix per-cpu flag problem in the cpu affinity checkers
[PARISC] fix vmap flush/invalidate
eliminate special FLUSH flag from page table
parisc: flush pages through tmpalias space
This patch initializes the margins for the initial mode correct.
This is required to get the desired initial refresh rate. Also do
more verbose sanity checking to prevent misbehavior.
Signed-off-by: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
Configuration for ads1015 gain and datarate is possible via
devicetree or platform data.
This is a followup patch to previous ads1015 patches on Jean Delvares
tree.
Signed-off-by: Dirk Eibach <eibach@gdsys.de>
Signed-off-by: Jean Delvare <khali@linux-fr.org>
SMSC SCH5627 Super I/O chips include complete hardware monitoring
capabilities. They can monitor up to 5 voltages, 4 fans and 8
temperatures.
The hardware monitoring part of the SMSC SCH5627 is accessed by talking
through an embedded microcontroller. An application note describing the
protocol for communicating with the microcontroller is available upon
request. Please mail me if you want a copy.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Jean Delvare <khali@linux-fr.org>
Make the LM75/LM75A device detection faster:
* Don't read the current temperature value when we don't use it.
* Check for unused bits in the configuration register as soon as we
have read its value.
* Don't use word reads, not all devices support this, and some which
don't misbehave when you try.
* Check for cycling register values every 40 register addresses
instead of every 8, it's 5 times faster and just as efficient.
Some of these improvements come straight from the user-space
sensors-detect script, so both detection routines are in line now.
Signed-off-by: Jean Delvare <khali@linux-fr.org>
Cc: Len Sorensen <lsorense@csclub.uwaterloo.ca>
Acked-by: Guenter Roeck <guenter.roeck@ericsson.com>
Add support for detection of the National Semiconductor LM75A using the ID
register value.
Signed-off-by: Len Sorensen <lsorense@csclub.uwaterloo.ca>
Signed-off-by: Jean Delvare <khali@linux-fr.org>
I suspect that the "lis3lv02d" driver name is a legacy from before
the split into several modules. Use a specific name for the hp_accel
driver, for better error messages and easier investigation of issues.
Signed-off-by: Jean Delvare <khali@linux-fr.org>
Acked-by: Guenter Roeck <guenter.roeck@ericsson.com>
Acked-by: Eric Piel <eric.piel@tremplin-utc.net>
Acked-by: Jonathan Cameron <jic23@cam.ac.uk>
Tested-by: Eric Piel <eric.piel@tremplin-utc.net>
Tested-by: Takashi Iwai <tiwai@suse.de>
The lis3lv02d drivers aren't hardware monitoring drivers, so the don't
belong to drivers/hwmon. Move them to drivers/misc, short of a better
home.
Signed-off-by: Jean Delvare <khali@linux-fr.org>
Acked-by: Guenter Roeck <guenter.roeck@ericsson.com>
Acked-by: Eric Piel <eric.piel@tremplin-utc.net>
Acked-by: Jonathan Cameron <jic23@cam.ac.uk>
Tested-by: Eric Piel <eric.piel@tremplin-utc.net>
Tested-by: Takashi Iwai <tiwai@suse.de>
The hp_accel driver isn't a hardware monitoring driver, so it doesn't
belong to drivers/hwmon. Move it to drivers/platform/x86, assuming HP
doesn't ship non-x86 laptops.
Signed-off-by: Jean Delvare <khali@linux-fr.org>
Acked-by: Guenter Roeck <guenter.roeck@ericsson.com>
Acked-by: Eric Piel <eric.piel@tremplin-utc.net>
Acked-by: Jonathan Cameron <jic23@cam.ac.uk>
Tested-by: Eric Piel <eric.piel@tremplin-utc.net>
Tested-by: Takashi Iwai <tiwai@suse.de>
The dependencies between the various lis3lv02d drivers make it
impossible to split them to different directories, while we really
want to do this. Move handling of dependencies from Makefile to
Kconfig, to make the move possible at all.
Signed-off-by: Jean Delvare <khali@linux-fr.org>
Acked-by: Guenter Roeck <guenter.roeck@ericsson.com>
Acked-by: Eric Piel <eric.piel@tremplin-utc.net>
Acked-by: Jonathan Cameron <jic23@cam.ac.uk>
Tested-by: Eric Piel <eric.piel@tremplin-utc.net>
Tested-by: Takashi Iwai <tiwai@suse.de>
An integer overflow occurs in the calculation of RHlinear when the
relative humidity is greater than around 30%. The consequence is a subtle
(but noticeable) error in the resulting humidity measurement.
Signed-off-by: Vivien Didelot <vivien.didelot@savoirfairelinux.com>
Signed-off-by: Jean Delvare <khali@linux-fr.org>
Cc: stable@kernel.org
Cc: Jonathan Cameron <jic23@cam.ac.uk>
Apparently users are interested in this information, so let's provide
it.
Signed-off-by: Jean Delvare <khali@linux-fr.org>
Acked-by: Guenter Roeck <guenter.roeck@ericsson.com>
* 'merge' of git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc:
powerpc/ptrace: Remove BUG_ON when full register set not available
powerpc: Factoring mpic cpu id fetching into a function
powerpc: Make MPIC honor the "pic-no-reset" device tree property
powerpc: Document the Open PIC device tree binding
powerpc/pci: Fix crash in PCI code on ppc64 when matching device nodes
v3 -> v2: Added text to describe the problem
v2 -> v1: Split this patch from v1
v1 : Part of: http://marc.info/?l=linux-pci&m=130042212003242&w=2
Disable ASPM when no _OSC control for PCIe services is granted
by the BIOS. This is to protect systems with a buggy BIOS that
did not set the ACPI FADT "ASPM Controls" bit even though the
underlying HW can't do ASPM.
To turn "on" ASPM the minimum the BIOS needs to do:
1. Clear the ACPI FADT "ASPM Controls" bit.
2. Support _OSC appropriately
There is no _OSC Control bit for ASPM. However, we expect the BIOS to
support _OSC for a Root Bridge that originates a PCIe hierarchy. If this
is not the case - we are better off not enabling ASPM on that server.
Commit 852972acff (ACPI: Disable ASPM if the
Platform won't provide _OSC control for PCIe) describes the above scenario.
To quote verbatim from there:
[The PCI SIG documentation for the _OSC OS/firmware handshaking interface
states:
"If the _OSC control method is absent from the scope of a host bridge
device, then the operating system must not enable or attempt to use any
features defined in this section for the hierarchy originated by the host
bridge."
The obvious interpretation of this is that the OS should not attempt to use
PCIe hotplug, PME or AER - however, the specification also notes that an
_OSC method is *required* for PCIe hierarchies, and experimental validation
with An Alternative OS indicates that it doesn't use any PCIe functionality
if the _OSC method is missing. That arguably means we shouldn't be using
MSI or extended config space, but right now our problems seem to be limited
to vendors being surprised when ASPM gets enabled on machines when other
OSs refuse to do so. So, for now, let's just disable ASPM if the _OSC
method doesn't exist or refuses to hand over PCIe capability control.]
Signed-off-by: Naga Chumbalkar <nagananda.chumbalkar@hp.com>
Cc: Rafael J. Wysocki <rjw@sisk.pl>
Cc: Matthew Garrett <mjg59@srcf.ucam.org>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
v3 -> v2: Modified the text that describes the problem
v2 -> v1: Returned -EPERM
v1 : http://marc.info/?l=linux-pci&m=130013194803727&w=2
For servers whose hardware cannot handle ASPM the BIOS ought to set the
FADT bit shown below:
In Sec 5.2.9.3 (IA-PC Boot Arch. Flags) of ACPI4.0a Specification, please
see Table 5-11:
PCIe ASPM Controls: If set, indicates to OSPM that it must not enable
OPSM ASPM control on this platform.
However there are shipping servers whose BIOS did not set this bit. (An
example is the HP ProLiant DL385 G6. A Maintenance BIOS will fix that).
For such servers even if a call is made via pci_no_aspm(), based on _OSC
support in the BIOS, it may be too late because the ASPM code may have
already allocated and filled its "link_list".
So if a user sets the ASPM "policy" to "powersave" via /sys then
pcie_aspm_set_policy() will run through the "link_list" and re-configure
ASPM policy on devices that advertise ASPM L0s/L1 capability:
# echo powersave > /sys/module/pcie_aspm/parameters/policy
# cat /sys/module/pcie_aspm/parameters/policy
default performance [powersave]
That can cause NMIs since the hardware doesn't play well with ASPM:
[ 1651.906015] NMI: PCI system error (SERR) for reason b1 on CPU 0.
[ 1651.906015] Dazed and confused, but trying to continue
Ideally, the BIOS should have set that FADT bit in the first place but we
could be more robust - especially given the fact that Windows doesn't
cause NMIs in the above scenario.
There should be a sanity check to not allow a user to modify ASPM policy
when aspm_disabled is set.
Signed-off-by: Naga Chumbalkar <nagananda.chumbalkar@hp.com>
Acked-by: Rafael J. Wysocki <rjw@sisk.pl>
Cc: Matthew Garrett <mjg59@srcf.ucam.org>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
v3 -> v2: Moved ASPM enabling logic to pci_set_power_state()
v2 -> v1: Preserved the logic in pci_raw_set_power_state()
: Added ASPM enabling logic after scanning Root Bridge
: http://marc.info/?l=linux-pci&m=130046996216391&w=2
v1 : http://marc.info/?l=linux-pci&m=130013164703283&w=2
The assumption made in commit 41cd766b06
(PCI: Don't enable aspm before drivers have had a chance to veto it) that
pci_enable_device() will result in re-configuring ASPM when aspm_policy is
POWERSAVE is no longer valid. This is due to commit
97c145f7c8 (PCI: read current power state
at enable time) which resets dev->current_state to D0. Due to this the
call to pcie_aspm_pm_state_change() is never made. Note the equality check
(below) that returns early:
./drivers/pci/pci.c: pci_raw_set_pci_power_state()
546 /* Check if we're already there */
547 if (dev->current_state == state)
548 return 0;
Therefore OSPM never configures the PCIe links for ASPM to turn them "on".
Fix it by configuring ASPM from the pci_enable_device() code path. This
also allows a driver such as the e1000e networking driver a chance to
disable ASPM (L0s, L1), if need be, prior to enabling the device. A
driver may perform this action if the device is known to mis-behave
wrt ASPM.
Signed-off-by: Naga Chumbalkar <nagananda.chumbalkar@hp.com>
Acked-by: Rafael J. Wysocki <rjw@sisk.pl>
Cc: Matthew Garrett <mjg59@srcf.ucam.org>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
We need to distinguish the situation in which ASPM support is
disabled from the command line or through .config from the situation
in which it is disabled, because the hardware or BIOS can't handle
it. In the former case we should not report ASPM support to the BIOS
through ACPI _OSC, but in the latter case we should do that.
Introduce pcie_aspm_support_enabled() that can be used by
acpi_pci_root_add() to determine whether or not it should report ASPM
support to the BIOS through _OSC.
Cc: stable@kernel.org
References: https://bugzilla.kernel.org/show_bug.cgi?id=29722
References: https://bugzilla.kernel.org/show_bug.cgi?id=20232
Reported-and-tested-by: Ortwin Glück <odi@odi.ch>
Reviewed-by: Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>
Tested-by: Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
lookup_mnt() is only used in the core fs routines now, so it doesn't need to
be globally declared anymore. It isn't exported to modules at the moment, so
nothing that can be modularised seems to be using it.
Signed-off-by: David Howells <dhowells@redhat.com>
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
This device contains the very same bug in report descriptor as the
Ortek ones do (i.e. LogicalMinimum == 1, which is wrong for the key
array).
As we have more reports for the Ortek devices, we are keeping the driver
name for now. Apparently there is a chip producer which sells chip with
this buggy descriptor to multiple vendors. Thus if such reports start
to come at highger frequency, we'll either have to rename the driver
accordingly, or come up with more generic workaround.
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
We have been creating bitmaps for small extents unconditionally forever. This
was great when testing to make sure the bitmap stuff was working, but is
overkill normally. So instead of always adding small chunks of free space to
bitmaps, only start doing it if we go past half of our extent threshold. This
will keeps us from creating a bitmap for just one small free extent at the front
of the block group, and will make the allocator a little faster as a result.
Thanks,
Signed-off-by: Josef Bacik <josef@redhat.com>
We do all this fun stuff with min_bytes, but either don't use it in the case of
just normal extents, or use it completely wrong in the case of bitmaps. So fix
this for both cases
1) In the extent case, stop looking for space with window_free >= min_bytes
instead of bytes + empty_size.
2) In the bitmap case, we were looking for streches of free space that was at
least min_bytes in size, which was not right at all. So instead search for
stretches of free space that are at least bytes in size (this will make a
difference when we have > page size blocks) and then only search for min_bytes
amount of free space.
Thanks,
Reviewed-by: Li Zefan <lizf@cn.fujitsu.com>
Signed-off-by: Josef Bacik <josef@redhat.com>
The free space cluster stuff is heavy duty, so there is no sense in going
through the entire song and dance if there isn't enough space in the block group
to begin with. Thanks,
Signed-off-by: Josef Bacik <josef@redhat.com>
Only bail out of fuse_dentry_revalidate() on LOOKUP_RCU when blocking
is actually necessary.
CC: Nick Piggin <npiggin@gmail.com>
Signed-off-by: Miklos Szeredi <mszeredi@suse.cz>
Only bail out of fuse_permission() on IPERM_FLAG_RCU when blocking is
actually necessary.
CC: Nick Piggin <npiggin@gmail.com>
Signed-off-by: Miklos Szeredi <mszeredi@suse.cz>
If a fuse dev connection is broken, wake up any
processes that are blocking, in a poll system call,
on one of the files in the now defunct filesystem.
Signed-off-by: Miklos Szeredi <mszeredi@suse.cz>
Reduce the size of struct fuse_request by removing cuse_init_out from
the request structure and allocating it dinamically instead.
CC: Tejun Heo <tj@kernel.org>
Signed-off-by: Miklos Szeredi <mszeredi@suse.cz>
The usage of find_first_zero_bit() in bfs_create() is wrong for two
reasons.
The bitmap size argument to find_first_zero_bit() is info->si_lasti but
the correct bitmap size is info->si_lasti + 1 as info->si_lasti is the
last valid index in info->si_imap bitmap.
Another problem is that it is impossible to detect that info->si_imap
bitmap is full because there is an off-by-one bug in the return value
check for find_first_zero_bit(). If no zero bits exist in info->si_imap,
find_first_zero_bit() returns info->si_lasti. But the check can't catch
it due to the off-by-one.
Signed-off-by: Akinobu Mita <akinobu.mita@gmail.com>
Acked-by: "Tigran A. Aivazian" <tigran@aivazian.fsnet.co.uk>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Some USB devices give trailing spaces in strings returned from
usb_string(). This confuses the automatic card-id creation, resulting
always in "default".
This patch fixes the behavior by removing trailing spaces.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
CONFIG_DEBUG_SECTION_MISMATCH has also runtime effects due to the
-fno-inline-functions-called-once compiler flag, so forcing it on
everyone is not a good idea.
Signed-off-by: Michal Marek <mmarek@suse.cz>
Fix regression that was introduced by dynamic register layout.
Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com>
Signed-off-by: Ben Dooks <ben-linux@fluff.org>
the of_node will auto-publish devices which are added to the device
tree.
Commit 925bb9c6 aka ("of/i2c: Fix module load order issue caused by
of_i2c.c) moved the of_i2c_register_devices() function from the i2c core
back to the drivers. This patch does the same thing for the pxa driver.
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Dirk Brandewie <dirk.brandewie@gmail.com>
Signed-off-by: Ben Dooks <ben-linux@fluff.org>
timeout here maybe 0 if the event occured and a task with a higher
priority stole the cpu and we were sleeping longer than the timeout
value we specified.
In case of a real timeout I changed the error code to I2C_RETRY so we
retry the transfer.
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Dirk Brandewie <dirk.brandewie@gmail.com>
Signed-off-by: Ben Dooks <ben-linux@fluff.org>
Sodaville has three of them on a single IRQ. IRQF_DISABLED is removed
because it is a NOP allready and scheduled for removal.
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Dirk Brandewie <dirk.brandewie@gmail.com>
Signed-off-by: Ben Dooks <ben-linux@fluff.org>
The Sodaville I2C controller is almost the same as found on PXA2xx. The
difference:
- the register are at a different offset
- no slave support
The PCI probe code adds three platform devices which are probed then by
the platform code.
The X86 part also adds dummy clock defines because we don't have HW
clock support.
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Dirk Brandewie <dirk.brandewie@gmail.com>
Signed-off-by: Ben Dooks <ben-linux@fluff.org>
One of the disadvantages of on-stack plugging is that we potentially
lose out on merging since all pending IO isn't always visible to
everybody. When we flush the on-stack plugs, right now we don't do
any checks to see if potential merge candidates could be utilized.
Correct this by adding a new insert variant, ELEVATOR_INSERT_SORT_MERGE.
It works just ELEVATOR_INSERT_SORT, but first checks whether we can
merge with an existing request before doing the insertion (if we fail
merging).
This fixes a regression with multiple processes issuing IO that
can be merged.
Thanks to Shaohua Li <shaohua.li@intel.com> for testing and fixing
an accounting bug.
Signed-off-by: Jens Axboe <jaxboe@fusionio.com>
This patch moves the platform data definition from
arch/arm/plat-pxa/include/plat/i2c.h to include/linux/i2c/pxa-i2c.h so
it can be accessed from x86 the same way as on ARM.
This change should make no functional change to the PXA code. The move
is verified by building the following defconfigs:
cm_x2xx_defconfig corgi_defconfig em_x270_defconfig ezx_defconfig
imote2_defconfig pxa3xx_defconfig spitz_defconfig zeus_defconfig
raumfeld_defconfig magician_defconfig mmp2_defconfig pxa168_defconfig
pxa910_defconfig
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Dirk Brandewie <dirk.brandewie@gmail.com>
Signed-off-by: Ben Dooks <ben-linux@fluff.org>
This will prepare the driver to handle register layouts where certain
registers are not available at all.
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Ben Dooks <ben-linux@fluff.org>
