Acked-by: Ian Munsie
Acked-by: Ian Munsie
Acked-by: Ian Munsie
Acked-by: Ian Munsie
Acked-by: Ian Munsie
Acked-by: Ian Munsie
Excerpts from Frederic Barrat's message of 2016-03-09 20:27:20 +1100:
> It would also avoid entering
> WARN(1, "afu_read must be buggy\n");
> if the driver changes its mind between the 2 calls :-)
Honestly, it had better not - that would be a gross violation of the
poll & read semantics an
Excerpts from Vaibhav Jain's message of 2016-03-10 01:37:56 +1100:
> > +select CXL_AFU_DRIVER_OPS
> I suggest wrapping the driver_ops struct definition and other related
> functions inside a #ifdef CONFIG_CXL_AFU_DRIVER_OPS.
No, the kconfig option is there so that cxlflash can add support for
Excerpts from Frederic Barrat's message of 2016-03-09 20:27:20 +1100:
> So on afu_read(), we may call afu_driver_ops->event_pending() twice
> before calling afu_driver_ops->deliver_event(). Actually, in the
> (likely) scenario where there's only an afu_driver event pending, we
> *will* call afu_
From: Ian Munsie
This adds an afu_driver_ops structure with event_pending and
deliver_event callbacks. An AFU driver such as cxlflash can fill these
out and associate it with a context to enable passing custom AFU
specific events to userspace.
The cxl driver will call event_pending() during
.
Signed-off-by: Michael Neuling
Signed-off-by: Ian Munsie
Reviewed-by: Matthew R. Ochs
---
No changes since v1, added Matt Ochs reviewed-by tag.
drivers/misc/cxl/api.c | 21 +
drivers/misc/cxl/cxl.h | 3 +++
include/misc/cxl.h | 7 +++
3 files changed, 31 insertions
Excerpts from Matt Ochs's message of 2016-03-08 11:26:55 +1100:
> Any reason for adding these extra lines as part of this commit?
mpe asked for some newlines here in the v1 submission, and it only
really made sense to do so if all the related sections had consistent
whitespace as well.
> > +/*
>
From: Ian Munsie
This adds an afu_driver_ops structure with event_pending and
deliver_event callbacks. An AFU driver such as cxlflash can fill these
out and associate it with a context to enable passing custom AFU
specific events to userspace.
The cxl driver will call event_pending() during
.
Signed-off-by: Michael Neuling
Signed-off-by: Ian Munsie
---
No changes since v1
drivers/misc/cxl/api.c | 21 +
drivers/misc/cxl/cxl.h | 3 +++
include/misc/cxl.h | 7 +++
3 files changed, 31 insertions(+)
diff --git a/drivers/misc/cxl/api.c b/drivers/misc/cxl/api.c
Acked-by: Ian Munsie
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Ian Munsie
If the cxl_context_alloc() call fails, we return immediately without
releasing the reference on the AFU device, allowing it to leak.
This patch switches to using goto style error handling so that the
device is released in common code for both error paths, and will also
simplify
From: Ian Munsie
The cxl user api uses the address_space associated with the file when we
need to force unmap all cxl mmap regions (e.g. on eeh, driver detach,
etc). Currently, contexts allocated through the kernel api do not do
this and instead skip the mmap invalidation, potentially allowing
Excerpts from Michael Ellerman's message of 2015-08-19 15:30:46 +1000:
> On Wed, 2015-08-19 at 14:19 +1000, Ian Munsie wrote:
> > From: Ian Munsie
> >
> > This adds an afu_driver_ops structure with event_pending and
> > deliver_event callbacks. An AFU driver
Excerpts from Michael Ellerman's message of 2015-08-19 14:49:30 +1000:
> Do we really need the accessors? They don't buy anything I can see over just
> using ctx->priv directly.
The reasoning there is because we don't currently expose the contents of
stuct cxl_context to afu drivers, rather they j
.
Signed-off-by: Michael Neuling
Signed-off-by: Ian Munsie
---
drivers/misc/cxl/api.c | 21 +
drivers/misc/cxl/cxl.h | 3 +++
include/misc/cxl.h | 7 +++
3 files changed, 31 insertions(+)
diff --git a/drivers/misc/cxl/api.c b/drivers/misc/cxl/api.c
index e0f0c78..5f0b22e
From: Ian Munsie
This adds an afu_driver_ops structure with event_pending and
deliver_event callbacks. An AFU driver can fill these out and associate
it with a context to enable passing custom AFU specific events to
userspace.
The cxl driver will call event_pending() during poll, select, read
From: Ian Munsie
userspace programs using cxl currently have to use two strategies for
dealing with MMIO errors simultaneously. They have to check every read
for a return of all Fs in case the adapter has gone away and the kernel
has not yet noticed, and they have to deal with SIGBUS in case the
Acked-by: Ian Munsie
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Excerpts from Sukadev Bhattiprolu's message of 2015-07-17 11:51:04 +1000:
> Are you seeing this on big-endian or little-endian system?
>
> IIRC, I saw the opposite behavior on an LE system a few months ago.
> i.e. without 1028ccf5, 'perf listf|grep syscall' failed.
>
> Applying 1028ccf5, seemed t
Acked-by: Ian Munsie
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Acked-by: Ian Munsie
We are probably also missing an idr_destroy(&afu->contexts_idr); in
cxl_release_afu() as well if you wanted to send a patch for that.
Cheers,
-Ian
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a
From: Ian Munsie
It was discovered that if a process mmaped their problem state area they
were able to access one page more than expected, potentially allowing
them to access the problem state area of an unrelated process.
This was due to a simple off by one error in the mmap fault handler
From: Ian Munsie
This patch makes the mmap call fail outright if the requested region is
larger than the problem state area assigned to the context so the error
is reported immediately rather than waiting for an attempt to access an
address out of bounds.
Although we never expect users to map
Acked-by: Ian Munsie
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Acked-by: Ian Munsie
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Acked-by: Ian Munsie
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Ian Munsie
The afu fd release path was identified as a significant bottleneck in
the overall performance of cxl. While an optimal AFU design would
minimise the need to close & reopen the AFU fd, it is not always
practical to avoid.
The bottleneck seems to be down to the cal
Excerpts from Joe Perches's message of 2015-02-24 01:59:45 +1100:
> On Mon, 2015-02-23 at 11:55 +0100, Rasmus Villemoes wrote:
> > 24 of the %.16llx
> > matches are in drivers/misc/cxl/, so internal consistency wins.
>
> I think that's more an argument for changing all of the
> cx1 uses to "%016ll
Acked-by: Ian Munsie
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Excerpts from Rasmus Villemoes's message of 2015-02-21 00:26:22 +1100:
> C99 says that a precision given as simply '.' with no following digits
> or * should be interpreted as 0. The kernel's printf implementation,
> however, treats this case as if the precision was omitted. C99 also
> says that if
From: Ian Munsie
We were missing a return statement in the PSL interrupt handler in the
case of an AFU error, which would trigger an "Unhandled CXL PSL IRQ"
warning. We do actually handle these type of errors (by notifying
userspace), so add the missing return IRQ_HANDLED so we d
From: Ian Munsie
An AFU may optionally contain one or more PCIe like configuration
records, which can be used to identify the AFU.
This patch adds support for exposing the raw config space and the
vendor, device and class code under sysfs. These will appear in a
subdirectory of the AFU device
From: Ian Munsie
If an AFU claims to have a configuration record but doesn't actually
contain a vendor and device ID, fail the AFU initialisation. Right now
this is just a way of politely letting AFU developers know that they
need to fix their config space, but later on we may expose the AF
From: Ian Munsie
This patch adds tracepoints throughout the cxl driver, which can provide
insight into:
- Context lifetimes
- Commands sent to the PSL and AFU and their completion status
- Segment and page table misses and their resolution
- PSL and AFU interrupts
- slbia calls from the powerpc
Acked-By: Ian Munsie
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Ryan Grimm
Signed-off-by: Ian Munsie
---
drivers/misc/cxl/pci.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/misc/cxl/pci.c b/drivers/misc/cxl/pci.c
index 2ccd0a9..f801c28 100644
--- a/drivers/misc/cxl/pci.c
+++ b/drivers/misc/cxl/pci.c
@@ -319,6 +319,7 @@ stati
From: Ian Munsie
An issue was introduced with "cxl: Unmap MMIO regions when detaching a
context" (b123429e6a9e8d03aacf888d23262835f0081448) where closing a
context normally could also unmap the problem state area of other
contexts currently using the AFU.
It was also discovered th
Excerpts from Ian Munsie's message of 2014-12-08 19:18:01 +1100:
> From: Ian Munsie
>
> If we need to force detach a context (e.g. due to EEH or simply force
> unbinding the driver) we should prevent the userspace contexts from
> being able to access the Problem State Area
From: Ian Munsie
We had a known sleep while atomic bug if a CXL device was forcefully
unbound while it was in use. This could occur as a result of EEH, or
manually induced with something like this while the device was in use:
echo :01:00.0 > /sys/bus/pci/drivers/cxl-pci/unbind
The is
From: Ian Munsie
In this particular error path we have already allocated the AFU
interrupts, but have not yet set the status to STARTED. The detach
context code will only attempt to release the interrupts if the context
is in state STARTED, so in this case the interrupts would remain
allocated
From: Ian Munsie
If we need to force detach a context (e.g. due to EEH or simply force
unbinding the driver) we should prevent the userspace contexts from
being able to access the Problem State Area MMIO region further, which
they may have mapped with mmap().
This patch unmaps any mapped MMIO
From: Ian Munsie
Upon inspection of the implementation specific registers, it was
discovered that the high bit of the implementation specific RXCTL
register was enabled, which enables the DEADB00F debug feature.
The debug feature causes MMIO reads to a disabled AFU to respond with
0xDEADB00F
From: Ian Munsie
When we deactivate the AFU directed mode we free the scheduled process
area, but did not clear the register in the hardware that has a pointer
to it.
This should be fine since we will have already cleared out every context
and we won't do anything that would cause the har
From: Ian Munsie
If a context is being detached and we get a translation fault for it
there is little point getting it's mm and handling the fault, so just
respond with an address error and return earlier.
Signed-off-by: Ian Munsie
---
drivers/misc/cxl/fault.c | 6 ++
1 file chang
From: Ian Munsie
In the event that something goes wrong in the hardware and it is unable
to complete a process element comment we would end up polling forever,
effectively making the associated process unkillable.
This patch adds a timeout to the process element command code path, so
that we
1066 OPAL ICS 2050 Level cxl-afu0.0
514: 0 OPAL ICS 2048 Level cxl-card0-err
515: 0 OPAL ICS 2049 Level cxl-afu0.0-err
Signed-off-by: Michael Neuling
Signed-off-by: Ian Munsie
---
drivers/misc/cxl/cxl.h | 13 +--
drivers/misc
From: Ian Munsie
If an AFU has a hardware bug that causes it to acknowledge a context
terminate or remove while that context has outstanding transactions, it
is possible for the kernel to receive an interrupt for that context
after we have removed it from the context list.
The kernel will not
From: Ian Munsie
This moves the segment table hash calculation from cxl_load_segment into
find_free_sste since that is the only place it is actually used.
Signed-off-by: Ian Munsie
---
drivers/misc/cxl/fault.c | 34 ++
1 file changed, 18 insertions(+), 16
From: Ian Munsie
This patch simplifies the process of finding a free segment table entry
by disabling the secondary hash. This reduces the number of possible
entries in the segment table for a given address from 16 to 8.
Due to the large segment sizes we use it is extremely unlikely that the
From: Ian Munsie
This patch makes copro_calculate_slb mask the ESID by the correct mask
for 1T vs 256M segments.
This has no effect by itself as the extra bits were ignored, but it
makes debugging the segment table entries easier and means that we can
directly compare the ESID values for
From: Ian Munsie
In certain circumstances the PSL (Power Service Layer, which provides
translation services for CXL hardware) can send an interrupt for a
segment miss that the kernel has already handled. This can happen if
multiple translations for the same segment are queued in the PSL before
In certain circumstances the PSL (Power Service Layer, which provides
translation services for CXL hardware) can send an interrupt for a segment miss
that the kernel has already handled. This can happen if multiple translations
for the same segment are queued in the PSL before the kernel has restar
Excerpts from Aneesh Kumar K.V's message of 2014-10-28 01:38:41 +1100:
> I guess you are missing too many fixes in one patch.
>
> 1) One cleanup
> 2) Fix for masking ea correctly
> 3) And fix for not erroring out when a slb is already in the slb cache.
ok, I'll split it up
> > +/* This finds a f
Excerpts from Michael Ellerman's message of 2014-10-27 17:41:00 +1100:
> On Mon, 2014-27-10 at 04:24:35 UTC, Ian Munsie wrote:
> > From: Ian Munsie
> >
> > In certain circumstances the PSL can send an interrupt for a segment
>
> Define PSL before using it please.
From: Ian Munsie
In certain circumstances the PSL can send an interrupt for a segment
miss that the kernel has already handled. This can happen if multiple
translations for the same segment are queued in the PSL before the
kernel has restarted the first translation.
The CXL driver did not
From: Ian Munsie
If afu_read() returned due to a signal or the AFU file descriptor being
opened non-blocking it would not call finish_wait() before returning,
which could lead to a crash later when something else wakes up the wait
queue.
This patch restructures the wait logic to ensure that the
correctly.
Signed-off-by: Ian Munsie
---
drivers/misc/cxl/file.c | 20 +++-
1 file changed, 15 insertions(+), 5 deletions(-)
diff --git a/drivers/misc/cxl/file.c b/drivers/misc/cxl/file.c
index 847b7e6..378b099 100644
--- a/drivers/misc/cxl/file.c
+++ b/drivers/misc/cxl/file.c
Excerpts from Michael Neuling's message of 2014-10-08 19:55:02 +1100:
> +static ssize_t afu_read(struct file *file, char __user *buf, size_t count,
> +loff_t *off)
...
> +for (;;) {
> +prepare_to_wait(&ctx->wq, &wait, TASK_INTERRUPTIBLE);
> +if (ctx_event_pending(ctx
Hey Michael,
Excerpts from Michael Ellerman's message of 2014-10-02 16:02:37 +1000:
> > +/* ioctls */
> > +struct cxl_ioctl_start_work {
> > +__u64 wed;
> > +__u64 amr;
> > +__u64 reserved1;
> > +__u32 reserved2;
> > +__s16 num_interrupts; /* -1 = use value from afu descriptor
Hi Cody,
I just tried building this with gcc 4.5, which failed with the following
warning (treated as an error):
cc1: warnings being treated as errors
arch/powerpc/perf/hv-24x7.c: In function 'single_24x7_request':
arch/powerpc/perf/hv-24x7.c:346:1: error: the frame size of 8192 bytes is
larger
Excerpts from Winkler, Tomas's message of 2014-01-16 09:36:40 +1100:
> I think the issue was fixed and also then number of consecutive resets were
> limited to 3 so you should
> not see this issue anymore in the next release, your patch just conflicted
> with these fixes.
> Still need to provid
Excerpts from Winkler, Tomas's message of 2014-01-14 19:31:26 +1100:
> > Today's linux-next merge of the akpm-current tree got a conflict in
> > drivers/misc/mei/init.c between commit 33ec08263147 ("mei: revamp mei
> > reset state machine") from the char-misc tree and commit dd045dab2999
> > ("driv
reset:
unexpected enumeration response hbm.
Dec 23 12:29:57 dukhat kernel: [336224.363201] mei_me :00:16.0: unexpected
reset: dev_state = RESETTING
This patch rate-limits those specific messages to reduce the impact if
this problem ever recurs.
Signed-off-by: Ian Munsie
---
drivers/misc/mei/
> Brad, Linus, does the above patch work for you as well as for Ian?
That would work fine for me, but I guess we need confirmation from
someone with the ISO or JIS layouts.
Cheers,
-Ian
--
http://sites.google.com/site/DarkStarJunkSpace
--
http://darkstarshout.blogspot.com/
--
Please avoid sendi
than the existing WELLSPRING8 IDs.
Signed-off-by: Ian Munsie
---
drivers/hid/hid-apple.c | 2 ++
drivers/hid/hid-core.c | 2 ++
drivers/hid/hid-ids.h | 1 +
3 files changed, 5 insertions(+)
diff --git a/drivers/hid/hid-apple.c b/drivers/hid/hid-apple.c
index c7710b5..9e5e9dd 100644
--- a/driver
than the existing WELLSPRING8 IDs.
Signed-off-by: Ian Munsie
---
drivers/input/mouse/bcm5974.c | 17 +
1 file changed, 17 insertions(+)
diff --git a/drivers/input/mouse/bcm5974.c b/drivers/input/mouse/bcm5974.c
index 4ef4d5e..fcd2f3f 100644
--- a/drivers/input/mouse/bcm5974.c
I recently got a new mid-2013 Macbook Air, which seems to use a device ID that
is missing from the kernel. From lsusb:
Bus 001 Device 003: ID 05ac:0290 Apple, Inc.
This generation of Macbook Air already has three IDs listed in the kernel
(0x0291, 0x0292 and 0x0293) as WELLSPRING8, so I've added 0x
Hey Ben,
Adding some people to CC...
Excerpts from Ben Guthro's message of 2012-10-02 11:02:59 +1000:
> I pulled the latest bits up to 797b9e5ae93270ec27a1f1ed48cd697d01b2269f -
> but am seeing the following build failure with gcc 4.6.3
Building that SHA works for me (on x86, haven't tried PPC y
73 matches
Mail list logo
