The test checks for the following case:
Router State Report Received New Router State Actions
INCLUDE (A) IS_IN (B) INCLUDE (A+B) (B)=MALI
Signed-off-by: Nikolay Aleksandrov <nikolay@nvidia.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
The test checks for the following case:
Router State Report Received New Router State Actions
INCLUDE (A) ALLOW (B) INCLUDE (A+B) (B)=MALI
Signed-off-by: Nikolay Aleksandrov <nikolay@nvidia.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Add the initial setup for MLDv2 tests with the first test of a simple
is_include report. For MLDv2 we need to setup the bridge properly and we
also send the full precooked packets instead of relying on mausezahn to
fill in some parts. For verification we use the generic S,G state checking
functions from lib.sh.
Signed-off-by: Nikolay Aleksandrov <nikolay@nvidia.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Factor out S,G entry state checking functions for existence, forwarding,
blocking and timer to lib.sh so they can be later used by MLDv2 tests.
Add brmcast_ suffix to their name to make the relation to the bridge
explicit.
Signed-off-by: Nikolay Aleksandrov <nikolay@nvidia.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
In order to test an IPv6 multicast packet we need to pass different tc
and mausezahn protocols only, so add a simple check for the destination
address which decides if we should generate an IPv4 or IPv6 mcast
packet.
Signed-off-by: Nikolay Aleksandrov <nikolay@nvidia.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Factor out mcast_packet_test into lib.sh so it can be later extended and
reused by MLDv2 tests.
Signed-off-by: Nikolay Aleksandrov <nikolay@nvidia.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
MT7530/7531 has a global RX packet length register, which can be used
to set MTU.
Supported packet length values are 1522 (1518 if untagged), 1536,
1552, and multiple of 1024 (from 2048 to 15360).
Signed-off-by: DENG Qingfang <dqfext@gmail.com>
Link: https://lore.kernel.org/r/20201103050618.11419-1-dqfext@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Alex Elder says:
====================
net: ipa: tell GSI the IPA version
The GSI code that supports IPA avoids having knowledge about the
IPA layer it serves. One result of this is that Boolean flags are
used during GSI initialization to convey that certain hardware
version-dependent special behaviors should be used.
A given version of IPA hardware uses a fixed/well-defined version
of GSI, so the IPA version really implies the GSI version.
If given only the IPA version, the GSI code supporting IPA can
use it to implement certain special behaviors required for IPA
*or* GSI. This avoids the need to pass and maintain numerous
Boolean flags.
====================
Link: https://lore.kernel.org/r/20201102175400.6282-1-elder@linaro.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
We enable a channel doorbell engine only for IPA v3.5.1, and that is
now handled directly by gsi_channel_program().
When initially setting up a channel, we want that doorbell engine
enabled, and we can request that independent of the IPA version.
Doing that makes the "legacy" argument to gsi_channel_setup_one()
unnecessary. And with that gone we can get rid of the "legacy"
argument to gsi_channel_setup(), and gsi_setup() as well.
Signed-off-by: Alex Elder <elder@linaro.org>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Use the IPA version in gsi_channel_program() to determine whether
we should enable the GSI doorbell engine when requested. This way,
callers only say whether or not it should be enabled if needed,
regardless of hardware version.
Rename the "legacy" argument to gsi_channel_reset(), and have
it indicate whether the doorbell engine should be enabled when
reprogramming following the reset.
Change all callers of gsi_channel_reset() to indicate whether to
enable the doorbell engine after reset, independent of hardware
version.
Rework a little logic in ipa_endpoint_reset() to get rid of the
"legacy" variable previously passed to gsi_channel_reset().
Signed-off-by: Alex Elder <elder@linaro.org>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
A quirk of IPA v3.5.1 requires a channel reset on an RX channel to
be performed twice. Use the IPA version in gsi_channel_reset()
rather than the passed-in legacy flag to determine that.
This is actually a bug fix, because this double reset is supposed
to occur independent of whether we're enabling the doorbell engine.
Now they will be independent.
Signed-off-by: Alex Elder <elder@linaro.org>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
A quirk of IPA v4.2 requires the AP to allocate the GSI channels
that are owned by the modem.
Rather than pass a flag argument to gsi_channel_init(), use the
IPA version directly in that function to determine whether modem
channels need to be allocated.
Signed-off-by: Alex Elder <elder@linaro.org>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Record the IPA version passed to gsi_init() in the GSI structure.
This allows that value to be used directly where needed, rather than
passing and storing certain flag arguments through the code.
In particular, for all but one supported version of IPA, the command
channel is programmed to only use an "escape buffer". By storing
the IPA version, we can do a simple version check in one location,
and avoid storing a flag field in every channel (and passing a flag
along while initializing channels to set that field properly).
Signed-off-by: Alex Elder <elder@linaro.org>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Although GSI is integral to IPA, it is a separate hardware component
and the IPA code supporting it has been structured to avoid explicit
dependence on IPA details. An example of this is that gsi_init() is
passed a number of Boolean flags to indicate special behaviors,
whose values are dependent on the IPA hardware version. Looking
ahead, newer hardware versions would require even more such special
behaviors.
For any given version of IPA hardware (like 3.5.1 or 4.2), the GSI
hardware version is fixed (in this case, 1.3 and 2.2, respectively).
So the IPA version *implies* the GSI version, and the IPA version
can be used as effectively the equivalent of the GSI hardware version.
Rather than proliferating new special behavior flags, just provide
the IPA version to the GSI layer when it is initialized. The GSI
code can then use that directly to determine whether special
behaviors are required. The IPA version enumerated type is already
isolated to its own header file, so the exposure of this IPA detail
is very limited.
For now, just change gsi_init() to pass the version rather than the
Boolean flags, and set the flag values internal to that function.
Signed-off-by: Alex Elder <elder@linaro.org>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Now that the inactive_list is protected by mm_lock, and everything
else on per-obj basis is protected by obj->resv, we no longer depend
on struct_mutex.
Signed-off-by: Rob Clark <robdclark@chromium.org>
Reviewed-by: Kristian H. Kristensen <hoegsberg@google.com>
Signed-off-by: Rob Clark <robdclark@chromium.org>
The obj->lock is sufficient for what we need.
This *does* have the implication that userspace can try to shoot
themselves in the foot by racing madvise(DONTNEED) with submit. But
the result will be about the same if they did madvise(DONTNEED) before
the submit ioctl, ie. they might not get want they want if they race
with shrinker. But iova fault handling is robust enough, so userspace
is only shooting it's own foot.
Signed-off-by: Rob Clark <robdclark@chromium.org>
Reviewed-by: Kristian H. Kristensen <hoegsberg@google.com>
Signed-off-by: Rob Clark <robdclark@chromium.org>
Now that we don't need struct_mutex in the free path, we can get rid of
the asynchronous free altogether.
Signed-off-by: Rob Clark <robdclark@chromium.org>
Reviewed-by: Kristian H. Kristensen <hoegsberg@google.com>
Signed-off-by: Rob Clark <robdclark@chromium.org>
Now that active_list/inactive_list is protected by mm_lock, we no longer
need dev->struct_mutex in the free_object() path.
Signed-off-by: Rob Clark <robdclark@chromium.org>
Reviewed-by: Kristian H. Kristensen <hoegsberg@google.com>
Signed-off-by: Rob Clark <robdclark@chromium.org>
Now that we are not relying on dev->struct_mutex to protect the
ring->submits lists, drop the struct_mutex lock.
Signed-off-by: Rob Clark <robdclark@chromium.org>
Reviewed-by: Jordan Crouse <jcrouse@codeaurora.org>
Reviewed-by: Kristian H. Kristensen <hoegsberg@google.com>
Signed-off-by: Rob Clark <robdclark@chromium.org>
It cannot be atomically updated with obj->active_count, and the only
purpose is a useless WARN_ON() (which becomes a buggy WARN_ON() once
retire_submits() is not serialized with incoming submits via
struct_mutex)
Signed-off-by: Rob Clark <robdclark@chromium.org>
Reviewed-by: Kristian H. Kristensen <hoegsberg@google.com>
Signed-off-by: Rob Clark <robdclark@chromium.org>
Before we remove dev->struct_mutex from the retire path, we have to deal
with the situation of a submit retiring before the submit ioctl returns.
To deal with this, ring->submits will hold a reference to the submit,
which is dropped when the submit is retired. And the submit ioctl path
holds it's own ref, which it drops when it is done with the submit.
Also, add to submit list *after* getting/pinning bo's, to prevent badness
in case the completed fence is corrupted, and retire_worker mistakenly
believes the submit is done too early.
Signed-off-by: Rob Clark <robdclark@chromium.org>
Reviewed-by: Jordan Crouse <jcrouse@codeaurora.org>
Reviewed-by: Kristian H. Kristensen <hoegsberg@google.com>
Signed-off-by: Rob Clark <robdclark@chromium.org>
One less place to rely on dev->struct_mutex.
Signed-off-by: Rob Clark <robdclark@chromium.org>
Reviewed-by: Jordan Crouse <jcrouse@codeaurora.org>
Reviewed-by: Kristian H. Kristensen <hoegsberg@google.com>
Signed-off-by: Rob Clark <robdclark@chromium.org>
Before adding another lock, give ring->lock a more descriptive name.
Signed-off-by: Rob Clark <robdclark@chromium.org>
Reviewed-by: Jordan Crouse <jcrouse@codeaurora.org>
Reviewed-by: Kristian H. Kristensen <hoegsberg@google.com>
Signed-off-by: Rob Clark <robdclark@chromium.org>
Rather than relying on the big dev->struct_mutex hammer, introduce a
more specific lock for protecting the bo lists.
Signed-off-by: Rob Clark <robdclark@chromium.org>
Reviewed-by: Jordan Crouse <jcrouse@codeaurora.org>
Reviewed-by: Kristian H. Kristensen <hoegsberg@google.com>
Signed-off-by: Rob Clark <robdclark@chromium.org>
Small cleanup, update_fences() is used in the hangcheck path, but also
in the normal retire path.
Signed-off-by: Rob Clark <robdclark@chromium.org>
Reviewed-by: Jordan Crouse <jcrouse@codeaurora.org>
Reviewed-by: Kristian H. Kristensen <hoegsberg@google.com>
Signed-off-by: Rob Clark <robdclark@chromium.org>
It is somewhat redundant with the gpu tracepoints, and anyways not too
useful to justify spamming the log when debug traces are enabled.
Signed-off-by: Rob Clark <robdclark@chromium.org>
Reviewed-by: Jordan Crouse <jcrouse@codeaurora.org>
Reviewed-by: Kristian H. Kristensen <hoegsberg@google.com>
Signed-off-by: Rob Clark <robdclark@chromium.org>
We only want to use the _unlocked() variant in the unlocked case.
Signed-off-by: Rob Clark <robdclark@chromium.org>
Reviewed-by: Kristian H. Kristensen <hoegsberg@google.com>
Signed-off-by: Rob Clark <robdclark@chromium.org>
This also converts the special msm_gem_get_vaddr_active() to expect the
lock to already be held. There are two call-sites for this, one already
has the lock held, so it is more straightforward to just open-code the
locking for the other caller.
Signed-off-by: Rob Clark <robdclark@chromium.org>
Reviewed-by: Kristian H. Kristensen <hoegsberg@google.com>
Signed-off-by: Rob Clark <robdclark@chromium.org>
Unfortunately, due to an dev_pm_opp locking interaction with
mm->mmap_sem, we need to do pm get before aquiring obj locks,
otherwise we can have anger lockdep with the chain:
opp_table_lock --> &mm->mmap_sem --> reservation_ww_class_mutex
For an explicit fencing userspace, the impact should be minimal
as we do all the fence waits before this point. It could result
in some needless resumes in error cases, etc.
Signed-off-by: Rob Clark <robdclark@chromium.org>
Reviewed-by: Kristian H. Kristensen <hoegsberg@google.com>
Signed-off-by: Rob Clark <robdclark@chromium.org>
We cannot switch to using obj->resv for locking without first moving all
the copy_from_user() ahead of submit_lock_objects(). Otherwise in the
mm fault path we aquire mm->mmap_sem before obj lock, but in the submit
path the order is reversed.
Signed-off-by: Rob Clark <robdclark@chromium.org>
Reviewed-by: Kristian H. Kristensen <hoegsberg@google.com>
Signed-off-by: Rob Clark <robdclark@chromium.org>
Move grabbing the bo lock into shrinker, with a msm_gem_trylock() to
skip over bo's that are already locked. This gets rid of the nested
lock classes.
Signed-off-by: Rob Clark <robdclark@chromium.org>
Reviewed-by: Kristian H. Kristensen <hoegsberg@google.com>
Signed-off-by: Rob Clark <robdclark@chromium.org>
When we cut-over to using dma_resv_lock/etc instead of msm_obj->lock,
we'll need these for the submit path (where resv->lock is already held).
Signed-off-by: Rob Clark <robdclark@chromium.org>
Reviewed-by: Kristian H. Kristensen <hoegsberg@google.com>
Signed-off-by: Rob Clark <robdclark@chromium.org>
Signed-off-by: Rob Clark <robdclark@chromium.org>
Reviewed-by: Kristian H. Kristensen <hoegsberg@google.com>
Signed-off-by: Rob Clark <robdclark@chromium.org>
We'll need to introduce a _locked() version of msm_gem_get_iova(), so we
need to make that name available.
Signed-off-by: Rob Clark <robdclark@chromium.org>
Reviewed-by: Kristian H. Kristensen <hoegsberg@google.com>
Signed-off-by: Rob Clark <robdclark@chromium.org>
This will make it easier to transition over to obj->resv locking for
everything that is per-bo locking.
Signed-off-by: Rob Clark <robdclark@chromium.org>
Reviewed-by: Kristian H. Kristensen <hoegsberg@google.com>
Signed-off-by: Rob Clark <robdclark@chromium.org>
The microcode bo's should never be madvise(WONTNEED), so these should
not be using msm_gem_get_vaddr_active().
Signed-off-by: Rob Clark <robdclark@chromium.org>
Reviewed-by: Kristian H. Kristensen <hoegsberg@google.com>
Signed-off-by: Rob Clark <robdclark@chromium.org>
Reading VCO rate for this PLL can cause boot stalls, if it is not
enabled. Guard clk_hw_get_rate with a call to
dsi_pll_28nm_clk_is_enabled().
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Signed-off-by: Rob Clark <robdclark@chromium.org>
Commit f89c696e7f ("drm/mediatek: mtk_dpi: Convert to bridge driver")
introduced the following build warning with W=1
drivers/gpu/drm/mediatek/mtk_dpi.c:530:39: warning: unused variable 'mtk_dpi_encoder_funcs' [-Wunused-const-variable]
static const struct drm_encoder_funcs mtk_dpi_encoder_funcs = {
This struct is and the 'mtk_dpi_encoder_destroy()' are not needed
anymore, so remove them.
Fixes: f89c696e7f ("drm/mediatek: mtk_dpi: Convert to bridge driver")
Reported-by: kernel test robot <lkp@intel.com>
Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
Signed-off-by: Chun-Kuang Hu <chunkuang.hu@kernel.org>
Add module parameter multipath_on_hba to enable/disable multi-port path
topology support. By default this feature is enabled on SAS3.5 HBA device
and disabled on SAS3 &SAS2.5 HBA devices.
When this feature is disabled then driver uses a default
PhysicalPort(PortID) number i.e. 255 instead of the PhysicalPort number
provided by HBA firmware.
Link: https://lore.kernel.org/r/20201027130847.9962-14-sreekanth.reddy@broadcom.com
Signed-off-by: Sreekanth Reddy <sreekanth.reddy@broadcom.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
During HBA reset the Port ID of vSES device may change. As a result, it is
necessary to refresh virtual_phy objects after reset.
Each Port's vphy_list table needs to be updated after updating the
HBA port table. The algorithm is as follows:
- Loop over each port entry from HBA port table
* Loop over each virtual phy entry from port's vphys_list table
- Mark virtual phy entry as dirty by setting dirty bit in virtual phy
entry's flags field
- Read SASIOUnitPage0 page
- Loop over each HBA Phy's Phy data from SASIOUnitPage0
* If phy's remote attached device is not SES device then continue with
processing next HBA Phy's Phy data;
* Read SASPhyPage0 data for this Phy number and determine whether
current phy is a virtual phy or not. If it is not a virtual phy then
continue with next Phy data;
* Get the current phy's remote attached vSES device's SAS Address;
* Loop over each port entry from HBA port table
- If Port's vphys_mask field is zero then continue with
next Port entry,
- Loop over each virtual phy entry from Port's vphy_list table
- If the current phy's remote SAS Address is different from
virtual phy entry's SAS Address then continue with next
virtual phy entry,
- Set bit corresponding to current phy number in virtual phy
entry's phy_mask field,
- Get the HBA port table's Port entry corresponding to
Phy data's 'Port' value,
* If there is no Port entry corresponding to Phy data's
'Port' value in HBA port table then create a new port entry
and add it to HBA port table.
- If this retrieved Port entry is the same as the current Port
entry then don't do anything, just clear the dirty bit from
virtual phy entry's flag field and continue with processing
next HBA Phy's Phy data.
- If this retrieved Port entry is different from the current Port
entry then move the current virtual phy entry from current Port's
vphys_list to retrieved Port entry's vphys_list.
* Clear current phy bit in current Port entry's vphys_mask and
set the current phy bit in the retrieved Port entry's
vphys_mask field.
* Clear the dirty bit from virtual phy entry's flag field and
continue with next HBA Phy's Phy data.
- Delete the 'virtual phy' entries and HBA's 'Port table' entries which
are still marked as 'dirty'.
Link: https://lore.kernel.org/r/20201027130847.9962-13-sreekanth.reddy@broadcom.com
Signed-off-by: Sreekanth Reddy <sreekanth.reddy@broadcom.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Added a new parameter bypass_dirty_port_flag in function
mpt3sas_get_port_by_id(). When this parameter is set to one then search for
matching hba port entry from port_table_list even when this hba_port entry
is marked as dirty.
Link: https://lore.kernel.org/r/20201027130847.9962-12-sreekanth.reddy@broadcom.com
Signed-off-by: Sreekanth Reddy <sreekanth.reddy@broadcom.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Each direct attached device will have a unique Port ID, but with an
exception. HBA vSES may use the same Port ID of another direct attached
device Port's ID. As a result, special handling is needed for vSES.
Create a virtual_phy object when a new HBA vSES device is detected and add
this virtual_phy object to vphys_list of port ID's hba_port object. When
the HBA vSES device is removed then remove the corresponding virtual_phy
object from its parent's hba_port's vphy_list and free this virtual_vphy
object.
In hba_port object add vphy_mask field to hold the list of HBA phy bits
which are assigned to vSES devices. Also add vphy_list list to hold list of
virtual_phy objects which holds the same portID of current hba_port's
portID.
Also, add a hba_vphy field in _sas_phy object to determine whether this
_sas_phy object belongs to vSES device or not.
- Allocate a virtual_phy object whenever a virtual phy is detected while
processing the SASIOUnitPage0's phy data. And this allocated virtual_phy
object to corresponding PortID's hba_port's vphy_list.
- When a vSES device is added to the SML then initialize the corresponding
virtual_phy objects's sas_address field with vSES device's SAS Address.
- Free this virtual_phy object during driver unload time and when this
vSES device is removed.
Link: https://lore.kernel.org/r/20201027130847.9962-11-sreekanth.reddy@broadcom.com
Signed-off-by: Sreekanth Reddy <sreekanth.reddy@broadcom.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
The driver currently sets PhysicalPort field to 0xFF for SMPPassthrough
Request message. In zoning topologies this SMPPassthrough command always
operates on devices in one zone (default zone) even when user issues SMP
command for other zone drives.
Define _transport_get_port_id_by_rphy() and
_transport_get_port_id_by_sas_phy() helper functions to get Physical Port
number from sas_rphy & sas_phy respectively for SMPPassthrough request
message so that SMP Passthrough request message is sent to intended zone
device.
Link: https://lore.kernel.org/r/20201027130847.9962-10-sreekanth.reddy@broadcom.com
Signed-off-by: Sreekanth Reddy <sreekanth.reddy@broadcom.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
During host reset there is a chance that the Port number allocated by the
firmware for the attached devices may change. Also, it may be possible that
some HBA phy's can go down/come up after reset. As a result, the driver
can't just trust the HBA Port table that it has populated before host reset
as valid. Instead it has to update the HBA Port table in such a way that it
shouldn't disturb the drives which are still accessible even after host
reset.
Use the following algorithm to update the HBA Port table during host reset:
I. After host reset operation and before marking the devices as
responding/non-responding, create a temporary Port table called "New
Port table" by parsing each of the HBA phy's Phy data info read from SAS
IOUnit Page0:
a. Check whether Phy's negotiated link rate is greater than 1.5Gbps, if
not go to next Phy;
b. Get the SAS Address of the attached device;
c. Create a new entry in the "New Port table" with SAS Address field
filled with attached device's SAS Address, port number with Phy's
Port number (read from SAS IOUnit Page0) and enable bit in the 'Phy
mask' field corresponding to current Phy number. New entry is
created only if the driver can't find an entry in the "New Port
table" which matches with attached device 'SAS Address' & 'Port
Number'. If it finds an entry with matches with attached device 'SAS
Address' & 'Port Number' then the driver takes that matched entry and
will enable current Phy number bit in the 'Phy mask' field;
d. After parsing all the HBA phy's info, the driver will have complete
Port table info in "New Port table".
II. Mark all the existing sas_device & sas_expander device structures as
'dirty'.
III. Mark each entry of the HBA Port lists as 'dirty'.
IV. Take each entry from 'New Port table' one by one and check whether the
entry has any corresponding matched entry (which is marked as 'dirty')
in the HBA Port table or not. While looking for a corresponding
matched entry, look for matched entry in the sequence from top row to
bottom row listed in the following table. If you find any matched entry
(according to any of the rules tabulated below) then perform the action
mentioned in the 'Action' column in that matched rule.
===========================================================================
|Search |SAS | Phy Mask | Port | Possibilities| Action |
|every |Address | or | Number | | required |
|entry |matched?| subset of| matched?| | |
|in below| | phy mask | | | |
|sequence| | matched? | | | |
===========================================================================
| 1 |matched | matched | matched | nothing |* unmark HBA port |
| | | | | changed |table entry as |
| | | | | |dirty |
---------------------------------------------------------------------------
| 2 |matched | matched | not | port number |* Update port |
| | | | matched | is changed |number in the |
| | | | | |matched port table |
| | | | | |entry |
| | | | | |* unmask HBA port |
| | | | | |table entry as |
| | | | | |dirty |
---------------------------------------------------------------------------
| 3.a |matched | subset of| matched |some phys |* Add these new |
| | | phy mask | (or) |might have |phys to current |
| | | matched | not |enabled which |port in STL |
| | | | matched |are previously|* Update phy mask |
| | | | (but |disabled |field in HBA's port|
| | | | first | |table's matched |
| | | | look for| |entry, |
| | | | matched | |* Update port |
| | | | one) | |number in the |
| | | | | |matched port |
| | | | | |table entry (if |
| | | | | |port number is |
| | | | | |changed), |
| | | | | |* Unmask HBA port |
| | | | | |table entry as |
| | | | | |dirty |
---------------------------------------------------------------------------
| 3.b |matched | subset of| matched |some phys |*Remove these phys |
| | | phy mask | (or) |might have |from current port |
| | | matched | not |disabled which|in STL |
| | | | matched |are previously|* Update phy mask |
| | | | (but |enabled |field in HBA's port|
| | | | first | |tables's matched |
| | | | look for| |entry, |
| | | | matched | |*Update port number|
| | | | one) | |in the matched port|
| | | | | |table entry (if |
| | | | | |port number is |
| | | | | |changed), |
| | | | | |* Unmask HBA port |
| | | | | |table entry as |
| | | | | |dirty |
---------------------------------------------------------------------------
| 4 |matched | not | matched |A cable |*Remove old phys & |
| | | matched | (or) |attached to an|new phys to current|
| | | | not |expander is |port in STL |
| | | | matched |changed to |* Update phy mask |
| | | | |another HBA |field in HBA's port|
| | | | |port during |tables's matched |
| | | | |reset |entry, |
| | | | | |*Update port number|
| | | | | |in the matched port|
| | | | | |table entry (if |
| | | | | |port number is |
| | | | | |changed), |
| | | | | |* Unmask HBA port |
| | | | | |table entry as |
| | | | | |dirty |
---------------------------------------------------------------------------
V. Delete the hba_port objects which are still marked as dirty.
Link: https://lore.kernel.org/r/20201027130847.9962-9-sreekanth.reddy@broadcom.com
Reported-by: kernel test robot <lkp@intel.com>
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Sreekanth Reddy <sreekanth.reddy@broadcom.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
In the following scsi_host_template and sas_function_template callback
functions the driver does not have PhysicalPort number information to
retrieve the sas_device object using SAS Address & PhysicalPort number. In
these callback functions the device's rphy object is used to retrieve
sas_device object for the device.
.target_alloc,
.get_enclosure_identifier
.get_bay_identifier
When a rphy (of type sas_rphy) object is allocated then its address is
saved in corresponding sas_device object's rphy field. In
__mpt3sas_get_sdev_by_rphy(), the driver loops over all the sas_device
objects from sas_device_list list to retrieve the sas_device objects whose
rphy matches the provided rphy.
Link: https://lore.kernel.org/r/20201027130847.9962-8-sreekanth.reddy@broadcom.com
Signed-off-by: Sreekanth Reddy <sreekanth.reddy@broadcom.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Renamed _transport_add_phy_to_an_existing_port() to
mpt3sas_transport_add_phy_to_an_existing_port() and
_transport_del_phy_from_an_existing_port() to
mpt3sas_transport_del_phy_from_an_existing_port() as the driver needs to
call these functions from outside mpt3sas_transport.c file.
Added extra function argument 'port' of type struct hba_port to above
functions and check for portID before adding/removing the phy from the
_sas_port object. I.e. add/remove the phy from _sas_port object only if
_sas_port's port object and phy's port object are the same.
Link: https://lore.kernel.org/r/20201027130847.9962-7-sreekanth.reddy@broadcom.com
Signed-off-by: Sreekanth Reddy <sreekanth.reddy@broadcom.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Currently driver retrieves the sas_device/sas_expander objects from
corresponding object's lists using just device's SAS Address.
Make driver retrieve the objects from the corresponding objects list using
device's SAS Address and PhysicalPort (or PortID) number. PhysicalPort
number is the port number of the HBA through which this device is accessed.
Link: https://lore.kernel.org/r/20201027130847.9962-6-sreekanth.reddy@broadcom.com
Signed-off-by: Sreekanth Reddy <sreekanth.reddy@broadcom.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Update hba_port's sas_address & phy_mask fields whenever a direct expander
or sas/sata target devices are added or removed.
When any direct attached device is discovered then driver:
- Gets the hba_port object corresponding to device's PhysicalPort
number;
- Updates the hba_port's sas_address field with device's SAS
Address;
- Updates the hba_port's phy_mask filed with device's narrow/wide
port Phy number bits;
- If a sas/sata end device (not only direct-attached devices) is added
then corresponding sas_device object's port variable is assigned with
hba_port object's address whose port_id matches the device's
PhysicalPort number.
- If an expander device is added then corresponding sas_expander object's
port variable is assigned with hba_port object's address whose port_id
matches the expander device's PhysicalPort number.
When any direct attached device is detached then driver will delete the
hba_port object corresponding to device's PhysicalPort number.
Whenever any HBA phy's link (of direct attached device's port) comes up
then update the phy_mask field of corresponding hba_port object.
Link: https://lore.kernel.org/r/20201027130847.9962-5-sreekanth.reddy@broadcom.com
Signed-off-by: Sreekanth Reddy <sreekanth.reddy@broadcom.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
