On 2021/4/19 17:07, Daniel Thompson wrote:
> On Sat, Apr 17, 2021 at 06:17:10PM +0800, Yicong Yang wrote:
>> Document the introduction and usage of HiSilicon PTT device driver.
>>
>> Signed-off-by: Yicong Yang
>> ---
>> Docum
On Sat, Apr 17, 2021 at 06:17:10PM +0800, Yicong Yang wrote:
> Document the introduction and usage of HiSilicon PTT device driver.
>
> Signed-off-by: Yicong Yang
> ---
> Documentation/trace/hisi-ptt.rst | 326
> +++
> 1 file ch
Document the introduction and usage of HiSilicon PTT device driver.
Signed-off-by: Yicong Yang
---
Documentation/trace/hisi-ptt.rst | 326 +++
1 file changed, 326 insertions(+)
create mode 100644 Documentation/trace/hisi-ptt.rst
diff --git a/Documentation
Hi,
New features:
1. ARM TEE backend for kernel trusted keys to complete the existing TPM
backend.
2. ASN.1 format for TPM2 trusted keys to make them interact with the
user space stack, such as OpenConnect VPN.
Other than that, contains bunch of bug fixes.
/Jarkko
The following changes
On Tue, Apr 13, 2021 at 11:42:15PM +0530, Vidya Sagar wrote:
> On 4/13/2021 3:23 AM, Bjorn Helgaas wrote:
> > The existing port services (AER, DPC, hotplug, etc) are things the
> > device advertises via the PCI Capabilities defined by the generic PCIe
> > spec, and in my opinion the support for
On 4/13/2021 11:43 PM, Rob Herring wrote:
External email: Use caution opening links or attachments
On Mon, Apr 12, 2021 at 12:01 PM Vidya Sagar wrote:
Hi
I'm starting this mail to seek advice on the best approach to be taken
to add support for the driver of the PCIe root port's DMA
On Mon, Apr 12, 2021 at 12:01 PM Vidya Sagar wrote:
>
> Hi
> I'm starting this mail to seek advice on the best approach to be taken
> to add support for the driver of the PCIe root port's DMA engine.
> To give some background, Tegra194's PCIe IPs are dual-mode PCIe IPs i.e.
> they work either in
On 4/13/2021 3:23 AM, Bjorn Helgaas wrote:
External email: Use caution opening links or attachments
[+cc Matthew for portdrv comment]
On Mon, Apr 12, 2021 at 10:31:02PM +0530, Vidya Sagar wrote:
Hi
I'm starting this mail to seek advice on the best approach to be taken to
add support for
Driver so far wasn't ported to the driver model and registered
the watchdog device out of the init after probing the I/O ports
for a watchdog with correct vendor and device revision.
Keep the device detection part at init time, but move watchdog
registration to a platform driver probe function.
[+cc Matthew for portdrv comment]
On Mon, Apr 12, 2021 at 10:31:02PM +0530, Vidya Sagar wrote:
> Hi
> I'm starting this mail to seek advice on the best approach to be taken to
> add support for the driver of the PCIe root port's DMA engine.
> To give some background, Tegra194's PCIe IPs are
Hi
I'm starting this mail to seek advice on the best approach to be taken
to add support for the driver of the PCIe root port's DMA engine.
To give some background, Tegra194's PCIe IPs are dual-mode PCIe IPs i.e.
they work either in the root port mode or in the endpoint mode based on
the boot
On 2021/4/9 0:57, Bjorn Helgaas wrote:
> On Thu, Apr 08, 2021 at 09:22:52PM +0800, Yicong Yang wrote:
>> On 2021/4/8 2:55, Bjorn Helgaas wrote:
>>> On Tue, Apr 06, 2021 at 08:45:53PM +0800, Yicong Yang wrote:
>
+On Kunpeng 930 SoC, the PCIe root complex is composed of several
+PCIe
via the PCIe device driver how PCIe
device driver can get the notification of the function level reset(FLR)?
On Thu, Apr 08, 2021 at 09:22:52PM +0800, Yicong Yang wrote:
> On 2021/4/8 2:55, Bjorn Helgaas wrote:
> > On Tue, Apr 06, 2021 at 08:45:53PM +0800, Yicong Yang wrote:
> >> +On Kunpeng 930 SoC, the PCIe root complex is composed of several
> >> +PCIe cores.
>
> > Can you connect "Kunpeng 930" to
On 2021/4/8 2:55, Bjorn Helgaas wrote:
> Move important info in the subject earlier, e.g.,
>
> docs: Add HiSilicon PTT device documentation
>
> On Tue, Apr 06, 2021 at 08:45:53PM +0800, Yicong Yang wrote:
>> Document the introduction and usage of HiSilicon PTT device dri
Move important info in the subject earlier, e.g.,
docs: Add HiSilicon PTT device documentation
On Tue, Apr 06, 2021 at 08:45:53PM +0800, Yicong Yang wrote:
> Document the introduction and usage of HiSilicon PTT device driver.
>
> Signed-off-by: Yicong Yang
> ---
> Documenta
Document the introduction and usage of HiSilicon PTT device driver.
Signed-off-by: Yicong Yang
---
Documentation/trace/hisi-ptt.rst | 316 +++
1 file changed, 316 insertions(+)
create mode 100644 Documentation/trace/hisi-ptt.rst
diff --git a/Documentation
On 18.03.2021 16:56:34, Pankaj Sharma wrote:
> Update Chandrasekar Ramakrishnan as maintainer for mcan mmio device driver as
> I
> will be moving to a different role.
Applied to can-next/testing.
regards,
Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Embed
Update Chandrasekar Ramakrishnan as maintainer for mcan mmio device driver as I
will be moving to a different role.
Signed-off-by: Pankaj Sharma
---
MAINTAINERS | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index a50a543e3c81..76db44337f6c 100644
The pull request you sent on Wed, 3 Mar 2021 17:52:40 +0200:
> git://git.kernel.org/pub/scm/linux/kernel/git/jarkko/linux-tpmdd.git/
> tags/tpmdd-next-v5.12-rc2
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/3cb60ee6323968b694208c4cbd56a7176396e931
Thank you!
--
Hi Linus,
Three urgent fixes for rc2.
/Jarkko
The following changes since commit c03c21ba6f4e95e406a1a7b4c34ef334b977c194:
Merge tag 'keys-misc-20210126' of
git://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs (2021-02-23
16:09:23 -0800)
are available in the Git repository at:
The pull request you sent on Thu, 18 Feb 2021 05:31:29 +0200:
> git://git.kernel.org/pub/scm/linux/kernel/git/jarkko/linux-tpmdd.git/
> tags/tpmdd-next-v5.12-rc1-v2
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/a2b095e0efa7229a1a88602283ba1a8a32004851
Thank you!
Hi Linus,
This now my "official" first PR for v5.12. There's still some known issues
in the tpm_tis driver *not& fixed in this first pull request, which trigger a
warning but do not overally collapse the kernel by any means.
The fixes are in good progress, but unfortunately there's still some
Driver so far wasn't ported to the driver model and registered
the watchdog device out of the init after probing the I/O ports
for a watchdog with correct vendor and device revision.
Keep the device detection part at init time, but move watchdog
registration to a platform driver probe function.
Hello:
This series was applied to netdev/net-next.git (refs/heads/master):
On Wed, 27 Jan 2021 22:08:27 +0900 you wrote:
> From: Bongsu Jeon
>
> 1/2 is the Virtual NCI device driver.
> 2/2 is the NCI selftest suite
>
> v4:
> 1/2
> - flip the condition for the ioctl.
Introduce a new misc device driver for the Intel(r) Dynamic Load Balancer
(Intel(r) DLB). The Intel DLB is a PCIe device that provides
load-balanced, prioritized scheduling of core-to-core communication.
Intel DLB is an accelerator for the event-driven programming model of
DPDK's Event Device
From: Bongsu Jeon
NCI virtual device simulates a NCI device to the user. It can be used to
validate the NCI module and applications. This driver supports
communication between the virtual NCI device and NCI module.
Signed-off-by: Bongsu Jeon
---
drivers/nfc/Kconfig | 11 ++
From: Bongsu Jeon
1/2 is the Virtual NCI device driver.
2/2 is the NCI selftest suite
v4:
1/2
- flip the condition for the ioctl.
- refactor some code.
- remove the unused function after refactoring.
v3:
1/2
- change the Kconfig help comment.
- remove the mutex init code.
- remove
Introduce a new misc device driver for the Intel(r) Dynamic Load Balancer
(Intel(r) DLB). The Intel DLB is a PCIe device that provides
load-balanced, prioritized scheduling of core-to-core communication.
Intel DLB is an accelerator for the event-driven programming model of
DPDK's Event Device
macv310.c b/drivers/dma/hiedmacv310.c
> new file mode 100644
> index ..c0df5088a6a1
> --- /dev/null
> +++ b/drivers/dma/hiedmacv310.c
> @@ -0,0 +1,1442 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * The Hiedma Controller v310 Device Driver for HiSilico
On Thu, Jan 7, 2021 at 2:01 AM Jakub Kicinski wrote:
>
> On Wed, 6 Jan 2021 08:16:47 +0900 Bongsu Jeon wrote:
> > On Tue, Jan 5, 2021 at 4:48 AM Jakub Kicinski wrote:
> > > > thank you for your answer.
> > > > I think that neard(NFC deamon) is necessary to test the NCI subsystem
> > > >
On Wed, 6 Jan 2021 08:16:47 +0900 Bongsu Jeon wrote:
> On Tue, Jan 5, 2021 at 4:48 AM Jakub Kicinski wrote:
> > > thank you for your answer.
> > > I think that neard(NFC deamon) is necessary to test the NCI subsystem
> > > meaningfully.
> > > The NCI virtual device in user space can communicate
From: "Daniel W. S. Almeida"
Change from "vidtv_bridge" to simply "vidtv" so that vidtv looks
more similar to the other media virtual drivers in /sys/bus/platform.
Signed-off-by: Daniel W. S. Almeida
---
drivers/media/test-drivers/vidtv/vidtv_bridge.c | 4 ++--
On Tue, Jan 5, 2021 at 4:48 AM Jakub Kicinski wrote:
>
> On Thu, 31 Dec 2020 14:22:45 +0900 Bongsu Jeon wrote:
> > On Tue, Dec 29, 2020 at 6:16 AM Jakub Kicinski wrote:
> > >
> > > On Mon, 28 Dec 2020 18:45:07 +0900 Bongsu Jeon wrote:
> > > > From: Bongsu Jeon
> > > >
> > > > A NCI virtual
From: "Daniel W. S. Almeida"
Change from "vidtv_bridge" to simply "vidtv" so that vidtv looks
more similar to the other media virtual drivers in /sys/bus/platform.
Signed-off-by: Daniel W. S. Almeida
---
drivers/media/test-drivers/vidtv/vidtv_bridge.c | 4 ++--
Introduce a new misc device driver for the Intel(r) Dynamic Load Balancer
(Intel(r) DLB). The Intel DLB is a PCIe device that provides
load-balanced, prioritized scheduling of core-to-core communication.
Intel DLB is an accelerator for the event-driven programming model of
DPDK's Event Device
On Thu, 31 Dec 2020 14:22:45 +0900 Bongsu Jeon wrote:
> On Tue, Dec 29, 2020 at 6:16 AM Jakub Kicinski wrote:
> >
> > On Mon, 28 Dec 2020 18:45:07 +0900 Bongsu Jeon wrote:
> > > From: Bongsu Jeon
> > >
> > > A NCI virtual device can be made to simulate a NCI device in user space.
> > > Using
> From: Marc Kleine-Budde
> Subject: Re: [PATCH] MAINTAINERS: Update MCAN MMIO device driver
> maintainer
>
> On 1/4/21 1:31 PM, Sriram Dash wrote:
> > Update Pankaj Sharma as maintainer for mcan mmio device driver as I
> > will be moving to a different rol
On 1/4/21 1:31 PM, Sriram Dash wrote:
> Update Pankaj Sharma as maintainer for mcan mmio device driver as I
> will be moving to a different role.
>
> Signed-off-by: Sriram Dash
> ---
Applied to linux-can/testing.
Tnx,
Marc
--
Pengutronix e.K. | Ma
Update Pankaj Sharma as maintainer for mcan mmio device driver as I
will be moving to a different role.
Signed-off-by: Sriram Dash
---
MAINTAINERS | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 6eff4f7..45cea57 100644
--- a/MAINTAINERS
+++ b
On Tue, Dec 29, 2020 at 6:16 AM Jakub Kicinski wrote:
>
> On Mon, 28 Dec 2020 18:45:07 +0900 Bongsu Jeon wrote:
> > From: Bongsu Jeon
> >
> > A NCI virtual device can be made to simulate a NCI device in user space.
> > Using the virtual NCI device, The NCI module and application can be
> >
On Mon, 28 Dec 2020 18:45:07 +0900 Bongsu Jeon wrote:
> From: Bongsu Jeon
>
> A NCI virtual device can be made to simulate a NCI device in user space.
> Using the virtual NCI device, The NCI module and application can be
> validated. This driver supports to communicate between the virtual NCI
>
From: JC Kuo
[ Upstream commit 4ea0bf2a52f1eea76578eac5a9148d95f5e181c0 ]
In commit "phy: tegra: xusb: Add usb-phy support", an OTG capable PHY
device, such as phy-usb2.0 device of Jetson-TX1 platform, will be
bound to the tegra-xusb-padctl driver by the following line in
/MAINTAINERS
index a355db292486..6479a4754a1e 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -12431,6 +12431,13 @@ F: include/net/nfc/
F: include/uapi/linux/nfc.h
F: net/nfc/
+NFC VIRTUAL NCI DEVICE DRIVER
+M: Bongsu Jeon
+L: net...@vger.kernel.org
+L: linux-...@lists.01.org
--git a/drivers/dma/hiedmacv310.c b/drivers/dma/hiedmacv310.c
new file mode 100644
index ..c0df5088a6a1
--- /dev/null
+++ b/drivers/dma/hiedmacv310.c
@@ -0,0 +1,1442 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * The Hiedma Controller v310 Device Driver for HiSilicon
+ *
+ * Copyright (c) 2019-2
gt; > > --- a/MAINTAINERS
> > > > > +++ b/MAINTAINERS
> > > > > @@ -19283,6 +19283,14 @@ T:
> > > > > githttps://github.com/Xilinx/linux-xlnx.git
> > > > > F: Documentation/devicetree/bindings/phy/xlnx,zynqmp-psgtr.yaml
> > > > >
device can have multiple logical partitions(groups of AI
engine tiles). Each partition is column based and has its own node ID
in the system. AI engine device driver manages its partitions.
Applications can access AI engine partition through the AI engine
partition driver instance. AI engine registers
--git a/drivers/dma/hiedmacv310.c b/drivers/dma/hiedmacv310.c
new file mode 100644
index ..ddf9b5d85a27
--- /dev/null
+++ b/drivers/dma/hiedmacv310.c
@@ -0,0 +1,1442 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * The Hiedma Controller v310 Device Driver for HiSilicon
+ *
+ * Copyright (c) 2019-2
--git a/drivers/dma/hiedmacv310.c b/drivers/dma/hiedmacv310.c
new file mode 100644
index ..ddf9b5d85a27
--- /dev/null
+++ b/drivers/dma/hiedmacv310.c
@@ -0,0 +1,1442 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * The Hiedma Controller v310 Device Driver for HiSilicon
+ *
+ * Copyright (c) 2019-2
--git a/drivers/dma/hiedmacv310.c b/drivers/dma/hiedmacv310.c
new file mode 100644
index ..ddf9b5d85a27
--- /dev/null
+++ b/drivers/dma/hiedmacv310.c
@@ -0,0 +1,1442 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * The Hiedma Controller v310 Device Driver for HiSilicon
+ *
+ * Copyright (c) 2019-2
Each AI engine device can have multiple logical partitions(groups of AI
> > > engine tiles). Each partition is column based and has its own node ID
> > > in the system. AI engine device driver manages its partitions.
> > >
> > > Applications can access AI engine
and has its own node ID
in the system. AI engine device driver manages its partitions.
Applications can access AI engine partition through the AI engine
partition driver instance. AI engine registers write is moved to kernel
as there are registers in the AI engine array needs privilege
permission.
Hi
and has its own node ID
in the system. AI engine device driver manages its partitions.
Applications can access AI engine partition through the AI engine
partition driver instance. AI engine registers write is moved to kernel
as there are registers in the AI engine array needs privilege
permission.
Hi
the system. AI engine device driver manages its partitions.
>
> Applications can access AI engine partition through the AI engine
> partition driver instance. AI engine registers write is moved to kernel
> as there are registers in the AI engine array needs privilege
> permissio
On 17-11-20, 16:38, JC Kuo wrote:
> In commit "phy: tegra: xusb: Add usb-phy support", an OTG capable PHY
> device, such as phy-usb2.0 device of Jetson-TX1 platform, will be
> bound to the tegra-xusb-padctl driver by the following line in
> tegra_xusb_setup_usb_role_switch().
>
>
Create AI engine device/partition hierarchical structure.
Each AI engine device can have multiple logical partitions(groups of AI
engine tiles). Each partition is column based and has its own node ID
in the system. AI engine device driver manages its partitions.
Applications can access AI engine
On Tue, Nov 17, 2020 at 04:38:03PM +0800, JC Kuo wrote:
> In commit "phy: tegra: xusb: Add usb-phy support", an OTG capable PHY
> device, such as phy-usb2.0 device of Jetson-TX1 platform, will be
> bound to the tegra-xusb-padctl driver by the following line in
> tegra_xusb_setup_usb_role_switch().
One Xilinx AI engine device can have multiple partitions (groups of
> + AI engine tiles). Xilinx AI engine device driver instance manages
> + AI engine partitions. User application access its partitions through
> + AI engine partition instance file o
--git a/drivers/dma/hiedmacv310.c b/drivers/dma/hiedmacv310.c
new file mode 100644
index ..23814f3f2305
--- /dev/null
+++ b/drivers/dma/hiedmacv310.c
@@ -0,0 +1,1441 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * The Hiedma Controller v310 Device Driver for HiSilicon
+ *
+ * Copyright (c) 2019-2
--git a/drivers/dma/hiedmacv310.c b/drivers/dma/hiedmacv310.c
new file mode 100644
index ..23814f3f2305
--- /dev/null
+++ b/drivers/dma/hiedmacv310.c
@@ -0,0 +1,1441 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * The Hiedma Controller v310 Device Driver for HiSilicon
+ *
+ * Copyright (c) 2019-2
Create AI engine device/partition hierarchical structure.
Each AI engine device can have multiple logical partitions(groups of AI
engine tiles). Each partition is column based and has its own node ID
in the system. AI engine device driver manages its partitions.
Applications can access AI engine
Create AI engine device/partition hierarchical structure.
Each AI engine device can have multiple logical partitions(groups of AI
engine tiles). Each partition is column based and has its own node ID
in the system. AI engine device driver manages its partitions.
Applications can access AI engine
Hello Guenter,
Thanks for the review. Comments inline.
On 11/8/20 6:26 PM, Guenter Roeck wrote:
> On Tue, Oct 20, 2020 at 08:21:11AM +0200, Ahmad Fatoum wrote:
>> Driver so far wasn't ported to the driver model and set up its
>> miscdevice out of the init after probing the I/O ports for a
In commit "phy: tegra: xusb: Add usb-phy support", an OTG capable PHY
device, such as phy-usb2.0 device of Jetson-TX1 platform, will be
bound to the tegra-xusb-padctl driver by the following line in
tegra_xusb_setup_usb_role_switch().
port->usb_phy.dev->driver = port->padctl->dev->driver;
Hi Dongjiu,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on vkoul-dmaengine/next]
[also build test WARNING on robh/for-next pza/reset/next v5.10-rc3
next-20201113]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting
rs/dma/hiedmacv310.c
new file mode 100644
index ..cd1fe30538ee
--- /dev/null
+++ b/drivers/dma/hiedmacv310.c
@@ -0,0 +1,1452 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * The Hiedma Controller v310 Device Driver for HiSilicon
+ *
+ * Copyright (c) 2019-2020, Huawei Tech. Co., Ltd.
+ *
rs/dma/hiedmacv310.c
new file mode 100644
index ..cd1fe30538ee
--- /dev/null
+++ b/drivers/dma/hiedmacv310.c
@@ -0,0 +1,1452 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * The Hiedma Controller v310 Device Driver for HiSilicon
+ *
+ * Copyright (c) 2019-2020, Huawei Tech. Co., Ltd.
+ *
On Tue, Oct 20, 2020 at 08:21:11AM +0200, Ahmad Fatoum wrote:
> Driver so far wasn't ported to the driver model and set up its
> miscdevice out of the init after probing the I/O ports for a watchdog
> with correct vendor and device revision.
>
> Keep the device detection part at init time, but
Driver so far wasn't ported to the driver model and set up its
miscdevice out of the init after probing the I/O ports for a watchdog
with correct vendor and device revision.
Keep the device detection part at init time, but move watchdog setup
to a platform driver probe function.
While at it,
On Thu, Oct 8, 2020 at 1:24 AM Kuppuswamy, Sathyanarayanan
wrote:
>
>
> On 10/7/20 4:31 AM, Ethan Zhao wrote:
> > During DPC error injection test we found there is race condition between
> > pciehp and DPC driver, NULL pointer dereference caused panic as following
> >
> > # setpci -s 64:02.0
On 10/7/20 4:31 AM, Ethan Zhao wrote:
During DPC error injection test we found there is race condition between
pciehp and DPC driver, NULL pointer dereference caused panic as following
# setpci -s 64:02.0 0x196.w=000a
// 64:02.0 is rootport has DPC capability
# setpci -s 65:00.0
During DPC error injection test we found there is race condition between
pciehp and DPC driver, NULL pointer dereference caused panic as following
# setpci -s 64:02.0 0x196.w=000a
// 64:02.0 is rootport has DPC capability
# setpci -s 65:00.0 0x04.w=0544
// 65:00.0 is NVMe SSD populated in
During DPC error injection test we found there is race condition between
pciehp and DPC driver, NULL pointer dereference caused panic as following
# setpci -s 64:02.0 0x196.w=000a
// 64:02.0 is rootport has DPC capability
# setpci -s 65:00.0 0x04.w=0544
// 65:00.0 is NVMe SSD populated in
During DPC error injection test we found there is race condition between
pciehp and DPC driver, NULL pointer dereference caused panic as following
# setpci -s 64:02.0 0x196.w=000a
// 64:02.0 is rootport has DPC capability
# setpci -s 65:00.0 0x04.w=0544
// 65:00.0 is NVMe SSD populated in
On Tue, Sep 29, 2020 at 6:48 PM Andy Shevchenko
wrote:
>
> On Tue, Sep 29, 2020 at 05:38:00PM +0800, Ethan Zhao wrote:
> > On Tue, Sep 29, 2020 at 4:51 PM Andy Shevchenko
> > wrote:
> > > On Tue, Sep 29, 2020 at 10:35:14AM +0800, Ethan Zhao wrote:
> > > > Preferred style, there will be cleared
On Tue, Sep 29, 2020 at 05:38:00PM +0800, Ethan Zhao wrote:
> On Tue, Sep 29, 2020 at 4:51 PM Andy Shevchenko
> wrote:
> > On Tue, Sep 29, 2020 at 10:35:14AM +0800, Ethan Zhao wrote:
> > > Preferred style, there will be cleared comment in v6.
> >
> > Avoid top postings.
> >
> > > On Sat, Sep 26,
Andy,
On Tue, Sep 29, 2020 at 4:51 PM Andy Shevchenko
wrote:
>
> On Tue, Sep 29, 2020 at 10:35:14AM +0800, Ethan Zhao wrote:
> > Preferred style, there will be cleared comment in v6.
>
> Avoid top postings.
>
> > On Sat, Sep 26, 2020 at 12:42 AM Andy Shevchenko
> > wrote:
> > >
> > > On Thu,
On Tue, Sep 29, 2020 at 10:35:14AM +0800, Ethan Zhao wrote:
> Preferred style, there will be cleared comment in v6.
Avoid top postings.
> On Sat, Sep 26, 2020 at 12:42 AM Andy Shevchenko
> wrote:
> >
> > On Thu, Sep 24, 2020 at 10:34:21PM -0400, Ethan Zhao wrote:
> > > During DPC error
Preferred style, there will be cleared comment in v6.
Thanks,
Ethan
On Sat, Sep 26, 2020 at 12:42 AM Andy Shevchenko
wrote:
>
> On Thu, Sep 24, 2020 at 10:34:21PM -0400, Ethan Zhao wrote:
> > During DPC error injection test we found there is race condition between
> > pciehp and DPC driver,
On Mon, Sep 28, 2020 at 4:46 PM Andy Shevchenko
wrote:
>
> On Mon, Sep 28, 2020 at 7:13 AM Ethan Zhao wrote:
>
> Same comments as per v4.
> Also you have an issue in versioning here. Use -v parameter to `git
> format-patch`, it will do it for you nicely.
Aha, git has got this function. I
On Mon, Sep 28, 2020 at 7:13 AM Ethan Zhao wrote:
Same comments as per v4.
Also you have an issue in versioning here. Use -v parameter to `git
format-patch`, it will do it for you nicely.
--
With Best Regards,
Andy Shevchenko
During DPC error injection test we found there is race condition between
pciehp and DPC driver, NULL pointer reference caused panic as following
# setpci -s 64:02.0 0x196.w=000a
// 64:02.0 is rootport has DPC capability
# setpci -s 65:00.0 0x04.w=0544
// 65:00.0 is NVMe SSD populated in
During DPC error injection test we found there is race condition between
pciehp and DPC driver, NULL pointer reference caused panic as following
# setpci -s 64:02.0 0x196.w=000a
// 64:02.0 is rootport has DPC capability
# setpci -s 65:00.0 0x04.w=0544
// 65:00.0 is NVMe SSD populated in
During DPC error injection test we found there is race condition between
pciehp and DPC driver, NULL pointer reference caused panic as following
# setpci -s 64:02.0 0x196.w=000a
// 64:02.0 is rootport has DPC capability
# setpci -s 65:00.0 0x04.w=0544
// 65:00.0 is NVMe SSD populated in
During DPC error injection test we found there is race condition between
pciehp and DPC driver, NULL pointer reference caused panic as following
# setpci -s 64:02.0 0x196.w=000a
// 64:02.0 is rootport has DPC capability
# setpci -s 65:00.0 0x04.w=0544
// 65:00.0 is NVMe SSD populated in
On Thu, Sep 24, 2020 at 10:34:21PM -0400, Ethan Zhao wrote:
> During DPC error injection test we found there is race condition between
> pciehp and DPC driver, null pointer reference caused panic as following
null -> NULL
>
> # setpci -s 64:02.0 0x196.w=000a
> // 64:02.0 is rootport has DPC
The Nitro Enclaves PCI device is used by the kernel driver as a means of
communication with the hypervisor on the host where the primary VM and
the enclaves run. It handles requests with regard to enclave lifetime.
Setup the PCI device driver and add support for MSI-X interrupts.
Changelog
v9
Update Git URL to
git://git.kernel.org/pub/scm/linux/kernel/git/jarkko/linux-tpmdd.git
This is done for availability reasons, i.e. better infrastructure.
Cc: Mauro Carvalho Chehab
Cc: "David S. Miller"
Cc: Rob Herring
Signed-off-by: Jarkko Sakkinen
---
I'm happy to include this to my next
:00:00 2001
From: Harald Freudenberger
Date: Thu, 10 Sep 2020 11:32:43 +0200
Subject: [PATCH] s390/zcrypt: remove set_fs() invocation in zcrypt device
driver
This patch reworks the zcrypt device driver so that the set_fs()
invocation is not needed any more. Instead there is a new flag bool
usersp
On Mon, Sep 14, 2020 at 09:36:07AM +0200, Harald Freudenberger wrote:
> Christoph, maybe you have a greater idea on how to solve this. So don't
> hesitate and tell me.
> Otherwise how to we provide this fix then ? My recommendation would be to go
> the 'usual' way:
> Commit this s390 internal
On Mon, Sep 14, 2020 at 09:36:07AM +0200, Harald Freudenberger wrote:
> Otherwise how to we provide this fix then ? My recommendation would
> be to go the 'usual' way: Commit this s390 internal and then let
> this go out with the next kernel merge window when next time Linus
> is pulling patches
On 11.09.20 08:21, Christoph Hellwig wrote:
> On Thu, Sep 10, 2020 at 12:28:38PM +0200, Harald Freudenberger wrote:
>> +static inline unsigned long z_copy_from_user(bool userspace,
>> + void *to, const void __user *from,
>> unsigned long n)
> Can you avoid
On Thu, Sep 10, 2020 at 12:28:38PM +0200, Harald Freudenberger wrote:
> +static inline unsigned long z_copy_from_user(bool userspace,
> + void *to, const void __user *from,
> unsigned long n)
Can you avoid the pointless long lines in the function
This patch reworks the zcrypt device driver so that the set_fs()
invocation is not needed any more. Instead there is a new flag bool
userspace passed through all the functions which tells if the pointer
arguments are userspace or kernelspace. Together with the two new
inline functions
The Nitro Enclaves PCI device is used by the kernel driver as a means of
communication with the hypervisor on the host where the primary VM and
the enclaves run. It handles requests with regard to enclave lifetime.
Setup the PCI device driver and add support for MSI-X interrupts.
Signed-off
This commit introduces a new misc device driver for the Intel(r) Dynamic
Load Balancer 2.0 (Intel(r) DLB 2.0). The Intel DLB 2.0 is a PCIe device that
provides load-balanced, prioritized scheduling of core-to-core communication.
The Intel DLB 2.0 consists of queues and arbiters that connect
From: Bastien Nocera
commit d5643d2249b279077427b2c2b2ffae9b70c95b0b upstream.
When a new device with a specialised device driver is plugged in, the
new driver will be modprobe()'d but the driver core will attach the
"generic" driver to the device.
After that, nothing will trigger
The Nitro Enclaves PCI device is used by the kernel driver as a means of
communication with the hypervisor on the host where the primary VM and
the enclaves run. It handles requests with regard to enclave lifetime.
Setup the PCI device driver and add support for MSI-X interrupts.
Signed-off
This commit introduces a new misc device driver for the Intel(r) Dynamic
Load Balancer 2.0 (Intel(r) DLB 2.0). The Intel DLB 2.0 is a PCIe device that
provides load-balanced, prioritized scheduling of core-to-core communication.
The Intel DLB 2.0 consists of queues and arbiters that connect
The Nitro Enclaves PCI device is used by the kernel driver as a means of
communication with the hypervisor on the host where the primary VM and
the enclaves run. It handles requests with regard to enclave lifetime.
Setup the PCI device driver and add support for MSI-X interrupts.
Signed-off
1 - 100 of 3054 matches
Mail list logo
