11 Jan, 2018
1 commit
-
In commit 87c8331fcf72 ("[SCSI] libsas: prevent domain rediscovery
competing with ata error handling") introduced disco mutex to prevent
rediscovery competing with ata error handling and put the whole
revalidation in the mutex. But the rphy add/remove needs to wait for the
error handling which also grabs the disco mutex. This may leads to dead
lock.So the probe and destruct event were introduce to do the rphy
add/remove asynchronously and out of the lock.The asynchronously processed workers makes the whole discovery process
not atomic, the other events may interrupt the process. For example,
if a loss of signal event inserted before the probe event, the
sas_deform_port() is called and the port will be deleted.And sas_port_delete() may run before the destruct event, but the
port-x:x is the top parent of end device or expander. This leads to
a kernel WARNING such as:[ 82.042979] sysfs group 'power' not found for kobject 'phy-1:0:22'
[ 82.042983] ------------[ cut here ]------------
[ 82.042986] WARNING: CPU: 54 PID: 1714 at fs/sysfs/group.c:237
sysfs_remove_group+0x94/0xa0
[ 82.043059] Call trace:
[ 82.043082] [] sysfs_remove_group+0x94/0xa0
[ 82.043085] [] dpm_sysfs_remove+0x60/0x70
[ 82.043086] [] device_del+0x138/0x308
[ 82.043089] [] sas_phy_delete+0x38/0x60
[ 82.043091] [] do_sas_phy_delete+0x6c/0x80
[ 82.043093] [] device_for_each_child+0x58/0xa0
[ 82.043095] [] sas_remove_children+0x40/0x50
[ 82.043100] [] sas_destruct_devices+0x64/0xa0
[ 82.043102] [] process_one_work+0x1fc/0x4b0
[ 82.043104] [] worker_thread+0x50/0x490
[ 82.043105] [] kthread+0xfc/0x128
[ 82.043107] [] ret_from_fork+0x10/0x50Make probe and destruct a direct call in the disco and revalidate function,
but put them outside the lock. The whole discovery or revalidate won't
be interrupted by other events. And the DISCE_PROBE and DISCE_DESTRUCT
event are deleted as a result of the direct call.Introduce a new list to destruct the sas_port and put the port delete after
the destruct. This makes sure the right order of destroying the sysfs
kobject and fix the warning above.In sas_ex_revalidate_domain() have a loop to find all broadcasted
device, and sometimes we have a chance to find the same expander twice.
Because the sas_port will be deleted at the end of the whole revalidate
process, sas_port with the same name cannot be added before this.
Otherwise the sysfs will complain of creating duplicate filename. Since
the LLDD will send broadcast for every device change, we can only
process one expander's revalidation.[mkp: kbuild test robot warning]
Signed-off-by: Jason Yan
CC: John Garry
CC: Johannes Thumshirn
CC: Ewan Milne
CC: Christoph Hellwig
CC: Tomas Henzl
CC: Dan Williams
Reviewed-by: Hannes Reinecke
Signed-off-by: Martin K. Petersen
02 Nov, 2017
1 commit
-
Many source files in the tree are missing licensing information, which
makes it harder for compliance tools to determine the correct license.By default all files without license information are under the default
license of the kernel, which is GPL version 2.Update the files which contain no license information with the 'GPL-2.0'
SPDX license identifier. The SPDX identifier is a legally binding
shorthand, which can be used instead of the full boiler plate text.This patch is based on work done by Thomas Gleixner and Kate Stewart and
Philippe Ombredanne.How this work was done:
Patches were generated and checked against linux-4.14-rc6 for a subset of
the use cases:
- file had no licensing information it it.
- file was a */uapi/* one with no licensing information in it,
- file was a */uapi/* one with existing licensing information,Further patches will be generated in subsequent months to fix up cases
where non-standard license headers were used, and references to license
had to be inferred by heuristics based on keywords.The analysis to determine which SPDX License Identifier to be applied to
a file was done in a spreadsheet of side by side results from of the
output of two independent scanners (ScanCode & Windriver) producing SPDX
tag:value files created by Philippe Ombredanne. Philippe prepared the
base worksheet, and did an initial spot review of a few 1000 files.The 4.13 kernel was the starting point of the analysis with 60,537 files
assessed. Kate Stewart did a file by file comparison of the scanner
results in the spreadsheet to determine which SPDX license identifier(s)
to be applied to the file. She confirmed any determination that was not
immediately clear with lawyers working with the Linux Foundation.Criteria used to select files for SPDX license identifier tagging was:
- Files considered eligible had to be source code files.
- Make and config files were included as candidates if they contained >5
lines of source
- File already had some variant of a license header in it (even if
Reviewed-by: Philippe Ombredanne
Reviewed-by: Thomas Gleixner
Signed-off-by: Greg Kroah-Hartman
30 Aug, 2017
1 commit
-
Simplify the SMP passthrough code by switching it to the generic bsg-lib
helpers that abstract away the details of the request code, and gets
drivers out of seeing struct scsi_request.For the libsas host SMP code there is a small behavior difference in
that we now always clear the residual len for successful commands,
similar to the three other SMP handler implementations. Given that
there is no partial command handling in the host SMP handler this should
not matter in practice.[mkp: typos and checkpatch fixes]
Signed-off-by: Christoph Hellwig
Reviewed-by: Johannes Thumshirn
Signed-off-by: Martin K. Petersen
19 Aug, 2016
2 commits
-
As there are no more users of is_sas_attached() left, remove it.
Signed-off-by: Johannes Thumshirn
Reviewed-by: James E.J. Bottomley
Signed-off-by: Martin K. Petersen -
Provide a stub implementation for scsi_is_sas_rphy for kernel
configurations which do not have CONFIG_SCSI_SAS_ATTRS defined.Reported-by: kbuild test robot
Suggested-by: James Bottomley
Reviewed-by: James E.J. Bottomley
Signed-off-by: Johannes Thumshirn
Signed-off-by: Martin K. Petersen
19 Dec, 2015
2 commits
-
For a device known to be SAS connected, this will return the endpoint
address. This is useful for getting the SAS address of SATA devices.Reviewed-by: Hannes Reinecke
Signed-off-by: James Bottomley -
Adds a function designed to be callable any time (regardless of
whether the transport attributes are configured or not) which returns
true if the device is attached over a SAS transport. The design of
this function is that transport specific functions can be embedded
within aif (is_sas_attached(sdev)) {
...
}which would be compiled out (and thus eliminate the symbols) if SAS is
not configured.Reviewed-by: Hannes Reinecke
Signed-off-by: James Bottomley
10 May, 2013
1 commit
-
These enums have been separate since the dawn of SAS, mainly because the
latter is a procotol only enum and the former includes additional state
for libsas. The dichotomy causes endless confusion about which one you
should use where and leads to pointless warnings like this:drivers/scsi/mvsas/mv_sas.c: In function 'mvs_update_phyinfo':
drivers/scsi/mvsas/mv_sas.c:1162:34: warning: comparison between 'enum sas_device_type' and 'enum sas_dev_type' [-Wenum-compare]Fix by eliminating one of them. The one kept is effectively the sas.h
one, but call it sas_device_type and make sure the enums are all
properly namespaced with the SAS_ prefix.Signed-off-by: James Bottomley
01 Dec, 2012
1 commit
-
[jejb: split this core change into a separate patch]
Signed-off-by: Sreekanth Reddy
Reviewed-by: Nagalakshmi Nandigama
Signed-off-by: James Bottomley
01 Mar, 2012
1 commit
-
In the direct-attached case this routine returns the phy on which this
device was first discovered. Which is broken if we want to support
wide-targets, as this phy reference can become stale even though the
port is still active.In the expander-attached case this routine tries to lookup the phy by
scanning the attached sas addresses of the parent expander, and BUG_ONs
if it can't find it. However since eh and the libsas workqueue run
independently we can still be attempting device recovery via eh after
libsas has recorded the device as detached. This is even easier to hit
now that eh is blocked while device domain rediscovery takes place, and
that libata is fed more timed out commands increasing the chances that
it will try to recover the ata device.Arrange for dev->phy to always point to a last known good phy, it may be
stale after the port is torn down, but it will catch up for wide port
reconfigurations, and never be NULL.Signed-off-by: Dan Williams
Signed-off-by: James Bottomley
20 Feb, 2012
2 commits
-
Extend the sas transport class to allow transport users to attach extra
data to a sas_phy (->hostdata). Use this area in libsas to move resets
to workq context in preparation for scheduling ata device resets through
libata-eh.Signed-off-by: Dan Williams
Signed-off-by: James Bottomley -
libata error handling provides for a timeout for link recovery. libsas
must not rescan for previously known devices in this interval otherwise
it may remove a device that is simply waiting for its link to recover.
Let libata-eh make the determination of when the link is stable and
prevent libsas (host workqueue) from taking action while this
determination is pending.Using a mutex (ha->disco_mutex) to flush and disable revalidation while
eh is running requires any discovery action that may block on eh be
moved to its own context outside the lock. Probing ATA devices
explicitly waits on ata-eh and the cache-flush-io issued during device
removal may also pend awaiting eh completion. Essentially any rphy
add/remove activity needs to run outside the lock.This adds two new cleanup states for sas_unregister_domain_devices()
'allocated-but-not-probed', and 'flagged-for-destruction'. In the
'allocated-but-not-probed' state dev->rphy points to a rphy that is
known to have not been through a sas_rphy_add() event. At domain
teardown check if this device is still pending probe and cleanup
accordingly. Similarly if a device has already been queued for removal
then sas_unregister_domain_devices has nothing to do.Signed-off-by: Dan Williams
Signed-off-by: James Bottomley
09 Feb, 2010
1 commit
-
The mpt2sas driver wants to use transport layer retries (TLR) so the
simplest thing to do seems to be to add the enabling flags and checks
to the SAS transport class, since they're a SAS specific protocol
feature.Signed-off-by: James Bottomley
20 Apr, 2008
1 commit
-
It's big, but there doesn't seem to be a way to split it up smaller...
Signed-off-by: Tony Jones
Signed-off-by: Kay Sievers
Cc: Roland Dreier
Cc: Sean Hefty
Cc: Hal Rosenstock
Cc: James Bottomley
Signed-off-by: Greg Kroah-Hartman
12 Jan, 2008
2 commits
-
This adds support for host side SMP processing, via a separate
SMP interpreter file.Signed-off-by: James Bottomley
-
sparse complains about the mixing of enums in libsas. Since the
underlying numeric values of both enums are the same, combine them
to get rid of the warning.Signed-off-by: Darrick J. Wong
Signed-off-by: James Bottomley
21 Jul, 2007
1 commit
-
There's currently no destructor for the bsg components. If you insert
and remove the module, you see the bsg devices building up and up. This
patch adds the destructor in the correct place in the transport class so
that the bsg and request queue are removed just before the device
destruction.Acked-by: FUJITA Tomonori
Signed-off-by: James Bottomley
19 Jul, 2007
2 commits
-
The sas transport class attaches one bsg device to every SAS object
(host, device, expander, etc). LLDs can define a function to handle
SMP requests via sas_function_template::smp_handler.Signed-off-by: FUJITA Tomonori
Signed-off-by: James Bottomley -
This one was noticed by Gilbert Wu of Adaptec:
The libata core actually does the DMA mapping for you, so there has to
be an exception in the device drivers that *don't* do dma mapping for
ATA commands. However, since we've already done this, libsas must now
dma map any ATA commands that it wishes to issue ... and yes, this is a
horrible mess.Additionally, the test in aic94xx for ATA protocols isn't quite right.
Signed-off-by: James Bottomley
28 Jan, 2007
1 commit
-
sas_rphy_delete does two things: it removes the sas_rphy from the transport
layer and frees the sas_rphy. This can be broken down into two functions,
sas_rphy_remove and sas_rphy_free; sas_rphy_remove is of interest to
sas_discover_root_expander because it calls functions that require
sas_rphy_add as a prerequisite and can fail (namely sas_discover_expander).
In that case, sas_discover_root_expander needs to be able to undo the effects
of sas_rphy_add yet leave the job of freeing the sas_rphy to the caller of
sas_discover_root_expander.This patch also removes some unnecessary code from sas_discover_end_dev
to eliminate an unnecessary cycle of sas_notify_lldd_gone/found for SAS
devices, thus eliminating a sas_rphy_remove call (and fixing a race condition
where a SCSI target scan can come in between the gone and found call).
It also moves the sas_rphy_free calls into sas_discover_domain and
sas_ex_discover_end_dev to complement the sas_rphy_allocation via
sas_get_port_device.This patch does not change the semantics of sas_rphy_delete.
Signed-off-by: Darrick J. Wong
Signed-off-by: James Bottomley
14 Jan, 2007
1 commit
-
This patch lets a user arbitrarily enable or disable a phy via sysfs.
Potential applications include shutting down a phy to replace one
lane of wide port, and (more importantly) providing a method for the
libata SATL to control the phy.Signed-off-by: Darrick J. Wong
Signed-off-by: James Bottomley
23 Nov, 2006
1 commit
-
This patch implements a REQ_DEVICE_RESET handler for the aic94xx
driver. Like the earlier REQ_TASK_ABORT patch, this patch defers the
device reset to the Scsi_Host's workqueue, which has the added benefit
of ensuring that the device reset does not happen at the same time
that the abort tmfs are being processed. After the phy reset, the
busted drive should go away and be re-detected later, which is indeed
what I've seen on both a x260 and a x206m.Signed-off-by: Darrick J. Wong
Signed-off-by: James Bottomley
08 Sep, 2006
2 commits
-
According to SPEC, the minimum_linkrate and maximum_linkrate should be
settable by the user. This patch introduces a callback that allows the
sas class to pass these settings on to the driver.Signed-off-by: James Bottomley
-
At the moment we have two separate linkspeed enumerations covering
roughly the same values. This patch consolidates on a single one enum
sas_linkspeed in scsi_transport_sas.h and uses it everywhere in the
aic94xx driver. Eventually I'll get around to removing the duplicated
fields in asd_sas_phy and sas_phy ...Signed-off-by: James Bottomley
28 Aug, 2006
1 commit
-
This flag denotes local attachment of the phy. There are two problems
with it:1) It's actually redundant ... you can get the same information simply
by seeing whether a host is the phys parent
2) we condition a lot of phy parameters on it on the false assumption
that we can only control local phys. I'm wiring up phy resets in the
aic94xx now, and it will be able to reset non-local phys as well.I fixed 2) by moving the local check into the reset and stats function
of the mptsas, since that seems to be the only HBA that can't
(currently) control non-local phys.Signed-off-by: James Bottomley
12 Jul, 2006
1 commit
-
This patch adds the ability to add a backlink to a particular port. The
idea is to represent properly ports on expanders that are used
specifically for linking to the parent device in the topology.Signed-off-by: James Bottomley
09 Jul, 2006
1 commit
-
Some SAS HBAs don't want to go to the trouble of tracking port numbers,
so they'd simply like to say "add this port and give it a number".
This is especially beneficial from the hotplug point of view, since
tracking ports and the available number space can be a real pain.The current implementation uses an incrementing number per expander to
add the port on. However, since there can never be more ports than
there are phys, a later implementation will try to be more intelligent
about this.Signed-off-by: James Bottomley
29 Jun, 2006
1 commit
-
this patch introduces a port object, separates out ports and phys,
with ports becoming the primary objects of the tree.Signed-off-by: James Bottomley
20 Mar, 2006
1 commit
-
This allows the removal of the contained flag and also does a bit of
class renaming (sas_rphy->sas_device).Signed-off-by: James Bottomley
15 Mar, 2006
1 commit
-
This patch makes expanders appear as labelled objects with properties in
the SAS tree.I've also modified the phy code to make expander phys appear labelled by
host number, expander number and phy index.So, for my current config, you see something like this in sysfs:
/sys/class/scsi_host/host1/device/phy-1:4/expander-1:0/phy-1-0:12/rphy-1:0-12/target1:0:1
And the expander properties are:
jejb@sparkweed> cd /sys/class/sas_expander/expander-1\:0/
jejb@sparkweed> for f in *; do echo -n $f ": "; cat $f; done
component_id : 29024
component_revision_id : 4
component_vendor_id : VITESSE
device : cat: device: Is a directory
level : 0
product_id : VSC7160 Eval Brd
product_rev : 4
uevent : cat: uevent: Permission denied
vendor_id : VITESSESigned-off-by: James Bottomley
06 Mar, 2006
1 commit
-
Begin introducing the concept of sas remote devices that have an rphy
embedded. The first one (this) is a simple end device. All that an
end device really does is have port mode page parameters contained.
The next and more complex piece will be expander remote devices.Signed-off-by: James Bottomley
03 Mar, 2006
1 commit
-
I don't think these exist in silicon yet, but the aic94xx driver has a
register setting for them.Signed-off-by: James Bottomley
28 Feb, 2006
1 commit
-
Signed-off-by: Christoph Hellwig
Signed-off-by: James Bottomley
29 Oct, 2005
3 commits
-
Signed-off-by: Christoph Hellwig
Signed-off-by: James Bottomley -
Add a flag to mark a PHY as attached to the HBA as opposed to beeing on
an expander. This is needed because various features are only supported
on those. This is a crude hack, the proper fix would be to use
different classes for host-attached vs expander phys. I'm looking into
that.Signed-off-by: Christoph Hellwig
Signed-off-by: James Bottomley -
For now supporting the ->get_linkerrors method is mandatory. I'll
probably be beaten to implement the .show_foo variables and different
types of attributes soon..Signed-off-by: Christoph Hellwig
Signed-off-by: James Bottomley
10 Sep, 2005
1 commit
-
The SAS transport class contains common code to deal with SAS HBAs, an
aproximated representation of SAS topologies in the driver model,
and various sysfs attributes to expose these topologies and managment
interfaces to userspace.In addition to the basic SCSI core objects this transport class introduces
two additional intermediate objects: The SAS PHY as represented by struct
sas_phy defines an "outgoing" PHY on a SAS HBA or Expander, and the SAS
remote PHY represented by struct sas_rphy defines an "incoming" PHY on a
SAS Expander or end device. Note that this is purely a software concept, the
underlying hardware for a PHY and a remote PHY is the exactly the same.There is no concept of a SAS port in this code, users can see what PHYs
form a wide port based on the port_identifier attribute, which is the same
for all PHYs in a port.This submission doesn't handle hot-plug addition or removal of SAS devices
and thus doesn't do scanning in a workqueue yet, that will be added in
phase2 after this submission. In a third phase I will add additional
managment infrastructure.I think this submission is ready for 2.6.14, but additional comments are
of course very welcome.I'd like to thanks James Smart a lot for his very useful input on the
design.Signed-off-by: Christoph Hellwig
Signed-off-by: James Bottomley