On 22/10/15 07:16, Matthew R. Ochs wrote:
Contexts may be skipped over for cleanup in situations where contention
for the adapter's table-list mutex is experienced in the presence of a
signal during the execution of the release handler.
This can lead to two known issues:
- A hang condition on
Each VF could have 6 BARs at most. When the total BAR size exceeds the
gate, after expanding it will also exhaust the M64 Window.
This patch limits the boundary by checking the total VF BAR size instead of
the individual BAR.
Signed-off-by: Wei Yang
Reviewed-by: Gavin Shan
Acked-by: Alexey Kard
At the moment 64bit-prefetchable window can be maximum 64GB, which is
currently got from device tree. This means that in shared mode the maximum
supported VF BAR size is 64GB/256=256MB. While this size could exhaust the
whole 64bit-prefetchable window. This is a design decision to set a
boundary to
When M64 BAR is set to Single PE mode, the PE# assigned to VF could be
sparse.
This patch restructures the code to allocate sparse PE# for VFs when M64
BAR is set to Single PE mode. Also it rename the offset to pe_num_map to
reflect the content is the PE number.
Signed-off-by: Wei Yang
Reviewed-
In original design, it tries to group VFs to enable more number of VFs in the
system, when VF BAR is bigger than 64MB. This design has a flaw in which one
error on a VF will interfere other VFs in the same group.
This patch series change this design by using M64 BAR in Single PE mode to
cover only
In current implementation, when VF BAR is bigger than 64MB, it uses 4 M64
BARs in Single PE mode to cover the number of VFs required to be enabled.
By doing so, several VFs would be in one VF Group and leads to interference
between VFs in the same group.
And in this patch, m64_wins is renamed to m
The alignment of IOV BAR on PowerNV platform is the total size of the IOV
BAR. No matter whether the IOV BAR is extended with number of
roundup_pow_of_two(total_vfs) or number of max PE number (256), the total
size could be calculated by (vfs_expanded * VF_BAR_size).
This patch simplifies the pnv_
On PHB3, we enable SRIOV devices by mapping IOV BAR with M64 BARs. If a
SRIOV device's IOV BAR is not 64bit-prefetchable, this is not assigned from
64bit prefetchable window, which means M64 BAR can't work on it.
The reason is PCI bridges support only 2 memory windows and the kernel code
programs
The name of PCI root bus's M64 resource isn't initialized properly.
When dumping "/proc/iomem", "" is seen for those M64 resources
on PCI root buses.
~# cat /proc/iomem | grep -e "BAD"
3b00-3b0fefff :
3b10-3b1fefff :
3c00-3c0fefff :
3c1
On Wed, 2015-10-21 at 00:54 -0500, Scott Wood wrote:
> On Mon, 2015-09-21 at 16:03 +0200, Tomeu Vizoso wrote:
> > Instead of trying to match and probe platform and AMBA devices right
> > after each is registered, delay their probes until device_initcall_sync.
> >
> > This means that devices will
On Wed, 2015-10-21 at 11:47 -0500, Segher Boessenkool wrote:
> On Mon, Oct 19, 2015 at 03:53:22PM +1100, Michael Ellerman wrote:
> > The boot wrapper uses dd when building for ps3, which annoyingly tells
> > us in great detail what it's doing, eg:
> >
> > 512+0 records in
> > 512+0 records o
On Wed, 2015-10-21 at 08:44 -0500, Rob Herring wrote:
> On Wed, Oct 21, 2015 at 12:54 AM, Scott Wood
> wrote:
> > On Mon, 2015-09-21 at 16:03 +0200, Tomeu Vizoso wrote:
> > > Instead of trying to match and probe platform and AMBA devices right
> > > after each is registered, delay their probes un
On 12.10.2015 00:08, Alexander Popov wrote:
> This driver for Freescale MPC512x LocalPlus Bus FIFO (called SCLPC
> in the Reference Manual) allows Direct Memory Access transfers
> between RAM and peripheral devices on LocalPlus Bus.
> Changes in v4:
> - the race condition is fixed;
> - plenty of
On Wed, Oct 21, 2015 at 12:54 AM, Scott Wood wrote:
> On Mon, 2015-09-21 at 16:03 +0200, Tomeu Vizoso wrote:
>> Instead of trying to match and probe platform and AMBA devices right
>> after each is registered, delay their probes until device_initcall_sync.
>>
>> This means that devices will start
Contexts may be skipped over for cleanup in situations where contention
for the adapter's table-list mutex is experienced in the presence of a
signal during the execution of the release handler.
This can lead to two known issues:
- A hang condition on remove as that path tries to wait for users
When running with lock instrumentation (e.g. lockdep), some of the
instrumentation can become disabled at probe time for a cxlflash
adapter. This is due to a missing lock registration for the tmf_slock.
The fix is to call spin_lock_init() for the tmf_slock during probe.
Signed-off-by: Matthew R.
The port selection mask of a LUN can be corrupted when the manage LUN
ioctl (DK_CXLFLASH_MANAGE_LUN) is issued more than once for any device.
This mask indicates to the AFU which port[s] can be used for a data
transfer to/from a particular LUN. The mask is critical to ensuring the
correct behavior
From: Manoj Kumar
A 'login timed out' asynchronous error interrupt is generated if no
response is seen to a FLOGI within 2 seconds. If the time out error
is not escalated to a LINK_RESET the port will not be available for
use. This fix provides the required escalation.
Signed-off-by: Manoj N. K
When running with an unsupported AFU, the cxlflash driver fails
the probe. When the driver is removed, the following Oops is
encountered on a show_interrupts() thread:
Call Trace:
[c01fba5a7a10] [0003] 0x3 (unreliable)
[c01fba5a7a60] [c053dcf4] vsnprintf+0x204/0x4c0
[c0
Ioctl threads that use scsi_execute() can run for an excessive amount
of time due to the fact that they have lengthy timeouts and retry logic
built in. Under normal operation this is not an issue. However, once EEH
enters the picture, a long execution time coupled with the possibility
that a timeou
The trace following the failure of alloc_mem() incorrectly identifies
which function failed. This can lead to misdiagnosing a failure.
Fix the string to correctly indicate that alloc_mem() failed.
Reported-by: Brian King
Signed-off-by: Matthew R. Ochs
Signed-off-by: Manoj N. Kumar
Reviewed-by:
The fops owned by the adapter can be corrupted in certain scenarios,
opening a window where certain fops are temporarily NULLed before being
reset to their proper value. This can potentially lead software to make
incorrect decisions, leaving the user with the inability to function as
intended.
An
From: Manoj Kumar
The operator used to double the master context response delay
is incorrect and does not result in delay doubling.
To fix, use a left shift instead of the XOR operator.
Reported-by: Tomas Henzl
Signed-off-by: Matthew R. Ochs
Signed-off-by: Manoj N. Kumar
Reviewed-by: Brian K
Add stanza for cxlflash SCSI driver.
Signed-off-by: Matthew R. Ochs
Signed-off-by: Manoj N. Kumar
Reviewed-by: Brian King
Reviewed-by: Andrew Donnellan
---
MAINTAINERS | 9 +
1 file changed, 9 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 274f854..f2f3046 100644
--- a/MA
Following an adapter reset, the AFU RRQ that resides in host memory
holds stale data. This can lead to a condition where the RRQ interrupt
handler tries to process stale entries and/or endlessly loops due to an
out of sync generation bit.
To fix, the AFU RRQ in host memory needs to be cleared afte
There are several spelling and grammar mistakes throughout the
driver. Additionally there are a handful of places where there
are extra lines and unnecessary variables/statements. These are
a nuisance and pollute the driver.
Fix spelling and grammar issues. Update some comments for clarity and
con
The process_sense() routine can perform a read capacity which
can take some time to complete. If an EEH occurs while waiting
on the read capacity, the EEH handler will wait to obtain the
context's mutex in order to put the context in an error state.
The EEH handler will sit and wait until the conte
Sparse uncovered several errors with MMIO operations (accessing
directly) and handling endianness. These can cause issues when
running in different environments.
Introduce __iomem and proper endianness tags/swaps where
appropriate to make driver sparse clean.
Signed-off-by: Matthew R. Ochs
Signe
Several function prologs have incorrect parameter names and return
code descriptions. This can lead to confusion when reviewing the
source and creates inaccurate documentation.
To remedy, update the function prologs to properly reflect parameter
names and return codes.
Signed-off-by: Matthew R. O
The host reset handler is called with I/O already blocked, thus
there is no need to explicitly block and unblock I/O in the handler.
Signed-off-by: Matthew R. Ochs
Signed-off-by: Manoj N. Kumar
Reviewed-by: Brian King
---
drivers/scsi/cxlflash/main.c | 2 --
1 file changed, 2 deletions(-)
dif
When the device reset handler is entered while a reset operation
is taking place, the handler exits without actually sending a
reset (TMF) to the targeted device. This behavior is incorrect
as the device is not reset. Further complicating matters is the
fact that a success is returned even when the
The workq can process work in parallel with a remove event, leading
to a condition where the workq handler can access freed memory.
To remedy, the workq should be terminated prior to freeing memory. Move
the termination call earlier in remove and use cancel_work_sync() instead
of flush_work() as t
Currently, scsi_host_put() is being called prematurely in the
remove path and is missing entirely in an error cleanup path.
The former can lead to memory being freed too early with
subsequent access potentially corrupting data whilst the former
would result in a memory leak.
Move the usage on remo
The AFU version is stored as a non-terminated string of bytes within
a 64-bit little-endian register. Presently the value is read directly
(no MMIO accessor) and is stored in a buffer that is not big enough
to contain a NULL terminator. Additionally the version obtained is not
evaluated against a k
At present, both ports must be online for the device to
configure properly. Remove this dependency and the unnecessary
internal LUN override logic as well. Additionally, as a refactoring
measure, change the return code variable name to match that used
throughout the driver.
With this change, the c
A bug was introduced earlier in the development cycle when cleaning
up logic statements. Instead of skipping bits that are not set, set
bits are skipped, causing async interrupts to not be handled correctly.
To fix, simply add back in the proper evaluation for an unset bit.
Signed-off-by: Matthew
Following a link up event, the LUNs available to the host may
have changed. Without rescanning the host, the LUN topology is
unknown to the user. In such a state, the user would be unable
to locate provisioned resources.
To remedy, the host should be rescanned after a link up event.
Signed-off-by
The resid is incorrectly set which can lead to unnecessary retry
attempts by the stack. This is due to resid _always_ being set
using a value returned from the adapter. Instead, the value
should only be interpreted and set when in an underrun scenario.
Signed-off-by: Matthew R. Ochs
Signed-off-by
Borrowing the TMF waitq's spinlock causes a stall condition when
waiting for the TMF to complete. To remedy, introduce our own spin
lock to serialize TMF and use the appropriate wait services.
Also add a timeout while waiting for a TMF completion. When a TMF
times out, report back a failure such t
During run-time the driver can be very chatty and spam the system
kernel log. Various print statements can be limited and/or moved
to development-only mode. Additionally, numerous prints can be
converted to trace the corresponding device. Lastly, one spelling
correction was made: 'entra' to 'extra'
Implement the following suggestions and add two new attributes
to allow for debugging the port LUN table.
- use scnprintf() instead of snprintf()
- use DEVICE_ATTR_RO and DEVICE_ATTR_RW
Suggested-by: Shane Seymour
Signed-off-by: Matthew R. Ochs
Signed-off-by: Manoj N. Kumar
Reviewed-by: Bria
Found during code inspection, that the following functions are not
being used outside of the file where they are defined. Make them static.
int cxlflash_send_cmd(struct afu *, struct afu_cmd *);
void cxlflash_wait_resp(struct afu *, struct afu_cmd *);
int cxlflash_afu_reset(struct cxlflash_cfg *);
Limbo is not an accurate representation of this state and is
also not consistent with the terminology that other drivers
use to represent this concept. Rename the state and and its
associated waitq to 'reset'.
Signed-off-by: Matthew R. Ochs
Signed-off-by: Manoj N. Kumar
Reviewed-by: Brian King
During an EEH freeze event, certain CXL services should not be
called until after the hardware reset has taken place. Doing so
can result in unnecessary failures and possibly cause other ill
effects by triggering hardware accesses. This translates to a
requirement to quiesce all threads that may po
The context encode mask covers more than 32-bits, making it
a long integer. This should be noted by appending the ULL
width suffix to the mask.
Signed-off-by: Matthew R. Ochs
Signed-off-by: Manoj N. Kumar
Reviewed-by: Brian King
Reviewed-by: Daniel Axtens
Reviewed-by: Tomas Henzl
---
drivers
Using sizeof(bool) is considered poor form for various reasons and
sparse warns us of that. Correct by changing type from bool to u8.
Signed-off-by: Matthew R. Ochs
Signed-off-by: Manoj N. Kumar
Reviewed-by: Brian King
Reviewed-by: Daniel Axtens
Reviewed-by: Tomas Henzl
---
drivers/scsi/cxlf
If the same virtual LUN is accessed over multiple cards, only accesses
made over the first card will be valid. Accesses made over the second
card will go to the wrong LUN causing data corruption.
This is because the global LUN's mode word was being used to determine
whether the LUN table for that
When a LUN is removed, the sdev that is associated with the LUN
remains intact until its reference count drops to 0. In order
to prevent an sdev from being removed while a context is still
associated with it, obtain an additional reference per-context
for each LUN attached to the context.
This res
From: Manoj Kumar
The timeout value for read capacity is too small. Certain devices
may take longer to respond and thus the command may prematurely
timeout. Additionally the literal used for the timeout is stale.
Update the timeout to 30 seconds (matches the value used in sd.c)
and rework the ti
From: Manoj Kumar
Magic numbers are not meaningful and can create confusion. As a
remedy, replace them with descriptive literals.
Replace 512 with literal MAX_SECTOR_UNIT.
Replace 5 with literal CMD_RETRIES.
Signed-off-by: Matthew R. Ochs
Signed-off-by: Manoj N. Kumar
Reviewed-by: Brian King
From: Manoj Kumar
If two concurrent MANAGE_LUN ioctls are issued with the same
WWID parameter, it would result in an incorrect value of port_sel.
This is because port_sel is modified without any locks being
held. If the first caller stalls after the return from
find_and_create_lun(), the value o
This patch set contains various fixes and corrections for issues that
were found during test and code review. The series is based upon the
code upstreamed in 4.3 (rebased to Dan Carpenter's 9/22 patch) and is
intended for 4.4. The entire set is bisectable. Please reference the
changelog below for d
On Wed, Oct 21, 2015 at 09:36:44PM +0200, Peter Zijlstra wrote:
> On Wed, Oct 21, 2015 at 12:29:23PM -0700, Paul E. McKenney wrote:
> > On Wed, Oct 21, 2015 at 10:24:52AM +0200, Peter Zijlstra wrote:
> > > On Tue, Oct 20, 2015 at 04:34:51PM -0700, Paul E. McKenney wrote:
> > > > There is also the q
On Wed, Oct 21, 2015 at 12:35:23PM -0700, Paul E. McKenney wrote:
> > > > > I ask this because I recall Peter once bought up a discussion:
> > > > >
> > > > > https://lkml.org/lkml/2015/8/26/596
> > So a full barrier on one side of these operations is enough, I think.
> > IOW, there is no need to
On Wed, Oct 21, 2015 at 12:29:23PM -0700, Paul E. McKenney wrote:
> On Wed, Oct 21, 2015 at 10:24:52AM +0200, Peter Zijlstra wrote:
> > On Tue, Oct 20, 2015 at 04:34:51PM -0700, Paul E. McKenney wrote:
> > > There is also the question of whether the barrier forces ordering
> > > of unrelated stores
Reviewed-by: Brian King
--
Brian King
Power Linux I/O
IBM Linux Technology Center
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
On Wed, Oct 21, 2015 at 10:18:33AM +0200, Peter Zijlstra wrote:
> On Tue, Oct 20, 2015 at 02:28:35PM -0700, Paul E. McKenney wrote:
> > I am not seeing a sync there, but I really have to defer to the
> > maintainers on this one. I could easily have missed one.
>
> So x86 implies a full barrier fo
On Wed, Oct 21, 2015 at 04:45:03PM +0800, Boqun Feng wrote:
> On Tue, Oct 20, 2015 at 02:28:35PM -0700, Paul E. McKenney wrote:
> > On Tue, Oct 20, 2015 at 11:21:47AM +0200, Peter Zijlstra wrote:
> > > On Tue, Oct 20, 2015 at 03:15:32PM +0800, Boqun Feng wrote:
> > > > On Wed, Oct 14, 2015 at 01:19
On Wed, Oct 21, 2015 at 04:04:04PM +, David Laight wrote:
> From: Paul E. McKenney
> > Sent: 21 October 2015 00:35
> ...
> > There is also the question of whether the barrier forces ordering
> > of unrelated stores, everything initially zero and all accesses
> > READ_ONCE() or WRITE_ONCE():
> >
On Wed, Oct 21, 2015 at 10:24:52AM +0200, Peter Zijlstra wrote:
> On Tue, Oct 20, 2015 at 04:34:51PM -0700, Paul E. McKenney wrote:
> > There is also the question of whether the barrier forces ordering
> > of unrelated stores, everything initially zero and all accesses
> > READ_ONCE() or WRITE_ONCE
On Mon, Oct 19, 2015 at 03:53:22PM +1100, Michael Ellerman wrote:
> The boot wrapper uses dd when building for ps3, which annoyingly tells
> us in great detail what it's doing, eg:
>
> 512+0 records in
> 512+0 records out
> 512 bytes (512 B) copied, 0.000802129 s, 638 kB/s
> 512+0 records
From: Paul E. McKenney
> Sent: 21 October 2015 00:35
...
> There is also the question of whether the barrier forces ordering
> of unrelated stores, everything initially zero and all accesses
> READ_ONCE() or WRITE_ONCE():
>
> P0 P1 P2 P3
> X = 1;
Commit 1851617cd2da ("PCI/MSI: Disable MSI at enumeration even if kernel
doesn't support MSI") changed the location of the code that initializes
dev->msi_cap/msix_cap and disables MSI/MSI-X interrupts at PCI probe
time in devices that have this flag set. It moved the code from
pci_msi_init_pci_dev(
On Wed, 2015-21-10 at 05:03:14 UTC, Paul Mackerras wrote:
> This reverts commit 9678cdaae93932473f696fdea5debf3eee1e1260 because
> the original commit had multiple, partly self-cancelling bugs, that
> could cause occasional memory corruption. In fact the logmpp instruction
> was using register r0
On Sun, 2015-18-10 at 10:23:53 UTC, Denis Kirjanov wrote:
> Event Based Branches currenly available on POWER8.
> so we can skip them on other CPUs.
>
> I've found that at least one test loops forever
> on 970MP (cycles_with_freeze_test).
>
> Signed-off-by: Denis Kirjanov
Applied to powerpc next
On Mon, 2015-19-10 at 17:53:26 UTC, Geoff Levand wrote:
> Add a boot wrapper script function run_cmd which will run a shell command
> quietly and only print the output if either V=1 or an error occurs.
>
> Also, run the ps3 dd commands with run_cmd to clean up the build output.
>
> Signed-off-by:
On Thu, 2015-15-10 at 04:22:35 UTC, Gavin Shan wrote:
> Similar to commit b6541db ("powerpc/eeh: Block PCI config access
> upon frozen PE"), this blocks the PCI config space of Broadcom
> Shiner adapter until PE reset is completed, to avoid recursive
> fenced PHB when dumping PCI config registers d
On Tue, 2015-13-10 at 08:17:07 UTC, Michael Ellerman wrote:
> The TUNE_CELL option allows you to build a kernel that runs on multiple
> CPUs but is tuned (ie. optimised) to run on Cell CPUs. Now days no one
> is building a distro in that fashion, and any users who are building
> custom kernels for
On Fri, 2015-16-10 at 21:38:45 UTC, Christophe Jaillet wrote:
> of_get_property() is used inside the loop, but then the reference to the
> node is dropped before dereferencing the prop pointer, which could by then
> point to junk if the node has been freed.
>
> Instead use of_property_read_u32() t
On Thu, 2015-08-10 at 03:58:52 UTC, Gavin Shan wrote:
> On PowerNV platform, the PE is kept in frozen state until the PE
> reset is completed to avoid recursive EEH error caused by MMIO
> access during the period of EEH reset. The PE's frozen state is
> cleared after BARs of PCI device included in
Building with CONFIG_DEBUG_SECTION_MISMATCH
gives the following warning:
WARNING: vmlinux.o(.text+0x41fa8): Section mismatch in reference from
the function .msi_bitmap_alloc() to the function
.init.text:.memblock_virt_alloc_try_nid()
The function .msi_bitmap_alloc() references
the function __init
On Thu, 2015-10-15 at 21:16 +0530, Anshuman Khandual wrote:
> This adds two tests for memory page migration. One for normal page
> migration which works for both 4K or 64K base page size kernel and
> the other one is for 16MB huge page migration which will work both
> 4K or 64K base page sized 16M
On Tue, Oct 20, 2015 at 02:28:35PM -0700, Paul E. McKenney wrote:
> On Tue, Oct 20, 2015 at 11:21:47AM +0200, Peter Zijlstra wrote:
> > On Tue, Oct 20, 2015 at 03:15:32PM +0800, Boqun Feng wrote:
> > > On Wed, Oct 14, 2015 at 01:19:17PM -0700, Paul E. McKenney wrote:
> > > >
> > > > Am I missing s
On 20/10/2015 at 20:20:07 -0400, Paul Gortmaker wrote :
> [Re: [PATCH 0/5] drivers/tty: make more bool drivers explicitly non-modular]
> On 20/10/2015 (Tue 17:10) Alexandre Belloni wrote:
>
> > On 18/10/2015 at 18:21:13 -0400, Paul Gortmaker wrote :
> > > The one common thread here for all the pa
On Tue, Oct 20, 2015 at 04:34:51PM -0700, Paul E. McKenney wrote:
> There is also the question of whether the barrier forces ordering
> of unrelated stores, everything initially zero and all accesses
> READ_ONCE() or WRITE_ONCE():
>
> P0 P1 P2 P3
>
On Wed, Oct 21, 2015 at 06:52:51PM +1100, Michael Ellerman wrote:
>On Wed, 2015-10-21 at 15:17 +0800, Wei Yang wrote:
>
>> Count of M64 BAR would differ with the evolution of hardware.
>>
>> This patch retieves this count from device node instead of a hard coded
>> value.
>>
>> Signed-off-by: Wei
On 10/21/15, Arnd Bergmann wrote:
> On Wednesday 21 October 2015 08:56:44 Denis Kirjanov wrote:
>> Building with CONFIG_DEBUG_SECTION_MISMATCH
>> gives the following warning:
>>
>> WARNING: vmlinux.o(.text+0x41fa8): Section mismatch in reference from
>> the function .msi_bitmap_alloc() to the func
On Tue, Oct 20, 2015 at 02:28:35PM -0700, Paul E. McKenney wrote:
> I am not seeing a sync there, but I really have to defer to the
> maintainers on this one. I could easily have missed one.
So x86 implies a full barrier for everything that changes the CPL; and
some form of implied ordering seems
On Wed, 2015-10-21 at 15:17 +0800, Wei Yang wrote:
> Count of M64 BAR would differ with the evolution of hardware.
>
> This patch retieves this count from device node instead of a hard coded
> value.
>
> Signed-off-by: Wei Yang
> ---
> arch/powerpc/platforms/powernv/pci-ioda.c | 7 ++-
> 1
Count of M64 BAR would differ with the evolution of hardware.
This patch retieves this count from device node instead of a hard coded
value.
Signed-off-by: Wei Yang
---
arch/powerpc/platforms/powernv/pci-ioda.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/arch/power
80 matches
Mail list logo
