On Fri, Mar 26, 2021 at 3:02 PM kernel test robot wrote:
>
> Hi Nick,
>
> Thank you for the patch! Perhaps something to improve:
>
> [auto build test WARNING on cryptodev/master]
> [also build test WARNING on kdave/for-next f2fs/dev-test linus/master
> v5.12-rc4 next-20210326]
> [cannot apply to
Hi Nick,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on cryptodev/master]
[also build test WARNING on kdave/for-next f2fs/dev-test linus/master v5.12-rc4
next-20210326]
[cannot apply to crypto/master kees/for-next/pstore squashfs/master]
[If your patch is appl
hris Chiu wrote:
>>>>> Hi Guys,
>>>>> We have received reports that on some Kabylake laptops (Acer Swift
>>>>> SF314-54/55 and Lenovo Yoga C930...etc), all sound cards no longer be
>>>>> detected after upgrade to kernel later tha
Yoga C930...etc), all sound cards no longer be
detected after upgrade to kernel later than 5.8. These laptops have
one thing in common, all of them have Realtek audio codec and connect
the internal microphone to DMIC of the Intel SST controller either
[8086:9d71] or [8086:9dc8]. Please refer to
-54/55 and Lenovo Yoga C930...etc), all sound cards no longer be
>>> detected after upgrade to kernel later than 5.8. These laptops have
>>> one thing in common, all of them have Realtek audio codec and connect
>>> the internal microphone to DMIC of the Intel SST con
On 2021-03-11 6:50 AM, Chris Chiu wrote:
On Tue, Mar 9, 2021 at 11:29 PM Cezary Rojewski
wrote:
...
Topologies for most common skylake driver configurations:
- skl/kbl with i2s rt286
- apl/glk with i2s rt298
- with hda dsp
can be found in alsa-topology-conf [2].
Standard, official tool c
On Tue, Mar 9, 2021 at 11:29 PM Cezary Rojewski
wrote:
>
> On 2021-03-09 1:19 PM, Chris Chiu wrote:
> > Hi Guys,
> > We have received reports that on some Kabylake laptops (Acer Swift
> > SF314-54/55 and Lenovo Yoga C930...etc), all sound cards no longer be
>
On 2021-03-09 1:19 PM, Chris Chiu wrote:
Hi Guys,
We have received reports that on some Kabylake laptops (Acer Swift
SF314-54/55 and Lenovo Yoga C930...etc), all sound cards no longer be
detected after upgrade to kernel later than 5.8. These laptops have
one thing in common, all of them
Hi Guys,
We have received reports that on some Kabylake laptops (Acer Swift
SF314-54/55 and Lenovo Yoga C930...etc), all sound cards no longer be
detected after upgrade to kernel later than 5.8. These laptops have
one thing in common, all of them have Realtek audio codec and connect
the
Currently NVME (and probably other drivers) require CAP_SYS_ADMIN to
send all commands to the device. This means that software running
in userspace needs the stronger CAP_SYS_ADMIN permission when realistically
a more limited subset of functionality is actually needed.
To allow software that perf
tions(-)
diff --git a/arch/arm64/include/asm/virt.h b/arch/arm64/include/asm/virt.h
index ee6a48df89d9..7379f35ae2c6 100644
--- a/arch/arm64/include/asm/virt.h
+++ b/arch/arm64/include/asm/virt.h
@@ -35,8 +35,13 @@
*/
#define HVC_RESET_VECTORS 2
+/*
+ * HVC_VHE_RESTART - Upgrade the CPU from E
tions(-)
diff --git a/arch/arm64/include/asm/virt.h b/arch/arm64/include/asm/virt.h
index ee6a48df89d9..7379f35ae2c6 100644
--- a/arch/arm64/include/asm/virt.h
+++ b/arch/arm64/include/asm/virt.h
@@ -35,8 +35,13 @@
*/
#define HVC_RESET_VECTORS 2
+/*
+ * HVC_VHE_RESTART - Upgrade the CPU from E
/arch/arm64/include/asm/virt.h b/arch/arm64/include/asm/virt.h
index ee6a48df89d9..7379f35ae2c6 100644
--- a/arch/arm64/include/asm/virt.h
+++ b/arch/arm64/include/asm/virt.h
@@ -35,8 +35,13 @@
*/
#define HVC_RESET_VECTORS 2
+/*
+ * HVC_VHE_RESTART - Upgrade the CPU from EL1 to EL2, if pos
On Mon, Jan 25, 2021 at 10:50:02AM +, Marc Zyngier wrote:
> As we are about to change the way a VHE system boots, let's
> provide the core helper, in the form of a stub hypercall that
> enables VHE and replicates the full EL1 context at EL2, thanks
> to EL1 and VHE-EL2 being extremely similar.
rm64/include/asm/virt.h
> > index ee6a48df89d9..7379f35ae2c6 100644
> > --- a/arch/arm64/include/asm/virt.h
> > +++ b/arch/arm64/include/asm/virt.h
> > @@ -35,8 +35,13 @@
> > */
> > #define HVC_RESET_VECTORS 2
> >
> > +/*
> > + * HVC_VHE_
If you are not using the test-definitions project to run kselftest,
please ignore this email.
A new run script for kselftest, run_kselftest.sh [1], was created during the
Linux v5.10 release.
This script allows someone to run both individual test cases and sets of
test cases. Accordingly, the tes
t.h
> @@ -35,8 +35,13 @@
> */
> #define HVC_RESET_VECTORS 2
>
> +/*
> + * HVC_VHE_RESTART - Upgrade the CPU from EL1 to EL2, if possible
> + */
> +#define HVC_VHE_RESTART 3
> +
> /* Max number of HYP stub hypercalls */
> -#define HVC_STUB_HCALL_NR 3
> +
t.h b/arch/arm64/include/asm/virt.h
index ee6a48df89d9..7379f35ae2c6 100644
--- a/arch/arm64/include/asm/virt.h
+++ b/arch/arm64/include/asm/virt.h
@@ -35,8 +35,13 @@
*/
#define HVC_RESET_VECTORS 2
+/*
+ * HVC_VHE_RESTART - Upgrade the CPU from EL1 to EL2, if possible
+ */
+#define HVC_VHE_RE
tions(+), 3 deletions(-)
diff --git a/arch/arm64/include/asm/virt.h
b/arch/arm64/include/asm/virt.h
index ee6a48df89d9..7379f35ae2c6 100644
--- a/arch/arm64/include/asm/virt.h
+++ b/arch/arm64/include/asm/virt.h
@@ -35,8 +35,13 @@
*/
#define HVC_RESET_VECTORS 2
+/*
+ * HVC_VHE_RESTART - Up
t.h b/arch/arm64/include/asm/virt.h
index ee6a48df89d9..7379f35ae2c6 100644
--- a/arch/arm64/include/asm/virt.h
+++ b/arch/arm64/include/asm/virt.h
@@ -35,8 +35,13 @@
*/
#define HVC_RESET_VECTORS 2
+/*
+ * HVC_VHE_RESTART - Upgrade the CPU from EL1 to EL2, if possible
+ */
+#define HVC_VHE_RE
that by introducing a new update_time inode operation. There, if
the glock is held non-exclusively, upgrade it to an exclusive lock.
Reported-by: Alexander Aring
Fixes: 20f82c38 ("gfs2: Rework read and page fault locking")
Cc: sta...@vger.kernel.org # v5.8+
Signed-off-by: Andreas Gru
On Thu, Dec 03, 2020 at 07:58:16AM +0800, kernel test robot wrote:
> All warnings (new ones prefixed by >>):
>
>lib/zstd/compress/zstd_double_fast.c: In function
> 'ZSTD_compressBlock_doubleFast_extDict_generic':
> >> lib/zstd/compress/zstd_double_fast.c:501:1: warning: the frame size of
> >
Hi Nick,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on cryptodev/master]
[also build test WARNING on kdave/for-next f2fs/dev-test kees/for-next/pstore
linus/master v5.10-rc6]
[cannot apply to crypto/master squashfs/master next-20201201]
[If your patch is appl
On Thu, Nov 19, 2020 at 06:55:11PM +0300, Mika Westerberg wrote:
> Hi all,
>
> This series improves the USB4 router NVM upgrade functionality and adds
> support for USB4 router operations proxy implemented by recent Intel
> Thunderbolt firmware connection manager. The last patch a
better what the spec suggests.
For this reason do the same what we already do with the Thunderbolt 3
devices and perform the NVM upgrade in two phases. First start the
NVM_AUTH router operation and once the router is added back after the
reset read the status in ROUTER_CS_26 and expose it to the
Hi all,
This series improves the USB4 router NVM upgrade functionality and adds
support for USB4 router operations proxy implemented by recent Intel
Thunderbolt firmware connection manager. The last patch adds support for
Intel Maple Ridge that is the first discrete Thunderbolt/USB4 controller
Hi Nick,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on cryptodev/master]
[also build test WARNING on kdave/for-next f2fs/dev-test linus/master v5.10-rc3
next-20201113]
[cannot apply to crypto/master squashfs/master]
[If your patch is applied to the wrong git
Hi Nick,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on cryptodev/master]
[also build test WARNING on kdave/for-next f2fs/dev-test linus/master v5.10-rc3
next-20201112]
[cannot apply to crypto/master]
[If your patch is applied to the wrong git tree, kindly dro
On Tue, Nov 03, 2020 at 12:17:17PM +, Will Deacon wrote:
> Hi all,
>
> These patches were previously posted as part of a larger series enabling
> architectures to override __READ_ONCE():
>
> v3: https://lore.kernel.org/lkml/20200710165203.31284-1-w...@kernel.org/
>
> With the bulk of that
Hi all,
These patches were previously posted as part of a larger series enabling
architectures to override __READ_ONCE():
v3: https://lore.kernel.org/lkml/20200710165203.31284-1-w...@kernel.org/
With the bulk of that merged, the four patches here override READ_ONCE()
so that it gains RCpc acqu
anges in OCREATE mdc record.
+ */
+static struct upgrade_history mdcrec_data_ocreate_table[]
+ = {
+ {
+ sizeof(struct omf_mdcrec_data),
+ omf_pmd_layout_unpack_letoh_v1,
+ NULL,
+ OMF_SB_DESC_UNDEF,
+ { {1, 0, 0, 0} }
+ },
+};
+
+
+/*
+ * Generic rou
Hi Nick,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on kdave/for-next]
[also build test WARNING on f2fs/dev-test linus/master v5.9-rc7 next-20201001]
[cannot apply to cryptodev/master crypto/master]
[If your patch is applied to the wrong git tree, kindly drop
omf_pmd_layout_unpack_letoh_v1,
+ NULL,
+ OMF_SB_DESC_UNDEF,
+ { {1, 0, 0, 0} }
+ },
+};
+
+
+/*
+ * Generic routines
+ */
+
+/**
+ * omf_find_upgrade_hist() - Find the upgrade history entry for the given sb
or mdc version
+ * @uhtab:
+ * @tabsz: NELEM
Hi Nick,
Thanks for the feedback, we'll take a look at these errors that maybe
false positives.
Best Regards,
Rong Chen
On 9/24/20 11:05 AM, Nick Terrell wrote:
On Wed, Sep 23, 2020 at 7:28 PM kernel test robot wrote:
Hi Nick,
Thank you for the patch! Yet something to improve:
[auto buil
On Wed, Sep 23, 2020 at 7:28 PM kernel test robot wrote:
>
> Hi Nick,
>
> Thank you for the patch! Yet something to improve:
>
> [auto build test ERROR on kdave/for-next]
> [also build test ERROR on f2fs/dev-test linus/master v5.9-rc6 next-20200923]
> [cannot apply to cryptodev/master crypto/maste
Hi Nick,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on kdave/for-next]
[also build test ERROR on f2fs/dev-test linus/master v5.9-rc6 next-20200923]
[cannot apply to cryptodev/master crypto/master]
[If your patch is applied to the wrong git tree, kindly drop us a not
Hi Nick,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on kdave/for-next]
[also build test WARNING on f2fs/dev-test linus/master v5.9-rc6 next-20200923]
[cannot apply to cryptodev/master crypto/master]
[If your patch is applied to the wrong git tree, kindly drop
> On Sep 15, 2020, at 8:42 PM, Nick Terrell wrote:
>
> From: Nick Terrell
>
> Upgrade to the latest upstream zstd version 1.4.6.
>
> This patch is 100% generated from upstream zstd commit c4763f087c2b [0].
>
> This patch is very large because it is transitioning fr
Hi Nick,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on kdave/for-next]
[also build test WARNING on f2fs/dev-test linus/master v5.9-rc5 next-20200915]
[cannot apply to cryptodev/master crypto/master squashfs/master]
[If your patch is applied to the wrong git tr
On 9/7/20 9:02 AM, Vaibhav Gupta wrote:
> Linux Kernel Mentee: Remove Legacy Power Management.
>
> The original goal of the patch series is to upgrade the power management
> framework of radeonfb fbdev driver. This has been done by upgrading .suspend()
> and .resume() call
> The original goal of the patch series is to upgrade the power management
> > > framework of radeonfb fbdev driver. This has been done by upgrading
> > > .suspend()
> > > and .resume() callbacks.
> > >
> > > The upgrade makes sure that the involve
On Mon, 2020-09-07 at 09:55 +0200, Daniel Vetter wrote:
> On Thu, Aug 06, 2020 at 12:52:54PM +0530, Vaibhav Gupta wrote:
> > Linux Kernel Mentee: Remove Legacy Power Management.
> >
> > The original goal of the patch series is to upgrade the power
> > management
>
On 2020-09-07 9:55 a.m., Daniel Vetter wrote:
On Thu, Aug 06, 2020 at 12:52:54PM +0530, Vaibhav Gupta wrote:
Linux Kernel Mentee: Remove Legacy Power Management.
The original goal of the patch series is to upgrade the power management
framework of radeonfb fbdev driver. This has been done by
On Mon, Sep 07, 2020 at 09:55:59AM +0200, Daniel Vetter wrote:
> On Thu, Aug 06, 2020 at 12:52:54PM +0530, Vaibhav Gupta wrote:
> > Linux Kernel Mentee: Remove Legacy Power Management.
> >
> > The original goal of the patch series is to upgrade the power management
>
On Thu, Aug 06, 2020 at 12:52:54PM +0530, Vaibhav Gupta wrote:
> Linux Kernel Mentee: Remove Legacy Power Management.
>
> The original goal of the patch series is to upgrade the power management
> framework of radeonfb fbdev driver. This has been done by upgrading .suspend()
&
Linux Kernel Mentee: Remove Legacy Power Management.
The original goal of the patch series is to upgrade the power management
framework of radeonfb fbdev driver. This has been done by upgrading .suspend()
and .resume() callbacks.
The upgrade makes sure that the involvement of PCI Core does not
On Mon, Sep 07, 2020 at 12:01:53PM +0530, Vaibhav Gupta wrote:
> Please review this patch-series.
I see no patch here :(
Please review this patch-series.
Thank you
Vaibhav Gupta
Linux Kernel Mentee: Remove Legacy Power Management.
The original goal of the patch series is to upgrade the power management
framework of radeonfb fbdev driver. This has been done by upgrading .suspend()
and .resume() callbacks.
The upgrade makes sure that the involvement of PCI Core does not
Linux Kernel Mentee: Remove Legacy Power Management.
The original goal of the patch series is to upgrade the power management
framework of radeonfb fbdev driver. This has been done by upgrading .suspend()
and .resume() callbacks.
The upgrade makes sure that the involvement of PCI Core does not
Linux Kernel Mentee: Remove Legacy Power Management.
The purpose of this patch series is to upgrade power management in i2c-eg20t
driver. This has been done by upgrading .suspend() and .resume() callbacks.
The upgrade makes sure that the involvement of PCI Core does not change the
order of
ensure device writes are visible before the
+ * task is marked as available for scheduling on a new hart. While I don't see
+ * any concrete reason we need a full IO fence, it seems safer to just upgrade
+ * this in order to avoid any IO crossing a scheduling boundary. In both
+ * instan
ensure device writes are visible before the
+ * task is marked as available for scheduling on a new hart. While I don't see
+ * any concrete reason we need a full IO fence, it seems safer to just upgrade
+ * this in order to avoid any IO crossing a scheduling boundary. In both
+ * instan
ensure device writes are visible before the
+ * task is marked as available for scheduling on a new hart. While I don't see
+ * any concrete reason we need a full IO fence, it seems safer to just upgrade
+ * this in order to avoid any IO crossing a scheduling boundary. In both
+ * instan
egions we need at least
+ * an "o" in the predecessor set to ensure device writes are visible before the
+ * task is marked as available for scheduling on a new hart. While I don't see
+ * any concrete reason we need a full IO fence, it seems safer to just upgrade
+ * this in order t
ensure device writes are visible before the
+ * task is marked as available for scheduling on a new hart. While I don't see
+ * any concrete reason we need a full IO fence, it seems safer to just upgrade
+ * this in order to avoid any IO crossing a scheduling boundary. In both
+ * instan
ensure device writes are visible before the
+ * task is marked as available for scheduling on a new hart. While I don't see
+ * any concrete reason we need a full IO fence, it seems safer to just upgrade
+ * this in order to avoid any IO crossing a scheduling boundary. In both
+ * instan
ensure device writes are visible before the
+ * task is marked as available for scheduling on a new hart. While I don't see
+ * any concrete reason we need a full IO fence, it seems safer to just upgrade
+ * this in order to avoid any IO crossing a scheduling boundary. In both
+ * instan
. The removal of
the reorder_objects atomic missed that the memory barrier in
padata_do_serial() depends on it.
Upgrade the barrier from smp_mb__after_atomic to smp_mb to get correct
ordering again.
Fixes: 3facced7aeed1 ("padata: remove reorder_objects")
Signed-off-by: Daniel Jordan
C
at 15:32:49 -0600, Shuah Khan wrote:
> > > > On 7/2/20 1:44 PM, Jarkko Sakkinen wrote:
> > > > > On Fri, Jun 26, 2020 at 11:40:52AM +0800, Pengfei Xu wrote:
> > > > > > Python 2 is no longer supported by the Python upstream project, so
> > > &
longer supported by the Python upstream project, so
upgrade TPM2 tests to Python 3.
Signed-off-by: Pengfei Xu
I think that it's perfect now. Thank you.
Also
1. I checked that scripts/checkpatch.pl did not report any errors.
2. sudo python3 -m unittest -v tpm2_tests.SmokeTest
3. sudo pytho
project, so
upgrade TPM2 tests to Python 3.
Signed-off-by: Pengfei Xu
I think that it's perfect now. Thank you.
Also
1. I checked that scripts/checkpatch.pl did not report any errors.
2. sudo python3 -m unittest -v tpm2_tests.SmokeTest
3. sudo python3 -m unittest -v tpm2_tests.SpaceTest
Rev
Thanks a lot Jarkko and Shuah!
BR.
Thanks!
On 2020-07-02 at 15:32:49 -0600, Shuah Khan wrote:
> On 7/2/20 1:44 PM, Jarkko Sakkinen wrote:
> > On Fri, Jun 26, 2020 at 11:40:52AM +0800, Pengfei Xu wrote:
> > > Python 2 is no longer supported by the Python upstream project, so
On 7/2/20 1:44 PM, Jarkko Sakkinen wrote:
On Fri, Jun 26, 2020 at 11:40:52AM +0800, Pengfei Xu wrote:
Python 2 is no longer supported by the Python upstream project, so
upgrade TPM2 tests to Python 3.
Signed-off-by: Pengfei Xu
I think that it's perfect now. Thank you.
Also
1. I ch
On Fri, Jun 26, 2020 at 11:40:52AM +0800, Pengfei Xu wrote:
> Python 2 is no longer supported by the Python upstream project, so
> upgrade TPM2 tests to Python 3.
>
> Signed-off-by: Pengfei Xu
I think that it's perfect now. Thank you.
Also
1. I checked that scripts/chec
Python 2 is no longer supported by the Python upstream project, so
upgrade TPM2 tests to Python 3.
Signed-off-by: Pengfei Xu
---
tools/testing/selftests/tpm2/test_smoke.sh | 4 +-
tools/testing/selftests/tpm2/test_space.sh | 2 +-
tools/testing/selftests/tpm2/tpm2.py | 56
Hi Jarkko,
I missed this improvement in previous mail.
Will do.
Thanks!
BR.
On 2020-06-26 at 00:51:45 +0300, Jarkko Sakkinen wrote:
> On Fri, Jun 26, 2020 at 12:37:54AM +0800, Pengfei Xu wrote:
> > Python 2 is no longer supported by the Python upstream project, so
> > upgrad
On Fri, Jun 26, 2020 at 12:37:54AM +0800, Pengfei Xu wrote:
> Python 2 is no longer supported by the Python upstream project, so
> upgrade TPM2 tests to Python 3.
>
> Signed-off-by: Pengfei Xu
> ---
> tools/testing/selftests/tpm2/test_smoke.sh | 4 +-
> tools/t
Python 2 is no longer supported by the Python upstream project, so
upgrade TPM2 tests to Python 3.
Signed-off-by: Pengfei Xu
---
tools/testing/selftests/tpm2/test_smoke.sh | 4 +-
tools/testing/selftests/tpm2/test_space.sh | 2 +-
tools/testing/selftests/tpm2/tpm2.py | 56
On 2020-06-25 at 02:14:57 +0300, Jarkko Sakkinen wrote:
> On Tue, Jun 23, 2020 at 07:41:55PM +0800, Pengfei Xu wrote:
> > I tried to use bytes(parm, encoding='UTF-8') way, it met the situation
> > that sometimes parm is string, sometimes parm is bytes.
>
> We need to do right things right, i.e
On Tue, Jun 23, 2020 at 07:41:55PM +0800, Pengfei Xu wrote:
> I tried to use bytes(parm, encoding='UTF-8') way, it met the situation
> that sometimes parm is string, sometimes parm is bytes.
We need to do right things right, i.e. you should fix in the call site,
not in the implementation.
/Ja
o longer supported by the Python upstream project, so
> > > upgrade TPM2 tests to Python 3.
> > >
> > > Signed-off-by: Pengfei Xu
> >
> > Use "selftests: tpm: ".
> >
Will do.
> > > ---
> > > tools/testing/
On Tue, Jun 23, 2020 at 12:46:18AM +0300, Jarkko Sakkinen wrote:
> On Thu, Jun 18, 2020 at 04:15:02PM +0800, Pengfei Xu wrote:
> > Python 2 is no longer supported by the Python upstream project, so
> > upgrade TPM2 tests to Python 3.
> >
> > Signed-off-by: Pengfei X
On Thu, Jun 18, 2020 at 04:15:02PM +0800, Pengfei Xu wrote:
> Python 2 is no longer supported by the Python upstream project, so
> upgrade TPM2 tests to Python 3.
>
> Signed-off-by: Pengfei Xu
Use "selftests: tpm: ".
> ---
> tools/testing/selftests/tpm2/test_smoke
Python 2 is no longer supported by the Python upstream project, so
upgrade TPM2 tests to Python 3.
Signed-off-by: Pengfei Xu
---
tools/testing/selftests/tpm2/test_smoke.sh | 4 +-
tools/testing/selftests/tpm2/test_space.sh | 2 +-
tools/testing/selftests/tpm2/tpm2.py | 68
e request. The removal of
> the reorder_objects atomic missed that the memory barrier in
> padata_do_serial() depends on it.
>
> Upgrade the barrier from smp_mb__after_atomic to smp_mb to get correct
> ordering again.
>
> Fixes: 3facced7aeed1 ("padata: remove reorder_objec
Hi Jarkko,
Thanks for your advice.
My feedback is as below.
BR.
Thanks!
On 2020-06-18 at 10:18:58 +0300, Jarkko Sakkinen wrote:
> On Thu, Jun 18, 2020 at 11:02:45AM +0800, Pengfei Xu wrote:
> > Some Linux OS will never support python2 anymore, so upgrade tpm2 selftests
>
On Thu, Jun 18, 2020 at 11:02:45AM +0800, Pengfei Xu wrote:
> Some Linux OS will never support python2 anymore, so upgrade tpm2 selftests
> to python3.
>
> Signed-off-by: Pengfei Xu
Linux is a kernel, not a full operating system. Perhaps you mean Linux
distributions?
Pleas
Some Linux OS will never support python2 anymore, so upgrade tpm2 selftests
to python3.
Signed-off-by: Pengfei Xu
---
tools/testing/selftests/tpm2/test_smoke.sh | 4 +-
tools/testing/selftests/tpm2/test_space.sh | 2 +-
tools/testing/selftests/tpm2/tpm2.py | 68
Some Linux OS will never support python2 anymore, so upgrade tpm2 selftests
to python3.
Signed-off-by: Pengfei Xu
---
tools/testing/selftests/tpm2/test_smoke.sh | 4 +-
tools/testing/selftests/tpm2/test_space.sh | 2 +-
tools/testing/selftests/tpm2/tpm2.py | 68
padata_do_serial() depends on it.
Upgrade the barrier from smp_mb__after_atomic to smp_mb to get correct
ordering again.
Fixes: 3facced7aeed1 ("padata: remove reorder_objects")
Signed-off-by: Daniel Jordan
Cc: Herbert Xu
Cc: Steffen Klassert
Cc: linux-cry...@vger.kernel.org
Cc: li
From: Ronak Doshi
Date: Thu, 28 May 2020 14:53:18 -0700
> vmxnet3 emulation has recently added several new features which includes
> offload support for tunnel packets, support for new commands the driver
> can issue to emulation, change in descriptor fields, etc. This patch
> series extends the
vmxnet3 emulation has recently added several new features which includes
offload support for tunnel packets, support for new commands the driver
can issue to emulation, change in descriptor fields, etc. This patch
series extends the vmxnet3 driver to leverage these new features.
Compatibility is m
vmxnet3 emulation has recently added several new features which includes
offload support for tunnel packets, support for new commands the driver
can issue to emulation, change in descriptor fields, etc. This patch
series extends the vmxnet3 driver to leverage these new features.
Compatibility is m
vmxnet3 emulation has recently added several new features which includes
offload support for tunnel packets, support for new commands the driver
can issue to emulation, change in descriptor fields, etc. This patch
series extends the vmxnet3 driver to leverage these new features.
Compatibility is m
From: David Miller
Date: Thu, 28 May 2020 11:07:46 -0700 (PDT)
> Series applied, thank you.
This doesn't even compile successfully, reverted... :(
drivers/net/vmxnet3/vmxnet3_drv.c: In function ‘vmxnet3_tq_xmit’:
drivers/net/vmxnet3/vmxnet3_drv.c:1145:5: error: expected ‘}’ before ‘else’
1145
From: Ronak Doshi
Date: Wed, 27 May 2020 18:54:22 -0700
> vmxnet3 emulation has recently added several new features which includes
> offload support for tunnel packets, support for new commands the driver
> can issue to emulation, change in descriptor fields, etc. This patch
> series extends the
vmxnet3 emulation has recently added several new features which includes
offload support for tunnel packets, support for new commands the driver
can issue to emulation, change in descriptor fields, etc. This patch
series extends the vmxnet3 driver to leverage these new features.
Compatibility is m
vmxnet3 emulation has recently added several new features which includes
offload support for tunnel packets, support for new commands the driver
can issue to emulation, change in descriptor fields, etc. This patch
series extends the vmxnet3 driver to leverage these new features.
Compatibility is m
From: Arvind Sankar
Use efi_err if we ignore a command-line dtb= argument, so that it shows
up even on a quiet boot.
Signed-off-by: Arvind Sankar
Link: https://lore.kernel.org/r/20200430182843.2510180-8-nived...@alum.mit.edu
Signed-off-by: Ard Biesheuvel
---
drivers/firmware/efi/libstub/efi-s
From: Ilan Peer
commit 4b559ec0bfc3a9f41a127cea6964f38b2b4bb323 upstream.
It is possible that the station is connected to an AP
with bandwidth of 80+80MHz or 160MHz. In such cases
there is no need to perform an upgrade as the maximal
supported bandwidth is 80MHz.
In addition, when upgrading
Use efi_err if we ignore a command-line dtb= argument, so that it shows
up even on a quiet boot.
Signed-off-by: Arvind Sankar
---
drivers/firmware/efi/libstub/efi-stub.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/firmware/efi/libstub/efi-stub.c
b/drivers/firmwar
From: Christian Borntraeger
commit 316ec154810960052d4586b634156c54d0778f74 upstream.
A page table upgrade in a kernel section that uses secondary address
mode will mess up the kernel instructions as follows:
Consider the following scenario: two threads are sharing memory.
On CPU1 thread 1
From: Christian Borntraeger
commit 316ec154810960052d4586b634156c54d0778f74 upstream.
A page table upgrade in a kernel section that uses secondary address
mode will mess up the kernel instructions as follows:
Consider the following scenario: two threads are sharing memory.
On CPU1 thread 1
From: Christian Borntraeger
commit 316ec154810960052d4586b634156c54d0778f74 upstream.
A page table upgrade in a kernel section that uses secondary address
mode will mess up the kernel instructions as follows:
Consider the following scenario: two threads are sharing memory.
On CPU1 thread 1
From: "Paul E. McKenney"
Although the rcu_swap_protected() macro follows the example of swap(),
the interactions with RCU make its update of its argument somewhat
counter-intuitive. This commit therefore introduces an rcu_replace()
that returns the old value of the RCU pointer instead of doing t
- On Oct 3, 2019, at 3:09 PM, paulmck paul...@kernel.org wrote:
> On Thu, Oct 03, 2019 at 01:21:14PM -0400, Mathieu Desnoyers wrote:
>> - On Oct 3, 2019, at 12:52 PM, paulmck paul...@kernel.org wrote:
>>
>> > On Thu, Oct 03, 2019 at 12:35:30PM -0400, Mathieu Desnoyers wrote:
>> >> - O
On Thu, Oct 03, 2019 at 01:21:14PM -0400, Mathieu Desnoyers wrote:
> - On Oct 3, 2019, at 12:52 PM, paulmck paul...@kernel.org wrote:
>
> > On Thu, Oct 03, 2019 at 12:35:30PM -0400, Mathieu Desnoyers wrote:
> >> - On Oct 2, 2019, at 9:43 PM, paulmck paul...@kernel.org wrote:
> >>
> >> > F
On Thu, Oct 03, 2019 at 12:31:38PM -0400, Mathieu Desnoyers wrote:
> We might want to consider simply using xchg() here.
As stated elsewhere, xchg() is an atomic op with full ordering, IOW it
is stupid expensive for what needs to be done.
- On Oct 3, 2019, at 12:52 PM, paulmck paul...@kernel.org wrote:
> On Thu, Oct 03, 2019 at 12:35:30PM -0400, Mathieu Desnoyers wrote:
>> - On Oct 2, 2019, at 9:43 PM, paulmck paul...@kernel.org wrote:
>>
>> > From: "Paul E. McKenney"
>> >
>> > Although the rcu_swap_protected() macro fol
1 - 100 of 789 matches
Mail list logo
