We have been getting a warning about non ANSI function.
warning: non-ANSI function declaration of function 'FPT_SccbMgrTableInitAll'
Signed-off-by: Sudip Mukherjee <sudip@vectorindia.org>
Acked-by: Khalid Aziz <khalid@gonehiking.org>
Signed-off-by: James Bottomley <JBottomley@Odin.com>
Add an IOA Inquiry command for Page 0xC4 during IOA initialization to
collect cache capabilities, particularly to check if Sync IOA Write
Cache is supported.
Inquiry will happen right after Cap Inquiry on page 0xD0; and will
execute only if the "Supported Pages" field in Inquiry Page 0x0 shows
support for Page 0xC4. Otherwise, assume Sync IOA Write Cache is
not supported.
Signed-off-by: Gabriel Krisman Bertazi <krisman@linux.vnet.ibm.com>
Acked-by: Brian King <brking@linux.vnet.ibm.com>
Reviewed-by: Wen Xiong <wenxiong@linux.vnet.ibm.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
According to the IPR specification, Inhibit Underlength Checking bit
must be disabled when issuing commands to vsets. Enabling it in this
case might cause SCSI commands to fail with an Illegal Request, so make
sure we keep this bit cleared when resource is a vset.
Signed-off-by: Gabriel Krisman Bertazi <krisman@linux.vnet.ibm.com>
Reviewed-by: Manoj Kumar <manoj@linux.vnet.ibm.com>
Acked-by: Brian King <brking@linux.vnet.ibm.com>
Reviewed-by: Wen Xiong <wenxiong@linux.vnet.ibm.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Add a holding pattern prior to collecting dump data, to wait for the IOA
indication that the Mailbox register is stable and won't change without
an explicit reset. This ensures we'll be collecting meaningful dump
data, even when dumping right after an adapter reset.
In the event of a timeout, we still force the dump, since a partial dump
still might be useful.
Signed-off-by: Gabriel Krisman Bertazi <krisman@linux.vnet.ibm.com>
Acked-by: Brian King <brking@linux.vnet.ibm.com>
Reviewed-by: Wen Xiong <wenxiong@linux.vnet.ibm.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
SRB status can have additional information. Mask these out before processing
SRB status.
This patch was sent as part of a collection of patches more than a year ago.
While the rest of the patches in the set were comitted, this patch was not.
I woulod like to thank Olaf for noticing that this patch was not committed
upstream.
Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
Reviewed-by: Long Li <longli@microsoft.com>
Signed-off-by: James Bottomley <JBottomley@Odin.com>
Storvsc driver needs to ensure there are no 'holes' in the presented
sg list (all segments in the middle of the list need to be of PAGE_SIZE).
When a hole is detected storvsc driver creates a 'bounce sgl' without
holes and copies data over with copy_{to,from}_bounce_buffer() functions.
Setting virt_boundary_mask to PAGE_SIZE - 1 guarantees we'll never see
such holes so we can significantly simplify the driver. This is also
supposed to bring us some performance improvement for certain workloads
as we eliminate copying.
Reported-by: Radim Krčmář <rkrcmar@redhat.com>
Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
Reviewed-by: K. Y. Srinivasan <kys@microsoft.com>
Tested-by: Alex Ng <alexng@microsoft.com>
Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
Signed-off-by: James Bottomley <JBottomley@Odin.com>
Don't set the SRB_FLAGS_QUEUE_ACTION_ENABLE flag since we are not specifying
tags. Without this, the qlogic driver doesn't work properly with storvsc.
Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
Cc: stable@vger.kernel.org
Signed-off-by: James Bottomley <JBottomley@Odin.com>
While posting WRB the next_pointer of the current WRB should point
to itself and the previous WRB next_pointer should point to the
current WRB.
The next pointer value was retrieved during alloc_pdu and was updated
in wrb before ringing the doorbell. The fix retrieves the
next_pointer just before ringing the doorbell and updates in the WRB.
Signed-off-by: John Soni Jose <sony.john@avagotech.com>
Reviewed-by: Mike Christie <michaelc@cs.wisc.edu>
Signed-off-by: James Bottomley <JBottomley@Odin.com>
EXTRA_CFLAGS are intended to be used on the command line, not by Kbuild.
In case of cxgbi drivers, use of EXTRA_CFLAGS results in a compilation
failure:
drivers/scsi/cxgbi/cxgb4i/cxgb4i.c:24:21: fatal error: t4_regs.h: No such file or directory
when building like:
$ make drivers/scsi/cxgbi/ EXTRA_CFLAGS=-Wwhatever
Use ccflags-y instead of EXTRA_CFLAGS.
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Reviewed-by: Johannes Thumshirn <jthumshirn@suse.de>
Cc: James Bottomley <James.Bottomley@HansenPartnership.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
New revisions of UFS host controller supports the new UniPro
hardware controller (referred as QUniPro). This patch adds
the support to enable this new UniPro controller hardware.
This change also adds power optimization for bus scaling feature,
as well as support for HS-G3 power mode.
Reviewed-by: Subhash Jadavani <subhashj@codeaurora.org>
Reviewed-by: Gilad Broner <gbroner@codeaurora.org>
Signed-off-by: Yaniv Gardi <ygardi@codeaurora.org>
Reviewed-by: Hannes Reinecke <hare@suse.de>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
This change turns the UFS variant (SCSI_UFS_QCOM) into a UFS
a platform device.
In order to do so a few additional changes are required:
1. The ufshcd-pltfrm is no longer serves as a platform device.
Now it only serves as a group of platform APIs such as PM APIs
(runtime suspend/resume, system suspend/resume etc), parsers of
clocks, regulators and pm_levels from DT.
2. What used to be the old platform "probe" is now "only"
a pltfrm_init() routine, that does exactly the same, but only
being called by the new probe function of the UFS variant.
Reviewed-by: Rob Herring <robherring2@gmail.com>
Reviewed-by: Gilad Broner <gbroner@codeaurora.org>
Signed-off-by: Yaniv Gardi <ygardi@codeaurora.org>
Tested-by: Alim Akhtar <alim.akhtar@samsung.com>
Reviewed-by: Hannes Reinecke <hare@suse.de>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
This change fixes a compilation warning that happens if SCSI_UFS_QCOM is
compiled as a module. Also this patch fixes an error happens when
insmod the module: "ufs_qcom: module license 'unspecified' taints
kernel."
Reviewed-by: Akinobu Mita <akinobu.mita@gmail.com>
Reviewed-by: Subhash Jadavani <subhashj@codeaurora.org>
Reviewed-by: Gilad Broner <gbroner@codeaurora.org>
Signed-off-by: Yaniv Gardi <ygardi@codeaurora.org>
Reviewed-by: Hannes Reinecke <hare@suse.de>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Like some of the other Yoga models the Lenovo Yoga 900 does not have a
hw rfkill switch, and trying to read the hw rfkill switch through the
ideapad module causes it to always reported blocking breaking wifi.
This commit adds the Lenovo Yoga 900 to the no_hw_rfkill dmi list, fixing
the wifi breakage.
BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1275490
Cc: stable@vger.kernel.org
Reported-and-tested-by: Kevin Fenzi <kevin@scrye.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Darren Hart <dvhart@linux.intel.com>
This changes the entry to the whitelist of machines that do not have
a physical rfkill switch. Unfortunately, the Yoga 3 generation seems
to use upper-case letters for the YOGA 3 Pro-1370, while it uses normal
capitalization for its Yoga 3 1170 and 1470 siblings.
In order to catch all variants of the Yoga 3, I'm changing both
the entry for the 1470 (using "Yoga" as the name) and the entry for
the Pro 1370 (using all-caps "YOGA") to not match the exact model number
but only the generation. This way, the 1170 and 1470 models share one
entry, but if the firmware changes from one format to the other, it will
still work.
The second entry for Yoga 2 Pro that was recently added for some
reason ended up not being added in alphanumeric order, and I'm
moving the Yoga 3 1470 entry down while making the change, so they
are sorted more logically.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Darren Hart <dvhart@linux.intel.com>
The ideapad-laptop handles most special keys on various Lenovo Laptops
including the Yoga line. Unfortunately, the Yoga 3 11/13/14 models have
one important exception, which is the Fn-ESC combination.
On other Lenovo Laptops, this is FnLock, which switches the function keys
between the primary (Mute, Vol down, Vol up, ...) and the secondary (F1,
F2, F3, ...) behavior. On the new machines, FnLock is only available
through BIOS setup (possibly through a yet-to-be-implemented feature
in this driver) but not through Fn-ESC, but instead the ESC key itself
switched between ESC and a "Paper Display" app for Windows.
Unfortunately, that means that you can never have both ESC *and* the
function keys working at the same time without needing to press Fn on
one of them.
As pointed out in the official Lenovo Forum by dozens of users, this
makes the machine rather useless for any serious work [1].
I have now studied the ACPI DSDT one more time and found the event
that is generated for the ESC key. Unlike all other key events on this
machine, it is actually a WMI, while the other ones are read from the
embedded controller.
I am now installing a WMI notifier that uses the event number from the
WMI subsystem as the scancode. The only event number generated here is
'128', and that fits in nicely with the two existing ranges of scancodes
used by the EC: 0-15 for the 16-bit VPCCMD_R_VPC register, 16-17 for
the VPCCMD_R_NOVO register and 64-67 for VPCCMD_R_SPECIAL_BUTTONS.
The only sane way to handle this button (in absence of the Windows Paper
Display driver) seems to be to have it emit KEY_ESC, so that is what
I use as the default. Should any user ever want to overwrite the default,
they can install their own keymap.
To ensure that we can still build the driver without adding a CONFIG_WMI
dependency, all new code is enclosed in #ifdef.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
[1] https://forums.lenovo.com/t5/Lenovo-Yoga-Series-Notebooks/YOGA-3-14-How-to-reclaim-my-Esc-key-and-permanently-disable/td-p/2070816
Signed-off-by: Darren Hart <dvhart@linux.intel.com>
WARNING: vmlinux.o(.text+0x1056606): Section mismatch in reference from the function parkbd_attach() to the function .init.text:parkbd_allocate_serio()
The function parkbd_attach() references
the function __init parkbd_allocate_serio().
This is often because parkbd_attach lacks a __init
annotation or the annotation of parkbd_allocate_serio is wrong.
Commit 33ca8ab97c ("Input: parkbd - use parallel port device
model") dropped the __init attribute from the sole caller of
parkbd_allocate_serio(), but forgot to remove it from
parkbd_allocate_serio() itself.
Fixes: 33ca8ab97c ("Input: parkbd - use parallel port device model")
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Acked-by: Sudip Mukherjee <sudipm.mukherjee@gmail.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
This patch fixes a 'general protection fault' issue by
moving the attribute to where it was likely meant.
Signed-off-by: Tomas Henzl <thenzl@redhat.com>
Signed-off-by: Don Brace <don.brace@pmcs.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
path_info_show() seems to be broken in multiple ways.
First, there's
817 return snprintf(buf, output_len+1, "%s%s%s%s%s%s%s%s",
818 path[0], path[1], path[2], path[3],
819 path[4], path[5], path[6], path[7]);
so hopefully output_len contains the combined length of the eight
strings. Otherwise, snprintf will stop copying to the output
buffer, but still end up reporting that combined length - which
in turn would result in user-space getting a bunch of useless nul
bytes (thankfully the upper sysfs layer seems to clear the output
buffer before passing it to the various ->show routines). But we have
767 output_len = snprintf(path[i],
768 PATH_STRING_LEN, "[%d:%d:%d:%d] %20.20s ",
769 h->scsi_host->host_no,
770 hdev->bus, hdev->target, hdev->lun,
771 scsi_device_type(hdev->devtype));
so output_len at best contains the length of the last string printed.
Inside the loop, we then otherwise add to output_len. By magic,
we still have PATH_STRING_LEN available every time... This
wouldn't really be a problem if the bean-counting has been done
properly and each line actually does fit in 50 bytes, and maybe
it does, but I don't immediately see why. Suppose we end up
taking this branch:
802 output_len += snprintf(path[i] + output_len,
803 PATH_STRING_LEN,
804 "BOX: %hhu BAY: %hhu %s\n",
805 box, bay, active);
An optimistic estimate says this uses strlen("BOX: 1 BAY: 2
Active\n") which is 21. Now add the 20 bytes guaranteed by the
%20.20s and then some for the rest of that format string, and
we're easily over 50 bytes. I don't think we can get over 100
bytes even being pessimistic, so this just means we'll scribble
into the next path[i+1] and maybe get that overwritten later,
leading to some garbled output (in fact, since we'd overwrite the
previous string's 0-terminator, we could end up with one very
long string and then print various suffixes of that, leading to
much more than 400 bytes of output). Except of course when we're
filling path[7], where overrunning it means writing random stuff
to the kernel stack, which is usually a lot of fun.
We can fix all of that and get rid of the 400 byte stack buffer by
simply writing directly to the given output buffer, which the upper
layer guarantees is at least PAGE_SIZE. s[c]nprintf doesn't care where
it is writing to, so this doesn't make the spin lock hold time any
longer. Using scnprintf ensures that output_len always represents the
number of bytes actually written to the buffer, so we'll report the
proper amount to the upper layer.
Reviewed-by: Hannes Reinecke <hare@suse.de>
Reviewed-by: Tomas Henzl <thenzl@redhat.com>
Reviewed-by: Matthew R. Ochs <mrochs@linux.vnet.ibm.com>
Signed-off-by: Rasmus Villemoes <linux@rasmusvillemoes.dk>
Signed-off-by: Don Brace <don.brace@pmcs.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
When external target arrays are present, disable the firmware's
normal behavior of returning a cached copy of the report lun data,
and force it to collect new data each time we request a report luns.
This is necessary for external arrays, since there may be no
reliable signal from the external array to the smart array when
lun configuration changes, and thus when driver requests
report luns, it may be stale data.
Use diag options to turn off RPL data caching.
Reviewed-by: Scott Teel <scott.teel@pmcs.com>
Reviewed-by: Justin Lindley <justin.lindley@pmcs.com>
Reviewed-by: Kevin Barnett <kevin.barnett@pmcs.com>
Reviewed-by: Hannes Reinecke <hare@suse.de>
Reviewed-by: Matthew R. Ochs <mrochs@linux.vnet.ibm.com>
Signed-off-by: Don Brace <don.brace@pmcs.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
There are problems with getting configuration change notification
in pass-through RAID environments. So, activate flag
h->discovery_polling when one of these devices is detected in
update_scsi_devices.
After discovery_polling is set, execute a report luns from
rescan_controller_worker (every 30 seconds).
If the data from report_luns is different than last
time (binary compare), execute a full rescan via update_scsi_devices.
Reviewed-by: Scott Teel <scott.teel@pmcs.com>
Reviewed-by: Justin Lindley <justin.lindley@pmcs.com>
Reviewed-by: Kevin Barnett <kevin.barnett@pmcs.com>
Reviewed-by: Hannes Reinecke <hare@suse.de>
Reviewed-by: Matthew R. Ochs <mrochs@linux.vnet.ibm.com>
Signed-off-by: Don Brace <don.brace@pmcs.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
We don't need to create fake enclosure devices at Lun0
in external target array configurations anymore.
This was done to support Pre-SCSI rev 5 controllers
that didn't suppoprt report luns commands, so the
SCSI layer had to scan targets. If there was no
LUN at LUN 0, then the target scan would stop, and
move to the next target. Lun0 enclosure device
was added to prevent sparsely-numbered LUNs from
being missed.
Reviewed-by: Scott Teel <scott.teel@pmcs.com>
Reviewed-by: Justin Lindley <justin.lindley@pmcs.com>
Reviewed-by: Kevin Barnett <kevin.barnett@pmcs.com>
Reviewed-by: Matthew R. Ochs <mrochs@linux.vnet.ibm.com>
Reviewed-by: Hannes Reinecke <hare@suse.de>
Reviewed-by: Tomas Henzl <thenzl@redhat.com>
Signed-off-by: Don Brace <don.brace@pmcs.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
External array LUNs must use target and lun numbers assigned by the
external array. So the driver must treat these differently from
local LUNs when assigning lun/target.
LUN's 'model' field has been used to detect Lun types that need
special treatment, but the desire is to eliminate the need to reference
specific array models, and support any external array.
Pass-through RAID (PTRAID) luns are not luns of the local controller,
so they are not reported in LUN count of command 'ID controller'.
However, they ARE reported in "Report logical Luns" command.
Local luns are listed first, then PTRAID LUNs.
The number of luns from "Report LUNs" in excess of those reported by
'ID controller' are therefore the PTRAID LUNS.
We can now remove function is_ext_target, and the 'white list'
array of supported model names.
Reviewed-by: Scott Teel <scott.teel@pmcs.com>
Reviewed-by: Justin Lindley <justin.lindley@pmcs.com>
Reviewed-by: Kevin Barnett <kevin.barnett@pmcs.com>
Signed-off-by: Don Brace <don.brace@pmcs.com>
Reviewed-by: Matthew R. Ochs <mrochs@linux.vnet.ibm.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
