Certain devices implement triggers as buttons rather than axes. In
particular, arcade sticks such as the HORI Real Arcade Pro.EX do not
have analog buttons.
These devices are now setup to present buttons rather than axes for
triggers.
User-space applications often also have problems with
axes-as-buttons. Activating MAP_TRIGGERS_TO_BUTTONS for a device
removes the artificial difference between buttons and triggers.
Signed-off-by: Nicolas Léveillé <nicolas@uucidl.com>
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
Lifebook protocol can only be activated if we find known DMI signature.
It is useles without DMI.
Reported-by: Rakib Mullick <rakib.mullick@gmail.com>
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
This should fix the following compile warning:
drivers/input/misc/wistron_btns.c:1331:5: warning: "CONFIG_PM" is not defined
Signed-off-by: Rakib Mullick <rakib.mullick@gmail.com>
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
backlight_device_register may return an ERR_PTR
value rather than a valid pointer.
Problem found by Julia Lawall, properly fixed by Zhang Rui.
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Acked-by: Julia Lawall <julia@diku.dk>
Signed-off-by: Len Brown <len.brown@intel.com>
Today's -tip failed to build because commit
9e368fa011 ("ipmi: add PNP discovery (ACPI
namespace via PNPACPI)") from today's upstream kernel causes the following
build failure on x86, for CONFIG_ACPI=n && CONFIG_IPMI_SI=y:
drivers/char/ipmi/ipmi_si_intf.c:3208: error: 'ipmi_pnp_driver' undeclared (first use in this function)
drivers/char/ipmi/ipmi_si_intf.c:3208: error: (Each undeclared identifier is reported only once
drivers/char/ipmi/ipmi_si_intf.c:3208: error: for each function it appears in.)
drivers/char/ipmi/ipmi_si_intf.c:3334: error: 'ipmi_pnp_driver' undeclared (first use in this function)
The reason is that the ipmi_pnp_driver depends on ACPI facilities and is only
made available under ACPI - while the registration and unregistration is made
dependent on CONFIG_PNP:
#ifdef CONFIG_PNP
pnp_register_driver(&ipmi_pnp_driver);
#endif
The solution is to only register this driver under ACPI. (Also, the CONFIG_PNP
dependency is not needed because pnp_register_driver() is stubbed out in the
!CONFIG_PNP case.)
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Acked-by: Myron Stowe <myron.stowe@hp.com>
Signed-off-by: Len Brown <len.brown@intel.com>
This fixes a bug (found by Curt Wohlgemuth) in which new blocks
returned from an extent created with ext4_ext_zeroout() can have dirty
metadata still associated with them.
Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
Signed-off-by: Curt Wohlgemuth <curtw@google.com>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
If two arrays share a device, then they will not both resync at the
same time. One will wait for the other to complete.
While waiting, the MD_RECOVERY_INTR flag is not checked so a device
failure, which would make the resync pointless, does not cause the
resync to abort, so the failed device cannot be removed (as it cannot
be remove while a resync is happening).
So add a test for MD_RECOVERY_INTR.
Reported-by: Brett Russ <bruss@netezza.com>
Signed-off-by: NeilBrown <neilb@suse.de>
Since commit dfc7064500,
->hot_remove_disks has not removed non-failed devices from
an array until recovery is no longer possible.
So the code in do_md_run to get around the fact that
md_check_recovery (which calls ->hot_remove_disks) would
remove partially-in-sync devices is no longer needed.
So remove it.
Signed-off-by: NeilBrown <neilb@suse.de>
By default md_do_sync() will perform recovery if no other actions are
specified. However, action_show() relies on MD_RECOVERY_RECOVER to be
set otherwise it returns 'idle'. So, add a missing set
MD_RECOVERY_RECOVER when starting recovery.
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
The start_ro modules parameter can be used to force arrays to be
started in 'auto-readonly' in which they are read-only until the first
write. This ensures that no resync/recovery happens until something
else writes to the device. This is important for resume-from-disk
off an md array.
However if an array is started 'readonly' (by writing 'readonly' to
the 'array_state' sysfs attribute) we want it to be really 'readonly',
not 'auto-readonly'.
So strengthen the condition to only set auto-readonly if the
array is not already read-only.
Signed-off-by: NeilBrown <neilb@suse.de>
Use the %pM kernel extension to display the MAC address.
The only difference in the output is that the MAC address is
shown in the usual colon-separated hex notation instead of
space-separated.
Signed-off-by: H Hartley Sweeten <hsweeten@visionengravers.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
evms configures md arrays by:
open device
send ioctl
close device
for each different ioctl needed.
Since 2.6.29, the device can disappear after the 'close'
unless a significant configuration has happened to the device.
The change made by "SET_ARRAY_INFO" can too minor to stop the device
from disappearing, but important enough that losing the change is bad.
So: make sure SET_ARRAY_INFO sets mddev->ctime, and keep the device
active as long as ctime is non-zero (it gets zeroed with lots of other
things when the array is stopped).
This is suitable for -stable kernels since 2.6.29.
Signed-off-by: NeilBrown <neilb@suse.de>
Cc: stable@kernel.org
Commit 500f5a0bf5
(reiserfs: Fix possible recursive lock) fixed a vmalloc under reiserfs
lock that triggered a lockdep warning because of a
IN-FS-RECLAIM <-> RECLAIM-FS-ON locking dependency inversion.
But this patch has ommitted another vmalloc call in the same path
that allocates the journal. Relax the lock for this one too.
Reported-by: Alexander Beregalov <a.beregalov@gmail.com>
Signed-off-by: Frederic Weisbecker <fweisbec@gmail.com>
Cc: Chris Mason <chris.mason@oracle.com>
Cc: Ingo Molnar <mingo@elte.hu>
Several config ROM related functions only peek at the ROM cache; mark
their arguments as const pointers. Ditto fw_device.config_rom and
fw_unit.directory, as the memory behind them is meant to be write-once.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Update the Kconfig help texts of both stacks to encourage a general move
from the older to the newer drivers. However, do not label ieee1394 as
"Obsolete" yet, as the newer drivers have not been deployed as default
stack in the majority of Linux distributions yet, and those who start
doing so now may still want to install the old drivers as fallback for
unforeseen issues.
Since Linux 2.6.32, FireWire audio devices can be driven by the newer
firewire driver stack too, hence remove an outdated comment about audio
devices. Also remove comments about library versions since the 2nd
generation of libraw1394 and libdc1394 is now in common use; details on
library versions can be read at the wiki link from the help texts.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Ben and Kristian have not been involved in maintenance of the IEEE 1394
drivers for quite some time; submitters are not required to Cc them on
patches.
The linux1394.org domain has been dead for a while and is no longer
under control of a Linux developer. The current web site of the
Linux 1394 project is http://ieee1394.wiki.kernel.org/.
The classic drivers/ieee1394/ stack is now obsolete from the development
point of view, though still a useful alternative in productive use. But
nobody should attempt to submit style cleanup patches for it or to
develop new drivers on top of this stack, hence mark its MAINTAINERS
entry as Obsolete.
drivers/ieee1394/raw1394*, like the rest of the old stack, does not
receive bigger code changes anymore, hence shrink the MAINTAINERS
database a bit by dropping raw1394's special entry. If something
important and urgent is going to come up for raw1394, I will make sure
that Dan will be notified of it besides via linux1394-devel.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Signed-off-by: Dan Dennedy <dan@dennedy.org>
Cc: Ben Collins <ben.collins@ubuntu.com>
Cc: Kristian Hoegsberg <krh@bitplanet.net>
The core (sysfs attributes), the firedtv driver, and possible future
drivers all read strings from some configuration ROM directory. Factor
out the generic code from show_text_leaf() into a new helper function,
modified slightly to handle arbitrary buffer sizes.
Signed-off-by: Clemens Ladisch <clemens@ladisch.de>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
This is a minimal change meant for the short term: Never set the
ohci->use_dualbuffer flag to true.
There are two reasons to do so:
- Packet-per-buffer mode and dual-buffer mode do not behave the same
under certain circumstances, notably if several packets are covered
by a single fw_cdev_iso_packet descriptor.
http://marc.info/?l=linux1394-devel&m=124965653718313
Therefore the driver stack should not silently choose one or the
other mode but should leave the choice to the high-level driver
(regardless if kernel driver or userspace driver). Or simply always
only offer packet-per-buffer mode, since a considerable number of
controllers, even current ones, does not offer dual-buffer support.
- Even under circumstances where packet-per-buffer mode and
dual-buffer mode behave exactly the same --- notably when used
through libraw1394, libdc1394, as well as the current two kernel
drivers which use isochronous reception (firewire-net and firedtv)
--- we are still faced with the problem that several OHCI 1.1
controllers have bugs in dual-buffer mode. Although it looks like
we have identified most of those buggy controllers by now, we
cannot be quite sure about that.
So, use packet-per-buffer by default from now on. This change should
be followed up by a more complete solution: Either extend the
in-kernel API and the userspace ABI by a choice between the two IR modes
or remove all dual-buffer related code from firewire-ohci.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
If copy_from_user in an FW_CDEV_IOC_SEND_RESPONSE ioctl failed, the
fw_request pointed to by the inbound_transaction_resource is no
longer referenced and needs to be freed.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Control of more than one AV/C device at once --- e.g. camcorders, tape
decks, audio devices, TV tuners --- failed or worked only unreliably,
depending on driver implementation. This affected kernelspace and
userspace drivers alike and was caused by firewire-core's inability to
accept multiple registrations of FCP listeners.
The fix allows multiple address handlers to be registered for the FCP
command and response registers. When a request for these registers is
received, all handlers are invoked, and the Firewire response is
generated by the core and not by any handler.
The cdev API does not change, i.e., userspace is still expected to send
a response for FCP requests; this response is silently ignored.
Signed-off-by: Clemens Ladisch <clemens@ladisch.de>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de> (changelog, rebased, whitespace)
!CONFIG_OPT evalues to FALSE if CONFIG_OPT='m'. Do not display the
"DRBD disabled..." message if the dependencies are compiled as module.
Signed-off-by: Johannes Thoma <johannes.thoma@linbit.com>
Signed-off-by: Philipp Reisner <philipp.reisner@linbit.com>
In D_DISKLESS we do not hand out any new references to ldev (local_cnt)
therefore waiting until all previously handed out refereces got returned
is sufficient before actually freeing mdev->ldev.
Signed-off-by: Philipp Reisner <philipp.reisner@linbit.com>
Signed-off-by: Lars Ellenberg <lars.ellenberg@linbit.com>
queue_sector_alignment_offset returned the wrong value which caused
partitions to report an incorrect alignment_offset. Since offset
alignment calculation is needed several places it has been split into a
separate helper function. The topology stacking function has been
updated accordingly.
Furthermore, comments have been added to clarify how the stacking
function works.
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Tested-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Jens Axboe <jens.axboe@oracle.com>
PXA mmc host driver supports card detect, read only and power gpio pin
setting already. Zylonite platform driver needn't implement this any more.
Signed-off-by: Haojian Zhuang <haojian.zhuang@marvell.com>
Signed-off-by: Eric Miao <eric.y.miao@gmail.com>
