Correct spelling typo in printk and comment within drivers/target.
Signed-off-by: NMasanari Iida <standby24x7@gmail.com>
Signed-off-by: NNicholas Bellinger <nab@linux-iscsi.org>

Every fabric driver has to supply a se_tfo->set_fabric_sense_len()
method, just so iSCSI can return an offset of 2.  However, every fabric
driver is already allocating a sense buffer and passing it into the
target core, either via transport_init_se_cmd() or target_submit_cmd().

So instead of having iSCSI pass the start of its sense buffer into the
core and then later tell the core to skip the first 2 bytes, it seems
easier for iSCSI just to do the offset of 2 when it passes the sense
buffer into the core.  Then we can drop the se_tfo->set_fabric_sense_len()
everywhere, and just add a couple of lines of code to iSCSI to set the
sense data length to the beginning of the buffer right before it sends
it over the network.

(nab: Remove .set_fabric_sense_len usage from tcm_qla2xxx_npiv_ops +
      change transport_get_sense_buffer to follow v3.6-rc6 code w/o
      ->set_fabric_sense_len usage)
Signed-off-by: NRoland Dreier <roland@purestorage.com>
Signed-off-by: NNicholas Bellinger <nab@linux-iscsi.org>

There are no callers of se_tfo->get_fabric_sense_len(), so we should
stop having every fabric driver implement it.
Signed-off-by: NRoland Dreier <roland@purestorage.com>
Signed-off-by: NNicholas Bellinger <nab@linux-iscsi.org>

It's always set, and controls whether uppercase A-F are allowed hex values.
I don't see a reason not to accept these.
Signed-off-by: NAndy Grover <agrover@redhat.com>
Cc: Chris Boot <bootc@bootc.net>
Signed-off-by: NNicholas Bellinger <nab@linux-iscsi.org>

Move static into function body from file scope.

Remove extraneous return statement
Signed-off-by: NAndy Grover <agrover@redhat.com>
Signed-off-by: NNicholas Bellinger <nab@linux-iscsi.org>

It is no longer a supported module.
Signed-off-by: NAndy Grover <agrover@redhat.com>
Signed-off-by: NNicholas Bellinger <nab@linux-iscsi.org>

This patch initialize register map of MUIC device because mfd driver
of Maxim MAX77693 use regmap-muic instance of MUIC device when irqs of
Maxim MAX77693 is initialized before call max77693-muic probe() function.
Signed-off-by: NChanwoo Choi <cw00.choi@samsung.com>
Signed-off-by: NMyungjoo Ham <myungjoo.ham@samsung.com>
Signed-off-by: NKyungmin Park <kyungmin.park@samsung.com>
Reported-by: NSylwester Nawrocki <s.nawrocki@samsung.com>
Acked-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>

This patch fix bug related to interrupt handling for MAX77693 devices.
- Unmask interrupt masking bit for charger/flash/muic to revolve
that interrupt isn't happened when external connector is attached.
- Fix wrong regmap instance when muic interrupt is happened.

This patch were discussed and confirm discussion about this patch on below url:
http://lkml.org/lkml/2012/7/16/118Signed-off-by: NChanwoo Choi <cw00.choi@samsung.com>
Signed-off-by: NMyungjoo Ham <myungjoo.ham@samsung.com>
Signed-off-by: NKyungmin Park <kyungmin.park@samsung.com>
Acked-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>

Currently the MFD core supports remapping MFD cell interrupts using an
irqdomain but only if the MFD is being instantiated using device tree
and only if the device tree bindings use the pattern of registering IPs
in the device tree with compatible properties.  This will be actively
harmful for drivers which support non-DT platforms and use this pattern
for their DT bindings as it will mean that the core will silently change
remapping behaviour and it is also limiting for drivers which don't do
DT with this particular pattern.  There is also a potential fragility if
there are interrupts not associated with MFD cells and all the cells are
omitted from the device tree for some reason.

Instead change the code to take an IRQ domain as an optional argument,
allowing drivers to take the decision about the parent domain for their
interrupts.  The one current user of this feature is ab8500-core, it has
the domain lookup pushed out into the driver.
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>

commit a606dac3 adds support to link
devices which have _PRx, if a device does not have _PRx, a warning
message will be printed.

This commit is for ZPODD on Intel ZPODD capable platforms, on other
platforms, it has no problem if there is no power resource for this
device, so a warning here is not appropriate, change it to debug.
Reported-by: NBorislav Petkov <bp@amd64.org>
Signed-off-by: NAaron Lu <aaron.lu@intel.com>
Cc: stable@vger.kernel.org
Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>

The code currently always selects turbo mode for PCA9665, no matter which
clock frequency is configured. This is because it compares the clock frequency
against constants reflecting (boundary / 100). Compare against real boundary
frequencies to fix the problem.
Signed-off-by: NThomas Kavanagh <tkavanagh@juniper.net>
Signed-off-by: NGuenter Roeck <groeck@juniper.net>
Signed-off-by: NWolfram Sang <w.sang@pengutronix.de>

We noticed a plymouth bug on Fedora 18, and I then
noticed this stupid thinko, fixing it fixed the problem
with plymouth.

Cc: stable@vger.kernel.org
Acked-by: NBen Skeggs <bskeggs@redhat.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Commit 0090def6("ACPI: Add interface to register/unregister device
to/from power resources") used resource_lock to protect the devices list
that relies on power resource. It caused a mutex dead lock, as below

    acpi_power_on ---> lock resource_lock
      __acpi_power_on
        acpi_power_on_device
          acpi_power_get_inferred_state
            acpi_power_get_list_state ---> lock resource_lock

This patch adds a new mutex "devices_lock" to protect the devices list
and calls acpi_power_on_device in acpi_power_on, instead of
__acpi_power_on, after the resource_lock is released.

[rjw: Changed data type of a boolean variable to bool.]
Signed-off-by: NLin Ming <ming.m.lin@intel.com>
Signed-off-by: NAaron Lu <aaron.lu@intel.com>
Cc: stable@vger.kernel.org
Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>

It turns out that there are ACPI BIOSes defining device objects with
_PSx and without either _PSC or _PRx.  For devices corresponding to
those ACPI objetcs __acpi_bus_get_power() returns ACPI_STATE_UNKNOWN
and their initial power states are regarded as unknown as a result.
If such a device is a parent of another power-manageable device, the
child cannot be put into a low-power state through ACPI, because
__acpi_bus_set_power() refuses to change power states of devices
whose parents' power states are unknown.

To work around this problem, observe that the ACPI power state of
a device cannot be higher-power (lower-number) than the power state
of its parent.  Thus, if the device's _PSC method or the
configuration of its power resources indicates that the device is
in D0, the device's parent has to be in D0 as well.  Consequently,
if the parent's power state is unknown when we've just learned that
its child's power state is D0, we can safely set the parent's
power.state field to ACPI_STATE_D0.
Tested-by: NAaron Lu <aaron.lu@intel.com>
Cc: stable@vger.kernel.org
Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>

The acpi_evalf() function modifies four bytes of data but in
fan_get_status() we pass a pointer to u8.  I have modified the
function to use type checking now.
Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: NMatthew Garrett <mjg@redhat.com>

Fix a device reference count leakage issue in function
eeepc_rfkill_hotplug().
Signed-off-by: NJiang Liu <jiang.liu@huawei.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Signed-off-by: NMatthew Garrett <mjg@redhat.com>

MODULE_PARM_DESC for wlan_status is further in the same file
Signed-off-by: NMaxim A. Nikulin <M.A.Nikulin@gmail.com>
Signed-off-by: NCorentin Chary <corentin.chary@gmail.com>
Signed-off-by: NMatthew Garrett <mjg@redhat.com>

Resolves-bug: https://bugzilla.kernel.org/show_bug.cgi?id=24222Signed-off-by: NCorentin Chary <corentin.chary@gmail.com>
Signed-off-by: NMatthew Garrett <mjg@redhat.com>

Signed-off-by: NCorentin Chary <corentin.chary@gmail.com>
Signed-off-by: NMatthew Garrett <mjg@redhat.com>

This function fails to add the start address of the gmux I/O range to
the requested port address and thus writes to the wrong location.
Signed-off-by: NSeth Forshee <seth.forshee@canonical.com>
Signed-off-by: NMatthew Garrett <mjg@redhat.com>

Study of Apple's binary driver revealed that the GMUX_READ_PORT should
be written between calls to gmux_index_wait_ready and
gmux_index_wait_complete (i.e., the new index protocol must be
followed). If this is not done correctly, the indexed
gmux device only partially accepts writes which lead to problems
concerning GPU switching. Special thanks to Seth Forshee who helped
greatly with identifying unnecessary changes.
Signed-off-by: NBernhard Froemel <froemel@vmars.tuwien.ac.at>
Signed-off-by: NMatthew Garrett <mjg@redhat.com>

This patch extracts and displays version information from the indexed
gmux device as it is also done for the classic gmux device.
Signed-off-by: NBernhard Froemel <froemel@vmars.tuwien.ac.at>
Signed-off-by: NMatthew Garrett <mjg@redhat.com>

Commit a3348722 added afex support but lacked
several logical changes. This lack can cause afex to crash, and also
have a slight effect on other flows (i.e., driver always assumes the Tx ring
has less available buffers than what it actually has).

This patch adds the missing segments, fixing said issues.
Signed-off-by: NYuval Mintz <yuvalmin@broadcom.com>
Signed-off-by: NBarak Witkowski <barak@broadcom.com>
Signed-off-by: NDmitry Kravkov <dmitry@broadcom.com>
Signed-off-by: NEilon Greenstein <eilong@broadcom.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Under traffic, there are several registers that when read (e.g., via
'ethtool -d') may cause the chip to stall.
This patch corrects the registers read in such flows.
Signed-off-by: NDmitry Kravkov <dmitry@broadcom.com>
Signed-off-by: NYuval Mintz <yuvalmin@broadcom.com>
Signed-off-by: NEilon Greenstein <eilong@broadcom.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

This patch propagates users' requested flow-control into the link layer,
which will later be used to advertise this flow-control for auto-negotiation
(until now these values were ignored).
Signed-off-by: NYaniv Rosner <yaniv.rosner@broadcom.com>
Signed-off-by: NYuval Mintz <yuvalmin@broadcom.com>
Signed-off-by: NEilon Greenstein <eilong@broadcom.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Prior to this fix, the driver reported the chip's active duplex state
is always 'full', even if using half-duplex mode.
Signed-off-by: NYaniv Rosner <yaniv.rosner@broadcom.com>
Signed-off-by: NYuval Mintz <yuvalmin@broadcom.com>
Signed-off-by: NEilon Greenstein <eilong@broadcom.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Prevent updating the xmac PFC configuration when using a link speed
slower than 10G -the umac block is responsible for 1G or slower connections,
therefore it is possible the xmac block is reset when connection is slower.
Signed-off-by: NYaniv Rosner <yaniv.rosner@broadcom.com>
Signed-off-by: NYuval Mintz <yuvalmin@broadcom.com>
Signed-off-by: NEilon Greenstein <eilong@broadcom.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

FW needs the driver statistics for management. Current logic is broken
in that the function that gathers the port statistics does not copy
its own statistics to a place where the FW can use it.
This patch causes every function that can pass statistics to the FW to
do so.
Signed-off-by: NYuval Mintz <yuvalmin@broadcom.com>
Signed-off-by: NEilon Greenstein <eilong@broadcom.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

During traffic when DCB is enabled, it is possible for multiple instances
of statistics queries to be sent to the chip - this may cause the FW to assert.

This patch prevents the sending of an additional instance of statistics query
while the previous query hasn't completed.
Signed-off-by: NDmitry Kravkov <dmitry@broadcom.com>
Signed-off-by: NYuval Mintz <yuvalmin@broadcom.com>
Signed-off-by: NEilon Greenstein <eilong@broadcom.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Only increase the higher 32bits if we really detect a wrap around.

v2: instead of increasing the higher 32bits just use the higher
    32bits from the last emitted fence.
v3: also use last emitted fence value as upper limit.

The intention of this patch is to make fences as robust as
they where before introducing 64bit fences. This is
necessary because on older systems it looks like the fence
value gets corrupted on initialization.

Fixes:
https://bugs.freedesktop.org/show_bug.cgi?id=51344

Should also fix:
https://bugs.freedesktop.org/show_bug.cgi?id=54129
https://bugs.freedesktop.org/show_bug.cgi?id=54662
https://bugzilla.redhat.com/show_bug.cgi?id=846505
https://bugzilla.redhat.com/show_bug.cgi?id=845639

3.5 needs a separate patch due to changes in the
fence code.  Will send that out separately.
Signed-off-by: NChristian König <deathsimple@vodafone.de>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

For DP we can use the same PPLL for all active DP
encoders.  Take advantage of that to prevent cases
where we may end up sharing a PPLL between DP and
non-DP which won't work.  Also clean up the code
a bit.

v2: - fix missing pll_id assignment in crtc init
v3: - fix DP PPLL check
    - document functions
    - break in main encoder search loop after matching.
      no need to keep checking additional encoders.

fixes:
https://bugs.freedesktop.org/show_bug.cgi?id=54471Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org

This fixes a hang on suspend due to calling wdm_suspend on
the unregistered data interface. The hang should have been
a NULL pointer reference had it not been for a logic error
in the cdc_wdm code.

  commit 230718bd net: qmi_wwan: bind to both control and data interface

changed qmi_wwan to use cdc_wdm as a subdriver for devices with
a two-interface QMI/wwan function.  The commit failed to update
qmi_wwan_suspend and qmi_wwan_resume, which were written to handle
either a single combined interface function, or no subdriver at all.

The result was that we called into the subdriver both when the
control interface was suspended and when the data interface was
suspended.  Calling the subdriver suspend function with an
unregistered interface is not supported and will make the
subdriver bug out.
Signed-off-by: NBjørn Mork <bjorn@mork.no>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

It is a bad idea to hold a spinlock and call flush_work_sync.
Move the workqueue cleanup outside the spinlock and use cancel_work_sync,
on closing the channel this seems to be the more correct function.
Remove the never used and constant return value of mISDN_freebchannel.
Signed-off-by: NKarsten Keil <keil@b1-systems.de>
Cc: <stable@kernel.org>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

They don't always appear as AHCI class devices but instead as IDE class.

Based on an initial patch by Hiroaki Nito

Resolves-bug: https://bugzilla.kernel.org/show_bug.cgi?id=42804Signed-off-by: NAlan Cox <alan@linux.intel.com>
Signed-off-by: NJeff Garzik <jgarzik@redhat.com>

This can also appear as 0x9192. Reported in bugzilla and confirmed with the
board documentation for these boards.

Resolves-bug: https://bugzilla.kernel.org/show_bug.cgi?id=42970Signed-off-by: NAlan Cox <alan@linux.intel.com>
Cc: The Stables <stable@vger.kernel.org>
Signed-off-by: NJeff Garzik <jgarzik@redhat.com>

The JMicron JMB362 controller supports AHCI only, but some revisions
use the IDE class code.  These need to be matched by device ID.

These additions have apparently been included by QNAP in their NAS
devices using these controllers.

References: http://bugs.debian.org/634180Signed-off-by: NBen Hutchings <ben@decadent.org.uk>
Signed-off-by: NJeff Garzik <jgarzik@redhat.com>

this patch removes DRM_FORMAT_NV12M from plane module because this format
is same as DRM_FORMAT_NV12. DRM_FORMAT_NV12M will be identified by
mode_cmd->handles and mode_cmd->offsets fields internally.
Signed-off-by: NInki Dae <inki.dae@samsung.com>
Signed-off-by: NKyungmin.park <kyungmin.park@samsung.com>

The double invocations are incorrect but seem to be safe so I don't
think this will fix any bugs.

Before:

[    7.639366] drm_prime_init_file ee3675d0
[    7.639377] drm_prime_init_file ee3675d0
[    7.639507] drm_prime_destroy_file ee3675d0
[    7.639518] drm_prime_destroy_file ee3675d0
[    7.639802] drm_prime_init_file ee372390
[    7.639810] drm_prime_init_file ee372390
[    8.473316] drm_prime_init_file ee356390
[    8.473331] drm_prime_init_file ee356390

After:

[    6.363842] drm_prime_init_file edc2e5d0
[    6.363994] drm_prime_destroy_file edc2e5d0
[    6.364260] drm_prime_init_file edc2e750
[    8.004837] drm_prime_init_file ee36ded0
Signed-off-by: NMandeep Singh Baines <msb@chromium.org>
Acked-by: NSeung-Woo Kim <sw0312.kim@samsung.com>
Signed-off-by: NInki Dae <inki.dae@samsung.com>
Signed-off-by: NKyungmin Park <kyungmin.park@samsung.com>

This patch adds a stub function for DMABUF mmap.
This allows to export a DMABUF.
Signed-off-by: NTomasz Stanislawski <t.stanislaws@samsung.com>
Signed-off-by: NKyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: NInki Dae <inki.dae@samsung.com>

Fixes the following checkpatch warnings:
WARNING: sizeof filter_y_horiz_tap8 should be sizeof(filter_y_horiz_tap8)
WARNING: sizeof filter_y_vert_tap4 should be sizeof(filter_y_vert_tap4)
WARNING: sizeof filter_cr_horiz_tap4 should be sizeof(filter_cr_horiz_tap4)
Signed-off-by: NSachin Kamat <sachin.kamat@linaro.org>
Signed-off-by: NInki Dae <inki.dae@samsung.com>
Signed-off-by: NKyungmin Park <kyungmin.park@samsung.com>