I've had the same issue as described in commit
c68929f75dfcb6354918862b91b5778585de1fa5
Except my touchscreen's ID is
ID 04f3:0125 Elan Microelectronics Corp.
Signed-off-by: Logan Gunthorpe log...@deltatee.com
---
drivers/usb/core/quirks.c | 3 +++
1 file changed, 3 insertions(+)
diff --git
Hi Dan,
We've uncovered another issue during testing with these patches. We get
a kernel panic sometimes just while using a DAX filesystem. I've traced
the issue back to this patch. (There's a stack trace at the end of this
email.)
On 22/09/15 10:42 PM, Dan Williams wrote:
+static void
Hi Dan,
We've been doing some experimenting and testing with this patchset.
Specifically, we are trying to use you're ZONE_DEVICE work to enable
peer to peer PCIe transfers. This is actually working pretty well
(though we're still testing and working through some things).
However, we've found a
Hi Dan,
Good to know you've already addressed the struct page issue. We'll watch
out for an updated patchset to try.
On 02/10/15 03:53 PM, Dan Williams wrote:
Hmm, I didn't have peer-to-peer PCI-E in mind for this mechanism, but
the test report is welcome nonetheless. The definition of
On 02/10/15 03:53 PM, Dan Williams wrote:
Yes, this location for dev_pagemap will not work. I've since moved it
to a union with the lru list_head since ZONE_DEVICE pages memory
should always have an elevated page count and never land on a slab
allocator lru.
Oh, also, I was actually hoping
Hi Jon,
Thanks for the feedback. I'll send an updated patch in a moment.
On 04/06/16 09:40 AM, Jon Mason wrote:
> Nit, please add spaces around '*' (per checkpatch)
I'll change this, but I did run it through checkpatch and it did not
warn about this.
> Please explicitly point out that this is
Hey Rafael,
Awesome, this patch fixes the problem! Nice work.
Thanks,
Logan
On 12/06/16 08:31 AM, Rafael J. Wysocki wrote:
On Saturday, June 11, 2016 10:48:08 PM Logan Gunthorpe wrote:
Hey,
Hi,
On 11/06/16 07:05 PM, Rafael J. Wysocki wrote:
1) Commit ab76f7b4ab only extends the NX bit
Hey,
On 10/06/16 12:09 PM, Kees Cook wrote:
>> restore_code: 880157c3b000
>> jump_addr: 81446be0
>>
>>
>> diff --git a/arch/x86/power/hibernate_64.c b/arch/x86/power/hibernate_64.c
>> index 009947d..6efedb7 100644
>> --- a/arch/x86/power/hibernate_64.c
>> +++
On 10/06/16 04:29 PM, Rafael J. Wysocki wrote:
> OK, I have a theory, but I need a bit of help.
>
> This may be a dumb question, but I don't quite remember the answer readily.
>
> Given a physical address, how do I get the corresponding virtual one under
> the kernel identity mapping?
Is that
AM Rafael J. Wysocki wrote:
On Friday, June 10, 2016 04:28:01 PM Logan Gunthorpe wrote:
On 10/06/16 04:29 PM, Rafael J. Wysocki wrote:
OK, I have a theory, but I need a bit of help.
This may be a dumb question, but I don't quite remember the answer readily.
Given a physical address, how do I
Ok, I'll add a comment.
Logan
On 10/06/16 08:35 PM, Allen Hubbe wrote:
On Fri, Jun 10, 2016 at 6:54 PM, Logan Gunthorpe <log...@deltatee.com> wrote:
On hardware with 32 scratchpad registers the spad field in ntb tool
could chop off the end. The maximum buffer size is increased from
256
explicitly have to enable the link before using it?
Thanks,
Logan
On 10/06/16 08:27 PM, Allen Hubbe wrote:
On Fri, Jun 10, 2016 at 6:54 PM, Logan Gunthorpe <log...@deltatee.com> wrote:
In order to more successfully script with ntb_tool it's useful to
have a link file to check the link sta
The pp_debugfs_dir is already initialized by the module init function.
If it doesn't exist here, I think we should just return instead of
trying again. It's also worth noting, though it is probably no harm,
the code here does not check debugfs_initialized().
+static int __init tool_init(void)
Rafael J. Wysocki wrote:
On Friday, June 10, 2016 04:28:01 PM Logan Gunthorpe wrote:
On 10/06/16 04:29 PM, Rafael J. Wysocki wrote:
OK, I have a theory, but I need a bit of help.
This may be a dumb question, but I don't quite remember the answer readily.
Given a physical address, how do I get
Hey,
On 11/06/16 07:05 PM, Rafael J. Wysocki wrote:
1) Commit ab76f7b4ab only extends the NX bit between __ex_table and
rodata; which, by my understanding, shouldn't be used by anything. And
__ex_table and rodata are fixed by the kernel's binary so both symbols
should be the same in both the
On 14/06/16 09:45 AM, Allen Hubbe wrote:
>
> Feel free to disregard my suggestion above. I hope my comment has not cost
> you too much time.
>
> The way you have written it already, and used it in the self-test script is
> much more concise.
>
>>> + * root@self# echo > $DBG_DIR/link
>
>
On 14/06/16 09:47 AM, Allen Hubbe wrote:
> From: Logan Gunthorpe
>> This script automates testing doorbells, scratchpads and memory windows
>> for an NTB device. It can be run locally, with the NTB looped
>> back to the same host or use SSH to remotely co
On 14/06/16 08:16 AM, Shuah Khan wrote:
> On 06/14/2016 08:06 AM, Jon Mason wrote:
>> On Fri, Jun 10, 2016 at 6:54 PM, Logan Gunthorpe <log...@deltatee.com> wrote:
>>> This script automates testing doorbells, scratchpads and memory windows
>>> for an NTB device. It
On 14/06/16 01:33 PM, Allen Hubbe wrote:
>> diff --git a/drivers/ntb/test/ntb_tool.c b/drivers/ntb/test/ntb_tool.c
>> index cba31fd..9bebd0d 100644
>> --- a/drivers/ntb/test/ntb_tool.c
>> +++ b/drivers/ntb/test/ntb_tool.c
>> @@ -59,6 +59,13 @@
>> *
>> * Eg: check if clearing the doorbell
On 15/06/16 10:02 AM, Allen Hubbe wrote:
>> My understanding is that ntb_tool is really just a test client to verify
>> the API and the hardware. I personally would not recommend it for any
>> real applications. As such, I don't think this philosophical argument
>> really matches that goal.
>
>
On 14/06/16 03:46 PM, Allen Hubbe wrote:
> The ntb_tool is intended to be a simple low level access to the ntb.h api.
> As much as possible, I think ntb_tool should directly expose the ntb.h api
> through debugfs, and not invent higher level concepts.
I really think practical concerns should
,
Rafael
---
From: Rafael J. Wysocki <rafael.j.wyso...@intel.com>
Subject: [PATCH v2] x86/power/64: Fix kernel text mapping corruption during
image restoration
Logan Gunthorpe reports that hibernation stopped working reliably for
him after commit ab76f7b4ab23 (x86/mm: Set NX on gap between _
of the event. If there's
agreement on this I can re-spin it again.
Thanks,
Logan
On 15/06/16 03:33 PM, Jiang, Dave wrote:
> On Wed, 2016-06-15 at 15:26 -0600, Logan Gunthorpe wrote:
>> When the link goes down, the link_is_up flag did not return to
>> false. This could have caused some sub
On 15/06/16 03:49 PM, Allen Hubbe wrote:
>> +function link_test()
>> +{
>> +LOC=$1
>> +REM=$2
>> +EXP=0
>> +
>> +echo "Running link tests on: $(basename $LOC) / $(basename $REM)"
>> +
>> +write_file "N" "$LOC/link"
>> +write_file "N" "$LOC/link_event"
>
> If it fails to
On 15/06/16 04:17 PM, Allen Hubbe wrote:
> This test should fail on Intel RP/TB topology (two cpu sharing one ntb). The
> link state is the link state of the secondary side pcie bus connected to the
> secondary side cpu. The link must be up in order for the secondary side cpu
> to discover
Hey,
On 15/06/16 04:24 PM, Jiang, Dave wrote:
> On Wed, 2016-06-15 at 16:20 -0600, Logan Gunthorpe wrote:
>> Hey,
>>
>> Actually, I have to retract this patch. After some more thorough
>> testing
>> I'm finding an issue:
>>
>> When you remove an
Great! Thanks Jon.
Logan
On 26/06/16 05:29 PM, Jon Mason wrote:
> On Mon, Jun 20, 2016 at 01:15:03PM -0600, Logan Gunthorpe wrote:
>> Sorry, I thought this was done but I found one more minor issue with
>> these patches so I'm resubmitting them one last time. Besides this isus
Hey,
This version is working for me as well. Thanks.
Logan
On 27/06/16 08:24 AM, Rafael J. Wysocki wrote:
On Tuesday, June 21, 2016 11:04:41 AM Kees Cook wrote:
On Mon, Jun 20, 2016 at 9:35 PM, Logan Gunthorpe <log...@deltatee.com> wrote:
Hey Rafael,
This patch appears to be working
yso...@intel.com>
Logan Gunthorpe reports that hibernation stopped working reliably for
him after commit ab76f7b4ab23 (x86/mm: Set NX on gap between __ex_table
and rodata).
That turns out to be a consequence of a long-standing issue with the
64-bit image restoration code on x86,
om/~logang/panic.jpg
Logan
On 29/06/16 08:48 AM, Kees Cook wrote:
On Mon, Jun 27, 2016 at 4:33 PM, Logan Gunthorpe <log...@deltatee.com> wrote:
Hey,
This version is working for me as well. Thanks.
Logan
On 27/06/16 08:24 AM, Rafael J. Wysocki wrote:
On Tuesday, June 21, 2016 11:04:41 AM
On 29/06/16 08:55 PM, Rafael J. Wysocki wrote:
The only thing that comes to mind at this point is that TLBs should be flushed
after page tables changes, so please apply the appended and let me know
if you see this panic any more with it.
Ok, I'll build a new kernel tomorrow. But keep in
Cool, Thanks.
Let me know if you need anything from me.
Logan
On 01/02/17 01:08 PM, Jon Mason wrote:
> On Thu, Jan 26, 2017 at 3:00 PM, Logan Gunthorpe <log...@deltatee.com> wrote:
>> Hi,
>>
>> It's been a couple weeks... Any thoughts on this?
>
> My ap
On 31/01/17 10:26 AM, Greg Kroah-Hartman wrote:
> That's one big patch to review, would you want to do that?
Sorry, will do.
> Can you break it up into smaller parts? At least put the documentation
> separately, right?
Ha, funny. Last time I sent a patch someone asked for the documentation
/switchtec-user
[2] https://github.com/linux-nvme/nvme-cli
Signed-off-by: Logan Gunthorpe <log...@deltatee.com>
Signed-off-by: Stephen Bates <stephen.ba...@microsemi.com>
---
Documentation/ABI/testing/sysfs-class-switchtec | 96 ++
Documentation/ioctl/ioctl-number.txt|
of IOCTLs to the switchtec device
* A number of miscelaneous bug fixes
--
Logan Gunthorpe (1):
MicroSemi Switchtec management interface driver
Documentation/ABI/testing/sysfs-class-switchtec | 96 ++
Documentation/ioctl/ioctl-number.txt|1 +
Documentation/switchtec.txt
On 31/01/17 11:57 AM, Greg Kroah-Hartman wrote:
> Sorry, it was probably me :)
Nope, it was Christoph Hellwig. I don't mind changing it. It's just hard
to know what's expected all the time.
> Why do you need this? Wherever you put it, it should be built as part
> of the online kernel
On 31/01/17 10:49 AM, Jonathan Corbet wrote:
> The good news is that your switchtec.txt file is already 99% in the RST
> format, so there is little or nothing to do there.
>
> The bad news is that we don't quite have a place for it yet. This is
> really user-space developer documentation, and
On 01/02/17 05:10 AM, Emil Velikov wrote:
> You can keep it roughly as-is if you're ~reasonably certain one won't
> change it in the future.
I've made the change anyway. I think it's better now.
> Some teams frown upon adding new IOCTL(s) where existing ones can be
> made backward/forward
This patch introduces a couple of special IOCTLs which are provided to:
* Inform userspace of firmware partition locations
* Pass event counts and allow userspace to wait on events
* Translate between PFF numbers used by the switch to
port numbers.
Signed-off-by: Logan Gunthorpe <
This adds standard documentation for the sysfs switchtec attributes and
a RST formatted text file which documents the char device interface.
Jonathan Corbet has indicated he will move this to a new user-space
developer documentation book once it's created.
Signed-off-by: Logan Gunthorpe <
This patch adds a few read-only sysfs attributes which provide
some device information that is exposed from the devices. Primarily
component and device names and versions. These are documented in
Documentation/ABI/testing/sysfs-class-switchtec.
Signed-off-by: Logan Gunthorpe <log...@deltatee.
atures may be added in the future.
[1] https://github.com/sbates130272/switchtec-user
[2] https://github.com/linux-nvme/nvme-cli
Signed-off-by: Logan Gunthorpe <log...@deltatee.com>
Signed-off-by: Stephen Bates <stephen.ba...@microsemi.com>
---
MAINTAINERS|8
://www.spinics.net/lists/linux-pci/msg56897.html
[2] https://github.com/sbates130272/switchtec-user
--
Logan Gunthorpe (4):
MicroSemi Switchtec management interface driver
switchtec: Add user interface documentation
switchtec: Add sysfs attributes to the Switchtec driver
switchtec: Add IOCTLs
Hi Emil,
Thanks for the feedback.
On 31/01/17 01:48 PM, Emil Velikov wrote:
>> +struct switchtec_ioctl_fw_info {
>> + __u32 flash_length;
>> +
>> + struct {
>> + __u32 address;
>> + __u32 length;
>> + __u32 active;
> Something to keep in
Hi,
It's been a couple weeks... Any thoughts on this?
Thanks,
Logan
On 10/01/17 05:33 PM, Logan Gunthorpe wrote:
> Hi,
>
> Here's an updated version of the style fixes patchset. The differences
> from v1 are:
>
> 1) Rebased onto Jon Mason's current NTB branch
>
> 2
concerns you
may have, just please let us know.
Thanks,
Logan
On 02/02/17 11:05 AM, Logan Gunthorpe wrote:
> Changes since v1:
>
> * Rebased onto 4.10-rc6 (cleanly)
> * Split the patch into a few more easily digestible patches (as
> suggested by Greg Kroah-Hartman)
> *
On 23/02/17 03:43 PM, Bjorn Helgaas wrote:
> This path seems a little generic. I don't see other cases where a
> product brand name ("Switchtec") appears at the top level of
> /sys/class/...
Ok, well we are certainly open to suggestions, but there isn't really a
generic version of this device
03:14 PM, Bjorn Helgaas wrote:
> On Thu, Feb 23, 2017 at 01:36:51PM -0700, Logan Gunthorpe wrote:
>> Hello,
>>
>> We're still waiting on any kind of response from Bjorn. (If you're
>> listening please say something!)
>>
>> Does anyone have any sugge
On 23/02/17 01:51 PM, Sinan Kaya wrote:
> You'll want to be careful during the merge window (these days) as the
> maintainer is usually busy with code delivery. You can't rush your code in at
> the last minute.
Thanks for the advice, we will continue to wait.
However, I would say we've been
another route? In the end, it's
just a fairly basic driver and doesn't touch any core PCI functionality
and we've had a fair amount of review from other kernel contributors,
all of which we've addressed.
Thanks,
Logan
On 17/02/17 01:36 PM, Logan Gunthorpe wrote:
> Hi Bjorn,
>
> Can
This patch introduces a couple of special IOCTLs which are provided to:
* Inform userspace of firmware partition locations
* Pass event counts and allow userspace to wait on events
* Translate between PFF numbers used by the switch to
port numbers.
Signed-off-by: Logan Gunthorpe <
a
smooth review process.
The patch is based off of the v4.10-rc6 release.
Thanks for your review,
Logan
[1] https://www.spinics.net/lists/linux-pci/msg56897.html
[2] https://github.com/sbates130272/switchtec-user
--
Logan Gunthorpe (4):
MicroSemi Switchtec management interface driver
switchtec
This patch adds a few read-only sysfs attributes which provide
some device information that is exposed from the devices. Primarily
component and device names and versions. These are documented in
Documentation/ABI/testing/sysfs-class-switchtec.
Signed-off-by: Logan Gunthorpe <log...@deltatee.
atures may be added in the future.
[1] https://github.com/sbates130272/switchtec-user
[2] https://github.com/linux-nvme/nvme-cli
Signed-off-by: Logan Gunthorpe <log...@deltatee.com>
Signed-off-by: Stephen Bates <stephen.ba...@microsemi.com>
Tested-by: Krishna Dhulipala <krish...@fb.co
This adds standard documentation for the sysfs switchtec attributes and
a RST formatted text file which documents the char device interface.
Jonathan Corbet has indicated he will move this to a new user-space
developer documentation book once it's created.
Signed-off-by: Logan Gunthorpe <
Hey Bjorn,
Thanks for the thorough review. It definitely helped a lot to make the
code as good as it can be.
I've made all of the changes you suggested. I'm just going to do a bit
more testing and then post a v4. See my responses to all of your
feedback bellow.
Logan
On 23/02/17 05:35 PM,
This patch introduces a couple of special IOCTLs which are provided to:
* Inform userspace of firmware partition locations
* Pass event counts and allow userspace to wait on events
* Translate between PFF numbers used by the switch to
port numbers.
Signed-off-by: Logan Gunthorpe <
to see this work included in either 4.11 or 4.12 assuming a
smooth review process.
The patch is based off of the v4.10-rc6 release.
Thanks for your review,
Logan
[1] https://www.spinics.net/lists/linux-pci/msg56897.html
[2] https://github.com/sbates130272/switchtec-user
Logan Gunthorpe (4
This patch adds a few read-only sysfs attributes which provide
some device information that is exposed from the devices. Primarily
component and device names and versions. These are documented in
Documentation/ABI/testing/sysfs-class-switchtec.
Signed-off-by: Logan Gunthorpe <log...@deltatee.
atures may be added in the future.
[1] https://github.com/sbates130272/switchtec-user
[2] https://github.com/linux-nvme/nvme-cli
Signed-off-by: Logan Gunthorpe <log...@deltatee.com>
Signed-off-by: Stephen Bates <stephen.ba...@microsemi.com>
Tested-by: Krishna Dhulipala <krish...@fb.co
This adds standard documentation for the sysfs switchtec attributes and
a RST formatted text file which documents the char device interface.
Jonathan Corbet has indicated he will move this to a new user-space
developer documentation book once it's created.
Signed-off-by: Logan Gunthorpe <
numerous examples are fixed up.
Thanks,
Logan
[1] https://lkml.org/lkml/2017/2/10/589
[2] https://lkml.org/lkml/2017/2/13/700
On 10/02/17 10:57 AM, Logan Gunthorpe wrote:
> Per a suggestion from Greg Kroah-Hartman [1], don't set the cdev's
> kobject parent. This allows us
On 19/02/17 02:43 PM, Dan Williams wrote:
> Is this race present for all file operations? I've only seen it with
> mmap() and late faults. So if these other drivers do not support mmap
> it's not clear they can trigger the failure.
I don't see how it's related to mmap only. I think there's a
On 11/02/17 11:27 AM, Dan Williams wrote:
> Why, when the lifetime of the cdev is already correct?
Well, it's only correct if you use the kobj parent trick which Greg is
arguing against. As someone reviewing/copying code that trick is
unclear, undocumented and it looks rather odd messing with
Hey,
I like the interface. It's just Greg that needs to comment on whether
using the kobj.parent for this purpose is actually sane. That was his
argument from the beginning.
Logan
On 13/02/17 01:47 PM, Dan Williams wrote:
> On Sat, Feb 11, 2017 at 9:42 PM, Logan Gunthorpe <log...@deltat
On 11/02/17 11:58 AM, Dan Williams wrote:
> Also when using an embedded cdev how would you recommend avoiding this
> problem?
I don't know. Hopefully, Greg has a good idea. But it sounds like a
general problem that a lot of cdev's actually suffer from without
realizing. Perhaps we need a more
Hey Greg,
Thanks so much for the review.
On 10/02/17 07:51 AM, Greg Kroah-Hartman wrote:
> On Thu, Feb 02, 2017 at 11:06:00AM -0700, Logan Gunthorpe wrote:
>> +cdev = >cdev;
>> +cdev_init(cdev, _fops);
>> +cdev->owner = THIS_MODULE;
>> +cdev->
://lkml.org/lkml/2017/2/10/370
Signed-off-by: Logan Gunthorpe <log...@deltatee.com>
---
drivers/dax/dax.c | 6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/drivers/dax/dax.c b/drivers/dax/dax.c
index ed758b7..24e53b7 100644
--- a/drivers/dax/dax.c
+++ b/drivers/dax
Hey,
Also on the subject of very minor fixes: I noticed drivers/dax is not in
the maintainers file. I just assumed the nvdimm list should have been
included with those from get_maintainers.
Thanks,
Logan
On 10/02/17 12:19 PM, Logan Gunthorpe wrote:
> I copied this code and per feedback f
Per a suggestion from Greg Kroah-Hartman [1], don't set the cdev's
kobject parent. This allows us to use device_register instead of init
and add.
[1] https://lkml.org/lkml/2017/2/10/370
---
drivers/pci/switch/switchtec.c | 15 +++
1 file changed, 7 insertions(+), 8 deletions(-)
diff
On 10/02/17 10:09 AM, Greg Kroah-Hartman wrote:
> Sure, or just wait for these to be applied to the PCI tree and then send
> a follow-on patch. It's up to Bjorn really, as to what he wants.
Ok, I sent a working follow-on patch to this thread.
@Bjorn: I'm happy to send the patches however you
On 10/02/17 09:55 AM, Greg Kroah-Hartman wrote:
> Yes, but try it yourself to verify it really is correct :)
Yes, of course... turns out it wasn't. I accidentally refereed to dev
before I assigned it. I had mainly just wanted your feedback to ensure
that switching to device_register made sense.
On 11/02/17 01:56 AM, Dan Williams wrote:
When the device is unregistered it invalidates all existing mappings,
but the driver may continue to service vm fault requests until the
final put of the cdev. Until that time the fault handler needs to be
able to check dax_dev->alive. Since the final
This patch adds a few read-only sysfs attributes which provide
some device information that is exposed from the devices. Primarily
component and device names and versions. These are documented in
Documentation/ABI/testing/sysfs-class-switchtec.
Signed-off-by: Logan Gunthorpe <log...@deltatee.
[2] https://github.com/sbates130272/switchtec-user
Logan Gunthorpe (4):
MicroSemi Switchtec management interface driver
switchtec: Add user interface documentation
switchtec: Add sysfs attributes to the Switchtec driver
switchtec: Add IOCTLs to the Switchtec driver
Documentation/ABI
atures may be added in the future.
[1] https://github.com/sbates130272/switchtec-user
[2] https://github.com/linux-nvme/nvme-cli
Signed-off-by: Logan Gunthorpe <log...@deltatee.com>
Signed-off-by: Stephen Bates <stephen.ba...@microsemi.com>
Tested-by: Krishna Dhulipala <krish...@fb.co
This patch introduces a couple of special IOCTLs which are provided to:
* Inform userspace of firmware partition locations
* Pass event counts and allow userspace to wait on events
* Translate between PFF numbers used by the switch to
port numbers.
Signed-off-by: Logan Gunthorpe <
This adds standard documentation for the sysfs switchtec attributes and
a RST formatted text file which documents the char device interface.
Jonathan Corbet has indicated he will move this to a new user-space
developer documentation book once it's created.
Signed-off-by: Logan Gunthorpe <
> This driver doesn't have anything to do with the PCI core, other than
> using the pci_register_driver() interface (just like all other drivers
> for PCI-connected devices), so drivers/pci doesn't really feel like
> the right place for it. Putting it in drivers/pci leads to the sort
> of
On 01/03/17 05:32 PM, Bjorn Helgaas wrote:
> It's not a perfect fit in drivers/pci because it's not bus
> infrastructure and I don't want to be the default maintainer of it,
> but I agree there's not really an alternative that's clearly better,
> so let's leave it where it is for now.
Sounds
On 01/03/17 04:58 PM, Jason Gunthorpe wrote:
> On Wed, Mar 01, 2017 at 03:49:04PM -0700, Logan Gunthorpe wrote:
>
>> Seems to me like an elegant solution would be to implement a 'cdev_kill'
>> function which could kill all the processes using a cdev. Thus, during
>> a
On 01/03/17 05:23 PM, Logan Gunthorpe wrote:
> Because of how poll works, I don't see how I can just hold a semaphore
> inside every fops call like the tpm code does.
On 01/03/17 04:58 PM, Jason Gunthorpe wrote:
> Both infiniband and TPM have the 'detach' flavour of unplug where t
On 01/03/17 03:26 PM, Keith Busch wrote:
> I think this is from using the managed device resource API to request the
> irq actions. The scope of the resource used to be tied to the pci_dev's
> dev, but now it's the new switchec class dev, which has a different
> lifetime while open references
On 01/03/17 02:41 PM, Bjorn Helgaas wrote:
> I don't think this is indicating a bug in the PCI core (although I do
> think a BUG_ON() here is an excessive response). I think it's an
> indication that the driver didn't disconnect its ISR. Without more
> details of the failure it's hard to tell
) and unless someone can describe how it's wrong or a better
solution I'd rather see it merged as is. If and when a better approach
arrives I'd happily patch it to improve the situation.
Logan
On 01/03/17 03:24 PM, Logan Gunthorpe wrote:
>
>
> On 01/03/17 02:41 PM, Bjorn Helgaas wrote:
&
On 01/03/17 03:59 PM, Keith Busch wrote:
> Okay, I see. Was mistakenliy looking at v4. The v5 looks right.
Great! Thanks for reviewing that for me.
Logan
Hi Christoph,
Thanks so much for the detailed review of the code! Even though by the
sounds of things we will be moving to device dax and most of this is
moot. Still, it's great to get some feedback and learn a few things.
I've given some responses below.
On 28/10/16 12:45 AM, Christoph Hellwig
On 25/11/16 06:06 AM, Christian König wrote:
> Well Serguei send me a couple of documents about QPI when we started to
> discuss this internally as well and that's exactly one of the cases I
> had in mind when writing this.
>
> If I understood it correctly for such systems P2P is technical
On 23/11/16 02:55 PM, Jason Gunthorpe wrote:
>>> Only ODP hardware allows changing the DMA address on the fly, and it
>>> works at the page table level. We do not need special handling for
>>> RDMA.
>>
>> I am aware of ODP but, noted by others, it doesn't provide a general
>> solution to the
Hey,
On 22/11/16 11:59 AM, Serguei Sagalovitch wrote:
> - How well we will be able to handle case when we need to "move"/"evict"
>memory/data to the new location so CPU pointer should point to the
> new physical location/address
> (and may be not in PCI device memory at all)?
IMO any
On 23/11/16 01:33 PM, Jason Gunthorpe wrote:
> On Wed, Nov 23, 2016 at 02:58:38PM -0500, Serguei Sagalovitch wrote:
>
>>We do not want to have "highly" dynamic translation due to
>>performance cost. We need to support "overcommit" but would
>>like to minimize impact. To support
On 28/11/16 09:57 AM, Jason Gunthorpe wrote:
>> On PeerDirect, we have some kind of a middle-ground solution for pinning
>> GPU memory. We create a non-ODP MR pointing to VRAM but rely on
>> user-space and the GPU not to migrate it. If they do, the MR gets
>> destroyed immediately.
>
> That
On 28/11/16 12:35 PM, Serguei Sagalovitch wrote:
> As soon as PeerDirect mapping is called then GPU must not "move" the
> such memory. It is by PeerDirect design. It is similar how it is works
> with system memory and RDMA MR: when "get_user_pages" is called then the
> memory is pinned.
We
Hey,
On 24/11/16 02:45 AM, Christian König wrote:
> E.g. it can happen that PCI device A exports it's BAR using ZONE_DEVICE.
> Not PCI device B (a SATA device) can directly read/write to it because
> it is on the same bus segment, but PCI device C (a network card for
> example) can't because it
On 24/11/16 09:42 AM, Jason Gunthorpe wrote:
> There are three cases to worry about:
> - Coherent long lived page table mirroring (RDMA ODP MR)
> - Non-coherent long lived page table mirroring (RDMA MR)
> - Short lived DMA mapping (everything else)
>
> Like you say below we have to handle
Hey,
On 06/12/16 09:38 AM, Jason Gunthorpe wrote:
>>> I'm not opposed to mapping /dev/nvmeX. However, the lookup is trivial
>>> to accomplish in sysfs through /sys/dev/char to find the sysfs path of the
>>> device-dax instance under the nvme device, or if you already have the nvme
>>> sysfs path
and
will be fleshed out assuming there are no serious objections to our
userspace interface. In the end, the tool will be released with a
GPL license.
The patch is based off of the v4.9 release.
Thanks for your review,
Logan
[1] https://github.com/sbates130272/switchtec-user
Logan Gunthorpe (1
This tool takes
inspiration (and borrows some code) from nvme-cli [2].
[1] https://github.com/sbates130272/switchtec-user
[2] https://github.com/linux-nvme/nvme-cli
Signed-off-by: Logan Gunthorpe <log...@deltatee.com>
Signed-off-by: Stephen Bates <stephen.ba...@microsemi.com>
---
Docum
As per a comments in [1] by Greg Kroah-Hartman, the ndev_* macros should
be cleaned up. This makes it more clear what's actually going on when
reading the code.
[1] http://www.spinics.net/lists/linux-pci/msg56904.html
Signed-off-by: Logan Gunthorpe <log...@deltatee.com>
---
drivers/ntb/hw
As per a comments in [1] by Greg Kroah-Hartman, the ndev_* macros should
be cleaned up. This makes it more clear what's actually going on when
reading the code.
[1] http://www.spinics.net/lists/linux-pci/msg56904.html
Signed-off-by: Logan Gunthorpe <log...@deltatee.com>
---
drivers/ntb/
1 - 100 of 2689 matches
Mail list logo
