Re: [PATCH v1 00/10] mm: online/offline 4MB chunks controlled by device driver

ed fixes. >> >> == >> >> I am right now working on a paravirtualized memory device ("virtio-mem"). >> These devices control a memory region and the amount of memory available >> via it. Memory will not be indicated/added/onlined via ACPI and frien

Re: [PATCH v1 00/10] mm: online/offline 4MB chunks controlled by device driver

le > via it. Memory will not be indicated/added/onlined via ACPI and friends, > the device driver is responsible for it. > > When the device driver starts up, it will add and online the requested > amount of memory from its assigned physical memory region. On request, it > can add (o

[PATCH v1 00/10] mm: online/offline 4MB chunks controlled by device driver

ilable via it. Memory will not be indicated/added/onlined via ACPI and friends, the device driver is responsible for it. When the device driver starts up, it will add and online the requested amount of memory from its assigned physical memory region. On request, it can add (online) either more mem

[PATCH v4 00/10] PECI device driver introduction

Introduction of the Platform Environment Control Interface (PECI) bus device driver. PECI is a one-wire bus interface that provides a communication channel between an Intel processor and chipset components to external monitoring or control devices. PECI is designed to support the following

Re: [PATCH v5 04/13] s390: vfio-ap: base implementation of VFIO AP device driver

On 05/16/2018 04:21 AM, Pierre Morel wrote: On 07/05/2018 17:11, Tony Krowiak wrote: Introduces a new AP device driver. This device driver is built on the VFIO mediated device framework. The framework provides sysfs interfaces that facilitate passthrough access by guests to devices installed on

Re: [PATCH v5 04/13] s390: vfio-ap: base implementation of VFIO AP device driver

On 05/16/2018 04:21 AM, Pierre Morel wrote: On 07/05/2018 17:11, Tony Krowiak wrote: Introduces a new AP device driver. This device driver is built on the VFIO mediated device framework. The framework provides sysfs interfaces that facilitate passthrough access by guests to devices installed on

Re: [PATCH v5 04/13] s390: vfio-ap: base implementation of VFIO AP device driver

On 07/05/2018 17:11, Tony Krowiak wrote: Introduces a new AP device driver. This device driver is built on the VFIO mediated device framework. The framework provides sysfs interfaces that facilitate passthrough access by guests to devices installed on the linux host. ...snip... +static int

Re: [PATCH RCFv2 0/7] mm: online/offline 4MB chunks controlled by device driver

On 30.04.2018 11:42, David Hildenbrand wrote: > I am right now working on a paravirtualized memory device ("virtio-mem"). > These devices control a memory region and the amount of memory available > via it. Memory will not be indicated/added/onlined via ACPI and friends, >

[PATCH v5 04/13] s390: vfio-ap: base implementation of VFIO AP device driver

Introduces a new AP device driver. This device driver is built on the VFIO mediated device framework. The framework provides sysfs interfaces that facilitate passthrough access by guests to devices installed on the linux host. The VFIO AP device driver will serve two purposes: 1. Provide the

[PATCH v5 12/28] fpga: add FPGA DFL PCIe device driver

FPGA_DFL_PCI + tristate "FPGA Device Feature List (DFL) PCIe Device Driver" + depends on PCI && FPGA_DFL + help + Select this option to enable PCIe driver for PCIe based + Field-Programmable Gate Array (FPGA) solutions which implemented + the D

[PATCH RCFv2 0/7] mm: online/offline 4MB chunks controlled by device driver

I am right now working on a paravirtualized memory device ("virtio-mem"). These devices control a memory region and the amount of memory available via it. Memory will not be indicated/added/onlined via ACPI and friends, the device driver is responsible for it. When the device driver sta

Re: [PATCH v6 08/17] media: rkisp1: add capture device driver

Hi Jacob, On Thu, Mar 8, 2018 at 6:49 PM Jacob Chen wrote: > From: Jacob Chen > This is the capture device interface driver that provides the v4l2 > user interface. Frames can be received from ISP1. Thanks for the patch. Please find my comment inline. [snip] > +static int > +rkisp1_start_str

[PATCH v4 06/15] s390: vfio-ap: base implementation of VFIO AP device driver

Introduces a new AP device driver. This device driver is built on the VFIO mediated device framework. The framework provides sysfs interfaces that facilitate passthrough access by guests to devices installed on the linux host. The VFIO AP device driver will serve two purposes: 1. Provide the

[PATCH v3 00/10] PECI device driver introduction

Introduction of the Platform Environment Control Interface (PECI) bus device driver. PECI is a one-wire bus interface that provides a communication channel between an Intel processor and chipset components to external monitoring or control devices. PECI is designed to support the following

Re: [PATCH v3 05/14] s390: vfio-ap: base implementation of VFIO AP device driver

On 04/03/2018 06:57 AM, Cornelia Huck wrote: On Wed, 14 Mar 2018 14:25:45 -0400 Tony Krowiak wrote: Introduces a new AP device driver. This device driver is built on the VFIO mediated device framework. The framework provides sysfs interfaces that facilitate passthrough access by guests to

Re: [PATCH v3 05/14] s390: vfio-ap: base implementation of VFIO AP device driver

On Wed, 14 Mar 2018 14:25:45 -0400 Tony Krowiak wrote: > Introduces a new AP device driver. This device driver > is built on the VFIO mediated device framework. The framework > provides sysfs interfaces that facilitate passthrough > access by guests to devices installed on th

Re: [PATCH v3 05/14] s390: vfio-ap: base implementation of VFIO AP device driver

On Tue, 27 Mar 2018 16:45:02 +0200 Pierre Morel wrote: > On 27/03/2018 13:17, Cornelia Huck wrote: > > On Thu, 15 Mar 2018 13:25:25 -0400 > > Tony Krowiak wrote: > > > >> On 03/15/2018 09:25 AM, Pierre Morel wrote: > >>> On 14/03/2018 19:25, Tony Krowiak wrote: > +config VFIO_AP > >>>

Re: [PATCH v3 05/14] s390: vfio-ap: base implementation of VFIO AP device driver

On 27/03/2018 13:17, Cornelia Huck wrote: On Thu, 15 Mar 2018 13:25:25 -0400 Tony Krowiak wrote: On 03/15/2018 09:25 AM, Pierre Morel wrote: On 14/03/2018 19:25, Tony Krowiak wrote: +config VFIO_AP +def_tristate m not sure it must be module by default. I would not set it by default. Co

Re: [PATCH v3 05/14] s390: vfio-ap: base implementation of VFIO AP device driver

On Thu, 15 Mar 2018 13:25:25 -0400 Tony Krowiak wrote: > On 03/15/2018 09:25 AM, Pierre Morel wrote: > > On 14/03/2018 19:25, Tony Krowiak wrote: > >> +config VFIO_AP > >> +def_tristate m > > not sure it must be module by default. > > I would not set it by default. > Connie also asked

[PATCH 15/15] mm/hmm: use device driver encoding for HMM pfn v2

From: Jérôme Glisse User of hmm_vma_fault() and hmm_vma_get_pfns() provide a flags array and pfn shift value allowing them to define their own encoding for HMM pfn that are fill inside the pfns array of the hmm_range struct. With this device driver can get pfn that match their own private

Re: [PATCH 15/15] mm/hmm: use device driver encoding for HMM pfn v2

the bitmap flags! > > This simplify nouveau code and it is the reason why i did that patch. > I am sure it can simplify NVidia uvm code, i can look into it if you > want to give pointers. Idea here is that HMM can fill array with some- > thing that match device driver internal forma

Re: [PATCH 15/15] mm/hmm: use device driver encoding for HMM pfn v2

ue if entry is valid then driver must > > provide > > + * an array in hmm_range.flags with hmm_range.flags[HMM_PFN_VALID] == 1 << > > 3. > > + * Same logic apply to all flags. This is same idea as vm_page_prot in vma > > + * except that this is per device driver rather

Re: [PATCH 15/15] mm/hmm: use device driver encoding for HMM pfn v2

ct. With > this device driver can get pfn that match their own private encoding > out of HMM without having to do any conversion. > > Changed since v1: > - Split flags and special values for clarification > - Improved comments and provide examples > > Signed-off-by: Jér

[PATCH 15/15] mm/hmm: use device driver encoding for HMM pfn v2

From: Jérôme Glisse User of hmm_vma_fault() and hmm_vma_get_pfns() provide a flags array and pfn shift value allowing them to define their own encoding for HMM pfn that are fill inside the pfns array of the hmm_range struct. With this device driver can get pfn that match their own private

Re: [PATCH 14/14] mm/hmm: use device driver encoding for HMM pfn

ct. With > this device driver can get pfn that match their own private encoding > out of HMM without having to do any convertion. > > Signed-off-by: Jérôme Glisse > Cc: Evgeny Baskakov > Cc: Ralph Campbell > Cc: Mark Hairgrove > Cc: John Hub

[PATCH 14/14] mm/hmm: use device driver encoding for HMM pfn

From: Jérôme Glisse User of hmm_vma_fault() and hmm_vma_get_pfns() provide a flags array and pfn shift value allowing them to define their own encoding for HMM pfn that are fill inside the pfns array of the hmm_range struct. With this device driver can get pfn that match their own private

Re: [PATCH v4 08/24] fpga: add FPGA DFL PCIe device driver

+140,19 @@ config FPGA_DFL > > Gate Array (FPGA) solutions which implement Device Feature List. > > It provides enumeration APIs, and feature device infrastructure. > > > > +config FPGA_DFL_PCI > > + tristate "FPGA Device Feature List (DFL) PCIe

Re: [PATCH v4 08/24] fpga: add FPGA DFL PCIe device driver

,4 +140,19 @@ config FPGA_DFL > Gate Array (FPGA) solutions which implement Device Feature List. > It provides enumeration APIs, and feature device infrastructure. > > +config FPGA_DFL_PCI > + tristate "FPGA Device Feature List (DFL) PCIe Device Driver"

Re: [PATCH v3 05/14] s390: vfio-ap: base implementation of VFIO AP device driver

On 03/15/2018 09:25 AM, Pierre Morel wrote: On 14/03/2018 19:25, Tony Krowiak wrote: Introduces a new AP device driver. This device driver is built on the VFIO mediated device framework. The framework provides sysfs interfaces that facilitate passthrough access by guests to devices installed on

Re: [PATCH v3 05/14] s390: vfio-ap: base implementation of VFIO AP device driver

On 14/03/2018 19:25, Tony Krowiak wrote: Introduces a new AP device driver. This device driver is built on the VFIO mediated device framework. The framework provides sysfs interfaces that facilitate passthrough access by guests to devices installed on the linux host. The VFIO AP device driver

[PATCH v3 05/14] s390: vfio-ap: base implementation of VFIO AP device driver

Introduces a new AP device driver. This device driver is built on the VFIO mediated device framework. The framework provides sysfs interfaces that facilitate passthrough access by guests to devices installed on the linux host. The VFIO AP device driver will serve two purposes: 1. Provide the

Re: [PATCH v4 08/24] fpga: add FPGA DFL PCIe device driver

> Gate Array (FPGA) solutions which implement Device Feature List. > It provides enumeration APIs, and feature device infrastructure. > > +config FPGA_DFL_PCI > + tristate "FPGA Device Feature List (DFL) PCIe Device Driver" > + depends on P

Re: [PATCH v6 08/17] media: rkisp1: add capture device driver

On 08/03/18 10:47, Jacob Chen wrote: > From: Jacob Chen > > This is the capture device interface driver that provides the v4l2 > user interface. Frames can be received from ISP1. > > Signed-off-by: Jacob Chen > Signed-off-by: Shunqian Zheng > Signed-off-by: Yichong Zhong > Signed-off-by: Jaco

[PATCH v6 08/17] media: rkisp1: add capture device driver

From: Jacob Chen This is the capture device interface driver that provides the v4l2 user interface. Frames can be received from ISP1. Signed-off-by: Jacob Chen Signed-off-by: Shunqian Zheng Signed-off-by: Yichong Zhong Signed-off-by: Jacob Chen Signed-off-by: Eddie Cai Signed-off-by: Jeffy

Re: [PATCH v2 0/8] PECI device driver introduction

Hi Pavel, Please see my answer inline. On 3/6/2018 4:40 AM, Pavel Machek wrote: Hi! Introduction of the Platform Environment Control Interface (PECI) bus device driver. PECI is a one-wire bus interface that provides a communication channel between Intel processor and chipset components to

Re: [PATCH v2 0/8] PECI device driver introduction

Hi! > Introduction of the Platform Environment Control Interface (PECI) bus > device driver. PECI is a one-wire bus interface that provides a > communication channel between Intel processor and chipset components to > external monitoring or control devices. PECI is designed to

Re: [PATCH v2 05/15] s390: vfio-ap: base implementation of VFIO AP device driver

On 02/28/2018 01:10 PM, Cornelia Huck wrote: On Wed, 28 Feb 2018 11:43:37 -0500 Tony Krowiak wrote: On 02/28/2018 10:33 AM, Pierre Morel wrote: On 27/02/2018 15:28, Tony Krowiak wrote: (...) diff --git a/arch/s390/Kconfig b/arch/s390/Kconfig index cbe1d97..9f23caf 100644 --- a/arch/s390/Kc

Re: [PATCH v2 05/15] s390: vfio-ap: base implementation of VFIO AP device driver

On Wed, 28 Feb 2018 11:43:37 -0500 Tony Krowiak wrote: > On 02/28/2018 10:33 AM, Pierre Morel wrote: > > On 27/02/2018 15:28, Tony Krowiak wrote: (...) > >> diff --git a/arch/s390/Kconfig b/arch/s390/Kconfig > >> index cbe1d97..9f23caf 100644 > >> --- a/arch/s390/Kconfig > >> +++ b/arch/s390/

Re: [PATCH v2 05/15] s390: vfio-ap: base implementation of VFIO AP device driver

On 02/28/2018 10:33 AM, Pierre Morel wrote: On 27/02/2018 15:28, Tony Krowiak wrote: Introduces a new AP device driver. This device driver is built on the VFIO mediated device framework. The framework provides sysfs interfaces that facilitate passthrough access by guests to devices installed on

Re: [PATCH v2 05/15] s390: vfio-ap: base implementation of VFIO AP device driver

On 27/02/2018 15:28, Tony Krowiak wrote: Introduces a new AP device driver. This device driver is built on the VFIO mediated device framework. The framework provides sysfs interfaces that facilitate passthrough access by guests to devices installed on the linux host. The VFIO AP device driver

[PATCH v2 05/15] s390: vfio-ap: base implementation of VFIO AP device driver

Introduces a new AP device driver. This device driver is built on the VFIO mediated device framework. The framework provides sysfs interfaces that facilitate passthrough access by guests to devices installed on the linux host. The VFIO AP device driver will serve two purposes: 1. Provide the

[PATCH v2 0/8] PECI device driver introduction

Introduction of the Platform Environment Control Interface (PECI) bus device driver. PECI is a one-wire bus interface that provides a communication channel between Intel processor and chipset components to external monitoring or control devices. PECI is designed to support the following sideband

[PATCH v4 08/24] fpga: add FPGA DFL PCIe device driver

FPGA_DFL Gate Array (FPGA) solutions which implement Device Feature List. It provides enumeration APIs, and feature device infrastructure. +config FPGA_DFL_PCI + tristate "FPGA Device Feature List (DFL) PCIe Device Driver" + depends on PCI && FPG

Re: [PATCH v5 08/16] media: rkisp1: add capture device driver

On 12/29/17 08:52, Shunqian Zheng wrote: > From: Jacob Chen > > This is the capture device interface driver that provides the v4l2 > user interface. Frames can be received from ISP1. > > Signed-off-by: Jacob Chen > Signed-off-by: Shunqian Zheng > Signed-off-by: Yichong Zhong > Signed-off-by:

[PATCH 0/2] dm: add asymmetric stripe device driver

Device-Mapper's "asm-striped" target is used to create a striped (i.e. RAID-0) device across one or more underlying devices. Data is written in "chunks", with consecutive chunks rotating among the underlying devices. This can potentially provide improved I/O throughput by utilizing several physical

[PATCH v5 08/16] media: rkisp1: add capture device driver

From: Jacob Chen This is the capture device interface driver that provides the v4l2 user interface. Frames can be received from ISP1. Signed-off-by: Jacob Chen Signed-off-by: Shunqian Zheng Signed-off-by: Yichong Zhong Signed-off-by: Jacob Chen Signed-off-by: Eddie Cai Signed-off-by: Jeffy

[PATCH v4 08/16] media: rkisp1: add capture device driver

From: Jacob Chen This is the capture device interface driver that provides the v4l2 user interface. Frames can be received from ISP1. Signed-off-by: Jacob Chen Signed-off-by: Shunqian Zheng Signed-off-by: Yichong Zhong Signed-off-by: Jacob Chen Signed-off-by: Eddie Cai Signed-off-by: Jeffy

Re: [PATCH v10 00/13] Introduce framework for SLIMbus device driver

On Mon, Dec 11, 2017 at 11:42:54PM +, srinivas.kandaga...@linaro.org wrote: > From: Srinivas Kandagatla > > SLIMbus (Serial Low Power Interchip Media Bus) is a specification > developed by MIPI (Mobile Industry Processor Interface) alliance. > SLIMbus is a 2-wire implementation, which is used

Re: [PATCH v10 00/13] Introduce framework for SLIMbus device driver

On 13/12/17 09:25, Greg Kroah-Hartman wrote: On Mon, Dec 11, 2017 at 11:42:54PM +, srinivas.kandaga...@linaro.org wrote: From: Srinivas Kandagatla SLIMbus (Serial Low Power Interchip Media Bus) is a specification developed by MIPI (Mobile Industry Processor Interface) alliance. SLIMbus i

Re: [PATCH v10 00/13] Introduce framework for SLIMbus device driver

On Mon, Dec 11, 2017 at 11:42:54PM +, srinivas.kandaga...@linaro.org wrote: > From: Srinivas Kandagatla > > SLIMbus (Serial Low Power Interchip Media Bus) is a specification > developed by MIPI (Mobile Industry Processor Interface) alliance. > SLIMbus is a 2-wire implementation, which is used

[PATCH v10 00/13] Introduce framework for SLIMbus device driver

From: Srinivas Kandagatla SLIMbus (Serial Low Power Interchip Media Bus) is a specification developed by MIPI (Mobile Industry Processor Interface) alliance. SLIMbus is a 2-wire implementation, which is used to communicate with peripheral components like audio-codec. SLIMbus uses Time-Division-Mu

[PATCH v9 00/13] Introduce framework for SLIMbus device driver

From: Srinivas Kandagatla Thanks for everyone who reviewed v8 patchset, here is v9 with review comments addressed. SLIMbus (Serial Low Power Interchip Media Bus) is a specification developed by MIPI (Mobile Industry Processor Interface) alliance. SLIMbus is a 2-wire implementation, which is used

[PATCH v8 00/13] Introduce framework for SLIMbus device driver

From: Srinivas Kandagatla Thanks for everyone who reviewed v7 patchset, here is v8 with review comments addressed. SLIMbus (Serial Low Power Interchip Media Bus) is a specification developed by MIPI (Mobile Industry Processor Interface) alliance. SLIMbus is a 2-wire implementation, which is used

[PATCH v5 2/8] drivers/fsi: Add SBEFIFO FSI client device driver

g @@ -33,6 +33,13 @@ config FSI_SCOM ---help--- This option enables an FSI based SCOM device driver. +config FSI_SBEFIFO + tristate "SBEFIFO FSI client device driver" + ---help--- + This option enables an FSI based SBEFIFO device driver. The SBEFIFO is +

Re: [RFC 05/19] s390/zcrypt: base implementation of AP matrix device driver

On Fri, 17 Nov 2017 16:13:45 -0500 Tony Krowiak wrote: > On 11/16/2017 11:47 AM, Cornelia Huck wrote: > > [Also, is IOMMU_API only needed to satisfy dependencies?] > Yes, VFIO is dependent upon it. Ah, my question was more whether we just need to make sure the api is there, but do not need to

Re: [RFC 05/19] s390/zcrypt: base implementation of AP matrix device driver

On 11/16/2017 11:47 AM, Cornelia Huck wrote: On Thu, 16 Nov 2017 09:25:27 -0500 Tony Krowiak wrote: On 11/16/2017 07:35 AM, Cornelia Huck wrote: On Thu, 16 Nov 2017 13:02:26 +0100 Pierre Morel wrote: On 14/11/2017 17:37, Tony Krowiak wrote: On 11/14/2017 07:40 AM, Cornelia Huck wrote:

[PATCH v4 2/4] drivers/fsi: Add SBEFIFO FSI client device driver

g @@ -33,6 +33,13 @@ config FSI_SCOM ---help--- This option enables an FSI based SCOM device driver. +config FSI_SBEFIFO + tristate "SBEFIFO FSI client device driver" + ---help--- + This option enables an FSI based SBEFIFO device driver. The SBEFIFO is +

Re: [RFC 05/19] s390/zcrypt: base implementation of AP matrix device driver

On Thu, 16 Nov 2017 09:25:27 -0500 Tony Krowiak wrote: > On 11/16/2017 07:35 AM, Cornelia Huck wrote: > > On Thu, 16 Nov 2017 13:02:26 +0100 > > Pierre Morel wrote: > > > >> On 14/11/2017 17:37, Tony Krowiak wrote: > >>> On 11/14/2017 07:40 AM, Cornelia Huck wrote: > On Fri, 13 Oct 20

Re: [RFC 05/19] s390/zcrypt: base implementation of AP matrix device driver

On 11/16/2017 07:35 AM, Cornelia Huck wrote: On Thu, 16 Nov 2017 13:02:26 +0100 Pierre Morel wrote: On 14/11/2017 17:37, Tony Krowiak wrote: On 11/14/2017 07:40 AM, Cornelia Huck wrote: On Fri, 13 Oct 2017 13:38:50 -0400 Tony Krowiak wrote: diff --git a/arch/s390/Kconfig b/arch/s390/Kconfi

Re: [RFC 05/19] s390/zcrypt: base implementation of AP matrix device driver

On 16/11/2017 13:35, Cornelia Huck wrote: On Thu, 16 Nov 2017 13:02:26 +0100 Pierre Morel wrote: On 14/11/2017 17:37, Tony Krowiak wrote: On 11/14/2017 07:40 AM, Cornelia Huck wrote: On Fri, 13 Oct 2017 13:38:50 -0400 Tony Krowiak wrote: diff --git a/arch/s390/Kconfig b/arch/s390/Kconfig

Re: [RFC 05/19] s390/zcrypt: base implementation of AP matrix device driver

On Thu, 16 Nov 2017 13:02:26 +0100 Pierre Morel wrote: > On 14/11/2017 17:37, Tony Krowiak wrote: > > On 11/14/2017 07:40 AM, Cornelia Huck wrote: > >> On Fri, 13 Oct 2017 13:38:50 -0400 > >> Tony Krowiak wrote: > >>> diff --git a/arch/s390/Kconfig b/arch/s390/Kconfig > >>> index 48af970..411

Re: [RFC 05/19] s390/zcrypt: base implementation of AP matrix device driver

On 14/11/2017 17:37, Tony Krowiak wrote: On 11/14/2017 07:40 AM, Cornelia Huck wrote: On Fri, 13 Oct 2017 13:38:50 -0400 Tony Krowiak wrote: Introduces a new AP matrix device driver. This device driver will ultimately perform the following functions: * Register with the AP bus to let it

[PATCH v7 00/13] Introduce framework for SLIMbus device driver

From: Srinivas Kandagatla Thanks for everyone who reviewed v6 patchset, here is v7 with review comments addressed. SLIMbus (Serial Low Power Interchip Media Bus) is a specification developed by MIPI (Mobile Industry Processor Interface) alliance. SLIMbus is a 2-wire implementation, which is used

Re: [RFC 05/19] s390/zcrypt: base implementation of AP matrix device driver

matrix ap_matrix; > >> > >> Does this seem like a reasonable approach? > > Getting rid of the bus as overhead is not unreasonable. > > > > I'm feeling a bit queasy about the extern, however. I'd prefer a getter > > function (that also makes sure

Re: [RFC 05/19] s390/zcrypt: base implementation of AP matrix device driver

e is a need for information about the AP queues that have been bound to the vfio_ap_matrix device driver. If interfaces are provided by the vfio_ap_matrix device driver to access the needed information, it won't be necessary to reference the ap_matrix device directly in vfio_ap_matrix_ops. I think th

Re: [RFC 05/19] s390/zcrypt: base implementation of AP matrix device driver

On Tue, 14 Nov 2017 11:37:05 -0500 Tony Krowiak wrote: > On 11/14/2017 07:40 AM, Cornelia Huck wrote: > > On Fri, 13 Oct 2017 13:38:50 -0400 > > Tony Krowiak wrote: > >> diff --git a/drivers/s390/crypto/ap_matrix_bus.c > >> b/drivers/s390/crypto/ap_matrix_bus.c > >> index 4eb1e3c..66bfa54 1006

Re: [RFC 05/19] s390/zcrypt: base implementation of AP matrix device driver

On 11/14/2017 07:40 AM, Cornelia Huck wrote: On Fri, 13 Oct 2017 13:38:50 -0400 Tony Krowiak wrote: Introduces a new AP matrix device driver. This device driver will ultimately perform the following functions: * Register with the AP bus to let it know that the matrix driver can control AP

Re: [RFC 05/19] s390/zcrypt: base implementation of AP matrix device driver

On Fri, 13 Oct 2017 13:38:50 -0400 Tony Krowiak wrote: > Introduces a new AP matrix device driver. This device driver > will ultimately perform the following functions: > > * Register with the AP bus to let it know that the matrix > driver can control AP queue devices. This wi

Re: [RFC 05/19] s390/zcrypt: base implementation of AP matrix device driver

l +++ b/drivers/s390/crypto/vfio_ap_matrix_drv.c @@ -0,0 +1,102 @@ +/* + * VFIO based AP Matrix device driver + * + * Copyright IBM Corp. 2017 + * + * Author(s): Tony Krowiak + */ + +#include +#include +#include + +#include "ap_bus.h" +#include "ap_matrix_bus.h" +#inclu

Re: [RFC 05/19] s390/zcrypt: base implementation of AP matrix device driver

ff --git a/drivers/s390/crypto/vfio_ap_matrix_drv.c > b/drivers/s390/crypto/vfio_ap_matrix_drv.c > new file mode 100644 > index 000..760ed56 > --- /dev/null > +++ b/drivers/s390/crypto/vfio_ap_matrix_drv.c > @@ -0,0 +1,102 @@ > +/* > + * VFIO based AP Matrix

[RFC 05/19] s390/zcrypt: base implementation of AP matrix device driver

Introduces a new AP matrix device driver. This device driver will ultimately perform the following functions: * Register with the AP bus to let it know that the matrix driver can control AP queue devices. This will allow an administrator to unbind an AP queue device from its device driver

Re: [PATCH v3 2/6] drivers: fsi: Add SBEFIFO FSI client device driver

Hi Eddie, On Sat, 23 Sep 2017, at 06:35, Eddie James wrote: > From: "Edward A. James" > > IBM POWER9 processors contain some embedded hardware and software bits > collectively referred to as the self boot engine (SBE). One role of > the SBE is to act as a proxy that provides access to the regis

[PATCH v3 2/6] drivers: fsi: Add SBEFIFO FSI client device driver

3,6 +33,13 @@ config FSI_SCOM ---help--- This option enables an FSI based SCOM device driver. +config FSI_SBEFIFO + tristate "SBEFIFO FSI client device driver" + ---help--- + This option enables an FSI based SBEFIFO device driver. The SBEFIFO is + a

Re: [I2C] About warning 'DMA-API: device driver maps memory from stack'

On Sat, 2017-09-02 at 23:58 +0200, Wolfram Sang wrote: > Hi, > > nice to see someone else interested in the I2C & DMA topic. > > Please check this series which I sent out recently: > > "[RFC PATCH v4 0/6] i2c: document DMA handling and add helpers for it" > > In that series, I proposed... > >

[PATCH v7 0/8] AC97 device/driver model revamp

Hi Lars, Mark, Charles, Lee, This is a revision for Lee and Charles, only targetted at wm97xx-core changes (second round) suggested by Lee and codecs remove path for Charles. I removed the leading 4 patches as Mark has already scheduled them. For easier spotting, I included in [1] the diff from

Re: [I2C] About warning 'DMA-API: device driver maps memory from stack'

Hi, nice to see someone else interested in the I2C & DMA topic. Please check this series which I sent out recently: "[RFC PATCH v4 0/6] i2c: document DMA handling and add helpers for it" In that series, I proposed... > 3. kmalloc data buffer instead of local variables buf in function > i2c_smb

[PATCH v6 00/12] AC97 device/driver model revamp

Hi Lars, Mark, Charles, Lee, This is a revision for Lee, only targetted at wm97xx-core changes suggested by Lee. I hope I have every concern covered Lee, just le me know if it suits you. For easier spotting, I included in [1] the diff from the last serie. I kept Charles ack for patch 6/12 follow

[I2C] About warning 'DMA-API: device driver maps memory from stack'

0.i2c: DMA-API: device driver maps memory from stack [addr=80007a21fb88] [ 11.874104] [ cut here ] [ 11.874703] WARNING: CPU: 1 PID: 1232 at /proj/user/kernel_only_dev_4.13_rc1/kernel/mediatek/lib/dma-debug.c:1188 check_for_stack+0xb0/0x100 [ 11.876337] Modules

Re: [PATCH v5 00/12] AC97 device/driver model revamp

Robert Jarzmik writes: > Hi Lars, Mark, Charles, Lee, Hi again, I have Lee's comments covered now. If there are no more comments, I'll send out a v6 for Lee to verify my work is dealing with his concerns. Cheers. -- Robert

RE: [PATCH v2 06/22] fpga: intel: add FPGA PCIe device driver

cidev->dev, "No suitable DMA support > > available.\n"); > > + goto release_region_exit; > > + } > > + > > + /* TODO: create and add the platform device per feature list */ > > + return 0; > > + > > +release_region_exit: > > + pci_release_regions(pcidev); > > +disable_error_report_exit: > > + pci_disable_pcie_error_reporting(pcidev); > > + pci_disable_device(pcidev); > > + return ret; > > +} > > + > > +static void cci_pci_remove(struct pci_dev *pcidev) > > +{ > > + pci_release_regions(pcidev); > > + pci_disable_pcie_error_reporting(pcidev); > > + pci_disable_device(pcidev); > > +} > > + > > +static struct pci_driver cci_pci_driver = { > > + .name = DRV_NAME, > > + .id_table = cci_pcie_id_tbl, > > + .probe = cci_pci_probe, > > + .remove = cci_pci_remove, > > +}; > > + > > +static int __init ccidrv_init(void) > > +{ > > + pr_info("Intel(R) FPGA PCIe Driver: Version %s\n", DRV_VERSION); > > + > > + return pci_register_driver(&cci_pci_driver); > > +} > > + > > +static void __exit ccidrv_exit(void) > > +{ > > + pci_unregister_driver(&cci_pci_driver); > > +} > > + > > +module_init(ccidrv_init); > > +module_exit(ccidrv_exit); > > + > > +MODULE_DESCRIPTION("Intel FPGA PCIe Device Driver"); > > +MODULE_AUTHOR("Intel Corporation"); > > +MODULE_LICENSE("GPL v2"); > > -- > > 1.8.3.1 > >

Re: [PATCH v2 06/22] fpga: intel: add FPGA PCIe device driver

rror_report_exit: > + pci_disable_pcie_error_reporting(pcidev); > + pci_disable_device(pcidev); > + return ret; > +} > + > +static void cci_pci_remove(struct pci_dev *pcidev) > +{ > + pci_release_regions(pcidev); > + pci_disable_pcie_error_reportin

[PATCH v5 00/12] AC97 device/driver model revamp

Hi Lars, Mark, Charles, Lee, This is a minor revision after v4, mainly reviews from Takashi, Charles. I extracted the diff from the v3 of sound/ac97 which is in [1] for easier spotting of what has globally changed. I tentatively kept your Ack Charles for patch 11/12, please shout if you disagree

[PATCH v4 00/12] AC97 device/driver model revamp

Hi Lars, Mark, Charles, Lee, This is a minor revision after v3, mainly reviews from Takashi, Charles. I did more extensive testing of load/unload of the whole serie, and apart from a bug in wm97xx-core in touchscreen tree (for a which a patch will be sent apart), it seems to work properly. I extr

Re: [PATCH v3 00/12] AC97 device/driver model revamp

Mark Brown writes: > On Fri, Jun 30, 2017 at 09:43:56PM +0200, Robert Jarzmik wrote: >> Hi Lars, Mark, Charles, Lee, >> >> This is a resend of the v2, with patch 1 added (forgotten in v2). Patch 12 >> was >> slightly modified after module unloading tests, and Dmitry acks were added. > > This al

Re: [PATCH v3 00/12] AC97 device/driver model revamp

On Fri, Jun 30, 2017 at 09:43:56PM +0200, Robert Jarzmik wrote: > Hi Lars, Mark, Charles, Lee, > > This is a resend of the v2, with patch 1 added (forgotten in v2). Patch 12 was > slightly modified after module unloading tests, and Dmitry acks were added. This all looks good to me modulo the nami

Re: [PATCH v12 02/10] powerpc/powernv: Autoload IMC device driver module

Hi Maddy/Anju, Comments below :) Anju T Sudhakar writes: > Code to create platform device for the IMC counters. > Paltform devices are created based on the IMC compatibility > string. > > New Config flag "CONFIG_HV_PERF_IMC_CTRS" add to contain the > IMC counter changes. I don't think we need a

[PATCH v2 1/5] drivers/fsi: Add SBEFIFO FSI client device driver

rs/fsi/fsi-sbefifo.c diff --git a/drivers/fsi/Kconfig b/drivers/fsi/Kconfig index 6821ed0..8c4d903 100644 --- a/drivers/fsi/Kconfig +++ b/drivers/fsi/Kconfig @@ -33,6 +33,13 @@ config FSI_SCOM ---help--- This option enables an FSI based SCOM device driver. +config FSI_SBEFIFO +

[PATCH v12 02/10] powerpc/powernv: Autoload IMC device driver module

Code to create platform device for the IMC counters. Paltform devices are created based on the IMC compatibility string. New Config flag "CONFIG_HV_PERF_IMC_CTRS" add to contain the IMC counter changes. Signed-off-by: Anju T Sudhakar Signed-off-by: Hemant Kumar Signed-off-by: Madhavan Srinivasa

[PATCH v3 00/12] AC97 device/driver model revamp

Hi Lars, Mark, Charles, Lee, This is a resend of the v2, with patch 1 added (forgotten in v2). Patch 12 was slightly modified after module unloading tests, and Dmitry acks were added. This serie has been stalled for almost one year, as I wasn't feeling that well lately. I'm quite better now, so l

Best practise for a polling device driver ?

Hi folks, I'm currently writing a driver for an (pseudo-)serial device (actually, a bunch of HW fifo's, which look like serial controllers to the host), which only supports polling, no interrupts. So far, I'm just using a kthread in a loop, but that would have to run w/ high priority sleep very

[PATCH v11 02/10] powerpc/powernv: Autoload IMC device driver module

Code to create platform device for the IMC counters. Paltform devices are created based on the IMC compatibility string. New Config flag "CONFIG_HV_PERF_IMC_CTRS" add to contain the IMC counter changes. Signed-off-by: Anju T Sudhakar Signed-off-by: Hemant Kumar Signed-off-by: Madhavan Srinivasa

[PATCH v2 06/22] fpga: intel: add FPGA PCIe device driver

%s\n", DRV_VERSION); + + return pci_register_driver(&cci_pci_driver); +} + +static void __exit ccidrv_exit(void) +{ + pci_unregister_driver(&cci_pci_driver); +} + +module_init(ccidrv_init); +module_exit(ccidrv_exit); + +MODULE_DESCRIPTION("Intel FPGA PCIe Device Driver"); +MODULE_AUTHOR("Intel Corporation"); +MODULE_LICENSE("GPL v2"); -- 1.8.3.1

[PATCH linux 1/4] drivers/fsi: Add SBEFIFO FSI client device driver

rs/fsi/fsi-sbefifo.c diff --git a/drivers/fsi/Kconfig b/drivers/fsi/Kconfig index 6821ed0..8c4d903 100644 --- a/drivers/fsi/Kconfig +++ b/drivers/fsi/Kconfig @@ -33,6 +33,13 @@ config FSI_SCOM ---help--- This option enables an FSI based SCOM device driver. +config FSI_SBEFIFO +

Re: [PATCH linux] drivers/fsi: Add SBEFIFO FSI client device driver

On 06/15/2017 5:24 AM, gre...@linuxfoundation.org wrote: On Wed, Jun 14, 2017 at 02:47:27PM -0500, Edward A. James wrote: +struct sbefifo { +struct timer_list poll_timer; +struct fsi_device *fsi_dev; +struct miscdev

Re: [PATCH 3.10 162/268] bcma: use (get|put)_device when probing/removing device driver

On 2017-06-20 09:58, Willy Tarreau wrote: On Tue, Jun 20, 2017 at 09:31:00AM +0200, Rafal Milecki wrote: Do you know if my name will appear correctly in git [0]? [0] https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/log/?h=linux-3.10.y I would have almost promised it wa

Re: [PATCH 3.10 162/268] bcma: use (get|put)_device when probing/removing device driver

On 2017-06-20 08:14, Willy Tarreau wrote: On Tue, Jun 20, 2017 at 08:12:26AM +0300, Kalle Valo wrote: Willy Tarreau writes: > From: Rafał Miłecki > > commit a971df0b9d04674e325346c17de9a895425ca5e1 upstream. > > This allows tracking device state and e.g. makes devm work as expected. > > Sig

Re: [PATCH 3.10 162/268] bcma: use (get|put)_device when probing/removing device driver

On Tue, Jun 20, 2017 at 10:14:05AM +0200, Rafal Milecki wrote: > On 2017-06-20 09:58, Willy Tarreau wrote: > > On Tue, Jun 20, 2017 at 09:31:00AM +0200, Rafal Milecki wrote: > > > Do you know if my name will appear correctly in git [0]? > > > > > > [0] > > > https://git.kernel.org/pub/scm/linux/k

Re: [PATCH 3.10 162/268] bcma: use (get|put)_device when probing/removing device driver

On Tue, Jun 20, 2017 at 09:31:00AM +0200, Rafal Milecki wrote: > Do you know if my name will appear correctly in git [0]? > > [0] > https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/log/?h=linux-3.10.y I would have almost promised it was going to be OK but it's bogus so it

Re: [PATCH 3.10 162/268] bcma: use (get|put)_device when probing/removing device driver

On Tue, Jun 20, 2017 at 08:12:26AM +0300, Kalle Valo wrote: > Willy Tarreau writes: > > > From: Rafał Miłecki > > > > commit a971df0b9d04674e325346c17de9a895425ca5e1 upstream. > > > > This allows tracking device state and e.g. makes devm work as expected. > > > > Signed-off-by: Rafał Miłecki

Re: [PATCH 3.10 162/268] bcma: use (get|put)_device when probing/removing device driver

Willy Tarreau writes: > From: Rafał Miłecki > > commit a971df0b9d04674e325346c17de9a895425ca5e1 upstream. > > This allows tracking device state and e.g. makes devm work as expected. > > Signed-off-by: Rafał Miłecki > Signed-off-by: Kalle Valo > Signed-off-by: Willy Tarreau UTF-8 characte

<    1   2   3   4   5   6   7   8   9   10   >