Re: [PATCH v5 0/4] New Microsemi PCI Switch Management Driver

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 the > user is

Re: [PATCH v5 0/4] New Microsemi PCI Switch Management Driver

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 >> an unbind, a driver could

[PATCH 05/20] arm64: rename COMPAT to AARCH32_EL0 in Kconfig

From: Andrew Pinski In this patchset ILP32 ABI support is added. Additionally to AARCH32, which is binary-compatible with ARM, ILP32 is (mostly) ABI-compatible. >From now, AARCH32_EL0 (former COMPAT) config option means the support of AARCH32 userspace, ARM64_ILP32 -

Re: [PATCH v5 0/4] New Microsemi PCI Switch Management Driver

On Tue, Feb 28, 2017 at 10:11:56AM -0700, Logan Gunthorpe wrote: > > > 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

Re: [PATCH v5 0/4] New Microsemi PCI Switch Management Driver

On Wed, Mar 01, 2017 at 05:23:38PM -0700, Logan Gunthorpe wrote: > > That could help, but this would mean cdev would have to insert a shim > > to grab locks around the various file ops. > > Hmm, I was hoping something more along the lines of actually killing the > processes instead of just

Re: [PATCH v5 0/4] New Microsemi PCI Switch Management Driver

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

Re: [PATCH v5 0/4] New Microsemi PCI Switch Management Driver

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 > an unbind, a driver could call it and be sure that there are no users > left and

Re: [PATCH v5 0/4] New Microsemi PCI Switch Management Driver

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 -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More

Re: [PATCH v5 0/4] New Microsemi PCI Switch Management Driver

Hey, 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 an unbind, a driver could call it and be sure that there are no users left and it can safely allow the devres unwind to continue. Then no difficult

Re: [PATCH v5 0/4] New Microsemi PCI Switch Management Driver

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

Re: [PATCH v5 0/4] New Microsemi PCI Switch Management Driver

On Wed, Mar 01, 2017 at 03:37:03PM -0700, Logan Gunthorpe wrote: > 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

Re: [PATCH v5 0/4] New Microsemi PCI Switch Management Driver

On Wed, Mar 01, 2017 at 03:41:20PM -0600, Bjorn Helgaas wrote: > On Sat, Feb 25, 2017 at 11:53:13PM -0700, Logan Gunthorpe wrote: > > Changes since v4: > > > > * Turns out pushing the pci release code into the device release > > function didn't work as I would have liked. If you try to unbind

Re: [PATCH v5 0/4] New Microsemi PCI Switch Management Driver

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

[PATCH 01/20] compat ABI: use non-compat openat and open_by_handle_at variants

The only difference is that non-compat version forces O_LARGEFILE, and it should be the default behaviour for all architectures, as we don't support 32-bit off_t. The only exception is tile32, that continues with compat version of syscalls. Signed-off-by: Yury Norov

[PATCH 04/20] arm64: ilp32: add documentation on the ILP32 ABI for ARM64

Based on Andrew Pinski's patch-series. Signed-off-by: Yury Norov --- Documentation/arm64/ilp32.txt | 45 +++ 1 file changed, 45 insertions(+) create mode 100644 Documentation/arm64/ilp32.txt diff --git

Re: [PATCH v5 0/4] New Microsemi PCI Switch Management Driver

On Sat, Feb 25, 2017 at 11:53:13PM -0700, Logan Gunthorpe wrote: > Changes since v4: > > * Turns out pushing the pci release code into the device release > function didn't work as I would have liked. If you try to unbind the > device with an instance open, then you hit a kernel bug at >

[PATCH 03/20] asm-generic: Drop getrlimit and setrlimit syscalls from default list

The newer prlimit64 syscall provides all the functionality provided by the getrlimit and setrlimit syscalls and adds the pid of target process, so future architectures won't need to include getrlimit and setrlimit. Therefore drop getrlimit and setrlimit syscalls from the generic syscall list

[PATCH 16/20] arm64: signal32: move ilp32 and aarch32 common code to separated file

Signed-off-by: Yury Norov --- arch/arm64/include/asm/signal32.h| 3 + arch/arm64/include/asm/signal32_common.h | 27 +++ arch/arm64/kernel/Makefile | 2 +- arch/arm64/kernel/signal32.c | 107

[PATCH 07/20] arm64:uapi: set __BITS_PER_LONG correctly for ILP32 and LP64

From: Andrew Pinski Define __BITS_PER_LONG depending on the ABI used (i.e. check whether __ILP32__ or __LP64__ is defined). This is necessary for glibc to determine the appropriate type definitions for the system call interface. Signed-off-by: Andrew Pinski

[PATCH 09/20] arm64: introduce is_a32_task and is_a32_thread (for AArch32 compat)

Based on patch of Andrew Pinski. This patch introduces is_a32_compat_task and is_a32_thread so it is easier to say this is a a32 specific thread or a generic compat thread/task. Corresponding functions are located in to avoid mess in headers. Some files include both and , and this is wrong

[PATCH 08/20] thread: move thread bits accessors to separated file

They may be accessed from low-level code, so isolating is a measure to avoid circular dependencies in header files. The exact reason for circular dependency is WARN_ON() macro added in patch edd63a27 "set_restore_sigmask() is never called without SIGPENDING (and never should be)" Signed-off-by:

[PATCH 10/20] arm64: ilp32: add is_ilp32_compat_{task,thread} and TIF_32BIT_AARCH64

ILP32 tasks are needed to be distinguished from lp64 and aarch32. This patch adds helper functions is_ilp32_compat_{task,thread} and thread flag TIF_32BIT_AARCH64 to address it. This is a preparation for following patches in ilp32 patchset. For consistency, SET_PERSONALITY is changed here

Re: [RFC PATCH v4 28/28] x86: Add support to make use of Secure Memory Encryption

On Thu, Feb 16, 2017 at 09:48:25AM -0600, Tom Lendacky wrote: > This patch adds the support to check if SME has been enabled and if > memory encryption should be activated (checking of command line option > based on the configuration of the default state). If memory encryption > is to be

[PATCH 11/20] arm64: introduce binfmt_elf32.c

As we support more than one compat formats, it looks more reasonable to not use fs/compat_binfmt.c. Custom binfmt_elf32.c allows to move aarch32 specific definitions there and make code more maintainable and readable. Signed-off-by: Yury Norov --- arch/arm64/Kconfig

[PATCH 13/20] arm64: ilp32: share aarch32 syscall handlers

off_t is passed in register pair just like in aarch32. In this patch corresponding aarch32 handlers are shared to ilp32 code. Signed-off-by: Yury Norov --- arch/arm64/kernel/Makefile | 1 + arch/arm64/kernel/entry32.S| 80

[PATCH 19/20] arm64:ilp32: add vdso-ilp32 and use for signal return

From: Philipp Tomsich ILP32 VDSO exports next symbols: __kernel_rt_sigreturn; __kernel_gettimeofday; __kernel_clock_gettime; __kernel_clock_getres. What shared object to use, kernel selects depending on result of is_ilp32_compat_task() in

[PATCH 14/20] arm64: ilp32: add sys_ilp32.c and a separate table (in entry.S) to use it

From: Andrew Pinski Add a separate syscall-table for ILP32, which dispatches either to native LP64 system call implementation or to compat-syscalls, as appropriate. Signed-off-by: Andrew Pinski Signed-off-by: Yury Norov

[PATCH 20/20] arm64:ilp32: add ARM64_ILP32 to Kconfig

From: Andrew Pinski This patch adds the config option for ILP32. Signed-off-by: Andrew Pinski Signed-off-by: Philipp Tomsich Signed-off-by: Christoph Muellner

[PATCH 18/20] arm64: ptrace: handle ptrace_request differently for aarch32 and ilp32

ILP32 has context-related structures different from both aarch32 and aarch64/lp64. In this patch compat_arch_ptrace() renamed to compat_a32_ptrace(), and compat_arch_ptrace() only makes choice between compat_a32_ptrace() and new compat_ilp32_ptrace() handler. compat_ilp32_ptrace() calls generic

[PATCH 17/20] arm64: ilp32: introduce ilp32-specific handlers for sigframe and ucontext

From: Andrew Pinski ILP32 uses AARCH32 compat structures and syscall handlers for signals. But ILP32 struct rt_sigframe and ucontext differs from both LP64 and AARCH32. So some specific mechanism is needed to take care of it. Signed-off-by: Andrew Pinski

[PATCH 15/20] arm64: signal: share lp64 signal routines to ilp32

After that, it will be possible to reuse it in ilp32. Signed-off-by: Yury Norov Signed-off-by: Bamvor Jian Zhang --- arch/arm64/include/asm/signal_common.h | 33 arch/arm64/kernel/signal.c | 93

[PATCH 12/20] arm64: ilp32: introduce binfmt_ilp32.c

Like binfmt_elf32.c, binfmt_ilp32.c is needed to handle ILP32 binaries Signed-off-by: Yury Norov Signed-off-by: Bamvor Jian Zhang --- arch/arm64/kernel/Makefile | 1 + arch/arm64/kernel/binfmt_ilp32.c | 85

[PATCH 06/20] arm64: ensure the kernel is compiled for LP64

From: Andrew Pinski The kernel needs to be compiled as a LP64 binary for ARM64, even when using a compiler that defaults to code-generation for the ILP32 ABI. Consequently, we need to explicitly pass '-mabi=lp64' (supported on gcc-4.9 and newer). Signed-off-by: Andrew Pinski

[PATCH v7 resend 00/20] ILP32 for ARM64

and GLIBC trees: https://github.com/norov/linux/tree/ilp32-20170301 https://github.com/norov/glibc/tree/dev9 (GLIBC patches are managed by Steve Ellcey, so my tree is only for reference.) Changes: v3: https://lkml.org/lkml/2014/9/3/704 v4: https://lkml.org/lkml/2015/4/13/691 v5: https://lkml.org/lkml

Re: [RFC PATCH v4 00/28] x86: Secure Memory Encryption (AMD)

On 3/1/2017 3:17 AM, Dave Young wrote: Hi Tom, Hi Dave, ... SNIP ... - Added support for (re)booting with kexec Could you please add kexec list in cc when you updating the patches so that kexec/kdump people do not miss them? Sorry about that, I'll be sure to add it to the cc list.

Re: [RFC PATCH v4 27/28] x86: Add support to encrypt the kernel in-place

On Thu, Feb 16, 2017 at 09:48:08AM -0600, Tom Lendacky wrote: > This patch adds the support to encrypt the kernel in-place. This is > done by creating new page mappings for the kernel - a decrypted > write-protected mapping and an encrypted mapping. The kernel is encyrpted s/encyrpted/encrypted/

Re: [PATCH 6/6] drm/doc: atomic overview, with graph

Daniel Vetter writes: > I've spent quite some time trying to beat DOT into submission, this is the > best I can do. The FIXME really is just a hint for someone with more clue > to maybe make it better, or if not possible at all, what would look better > when doing a proper

Re: [PATCH] drm/doc: atomic overview, with graph

Daniel Vetter writes: > I want to split up a few more things and document some details better > (like how exactly to subclass drm_atomic_state). And maybe also split > up the helpers a bit per-topic, but this should be a ok-ish start for > better atomic overview. > > One

Re: [RFC PATCH v4 21/28] x86: Check for memory encryption on the APs

On Tue, Feb 28, 2017 at 05:28:48PM -0600, Tom Lendacky wrote: > That's a good idea, I'll expand on that. I probably won't be that > direct in my comment though :) You either haven't dealt with firmware long enough or you're much better person than me. :-))) -- Regards/Gruss, Boris. Good

Re: [PATCH] drm/doc: diagram for mode objects and properties

Daniel Vetter writes: > Resulted in confusion a few times in the past. > Reviewed-by: Gabriel Krisman Bertazi -- Gabriel Krisman Bertazi -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to

Re: [PATCH 3/6] drm/doc: Add KMS overview graphs

Daniel Vetter writes: > Oh, the shiny and pretties! > Very nice! Reviewed-by: Gabriel Krisman Bertazi -- Gabriel Krisman Bertazi -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to

Re: [RFC PATCH v4 26/28] x86: Allow kexec to be used with SME

+kexec list On 2/28/2017 4:35 AM, Borislav Petkov wrote: On Thu, Feb 16, 2017 at 09:47:55AM -0600, Tom Lendacky wrote: Provide support so that kexec can be used to boot a kernel when SME is enabled. Support is needed to allocate pages for kexec without encryption. This is needed in order to

[PATCH] pcieaer doc: update the link

The original link is empty, replace it. Signed-off-by: Cao jin --- The new link is the only one I can find in kernel.org. Documentation/PCI/pcieaer-howto.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/PCI/pcieaer-howto.txt

Re: [RFC PATCH v4 19/28] swiotlb: Add warnings for use of bounce buffers with SME

On Tue, Feb 28, 2017 at 05:19:51PM -0600, Tom Lendacky wrote: > Device drivers don't supply set_dma_mask() since that is part of the > dma_map_ops structure. The fm10k_pf.c file function is unrelated to this > (it's part of an internal driver structure). The dma_map_ops structure > is setup by the

Re: [PATCH 6/6] drm/doc: atomic overview, with graph

On Tue, Feb 28, 2017 at 03:48:47PM -0800, Eric Anholt wrote: > Daniel Vetter writes: > > > I want to split up a few more things and document some details better > > (like how exactly to subclass drm_atomic_state). And maybe also split > > up the helpers a bit per-topic,

Re: [RFC PATCH v4 26/28] x86: Allow kexec to be used with SME

Hi Tom, On 02/17/17 at 10:43am, Tom Lendacky wrote: > On 2/17/2017 9:57 AM, Konrad Rzeszutek Wilk wrote: > > On Thu, Feb 16, 2017 at 09:47:55AM -0600, Tom Lendacky wrote: > > > Provide support so that kexec can be used to boot a kernel when SME is > > > enabled. > > > > Is the point of kexec and

Re: [RFC PATCH v4 26/28] x86: Allow kexec to be used with SME

Add kexec list.. On 03/01/17 at 05:25pm, Dave Young wrote: > Hi Tom, > > On 02/17/17 at 10:43am, Tom Lendacky wrote: > > On 2/17/2017 9:57 AM, Konrad Rzeszutek Wilk wrote: > > > On Thu, Feb 16, 2017 at 09:47:55AM -0600, Tom Lendacky wrote: > > > > Provide support so that kexec can be used to

Re: [RFC PATCH v4 00/28] x86: Secure Memory Encryption (AMD)

Hi Tom, On 02/16/17 at 09:41am, Tom Lendacky wrote: > This RFC patch series provides support for AMD's new Secure Memory > Encryption (SME) feature. > > SME can be used to mark individual pages of memory as encrypted through the > page tables. A page of memory that is marked encrypted will be

[PATCH] drm/doc: diagram for mode objects and properties

Resulted in confusion a few times in the past. v2: Spelling fix (Eric). Cc: Eric Anholt Acked-by: Eric Anholt Cc: Laurent Pinchart Cc: Manasi Navare Signed-off-by: Daniel Vetter

[PATCH] drm/doc: atomic overview, with graph

I want to split up a few more things and document some details better (like how exactly to subclass drm_atomic_state). And maybe also split up the helpers a bit per-topic, but this should be a ok-ish start for better atomic overview. One thing I failed at is getting DOT to layout the overview