If CONFIG_UIDGID_STRICT_TYPE_CHECKS is enalbed, the below compile
failure will be triggered:

	drivers/base/devtmpfs.c: In function 'handle_create':
	drivers/base/devtmpfs.c:214:19: error: incompatible types when assigning to type 'kuid_t' from type 'uid_t'
	drivers/base/devtmpfs.c:215:19: error: incompatible types when assigning to type 'kgid_t' from type 'gid_t'
	make[2]: *** [drivers/base/devtmpfs.o] Error 1

This patch fixes the compile failure.
Signed-off-by: NMing Lei <ming.lei@canonical.com>
Cc: Kay Sievers <kay@vrfy.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

This fixes a sparse warning, and is a good idea given that the
devtmpfs_init() prototype is in this file.
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Some drivers want to tell userspace what uid and gid should be used for
their device nodes, so allow that information to percolate through the
driver core to userspace in order to make this happen.  This means that
some systems (i.e.  Android and friends) will not need to even run a
udev-like daemon for their device node manager and can just rely in
devtmpfs fully, reducing their footprint even more.
Signed-off-by: NKay Sievers <kay@vrfy.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

commit eca4549f "sysfs: Add crash_notes_size to export percpu
note size" adds a printk that outputs a size_t value as %lu
when it should be %zu, resulting in this warning.

drivers/base/cpu.c: In function 'show_crash_notes_size':
drivers/base/cpu.c:142:2: warning: format '%lu' expects argument of type 'long unsigned int', but argument 3 has type 'unsigned int' [-Wformat=]
Reported-by: Nkbuild test robot <fengguang.wu@intel.com>
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Cc: Zhang Yanfei <zhangyanfei@cn.fujitsu.com>
Cc: Simon Horman <horms@verge.net.au>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

On some hardware configurations we have got the request line with the offset.
The patch introduces convert_slave_id() helper for that cases. The request line
base is came from the driver data provided by the platform_device_id table.
Signed-off-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Cc: Viresh Kumar <viresh.kumar@linaro.org>
Acked-by: NViresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: NVinod Koul <vinod.koul@intel.com>

As reported by Wu Fengguang's build robot tracking sparse warnings, the
dma_spec arguments in the dw_dma_xlate are already byte swapped on
little-endian platforms and must not get swapped again. This code is
currently not used anywhere, but will be used in Linux 3.10 when the
ARM SPEAr platform starts using the generic DMA DT binding.
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Reported-by: NFengguang Wu <fengguang.wu@intel.com>
Acked-by: NViresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: NVinod Koul <vinod.koul@intel.com>

A result of ENOENT from a read request for an object that's part of
an rbd image indicates that there is a hole in that portion of the
image.  Similarly, a short read for such an object indicates that
the remainder of the read should be interpreted a full read with
zeros filling out the end of the request.

This behavior is not correct for objects that are not backing rbd
image data.  Currently rbd_img_obj_request_callback() assumes it
should be done for all objects.

Change rbd_img_obj_request_callback() so it only does this zeroing
for image objects.  Encapsulate that special handling in its own
function.  Add an assertion that the image object request is a bio
request, since we assume that (and we currently don't support any
other types).

This resolves a problem identified here:
    http://tracker.ceph.com/issues/4559

The regression was introduced by bf0d5f50.
Reported-by: NDan van der Ster <dan@vanderster.com>
Signed-off-by: NAlex Elder <elder@inktank.com>
Reviewed-off-by: NSage Weil <sage@inktank.com>

For percpu notes, we are exporting only address and not size. So
the userspace tool kexec-tools is putting an upper limit of 1024
and putting the value in p_memsz and p_filesz fields. So the patch
add the new sysfile crash_notes_size to export the exact percpu
note size and let the kexec-tools parse it intead of using 1024.

The idea came from Vivek Goyal. And a later patch will be sent to
kexec-tools to let it parse the size.

Cc: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: Vivek Goyal <vgoyal@redhat.com>
Signed-off-by: NZhang Yanfei <zhangyanfei@cn.fujitsu.com>
Acked-by: NSimon Horman <horms@verge.net.au>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Signed-off-by: NFabio Porcedda <fabio.porcedda@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Add documentation that platform_driver_probe() is incompatible with
deferred probing.
Signed-off-by: NFabio Porcedda <fabio.porcedda@gmail.com>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

This patch fixes a regression introduced in v3.8-rc1 code where a failed
target_check_reservation() check in target_setup_cmd_from_cdb() was causing
an incorrect SAM_STAT_GOOD status to be returned during a WRITE operation
performed by an unregistered / unreserved iscsi initiator port.

This regression is only effecting iscsi-target due to a special case check
for TCM_RESERVATION_CONFLICT within iscsi_target_erl1.c:iscsit_execute_cmd(),
and was still correctly disallowing WRITE commands from backend submission
for unregistered / unreserved initiator ports, while returning the incorrect
SAM_STAT_GOOD status due to the missing SAM_STAT_RESERVATION_CONFLICT
assignment.

This regression was first introduced with:

commit de103c93
Author: Christoph Hellwig <hch@lst.de>
Date:   Tue Nov 6 12:24:09 2012 -0800

    target: pass sense_reason as a return value

Go ahead and re-add the missing SAM_STAT_RESERVATION_CONFLICT assignment
during a target_check_reservation() failure, so that iscsi-target code
sends the correct SCSI status.

All other fabrics using target_submit_cmd_*() with a RESERVATION_CONFLICT
call to transport_generic_request_failure() are not effected by this bug.
Reported-by: NJeff Leung <jleung@curriegrad2004.ca>
Cc: Christoph Hellwig <hch@lst.de>
Cc: <stable@vger.kernel.org>
Signed-off-by: NNicholas Bellinger <nab@linux-iscsi.org>

This patch adds a VHOST_SCSI_FEATURES mask minus VIRTIO_RING_F_EVENT_IDX
so that vhost-scsi-pci userspace will strip this feature bit once
GET_FEATURES reports it as being unsupported on the host.

This is to avoid a bug where ->handle_kicks() are missed when EVENT_IDX
is enabled by default in userspace code.

(mst: Rename to VHOST_SCSI_FEATURES + add comment)
Acked-by: NMichael S. Tsirkin <mst@redhat.com>
Reviewed-by: NAsias He <asias@redhat.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: NNicholas Bellinger <nab@linux-iscsi.org>

It enhances the driver for FTDI-based USB serial adapters
to recognize Mitsubishi Electric Corp. USB/RS422 Converters
as FT232BM chips and support them.
https://search.meau.com/?q=FX-USB-AWSigned-off-by: NKonstantin Holoborodko <klh.kernel@gmail.com>
Tested-by: NKonstantin Holoborodko <klh.kernel@gmail.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Fix to return a negative error code from the error handling
case instead of 0, as returned elsewhere in this function.
Signed-off-by: NWei Yongjun <yongjun_wei@trendmicro.com.cn>
Reviewed-by: NJingoo Han <jg1.han@samsung.com>
Signed-off-by: NJens Axboe <axboe@kernel.dk>

In unmask_evtchn(), when the mask bit is cleared after testing for
pending and the event becomes pending between the test and clear, then
the upcall will not become pending and the event may be lost or
delayed.

Avoid this by always clearing the mask bit before checking for
pending.  If a hypercall is needed, remask the event as
EVTCHNOP_unmask will only retrigger pending events if they were
masked.

This fixes a regression introduced in 3.7 by
b5e57923 (xen/events: fix
unmask_evtchn for PV on HVM guests) which reordered the clear mask and
check pending operations.

Changes in v2:
- set mask before hypercall.

Cc: stable@vger.kernel.org
Acked-by: NStefano Stabellini <stefano.stabellini@eu.citrix.com>
Signed-off-by: NDavid Vrabel <david.vrabel@citrix.com>
Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>

With the Xen ACPI stub code (CONFIG_XEN_STUB=y) enabled, the power
C and P states are no longer uploaded to the hypervisor.

The reason is that the Xen CPU hotplug code: xen-acpi-cpuhotplug.c
and the xen-acpi-stub.c register themselves as the "processor" type object.

That means the generic processor (processor_driver.c) stops
working and it does not call (acpi_processor_add) which populates the

         per_cpu(processors, pr->id) = pr;

structure. The 'pr' is gathered from the acpi_processor_get_info function
which does the job of finding the C-states and figuring out PBLK address.

The 'processors->pr' is then later used by xen-acpi-processor.c (the one that
uploads C and P states to the hypervisor). Since it is NULL, we end
skip the gathering of _PSD, _PSS, _PCT, etc and never upload the power
management data.

The end result is that enabling the CONFIG_XEN_STUB in the build means that
xen-acpi-processor is not working anymore.

This temporary patch fixes it by marking the XEN_STUB driver as
BROKEN until this can be properly fixed.

CC: jinsong.liu@intel.com
Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>

The current lpc32xx_defconfig breaks like this, caused by recent phy
restructuring:

  LD      init/built-in.o
drivers/built-in.o: In function `usb_hcd_nxp_probe':
drivers/usb/host/ohci-nxp.c:224: undefined reference to `isp1301_get_client'
drivers/built-in.o: In function `lpc32xx_udc_probe':
drivers/usb/gadget/lpc32xx_udc.c:3104: undefined reference to
`isp1301_get_client' distcc[27867] ERROR: compile (null) on localhost failed
make: *** [vmlinux] Error 1

Caused by 1c208881 (usb: Makefile: fix
drivers/usb/phy/ Makefile entry)

This patch fixes this by selecting USB_OTG_UTILS in Kconfig which
causes the phy driver to be built again.
Signed-off-by: NRoland Stigge <stigge@antcom.de>
Acked-by: NFelipe Balbi <balbi@ti.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Commit "HID: multitouch: use the callback "report" instead..." breaks the
buttons of touchpads following the HID multitouch specification.
The buttons were emmitted through hid-input, but as now the events
are generated only in hid-multitouch, the buttons are not emmitted anymore.

The input_event() call is far much simpler than the hid-input one as
many of the different tests do not apply to multitouch touchpads.
Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

There is a bug introduced with commit 27c2127a that causes
devices which are hot unplugged and then hot-replugged to
not have per-device dma_ops set. This causes these devices
to not function correctly. Fixed with this patch.

Cc: stable@vger.kernel.org
Reported-by: NAndreas Degert <andreas.degert@googlemail.com>
Signed-off-by: NJoerg Roedel <joro@8bytes.org>

vcs_poll_data_free() calls unregister_vt_notifier(), which calls
atomic_notifier_chain_unregister(), which calls synchronize_rcu().
Do it *after* we'd dropped ->f_lock.

Cc: stable@vger.kernel.org (all kernels since 2.6.37)
Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>

During merging the PCI tree with the PM/ACPI tree, Linus noticed
that we don't use the same lock using patten about ACPI PCI root as
acpiphp.

Here apply the same locking patten, and we need to execute
acpi_bus_hot_remove_device() via acpi_os_hotplug_execute()
as it also holds acpi_scan_lock.

[rjw: Changelog]
Reported-by: NLinus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: NYinghai Lu <yinghai@kernel.org>
No-objection-from: Bjorn Helgaas <bhelgaas@google.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

In Table 18-289, ACPI5.0 SPEC, the error data length in CPER
Generic Error Data Entry can be 0, which means this generic
error data entry can have only one header. So fix the check
conditon for it.
Signed-off-by: NChen Gong <gong.chen@linux.intel.com>
Reviewed-by: NHuang Ying <ying.huang@intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

Add Sony Vaio VGN-FW21M to the device blacklist in
drivers/acpi/sleep.c.

Fixes suspend/resume on this device (device no longer reboots
instead of resuming).

References: https://bugzilla.kernel.org/show_bug.cgi?id=55001Signed-off-by: NFabio Valentini <fafatheone@gmail.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

Signed-off-by: NPhilip J Kelleher <pjk1939@linux.vnet.ibm.com>
Signed-off-by: NJens Axboe <axboe@kernel.dk>

Commit d8d595df introduced a bug where we did not check for a NULL
return from kmalloc(). Make rsxx_eeh_save_issued_dmas() return an
error for that case, and make the callers handle that.
Signed-off-by: NPhilip J Kelleher <pjk1939@linux.vnet.ibm.com>
Signed-off-by: NJens Axboe <axboe@kernel.dk>

If slave sysfs symlink failes to be created - we end up without removing
the master sysfs symlink. Remove it in case of failure.
Signed-off-by: NVeaceslav Falico <vfalico@redhat.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Johan's 'fix use-after-free in TIOCMIWAIT' patchset[1] introduces
one bug which can cause kernel hang when opening port.

This patch initialized the 'port->delta_msr_wait' waitqueue head
to fix the bug which is introduced in 3.9-rc4.

[1], http://marc.info/?l=linux-usb&m=136368139627876&w=2

Cc: stable <stable@vger.kernel.org>
Signed-off-by: NMing Lei <tom.leiming@gmail.com>
Acked-by: NJohan Hovold <jhovold@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

skb->ip_summed should be CHECKSUM_UNNECESSARY when the driver reports that
checksums were correct and CHECKSUM_NONE in any other case. They're
currently placed vice versa, which breaks the forwarding scenario. Fix it
by placing them as described above.
Signed-off-by: NVeaceslav Falico <vfalico@redhat.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Remove duplicated include.
Signed-off-by: NWei Yongjun <yongjun_wei@trendmicro.com.cn>
Signed-off-by: NJoerg Roedel <joro@8bytes.org>

Since commit a1fd2877:
"[media] bttv-driver: fix two warnings"
cropcap.defrect.height and cropcap.bounds.height for the PAL entry are 32
resp 30 pixels too large, if a userspace app (ie xawtv) actually tries to use
the full advertised height, the resulting image is broken in ways only a
screenshot can describe.
The cause of this is the fix for this warning:
drivers/media/pci/bt8xx/bttv-driver.c:308:3: warning: initialized field overwritten [-Woverride-init]
In this chunk of the commit:
@@ -301,11 +301,10 @@ const struct bttv_tvnorm bttv_tvnorms[] = {
                        /* totalwidth */ 1135,
                        /* sqwidth */ 944,
                        /* vdelay */ 0x20,
-                       /* sheight */ 576,
-                       /* videostart0 */ 23)
                /* bt878 (and bt848?) can capture another
                   line below active video. */
-               .cropcap.bounds.height = (576 + 2) + 0x20 - 2,
+                       /* sheight */ (576 + 2) + 0x20 - 2,
+                       /* videostart0 */ 23)
        },{
                .v4l2_id        = V4L2_STD_NTSC_M | V4L2_STD_NTSC_M_KR,
                .name           = "NTSC",
Which replaces the overriding of cropcap.bounds.height initialization outside
of the CROPCAP macro (which also initializes it), with passing a
different sheight value to the CROPCAP macro.
There are 2 problems with this warning fix:
1) The sheight value is used twice in the CROPCAP macro, and the old code
   only changed one resulting value.
2) The old code increased the .cropcap.bounds.height value (and did not
   touch the .cropcap.defrect.height value at all) by 2, where as the fixed
   code increases it by 32, as the fixed code passes (576 + 2) + 0x20 - 2
   to the CROPCAP macro, but the + 0x20 - 2 is already done by the macro so
   now is done twice for .cropcap.bounds.height, and also is applied to
   .cropcap.defrect.height where it should not be applied at all.
This patch fixes this by adding an extraheight parameter to the CROPCAP entry
and using it for the PAL entry.

Cc: stable@kernel.org	# For Kernel 3.8
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

For 82576 MAC type, max_adj is reported as 1000000000 ppb. However, if
this value is passed to igb_ptp_adjfreq_82576, incvalue overflows out of
INCVALUE_82576_MASK, resulting in setting of zero TIMINCA.incvalue, stopping
the PHC (instead of going at twice the nominal speed).

Fix the advertised max_adj value to the largest value hardware can handle.
As there is no min_adj value available (-max_adj is used instead), this will
also prevent stopping the clock intentionally. It's probably not a big deal,
other igb MAC types don't support stopping the clock, either.
Signed-off-by: NJiri Benc <jbenc@redhat.com>
Acked-by: NMatthew Vick <matthew.vick@intel.com>
Tested-by: NAaron Brown <aaron.f.brown@intel.com>
Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>

Trivial sparse warning.
Signed-off-by: NStephen Hemminger <stephen@networkplumber.org>
Tested-by: NAaron Brown <aaron.f.brown@intel.com>
Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>

igb is ineffective at setting a lower total VFs because:

int pci_sriov_set_totalvfs(struct pci_dev *dev, u16 numvfs)
{
        ...
        /* Shouldn't change if VFs already enabled */
        if (dev->sriov->ctrl & PCI_SRIOV_CTRL_VFE)
                return -EBUSY;

Swap init ordering.
Signed-off-by: NAlex Williamson <alex.williamson@redhat.com>
Acked-by: NGreg Rose <gregory.v.rose@intel.com>
Tested-by: NAaron Brown <aaron.f.brown@intel.com>
Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>

The max_vfs= option has always been self limiting to the number of VFs
supported by the device.  fa44f2f1 added SR-IOV configuration via
sysfs, but in the process broke this self correction factor.  The
failing path is:

igb_probe
  igb_sw_init
    if (max_vfs > 7) {
        adapter->vfs_allocated_count = 7;
    ...
    igb_probe_vfs
    igb_enable_sriov(, max_vfs)
      if (num_vfs > 7) {
        err = -EPERM;
        ...

This leaves vfs_allocated_count = 7 and vf_data = NULL, so we bomb out
when igb_probe finally calls igb_reset.  It seems like a really bad
idea, and somewhat pointless, to set vfs_allocated_count separate from
vf_data, but limiting max_vfs is enough to avoid the null pointer.
Signed-off-by: NAlex Williamson <alex.williamson@redhat.com>
Acked-by: NGreg Rose <gregory.v.rose@intel.com>
Tested-by: NAaron Brown <aaron.f.brown@intel.com>
Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>

Fix a problem in i350 where anti spoofing configuration was written into a
wrong register.
Signed-off-by: NLior Levy <lior.levy@intel.com>
Tested-by: NAaron Brown <aaron.f.brown@intel.com>
Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>

When the ixgbevf driver is opened the request to allocate MSIX irq
vectors may fail.  In that case the driver will call ixgbevf_down()
which will call ixgbevf_irq_disable() to clear the HW interrupt
registers and calls synchronize_irq() using the msix_entries pointer in
the adapter structure.  However, when the function to request the MSIX
irq vectors failed it had already freed the msix_entries which causes
an OOPs from using the NULL pointer in synchronize_irq().

The calls to pci_disable_msix() and to free the msix_entries memory
should not occur if device open fails.  Instead they should be called
during device driver removal to balance with the call to
pci_enable_msix() and the call to allocate msix_entries memory
during the device probe and driver load.
Signed-off-by: NLi Xun <xunleer.li@huawei.com>
Signed-off-by: NGreg Rose <gregory.v.rose@intel.com>
Tested-by: NSibai Li <sibai.li@intel.com>
Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>

This patch removes dynamic allocation on the stack error.
Signed-off-by: NPhilip J Kelleher <pjk1939@linux.vnet.ibm.com>
Signed-off-by: NJens Axboe <axboe@kernel.dk>

The Boot ROM has an issue which will cause the driver to
lock up as pending irqs are not being cleared. With them
cleared it prevents that issue.

This patch is needed for the current (3.9-rc3) mainline kernel. I guess
it went unnoticed, because it was only tested with u-boot up until now.
And u-boot maybe handles this.

[s.trumtrar@pengutronix.de: cherry-picked from linux-xlnx.git]
Signed-off-by: NSteffen Trumtrar <s.trumtrar@pengutronix.de>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

They were introduced by mistake in 3.7. Let's deprecate them now. For
the reasons, see the text in Kconfig below.
Signed-off-by: NJiri Slaby <jslaby@suse.cz>
Cc: Josh Boyer <jwboyer@redhat.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

In 3.7 the 8250 module name was changed unintentionally from 8250 to
8250_core by commit 835d844d
(8250_pnp: do pnp probe before legacy probe). We then had to
re-introduce the old module options to ensure the old good
8250.nr_uart & co. still work. This can be done only by a very dirty
hack and we did it in f2b8dfd9
(serial: 8250: Keep 8250.<xxxx> module options functional after driver
rename).

That is so damn ugly so that I decided to revert to the old module
name and deprecate the new 8250_core options present in 3.7 and 3.8
only. The deprecation will happen in the following patch.

Note that this patch changes the hack above to support "8250_core.*",
because we now have "8250.*" natively.
Signed-off-by: NJiri Slaby <jslaby@suse.cz>
Cc: Josh Boyer <jwboyer@redhat.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>