Currently libata statically allows only 1-block (512-byte) payload
for each TRIM command. Each payload can carry 64 TRIM ranges since
each range requires 8 bytes.

It is silly to keep doing the calculation (512 / 8) in different
places. Hence, define the new ATA_MAX_TRIM_RNUM for the result.
Signed-off-by: NTom Yan <tom.ty89@gmail.com>
Signed-off-by: NTejun Heo <tj@kernel.org>

Currently if a WRITE SAME (16) command is issued to the SATL with
"number of blocks" that is larger than the "Maximum write same length"
(which is the maximum number of blocks per TRIM command allowed in
libata, currently 65535 * 512 / 8 blocks), the SATL will accept the
command and translate it to a TRIM command with the upper limit.

However, according to SBC (as of sbc4r11.pdf), the "device server"
should terminate the command with "Invalid field in CDB" in that case.
Signed-off-by: NTom Yan <tom.ty89@gmail.com>
Signed-off-by: NTejun Heo <tj@kernel.org>

To make it consistent with the recently added ata_mselect_control().
We probably shouldn't have the word "mode" in its name anyway, since
that's not the case for other ata_msense_*() / ata_mselect_*() either.
Signed-off-by: NTom Yan <tom.ty89@gmail.com>
Signed-off-by: NTejun Heo <tj@kernel.org>

The bit should always be set to 1 when the requested version of
page is "changeable" because we've made it so in ata_mselect_control().
Also, it should always be set to 1 if ATA_DFLAG_D_SENSE is set (when
the requested version of page is "current" or "default").
Signed-off-by: NTom Yan <tom.ty89@gmail.com>
Signed-off-by: NTejun Heo <tj@kernel.org>

According to the HPT366 data sheet, PCI config space dword 0x40-0x43
bits 11:8 specify the primary drive cmd_high_time, however,
currently just 3 bits of the 4 are being used because the mask
is 0x700 and not 0x0f00.  Fix the mask, allowing for the 40MHz clock
to be detected.
Signed-off-by: NColin Ian King <colin.king@canonical.com>
Signed-off-by: NTejun Heo <tj@kernel.org>

The comment suggests we should be having an SPC-3 version descriptor
but the 0260h is the code for "SPC-2 (no version claimed)". Correct
it to 0300h so that it has the "SPC-3 (no version claimed)" descriptor.

Note that we are claiming SPC-3 version compatibility in the VERSION
field of the standard INQUIRY data. Therefore, I assume the typo was
on the code but not on the comment.
Signed-off-by: NTom Yan <tom.ty89@gmail.com>
Signed-off-by: NTejun Heo <tj@kernel.org>

Avoid performance bottleneck when being SCSI pass-through'd to
virtual machines with other OSes (e.g. Windows) via virtio-scsi
and scsi-block in qemu.

Ref.: https://github.com/YanVugenfirer/kvm-guest-drivers-windows/issues/63Signed-off-by: NTom Yan <tom.ty89@gmail.com>
Signed-off-by: NTejun Heo <tj@kernel.org>

Without this fix, the DRA bit of the caching mode page would not
be updated when the read look-ahead feature is toggled (e.g. with
`smartctl --set`), but will only be until, for example, the write
cache feature is touched.
Signed-off-by: NTom Yan <tom.ty89@gmail.com>
Signed-off-by: NTejun Heo <tj@kernel.org>

Commit 856c4663 ("libata: support device-managed ZAC devices")
had the line that "bumps" the VERSION field in standard INQUIRY data
removed. Add it back and claim SPC-5 version compatibility, which
matches with the current version descriptor "SPC-5 (no version claimed)"
that is used for ZAC devices.
Signed-off-by: NTom Yan <tom.ty89@gmail.com>
Signed-off-by: NTejun Heo <tj@kernel.org>

It's Command Descriptor Block. Also capitalized it.
Signed-off-by: NTom Yan <tom.ty89@gmail.com>
Signed-off-by: NTejun Heo <tj@kernel.org>

It does not make sense and is confusing to respond with "Invalid
field in CDB" while we have no support at all implemented for
FORMAT UNIT. It is decent to let it go to the default, which
will respond with "Invalid command operation code" instead.
Signed-off-by: NTom Yan <tom.ty89@gmail.com>
Signed-off-by: NTejun Heo <tj@kernel.org>

Note that `&acdev->host->lock' and `qc->ap->lock' denote the same lock, and it's
particularly confusing to spin_lock on the former but spin_unlock on the latter.
Signed-off-by: NIago Abal <mail@iagoabal.eu>
Signed-off-by: NTejun Heo <tj@kernel.org>

The sysfs file for the libata error handling has multiple issues
in the way it prints time stamps:

 * it prints a 9-digit nanosecond value using a %06lu format string,
   which drops some leading zeroes
 * it converts a 64-bit jiffes value to a timespec using
   jiffies_to_timespec(), which takes a 'long' argument, so the
   result is wrong after a jiffies overflow (49 days).
 * we try to avoid using timespec because that generally overflows
   in 2038, although this particular usage is ok.

This replaces the jiffies_to_timespec call with an open-coded
implementation that gets it right.
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Signed-off-by: NTejun Heo <tj@kernel.org>

This patch adds support for Broadcom NSP SATA3 PHY in existing
Broadcom SATA PHY driver.
Signed-off-by: NYendapally Reddy Dhananjaya Reddy <yendapally.reddy@broadcom.com>
Acked-by: NFlorian Fainelli <f.fainelli@gmail.com>
Signed-off-by: NTejun Heo <tj@kernel.org>

Add SATA3 support for Broadcom NSP SoC
Signed-off-by: NYendapally Reddy Dhananjaya Reddy <yendapally.reddy@broadcom.com>
Acked-by: NFlorian Fainelli <f.fainelli@gmail.com>
Signed-off-by: NTejun Heo <tj@kernel.org>

Rename the existing Broadcom STB ahci driver to common
Broadcom SATA3 driver to share this across Broadcom SoCs.
Signed-off-by: NYendapally Reddy Dhananjaya Reddy <yendapally.reddy@broadcom.com>
Acked-by: NFlorian Fainelli <f.fainelli@gmail.com>
Signed-off-by: NTejun Heo <tj@kernel.org>

The IS_ENABLED() macro checks if a Kconfig symbol has been enabled either
built-in or as a module, use that macro instead of open coding the same.
Signed-off-by: NJavier Martinez Canillas <javier@osg.samsung.com>
Signed-off-by: NTejun Heo <tj@kernel.org>

Remove extraneous space on if statement and on the following line,
trivial fix, no functional change
Signed-off-by: NColin Ian King <colin.king@canonical.com>
Signed-off-by: NTejun Heo <tj@kernel.org>

gcc-4.4 and thereabouts has issues with initializers of anonymous
unions, and it generates the following warnings:

  drivers/pinctrl/intel/pinctrl-baytrail.c:413: error: unknown field 'simple_funcs' specified in initializer
  drivers/pinctrl/intel/pinctrl-baytrail.c:413: warning: missing braces around initializer
  drivers/pinctrl/intel/pinctrl-baytrail.c:413: warning: (near initialization for 'byt_score_groups[0].<anonymous>')
  drivers/pinctrl/intel/pinctrl-baytrail.c:415: error: unknown field 'simple_funcs' specified in initializer
  drivers/pinctrl/intel/pinctrl-baytrail.c:417: error: unknown field 'simple_funcs' specified in initializer
  ...

Work around this.
Acked-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Cc: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Cc: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

"apd" was intended here instead of "init".
Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: NJean Delvare <jdelvare@suse.de>

... with a wrapper around maybe_request_map() - no need for two
osdmap-specific functions.
Signed-off-by: NIlya Dryomov <idryomov@gmail.com>

For map check, we are going to need to send CEPH_MSG_MON_GET_VERSION
messages asynchronously and get a callback on completion.  Refactor MON
client to allow firing off generic requests asynchronously and add an
async variant of ceph_monc_get_version().  ceph_monc_do_statfs() is
switched over and remains sync.
Signed-off-by: NIlya Dryomov <idryomov@gmail.com>

This adds support and switches rbd to a new, more reliable version of
watch/notify protocol.  As with the OSD client update, this is mostly
about getting the right structures linked into the right places so that
reconnects are properly sent when needed.  watch/notify v2 also
requires sending regular pings to the OSDs - send_linger_ping().

A major change from the old watch/notify implementation is the
introduction of ceph_osd_linger_request - linger requests no longer
piggy back on ceph_osd_request.  ceph_osd_event has been merged into
ceph_osd_linger_request.

All the details are now hidden within libceph, the interface consists
of a simple pair of watch/unwatch functions and ceph_osdc_notify_ack().
ceph_osdc_watch() does return ceph_osd_linger_request, but only to keep
the lifetime management simple.

ceph_osdc_notify_ack() accepts an optional data payload, which is
relayed back to the notifier.

Portions of this patch are loosely based on work by Douglas Fuller
<dfuller@redhat.com> and Mike Christie <michaelc@cs.wisc.edu>.
Signed-off-by: NIlya Dryomov <idryomov@gmail.com>

Introduce __rbd_dev_header_unwatch_sync(), which doesn't flush notify
callbacks.  This is for the new rados_watcherrcb_t, which would be
called from a notify callback.
Signed-off-by: NIlya Dryomov <idryomov@gmail.com>

finish_read(), its only user, uses it to get to hdr.data_len, which is
what ->r_result is set to on success.  This gains us the ability to
safely call callbacks from contexts other than reply, e.g. map check.
Signed-off-by: NIlya Dryomov <idryomov@gmail.com>

The crux of this is getting rid of ceph_osdc_build_request(), so that
MOSDOp can be encoded not before but after calc_target() calculates the
actual target.  Encoding now happens within ceph_osdc_start_request().

Also nuked is the accompanying bunch of pointers into the encoded
buffer that was used to update fields on each send - instead, the
entire front is re-encoded.  If we want to support target->name_len !=
base->name_len in the future, there is no other way, because oid is
surrounded by other fields in the encoded buffer.

Encoding OSD ops and adding data items to the request message were
mixed together in osd_req_encode_op().  While we want to re-encode OSD
ops, we don't want to add duplicate data items to the message when
resending, so all call to ceph_osdc_msg_data_add() are factored out
into a new setup_request_data().
Signed-off-by: NIlya Dryomov <idryomov@gmail.com>

Switch to ceph_object_id and use ceph_oid_aprintf() instead of a bare
const char *.  This reduces noise in rbd_dev_header_name().
Signed-off-by: NIlya Dryomov <idryomov@gmail.com>

Currently ceph_object_id can hold object names of up to 100
(CEPH_MAX_OID_NAME_LEN) characters.  This is enough for all use cases,
expect one - long rbd image names:

- a format 1 header is named "<imgname>.rbd"
- an object that points to a format 2 header is named "rbd_id.<imgname>"

We operate on these potentially long-named objects during rbd map, and,
for format 1 images, during header refresh.  (A format 2 header name is
a small system-generated string.)

Lift this 100 character limit by making ceph_object_id be able to point
to an externally-allocated string.  Apart from being able to work with
almost arbitrarily-long named objects, this allows us to reduce the
size of ceph_object_id from >100 bytes to 64 bytes.
Signed-off-by: NIlya Dryomov <idryomov@gmail.com>

The size of ->r_request and ->r_reply messages depends on the size of
the object name (ceph_object_id), while the size of ceph_osd_request is
fixed.  Move message allocation into a separate function that would
have to be called after ceph_object_id and ceph_object_locator (which
is also going to become variable in size with RADOS namespaces) have
been filled in:

    req = ceph_osdc_alloc_request(...);
    <fill in req->r_base_oid>
    <fill in req->r_base_oloc>
    ceph_osdc_alloc_messages(req);
Signed-off-by: NIlya Dryomov <idryomov@gmail.com>

By the time we get to checking for_each_obj_request_safe(img_request)
terminating condition, all obj_requests may be complete and img_request
ref, that rbd_img_request_submit() takes away from its caller, may be
put.  Moving the next_obj_request cursor is then a use-after-free on
img_request.

It's totally benign, as the value that's read is never used, but
I think it's still worth fixing.

Cc: Alex Elder <elder@linaro.org>
Signed-off-by: NIlya Dryomov <idryomov@gmail.com>

Commit ff1e22e7 ("xen/events: Mask a moving irq") open-coded
irq_move_irq() but left out checking if the IRQ is disabled. This broke
resuming from suspend since it tries to move a (disabled) irq without
holding the IRQ's desc->lock. Fix it by adding in a check for disabled
IRQs.

The resulting stacktrace was:
kernel BUG at /build/linux-UbQGH5/linux-4.4.0/kernel/irq/migration.c:31!
invalid opcode: 0000 [#1] SMP
Modules linked in: xenfs xen_privcmd ...
CPU: 0 PID: 9 Comm: migration/0 Not tainted 4.4.0-22-generic #39-Ubuntu
Hardware name: Xen HVM domU, BIOS 4.6.1-xs125180 05/04/2016
task: ffff88003d75ee00 ti: ffff88003d7bc000 task.ti: ffff88003d7bc000
RIP: 0010:[<ffffffff810e26e2>]  [<ffffffff810e26e2>] irq_move_masked_irq+0xd2/0xe0
RSP: 0018:ffff88003d7bfc50  EFLAGS: 00010046
RAX: 0000000000000000 RBX: ffff88003d40ba00 RCX: 0000000000000001
RDX: 0000000000000001 RSI: 0000000000000100 RDI: ffff88003d40bad8
RBP: ffff88003d7bfc68 R08: 0000000000000000 R09: ffff88003d000000
R10: 0000000000000000 R11: 000000000000023c R12: ffff88003d40bad0
R13: ffffffff81f3a4a0 R14: 0000000000000010 R15: 00000000ffffffff
FS:  0000000000000000(0000) GS:ffff88003da00000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007fd4264de624 CR3: 0000000037922000 CR4: 00000000003406f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Stack:
 ffff88003d40ba38 0000000000000024 0000000000000000 ffff88003d7bfca0
 ffffffff814c8d92 00000010813ef89d 00000000805ea732 0000000000000009
 0000000000000024 ffff88003cc39b80 ffff88003d7bfce0 ffffffff814c8f66
Call Trace:
 [<ffffffff814c8d92>] eoi_pirq+0xb2/0xf0
 [<ffffffff814c8f66>] __startup_pirq+0xe6/0x150
 [<ffffffff814ca659>] xen_irq_resume+0x319/0x360
 [<ffffffff814c7e75>] xen_suspend+0xb5/0x180
 [<ffffffff81120155>] multi_cpu_stop+0xb5/0xe0
 [<ffffffff811200a0>] ? cpu_stop_queue_work+0x80/0x80
 [<ffffffff811203d0>] cpu_stopper_thread+0xb0/0x140
 [<ffffffff810a94e6>] ? finish_task_switch+0x76/0x220
 [<ffffffff810ca731>] ? __raw_callee_save___pv_queued_spin_unlock+0x11/0x20
 [<ffffffff810a3935>] smpboot_thread_fn+0x105/0x160
 [<ffffffff810a3830>] ? sort_range+0x30/0x30
 [<ffffffff810a0588>] kthread+0xd8/0xf0
 [<ffffffff810a04b0>] ? kthread_create_on_node+0x1e0/0x1e0
 [<ffffffff8182568f>] ret_from_fork+0x3f/0x70
 [<ffffffff810a04b0>] ? kthread_create_on_node+0x1e0/0x1e0
Signed-off-by: NRoss Lagerwall <ross.lagerwall@citrix.com>
Reviewed-by: NBoris Ostrovsky <boris.ostrovsky@oracle.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: NDavid Vrabel <david.vrabel@citrix.com>

The XEN UEFI code has become available on the ARM architecture
recently, but now causes a link-time warning:

ld: warning: drivers/xen/efi.o uses 2-byte wchar_t yet the output is to use 4-byte wchar_t; use of wchar_t values across objects may fail

This seems harmless, because the efi code only uses 2-byte
characters when interacting with EFI, so we don't pass on those
strings to elsewhere in the system, and we just need to
silence the warning.

It is not clear to me whether we actually need to build the file
with the -fshort-wchar flag, but if we do, then we should also
pass --no-wchar-size-warning to the linker, to avoid the warning.
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Reviewed-by: NStefano Stabellini <sstabellini@kernel.org>
Fixes: 37060935dc04 ("ARM64: XEN: Add a function to initialize Xen specific UEFI runtime services")

IOCTL_GNTDEV_GRANT_COPY batches copy operations to reduce the number
of hypercalls.  The stack is used to avoid a memory allocation in a
hot path. However, a batch size of 24 requires more than 1024 bytes of
stack which in some configurations causes a compiler warning.

    xen/gntdev.c: In function ‘gntdev_ioctl_grant_copy’:
    xen/gntdev.c:949:1: warning: the frame size of 1248 bytes is
    larger than 1024 bytes [-Wframe-larger-than=]

This is a harmless warning as there is still plenty of stack spare,
but people keep trying to "fix" it.  Reduce the batch size to 16 to
reduce stack usage to less than 1024 bytes.  This should have minimal
impact on performance.
Signed-off-by: NDavid Vrabel <david.vrabel@citrix.com>

amdgpu_mn_get which is called during ioct path relies on mmap_sem for
write.  If the waiting task gets killed by the oom killer it would block
oom_reaper from asynchronous address space reclaim and reduce the
chances of timely OOM resolving.  Wait for the lock in the killable mode
and return with EINTR if the task got killed while waiting.

[arnd@arndb.de: use ERR_PTR() to return from amdgpu_mn_get]
Signed-off-by: NMichal Hocko <mhocko@suse.com>
Acked-by: NVlastimil Babka <vbabka@suse.cz>
Reviewed-by: NChristian König <christian.koenig@amd.com>
Cc: David Airlie <airlied@linux.ie>
Cc: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

radeon_mn_get which is called during ioct path relies on mmap_sem for
write.  If the waiting task gets killed by the oom killer it would block
oom_reaper from asynchronous address space reclaim and reduce the
chances of timely OOM resolving.  Wait for the lock in the killable mode
and return with EINTR if the task got killed while waiting.
Signed-off-by: NMichal Hocko <mhocko@suse.com>
Acked-by: NVlastimil Babka <vbabka@suse.cz>
Reviewed-by: NChristian König <christian.koenig@amd.com>
Cc: Alex Deucher <alexander.deucher@amd.com>
Cc: David Airlie <airlied@linux.ie>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

i915_gem_mmap_ioctl relies on mmap_sem for write.  If the waiting task
gets killed by the oom killer it would block oom_reaper from
asynchronous address space reclaim and reduce the chances of timely OOM
resolving.  Wait for the lock in the killable mode and return with EINTR
if the task got killed while waiting.
Signed-off-by: NMichal Hocko <mhocko@suse.com>
Acked-by: NVlastimil Babka <vbabka@suse.cz>
Cc: Daniel Vetter <daniel.vetter@intel.com>
Cc: David Airlie <airlied@linux.ie>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Use kmemdup when some other buffer is immediately copied into allocated
region.  It replaces call to allocation followed by memcpy, by a single
call to kmemdup.

[akpm@linux-foundation.org: remove unneeded cast to void*]
Link: http://lkml.kernel.org/r/1463665743-16269-1-git-send-email-falakreyaz@gmail.comSigned-off-by: NMuhammad Falak R Wani <falakreyaz@gmail.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

First version of this patch has already been posted to LKML by Ben
Hutchings ~6 months ago, but no further action were performed.

Ben's original message:

: rtsx_usb_ms creates a task that mostly sleeps, but tasks in
: uninterruptible sleep still contribute to the load average (for
: bug-compatibility with Unix).  A load average of ~1 on a system that
: should be idle is somewhat alarming.
:
: Change the sleep to be interruptible, but still ignore signals.

References: https://bugs.debian.org/765717
Link: http://lkml.kernel.org/r/b49f95ae83057efa5d96f532803cba47@natalenko.nameSigned-off-by: NOleksandr Natalenko <oleksandr@natalenko.name>
Cc: Oleg Nesterov <oleg@redhat.com>
Cc: Ben Hutchings <ben@decadent.org.uk>
Cc: Lee Jones <lee.jones@linaro.org>
Cc: Wolfram Sang <wsa@the-dreams.de>
Cc: Roger Tseng <rogerable@realtek.com>
Cc: Greg KH <greg@kroah.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

The CMD19/CMD14 bus width test has been found to be unreliable in
some cases.  It is not essential, so simply remove it.
Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com>
Cc: stable@vger.kernel.org
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

The CMD19/CMD14 bus width test has been found to be unreliable in
some cases.  It is not essential, so simply remove it.
Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com>
Cc: stable@vger.kernel.org
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>