Currently unknown consumer page codes are ignored, which means that they cannot
later be mapped from userspace using udev / hwdb. Map them to KEY_UNKNOWN, so
that userspace can remap them for keyboards which make up their own consumer
page codes.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

This patch fixes a bug on hotmod removing.

After ipmi interface is removed using hotmod, kernel panic occurs when
rmmod impi_si.  For example, try this:

 # echo "remove,"`cat /proc/ipmi/0/params` > \
 /sys/module/ipmi_si/parameters/hotmod
 # rmmod ipmi_si

Then, rmmod fails with the following messages.

  ------------[ cut here ]------------
  WARNING: CPU: 12 PID: 10819 at /mnt/repos/linux/lib/list_debug.c:53 __list_del_entry+0x63/0xd0()
  CPU: 12 PID: 10819 Comm: rmmod Not tainted 3.17.0-rc1 #19
  Hardware name: FUJITSU-SV PRIMERGY BX920 S2/D3030, BIOS 080015 Rev.3D81.3030 02/10/2012
  Call Trace:
    dump_stack+0x45/0x56
    warn_slowpath_common+0x7d/0xa0
    warn_slowpath_fmt+0x4c/0x50
    __list_del_entry+0x63/0xd0
    list_del+0xd/0x30
    cleanup_one_si+0x2a/0x230 [ipmi_si]
    ipmi_pnp_remove+0x15/0x20 [ipmi_si]
    pnp_device_remove+0x24/0x40
    __device_release_driver+0x7f/0xf0
    driver_detach+0xb0/0xc0
    bus_remove_driver+0x55/0xd0
    driver_unregister+0x2c/0x50
    pnp_unregister_driver+0x12/0x20
    cleanup_ipmi_si+0xbc/0xf0 [ipmi_si]
    SyS_delete_module+0x132/0x1c0
    system_call_fastpath+0x16/0x1b
  ---[ end trace 70b4377268f85c23 ]---

list_del in cleanup_one_si() fails because the smi_info is already
removed when hotmod removing.

When ipmi interface is removed by hotmod, smi_info is removed by
cleanup_one_si(), but is is still set in drvdata.  Therefore when rmmod
ipmi_si, ipmi_pnp_remove tries to remove it again and fails.

By this patch, a pointer to smi_info in drvdata is cleared when hotmod
removing so that it will be not accessed when rmmod.

changelog:
v2:
- Clear drvdata in cleanup_one_si
- Change subject

v1:
https://lkml.org/lkml/2014/9/8/741Signed-off-by: NTakao Indoh <indou.takao@jp.fujitsu.com>
Signed-off-by: NCorey Minyard <cminyard@mvista.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Building ipmi on arm with gcc-4.9 results in this warning for an
allmodconfig build:

  drivers/char/ipmi/ipmi_si_intf.c: In function 'ipmi_thread':
  include/linux/time.h:28:5: warning: 'busy_until.tv_sec' may be used uninitialized in this function [-Wmaybe-uninitialized]
    if (lhs->tv_sec > rhs->tv_sec)
       ^
  drivers/char/ipmi/ipmi_si_intf.c:1007:18: note: 'busy_until.tv_sec' was declared here
    struct timespec busy_until;
                    ^

The warning is bogus and this case can not occur.  Apparently this is a
false positive resulting from gcc getting a little smarter about
tracking assignments but not smart enough.

Marking the ipmi_thread_busy_wait function as inline gives the gcc
optimization logic enough information to figure out for itself that the
case cannot happen, which gets rid of the warning without adding any
fake initialization.
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Signed-off-by: NCorey Minyard <cminyard@mvista.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

If an IPMI controller is used by the firmware and as such marked with
a reserved status, we shouldn't use it.
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: NCorey Minyard <cminyard@mvista.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

The code to send the channel config errors was missing an error report
in one place and needed some more information in another, and had an
extraneous bit of code.  Clean all that up.
Signed-off-by: NCorey Minyard <cminyard@mvista.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

This replaces http://git.linuxtv.org/v4l-utils/ (broken link)
by http://git.linuxtv.org/cgit.cgi/v4l-utils.git/Signed-off-by: NMichael Opdenacker <michael.opdenacker@free-electrons.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

Signed-off-by: NMichael Heimpold <mhei@heimpold.de>
Signed-off-by: NMark Brown <broonie@kernel.org>

The uas driver uses the block layer tag for USB3 stream IDs.  With
blk-mq we can get larger tag numbers that the queue depth, which breaks
this assumption.  A fix is under way for 3.18, but sits on top of
large changes so can't easily be backported.   Set the disable_blk_mq
path so that a uas device can't easily crash the system when using
blk-mq for SCSI.
Signed-off-by: NChristoph Hellwig <hch@lst.de>
Acked-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>

The runtime pm calls need to be done before populating the children via the
i2c_add_adapter call.  If this is not done, a child can run into issues trying
to do i2c read/writes due to the pm_runtime_sync failing.
Signed-off-by: NAndy Gross <agross@codeaurora.org>
Reviewed-by: NFelipe Balbi <balbi@ti.com>
Acked-by: NBjorn Andersson <bjorn.andersson@sonymobile.com>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>
Cc: stable@kernel.org

i2cdetect -q was broken (everything was a false positive, and no transfers were
actually being sent over i2c). The way it works is by sending a 0 length write
request and checking for NACK. This patch fixes the 0 length writes and actually
sends them.
Reported-by: NDoug Anderson <dianders@chromium.org>
Signed-off-by: NAlexandru M Stan <amstan@chromium.org>
Tested-by: NDoug Anderson <dianders@chromium.org>
Tested-by: NMax Schwarz <max.schwarz@online.de>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>
Cc: stable@kernel.org

Though intel-mid-dma does not follow a new DMA workflow (*) let's prepare SPI
DW driver for that.

(*) The client is obliged to call dma_async_issue_pending() which starts the
actual transfers. Old DMA drivers do not follow this, since requirement was
introduced in the discussion of [1].

[1] http://www.spinics.net/lists/arm-kernel/msg125987.htmlSigned-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

Instead of direct dereference to dmaengine callbacks we are going to use
DMAengine wrappers.
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

Instead of using magic numbers in the code we create a bit map definition of
the DMACR register and use it.

There is no functional change.
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

It has come to my attention (thanks Martin) that 'discard_zeroes_data'
is only a hint.  Some devices in some cases don't do what it
says on the label.

The use of DISCARD in RAID5 depends on reads from discarded regions
being predictably zero.  If a write to a previously discarded region
performs a read-modify-write cycle it assumes that the parity block
was consistent with the data blocks.  If all were zero, this would
be the case.  If some are and some aren't this would not be the case.
This could lead to data corruption after a device failure when
data needs to be reconstructed from the parity.

As we cannot trust 'discard_zeroes_data', ignore it by default
and so disallow DISCARD on all raid4/5/6 arrays.

As many devices are trustworthy, and as there are benefits to using
DISCARD, add a module parameter to over-ride this caution and cause
DISCARD to work if discard_zeroes_data is set.

If a site want to enable DISCARD on some arrays but not on others they
should select DISCARD support at the filesystem level, and set the
raid456 module parameter.
    raid456.devices_handle_discard_safely=Y

As this is a data-safety issue, I believe this patch is suitable for
-stable.
DISCARD support for RAID456 was added in 3.7

Cc: Shaohua Li <shli@kernel.org>
Cc: "Martin K. Petersen" <martin.petersen@oracle.com>
Cc: Mike Snitzer <snitzer@redhat.com>
Cc: Heinz Mauelshagen <heinzm@redhat.com>
Cc: stable@vger.kernel.org (3.7+)
Acked-by: NMartin K. Petersen <martin.petersen@oracle.com>
Acked-by: NMike Snitzer <snitzer@redhat.com>
Fixes: 620125f2Signed-off-by: NNeilBrown <neilb@suse.de>

Linus commit 05c63c2f modified the
runtime suspend/resume paths to skip over display-related tasks to
avoid locking issues on resume.

Unfortunately, this resulted in the display hardware being left in
a partially initialised state, preventing subsequent modesets from
completing.

This commit unifies the (many) suspend/resume paths, bringing back
display (and fbcon) handling in the runtime paths.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Preparation for some runtime pm fixes.  Currently we skip over fbcon
suspend/resume in the runtime path, which causes issues on resume if
fbcon tries to write to the framebuffer before the BAR subdev has
been resumed to restore the BAR1 VM setup.

As we might be woken up via a sysfs connector, we are unable to call
fb_set_suspend() in the resume path as it could make its way down to
a modeset and cause all sorts of locking hilarity.

To solve this, we'll just delay the fbcon resume to a workqueue.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Xorg (and any non-DRM client really) doesn't have permission to directly
touch VRAM on nv50 and up, which the fence code prior to g84 depends on.

It's less invasive to temporarily grant it premission to do so, as it
previously did, than it is to rework fencenv50 to use the VM.  That
will come later on.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Reported in fdo#82527 comment #2.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

The firmware would be clear when the power cut is enabled for
RTL8153.
Signed-off-by: NHayes Wang <hayeswang@realtek.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

The xxx_clear_bp() is used to halt the firmware. It only necessary
for updating the new firmware. Besides, depend on the version of
the current firmware, it may have problem to halt the firmware
directly. Finally, halt the firmware would let the firmware code
useless, and the bugs which are fixed by the firmware would occur.
Signed-off-by: NHayes Wang <hayeswang@realtek.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

This driver, similar to tg3, has a check that will
cause full sized 802.1ad frames to be dropped.  The
frame will be larger then the standard mtu due to the
presense of vlan header that has not been stripped.
The driver should not drop this frame and should process
it just like it does for 802.1q.

CC: Sony Chacko <sony.chacko@qlogic.com>
CC: Dept-HSGLinuxNICDev@qlogic.com
Signed-off-by: NVladislav Yasevich <vyasevic@redhat.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

When receiving a vlan-tagged frame that still contains
a vlan header, the length of the packet will be greater
then MTU+ETH_HLEN since it will account of the extra
vlan header.  TG3 checks this for the case for 802.1Q,
but not for 802.1ad.  As a result, full sized 802.1ad
frames get dropped by the card.

Add a check for 802.1ad protocol when receving full
sized frames.
Suggested-by: NPrashant Sreedharan <prashant@broadcom.com>
CC: Prashant Sreedharan <prashant@broadcom.com>
CC: Michael Chan <mchan@broadcom.com>
Signed-off-by: NVladislav Yasevich <vyasevic@redhat.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Fix the serial console on machines where the serial port is located on
the SuperIO chip.
Signed-off-by: NHelge Deller <deller@gmx.de>
Cc: Peter Hurley <peter@hurleysoftware.com>

When uhid_get_report() or uhid_set_report() are called, they emit on the
char device a UHID_GET_REPORT or UHID_SET_REPORT message. Then, the
protocol says that the user space asnwers with UHID_GET_REPORT_REPLY
or UHID_SET_REPORT_REPLY.

Unfortunatelly, the current code waits for an event of type UHID_GET_REPORT
or UHID_SET_REPORT instead of the reply one.
Add 1 to UHID_GET_REPORT or UHID_SET_REPORT to actually wait for the
reply, and validate the reply.
Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
Reviewed-by: NDavid Herrmann <dh.herrmann@gmail.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

The Armada SoC family implementation of this SPI hardware module has
extended the configuration register to allow for a wider range of SPI
clock rates. Specifically the Serial Baud Rate Pre-selection bits in the
SPI Interface Configuration Register now also use bits 6 and 7 as well.

Modify the baud rate calculation to handle these differences for the
Armada case. Potentially a baud rate can be setup using a number of
different pre-scalar and scalar combinations. This code tries all
possible pre-scalar divisors (8 in total) to try and find the most
accurate set.

This change introduces (and documents) a new device tree compatible
device name "armada-370-spi" to support this.
Signed-off-by: NGreg Ungerer <gerg@uclinux.org>
Tested-by: NEzequiel Garcia <ezequiel.garcia@free-electrons.com>
Reviewed-by: NEzequiel Garcia <ezequiel.garcia@free-electrons.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

cxgbi_inet6addr_handler() can be called in interrupt context, so use rcu
protected list while finding netdev.  This is observed as a scheduling in
atomic oops when running over ipv6.

Fixes: fc8d0590 ("libcxgbi: Add ipv6 api to driver")
Fixes: 759a0cc5 ("cxgb4i: Add ipv6 code to driver, call into libcxgbi ipv6 api")
Signed-off-by: NAnish Bhatt <anish@chelsio.com>
Signed-off-by: NKaren Xie <kxie@chelsio.com>
Signed-off-by: NChristoph Hellwig <hch@lst.de>
Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>

There is a second mouse sharing the same vendor strings but different IDs.
Signed-off-by: NOliver Neukum <oneukum@suse.de>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
Acked-by: NJason Gerecke <killertofu@gmail.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

ISDv4 and v5 are plain HID devices. We can directly implement a generic
HID parsing/handling and remove the need to manually add those PID in
the list of supported devices.

This patch implements the pen support only. The finger part will come in
a later patch.

To be properly notified of an .event() and a .report(), we need to force
hid-core to go through the HID parsing. By default, wacom.ko binds only
hidraw, so the hid parsing is not done by hid-core. When a true HID device
is there, we add the flag HID_CLAIMED_DRIVER to hid->claimed which will
force hid-core to parse the incoming reports.
(Note that this can be easily backported by directly setting the .claimed
flag to HID_CLAIMED_DRIVER even if hid-core does not support
HID_CONNECT_DRIVER)
Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
Acked-by: NJason Gerecke <killertofu@gmail.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

This allows to have the input devices ready in while parsing the reports
descriptor.
Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
Acked-by: NJason Gerecke <killertofu@gmail.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

If the input can be created earlier during probe, we can already populate
them while reading the report descriptor. This way, we can rely on the
hid subsystem directly for tablets which already provide a meaningful
report descriptor (like ISDv4-5).

This patch only splits the allocation and registration, but do not
change where we allocate the input. This will come in a later patch.
Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
Acked-by: NJason Gerecke <killertofu@gmail.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

When we have to deal with new elements in probe, having the exit labels
named sequencially is a pain to maintain. Put a meaningful name instead
so that we do not have to renumber them on inserts.
Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
Acked-by: NJason Gerecke <killertofu@gmail.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

The flag of RTL8152_UNPLUG should only be set when the device is
unplugged, not each time the rtl8152_disconnect() is called.
Otherwise, the device wouldn't be stopped normally.
Signed-off-by: NHayes Wang <hayeswang@realtek.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

o Driver is not updating sw_consumer while processing Tx completion
  when interface is going down. Due to this interface down path gets
  stuck forever waiting for NAPI to complete.
Signed-off-by: NManish Chopra <manish.chopra@qlogic.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

o __netxen_nic_down() function might sleep while holding spinlock_t(tx_clean_lock).
  Acquire this lock for only releasing TX buffers instead of taking it
  for whole down path.
Reported-by: NMike Galbraith <umgwanakikbuti@gmail.com>
Signed-off-by: NManish Chopra <manish.chopra@qlogic.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Commit 8e30444e ("cpufreq: fix cpufreq suspend/resume for intel_pstate")
introduced a bug where the governors wouldn't be stopped anymore for
->target{_index}() drivers during suspend. This happens because
'cpufreq_suspended' is updated before stopping the governors during suspend
and due to this __cpufreq_governor() would return early due to this check:

	/* Don't start any governor operations if we are entering suspend */
	if (cpufreq_suspended)
		return 0;

Fixes: 8e30444e ("cpufreq: fix cpufreq suspend/resume for intel_pstate")
Cc: 3.15+ <stable@vger.kernel.org> # 3.15+: 8e30444e "cpufreq: fix cpufreq suspend/resume for intel_pstate"
Signed-off-by: NViresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

The debugfs file would only define if the line was "pulled" and
not which direction (pull up or pull down). Improve this by
taking two print paths depending on whether the pin is set as
input or output and use the data register directly to figure
out whether the pin is set for pull up or pull down.
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

This is a patch for fixing a bug about mask bit operation.
Signed-off-by: NJames Ban <james.ban.opensource@diasemi.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

The other two interrupt handlers in this driver are shared, except this
one. When loading the driver, it fails like this.

So make the IRQ line shared.

Freescale(R) MPC85xx EDAC driver, (C) 2006 Montavista Software
mpc85xx_mc_err_probe: No ECC DIMMs discovered
EDAC DEVICE0: Giving out device to module MPC85xx_edac controller mpc85xx_l2_err: DEV mpc85xx_l2_err (INTERRUPT)
genirq: Flags mismatch irq 16. 00000000 ([EDAC] L2 err) vs. 00000080 ([EDAC] PCI err)
mpc85xx_l2_err_probe: Unable to request irq 16 for MPC85xx L2 err
remove_proc_entry: removing non-empty directory 'irq/16', leaking at least 'aerdrv'
------------[ cut here ]------------
WARNING: at fs/proc/generic.c:521
Modules linked in:
CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.17.0-rc5-dirty #1
task: ee058000 ti: ee046000 task.ti: ee046000
NIP: c016c0c4 LR: c016c0c4 CTR: c037b51c
REGS: ee047c10 TRAP: 0700 Not tainted (3.17.0-rc5-dirty)
MSR: 00029000 <CE,EE,ME> CR: 22008022 XER: 20000000

GPR00: c016c0c4 ee047cc0 ee058000 00000053 00029000 00000000 c037c744 00000003
GPR08: c09aab28 c09aab24 c09aab28 00000156 20008028 00000000 c0002ac8 00000000
GPR16: 00000000 00000000 00000000 00000000 00000000 00000000 00000139 c0950394
GPR24: c09f0000 ee5585b0 ee047d08 c0a10000 ee047d08 ee15f808 00000002 ee03f660
NIP [c016c0c4] remove_proc_entry
LR [c016c0c4] remove_proc_entry
Call Trace:
remove_proc_entry (unreliable)
unregister_irq_proc
free_desc
irq_free_descs
mpc85xx_l2_err_probe
platform_drv_probe
really_probe
__driver_attach
bus_for_each_dev
bus_add_driver
driver_register
mpc85xx_mc_init
do_one_initcall
kernel_init_freeable
kernel_init
ret_from_kernel_thread
Instruction dump: ...

Reported-and-tested-by: <lpb_098@163.com>
Acked-by: NJohannes Thumshirn <johannes.thumshirn@men.de>
Cc: stable@vger.kernel.org
Signed-off-by: NBorislav Petkov <bp@suse.de>

We refactor the DT parser to look for either a config or a
function and then look for further nodes and reserve maps,
not the two things mixed up like prior to this patch.
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>