[PATCH v2] AMD_SFH: Fix for incorrect Sensor index
From: Sandeep Singh
Add fix for incorrect sensor index and minor code clean-up.
Reported-by: Mandoli
Reported-by: Richard Neumann
Signed-off-by: Sandeep Singh
Fixes: SFH: PCIe driver to add support of AMD sensor fusion hub (4f567b9f8141)
---
Changes since v1:(https://lkml.org/lkml/2020/10/23/172)
-> Add Reported by : Richard Neumann
drivers/hid/amd-sfh-hid/amd_sfh_pcie.c | 6 +++---
.../amd-sfh-hid/hid_descriptor/amd_sfh_hid_desc.h | 14 --
2 files changed, 3 insertions(+), 17 deletions(-)
diff --git a/drivers/hid/amd-sfh-hid/amd_sfh_pcie.c
b/drivers/hid/amd-sfh-hid/amd_sfh_pcie.c
index 9c5eb442e1a6..a51c7b76283b 100644
--- a/drivers/hid/amd-sfh-hid/amd_sfh_pcie.c
+++ b/drivers/hid/amd-sfh-hid/amd_sfh_pcie.c
@@ -20,9 +20,9 @@
#define DRIVER_NAME"pcie_mp2_amd"
#define DRIVER_DESC"AMD(R) PCIe MP2 Communication Driver"
-#define ACEL_ENBIT(1)
-#define GYRO_ENBIT(2)
-#define MAGNO_EN BIT(3)
+#define ACEL_ENBIT(0)
+#define GYRO_ENBIT(1)
+#define MAGNO_EN BIT(2)
#define ALS_EN BIT(19)
void amd_start_sensor(struct amd_mp2_dev *privdata, struct amd_mp2_sensor_info
info)
diff --git a/drivers/hid/amd-sfh-hid/hid_descriptor/amd_sfh_hid_desc.h
b/drivers/hid/amd-sfh-hid/hid_descriptor/amd_sfh_hid_desc.h
index ac9a01cc1454..095c471d8fd6 100644
--- a/drivers/hid/amd-sfh-hid/hid_descriptor/amd_sfh_hid_desc.h
+++ b/drivers/hid/amd-sfh-hid/hid_descriptor/amd_sfh_hid_desc.h
@@ -16,11 +16,6 @@ enum desc_type {
feature_size,
};
-struct _hid_report_descriptor {
- u8 bDescriptorType;
- u8 wDescriptorLength;
-};
-
struct common_feature_property {
/* common properties */
u8 report_id;
@@ -38,15 +33,6 @@ struct common_input_property {
u8 event_type;
} __packed;
-struct _hid_device_descriptor {
- u8 bLength;
- u8 bDescriptorType;
- u8 bcdHID[2];
- u8 bCountryCode;
- u8 bNumDescriptors;
- struct _hid_report_descriptor *reports;
-};
-
struct accel3_feature_report {
struct common_feature_property common_property;
/* properties specific to this sensor */
--
2.25.1
Re: [PATCH] docs: driver-api: remove a duplicated index entry
Em Wed, 21 Oct 2020 15:13:44 -0600
Jonathan Corbet escreveu:
> On Thu, 15 Oct 2020 11:12:06 +0200
> Mauro Carvalho Chehab wrote:
>
> > The ipmb file was added twice at index.rst. That
> > sounds to be because the same patch was applied twice,
> > via different git trees:
> >
> > commit f6ae22d64433fd8e08654adad7966299da931bb9
> > Author: Mauro Carvalho Chehab
> > Commit: Jonathan Corbet
> >
> > docs: ipmb: place it at driver-api and convert to ReST
> >
> > commit ac499fba98c3c65078fd84fa0a62cd6f6d5837ed
> > Author: Mauro Carvalho Chehab
> > Commit: Corey Minyard
> >
> > docs: ipmb: place it at driver-api and convert to ReST
> >
> > With Sphinx 4.0.0 development tree, a new warning is produced
> > due to that:
> >
> > .../Documentation/driver-api/index.rst:14: WARNING: duplicated entry
> > found in toctree: driver-api/ipmb
> >
> > The fix is trivial: just drop the duplicated line.
> >
> > Fixes: f6ae22d64433 ("docs: ipmb: place it at driver-api and convert to
> > ReST")
> > Fixes: ac499fba98c3 ("docs: ipmb: place it at driver-api and convert to
> > ReST")
> > Signed-off-by: Mauro Carvalho Chehab
>
> Interesting...I wonder how applying the patch twice could lead to the line
> being inserted in two completely different locations like that? Anyway,
> I've applied this one, hopefully nobody else will do the same :)
Probably this was due to some manual conflict resolution when applying
one of the versions of it ;-)
No big harm, and with newer Sphinx versions, we should be able
to detect similar cases in the future.
Thanks,
Mauro
Re: [PATCH v3 01/56] scripts: kernel-doc: fix typedef parsing
Em Fri, 23 Oct 2020 11:22:26 -0600
Jonathan Corbet escreveu:
> On Fri, 23 Oct 2020 18:32:48 +0200
> Mauro Carvalho Chehab wrote:
>
> > The include/linux/genalloc.h file defined this typedef:
> >
> > typedef unsigned long (*genpool_algo_t)(unsigned long *map,unsigned
> > long size,unsigned long start,unsigned int nr,void *data, struct gen_pool
> > *pool, unsigned long start_addr);
> >
> > Because it has a type composite of two words (unsigned long),
> > the parser gets the typedef name wrong:
> >
> > .. c:macro:: long
> >
> >**Typedef**: Allocation callback function type definition
> >
> > Fix the regex in order to accept composite types when
> > defining a typedef for a function pointer.
> >
> > Signed-off-by: Mauro Carvalho Chehab
> > ---
> > scripts/kernel-doc | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/scripts/kernel-doc b/scripts/kernel-doc
> > index 99cd8418ff8a..311d213ee74d 100755
> > --- a/scripts/kernel-doc
> > +++ b/scripts/kernel-doc
> > @@ -1438,7 +1438,7 @@ sub dump_typedef($$) {
> > $x =~ s@/\*.*?\*/@@gos;# strip comments.
> >
> > # Parse function prototypes
> > -if ($x =~ /typedef\s+(\w+)\s*\(\*\s*(\w\S+)\s*\)\s*\((.*)\);/ ||
> > +if ($x =~ /typedef\s+(\w+\s*){1,}\(\*\s*(\w\S+)\s*\)\s*\((.*)\);/ ||
>
> I sure wish we could find a way to make all these regexes more
> understandable and maintainable. Reviewing a change like this is ... fun.
Yeah. Regexes can be take a while to check. Btw, there's a site that
is really cool to check things:
https://regex101.com/
Unfortunately, it doesn't support Perl flavor. So, you may still
need to double-check if Perl will handle the regex the same way[1].
[1] One of the differences I found is with regards to match repetitions
https://perldoc.perl.org/perlrequick#Matching-repetitions
This works on both Python and Perl:
(foo){0,2}
But this only works on Python:
(foo){,2}
>
> Anyway, it seems to work, but it does now include trailing whitespace in
> the type portion. So, for example, from include/linux/xarray.h:
>
> typedef void (*xa_update_node_t)(struct xa_node *node);
>
> The type is parsed as "void " where it was "void" before. The only ill
> effect I can see is that some non-breaking spaces get inserted into the
> HTML output, but perhaps it's worth stripping off that trailing space
> anyway?
Ok, I'll work on a second version addressing it.
Thanks,
Mauro
Re: [PATCH] KVM: x86/mmu: Avoid modulo operator on 64-bit value to fix i386 build
On 24/10/20 05:11, Sean Christopherson wrote:
> Replace a modulo operator with the more common pattern for computing the
> gfn "offset" of a huge page to fix an i386 build error.
>
> arch/x86/kvm/mmu/tdp_mmu.c:212: undefined reference to `__umoddi3'
>
> Fixes: 2f2fad0897cb ("kvm: x86/mmu: Add functions to handle changed TDP
> SPTEs")
> Reported-by: Daniel Díaz
> Signed-off-by: Sean Christopherson
> ---
>
> Linus, do you want to take this directly so that it's in rc1? I don't
> know whether Paolo will be checking mail before then
Yes, I am. I also have another bugfix, I was going to wait a couple
days for any -rc1 issues to pop up but they came up faster than that.
Paolo
Re: [PATCH v3 49/56] refcount.h: fix a kernel-doc markup
Em Fri, 23 Oct 2020 13:47:57 -0600
Jonathan Corbet escreveu:
> On Fri, 23 Oct 2020 21:39:07 +0200
> Peter Zijlstra wrote:
>
> > > > /**
> > > > - * struct refcount_t - variant of atomic_t specialized for reference
> > > > counts
> > > > + * struct refcount_struct - variant of atomic_t specialized for
> > > > reference counts
> > >
> > > Hm, this is a weird one. Yes, it's actually "struct refcount_struct",
> > > but the usage should be refcount_t (through the typedef). I'm not sure
> > > what the right way to document this is.
> >
> > Yeah, this is wrong. If this is due to a kernel doc warning, the kernel
> > doc machinery is wrong *again*.
This issue has nothing to do with warnings. The problem here is that
"struct" is a markup for structs, and not for typedefs.
>
> ...except that, since refcount_t is a typedef, "struct refcount_t" doesn't
> actually exist. Whether it works properly after doing s/struct// remains
> to be seen...
If the intent is to document the struct and its internal fields,
this kernel-doc should work:
/**
* struct refcount_struct - variant of atomic_t specialized for
reference counts
* @refs: atomic_t counter field
*
* The counter saturates at REFCOUNT_SATURATED and will not move once
* there. This avoids wrapping the counter and causing 'spurious'
* use-after-free bugs.
*/
Which produces this result:
.. c:struct:: refcount_struct
variant of atomic_t specialized for reference counts
**Definition**
::
struct refcount_struct {
atomic_t refs;
};
**Members**
``refs``
atomic_t counter field
(description)
See, in this case, the identifier is not opaque: its members are
documented at the html (or man) output.
If you want, instead, to document the typedef, this is the
proper way:
/**
* typedef refcount_t - variant of atomic_t specialized for reference
counts
*
* The counter saturates at REFCOUNT_SATURATED and will not move once
* there. This avoids wrapping the counter and causing 'spurious'
* use-after-free bugs.
*/
It will handle this one as an opaque type, meaning that it won't be
showing the "refs" field - even if you forget to drop the @refs:
at the markup. The result will be:
.. c:type:: refcount_t
variant of atomic_t specialized for reference counts
(description)
-
If you want both, then you would either split struct and typedef, e. g.
with something like:
/**
* struct refcount_struct - variant of atomic_t specialized for
reference counts
* @refs: atomic_t counter field
*
* The counter saturates at REFCOUNT_SATURATED and will not move once
* there. This avoids wrapping the counter and causing 'spurious'
* use-after-free bugs.
*/
struct refcount_struct {
atomic_t refs;
};
/**
* typedef refcount_t - variant of atomic_t specialized for reference
counts
* @refs: atomic_t counter field
*
* The counter saturates at REFCOUNT_SATURATED and will not move once
* there. This avoids wrapping the counter and causing 'spurious'
* use-after-free bugs.
*/
typedef struct refcount_struct refcount_t;
Or, you could add the member at the description field. E. g. something
like this:
/**
* typedef refcount_t - variant of atomic_t specialized for reference
counts
*
* The counter saturates at REFCOUNT_SATURATED and will not move once
* there. This avoids wrapping the counter and causing 'spurious'
* use-after-free bugs.
*
* Members:
* ``refs``
*atomic_t counter field
*/
typedef struct refcount_struct {
atomic_t refs;
} refcount_t;
If you want to test it, you can run kernel-doc directly, to see how
it will parse it. For ReST output, that's the syntax:
./scripts/kernel-doc --sphinx-version 3 include/linux/refcount.h
Thanks,
Mauro
[PATCH] pinctrl: amd: print debounce filter info in debugfs
Print out the status of debounce filter as follows,
$ cat /sys/kernel/debug/gpio|grep pin130
pin130 interrupt is disabled| interrupt is masked| disable wakeup in
S0i3 state| disable wakeup in S3 state|
disable wakeup in S4/S5 state| input is high| pull-up is disabled| Pull-down
is disabled| output is disabled| debouncing filter (high) enabled| debouncing
timeout is 124800 (us)| 0x503c8
Signed-off-by: Coiby Xu
---
drivers/pinctrl/pinctrl-amd.c | 43 +--
1 file changed, 41 insertions(+), 2 deletions(-)
diff --git a/drivers/pinctrl/pinctrl-amd.c b/drivers/pinctrl/pinctrl-amd.c
index 9a760f5cd7ed..9897f86b1bec 100644
--- a/drivers/pinctrl/pinctrl-amd.c
+++ b/drivers/pinctrl/pinctrl-amd.c
@@ -197,10 +197,16 @@ static int amd_gpio_set_config(struct gpio_chip *gc,
unsigned offset,
static void amd_gpio_dbg_show(struct seq_file *s, struct gpio_chip *gc)
{
u32 pin_reg;
+ u32 reg_db_mask;
unsigned long flags;
unsigned int bank, i, pin_num;
struct amd_gpio *gpio_dev = gpiochip_get_data(gc);
+ bool tmr_out_unit;
+ unsigned int time;
+ unsigned int unit;
+ bool tmr_large;
+
char *level_trig;
char *active_level;
char *interrupt_enable;
@@ -214,6 +220,8 @@ static void amd_gpio_dbg_show(struct seq_file *s, struct
gpio_chip *gc)
char *pull_down_enable;
char *output_value;
char *output_enable;
+ char debounce_value[40];
+ char *debounce_enable;
for (bank = 0; bank < gpio_dev->hwbank_num; bank++) {
seq_printf(s, "GPIO bank%d\t", bank);
@@ -327,13 +335,44 @@ static void amd_gpio_dbg_show(struct seq_file *s, struct
gpio_chip *gc)
pin_sts = "input is low|";
}
+ reg_db_mask = (DB_CNTRl_MASK << DB_CNTRL_OFF) & pin_reg;
+ if (reg_db_mask & pin_reg) {
+ tmr_out_unit = pin_reg &
BIT(DB_TMR_OUT_UNIT_OFF);
+ tmr_large = pin_reg & BIT(DB_TMR_LARGE_OFF);
+ time = pin_reg & DB_TMR_OUT_MASK;
+ if (!tmr_large) {
+ if (!tmr_out_unit)
+ unit = 61;
+ else
+ unit = 244;
+ } else {
+ if (!tmr_out_unit)
+ unit = 15600;
+ else
+ unit = 62500;
+ }
+ if ((DB_TYPE_REMOVE_GLITCH << DB_CNTRL_OFF) ==
reg_db_mask)
+ debounce_enable = "debouncing filter
(high and low) enabled|";
+ else if ((DB_TYPE_PRESERVE_LOW_GLITCH <<
DB_CNTRL_OFF) == reg_db_mask)
+ debounce_enable = "debouncing filter
(low) enabled|";
+ else
+ debounce_enable = "debouncing filter
(high) enabled|";
+
+ snprintf(debounce_value, 40,
+"debouncing timeout is %u (us)|", time
* unit);
+ } else {
+ debounce_enable = "debouncing filter disabled|";
+ snprintf(debounce_value, 30, " ");
+ }
+
seq_printf(s, "%s %s %s %s %s %s\n"
- " %s %s %s %s %s %s %s 0x%x\n",
+ " %s %s %s %s %s %s %s %s %s 0x%x\n",
level_trig, active_level, interrupt_enable,
interrupt_mask, wake_cntrl0, wake_cntrl1,
wake_cntrl2, pin_sts, pull_up_sel,
pull_up_enable, pull_down_enable,
- output_value, output_enable, pin_reg);
+ output_value, output_enable,
+ debounce_enable, debounce_value, pin_reg);
}
}
}
--
2.28.0
security/integrity/platform_certs/keyring_handler.c:62:30: warning: no previous prototype for function 'get_handler_for_db'
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: f11901ed723d1351843771c3a84b03a253bbf8b2
commit: ad723674d6758478829ee766e3f1a2a24d56236f x86/efi: move common keyring
handler functions to new file
date: 12 months ago
config: x86_64-randconfig-a005-20201024 (attached as .config)
compiler: clang version 12.0.0 (https://github.com/llvm/llvm-project
77cbf2595331b11018c2cffb76eb5b8db69f4577)
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# install x86_64 cross compiling tool for clang build
# apt-get install binutils-x86-64-linux-gnu
#
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=ad723674d6758478829ee766e3f1a2a24d56236f
git remote add linus
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
git fetch --no-tags linus master
git checkout ad723674d6758478829ee766e3f1a2a24d56236f
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=x86_64
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All warnings (new ones prefixed by >>):
>> security/integrity/platform_certs/keyring_handler.c:62:30: warning: no
>> previous prototype for function 'get_handler_for_db' [-Wmissing-prototypes]
__init efi_element_handler_t get_handler_for_db(const efi_guid_t *sig_type)
^
security/integrity/platform_certs/keyring_handler.c:62:8: note: declare
'static' if the function is not intended to be used outside of this translation
unit
__init efi_element_handler_t get_handler_for_db(const efi_guid_t *sig_type)
^
static
>> security/integrity/platform_certs/keyring_handler.c:73:30: warning: no
>> previous prototype for function 'get_handler_for_dbx' [-Wmissing-prototypes]
__init efi_element_handler_t get_handler_for_dbx(const efi_guid_t *sig_type)
^
security/integrity/platform_certs/keyring_handler.c:73:8: note: declare
'static' if the function is not intended to be used outside of this translation
unit
__init efi_element_handler_t get_handler_for_dbx(const efi_guid_t *sig_type)
^
static
2 warnings generated.
vim +/get_handler_for_db +62 security/integrity/platform_certs/keyring_handler.c
57
58 /*
59 * Return the appropriate handler for particular signature list types
found in
60 * the UEFI db and MokListRT tables.
61 */
> 62 __init efi_element_handler_t get_handler_for_db(const efi_guid_t
*sig_type)
63 {
64 if (efi_guidcmp(*sig_type, efi_cert_x509_guid) == 0)
65 return add_to_platform_keyring;
66 return 0;
67 }
68
69 /*
70 * Return the appropriate handler for particular signature list types
found in
71 * the UEFI dbx and MokListXRT tables.
72 */
> 73 __init efi_element_handler_t get_handler_for_dbx(const efi_guid_t
*sig_type)
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
.config.gz
Description: application/gzip
[PATCH v6] fat: Add KUnit tests for checksums and timestamps
Add some basic sanity-check tests for the fat_checksum() function and
the fat_time_unix2fat() and fat_time_fat2unix() functions. These unit
tests verify these functions return correct output for a number of test
inputs.
These tests were inspored by -- and serve a similar purpose to -- the
timestamp parsing KUnit tests in ext4[1].
Note that, unlike fat_time_unix2fat, fat_time_fat2unix wasn't previously
exported, so this patch exports it as well. This is required for the
case where we're building the fat and fat_test as modules.
[1]:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/fs/ext4/inode-test.c
Signed-off-by: David Gow
Acked-by: OGAWA Hirofumi
---
I am _so_ sorry: I sent out the wrong version again! It's clearly not my
day! This version actually has the fix!
-- David
Changes since v4/v5:
https://lore.kernel.org/linux-kselftest/20201024052047.2526780-1-david...@google.com/
- Fix a typo introduced in the Kconfig. It builds now.
Changes since v3:
https://lore.kernel.org/linux-kselftest/20201021061713.1545931-1-david...@google.com/
- Update the Kconfig entry to use "depends on" rather than "select", as
discussed in [2].
- Depend on "MSDOS_FS || VFAT_FS", rather than "FAT_FS", as we need the
CONFIG_FAT_DEFAULT_CODEPAGE symbol to be defined.
Changes since v2:
https://lore.kernel.org/linux-kselftest/20201020055856.1270482-1-david...@google.com/
- Comment that the export for fat_time_fat2unix() function is for KUnit
tests.
Changes since v1:
https://lore.kernel.org/linux-kselftest/20201017064107.375174-1-david...@google.com/
- Now export fat_time_fat2unix() so that the test can access it when
built as a module.
[2]:
https://lore.kernel.org/linux-ext4/52959e99-4105-3de9-730c-c46894b82...@infradead.org/T/#t
fs/fat/Kconfig| 12 +++
fs/fat/Makefile | 2 +
fs/fat/fat_test.c | 196 ++
fs/fat/misc.c | 2 +
4 files changed, 212 insertions(+)
create mode 100644 fs/fat/fat_test.c
diff --git a/fs/fat/Kconfig b/fs/fat/Kconfig
index 66532a71e8fd..4e66f7e8defc 100644
--- a/fs/fat/Kconfig
+++ b/fs/fat/Kconfig
@@ -115,3 +115,15 @@ config FAT_DEFAULT_UTF8
Say Y if you use UTF-8 encoding for file names, N otherwise.
See for more information.
+
+config FAT_KUNIT_TEST
+ tristate "Unit Tests for FAT filesystems" if !KUNIT_ALL_TESTS
+ depends on KUNIT && (MSDOS_FS || VFAT_FS)
+ default KUNIT_ALL_TESTS
+ help
+ This builds the FAT KUnit tests
+
+ For more information on KUnit and unit tests in general, please refer
+ to the KUnit documentation in Documentation/dev-tools/kunit
+
+ If unsure, say N
diff --git a/fs/fat/Makefile b/fs/fat/Makefile
index 70645ce2f7fc..2b034112690d 100644
--- a/fs/fat/Makefile
+++ b/fs/fat/Makefile
@@ -10,3 +10,5 @@ obj-$(CONFIG_MSDOS_FS) += msdos.o
fat-y := cache.o dir.o fatent.o file.o inode.o misc.o nfs.o
vfat-y := namei_vfat.o
msdos-y := namei_msdos.o
+
+obj-$(CONFIG_FAT_KUNIT_TEST) += fat_test.o
diff --git a/fs/fat/fat_test.c b/fs/fat/fat_test.c
new file mode 100644
index ..c99bfbdf89bb
--- /dev/null
+++ b/fs/fat/fat_test.c
@@ -0,0 +1,196 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * KUnit tests for FAT filesystems.
+ *
+ * Copyright (C) 2020 Google LLC.
+ * Author: David Gow
+ */
+
+#include
+
+#include "fat.h"
+
+static void fat_checksum_test(struct kunit *test)
+{
+ /* With no extension. */
+ KUNIT_EXPECT_EQ(test, fat_checksum("VMLINUX"), 44);
+ /* With 3-letter extension. */
+ KUNIT_EXPECT_EQ(test, fat_checksum("README TXT"), 115);
+ /* With short (1-letter) extension. */
+ KUNIT_EXPECT_EQ(test, fat_checksum("ABCDEFGHA "), 98);
+}
+
+
+struct fat_timestamp_testcase {
+ const char *name;
+ struct timespec64 ts;
+ __le16 time;
+ __le16 date;
+ u8 cs;
+ int time_offset;
+};
+
+const static struct fat_timestamp_testcase time_test_cases[] = {
+ {
+ .name = "Earliest possible UTC (1980-01-01 00:00:00)",
+ .ts = {.tv_sec = 315532800LL, .tv_nsec = 0L},
+ .time = 0,
+ .date = 33,
+ .cs = 0,
+ .time_offset = 0,
+ },
+ {
+ .name = "Latest possible UTC (2107-12-31 23:59:58)",
+ .ts = {.tv_sec = 4354819198LL, .tv_nsec = 0L},
+ .time = 49021,
+ .date = 65439,
+ .cs = 0,
+ .time_offset = 0,
+ },
+ {
+ .name = "Earliest possible (UTC-11) (== 1979-12-31 13:00:00
UTC)",
+ .ts = {.tv_sec = 315493200LL, .tv_nsec = 0L},
+ .time = 0,
+ .date = 33,
+ .cs = 0,
+ .time_offset = 11 * 60,
+ },
+ {
+ .name = "Latest possible (UTC+11) (== 2108-01-01 10:59:58 UTC)",
+ .ts = {.tv_sec = 4354858798LL, .tv_nsec = 0L},
+
[PATCH v5] fat: Add KUnit tests for checksums and timestamps
Add some basic sanity-check tests for the fat_checksum() function and
the fat_time_unix2fat() and fat_time_fat2unix() functions. These unit
tests verify these functions return correct output for a number of test
inputs.
These tests were inspored by -- and serve a similar purpose to -- the
timestamp parsing KUnit tests in ext4[1].
Note that, unlike fat_time_unix2fat, fat_time_fat2unix wasn't previously
exported, so this patch exports it as well. This is required for the
case where we're building the fat and fat_test as modules.
[1]:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/fs/ext4/inode-test.c
Signed-off-by: David Gow
Acked-by: OGAWA Hirofumi
---
Whoops! Sent out a broken early version of this as v4 instead.
Sorry about that!
-- David
Changes since v4:
https://lore.kernel.org/linux-kselftest/20201024052047.2526780-1-david...@google.com/
- Fix a typo introduced in the Kconfig. It builds now.
Changes since v3:
https://lore.kernel.org/linux-kselftest/20201021061713.1545931-1-david...@google.com/
- Update the Kconfig entry to use "depends on" rather than "select", as
discussed in [2].
- Depend on "MSDOS_FS || VFAT_FS", rather than "FAT_FS", as we need the
CONFIG_FAT_DEFAULT_CODEPAGE symbol to be defined.
Changes since v2:
https://lore.kernel.org/linux-kselftest/20201020055856.1270482-1-david...@google.com/
- Comment that the export for fat_time_fat2unix() function is for KUnit
tests.
Changes since v1:
https://lore.kernel.org/linux-kselftest/20201017064107.375174-1-david...@google.com/
- Now export fat_time_fat2unix() so that the test can access it when
built as a module.
[2]:
https://lore.kernel.org/linux-ext4/52959e99-4105-3de9-730c-c46894b82...@infradead.org/T/#t
fs/fat/Kconfig| 12 +++
fs/fat/Makefile | 2 +
fs/fat/fat_test.c | 196 ++
fs/fat/misc.c | 2 +
4 files changed, 212 insertions(+)
create mode 100644 fs/fat/fat_test.c
diff --git a/fs/fat/Kconfig b/fs/fat/Kconfig
index 66532a71e8fd..5f44bf94224e 100644
--- a/fs/fat/Kconfig
+++ b/fs/fat/Kconfig
@@ -115,3 +115,15 @@ config FAT_DEFAULT_UTF8
Say Y if you use UTF-8 encoding for file names, N otherwise.
See for more information.
+
+config FAT_KUNIT_TEST
+ tristate "Unit Tests for FAT filesystems" if !KUNIT_ALL_TESTS
+ depends on KUNIT & (MSDOS_FS || VFAT_FS)
+ default KUNIT_ALL_TESTS
+ help
+ This builds the FAT KUnit tests
+
+ For more information on KUnit and unit tests in general, please refer
+ to the KUnit documentation in Documentation/dev-tools/kunit
+
+ If unsure, say N
diff --git a/fs/fat/Makefile b/fs/fat/Makefile
index 70645ce2f7fc..2b034112690d 100644
--- a/fs/fat/Makefile
+++ b/fs/fat/Makefile
@@ -10,3 +10,5 @@ obj-$(CONFIG_MSDOS_FS) += msdos.o
fat-y := cache.o dir.o fatent.o file.o inode.o misc.o nfs.o
vfat-y := namei_vfat.o
msdos-y := namei_msdos.o
+
+obj-$(CONFIG_FAT_KUNIT_TEST) += fat_test.o
diff --git a/fs/fat/fat_test.c b/fs/fat/fat_test.c
new file mode 100644
index ..c99bfbdf89bb
--- /dev/null
+++ b/fs/fat/fat_test.c
@@ -0,0 +1,196 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * KUnit tests for FAT filesystems.
+ *
+ * Copyright (C) 2020 Google LLC.
+ * Author: David Gow
+ */
+
+#include
+
+#include "fat.h"
+
+static void fat_checksum_test(struct kunit *test)
+{
+ /* With no extension. */
+ KUNIT_EXPECT_EQ(test, fat_checksum("VMLINUX"), 44);
+ /* With 3-letter extension. */
+ KUNIT_EXPECT_EQ(test, fat_checksum("README TXT"), 115);
+ /* With short (1-letter) extension. */
+ KUNIT_EXPECT_EQ(test, fat_checksum("ABCDEFGHA "), 98);
+}
+
+
+struct fat_timestamp_testcase {
+ const char *name;
+ struct timespec64 ts;
+ __le16 time;
+ __le16 date;
+ u8 cs;
+ int time_offset;
+};
+
+const static struct fat_timestamp_testcase time_test_cases[] = {
+ {
+ .name = "Earliest possible UTC (1980-01-01 00:00:00)",
+ .ts = {.tv_sec = 315532800LL, .tv_nsec = 0L},
+ .time = 0,
+ .date = 33,
+ .cs = 0,
+ .time_offset = 0,
+ },
+ {
+ .name = "Latest possible UTC (2107-12-31 23:59:58)",
+ .ts = {.tv_sec = 4354819198LL, .tv_nsec = 0L},
+ .time = 49021,
+ .date = 65439,
+ .cs = 0,
+ .time_offset = 0,
+ },
+ {
+ .name = "Earliest possible (UTC-11) (== 1979-12-31 13:00:00
UTC)",
+ .ts = {.tv_sec = 315493200LL, .tv_nsec = 0L},
+ .time = 0,
+ .date = 33,
+ .cs = 0,
+ .time_offset = 11 * 60,
+ },
+ {
+ .name = "Latest possible (UTC+11) (== 2108-01-01 10:59:58 UTC)",
+ .ts = {.tv_sec = 4354858798LL, .tv_nsec = 0L},
+ .time = 49021,
+ .date
Re: [PATCH v4] fat: Add KUnit tests for checksums and timestamps
Hi David, I love your patch! Yet something to improve: [auto build test ERROR on linus/master] [also build test ERROR on v5.9 next-20201023] [If your patch is applied to the wrong git tree, kindly drop us a note. And when submitting patch, we suggest to use '--base' as documented in https://git-scm.com/docs/git-format-patch] url: https://github.com/0day-ci/linux/commits/David-Gow/fat-Add-KUnit-tests-for-checksums-and-timestamps/20201024-132133 base: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git f11901ed723d1351843771c3a84b03a253bbf8b2 config: sparc-randconfig-s031-20201024 compiler: sparc-linux-gcc (GCC) 9.3.0 reproduce: wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # apt-get install sparse # sparse version: v0.6.3-17-g2d3af347-dirty # https://github.com/0day-ci/linux/commit/3904bec3c79102be934e8021abb02c9176f099d7 git remote add linux-review https://github.com/0day-ci/linux git fetch --no-tags linux-review David-Gow/fat-Add-KUnit-tests-for-checksums-and-timestamps/20201024-132133 git checkout 3904bec3c79102be934e8021abb02c9176f099d7 # save the attached .config to linux build tree COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross C=1 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' ARCH=sparc If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot All errors (new ones prefixed by >>): fs/fat/Kconfig:121:warning: ignoring unsupported character '&' >> fs/fat/Kconfig:122: syntax error fs/fat/Kconfig:121: invalid statement fs/fat/Kconfig:122: invalid statement fs/fat/Kconfig:123: invalid statement fs/fat/Kconfig:124: unknown statement "This" fs/fat/Kconfig:126:warning: ignoring unsupported character ',' fs/fat/Kconfig:126: unknown statement "For" fs/fat/Kconfig:127:warning: ignoring unsupported character '/' fs/fat/Kconfig:127:warning: ignoring unsupported character '/' fs/fat/Kconfig:127: unknown statement "to" fs/fat/Kconfig:129:warning: ignoring unsupported character ',' fs/fat/Kconfig:129: unknown statement "If" make[2]: *** [scripts/kconfig/Makefile:71: oldconfig] Error 1 make[1]: *** [Makefile:604: oldconfig] Error 2 make: *** [Makefile:185: __sub-make] Error 2 make: Target 'oldconfig' not remade because of errors. -- fs/fat/Kconfig:121:warning: ignoring unsupported character '&' >> fs/fat/Kconfig:122: syntax error fs/fat/Kconfig:121: invalid statement fs/fat/Kconfig:122: invalid statement fs/fat/Kconfig:123: invalid statement fs/fat/Kconfig:124: unknown statement "This" fs/fat/Kconfig:126:warning: ignoring unsupported character ',' fs/fat/Kconfig:126: unknown statement "For" fs/fat/Kconfig:127:warning: ignoring unsupported character '/' fs/fat/Kconfig:127:warning: ignoring unsupported character '/' fs/fat/Kconfig:127: unknown statement "to" fs/fat/Kconfig:129:warning: ignoring unsupported character ',' fs/fat/Kconfig:129: unknown statement "If" make[2]: *** [scripts/kconfig/Makefile:71: olddefconfig] Error 1 make[1]: *** [Makefile:604: olddefconfig] Error 2 make: *** [Makefile:185: __sub-make] Error 2 make: Target 'olddefconfig' not remade because of errors. vim +122 fs/fat/Kconfig > 122 default KUNIT_ALL_TESTS --- 0-DAY CI Kernel Test Service, Intel Corporation https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
Re: [PATCH] ext: EXT4_KUNIT_TESTS should depend on EXT4_FS instead of selecting it
On Fri, Oct 23, 2020 at 10:07 PM Theodore Y. Ts'o wrote: > > On Thu, Oct 22, 2020 at 04:52:52PM -0700, Brendan Higgins wrote: > > So you, me, Luis, David, and a whole bunch of other people have been > > thinking about this problem for a while. What if we just put > > kunitconfig fragments in directories along side the test files they > > enable? > > > > For example, we could add a file to fs/ext4/kunitconfig which contains: > > > > CONFIG_EXT4_FS=y > > CONFIG_EXT4_KUNIT_TESTS=y > > > > We could do something similar in fs/jdb2, etc. > > > > Obviously some logically separate KUnit tests (different maintainers, > > different Kconfig symbols, etc) reside in the same directory, for > > these we could name the kunitconfig file something like > > lib/list-test.kunitconfig (not a great example because lists are > > always built into Linux), but you get the idea. > > > > Then like Ted suggested, if you call kunit.py run foo/bar, then > > > > if bar is a directory, then kunit.py will look for foo/bar/kunitconfig > > > > if bar is a file ending with .kunitconfig like foo/bar.kunitconfig, > > then it will use that kunitconfig > > > > if bar is '...' (foo/...) then kunit.py will look for all kunitconfigs > > underneath foo. > > > > Once all the kunitconfigs have been resolved, they will be merged into > > the .kunitconfig. If they can be successfully merged together, the new > > .kunitconfig will then continue to function as it currently does. > > I was thinking along a similar set of lines this morning. One thing > I'd add in addition to your suggestion to that is to change how > .kunitconfig is interpreted such that > > CONFIG_KUNIT=y > > is always implied, so it doesn't have to be specified explicitly, and > that if a line like: > > fs/ext4 > > or > > mm > > etc. occurs, that will cause a include of the Kunitconfig (I'd using a > capitalized version of the filename like Kconfig, so that it's easier > to see in a directory listing) in the named directory. > > That way, .kunitconfig is backwards compatible, but it also allows > people to put a one-liner into .kunitconfig to enable the unit tests > for that particular directory. > > What do folks think? > I quite like the idea of supporting includes, as it'd make it easier to have test hierarchies as well: fs/Kunitconfig could include ext4/Kunitconfig and fat/Kunitconfig, for instance. If we're adding something more complicated to the Kunitconfig files than just raw config entries, there are other things we could do, too (personally, I'd quite like to be able to list KUnit test modules to be loaded someday, though that's a bit outside the scope of this discussion). There are some issues with exactly how we format these that'll need to be resolved: there are cases where there are multiple distinct "areas" that need testing which share a subdirectory (something like lib/), so just using directory paths with one Kunitconfig file per directory has some limitations. At the same time, it's definitely nicer to be able to just specify a directory where that works. Here's what I propose (noting that, realistically, it's unlikely we'll have time to build the perfect system straight away): 1. We've agreed that 'select' isn't the solution we want, so accept this patch to get rid of it, and avoid using it elsewhere (I've done this for the fat test[1]). Do we know if changing this now will seriously break anyone's workflow (particularly if there's something automated that'd break?) 2. Add support to kunit.py for loading an arbitrary kunitconfig, rather than using the default one in the root or build dir. (e.g., kunit.py run [path_to_kunitconfig]). This'd let us create per-subsystem/feature/etc kunitconfigs and use them straight away. This'd still require people to pass in the kunitconfig path each time they run the tests, but'd at least give maintainers a single command they can use and recommend — they'd just need to have a Kunitconfig file somewhere in the tree with the tests they want people to run. Maybe if you pass a directory path, it looks for "Kunitconfig" in that directory, but otherwise it can be a file like "lib/data-structres.Kunitconfig" or something which doesn't correspond to a directory. 3. Add the include support, etc, to kunitconfig, so people working on multiple subsystems can more easily run groups of tests. This may get a little complicated if we care about handling things with conflicting dependencies, so I don't want to hold up the first two on that. How does that sound? -- David [1]: https://lore.kernel.org/linux-kselftest/20201024052047.2526780-1-david...@google.com/
Re: [PATCH v4 0/2] Control over userfaultfd kernel-fault handling
Hello, On Thu, Oct 08, 2020 at 04:22:36PM -0700, Nick Kralevich wrote: > I haven't tried to verify this myself. I wonder if the usermode > hardening changes also impacted this exploit? See > https://lkml.org/lkml/2017/1/16/468 My plan was to: 1) reproduce with the old buggy kernel 2) forward port the bug to the very first version that had both the slub and page freelist randomization available and keep them disabled 3) enable the freelist randomization features (which are already enabled by default in the current enterprise kernels) and see if that makes the attack not workable The hardening of the usermode helper you mentioned is spot on, but it would have been something to worry about and possibly roll back at point 2), but I couldn't get past point 1).. Plenty other hardening techniques (just like the usermode helper) are very specific to a single attack, but the randomization looks generic enough to cover the entire class. > But again, focusing on an exploit, which is inherently fragile in > nature and dependent on the state of the kernel tree at a particular > time, is unlikely to be useful to analyze this patch. Agreed. A single exploit using userfaultfd to enlarge the race window of the use-after-free, not being workable anymore with randomized slub and page freelist enabled, wouldn't have meant a thing by itself. As opposed if that single exploit was still fairly reproducible, it would have been enough to consider the sysctl default to zero as something providing a more tangible long term benefit. That would have been good information to have too, if that's actually the case. I was merely attempting to get a first data point.. overall it would be nice to initiate some research to verify the exact statistical effects that slub/page randomization has on those use-after-free race conditions that can be enlarged by blocking kernel faults, given we're already paying the price for it. I don't think anybody has a sure answer at this point, if we can entirely rely on those features or not. > Seccomp causes more problems than just performance. Seccomp is not > designed for whole-of-system protections. Please see my other writeup > at > https://lore.kernel.org/lkml/cafj0lneo-7yuvgohb4phteuiuw+wpfzqbwxucgaa35zmx11...@mail.gmail.com/ Whole-of-system protection I guess helps primarily because it requires no change to userland I guess. An example of a task not running as root (and without ptrace capability) that could use more seccomp blocking: # cat /proc/1517/cmdline ; echo ; grep CapEff /proc/1517/status; grep Seccomp /proc/1517/status /vendor/bin/hw/qcrild CapEff: 00103000 Seccomp:0 My view is that if the various binaries started by init.rc are run without a strict seccomp filter there would be more things to worry about, than kernel initiated userfaults for those. Still the solution in the v5 patchset looks the safest for all until we'll be able to tell if the slub/page randomizaton (or any other generic enough robustness feature) is already effective against an enlarged race window of kernel initiated userfaults and at the same time it provides the main benefit of avoiding divergence in the behavior of the userfaultfd syscall if invoked within the Android userland. Thanks, Andrea
Re: kvm+nouveau induced lockdep gripe
On Sat, 2020-10-24 at 13:00 +0800, Hillf Danton wrote: > On Sat, 24 Oct 2020 05:38:23 +0200 Mike Galbraith wrote: > > On Sat, 2020-10-24 at 10:22 +0800, Hillf Danton wrote: > > > > > > Looks like we can break the lock chain by moving ttm bo's release > > > method out of mmap_lock, see diff below. > > > > Ah, the perfect compliment to morning java, a patchlet to wedge in and > > see what happens. > > > > wedge/build/boot > > > > Mmm, box says no banana... a lot. > > Hmm...curious how that word went into your mind. And when? There's a colloquial expression "close, but no cigar", and a variant "close, but no banana". The intended communication being "not quite". -Mike
Re: [PATCH v2 1/2] kunit: Support for Parameterized Testing
On 24/10/20 12:18 am, Marco Elver wrote:
> On Fri, Oct 23, 2020 at 08:35PM +0530, Arpitha Raghunandan wrote:
>> Implementation of support for parameterized testing in KUnit.
>
> Already looks much cleaner, thanks for using this approach!
>
> I think the commit message needs a brief summary of the approach.
>
Okay, I will add a more detailed commit message for the next version.
>> Signed-off-by: Arpitha Raghunandan <98.a...@gmail.com>
>> ---
>> Changes v1->v2:
>> - Use of a generator method to access test case parameters
>>
>> include/kunit/test.h | 45
>> lib/kunit/test.c | 20 +++-
>> 2 files changed, 64 insertions(+), 1 deletion(-)
>>
>> diff --git a/include/kunit/test.h b/include/kunit/test.h
>> index a423fffefea0..c417ac140326 100644
>> --- a/include/kunit/test.h
>> +++ b/include/kunit/test.h
>> @@ -141,6 +141,7 @@ struct kunit;
>> struct kunit_case {
>> void (*run_case)(struct kunit *test);
>> const char *name;
>> +void* (*generate_params)(struct kunit *test, void *prev);
>
> Would adding documentation above this field be the right place, or
> somewhere else? In any case, some explanation of the protocol would be
> good.
>
I will include this.
>> /* private: internal use only. */
>> bool success;
>> @@ -162,6 +163,9 @@ static inline char *kunit_status_to_string(bool status)
>> * &struct kunit_case for an example on how to use it.
>> */
>> #define KUNIT_CASE(test_name) { .run_case = test_name, .name = #test_name }
>> +#define KUNIT_CASE_PARAM(test_name, gen_params) \
>> +{ .run_case = test_name, .name = #test_name,\
>> + .generate_params = gen_params }
>>
>> /**
>> * struct kunit_suite - describes a related collection of &struct kunit_case
>> @@ -208,6 +212,15 @@ struct kunit {
>> const char *name; /* Read only after initialization! */
>> char *log; /* Points at case log after initialization */
>> struct kunit_try_catch try_catch;
>> +/* param_values points to test case parameters in parameterized tests */
>> +void *param_values;
>> +/*
>> + * current_param stores the index of the parameter in
>> + * the array of parameters in parameterized tests.
>> + * current_param + 1 is printed to indicate the parameter
>> + * that causes the test to fail in case of test failure.
>> + */
>> +int current_param;
>> /*
>> * success starts as true, and may only be set to false during a
>> * test case; thus, it is safe to update this across multiple
>> @@ -1742,4 +1755,36 @@ do {
>>\
>> fmt, \
>> ##__VA_ARGS__)
>>
>> +/**
>> + * kunit_param_generator_helper() - Helper method for test parameter
>> generators
>> + * required in parameterized tests.
>> + * @test: The test context object.
>> + * @prev_param: a pointer to the previous test parameter, NULL for first
>> parameter.
>> + * @param_array: a user-supplied pointer to an array of test parameters.
>> + * @array_size: number of test parameters in the array.
>> + * @type_size: size of one test parameter.
>> + */
>> +static inline void *kunit_param_generator_helper(struct kunit *test,
>
> I don't think this needs to be inline, but see my other suggestion
> below, which might make this function obsolete.
>
>> +void *prev_param,
>> +void *param_array,
>> +size_t array_size,
>> +size_t type_size)
>> +{
>> +KUNIT_ASSERT_EQ(test, (prev_param - param_array) % type_size, 0);
>> +
>> +if (!prev_param)
>> +return param_array;
>> +
>> +KUNIT_ASSERT_GE(test, prev_param, param_array);
>> +
>> +if (prev_param + type_size < param_array + (array_size * type_size))
>> +return prev_param + type_size;
>> +else
>> +return NULL;
>> +}
>> +
>> +#define KUNIT_PARAM_GENERATOR_HELPER(test, prev_param, param_array,
>> param_type) \
>> +kunit_param_generator_helper(test, prev_param, param_array,
>> \
>> +ARRAY_SIZE(param_array), sizeof(param_type))
>
> You do not need param_type, you can use the same trick that ARRAY_SIZE
> uses:
>
> #define ARRAY_SIZE(arr) (sizeof(arr) / sizeof((arr)[0]) +
> __must_be_array(arr))
>
> So you could use sizeof((param_aray)[0]) instead of sizeof(param_type).
> ARRAY_SIZE already checks for you that it's a real array via
> __must_be_array().
>
>
> The other question is, will kunit_param_generator_helper() find much use
> without the KUNIT_PARAM_GENERATOR_HELPER() macro? If I have some
> complicated generator protocol to generate params, then I'd just
> directly write th
[PATCH v4] fat: Add KUnit tests for checksums and timestamps
Add some basic sanity-check tests for the fat_checksum() function and
the fat_time_unix2fat() and fat_time_fat2unix() functions. These unit
tests verify these functions return correct output for a number of test
inputs.
These tests were inspored by -- and serve a similar purpose to -- the
timestamp parsing KUnit tests in ext4[1].
Note that, unlike fat_time_unix2fat, fat_time_fat2unix wasn't previously
exported, so this patch exports it as well. This is required for the
case where we're building the fat and fat_test as modules.
[1]:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/fs/ext4/inode-test.c
Signed-off-by: David Gow
Acked-by: OGAWA Hirofumi
---
Changes since v3:
https://lore.kernel.org/linux-kselftest/20201021061713.1545931-1-david...@google.com/
- Update the Kconfig entry to use "depends on" rather than "select", as
discussed in [2].
- Depend on "MSDOS_FS || VFAT_FS", rather than "FAT_FS", as we need the
CONFIG_FAT_DEFAULT_CODEPAGE symbol to be defined.
Changes since v2:
https://lore.kernel.org/linux-kselftest/20201020055856.1270482-1-david...@google.com/
- Comment that the export for fat_time_fat2unix() function is for KUnit
tests.
Changes since v1:
https://lore.kernel.org/linux-kselftest/20201017064107.375174-1-david...@google.com/
- Now export fat_time_fat2unix() so that the test can access it when
built as a module.
[2]:
https://lore.kernel.org/linux-ext4/52959e99-4105-3de9-730c-c46894b82...@infradead.org/T/#t
fs/fat/Kconfig| 12 +++
fs/fat/Makefile | 2 +
fs/fat/fat_test.c | 196 ++
fs/fat/misc.c | 2 +
4 files changed, 212 insertions(+)
create mode 100644 fs/fat/fat_test.c
diff --git a/fs/fat/Kconfig b/fs/fat/Kconfig
index 66532a71e8fd..5f44bf94224e 100644
--- a/fs/fat/Kconfig
+++ b/fs/fat/Kconfig
@@ -115,3 +115,15 @@ config FAT_DEFAULT_UTF8
Say Y if you use UTF-8 encoding for file names, N otherwise.
See for more information.
+
+config FAT_KUNIT_TEST
+ tristate "Unit Tests for FAT filesystems" if !KUNIT_ALL_TESTS
+ depends on KUNIT & (MSDOS_FS || VFAT_FS)
+ default KUNIT_ALL_TESTS
+ help
+ This builds the FAT KUnit tests
+
+ For more information on KUnit and unit tests in general, please refer
+ to the KUnit documentation in Documentation/dev-tools/kunit
+
+ If unsure, say N
diff --git a/fs/fat/Makefile b/fs/fat/Makefile
index 70645ce2f7fc..2b034112690d 100644
--- a/fs/fat/Makefile
+++ b/fs/fat/Makefile
@@ -10,3 +10,5 @@ obj-$(CONFIG_MSDOS_FS) += msdos.o
fat-y := cache.o dir.o fatent.o file.o inode.o misc.o nfs.o
vfat-y := namei_vfat.o
msdos-y := namei_msdos.o
+
+obj-$(CONFIG_FAT_KUNIT_TEST) += fat_test.o
diff --git a/fs/fat/fat_test.c b/fs/fat/fat_test.c
new file mode 100644
index ..c99bfbdf89bb
--- /dev/null
+++ b/fs/fat/fat_test.c
@@ -0,0 +1,196 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * KUnit tests for FAT filesystems.
+ *
+ * Copyright (C) 2020 Google LLC.
+ * Author: David Gow
+ */
+
+#include
+
+#include "fat.h"
+
+static void fat_checksum_test(struct kunit *test)
+{
+ /* With no extension. */
+ KUNIT_EXPECT_EQ(test, fat_checksum("VMLINUX"), 44);
+ /* With 3-letter extension. */
+ KUNIT_EXPECT_EQ(test, fat_checksum("README TXT"), 115);
+ /* With short (1-letter) extension. */
+ KUNIT_EXPECT_EQ(test, fat_checksum("ABCDEFGHA "), 98);
+}
+
+
+struct fat_timestamp_testcase {
+ const char *name;
+ struct timespec64 ts;
+ __le16 time;
+ __le16 date;
+ u8 cs;
+ int time_offset;
+};
+
+const static struct fat_timestamp_testcase time_test_cases[] = {
+ {
+ .name = "Earliest possible UTC (1980-01-01 00:00:00)",
+ .ts = {.tv_sec = 315532800LL, .tv_nsec = 0L},
+ .time = 0,
+ .date = 33,
+ .cs = 0,
+ .time_offset = 0,
+ },
+ {
+ .name = "Latest possible UTC (2107-12-31 23:59:58)",
+ .ts = {.tv_sec = 4354819198LL, .tv_nsec = 0L},
+ .time = 49021,
+ .date = 65439,
+ .cs = 0,
+ .time_offset = 0,
+ },
+ {
+ .name = "Earliest possible (UTC-11) (== 1979-12-31 13:00:00
UTC)",
+ .ts = {.tv_sec = 315493200LL, .tv_nsec = 0L},
+ .time = 0,
+ .date = 33,
+ .cs = 0,
+ .time_offset = 11 * 60,
+ },
+ {
+ .name = "Latest possible (UTC+11) (== 2108-01-01 10:59:58 UTC)",
+ .ts = {.tv_sec = 4354858798LL, .tv_nsec = 0L},
+ .time = 49021,
+ .date = 65439,
+ .cs = 0,
+ .time_offset = -11 * 60,
+ },
+ {
+ .name = "Leap Day / Year (1996-02-29 00:00:00)",
+ .ts = {.tv_sec = 825552000LL, .tv_nsec = 0L},
+ .time = 0,
+
[GIT PULL] RISC-V Patches for the 5.10 Merge Window, Part 2
The following changes since commit de22d2107ced3cc5355cc9dbbd85e44183546bd5:
RISC-V: Add page table dump support for uefi (2020-10-02 14:31:33 -0700)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux.git
tags/riscv-for-linus-5.10-mw1
for you to fetch changes up to e8d444d3e98c255f91d228984abc46cfdfaf48b4:
riscv: remove address space overrides using set_fs() (2020-10-04 10:27:10
-0700)
RISC-V Patches for the 5.10 Merge Window, Part 2
This actually just contains a single patch set:
* The remainder of Christoph's work to remove set_fs, including the RISC-V
portion.
I know I said in the previous PR that I'd keep including shortlogs as of the
last tag, but I haven't done that here as it would include my previous PR.
Essentially I wanted to wait for the base branch of this to land first, as it
touched a lot. Rather than rebasing I've just left the original merge in
place and sent a shortlog against master.
I'm not sure why the diffstat shows so much more, though. I manually checked
the commits and my merge has the same commits yours does. It's my first time
trying this particular sort of merge (though the last one had a tag-based merge
of the same sort, which IIUC shouldn't be any different) so hopefully it went
OK.
Christoph Hellwig (8):
uaccess: provide a generic TASK_SIZE_MAX definition
asm-generic: improve the nommu {get,put}_user handling
asm-generic: add nommu implementations of __{get,put}_kernel_nofault
asm-generic: make the set_fs implementation optional
riscv: use memcpy based uaccess for nommu again
riscv: refactor __get_user and __put_user
riscv: implement __get_kernel_nofault and __put_user_nofault
riscv: remove address space overrides using set_fs()
Palmer Dabbelt (1):
Merge branch 'base.set_fs' of git://git.kernel.org/.../viro/vfs into
for-next
arch/Kconfig| 3 +
arch/alpha/Kconfig | 1 +
arch/arc/Kconfig| 1 +
arch/arm/Kconfig| 1 +
arch/arm64/Kconfig | 1 +
arch/c6x/Kconfig| 1 +
arch/csky/Kconfig | 1 +
arch/h8300/Kconfig | 1 +
arch/hexagon/Kconfig| 1 +
arch/ia64/Kconfig | 1 +
arch/m68k/Kconfig | 1 +
arch/microblaze/Kconfig | 1 +
arch/mips/Kconfig | 1 +
arch/nds32/Kconfig | 1 +
arch/nios2/Kconfig | 1 +
arch/openrisc/Kconfig | 1 +
arch/parisc/Kconfig | 1 +
arch/powerpc/include/asm/processor.h| 7 --
arch/powerpc/include/asm/thread_info.h | 5 +-
arch/powerpc/include/asm/uaccess.h | 67
arch/powerpc/kernel/signal.c| 3 -
arch/powerpc/lib/sstep.c| 6 +-
arch/riscv/Kconfig | 1 +
arch/riscv/include/asm/thread_info.h| 6 --
arch/riscv/include/asm/uaccess.h| 177
arch/riscv/kernel/process.c | 1 -
arch/riscv/lib/Makefile | 2 +-
arch/s390/Kconfig | 1 +
arch/sh/Kconfig | 1 +
arch/sparc/Kconfig | 1 +
arch/um/Kconfig | 1 +
arch/x86/ia32/ia32_aout.c | 1 -
arch/x86/include/asm/page_32_types.h| 11 ++
arch/x86/include/asm/page_64_types.h| 38 +++
arch/x86/include/asm/processor.h| 60 +--
arch/x86/include/asm/thread_info.h | 2 -
arch/x86/include/asm/uaccess.h | 26 +
arch/x86/kernel/asm-offsets.c | 3 -
arch/x86/lib/getuser.S | 47 -
arch/x86/lib/putuser.S | 25 ++---
arch/xtensa/Kconfig | 1 +
drivers/misc/lkdtm/bugs.c | 10 --
drivers/misc/lkdtm/core.c | 2 -
drivers/misc/lkdtm/lkdtm.h | 2 -
drivers/misc/lkdtm/usercopy.c | 15 ---
fs/proc/inode.c | 119 ++---
fs/proc/proc_sysctl.c | 48 -
fs/read_write.c | 69 -
fs/splice.c | 130 +++
include/asm-generic/uaccess.h | 109
include/linux/bpf-cgroup.h | 2 +-
include/linux/fs.h | 2 -
include/linux/proc_fs.h | 1 +
include/linux/uaccess.h | 22
kernel/bpf/cgroup.c | 2 +-
lib/test_bitmap.c | 91
tools/testing/selftests/lkd
Re: [PATCH v2] lib: Convert test_printf.c to KUnit
On 23/10/20 11:31 pm, Petr Mladek wrote:
> On Fri 2020-10-23 19:13:00, Arpitha Raghunandan wrote:
>> On 23/10/20 4:36 pm, Rasmus Villemoes wrote:
>>> On 22/10/2020 21.16, Andy Shevchenko wrote:
On Thu, Oct 22, 2020 at 08:43:49PM +0530, Arpitha Raghunandan wrote:
> Converted test failure:
> # Subtest: printf-kunit-test
> 1..1
> # selftest: EXPECTATION FAILED at lib/printf_kunit.c:82
> vsnprintf(buf, 256, "%pi4|%pI4", ...) wrote
> '127.000.000.001|127.0.0.1', expected '127-000.000.001|127.0.0.1'
> # selftest: EXPECTATION FAILED at lib/printf_kunit.c:82
> vsnprintf(buf, 5, "%pi4|%pI4", ...) wrote '127.', expected '127-'
> # selftest: EXPECTATION FAILED at lib/printf_kunit.c:118
> kvasprintf(..., "%pi4|%pI4", ...) returned
> '127.000.000.001|127.0.0.1', expected '127-000.000.001|127.0.0.1'
> not ok 1 - selftest
> not ok 1 - printf-kunit-test
Not bad. Rasmus, what do you think?
>>>
>>> Much better, but that '1..1' and reporting the entire test suite as 1
>>> single (failing or passing) test is (also) a regression. Look at the
>>> original
>>>
> [0.591409] test_printf: all 388 tests passed
>>>
>>> or
>>>
> [0.619495] test_printf: failed 3 out of 388 tests
>>>
>>> That's far more informative, and I'd prefer if the summary information
>>> (whether in the all-good case or some-failing) included something like
>>> this. In particular, I have at some point spotted that I failed to
>>> properly hook up a new test case (or perhaps failed to re-compile, or
>>> somehow still ran the old kernel binary, don't remember which it was) by
>>> noticing that the total number of tests hadn't increased. The new output
>>> would not help catch such PEBKACs.
>>>
>>> Rasmus
>>>
>>
>> Splitting the test into multiple test cases in KUnit will display
>> the number and name of tests that pass or fail. This will be similar
>> to the lib/list-test.c test as can be seen here:
>> https://elixir.bootlin.com/linux/latest/source/lib/list-test.c.
>> I will work on this for the next version of this patch.
>
> We should probably agree on the granularity first.
>
> It looks like an overkill to split the tests into 388 functions
> and define KUNIT_CASE() lines. It might be possible to hide
> this into macros but macros are hell for debugging.
>
> I suggest to split it by the current functions that do more test()
> call inside. I mean to define something like:
>
> static struct kunit_case printf_test_cases[] = {
> KUNIT_CASE(basic),
> KUNIT_CASE(number),
> KUNIT_CASE(string),
> KUNIT_CASE(plain_pointer),
> KUNIT_CASE(null_poiter),
> KUNIT_CASE(error_pointer),
> KUNIT_CASE(addr),
> KUNIT_CASE(struct_resource),
> KUNIT_CASE(dentry),
> KUNIT_CASE(pointer_addr),
>...,
> {}
> };
>
> Best Regards,
> Petr
>
Okay, I will split it by the current functions that have more test() calls
inside as suggested.
I will also make changes as per your other suggestions for the next version.
Thanks!
[PATCH v3] ASoC: Intel: boards: Add CML_RT1015 m/c driver
From: Keith Tzeng
Machine driver to enable RT5682 on SSP0, DMIC, HDMI and RT1015 AMP on
SSP1: Enabled 4 CH TDM playback with 24 bit data.
Signed-off-by: Keith Tzeng
---
sound/soc/intel/boards/Kconfig| 15 +
sound/soc/intel/boards/Makefile | 2 +
sound/soc/intel/boards/cml_rt1015_rt5682.c| 570 ++
sound/soc/intel/common/soc-acpi-intel-cnl-match.c | 7 +
4 files changed, 594 insertions(+)
create mode 100644 sound/soc/intel/boards/cml_rt1015_rt5682.c
diff --git a/sound/soc/intel/boards/Kconfig b/sound/soc/intel/boards/Kconfig
index c10c378..f674c56 100644
--- a/sound/soc/intel/boards/Kconfig
+++ b/sound/soc/intel/boards/Kconfig
@@ -496,6 +496,21 @@ config SND_SOC_INTEL_SOF_CML_RT1011_RT5682_MACH
Say Y if you have such a device.
If unsure select "N".
+config SND_SOC_INTEL_SOF_CML_RT1015_RT5682_MACH
+tristate "CML with RT1015 and RT5682 in I2S Mode"
+depends on I2C && ACPI && GPIOLIB
+depends on MFD_INTEL_LPSS || COMPILE_TEST
+depends on SND_HDA_CODEC_HDMI && SND_SOC_SOF_HDA_AUDIO_CODEC
+select SND_SOC_RT1015
+select SND_SOC_RT5682_I2C
+select SND_SOC_DMIC
+select SND_SOC_HDAC_HDMI
+help
+ This adds support for ASoC machine driver for SOF platform with
+ RT1015 + RT5682 I2S codec.
+ Say Y if you have such a device.
+ If unsure select "N".
+
endif ## SND_SOC_SOF_COMETLAKE && SND_SOC_SOF_HDA_LINK
if SND_SOC_SOF_JASPERLAKE
diff --git a/sound/soc/intel/boards/Makefile b/sound/soc/intel/boards/Makefile
index a58e4d2..73131cc 100644
--- a/sound/soc/intel/boards/Makefile
+++ b/sound/soc/intel/boards/Makefile
@@ -20,6 +20,7 @@ snd-soc-sst-byt-cht-es8316-objs := bytcht_es8316.o
snd-soc-sst-byt-cht-nocodec-objs := bytcht_nocodec.o
snd-soc-sof_rt5682-objs := sof_rt5682.o hda_dsp_common.o sof_maxim_common.o
snd-soc-cml_rt1011_rt5682-objs := cml_rt1011_rt5682.o hda_dsp_common.o
+snd-soc-cml_rt1015_rt5682-objs := cml_rt1015_rt5682.o
snd-soc-kbl_da7219_max98357a-objs := kbl_da7219_max98357a.o
snd-soc-kbl_da7219_max98927-objs := kbl_da7219_max98927.o
snd-soc-kbl_rt5663_max98927-objs := kbl_rt5663_max98927.o
@@ -60,6 +61,7 @@ obj-$(CONFIG_SND_SOC_INTEL_BYT_CHT_DA7213_MACH) +=
snd-soc-sst-byt-cht-da7213.o
obj-$(CONFIG_SND_SOC_INTEL_BYT_CHT_ES8316_MACH) += snd-soc-sst-byt-cht-es8316.o
obj-$(CONFIG_SND_SOC_INTEL_BYT_CHT_NOCODEC_MACH) +=
snd-soc-sst-byt-cht-nocodec.o
obj-$(CONFIG_SND_SOC_INTEL_SOF_CML_RT1011_RT5682_MACH) +=
snd-soc-cml_rt1011_rt5682.o
+obj-$(CONFIG_SND_SOC_INTEL_SOF_CML_RT1015_RT5682_MACH) += cml_rt1015_rt5682.o
obj-$(CONFIG_SND_SOC_INTEL_KBL_DA7219_MAX98357A_MACH) +=
snd-soc-kbl_da7219_max98357a.o
obj-$(CONFIG_SND_SOC_INTEL_KBL_DA7219_MAX98927_MACH) +=
snd-soc-kbl_da7219_max98927.o
obj-$(CONFIG_SND_SOC_INTEL_KBL_RT5663_MAX98927_MACH) +=
snd-soc-kbl_rt5663_max98927.o
diff --git a/sound/soc/intel/boards/cml_rt1015_rt5682.c
b/sound/soc/intel/boards/cml_rt1015_rt5682.c
new file mode 100644
index 000..9117f52
--- /dev/null
+++ b/sound/soc/intel/boards/cml_rt1015_rt5682.c
@@ -0,0 +1,570 @@
+// SPDX-License-Identifier: GPL-2.0
+// Copyright(c) 2019 Intel Corporation.
+
+/*
+ * Intel Cometlake I2S Machine driver for RT1015 + RT5682 codec
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include "../../codecs/rt1015.h"
+#include "../../codecs/rt5682.h"
+#include "../../codecs/hdac_hdmi.h"
+
+/* The platform clock outputs 24Mhz clock to codec as I2S MCLK */
+#define CML_PLAT_CLK 2400
+#define CML_RT1015_CODEC_DAI "rt1015-aif"
+#define CML_RT5682_CODEC_DAI "rt5682-aif1"
+#define NAME_SIZE 32
+
+#define SOF_RT1015_SPEAKER_WL BIT(0)
+#define SOF_RT1015_SPEAKER_WR BIT(1)
+#define SOF_RT1015_SPEAKER_TL BIT(2)
+#define SOF_RT1015_SPEAKER_TR BIT(3)
+#define SPK_CH 4
+
+/* Default: Woofer speakers */
+static unsigned long sof_rt1015_quirk = SOF_RT1015_SPEAKER_WL |
+ SOF_RT1015_SPEAKER_WR;
+
+static int sof_rt1015_quirk_cb(const struct dmi_system_id *id)
+{
+ sof_rt1015_quirk = (unsigned long)id->driver_data;
+ return 1;
+}
+
+static const struct dmi_system_id sof_rt1015_quirk_table[] = {
+ {
+ .callback = sof_rt1015_quirk_cb,
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "Google"),
+ DMI_MATCH(DMI_PRODUCT_NAME, "Dooly"),
+ },
+ .driver_data = (void *)(SOF_RT1015_SPEAKER_WL |
SOF_RT1015_SPEAKER_WR),
+ },
+ {
+ }
+};
+
+static struct snd_soc_jack hdmi_jack[3];
+
+struct hdmi_pcm {
+ struct list_head head;
+ struct snd_soc_dai *codec_dai;
+ int device;
+};
+
+struct card_private {
+ char codec_name[SND_ACPI_I2C_ID_LEN];
+ struct snd_soc_jack headset;
Re: [PATCH 1/2] mm: reorganize internal_get_user_pages_fast()
On 10/23/20 5:19 PM, Jason Gunthorpe wrote:
The next patch in this series makes the lockless flow a little more
complex, so move the entire block into a new function and remove a level
of indention. Tidy a bit of cruft:
- addr is always the same as start, so use start
- Use the modern check_add_overflow() for computing end = start + len
- nr_pinned << PAGE_SHIFT needs an unsigned long cast, like nr_pages
- The handling of ret and nr_pinned can be streamlined a bit
No functional change.
Looks nice. Because of the above, which is not just code movement but
quite a bit more than that, I had to rake through it with a fine-toothed
comb to be sure it's OK. I think it is. But as a side effect, I noticed
some tiny polishing ideas that popped up, see below.
Signed-off-by: Jason Gunthorpe
---
mm/gup.c | 88 +---
1 file changed, 46 insertions(+), 42 deletions(-)
diff --git a/mm/gup.c b/mm/gup.c
index 102877ed77a4b4..ecbe1639ea2af7 100644
--- a/mm/gup.c
+++ b/mm/gup.c
@@ -2671,13 +2671,42 @@ static int __gup_longterm_unlocked(unsigned long start,
int nr_pages,
return ret;
}
+static unsigned int lockless_pages_from_mm(unsigned long addr,
It would be slightly more consistent to use "start" here, too, instead of addr.
Separately, I'm not joyful about the change to unsigned int for the
return type. I understand why you did it and that's perfectly sound
reasoning: there is no -ERRNO possible here, and nr_pinned will always
be >=0. And it's correct, although it does have a type mismatch in the
return value.
However, I'd argue, mildly, that it's better to just leave everything as
"int" for nr_pages and nr_pinned, in gup.c, and just keep all the types
matched perfectly. This helps avoid bugs. And if we want to meaningfully
upgrade that, then either:
a) change all the nr_pages and nr_pinned throughout, to "long", or
b) change all the nr_pages and nr_pinned all function args, and use int
return types throughout, as a "O or -ERRNO, only" return value
convention.
+ unsigned long end,
+ unsigned int gup_flags,
+ struct page **pages)
+{
+ unsigned long flags;
+ int nr_pinned = 0;
+
+ if (!IS_ENABLED(CONFIG_HAVE_FAST_GUP) ||
+ !gup_fast_permitted(addr, end))
That actually fits on a single 80-col line, so let's leave it that way:
if (!IS_ENABLED(CONFIG_HAVE_FAST_GUP) || !gup_fast_permitted(addr, end))
+ return 0;
+
+ /*
+* Disable interrupts. The nested form is used, in order to allow full,
+* general purpose use of this routine.
+*
+* With interrupts disabled, we block page table pages from being freed
+* from under us. See struct mmu_table_batch comments in
+* include/asm-generic/tlb.h for more details.
+*
+* We do not adopt an rcu_read_lock(.) here as we also want to block
+* IPIs that come from THPs splitting.
+*/
+ local_irq_save(flags);
+ gup_pgd_range(addr, end, gup_flags, pages, &nr_pinned);
+ local_irq_restore(flags);
+ return nr_pinned;
+}
+
static int internal_get_user_pages_fast(unsigned long start, int nr_pages,
unsigned int gup_flags,
struct page **pages)
{
- unsigned long addr, len, end;
- unsigned long flags;
- int nr_pinned = 0, ret = 0;
+ unsigned long len, end;
+ unsigned int nr_pinned;
If you choose to take the advice above, then this should be left as "int
nr_pinned".
+ int ret;
if (WARN_ON_ONCE(gup_flags & ~(FOLL_WRITE | FOLL_LONGTERM |
FOLL_FORCE | FOLL_PIN | FOLL_GET |
@@ -2691,53 +2720,28 @@ static int internal_get_user_pages_fast(unsigned long
start, int nr_pages,
might_lock_read(¤t->mm->mmap_lock);
start = untagged_addr(start) & PAGE_MASK;
- addr = start;
len = (unsigned long) nr_pages << PAGE_SHIFT;
- end = start + len;
-
- if (end <= start)
+ if (check_add_overflow(start, len, &end))
return 0;
Very nice.
if (unlikely(!access_ok((void __user *)start, len)))
return -EFAULT;
- /*
-* Disable interrupts. The nested form is used, in order to allow
-* full, general purpose use of this routine.
-*
-* With interrupts disabled, we block page table pages from being
-* freed from under us. See struct mmu_table_batch comments in
-* include/asm-generic/tlb.h for more details.
-*
-* We do not adopt an rcu_read_lock(.) here as we also want to
I wish I had not copied that comment verbatim when I moved it here. Can
you please delete the weird ".", so that it just reads:
* We do not adopt an rcu_read_
Re: [PATCH v5 2/2] Add user-mode only option to unprivileged_userfaultfd sysctl knob
On Fri, Oct 23, 2020 at 7:48 PM Andrea Arcangeli wrote: > > Hello everyone, > > On Sat, Oct 10, 2020 at 11:24:56PM -0700, Lokesh Gidra wrote: > > With this change, when the knob is set to 0, it allows unprivileged > > users to call userfaultfd, like when it is set to 1, but with the > > restriction that page faults from only user-mode can be handled. > > In this mode, an unprivileged user (without SYS_CAP_PTRACE capability) > > must pass UFFD_USER_MODE_ONLY to userfaultd or the API will fail with > > EPERM. > > > > This enables administrators to reduce the likelihood that > > an attacker with access to userfaultfd can delay faulting kernel > > code to widen timing windows for other exploits. > > > > The default value of this knob is changed to 0. This is required for > > correct functioning of pipe mutex. However, this will fail postcopy > > live migration, which will be unnoticeable to the VM guests. To avoid > > this, set 'vm.userfault = 1' in /sys/sysctl.conf. For more details, > > refer to Andrea's reply [1]. > > > > [1] https://lore.kernel.org/lkml/20200904033438.gi9...@redhat.com/ > > > > Signed-off-by: Lokesh Gidra > > Nobody commented so it seems everyone is on board with this change to > synchronize the kernel default with the post-boot Android default. > > The email in the link above was pretty long, so the below would be a > summary that could be added to the commit header: > > == > > The main reason this change is desirable as in the short term is that > the Android userland will behave as with the sysctl set to zero. So > without this commit, any Linux binary using userfaultfd to manage its > memory would behave differently if run within the Android userland. > > == Sure. I'll add it in the next revision. > > Reviewed-by: Andrea Arcangeli > Thanks so much for the review. I hope it's ok to add your 'reviewed-by' in the next revision? > > BTW, this is still a minor nitpick, but a printk_once of the 1/2 could > be added before the return -EPERM too, that's actually what I meant > when I suggested to add a printk_once :), however the printk_once you > added can turn out to be useful too for devs converting code to use > bounce buffers, so it's fine too, just it could go under DEBUG_VM and > to be ratelimited (similarly to the "FAULT_FLAG_ALLOW_RETRY missing > %x\n" printk). I'll move the printk_once from 1/2 to this patch, as you suggested. > > Thanks, > Andrea >
Re: [PATCH 0/3] Add support to handle prefetchable memory
On 10/23/20, 3:57 PM, Vidya Sagar wrote: > > This patch series adds support for configuring the DesignWare IP's ATU > region for prefetchable memory translations. > It first starts by flagging a warning if the size of non-prefetchable > aperture goes beyond 32-bit as PCIe spec doesn't allow it. > And then adds required support for programming the ATU to handle higher > (i.e. >4GB) sizes and then finally adds support for differentiating > between prefetchable and non-prefetchable regions and configuring one of > the ATU regions for prefetchable memory translations purpose. > > Vidya Sagar (3): > PCI: of: Warn if non-prefetchable memory aperture size is > 32-bit > PCI: dwc: Add support to program ATU for >4GB memory aperture sizes > PCI: dwc: Add support to handle prefetchable memory mapping For 2nd & 3rd, Acked-by: Jingoo But, I still want someone to ack 1st patch, not me. To Vidya, If possible, can you ask your coworker to give 'Tested-by'? It will be very helpful. Thank you. Best regards, Jingoo Han > > .../pci/controller/dwc/pcie-designware-host.c | 39 --- > drivers/pci/controller/dwc/pcie-designware.c | 12 +++--- > drivers/pci/controller/dwc/pcie-designware.h | 4 +- > drivers/pci/of.c | 5 +++ > 4 files changed, 48 insertions(+), 12 deletions(-) > > -- > 2.17.1
ld.lld: warning: fs/built-in.a(cifs/smb2pdu.o):(.data..L__unnamed_18) is being placed in '.data..L__unnamed_18'
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: b76f733c3ff83089cf1e3f9ae233533649f999b3 commit: 29e279230413cdd5e00fb5d269cae1099184ab85 smb3.1.1: add new module load parm enable_gcm_256 date: 8 days ago config: powerpc64-randconfig-r004-20201022 (attached as .config) compiler: clang version 12.0.0 (https://github.com/llvm/llvm-project 147b9497e79a98a8614b2b5eb4ba653b44f6b6f0) reproduce (this is a W=1 build): wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # install powerpc64 cross compiling tool for clang build # apt-get install binutils-powerpc64-linux-gnu # https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=29e279230413cdd5e00fb5d269cae1099184ab85 git remote add linus https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git git fetch --no-tags linus master git checkout 29e279230413cdd5e00fb5d269cae1099184ab85 # save the attached .config to linux build tree COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=powerpc64 If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot All warnings (new ones prefixed by >>): ld.lld: warning: fs/built-in.a(cifs/connect.o):(.data..L__unnamed_24) is being placed in '.data..L__unnamed_24' ld.lld: warning: fs/built-in.a(cifs/connect.o):(.data..L__unnamed_25) is being placed in '.data..L__unnamed_25' ld.lld: warning: fs/built-in.a(cifs/connect.o):(.data..L__unnamed_26) is being placed in '.data..L__unnamed_26' ld.lld: warning: fs/built-in.a(cifs/connect.o):(.data..L__unnamed_20) is being placed in '.data..L__unnamed_20' ld.lld: warning: fs/built-in.a(cifs/connect.o):(.data..L__unnamed_21) is being placed in '.data..L__unnamed_21' ld.lld: warning: fs/built-in.a(cifs/connect.o):(.data..L__unnamed_27) is being placed in '.data..L__unnamed_27' ld.lld: warning: fs/built-in.a(cifs/connect.o):(.data..L__unnamed_33) is being placed in '.data..L__unnamed_33' ld.lld: warning: fs/built-in.a(cifs/connect.o):(.data..L__unnamed_29) is being placed in '.data..L__unnamed_29' ld.lld: warning: fs/built-in.a(cifs/connect.o):(.data..L__unnamed_30) is being placed in '.data..L__unnamed_30' ld.lld: warning: fs/built-in.a(cifs/dir.o):(.data..L__unnamed_1) is being placed in '.data..L__unnamed_1' ld.lld: warning: fs/built-in.a(cifs/dir.o):(.data..L__unnamed_2) is being placed in '.data..L__unnamed_2' ld.lld: warning: fs/built-in.a(cifs/dir.o):(.data..L__unnamed_3) is being placed in '.data..L__unnamed_3' ld.lld: warning: fs/built-in.a(cifs/file.o):(.data..L__unnamed_1) is being placed in '.data..L__unnamed_1' ld.lld: warning: fs/built-in.a(cifs/file.o):(.data..L__unnamed_4) is being placed in '.data..L__unnamed_4' ld.lld: warning: fs/built-in.a(cifs/file.o):(.data..L__unnamed_7) is being placed in '.data..L__unnamed_7' ld.lld: warning: fs/built-in.a(cifs/file.o):(.data..L__unnamed_8) is being placed in '.data..L__unnamed_8' ld.lld: warning: fs/built-in.a(cifs/file.o):(.data..L__unnamed_11) is being placed in '.data..L__unnamed_11' ld.lld: warning: fs/built-in.a(cifs/file.o):(.data..L__unnamed_12) is being placed in '.data..L__unnamed_12' ld.lld: warning: fs/built-in.a(cifs/file.o):(.data..L__unnamed_3) is being placed in '.data..L__unnamed_3' ld.lld: warning: fs/built-in.a(cifs/file.o):(.data..L__unnamed_5) is being placed in '.data..L__unnamed_5' ld.lld: warning: fs/built-in.a(cifs/file.o):(.data..L__unnamed_6) is being placed in '.data..L__unnamed_6' ld.lld: warning: fs/built-in.a(cifs/file.o):(.data..L__unnamed_9) is being placed in '.data..L__unnamed_9' ld.lld: warning: fs/built-in.a(cifs/file.o):(.data..L__unnamed_10) is being placed in '.data..L__unnamed_10' ld.lld: warning: fs/built-in.a(cifs/file.o):(.data..L__unnamed_14) is being placed in '.data..L__unnamed_14' ld.lld: warning: fs/built-in.a(cifs/file.o):(.data..L__unnamed_13) is being placed in '.data..L__unnamed_13' ld.lld: warning: fs/built-in.a(cifs/file.o):(.data..L__unnamed_15) is being placed in '.data..L__unnamed_15' ld.lld: warning: fs/built-in.a(cifs/file.o):(.data..L__unnamed_16) is being placed in '.data..L__unnamed_16' ld.lld: warning: fs/built-in.a(cifs/file.o):(.data..L__unnamed_18) is being placed in '.data..L__unnamed_18' ld.lld: warning: fs/built-in.a(cifs/file.o):(.data..L__unnamed_17) is being placed in '.data..L__unnamed_17' ld.lld: warning: fs/built-in.a(cifs/file.o):(.data..L__unnamed_20) is being placed in '.data..L__unnamed_20' ld.lld: warning: fs/built-in.a(cifs/file.o):(.data..L__unnamed_19) is being placed in '.data..L__unnamed_19' ld.lld: warning: fs/built-in.a(cifs/file.o):(.data..L__unnamed_21) is being placed in '.data..L__unnamed_21' ld.lld: warning: fs/built-in.a(cifs/file.o):(.da
[PATCH] drm/rockchip: dw_hdmi: fix incorrect clock in vpll clock error message
Error message incorrectly refers to grf clock instead of vpll clock.
Signed-off-by: Jonathan Liu
---
drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
index 23de359a1dec..830bdd5e9b7c 100644
--- a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
+++ b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
@@ -202,7 +202,7 @@ static int rockchip_hdmi_parse_dt(struct rockchip_hdmi
*hdmi)
} else if (PTR_ERR(hdmi->vpll_clk) == -EPROBE_DEFER) {
return -EPROBE_DEFER;
} else if (IS_ERR(hdmi->vpll_clk)) {
- DRM_DEV_ERROR(hdmi->dev, "failed to get grf clock\n");
+ DRM_DEV_ERROR(hdmi->dev, "failed to get vpll clock\n");
return PTR_ERR(hdmi->vpll_clk);
}
--
2.29.1
Re: [PATCH v4 23/23] drm/msm: Don't implicit-sync if only a single ring
On Fri, Oct 23, 2020 at 11:20 AM Lucas Stach wrote:
>
> On Fr, 2020-10-23 at 09:51 -0700, Rob Clark wrote:
> > From: Rob Clark
> >
> > If there is only a single ring (no-preemption), everything is FIFO order
> > and there is no need to implicit-sync.
> >
> > Mesa should probably just always use MSM_SUBMIT_NO_IMPLICIT, as behavior
> > is undefined when fences are not used to synchronize buffer usage across
> > contexts (which is the only case where multiple different priority rings
> > could come into play).
>
> Really, doesn't this break cross-device implicit sync? Okay, you may
> not have many peripherals that rely on implicit sync on devices where
> Adreno is usually found, but it seems rather heavy-handed.
>
> Wouldn't it be better to only ignore fences from your own ring context
> in the implicit sync, like we do in the common DRM scheduler
> (drm_sched_dependency_optimized)?
we already do this.. as was discussed on an earlier iteration of this patchset
But I'm not aware of any other non-gpu related implicit sync use-case
(even on imx devices where display is decoupled from gpu).. I'll
revert the patch if someone comes up with one, but otherwise lets let
the implicit sync baggage die
BR,
-R
>
> Regards,
> Lucas
>
> > Signed-off-by: Rob Clark
> > Reviewed-by: Kristian H. Kristensen
> > ---
> > drivers/gpu/drm/msm/msm_gem_submit.c | 7 ---
> > 1 file changed, 4 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/msm/msm_gem_submit.c
> > b/drivers/gpu/drm/msm/msm_gem_submit.c
> > index d04c349d8112..b6babc7f9bb8 100644
> > --- a/drivers/gpu/drm/msm/msm_gem_submit.c
> > +++ b/drivers/gpu/drm/msm/msm_gem_submit.c
> > @@ -283,7 +283,7 @@ static int submit_lock_objects(struct msm_gem_submit
> > *submit)
> > return ret;
> > }
> >
> > -static int submit_fence_sync(struct msm_gem_submit *submit, bool
> > no_implicit)
> > +static int submit_fence_sync(struct msm_gem_submit *submit, bool
> > implicit_sync)
> > {
> > int i, ret = 0;
> >
> > @@ -303,7 +303,7 @@ static int submit_fence_sync(struct msm_gem_submit
> > *submit, bool no_implicit)
> > return ret;
> > }
> >
> > - if (no_implicit)
> > + if (!implicit_sync)
> > continue;
> >
> > ret = msm_gem_sync_object(&msm_obj->base, submit->ring->fctx,
> > @@ -774,7 +774,8 @@ int msm_ioctl_gem_submit(struct drm_device *dev, void
> > *data,
> > if (ret)
> > goto out;
> >
> > - ret = submit_fence_sync(submit, !!(args->flags &
> > MSM_SUBMIT_NO_IMPLICIT));
> > + ret = submit_fence_sync(submit, (gpu->nr_rings > 1) &&
> > + !(args->flags & MSM_SUBMIT_NO_IMPLICIT));
> > if (ret)
> > goto out;
> >
>
Re: kvm+nouveau induced lockdep gripe
On Sat, 2020-10-24 at 10:22 +0800, Hillf Danton wrote:
>
> Looks like we can break the lock chain by moving ttm bo's release
> method out of mmap_lock, see diff below.
Ah, the perfect compliment to morning java, a patchlet to wedge in and
see what happens.
wedge/build/boot
Mmm, box says no banana... a lot.
[ 30.456921]
[ 30.456924] WARNING: inconsistent lock state
[ 30.456928] 5.9.0.gf11901e-master #2 Tainted: G S E
[ 30.456932]
[ 30.456935] inconsistent {SOFTIRQ-ON-W} -> {IN-SOFTIRQ-W} usage.
[ 30.456940] ksoftirqd/4/36 [HC0[0]:SC1[1]:HE1:SE0] takes:
[ 30.456944] 8e2c8bde9e40 (&mgr->vm_lock){++?+}-{2:2}, at:
drm_vma_offset_remove+0x14/0x70 [drm]
[ 30.456976] {SOFTIRQ-ON-W} state was registered at:
[ 30.456982] lock_acquire+0x1a7/0x3b0
[ 30.456987] _raw_write_lock+0x2f/0x40
[ 30.457006] drm_vma_offset_add+0x1c/0x60 [drm]
[ 30.457013] ttm_bo_init_reserved+0x28b/0x460 [ttm]
[ 30.457020] ttm_bo_init+0x57/0x110 [ttm]
[ 30.457066] nouveau_bo_init+0xb0/0xc0 [nouveau]
[ 30.457108] nouveau_bo_new+0x4d/0x60 [nouveau]
[ 30.457145] nv84_fence_create+0xb9/0x130 [nouveau]
[ 30.457180] nvc0_fence_create+0xe/0x47 [nouveau]
[ 30.457221] nouveau_drm_device_init+0x3d9/0x800 [nouveau]
[ 30.457262] nouveau_drm_probe+0xfb/0x200 [nouveau]
[ 30.457268] local_pci_probe+0x42/0x90
[ 30.457272] pci_device_probe+0xe7/0x1a0
[ 30.457276] really_probe+0xf7/0x4d0
[ 30.457280] driver_probe_device+0x5d/0x140
[ 30.457284] device_driver_attach+0x4f/0x60
[ 30.457288] __driver_attach+0xa4/0x140
[ 30.457292] bus_for_each_dev+0x67/0x90
[ 30.457296] bus_add_driver+0x18c/0x230
[ 30.457299] driver_register+0x5b/0xf0
[ 30.457304] do_one_initcall+0x54/0x2f0
[ 30.457309] do_init_module+0x5b/0x21b
[ 30.457314] load_module+0x1e40/0x2370
[ 30.457317] __do_sys_finit_module+0x98/0xe0
[ 30.457321] do_syscall_64+0x33/0x40
[ 30.457326] entry_SYSCALL_64_after_hwframe+0x44/0xa9
[ 30.457329] irq event stamp: 366850
[ 30.457335] hardirqs last enabled at (366850): []
rcu_nocb_unlock_irqrestore+0x4f/0x60
[ 30.457342] hardirqs last disabled at (366849): []
rcu_do_batch+0x59f/0x990
[ 30.457347] softirqs last enabled at (366834): []
__do_softirq+0x2d7/0x4a4
[ 30.457357] softirqs last disabled at (366839): []
run_ksoftirqd+0x32/0x60
[ 30.457363]
other info that might help us debug this:
[ 30.457369] Possible unsafe locking scenario:
[ 30.457375]CPU0
[ 30.457378]
[ 30.457381] lock(&mgr->vm_lock);
[ 30.457386]
[ 30.457389] lock(&mgr->vm_lock);
[ 30.457394]
*** DEADLOCK ***
Re: [PATCH 2/3] irqchip/irq-sifive-plic: Fixup couldn't broadcast to multi CPUs
On Fri, Oct 23, 2020 at 8:17 PM Anup Patel wrote:
>
> On Fri, Oct 23, 2020 at 3:48 PM wrote:
> >
> > From: Guo Ren
> >
> > If "echo 3 > /proc/irq/1/smp_affinity", we want irq 1 could be
> > broadcast to CPU0 & CPU1 and one of them would pick up the irq
> > handler.
> >
> > But current implementation couldn't let multi CPUs process the
> > same IRQ concurrent.
> >
> > Signed-off-by: Guo Ren
> > ---
> > drivers/irqchip/irq-sifive-plic.c | 23 ++-
> > 1 file changed, 6 insertions(+), 17 deletions(-)
> >
> > diff --git a/drivers/irqchip/irq-sifive-plic.c
> > b/drivers/irqchip/irq-sifive-plic.c
> > index 2e56576..0003322 100644
> > --- a/drivers/irqchip/irq-sifive-plic.c
> > +++ b/drivers/irqchip/irq-sifive-plic.c
> > @@ -114,15 +114,12 @@ static inline void plic_irq_toggle(const struct
> > cpumask *mask,
> > static void plic_irq_unmask(struct irq_data *d)
> > {
> > struct cpumask amask;
> > - unsigned int cpu;
> > struct plic_priv *priv = irq_get_chip_data(d->irq);
> >
> > cpumask_and(&amask, &priv->lmask, cpu_online_mask);
> > - cpu = cpumask_any_and(irq_data_get_affinity_mask(d),
> > - &amask);
> > - if (WARN_ON_ONCE(cpu >= nr_cpu_ids))
> > - return;
> > - plic_irq_toggle(cpumask_of(cpu), d, 1);
> > + cpumask_and(&amask, &amask, irq_data_get_affinity_mask(d));
> > +
> > + plic_irq_toggle(&amask, d, 1);
> > }
> >
> > static void plic_irq_mask(struct irq_data *d)
> > @@ -136,24 +133,16 @@ static void plic_irq_mask(struct irq_data *d)
> > static int plic_set_affinity(struct irq_data *d,
> > const struct cpumask *mask_val, bool force)
> > {
> > - unsigned int cpu;
> > struct cpumask amask;
> > struct plic_priv *priv = irq_get_chip_data(d->irq);
> >
> > cpumask_and(&amask, &priv->lmask, mask_val);
> > + cpumask_and(&amask, &amask, cpu_online_mask);
> >
> > - if (force)
> > - cpu = cpumask_first(&amask);
> > - else
> > - cpu = cpumask_any_and(&amask, cpu_online_mask);
> > -
> > - if (cpu >= nr_cpu_ids)
> > - return -EINVAL;
> > + irq_data_update_effective_affinity(d, &amask);
> >
> > plic_irq_toggle(&priv->lmask, d, 0);
> > - plic_irq_toggle(cpumask_of(cpu), d, 1);
> > -
> > - irq_data_update_effective_affinity(d, cpumask_of(cpu));
> > + plic_irq_toggle(&amask, d, 1);
> >
> > return IRQ_SET_MASK_OK_DONE;
> > }
> > --
> > 2.7.4
> >
>
> In the past, a similar patch was proposed by Zong Li (SiFive). We
> have good reasons to not allow multiple CPUs handle the same IRQ.
>
> Refer, https://lkml.org/lkml/2020/4/26/201
>
> NACK from my side.
Thx for sharing the information, I agree with Zong Li & Greentime's
aspect: Don't limit the usage of PLIC! We could let (one hart -> one
irq) as default.
I also agree that using irq broadcast indiscriminately can cause
performance problems. (Anup and Mark Z's view)
I think you've discussed enough at that time and l won't persist the patch.
--
Best Regards
Guo Ren
ML: https://lore.kernel.org/linux-csky/
[PATCH] KVM: x86/mmu: Avoid modulo operator on 64-bit value to fix i386 build
Replace a modulo operator with the more common pattern for computing the
gfn "offset" of a huge page to fix an i386 build error.
arch/x86/kvm/mmu/tdp_mmu.c:212: undefined reference to `__umoddi3'
Fixes: 2f2fad0897cb ("kvm: x86/mmu: Add functions to handle changed TDP SPTEs")
Reported-by: Daniel Díaz
Signed-off-by: Sean Christopherson
---
Linus, do you want to take this directly so that it's in rc1? I don't
know whether Paolo will be checking mail before then.
arch/x86/kvm/mmu/tdp_mmu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/kvm/mmu/tdp_mmu.c b/arch/x86/kvm/mmu/tdp_mmu.c
index e246d71b8ea2..27e381c9da6c 100644
--- a/arch/x86/kvm/mmu/tdp_mmu.c
+++ b/arch/x86/kvm/mmu/tdp_mmu.c
@@ -209,7 +209,7 @@ static void __handle_changed_spte(struct kvm *kvm, int
as_id, gfn_t gfn,
WARN_ON(level > PT64_ROOT_MAX_LEVEL);
WARN_ON(level < PG_LEVEL_4K);
- WARN_ON(gfn % KVM_PAGES_PER_HPAGE(level));
+ WARN_ON(gfn & (KVM_PAGES_PER_HPAGE(level) - 1));
/*
* If this warning were to trigger it would indicate that there was a
--
2.28.0
Re: [PATCH v2 5/6] pci: dwc: pci-exynos: rework the driver to support Exynos5433 variant
On 10/23/20, 3:58 AM, Marek Szyprowski wrote:
>
> From: Jaehoon Chung
>
> Exynos5440 SoC support has been dropped since commit 8c83315da1cf ("ARM:
> dts: exynos: Remove Exynos5440"). Rework this driver to support DWC PCIe
> variant found in the Exynos5433 SoCs.
>
> The main difference in Exynos5433 variant is lack of the MSI support
> (the MSI interrupt is not even routed to the CPU).
>
> Signed-off-by: Jaehoon Chung
> [mszyprow: reworked the driver to support only Exynos5433 variant,
> simplified code, rebased onto current kernel code, added
> regulator support, converted to the regular platform driver,
> removed MSI related code, rewrote commit message]
> Signed-off-by: Marek Szyprowski
> Acked-by: Krzysztof Kozlowski
> ---
> drivers/pci/controller/dwc/Kconfig | 3 +-
> drivers/pci/controller/dwc/pci-exynos.c | 358 ++--
> drivers/pci/quirks.c| 1 +
> 3 files changed, 145 insertions(+), 217 deletions(-)
[]
> diff --git a/drivers/pci/controller/dwc/pci-exynos.c
> b/drivers/pci/controller/dwc/pci-exynos.c
> index 242683cde04a..58056fbdc2fa 100644
> --- a/drivers/pci/controller/dwc/pci-exynos.c
> +++ b/drivers/pci/controller/dwc/pci-exynos.c
> @@ -2,26 +2,23 @@
> /*
> * PCIe host controller driver for Samsung Exynos SoCs
> *
> - * Copyright (C) 2013 Samsung Electronics Co., Ltd.
> + * Copyright (C) 2013-2020 Samsung Electronics Co., Ltd.
> * https://www.samsung.com
> *
> * Author: Jingoo Han
> + * Jaehoon Chung
Would you explain the reason why you add him as an author?
If reasonable, I will accept it. Also, I want gentle discussion, not aggressive
one.
Thank you.
Best regards,
Jingoo Han
> */
[]
Re: [PATCH 1/3] irqchip/irq-sifive-plic: Fixup wrong size of xxx_PER_HART and reg base
On Fri, Oct 23, 2020 at 8:31 PM Anup Patel wrote:
>
> On Fri, Oct 23, 2020 at 3:48 PM wrote:
> >
> > From: Guo Ren
> >
> > ENABLE and CONTEXT registers contain M & S status for per-hart, so
> > ref to the specification the correct definition is double to the
> > current value.
> >
> > The value of hart_base and enable_base should be calculated by real
> > physical hartid not software id. Sometimes the CPU node's
> > from dts is not equal to the sequence index.
> >
> > Signed-off-by: Guo Ren
> > ---
> > drivers/irqchip/irq-sifive-plic.c | 12 ++--
> > 1 file changed, 6 insertions(+), 6 deletions(-)
> >
> > diff --git a/drivers/irqchip/irq-sifive-plic.c
> > b/drivers/irqchip/irq-sifive-plic.c
> > index eaa3e9f..2e56576 100644
> > --- a/drivers/irqchip/irq-sifive-plic.c
> > +++ b/drivers/irqchip/irq-sifive-plic.c
> > @@ -44,16 +44,16 @@
> > * Each hart context has a vector of interrupt enable bits associated with
> > it.
> > * There's one bit for each interrupt source.
> > */
> > -#define ENABLE_BASE0x2000
> > -#define ENABLE_PER_HART0x80
> > +#define ENABLE_BASE0x2080
> > +#define ENABLE_PER_HART0x100
> >
> > /*
> > * Each hart context has a set of control registers associated with it.
> > Right
> > * now there's only two: a source priority threshold over which the hart
> > will
> > * take an interrupt, and a register to claim interrupts.
> > */
> > -#define CONTEXT_BASE 0x20
> > -#define CONTEXT_PER_HART 0x1000
> > +#define CONTEXT_BASE 0x201000
> > +#define CONTEXT_PER_HART 0x2000
> > #define CONTEXT_THRESHOLD 0x00
> > #define CONTEXT_CLAIM 0x04
> >
> > @@ -358,10 +358,10 @@ static int __init plic_init(struct device_node *node,
> > cpumask_set_cpu(cpu, &priv->lmask);
> > handler->present = true;
> > handler->hart_base =
> > - priv->regs + CONTEXT_BASE + i * CONTEXT_PER_HART;
> > + priv->regs + CONTEXT_BASE + hartid *
> > CONTEXT_PER_HART;
> > raw_spin_lock_init(&handler->enable_lock);
> > handler->enable_base =
> > - priv->regs + ENABLE_BASE + i * ENABLE_PER_HART;
> > + priv->regs + ENABLE_BASE + hartid * ENABLE_PER_HART;
> > handler->priv = priv;
> > done:
> > for (hwirq = 1; hwirq <= nr_irqs; hwirq++)
> > --
> > 2.7.4
> >
>
> There is no one-to-one mapping between PLIC context and HARTID. Instead,
> we have many-to-one mapping between PLIC contexts and HARTID. In other
> words, we have one PLIC context for each interrupt capable mode (i.e.
> M/S-mode) of each HART.
>
> For example, on SiFive Unleashed we have 5 HARTs but HARTID=0 has
> only M-mode capable of taking interrupts so we have total (1 + 2x4) = 9
> PLIC contexts.
That's OK, but what the bug I want to point out is enable_base &
context_base should be calculated by 'hartid' not 'i'.
For example, how we deal with below dts configuration:
cpus {
#address-cells = <1>;
#size-cells = <0>;
timebase-frequency = <300>;
cpu@0 {
device_type = "cpu";
reg = <2>; //* different from index
status = "okay";
compatible = "riscv";
riscv,isa = "rv64imafdcsu";
mmu-type = "riscv,sv39";
cpu0_intc: interrupt-controller {
#interrupt-cells = <1>;
compatible = "riscv,cpu-intc";
interrupt-controller;
};
};
cpu@1 {
device_type = "cpu";
reg = <3>; //* different from index
status = "fail";
compatible = "riscv";
riscv,isa = "rv64imafdcsu";
mmu-type = "riscv,sv39";
cpu1_intc: interrupt-controller {
#interrupt-cells = <1>;
compatible = "riscv,cpu-intc";
interrupt-controller;
};
};
}
>
> I would also like to highlight that this patch is forcing PLIC driver to
> always
> use PLIC S-mode context for each HART which breaks the Linux RISC-V
> NoMMU kernel.
Yes, I forgot M-mode and I will correct it.
>
> There is no issue with the existing defines because these are aligned with
> above and latest PLIC spec.
> (Refer, https://github.com/riscv/riscv-plic-spec/blob/master/riscv-plic.adoc)
>
> NACK to this patch from my side.
Here is my new patch which fixup m-mode linux:
d
Re: WARNING in dma_map_page_attrs
syzbot has found a reproducer for the following issue on: HEAD commit:3cb12d27 Merge tag 'net-5.10-rc1' of git://git.kernel.org/.. git tree: net console output: https://syzkaller.appspot.com/x/log.txt?x=1312539050 kernel config: https://syzkaller.appspot.com/x/.config?x=46c6fea3eb827ae1 dashboard link: https://syzkaller.appspot.com/bug?extid=34dc2fea3478e659af01 compiler: gcc (GCC) 10.1.0-syz 20200507 syz repro: https://syzkaller.appspot.com/x/repro.syz?x=1685866450 C reproducer: https://syzkaller.appspot.com/x/repro.c?x=11f402ef90 IMPORTANT: if you fix the issue, please add the following tag to the commit: Reported-by: syzbot+34dc2fea3478e659a...@syzkaller.appspotmail.com netdevsim netdevsim0 netdevsim1: set [1, 0] type 2 family 0 port 6081 - 0 netdevsim netdevsim0 netdevsim2: set [1, 0] type 2 family 0 port 6081 - 0 netdevsim netdevsim0 netdevsim3: set [1, 0] type 2 family 0 port 6081 - 0 infiniband syz2: set active infiniband syz2: added macvlan0 [ cut here ] WARNING: CPU: 1 PID: 8488 at kernel/dma/mapping.c:149 dma_map_page_attrs+0x493/0x700 kernel/dma/mapping.c:149 Modules linked in: CPU: 1 PID: 8488 Comm: syz-executor144 Not tainted 5.9.0-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:dma_map_page_attrs+0x493/0x700 kernel/dma/mapping.c:149 Code: 80 3c 10 00 0f 85 ed 01 00 00 48 8b 1d 86 38 e9 0c e9 2d fc ff ff 48 89 c3 e9 d1 fd ff ff e8 04 11 12 00 0f 0b e8 fd 10 12 00 <0f> 0b 49 c7 c4 ff ff ff ff e9 d5 fd ff ff e8 ea 10 12 00 48 8d 7b RSP: 0018:c9fdec68 EFLAGS: 00010293 RAX: RBX: 894d1060 RCX: 815df1e3 RDX: 8880208c1a40 RSI: 815df5b3 RDI: 8880196f8b00 RBP: 88801412d800 R08: 0002 R09: R10: 0002 R11: R12: ea504b40 R13: 8880196f86e8 R14: 08b8 R15: 0002 FS: 01b26880() GS:8880b9f0() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: 22c0 CR3: 22446000 CR4: 001506e0 DR0: DR1: DR2: DR3: DR6: fffe0ff0 DR7: 0400 Call Trace: dma_map_single_attrs include/linux/dma-mapping.h:279 [inline] ib_dma_map_single include/rdma/ib_verbs.h:3967 [inline] ib_mad_post_receive_mads+0x23f/0xd60 drivers/infiniband/core/mad.c:2715 ib_mad_port_start drivers/infiniband/core/mad.c:2862 [inline] ib_mad_port_open drivers/infiniband/core/mad.c:3016 [inline] ib_mad_init_device+0x72b/0x1400 drivers/infiniband/core/mad.c:3092 add_client_context+0x405/0x5e0 drivers/infiniband/core/device.c:680 enable_device_and_get+0x1d5/0x3c0 drivers/infiniband/core/device.c:1301 ib_register_device drivers/infiniband/core/device.c:1376 [inline] ib_register_device+0x7a7/0xa40 drivers/infiniband/core/device.c:1335 rxe_register_device+0x46d/0x570 drivers/infiniband/sw/rxe/rxe_verbs.c:1182 rxe_add+0x12fe/0x16d0 drivers/infiniband/sw/rxe/rxe.c:247 rxe_net_add+0x8c/0xe0 drivers/infiniband/sw/rxe/rxe_net.c:507 rxe_newlink drivers/infiniband/sw/rxe/rxe.c:269 [inline] rxe_newlink+0xb7/0xe0 drivers/infiniband/sw/rxe/rxe.c:250 nldev_newlink+0x30e/0x540 drivers/infiniband/core/nldev.c:1555 rdma_nl_rcv_msg+0x367/0x690 drivers/infiniband/core/netlink.c:195 rdma_nl_rcv_skb drivers/infiniband/core/netlink.c:239 [inline] rdma_nl_rcv+0x2f2/0x440 drivers/infiniband/core/netlink.c:259 netlink_unicast_kernel net/netlink/af_netlink.c:1304 [inline] netlink_unicast+0x533/0x7d0 net/netlink/af_netlink.c:1330 netlink_sendmsg+0x856/0xd90 net/netlink/af_netlink.c:1919 sock_sendmsg_nosec net/socket.c:651 [inline] sock_sendmsg+0xcf/0x120 net/socket.c:671 sys_sendmsg+0x6e8/0x810 net/socket.c:2353 ___sys_sendmsg+0xf3/0x170 net/socket.c:2407 __sys_sendmsg+0xe5/0x1b0 net/socket.c:2440 do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46 entry_SYSCALL_64_after_hwframe+0x44/0xa9 RIP: 0033:0x443699 Code: 18 89 d0 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 db 0d fc ff c3 66 2e 0f 1f 84 00 00 00 00 RSP: 002b:7ffc067db418 EFLAGS: 0246 ORIG_RAX: 002e RAX: ffda RBX: 0003 RCX: 00443699 RDX: RSI: 22c0 RDI: 0003 RBP: 7ffc067db420 R08: 01bb R09: 01bb R10: R11: 0246 R12: 7ffc067db430 R13: R14: R15:
Re: kvm: x86-32 fails to link with tdp_mmu
On Fri, Oct 23, 2020 at 07:17:54PM -0700, Sean Christopherson wrote: > On Fri, Oct 23, 2020 at 09:13:21PM -0500, Daniel Díaz wrote: > > Hello! > > > > We found the following problem building torvalds/master, which > > recently merged the for-linus tag from the KVM tree, when building > > with gcc 7.3.0 and glibc 2.27 for x86 32-bits under OpenEmbedded: > > > > | LD vmlinux.o > > | MODPOST vmlinux.symvers > > | MODINFO modules.builtin.modinfo > > | GEN modules.builtin > > | LD .tmp_vmlinux.kallsyms1 > > | arch/x86/kvm/mmu/tdp_mmu.o: In function `__handle_changed_spte': > > | tdp_mmu.c:(.text+0x78a): undefined reference to `__umoddi3' > > The problem is a % on a 64-bit value. Patches incoming, there's also a goof > in similar code that was tweaked last minute to avoid the %. Just the one patch actually, I misread some cleverness. Patch still inbound...
Re: [PATCH v2 4/6] phy: samsung: phy-exynos-pcie: rework driver to support Exynos5433 PCIe PHY
On 10/23/20, 3:59 AM, Marek Szyprowski wrote:
>
> From: Jaehoon Chung
>
> Exynos5440 SoC support has been dropped since commit 8c83315da1cf ("ARM:
> dts: exynos: Remove Exynos5440"). Rework this driver to support PCIe PHY
> variant found in the Exynos5433 SoCs.
>
> Signed-off-by: Jaehoon Chung
> [mszyprow: reworked the driver to support only Exynos5433 variant, rebased
> onto current kernel code, rewrote commit message]
> Signed-off-by: Marek Szyprowski
> Acked-by: Krzysztof Kozlowski
>
Reviewed-by: Jingoo Han
Best regards,
Jingoo Han
> ---
> drivers/phy/samsung/phy-exynos-pcie.c | 304 ++
> 1 file changed, 112 insertions(+), 192 deletions(-)
[.]
Re: [PATCH v2 1/6] dt-bindings: pci: drop samsung,exynos5440-pcie binding
On 10/23/20, 3:58 AM, Marek Szyprowski wrote:
>
> Exynos5440 SoC support has been dropped since commit 8c83315da1cf ("ARM:
> dts: exynos: Remove Exynos5440"). Drop the obsolete bindings for
> exynos5440-pcie.
>
> Signed-off-by: Marek Szyprowski
> Reviewed-by: Rob Herring
> Reviewed-by: Krzysztof Kozlowski
Reviewed-by: Jingoo Han
Best regards,
Jingoo Han
> ---
> .../bindings/pci/samsung,exynos5440-pcie.txt | 58 ---
> 1 file changed, 58 deletions(-)
> delete mode 100644
> Documentation/devicetree/bindings/pci/samsung,exynos5440-pcie.txt
[.]
[PATCH 1/2] perf test: Use generic event for expand_libpfm_events()
I found that the UNHALTED_CORE_CYCLES event is only available in the
Intel machines and it makes other vendors/archs fail on the test. As
libpfm4 can parse the generic events like cycles, let's use them.
Fixes: 40b74c30ffb9 ("perf test: Add expand cgroup event test")
Signed-off-by: Namhyung Kim
---
tools/perf/tests/expand-cgroup.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/perf/tests/expand-cgroup.c b/tools/perf/tests/expand-cgroup.c
index d5771e4d094f..4c59f3ae438f 100644
--- a/tools/perf/tests/expand-cgroup.c
+++ b/tools/perf/tests/expand-cgroup.c
@@ -145,7 +145,7 @@ static int expand_libpfm_events(void)
int ret;
struct evlist *evlist;
struct rblist metric_events;
- const char event_str[] = "UNHALTED_CORE_CYCLES";
+ const char event_str[] = "CYCLES";
struct option opt = {
.value = &evlist,
};
--
2.29.0.rc1.297.gfa9743e501-goog
[PATCH v2 2/2] perf stat: Support regex pattern in --for-each-cgroup
To make the command line even more compact with cgroups, support regex
pattern matching in cgroup names.
$ perf stat -a -e cpu-clock,cycles --for-each-cgroup ^foo sleep 1
3,000.73 msec cpu-clock foo #2.998 CPUs utilized
12,530,992,699 cyclesfoo #7.517 GHz
(100.00%)
1,000.61 msec cpu-clock foo/bar #1.000 CPUs
utilized
4,178,529,579 cyclesfoo/bar #2.506 GHz
(100.00%)
1,000.03 msec cpu-clock foo/baz #0.999 CPUs
utilized
4,176,104,315 cyclesfoo/baz #2.505 GHz
(100.00%)
1.000892614 seconds time elapsed
Signed-off-by: Namhyung Kim
---
tools/perf/Documentation/perf-stat.txt | 5 +-
tools/perf/util/cgroup.c | 192 +
2 files changed, 171 insertions(+), 26 deletions(-)
diff --git a/tools/perf/Documentation/perf-stat.txt
b/tools/perf/Documentation/perf-stat.txt
index 9f9f29025e49..2b44c08b3b23 100644
--- a/tools/perf/Documentation/perf-stat.txt
+++ b/tools/perf/Documentation/perf-stat.txt
@@ -168,8 +168,9 @@ command line can be used: 'perf stat -e cycles -G
cgroup_name -a -e cycles'.
--for-each-cgroup name::
Expand event list for each cgroup in "name" (allow multiple cgroups separated
-by comma). This has same effect that repeating -e option and -G option for
-each event x name. This option cannot be used with -G/--cgroup option.
+by comma). It also support regex patterns to match multiple groups. This has
same
+effect that repeating -e option and -G option for each event x name. This
option
+cannot be used with -G/--cgroup option.
-o file::
--output file::
diff --git a/tools/perf/util/cgroup.c b/tools/perf/util/cgroup.c
index b81324a13a2b..127c2411fb9f 100644
--- a/tools/perf/util/cgroup.c
+++ b/tools/perf/util/cgroup.c
@@ -13,9 +13,19 @@
#include
#include
#include
+#include
+#include
int nr_cgroups;
+/* used to match cgroup name with patterns */
+struct cgroup_name {
+ struct list_head list;
+ bool used;
+ char name[];
+};
+static LIST_HEAD(cgroup_list);
+
static int open_cgroup(const char *name)
{
char path[PATH_MAX + 1];
@@ -149,6 +159,137 @@ void evlist__set_default_cgroup(struct evlist *evlist,
struct cgroup *cgroup)
evsel__set_default_cgroup(evsel, cgroup);
}
+/* helper function for ftw() in match_cgroups and list_cgroups */
+static int add_cgroup_name(const char *fpath, const struct stat *sb
__maybe_unused,
+ int typeflag)
+{
+ struct cgroup_name *cn;
+
+ if (typeflag != FTW_D)
+ return 0;
+
+ cn = malloc(sizeof(*cn) + strlen(fpath) + 1);
+ if (cn == NULL)
+ return -1;
+
+ cn->used = false;
+ strcpy(cn->name, fpath);
+
+ list_add_tail(&cn->list, &cgroup_list);
+ return 0;
+}
+
+static void release_cgroup_list(void)
+{
+ struct cgroup_name *cn;
+
+ while (!list_empty(&cgroup_list)) {
+ cn = list_first_entry(&cgroup_list, struct cgroup_name, list);
+ list_del(&cn->list);
+ free(cn);
+ }
+}
+
+/* collect given cgroups only */
+static int list_cgroups(const char *str)
+{
+ const char *p, *e, *eos = str + strlen(str);
+ struct cgroup_name *cn;
+ char *s;
+
+ /* use given name as is - for testing purpose */
+ for (;;) {
+ p = strchr(str, ',');
+ e = p ? p : eos;
+
+ if (e - str) {
+ int ret;
+
+ s = strndup(str, e - str);
+ if (!s)
+ return -1;
+ /* pretend if it's added by ftw() */
+ ret = add_cgroup_name(s, NULL, FTW_D);
+ free(s);
+ if (ret)
+ return -1;
+ } else {
+ if (add_cgroup_name("", NULL, FTW_D) < 0)
+ return -1;
+ }
+
+ if (!p)
+ break;
+ str = p+1;
+ }
+
+ /* these groups will be used */
+ list_for_each_entry(cn, &cgroup_list, list)
+ cn->used = true;
+
+ return 0;
+}
+
+/* collect all cgroups first and then match with the pattern */
+static int match_cgroups(const char *str)
+{
+ char mnt[PATH_MAX];
+ const char *p, *e, *eos = str + strlen(str);
+ struct cgroup_name *cn;
+ regex_t reg;
+ int prefix_len;
+ char *s;
+
+ if (cgroupfs_find_mountpoint(mnt, sizeof(mnt), "perf_event"))
+ return -1;
+
+ /* cgroup_name will have a full path, skip the root directory */
+ prefix_len = strlen(mnt);
+
+ /* collect all cgroups in the cgroup_list */
+
Re: [PATCH v4 seccomp 5/5] seccomp/cache: Report cache data through /proc/pid/seccomp_cache
On Thu, Oct 22, 2020 at 06:40:08PM -0500, YiFei Zhu wrote:
> On Thu, Oct 22, 2020 at 5:32 PM Kees Cook wrote:
> > I've been going back and forth on this, and I think what I've settled
> > on is I'd like to avoid new CONFIG dependencies just for this feature.
> > Instead, how about we just fill in SECCOMP_NATIVE and SECCOMP_COMPAT
> > for all the HAVE_ARCH_SECCOMP_FILTER architectures, and then the
> > cache reporting can be cleanly tied to CONFIG_SECCOMP_FILTER? It
> > should be relatively simple to extract those details and make
> > SECCOMP_ARCH_{NATIVE,COMPAT}_NAME part of the per-arch enabling patches?
>
> Hmm. So I could enable the cache logic to every architecture (one
> patch per arch) that does not have the sparse syscall numbers, and
> then have the proc reporting after the arch patches? I could do that.
> I don't have test machines to run anything other than x86_64 or ia32,
> so they will need a closer look by people more familiar with those
> arches.
Cool, yes please. It looks like MIPS will need to be skipped for now. I
would have the debug cache reporting patch then depend on
!CONFIG_HAVE_SPARSE_SYSCALL_NR.
> > I'd still like to get more specific workload performance numbers too.
> > The microbenchmark is nice, but getting things like build times under
> > docker's default seccomp filter, etc would be lovely. I've almost gotten
> > there, but my benchmarks are still really noisy and CPU isolation
> > continues to frustrate me. :)
>
> Ok, let me know if I can help.
Do you have a test environment where you can compare the before/after
of repeated kernel build times (or some other sufficiently
complex/interesting) workload under these conditions:
bare metal
docker w/ seccomp policy disabled
docker w/ default seccomp policy
This is what I've been trying to construct, but it's really noisy, so
I've been trying to pin CPUs and NUMA memory nodes, but it's not really
helping yet. :P
--
Kees Cook
Re: [PATCH v5 2/2] Add user-mode only option to unprivileged_userfaultfd sysctl knob
Hello everyone, On Sat, Oct 10, 2020 at 11:24:56PM -0700, Lokesh Gidra wrote: > With this change, when the knob is set to 0, it allows unprivileged > users to call userfaultfd, like when it is set to 1, but with the > restriction that page faults from only user-mode can be handled. > In this mode, an unprivileged user (without SYS_CAP_PTRACE capability) > must pass UFFD_USER_MODE_ONLY to userfaultd or the API will fail with > EPERM. > > This enables administrators to reduce the likelihood that > an attacker with access to userfaultfd can delay faulting kernel > code to widen timing windows for other exploits. > > The default value of this knob is changed to 0. This is required for > correct functioning of pipe mutex. However, this will fail postcopy > live migration, which will be unnoticeable to the VM guests. To avoid > this, set 'vm.userfault = 1' in /sys/sysctl.conf. For more details, > refer to Andrea's reply [1]. > > [1] https://lore.kernel.org/lkml/20200904033438.gi9...@redhat.com/ > > Signed-off-by: Lokesh Gidra Nobody commented so it seems everyone is on board with this change to synchronize the kernel default with the post-boot Android default. The email in the link above was pretty long, so the below would be a summary that could be added to the commit header: == The main reason this change is desirable as in the short term is that the Android userland will behave as with the sysctl set to zero. So without this commit, any Linux binary using userfaultfd to manage its memory would behave differently if run within the Android userland. == Reviewed-by: Andrea Arcangeli BTW, this is still a minor nitpick, but a printk_once of the 1/2 could be added before the return -EPERM too, that's actually what I meant when I suggested to add a printk_once :), however the printk_once you added can turn out to be useful too for devs converting code to use bounce buffers, so it's fine too, just it could go under DEBUG_VM and to be ratelimited (similarly to the "FAULT_FLAG_ALLOW_RETRY missing %x\n" printk). Thanks, Andrea
Re: [PATCH v8 -tip 02/26] sched: Introduce sched_class::pick_task()
On 2020/10/24 5:47, Joel Fernandes wrote:
> On Fri, Oct 23, 2020 at 01:25:38PM +0800, Li, Aubrey wrote:
> @@ -2517,6 +2528,7 @@ const struct sched_class dl_sched_class
>
> #ifdef CONFIG_SMP
> .balance= balance_dl,
> + .pick_task = pick_task_dl,
> .select_task_rq = select_task_rq_dl,
> .migrate_task_rq= migrate_task_rq_dl,
> .set_cpus_allowed = set_cpus_allowed_dl,
> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> index dbd9368a959d..bd6aed63f5e3 100644
> --- a/kernel/sched/fair.c
> +++ b/kernel/sched/fair.c
> @@ -4450,7 +4450,7 @@ pick_next_entity(struct cfs_rq *cfs_rq, struct
> sched_entity *curr)
>* Avoid running the skip buddy, if running something else can
>* be done without getting too unfair.
>*/
> - if (cfs_rq->skip == se) {
> + if (cfs_rq->skip && cfs_rq->skip == se) {
> struct sched_entity *second;
>
> if (se == curr) {
> @@ -6976,6 +6976,35 @@ static void check_preempt_wakeup(struct rq *rq,
> struct task_struct *p, int wake_
> set_last_buddy(se);
> }
>
> +#ifdef CONFIG_SMP
> +static struct task_struct *pick_task_fair(struct rq *rq)
> +{
> + struct cfs_rq *cfs_rq = &rq->cfs;
> + struct sched_entity *se;
> +
> + if (!cfs_rq->nr_running)
> + return NULL;
> +
> + do {
> + struct sched_entity *curr = cfs_rq->curr;
> +
> + se = pick_next_entity(cfs_rq, NULL);
> +
> + if (curr) {
> + if (se && curr->on_rq)
> + update_curr(cfs_rq);
> +
> + if (!se || entity_before(curr, se))
> + se = curr;
> + }
> +
> + cfs_rq = group_cfs_rq(se);
> + } while (cfs_rq);
> ++
> + return task_of(se);
> +}
> +#endif
One of my machines hangs when I run uperf with only one message:
[ 719.034962] BUG: kernel NULL pointer dereference, address:
0050
Then I replicated the problem on my another machine(no serial console),
here is the stack by manual copy.
Call Trace:
pick_next_entity+0xb0/0x160
pick_task_fair+0x4b/0x90
__schedule+0x59b/0x12f0
schedule_idle+0x1e/0x40
do_idle+0x193/0x2d0
cpu_startup_entry+0x19/0x20
start_secondary+0x110/0x150
secondary_startup_64_no_verify+0xa6/0xab
>>>
>>> Interesting. Wondering if we screwed something up in the rebase.
>>>
>>> Questions:
>>> 1. Does the issue happen if you just apply only up until this patch,
>>> or the entire series?
>>
>> I applied the entire series and just find a related patch to report the
>> issue.
>
> Ok.
>
>>> 2. Do you see the issue in v7? Not much if at all has changed in this
>>> part of the code from v7 -> v8 but could be something in the newer
>>> kernel.
>>>
>>
>> IIRC, I can run uperf successfully on v7.
>> I'm on tip/master 2d3e8c9424c9 (origin/master) "Merge branch 'linus'."
>> Please let me know if this is a problem, or you have a repo I can pull
>> for testing.
>
> Here is a repo with v8 series on top of v5.9 release:
> https://git.kernel.org/pub/scm/linux/kernel/git/jfern/linux.git/log/?h=coresched-v5.9
I didn't see NULL pointer dereference BUG of this repo, will post performance
data later.
Thanks,
-Aubrey
Re: [PATCH] perf stat: Support regex pattern in --for-each-cgroup
Hi Andi, On Sat, Oct 24, 2020 at 2:04 AM Andi Kleen wrote: > > On Fri, Oct 23, 2020 at 04:42:34PM +0900, Namhyung Kim wrote: > > To make the command line even more compact with cgroups, support regex > > pattern matching in cgroup names. > > > > $ perf stat -a -e cpu-clock,cycles --for-each-cgroup '^.$' sleep 1 > > The example doesn't exactly show the benefit. So ^.$ would be only > for one character cgroups? Right, I know it's not a good example but just wanted to show the possibility of regex patterns. Let me come up with a better one. > > Missing documentation updates. Will add. Thanks Namhyung
Re: kvm: x86-32 fails to link with tdp_mmu
On Fri, Oct 23, 2020 at 09:13:21PM -0500, Daniel Díaz wrote: > Hello! > > We found the following problem building torvalds/master, which > recently merged the for-linus tag from the KVM tree, when building > with gcc 7.3.0 and glibc 2.27 for x86 32-bits under OpenEmbedded: > > | LD vmlinux.o > | MODPOST vmlinux.symvers > | MODINFO modules.builtin.modinfo > | GEN modules.builtin > | LD .tmp_vmlinux.kallsyms1 > | arch/x86/kvm/mmu/tdp_mmu.o: In function `__handle_changed_spte': > | tdp_mmu.c:(.text+0x78a): undefined reference to `__umoddi3' The problem is a % on a 64-bit value. Patches incoming, there's also a goof in similar code that was tweaked last minute to avoid the %.
kvm: x86-32 fails to link with tdp_mmu
Hello!
We found the following problem building torvalds/master, which
recently merged the for-linus tag from the KVM tree, when building
with gcc 7.3.0 and glibc 2.27 for x86 32-bits under OpenEmbedded:
| LD vmlinux.o
| MODPOST vmlinux.symvers
| MODINFO modules.builtin.modinfo
| GEN modules.builtin
| LD .tmp_vmlinux.kallsyms1
| arch/x86/kvm/mmu/tdp_mmu.o: In function `__handle_changed_spte':
| tdp_mmu.c:(.text+0x78a): undefined reference to `__umoddi3'
|
/srv/oe/build/tmp-lkft-glibc/work-shared/intel-core2-32/kernel-source/Makefile:1164:
recipe for target 'vmlinux' failed
| make[1]: *** [vmlinux] Error 1
|
/srv/oe/build/tmp-lkft-glibc/work-shared/intel-core2-32/kernel-source/Makefile:185:
recipe for target '__sub-make' failed
| make: *** [__sub-make] Error 2
This builds fine for x86 (64 bits) and arm (32/64 bits) with the same
toolchain. This also builds correctly (outside OpenEmbedded) with
gcc-8, gcc-9 and gcc-10 for: x86 (32/64 bits), arm (32/64 bits), MIPS,
and RISCV; and gcc-8 and gcc-9 for ARC.
We first noticed this when 0adc313c4f20 was pushed, but reverting
f9a705ad1c07 ("Merge tag 'for-linus' of
git://git.kernel.org/pub/scm/virt/kvm/kvm") brought it back into
building.
A follow-up bisection led to faaf05b00aec ("kvm: x86/mmu: Support
zapping SPTEs in the TDP MMU"). In that commit, the problematic code
was:
handle_changed_spte(kvm, as_id, iter->gfn, iter->old_spte, new_spte,
iter->level);
which was later changed by f8e144971c68 ("kvm: x86/mmu: Add access
tracking for tdp_mmu") to:
__handle_changed_spte(kvm, as_id, iter->gfn, iter->old_spte, new_spte,
iter->level);
Greetings!
Daniel Díaz
daniel.d...@linaro.org
Re: [PATCH] sunrpc: raise kernel RPC channel buffer size
On Sat, Oct 24, 2020 at 03:29:25AM +0200, Roberto Bergantinos Corpas wrote: > Good point Geert ! > > > How about making it a kvmalloc? > > I can post a new patch using kvmalloc, Bruce looks we can also > prescind of queue_io_mutex, what do you think ? And revert da77005f0d64, I think. Maybe there's something I'm missing, but I don't think we need all that complexity. --b.
Re: [PATCH v4] mm,thp,shmem: limit shmem THP alloc gfp_mask
On Fri, Oct 23, 2020 at 08:48:04PM -0400, Rik van Riel wrote:
> The allocation flags of anonymous transparent huge pages can be controlled
> through the files in /sys/kernel/mm/transparent_hugepage/defrag, which can
> help the system from getting bogged down in the page reclaim and compaction
> code when many THPs are getting allocated simultaneously.
>
> However, the gfp_mask for shmem THP allocations were not limited by those
> configuration settings, and some workloads ended up with all CPUs stuck
> on the LRU lock in the page reclaim code, trying to allocate dozens of
> THPs simultaneously.
>
> This patch applies the same configurated limitation of THPs to shmem
> hugepage allocations, to prevent that from happening.
>
> This way a THP defrag setting of "never" or "defer+madvise" will result
> in quick allocation failures without direct reclaim when no 2MB free
> pages are available.
>
> With this patch applied, THP allocations for tmpfs will be a little
> more aggressive than today for files mmapped with MADV_HUGEPAGE,
> and a little less aggressive for files that are not mmapped or
> mapped without that flag.
How about this code path though?
shmem_get_pages() [ in i915 ]
shmem_read_mapping_page_gfp(__GFP_NORETRY | __GFP_NOWARN)
shmem_getpage_gfp()
shmem_alloc_and_acct_page()
shmem_alloc_hugepage()
I feel like the NORETRY from i915 should override whatever is set
in sysfs for anon THPs. What do others think?
> Signed-off-by: Rik van Riel
> ---
> v4: rename alloc_hugepage_direct_gfpmask to vma_thp_gfp_mask (Matthew Wilcox)
> v3: fix NULL vma issue spotted by Hugh Dickins & tested
> v2: move gfp calculation to shmem_getpage_gfp as suggested by Yu Xu
>
> diff --git a/include/linux/gfp.h b/include/linux/gfp.h
> index c603237e006c..c7615c9ba03c 100644
> --- a/include/linux/gfp.h
> +++ b/include/linux/gfp.h
> @@ -614,6 +614,8 @@ bool gfp_pfmemalloc_allowed(gfp_t gfp_mask);
> extern void pm_restrict_gfp_mask(void);
> extern void pm_restore_gfp_mask(void);
>
> +extern gfp_t vma_thp_gfp_mask(struct vm_area_struct *vma);
> +
> #ifdef CONFIG_PM_SLEEP
> extern bool pm_suspended_storage(void);
> #else
> diff --git a/mm/huge_memory.c b/mm/huge_memory.c
> index 9474dbc150ed..c5d03b2f2f2f 100644
> --- a/mm/huge_memory.c
> +++ b/mm/huge_memory.c
> @@ -649,9 +649,9 @@ static vm_fault_t __do_huge_pmd_anonymous_page(struct
> vm_fault *vmf,
> * available
> * never: never stall for any thp allocation
> */
> -static inline gfp_t alloc_hugepage_direct_gfpmask(struct vm_area_struct *vma)
> +gfp_t vma_thp_gfp_mask(struct vm_area_struct *vma)
> {
> - const bool vma_madvised = !!(vma->vm_flags & VM_HUGEPAGE);
> + const bool vma_madvised = vma && (vma->vm_flags & VM_HUGEPAGE);
>
> /* Always do synchronous compaction */
> if (test_bit(TRANSPARENT_HUGEPAGE_DEFRAG_DIRECT_FLAG,
> &transparent_hugepage_flags))
> @@ -744,7 +744,7 @@ vm_fault_t do_huge_pmd_anonymous_page(struct vm_fault
> *vmf)
> pte_free(vma->vm_mm, pgtable);
> return ret;
> }
> - gfp = alloc_hugepage_direct_gfpmask(vma);
> + gfp = vma_thp_gfp_mask(vma);
> page = alloc_hugepage_vma(gfp, vma, haddr, HPAGE_PMD_ORDER);
> if (unlikely(!page)) {
> count_vm_event(THP_FAULT_FALLBACK);
> diff --git a/mm/shmem.c b/mm/shmem.c
> index 537c137698f8..6c3cb192a88d 100644
> --- a/mm/shmem.c
> +++ b/mm/shmem.c
> @@ -1545,8 +1545,8 @@ static struct page *shmem_alloc_hugepage(gfp_t gfp,
> return NULL;
>
> shmem_pseudo_vma_init(&pvma, info, hindex);
> - page = alloc_pages_vma(gfp | __GFP_COMP | __GFP_NORETRY | __GFP_NOWARN,
> - HPAGE_PMD_ORDER, &pvma, 0, numa_node_id(), true);
> + page = alloc_pages_vma(gfp, HPAGE_PMD_ORDER, &pvma, 0, numa_node_id(),
> +true);
> shmem_pseudo_vma_destroy(&pvma);
> if (page)
> prep_transhuge_page(page);
> @@ -1802,6 +1802,7 @@ static int shmem_getpage_gfp(struct inode *inode,
> pgoff_t index,
> struct page *page;
> enum sgp_type sgp_huge = sgp;
> pgoff_t hindex = index;
> + gfp_t huge_gfp;
> int error;
> int once = 0;
> int alloced = 0;
> @@ -1887,7 +1888,8 @@ static int shmem_getpage_gfp(struct inode *inode,
> pgoff_t index,
> }
>
> alloc_huge:
> - page = shmem_alloc_and_acct_page(gfp, inode, index, true);
> + huge_gfp = vma_thp_gfp_mask(vma);
> + page = shmem_alloc_and_acct_page(huge_gfp, inode, index, true);
> if (IS_ERR(page)) {
> alloc_nohuge:
> page = shmem_alloc_and_acct_page(gfp, inode,
Re: [PATCH v5 1/2] Add UFFD_USER_MODE_ONLY
On Sat, Oct 10, 2020 at 11:24:55PM -0700, Lokesh Gidra wrote: > userfaultfd handles page faults from both user and kernel code. > Add a new UFFD_USER_MODE_ONLY flag for userfaultfd(2) that makes > the resulting userfaultfd object refuse to handle faults from kernel > mode, treating these faults as if SIGBUS were always raised, causing > the kernel code to fail with EFAULT. > > A future patch adds a knob allowing administrators to give some > processes the ability to create userfaultfd file objects only if they > pass UFFD_USER_MODE_ONLY, reducing the likelihood that these processes > will exploit userfaultfd's ability to delay kernel page faults to open > timing windows for future exploits. > > Signed-off-by: Daniel Colascione > Signed-off-by: Lokesh Gidra Reviewed-by: Andrea Arcangeli
[PATCH v1 1/2] bus: mhi: core: Count number of HW channels supported by controller
Device provides the total number of HW channels it supports using MHI
configuration register. Host supported HW channels shall not exceed
that value. In order to make this check, a counter is needed to store
total number of HW channels required by host.
Signed-off-by: Hemant Kumar
---
drivers/bus/mhi/core/init.c | 2 ++
drivers/bus/mhi/core/internal.h | 1 +
include/linux/mhi.h | 1 +
3 files changed, 4 insertions(+)
diff --git a/drivers/bus/mhi/core/init.c b/drivers/bus/mhi/core/init.c
index 0ffdebd..70fd6af 100644
--- a/drivers/bus/mhi/core/init.c
+++ b/drivers/bus/mhi/core/init.c
@@ -725,6 +725,8 @@ static int parse_ch_cfg(struct mhi_controller *mhi_cntrl,
mhi_chan = &mhi_cntrl->mhi_chan[chan];
mhi_chan->name = ch_cfg->name;
mhi_chan->chan = chan;
+ if (chan >= MHI_HW_CHAN_START_IDX)
+ mhi_cntrl->hw_chan++;
mhi_chan->tre_ring.elements = ch_cfg->num_elements;
if (!mhi_chan->tre_ring.elements)
diff --git a/drivers/bus/mhi/core/internal.h b/drivers/bus/mhi/core/internal.h
index 7989269..3d8e480 100644
--- a/drivers/bus/mhi/core/internal.h
+++ b/drivers/bus/mhi/core/internal.h
@@ -454,6 +454,7 @@ enum mhi_pm_state {
#define PRIMARY_CMD_RING 0
#define MHI_DEV_WAKE_DB127
#define MHI_MAX_MTU0x
+#define MHI_HW_CHAN_START_IDX 100
#define MHI_RANDOM_U32_NONZERO(bmsk) (prandom_u32_max(bmsk) + 1)
enum mhi_er_type {
diff --git a/include/linux/mhi.h b/include/linux/mhi.h
index d4841e5..ea441d2 100644
--- a/include/linux/mhi.h
+++ b/include/linux/mhi.h
@@ -389,6 +389,7 @@ struct mhi_controller {
struct list_head lpm_chans;
int *irq;
u32 max_chan;
+ u32 hw_chan;
u32 total_ev_rings;
u32 hw_ev_rings;
u32 sw_ev_rings;
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
[PATCH v1 2/2] bus: mhi: core: Check for device supported event rings and channels
It is possible that the device does not support the number of event
rings and channels that the controller would like to use. Read the
MHICFG to determine device-side support and if the controller requests
more than the device supports, bailout without configuring device MMIO
registers.
Signed-off-by: Hemant Kumar
---
drivers/bus/mhi/core/init.c | 31 +++
drivers/bus/mhi/core/internal.h | 4
2 files changed, 35 insertions(+)
diff --git a/drivers/bus/mhi/core/init.c b/drivers/bus/mhi/core/init.c
index 70fd6af..35a6b1d 100644
--- a/drivers/bus/mhi/core/init.c
+++ b/drivers/bus/mhi/core/init.c
@@ -488,6 +488,37 @@ int mhi_init_mmio(struct mhi_controller *mhi_cntrl)
{ 0, 0, 0 }
};
+ /* range check b/w host and device supported ev rings and channels */
+ ret = mhi_read_reg(mhi_cntrl, base, MHICFG, &val);
+ if (ret) {
+ dev_err(dev, "Unable to read MHICFG register\n");
+ return -EIO;
+ }
+
+ if (MHICFG_NHWER(val) < mhi_cntrl->hw_ev_rings) {
+ dev_err(dev, "#HWEV ring: host requires %d dev supports %d\n",
+ mhi_cntrl->hw_ev_rings, MHICFG_NHWER(val));
+ return -EIO;
+ }
+
+ if (MHICFG_NER(val) < mhi_cntrl->total_ev_rings) {
+ dev_err(dev, "#EV ring: host requires %d dev supports %d\n",
+ mhi_cntrl->total_ev_rings, MHICFG_NER(val));
+ return -EIO;
+ }
+
+ if (MHICFG_NHWCH(val) < mhi_cntrl->hw_chan) {
+ dev_err(dev, "#HWCH: host requires %d dev supports %d\n",
+ mhi_cntrl->hw_chan, MHICFG_NHWCH(val));
+ return -EIO;
+ }
+
+ if (MHICFG_NCH(val) < mhi_cntrl->max_chan) {
+ dev_err(dev, "#CH: host requires %d dev supports %d\n",
+ mhi_cntrl->max_chan, MHICFG_NCH(val));
+ return -EIO;
+ }
+
dev_dbg(dev, "Initializing MHI registers\n");
/* Read channel db offset */
diff --git a/drivers/bus/mhi/core/internal.h b/drivers/bus/mhi/core/internal.h
index 3d8e480..9cbfa71 100644
--- a/drivers/bus/mhi/core/internal.h
+++ b/drivers/bus/mhi/core/internal.h
@@ -28,6 +28,10 @@ extern struct bus_type mhi_bus_type;
#define MHICFG_NHWCH_SHIFT (8)
#define MHICFG_NCH_MASK (0xFF)
#define MHICFG_NCH_SHIFT (0)
+#define MHICFG_NHWER(n) (((n) & MHICFG_NHWER_MASK) >> MHICFG_NHWER_SHIFT)
+#define MHICFG_NER(n) (((n) & MHICFG_NER_MASK) >> MHICFG_NER_SHIFT)
+#define MHICFG_NHWCH(n) (((n) & MHICFG_NHWCH_MASK) >> MHICFG_NHWCH_SHIFT)
+#define MHICFG_NCH(n) (((n) & MHICFG_NCH_MASK) >> MHICFG_NCH_SHIFT)
#define CHDBOFF (0x18)
#define CHDBOFF_CHDBOFF_MASK (0x)
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
[PATCH v1 0/2] Check for device supported event rings and channels
This change is introduced to make sure device supported hardware event ring, hardware channels, total number of event rings and total number of channels match with MHI host controller. In case of a mismatch, driver bails out and does not move MHI device to M0 from Ready state. Hemant Kumar (2): bus: mhi: core: Count number of HW channels supported by controller bus: mhi: core: Check for device supported event rings and channels drivers/bus/mhi/core/init.c | 33 + drivers/bus/mhi/core/internal.h | 5 + include/linux/mhi.h | 1 + 3 files changed, 39 insertions(+) -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project
Re: [PATCH] net: ucc_geth: Drop extraneous parentheses in comparison
Hello: This patch was applied to netdev/net.git (refs/heads/master): On Fri, 23 Oct 2020 14:32:36 +1100 you wrote: > Clang warns about the extra parentheses in this comparison: > > drivers/net/ethernet/freescale/ucc_geth.c:1361:28: > warning: equality comparison with extraneous parentheses > if ((ugeth->phy_interface == PHY_INTERFACE_MODE_SGMII)) > ~^~~ > > [...] Here is the summary with links: - net: ucc_geth: Drop extraneous parentheses in comparison https://git.kernel.org/netdev/net/c/dab234227cbd You are awesome, thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/patchwork/pwbot.html
Re: [PATCH] net: ucc_geth: Drop extraneous parentheses in comparison
On Fri, 23 Oct 2020 14:32:36 +1100 Michael Ellerman wrote: > Clang warns about the extra parentheses in this comparison: > > drivers/net/ethernet/freescale/ucc_geth.c:1361:28: > warning: equality comparison with extraneous parentheses > if ((ugeth->phy_interface == PHY_INTERFACE_MODE_SGMII)) > ~^~~ > > It seems clear the intent here is to do a comparison not an > assignment, so drop the extra parentheses to avoid any confusion. > > Signed-off-by: Michael Ellerman Applied, thanks!
Re: [PATCH v4] checkpatch: fix false positives in REPEATED_WORD warning
On Sat, 2020-10-24 at 05:38 +0530, Aditya Srivastava wrote:
> Presence of hexadecimal address or symbol results in false warning
> message by checkpatch.pl.
>
> For example, running checkpatch on commit b8ad540dd4e4 ("mptcp: fix
> memory leak in mptcp_subflow_create_socket()") results in warning:
>
> WARNING:REPEATED_WORD: Possible repeated word: 'ff'
> 00 00 00 00 00 00 00 00 00 2f 30 0a 81 88 ff ff ./0.
>
> Similarly, the presence of list command output in commit results in
> an unnecessary warning.
>
> For example, running checkpatch on commit 899e5ffbf246 ("perf record:
> Introduce --switch-output-event") gives:
>
> WARNING:REPEATED_WORD: Possible repeated word: 'root'
> dr-xr-x---. 12 root root4096 Apr 27 17:46 ..
>
> Here, it reports 'ff' and 'root to be repeated, but it is in fact part
'root'
> of some address or code, where it has to be repeated.
>
> In these cases, the intent of the warning to find stylistic issues in
> commit messages is not met and the warning is just completely wrong in
> this case.
>
> To avoid these warnings, add additional regex check for the
add an
> directory permission pattern and avoid checking the line for this
> class of warning. Similarly, to avoid hex pattern, check if the word
> consists of hex symbols and skip this warning if it is not among the
> common english words formed using hex letters.
>
> A quick evaluation on v5.6..v5.8 showed that this fix reduces
> REPEATED_WORD warnings from 2797 to 907.
How many of these 907 remaining are still false positive?
> A quick manual check found all cases are related to hex output or
> list command outputs in commit messages.
You mean 1890 of the 2797 are now no longer reported and all 1890
were false positives yes?
> diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
[]
> @@ -3049,7 +3049,9 @@ sub process {
> }
>
>
> # check for repeated words separated by a single space
> - if ($rawline =~ /^\+/ || $in_commit_log) {
> +# avoid false positive from list command eg, '-rw-r--r-- 1 root root'
> + if (($rawline =~ /^\+/ || $in_commit_log) &&
> +$rawline !~ /[bcCdDlMnpPs\?-][rwxsStT-]{9}/) {
Use maximal tab indentation and spaces to align please.
2 tabs, 4 spaces
> pos($rawline) = 1 if (!$in_commit_log);
> while ($rawline =~ /\b($word_pattern)
> (?=($word_pattern))/g) {
>
>
> @@ -3074,6 +3076,17 @@ sub process {
> next if ($start_char =~ /^\S$/);
> next if (index(" \t.,;?!", $end_char) == -1);
>
>
> +# avoid repeating hex occurrences like 'ff
> ff fe 09 ...'
> +my %allow_repeated_words = (
> +add => '',
> +added => '',
> +bad => '',
> +be => '',
> +);
If perl caches this local hash declaration, fine,
but I think it better to use 'our %allow_repeated_words'
and move it so it's only declared using the file scope.
> +if ($first =~ /\b[0-9a-f]{2,}\b/) {
This regex matches only lower case so it wouldn't match "Add".
I think this regex would be clearer using
/^[0-9a-f]+$/i or /^[A-Fa-f0-9]+$/
Re: [PATCH] selftests/ftrace: remove _do_fork() leftovers
On Fri, 23 Oct 2020 09:35:23 -0400
Steven Rostedt wrote:
> On Fri, 23 Oct 2020 10:52:03 +0200
> Alexander Gordeev wrote:
>
> > diff --git
> > a/tools/testing/selftests/ftrace/test.d/ftrace/func-filter-notrace-pid.tc
> > b/tools/testing/selftests/ftrace/test.d/ftrace/func-filter-notrace-pid.tc
> > index acb17ce..0ddb948 100644
> > ---
> > a/tools/testing/selftests/ftrace/test.d/ftrace/func-filter-notrace-pid.tc
> > +++
> > b/tools/testing/selftests/ftrace/test.d/ftrace/func-filter-notrace-pid.tc
> > @@ -39,7 +39,7 @@ do_test() {
> > disable_tracing
> >
> > echo do_execve* > set_ftrace_filter
> > -echo *do_fork >> set_ftrace_filter
> > +echo kernel_clone >> set_ftrace_filter
> >
> > echo $PID > set_ftrace_notrace_pid
> > echo function > current_tracer
> > diff --git
> > a/tools/testing/selftests/ftrace/test.d/ftrace/func-filter-pid.tc
> > b/tools/testing/selftests/ftrace/test.d/ftrace/func-filter-pid.tc
> > index 9f0a968..71319b3 100644
> > --- a/tools/testing/selftests/ftrace/test.d/ftrace/func-filter-pid.tc
> > +++ b/tools/testing/selftests/ftrace/test.d/ftrace/func-filter-pid.tc
> > @@ -39,7 +39,7 @@ do_test() {
> > disable_tracing
> >
> > echo do_execve* > set_ftrace_filter
> > -echo *do_fork >> set_ftrace_filter
> > +echo kernel_clone >> set_ftrace_filter
> >
> > echo $PID > set_ftrace_pid
> > echo function > current_tracer
>
> The issue I have with this, is that I run these tests on older kernels too,
> and tests that use to work on older kernels should still work. In fact,
> this fails on the kernel I'm currently adding new changes to!
>
> Perhaps we should have:
>
> # older kernels have do_fork, but newer kernels have kernel_clone
> echo kernel_clone >> set_ftrace_filter || echo *do_fork >>
> set_ftrace_filter
Good catch. BTW, can we check the filter-bility by grep the pattern from
set_ftrace_filter?
Thank you,
--
Masami Hiramatsu
Re: [PATCH net] net: ipa: command payloads already mapped
On Wed, 21 Oct 2020 20:00:29 -0500 Alex Elder wrote:
> IPA transactions describe actions to be performed by the IPA
> hardware. Three cases use IPA transactions: transmitting a socket
> buffer; providing a page to receive packet data; and issuing an IPA
> immediate command. An IPA transaction contains a scatter/gather
> list (SGL) to hold the set of actions to be performed.
>
> We map buffers in the SGL for DMA at the time they are added to the
> transaction. For skb TX transactions, we fill the SGL with a call
> to skb_to_sgvec(). Page RX transactions involve a single page
> pointer, and that is recorded in the SGL with sg_set_page(). In
> both of these cases we then map the SGL for DMA with a call to
> dma_map_sg().
>
> Immediate commands are different. The payload for an immediate
> command comes from a region of coherent DMA memory, which must
> *not* be mapped for DMA. For that reason, gsi_trans_cmd_add()
> sort of hand-crafts each SGL entry added to a command transaction.
>
> This patch fixes a problem with the code that crafts the SGL entry
> for an immediate command. Previously a portion of the SGL entry was
> updated using sg_set_buf(). However this is not valid because it
> includes a call to virt_to_page() on the buffer, but the command
> buffer pointer is not a linear address.
>
> Since we never actually map the SGL for command transactions, there
> are very few fields in the SGL we need to fill. Specifically, we
> only need to record the DMA address and the length, so they can be
> used by __gsi_trans_commit() to fill a TRE. We additionally need to
> preserve the SGL flags so for_each_sg() still works. For that we
> can simply assign a null page pointer for command SGL entries.
>
> Fixes: 9dd441e4ed575 ("soc: qcom: ipa: GSI transactions")
> Reported-by: Stephen Boyd
> Tested-by: Stephen Boyd
> Signed-off-by: Alex Elder
Applied, thanks!
Re: [PATCH] sunrpc: raise kernel RPC channel buffer size
Good point Geert ! > How about making it a kvmalloc? I can post a new patch using kvmalloc, Bruce looks we can also prescind of queue_io_mutex, what do you think ? > > --b. >
Re: [RFC PATCH v3 9/9] ipu3-cio2: Add functionality allowing software_node connections to sensors on platforms designed for Windows
Hi Daniel,
Thank you for the patch.
On Mon, Oct 19, 2020 at 11:59:03PM +0100, Daniel Scally wrote:
> Currently on platforms designed for Windows, connections between CIO2 and
> sensors are not properly defined in DSDT. This patch extends the ipu3-cio2
> driver to compensate by building software_node connections, parsing the
> connection properties from the sensor's SSDB buffer.
>
> Suggested-by: Jordan Hand
> Signed-off-by: Daniel Scally
> ---
> Changes in v3:
> - Rather than overwriting the device's primary fwnode, we now
> simply assign a secondary. Some of the preceding patches alter the
> existing driver code and v4l2 framework to allow for that.
> - Rather than reprobe() the sensor after connecting the devices in
> cio2-bridge we create the software_nodes right away. In this case,
> sensor drivers will have to defer probing until they detect that a
> fwnode graph is connecting them to the CIO2 device.
> - Error paths in connect_supported_devices() moved outside the
> loop
> - Replaced pr_*() with dev_*() throughout
> - Moved creation of software_node / property_entry arrays to stack
> - A lot of formatting changes.
>
> MAINTAINERS | 1 +
> drivers/media/pci/intel/ipu3/Kconfig | 18 +
> drivers/media/pci/intel/ipu3/Makefile | 3 +-
> drivers/media/pci/intel/ipu3/cio2-bridge.c| 327 ++
> drivers/media/pci/intel/ipu3/cio2-bridge.h| 94 +
> drivers/media/pci/intel/ipu3/ipu3-cio2-main.c | 21 ++
> drivers/media/pci/intel/ipu3/ipu3-cio2.h | 9 +
> 7 files changed, 472 insertions(+), 1 deletion(-)
> create mode 100644 drivers/media/pci/intel/ipu3/cio2-bridge.c
> create mode 100644 drivers/media/pci/intel/ipu3/cio2-bridge.h
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 5d768d5ad..4c9c646c7 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -8848,6 +8848,7 @@ INTEL IPU3 CSI-2 CIO2 DRIVER
> M: Yong Zhi
> M: Sakari Ailus
> M: Bingbu Cao
> +M: Dan Scally
> R: Tianshu Qiu
> L: linux-me...@vger.kernel.org
> S: Maintained
> diff --git a/drivers/media/pci/intel/ipu3/Kconfig
> b/drivers/media/pci/intel/ipu3/Kconfig
> index 82d7f17e6..d14cbceae 100644
> --- a/drivers/media/pci/intel/ipu3/Kconfig
> +++ b/drivers/media/pci/intel/ipu3/Kconfig
> @@ -16,3 +16,21 @@ config VIDEO_IPU3_CIO2
> Say Y or M here if you have a Skylake/Kaby Lake SoC with MIPI CSI-2
> connected camera.
> The module will be called ipu3-cio2.
> +
> +config CIO2_BRIDGE
> + bool "IPU3 CIO2 Sensors Bridge"
> + depends on VIDEO_IPU3_CIO2
> + help
> + This extension provides an API for the ipu3-cio2 driver to create
> + connections to cameras that are hidden in SSDB buffer in ACPI. It
> + can be used to enable support for cameras in detachable / hybrid
> + devices that ship with Windows.
> +
> + Say Y here if your device is a detachable / hybrid laptop that comes
> + with Windows installed by the OEM, for example:
> +
> + - Some Microsoft Surface models
> + - The Lenovo Miix line
> + - Dell 7285
> +
> + If in doubt, say N here.
> diff --git a/drivers/media/pci/intel/ipu3/Makefile
> b/drivers/media/pci/intel/ipu3/Makefile
> index b4e3266d9..933777e6e 100644
> --- a/drivers/media/pci/intel/ipu3/Makefile
> +++ b/drivers/media/pci/intel/ipu3/Makefile
> @@ -1,4 +1,5 @@
> # SPDX-License-Identifier: GPL-2.0-only
> obj-$(CONFIG_VIDEO_IPU3_CIO2) += ipu3-cio2.o
>
> -ipu3-cio2-y += ipu3-cio2-main.o
> \ No newline at end of file
> +ipu3-cio2-y += ipu3-cio2-main.o
> +ipu3-cio2-$(CONFIG_CIO2_BRIDGE) += cio2-bridge.o
> diff --git a/drivers/media/pci/intel/ipu3/cio2-bridge.c
> b/drivers/media/pci/intel/ipu3/cio2-bridge.c
> new file mode 100644
> index 0..bbe072f04
> --- /dev/null
> +++ b/drivers/media/pci/intel/ipu3/cio2-bridge.c
> @@ -0,0 +1,327 @@
> +// SPDX-License-Identifier: GPL-2.0
> +// Author: Dan Scally
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include "cio2-bridge.h"
> +
> +/*
> + * Extend this array with ACPI Hardware ID's of devices known to be
> + * working
> + */
> +static const char * const supported_devices[] = {
> + "INT33BE",
> + "OVTI2680",
> +};
> +
> +static struct software_node cio2_hid_node = { CIO2_HID };
> +
> +static struct cio2_bridge bridge;
While there shouldn't be more than one CIO2 instance, we try to develop
drivers in a way that avoids global per-device variables. Could all this
be allocated dynamically, with the pointer returned by
cio2_bridge_build() and stored in the cio2_device structure ?
> +
> +static const char * const port_names[] = {
> + "port0", "port1", "port2", "port3"
> +};
> +
> +static const struct property_entry remote_endpoints[] = {
> + PROPERTY_ENTRY_REF("remote-endpoint", /* Sensor 0, Sensor
drivers/vfio/fsl-mc/vfio_fsl_mc_intr.c:16:5: warning: no previous prototype for function 'vfio_fsl_mc_irqs_allocate'
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: b76f733c3ff83089cf1e3f9ae233533649f999b3
commit: cc0ee20bd96971c10eba9a83ecf1c0733078a083 vfio/fsl-mc: trigger an
interrupt via eventfd
date: 11 days ago
config: arm64-randconfig-r001-20201024 (attached as .config)
compiler: clang version 12.0.0 (https://github.com/llvm/llvm-project
77cbf2595331b11018c2cffb76eb5b8db69f4577)
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# install arm64 cross compiling tool for clang build
# apt-get install binutils-aarch64-linux-gnu
#
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=cc0ee20bd96971c10eba9a83ecf1c0733078a083
git remote add linus
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
git fetch --no-tags linus master
git checkout cc0ee20bd96971c10eba9a83ecf1c0733078a083
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=arm64
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All warnings (new ones prefixed by >>):
>> drivers/vfio/fsl-mc/vfio_fsl_mc_intr.c:16:5: warning: no previous prototype
>> for function 'vfio_fsl_mc_irqs_allocate' [-Wmissing-prototypes]
int vfio_fsl_mc_irqs_allocate(struct vfio_fsl_mc_device *vdev)
^
drivers/vfio/fsl-mc/vfio_fsl_mc_intr.c:16:1: note: declare 'static' if the
function is not intended to be used outside of this translation unit
int vfio_fsl_mc_irqs_allocate(struct vfio_fsl_mc_device *vdev)
^
static
drivers/vfio/fsl-mc/vfio_fsl_mc_intr.c:121:8: error: implicit declaration of
function 'fsl_mc_populate_irq_pool' [-Werror,-Wimplicit-function-declaration]
ret = fsl_mc_populate_irq_pool(mc_cont,
^
drivers/vfio/fsl-mc/vfio_fsl_mc_intr.c:122:4: error: use of undeclared
identifier 'FSL_MC_IRQ_POOL_MAX_TOTAL_IRQS'
FSL_MC_IRQ_POOL_MAX_TOTAL_IRQS);
^
1 warning and 2 errors generated.
vim +/vfio_fsl_mc_irqs_allocate +16 drivers/vfio/fsl-mc/vfio_fsl_mc_intr.c
15
> 16 int vfio_fsl_mc_irqs_allocate(struct vfio_fsl_mc_device *vdev)
17 {
18 struct fsl_mc_device *mc_dev = vdev->mc_dev;
19 struct vfio_fsl_mc_irq *mc_irq;
20 int irq_count;
21 int ret, i;
22
23 /* Device does not support any interrupt */
24 if (mc_dev->obj_desc.irq_count == 0)
25 return 0;
26
27 /* interrupts were already allocated for this device */
28 if (vdev->mc_irqs)
29 return 0;
30
31 irq_count = mc_dev->obj_desc.irq_count;
32
33 mc_irq = kcalloc(irq_count, sizeof(*mc_irq), GFP_KERNEL);
34 if (!mc_irq)
35 return -ENOMEM;
36
37 /* Allocate IRQs */
38 ret = fsl_mc_allocate_irqs(mc_dev);
39 if (ret) {
40 kfree(mc_irq);
41 return ret;
42 }
43
44 for (i = 0; i < irq_count; i++) {
45 mc_irq[i].count = 1;
46 mc_irq[i].flags = VFIO_IRQ_INFO_EVENTFD;
47 }
48
49 vdev->mc_irqs = mc_irq;
50
51 return 0;
52 }
53
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
.config.gz
Description: application/gzip
[PATCH] kernel/sys.c: fix prototype of prctl_get_tid_address()
tid_addr is not a "pointer to (pointer to int in userspace)"; it is in
fact a "pointer to (pointer to int in userspace) in userspace". So
sparse rightfully complains about passing a kernel pointer to
put_user().
Reported-by: kernel test robot
Signed-off-by: Rasmus Villemoes
---
kernel/sys.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/kernel/sys.c b/kernel/sys.c
index 6401880dff74a80a4594..85395f5cebc34d073cf4 100644
--- a/kernel/sys.c
+++ b/kernel/sys.c
@@ -2238,12 +2238,12 @@ static int prctl_set_mm(int opt, unsigned long addr,
}
#ifdef CONFIG_CHECKPOINT_RESTORE
-static int prctl_get_tid_address(struct task_struct *me, int __user **tid_addr)
+static int prctl_get_tid_address(struct task_struct *me, int __user * __user
*tid_addr)
{
return put_user(me->clear_child_tid, tid_addr);
}
#else
-static int prctl_get_tid_address(struct task_struct *me, int __user **tid_addr)
+static int prctl_get_tid_address(struct task_struct *me, int __user * __user
*tid_addr)
{
return -EINVAL;
}
@@ -2427,7 +2427,7 @@ SYSCALL_DEFINE5(prctl, int, option, unsigned long, arg2,
unsigned long, arg3,
error = prctl_set_mm(arg2, arg3, arg4, arg5);
break;
case PR_GET_TID_ADDRESS:
- error = prctl_get_tid_address(me, (int __user **)arg2);
+ error = prctl_get_tid_address(me, (int __user * __user *)arg2);
break;
case PR_SET_CHILD_SUBREAPER:
me->signal->is_child_subreaper = !!arg2;
--
2.23.0
[PATCH v4] mm,thp,shmem: limit shmem THP alloc gfp_mask
The allocation flags of anonymous transparent huge pages can be controlled
through the files in /sys/kernel/mm/transparent_hugepage/defrag, which can
help the system from getting bogged down in the page reclaim and compaction
code when many THPs are getting allocated simultaneously.
However, the gfp_mask for shmem THP allocations were not limited by those
configuration settings, and some workloads ended up with all CPUs stuck
on the LRU lock in the page reclaim code, trying to allocate dozens of
THPs simultaneously.
This patch applies the same configurated limitation of THPs to shmem
hugepage allocations, to prevent that from happening.
This way a THP defrag setting of "never" or "defer+madvise" will result
in quick allocation failures without direct reclaim when no 2MB free
pages are available.
With this patch applied, THP allocations for tmpfs will be a little
more aggressive than today for files mmapped with MADV_HUGEPAGE,
and a little less aggressive for files that are not mmapped or
mapped without that flag.
Signed-off-by: Rik van Riel
---
v4: rename alloc_hugepage_direct_gfpmask to vma_thp_gfp_mask (Matthew Wilcox)
v3: fix NULL vma issue spotted by Hugh Dickins & tested
v2: move gfp calculation to shmem_getpage_gfp as suggested by Yu Xu
diff --git a/include/linux/gfp.h b/include/linux/gfp.h
index c603237e006c..c7615c9ba03c 100644
--- a/include/linux/gfp.h
+++ b/include/linux/gfp.h
@@ -614,6 +614,8 @@ bool gfp_pfmemalloc_allowed(gfp_t gfp_mask);
extern void pm_restrict_gfp_mask(void);
extern void pm_restore_gfp_mask(void);
+extern gfp_t vma_thp_gfp_mask(struct vm_area_struct *vma);
+
#ifdef CONFIG_PM_SLEEP
extern bool pm_suspended_storage(void);
#else
diff --git a/mm/huge_memory.c b/mm/huge_memory.c
index 9474dbc150ed..c5d03b2f2f2f 100644
--- a/mm/huge_memory.c
+++ b/mm/huge_memory.c
@@ -649,9 +649,9 @@ static vm_fault_t __do_huge_pmd_anonymous_page(struct
vm_fault *vmf,
* available
* never: never stall for any thp allocation
*/
-static inline gfp_t alloc_hugepage_direct_gfpmask(struct vm_area_struct *vma)
+gfp_t vma_thp_gfp_mask(struct vm_area_struct *vma)
{
- const bool vma_madvised = !!(vma->vm_flags & VM_HUGEPAGE);
+ const bool vma_madvised = vma && (vma->vm_flags & VM_HUGEPAGE);
/* Always do synchronous compaction */
if (test_bit(TRANSPARENT_HUGEPAGE_DEFRAG_DIRECT_FLAG,
&transparent_hugepage_flags))
@@ -744,7 +744,7 @@ vm_fault_t do_huge_pmd_anonymous_page(struct vm_fault *vmf)
pte_free(vma->vm_mm, pgtable);
return ret;
}
- gfp = alloc_hugepage_direct_gfpmask(vma);
+ gfp = vma_thp_gfp_mask(vma);
page = alloc_hugepage_vma(gfp, vma, haddr, HPAGE_PMD_ORDER);
if (unlikely(!page)) {
count_vm_event(THP_FAULT_FALLBACK);
diff --git a/mm/shmem.c b/mm/shmem.c
index 537c137698f8..6c3cb192a88d 100644
--- a/mm/shmem.c
+++ b/mm/shmem.c
@@ -1545,8 +1545,8 @@ static struct page *shmem_alloc_hugepage(gfp_t gfp,
return NULL;
shmem_pseudo_vma_init(&pvma, info, hindex);
- page = alloc_pages_vma(gfp | __GFP_COMP | __GFP_NORETRY | __GFP_NOWARN,
- HPAGE_PMD_ORDER, &pvma, 0, numa_node_id(), true);
+ page = alloc_pages_vma(gfp, HPAGE_PMD_ORDER, &pvma, 0, numa_node_id(),
+ true);
shmem_pseudo_vma_destroy(&pvma);
if (page)
prep_transhuge_page(page);
@@ -1802,6 +1802,7 @@ static int shmem_getpage_gfp(struct inode *inode, pgoff_t
index,
struct page *page;
enum sgp_type sgp_huge = sgp;
pgoff_t hindex = index;
+ gfp_t huge_gfp;
int error;
int once = 0;
int alloced = 0;
@@ -1887,7 +1888,8 @@ static int shmem_getpage_gfp(struct inode *inode, pgoff_t
index,
}
alloc_huge:
- page = shmem_alloc_and_acct_page(gfp, inode, index, true);
+ huge_gfp = vma_thp_gfp_mask(vma);
+ page = shmem_alloc_and_acct_page(huge_gfp, inode, index, true);
if (IS_ERR(page)) {
alloc_nohuge:
page = shmem_alloc_and_acct_page(gfp, inode,
[PATCH] drm/ttm: add __user annotation in radeon_ttm_vram_read
Keep sparse happy by preserving the __user annotation when casting. Reported-by: kernel test robot Signed-off-by: Rasmus Villemoes --- kernel test robot has already started spamming me due to 9c5743dff. If I don't fix those warnings I'll keep getting those emails for months, so let me do the easy ones. drivers/gpu/drm/radeon/radeon_ttm.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c b/drivers/gpu/drm/radeon/radeon_ttm.c index 36150b7f31a90aa1eece..ecfe88b0a35d8f317712 100644 --- a/drivers/gpu/drm/radeon/radeon_ttm.c +++ b/drivers/gpu/drm/radeon/radeon_ttm.c @@ -1005,7 +1005,7 @@ static ssize_t radeon_ttm_vram_read(struct file *f, char __user *buf, value = RREG32(RADEON_MM_DATA); spin_unlock_irqrestore(&rdev->mmio_idx_lock, flags); - r = put_user(value, (uint32_t *)buf); + r = put_user(value, (uint32_t __user *)buf); if (r) return r; -- 2.23.0
Re: [RFC PATCH v3 7/9] ipu3-cio2: Check if pci_dev->dev's fwnode is a software_node in cio2_parse_firmware() and set FWNODE_GRAPH_DEVICE_DISABLED if so
Hi Sakari
On Wed, Oct 21, 2020 at 01:49:10AM +0300, Sakari Ailus wrote:
> On Tue, Oct 20, 2020 at 08:56:07PM +0100, Dan Scally wrote:
> > On 20/10/2020 13:06, Sakari Ailus wrote:
> > > On Tue, Oct 20, 2020 at 12:19:58PM +0300, Andy Shevchenko wrote:
> > >> On Mon, Oct 19, 2020 at 11:59:01PM +0100, Daniel Scally wrote:
> > >>> fwnode_graph_get_endpoint_by_id() will optionally parse enabled devices
> > >>> only; that status being determined through the .device_is_available() op
> > >>> of the device's fwnode. As software_nodes don't have that operation and
> > >>> adding it is meaningless, we instead need to check if the device's
> > >>> fwnode
> > >>> is a software_node and if so pass the appropriate flag to disable that
> > >>> check
> > >> Period.
> > >>
> > >> I'm wondering if actually this can be hidden in
> > >> fwnode_graph_get_endpoint_by_id().
> > > The device availability test is actually there for a reason. Some firmware
> > > implementations put all the potential devices in the tables and only one
> > > (of some) of them are available.
> > >
> > > Could this be implemented so that if the node is a software node, then get
> > > its parent and then see if that is available?
> > >
> > > I guess that could be implemented in software node ops. Any opinions?
> > Actually when considering the cio2 device, it seems that
> > set_secondary_fwnode() actually overwrites the _primary_, given
> > fwnode_is_primary(dev->fwnode) returns false. So in at least some cases,
> > this wouldn't work.
>
> Ouch. I wonder when this happens --- have you checked what's the primary
> there? I guess it might be if it's a PCI device without the corresponding
> ACPI device node?
>
> I remember you had an is_available implementation that just returned true
> for software nodes in an early version of the set? I think it would still
> be a lesser bad in this case.
How about the following ?
diff --git a/drivers/base/property.c b/drivers/base/property.c
index 81bd01ed4042..ea44ba846299 100644
--- a/drivers/base/property.c
+++ b/drivers/base/property.c
@@ -706,9 +706,14 @@ EXPORT_SYMBOL_GPL(fwnode_handle_put);
/**
* fwnode_device_is_available - check if a device is available for use
* @fwnode: Pointer to the fwnode of the device.
+ *
+ * For fwnode node types that don't implement the .device_is_available()
+ * operation, such as software nodes, this function returns true.
*/
bool fwnode_device_is_available(const struct fwnode_handle *fwnode)
{
+ if (!fwnode_has_op(fwnode, device_is_available))
+ return true;
return fwnode_call_bool_op(fwnode, device_is_available);
}
EXPORT_SYMBOL_GPL(fwnode_device_is_available);
--
Regards,
Laurent Pinchart
Re: [RFC PATCH v3 6/9] ipu3-cio2: Rename ipu3-cio2.c to allow module to be built from multiple sources files retaining ipu3-cio2 name
Hi Daniel,
Thank you for the patch.
On Mon, Oct 19, 2020 at 11:59:00PM +0100, Daniel Scally wrote:
> ipu3-cio2 driver needs extending with multiple files; rename the main
> source file and specify the renamed file in Makefile to accommodate that.
>
> Signed-off-by: Daniel Scally
> ---
> Changes in v3:
> - patch introduced
>
> drivers/media/pci/intel/ipu3/Makefile | 2 ++
> drivers/media/pci/intel/ipu3/{ipu3-cio2.c => ipu3-cio2-main.c} | 0
> 2 files changed, 2 insertions(+)
> rename drivers/media/pci/intel/ipu3/{ipu3-cio2.c => ipu3-cio2-main.c} (100%)
>
> diff --git a/drivers/media/pci/intel/ipu3/Makefile
> b/drivers/media/pci/intel/ipu3/Makefile
> index 98ddd5bea..b4e3266d9 100644
> --- a/drivers/media/pci/intel/ipu3/Makefile
> +++ b/drivers/media/pci/intel/ipu3/Makefile
> @@ -1,2 +1,4 @@
> # SPDX-License-Identifier: GPL-2.0-only
> obj-$(CONFIG_VIDEO_IPU3_CIO2) += ipu3-cio2.o
> +
> +ipu3-cio2-y += ipu3-cio2-main.o
> \ No newline at end of file
I would have sworn the usual naming for this kind of case was -drv.c,
but it seems -main.c is more common (I've probably been mistaken by
focussing quite a bit on drivers/gpu/drm/ in the past few years).
-core.c wins over both though :-) Anyway, enough bikeshedding, with the
newline fixed,
Reviewed-by: Laurent Pinchart
> diff --git a/drivers/media/pci/intel/ipu3/ipu3-cio2.c
> b/drivers/media/pci/intel/ipu3/ipu3-cio2-main.c
> similarity index 100%
> rename from drivers/media/pci/intel/ipu3/ipu3-cio2.c
> rename to drivers/media/pci/intel/ipu3/ipu3-cio2-main.c
--
Regards,
Laurent Pinchart
Re: [PATCH v3 13/20] perf arm-spe: Add new function arm_spe_pkt_desc_event()
On 22/10/2020 15:58, Leo Yan wrote:
Hi,
> This patch moves out the event packet parsing from arm_spe_pkt_desc()
> to the new function arm_spe_pkt_desc_event().
>
> Signed-off-by: Leo Yan
diff -w says this is correct, so:
Reviewed-by: Andre Przywara
Thanks!
Andre
> ---
> .../arm-spe-decoder/arm-spe-pkt-decoder.c | 136 ++
> 1 file changed, 73 insertions(+), 63 deletions(-)
>
> diff --git a/tools/perf/util/arm-spe-decoder/arm-spe-pkt-decoder.c
> b/tools/perf/util/arm-spe-decoder/arm-spe-pkt-decoder.c
> index 6eebd30f3d78..8a6b50f32a52 100644
> --- a/tools/perf/util/arm-spe-decoder/arm-spe-pkt-decoder.c
> +++ b/tools/perf/util/arm-spe-decoder/arm-spe-pkt-decoder.c
> @@ -266,6 +266,78 @@ static int arm_spe_pkt_snprintf(char **buf_p, size_t
> *blen,
> return ret;
> }
>
> +static int arm_spe_pkt_desc_event(const struct arm_spe_pkt *packet,
> + char *buf, size_t buf_len)
> +{
> + u64 payload = packet->payload;
> + size_t blen = buf_len;
> + int ret;
> +
> + ret = arm_spe_pkt_snprintf(&buf, &blen, "EV");
> + if (ret < 0)
> + return ret;
> +
> + if (payload & 0x1) {
> + ret = arm_spe_pkt_snprintf(&buf, &blen, " EXCEPTION-GEN");
> + if (ret < 0)
> + return ret;
> + }
> + if (payload & 0x2) {
> + ret = arm_spe_pkt_snprintf(&buf, &blen, " RETIRED");
> + if (ret < 0)
> + return ret;
> + }
> + if (payload & 0x4) {
> + ret = arm_spe_pkt_snprintf(&buf, &blen, " L1D-ACCESS");
> + if (ret < 0)
> + return ret;
> + }
> + if (payload & 0x8) {
> + ret = arm_spe_pkt_snprintf(&buf, &blen, " L1D-REFILL");
> + if (ret < 0)
> + return ret;
> + }
> + if (payload & 0x10) {
> + ret = arm_spe_pkt_snprintf(&buf, &blen, " TLB-ACCESS");
> + if (ret < 0)
> + return ret;
> + }
> + if (payload & 0x20) {
> + ret = arm_spe_pkt_snprintf(&buf, &blen, " TLB-REFILL");
> + if (ret < 0)
> + return ret;
> + }
> + if (payload & 0x40) {
> + ret = arm_spe_pkt_snprintf(&buf, &blen, " NOT-TAKEN");
> + if (ret < 0)
> + return ret;
> + }
> + if (payload & 0x80) {
> + ret = arm_spe_pkt_snprintf(&buf, &blen, " MISPRED");
> + if (ret < 0)
> + return ret;
> + }
> + if (packet->index > 1) {
> + if (payload & 0x100) {
> + ret = arm_spe_pkt_snprintf(&buf, &blen, " LLC-ACCESS");
> + if (ret < 0)
> + return ret;
> + }
> + if (payload & 0x200) {
> + ret = arm_spe_pkt_snprintf(&buf, &blen, " LLC-REFILL");
> + if (ret < 0)
> + return ret;
> + }
> + if (payload & 0x400) {
> + ret = arm_spe_pkt_snprintf(&buf, &blen, "
> REMOTE-ACCESS");
> + if (ret < 0)
> + return ret;
> + }
> + }
> +
> + return buf_len - blen;
> +}
> +
> static int arm_spe_pkt_desc_addr(const struct arm_spe_pkt *packet,
>char *buf, size_t buf_len)
> {
> @@ -344,69 +416,7 @@ int arm_spe_pkt_desc(const struct arm_spe_pkt *packet,
> char *buf,
> case ARM_SPE_END:
> return arm_spe_pkt_snprintf(&buf, &blen, "%s", name);
> case ARM_SPE_EVENTS:
> - ret = arm_spe_pkt_snprintf(&buf, &blen, "EV");
> - if (ret < 0)
> - return ret;
> -
> - if (payload & 0x1) {
> - ret = arm_spe_pkt_snprintf(&buf, &blen, "
> EXCEPTION-GEN");
> - if (ret < 0)
> - return ret;
> - }
> - if (payload & 0x2) {
> - ret = arm_spe_pkt_snprintf(&buf, &blen, " RETIRED");
> - if (ret < 0)
> - return ret;
> - }
> - if (payload & 0x4) {
> - ret = arm_spe_pkt_snprintf(&buf, &blen, " L1D-ACCESS");
> - if (ret < 0)
> - return ret;
> - }
> - if (payload & 0x8) {
> - ret = arm_spe_pkt_snprintf(&buf, &blen, " L1D-REFILL");
> - if (ret < 0)
> - return ret;
> - }
> - if (payload & 0x10) {
> - ret = arm_spe_pkt_snprintf(&buf, &blen, " TLB-ACCESS");
> - if (ret < 0)
> - return ret;
> - }
> - if (payload & 0x20) {
> - ret = arm_spe_pkt_snprintf(&buf, &blen, " TLB-REFILL");
> -
Re: [PATCH v3 19/20] perf arm_spe: Decode memory tagging properties
On 22/10/2020 15:58, Leo Yan wrote:
Hi,
> From: Andre Przywara
>
> When SPE records a physical address, it can additionally tag the event
> with information from the Memory Tagging architecture extension.
>
> Decode the two additional fields in the SPE event payload.
>
> [leoy: Refined patch to use predefined macros]
>
> Signed-off-by: Andre Przywara
> Signed-off-by: Leo Yan
> ---
> tools/perf/util/arm-spe-decoder/arm-spe-pkt-decoder.c | 6 +-
> tools/perf/util/arm-spe-decoder/arm-spe-pkt-decoder.h | 2 ++
> 2 files changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/tools/perf/util/arm-spe-decoder/arm-spe-pkt-decoder.c
> b/tools/perf/util/arm-spe-decoder/arm-spe-pkt-decoder.c
> index c1a3b0afd1de..74ac12cbec69 100644
> --- a/tools/perf/util/arm-spe-decoder/arm-spe-pkt-decoder.c
> +++ b/tools/perf/util/arm-spe-decoder/arm-spe-pkt-decoder.c
> @@ -432,6 +432,7 @@ static int arm_spe_pkt_desc_addr(const struct arm_spe_pkt
> *packet,
>char *buf, size_t buf_len)
> {
> int ns, el, idx = packet->index;
> + int ch, pat;
> u64 payload = packet->payload;
>
> switch (idx) {
> @@ -448,9 +449,12 @@ static int arm_spe_pkt_desc_addr(const struct
> arm_spe_pkt *packet,
> "VA 0x%llx", payload);
> case SPE_ADDR_PKT_HDR_INDEX_DATA_PHYS:
> ns = !!SPE_ADDR_PKT_GET_NS(payload);
> + ch = !!SPE_ADDR_PKT_GET_CH(payload);
> + pat = SPE_ADDR_PKT_GET_PAT(payload);
> payload = SPE_ADDR_PKT_ADDR_GET_BYTES_0_6(payload);
> return arm_spe_pkt_snprintf(&buf, &buf_len,
> - "PA 0x%llx ns=%d", payload, ns);
> + "PA 0x%llx ns=%d ch=%d, pat=%x",
> + payload, ns, ch, pat);
> default:
> return 0;
> }
> diff --git a/tools/perf/util/arm-spe-decoder/arm-spe-pkt-decoder.h
> b/tools/perf/util/arm-spe-decoder/arm-spe-pkt-decoder.h
> index 31dbb8c0fde3..d69af0d618ea 100644
> --- a/tools/perf/util/arm-spe-decoder/arm-spe-pkt-decoder.h
> +++ b/tools/perf/util/arm-spe-decoder/arm-spe-pkt-decoder.h
> @@ -75,6 +75,8 @@ struct arm_spe_pkt {
>
> #define SPE_ADDR_PKT_GET_NS(v) (((v) & BIT(63)) >> 63)
> #define SPE_ADDR_PKT_GET_EL(v) (((v) & GENMASK_ULL(62,
> 61)) >> 61)
> +#define SPE_ADDR_PKT_GET_CH(v) (((v) & BIT(62)) >> 62)
You need BIT_ULL() here to make this work on 32-bit systems.
Cheers,
Andre
> +#define SPE_ADDR_PKT_GET_PAT(v) (((v) & GENMASK_ULL(59,
> 56)) >> 56)
>
> #define SPE_ADDR_PKT_EL0 0
> #define SPE_ADDR_PKT_EL1 1
>
Re: [PATCH v3 18/20] perf arm-spe: Add more sub classes for operation packet
On 22/10/2020 15:58, Leo Yan wrote:
Hi,
> For the operation type packet payload with load/store class, it misses
> to support these sub classes:
>
> - A load/store targeting the general-purpose registers;
> - A load/store targeting unspecified registers;
> - The ARMv8.4 nested virtualisation extension can redirect system
> register accesses to a memory page controlled by the hypervisor.
> The SPE profiling feature in newer implementations can tag those
> memory accesses accordingly.
>
> Add the bit pattern describing load/store sub classes, so that the perf
> tool can decode it properly.
>
> Inspired by Andre Przywara, refined the commit log and code for more
> clear description.
>
> Co-developed-by: Andre Przywara
> Signed-off-by: Leo Yan
Reviewed-by: Andre Przywara
Cheers,
Andre
> ---
> .../arm-spe-decoder/arm-spe-pkt-decoder.c | 28 +--
> 1 file changed, 26 insertions(+), 2 deletions(-)
>
> diff --git a/tools/perf/util/arm-spe-decoder/arm-spe-pkt-decoder.c
> b/tools/perf/util/arm-spe-decoder/arm-spe-pkt-decoder.c
> index 59b538563d31..c1a3b0afd1de 100644
> --- a/tools/perf/util/arm-spe-decoder/arm-spe-pkt-decoder.c
> +++ b/tools/perf/util/arm-spe-decoder/arm-spe-pkt-decoder.c
> @@ -370,11 +370,35 @@ static int arm_spe_pkt_desc_op_type(const struct
> arm_spe_pkt *packet,
> if (ret < 0)
> return ret;
> }
> - } else if (SPE_OP_PKT_LDST_SUBCLASS_GET(payload) ==
> - SPE_OP_PKT_LDST_SUBCLASS_SIMD_FP) {
> + }
> +
> + switch (SPE_OP_PKT_LDST_SUBCLASS_GET(payload)) {
> + case SPE_OP_PKT_LDST_SUBCLASS_SIMD_FP:
> ret = arm_spe_pkt_snprintf(&buf, &blen, " SIMD-FP");
> if (ret < 0)
> return ret;
> +
> + break;
> + case SPE_OP_PKT_LDST_SUBCLASS_GP_REG:
> + ret = arm_spe_pkt_snprintf(&buf, &blen, " GP-REG");
> + if (ret < 0)
> + return ret;
> +
> + break;
> + case SPE_OP_PKT_LDST_SUBCLASS_UNSPEC_REG:
> + ret = arm_spe_pkt_snprintf(&buf, &blen, " UNSPEC-REG");
> + if (ret < 0)
> + return ret;
> +
> + break;
> + case SPE_OP_PKT_LDST_SUBCLASS_NV_SYSREG:
> + ret = arm_spe_pkt_snprintf(&buf, &blen, " NV-SYSREG");
> + if (ret < 0)
> + return ret;
> +
> + break;
> + default:
> + break;
> }
>
> return buf_len - blen;
>
Re: [PATCH v3 14/20] perf arm-spe: Refactor event type handling
On 22/10/2020 15:58, Leo Yan wrote:
Hi,
> Move the enums of event types to arm-spe-pkt-decoder.h, thus function
> arm_spe_pkt_desc() can them for bitmasks.
>
> Suggested-by: Andre Przywara
> Signed-off-by: Leo Yan
The move is fine, and I checked the bitmasks as well.
Reviewed-by: Andre Przywara
Cheers,
Andre
> ---
> .../util/arm-spe-decoder/arm-spe-decoder.h| 17 --
> .../arm-spe-decoder/arm-spe-pkt-decoder.c | 22 +--
> .../arm-spe-decoder/arm-spe-pkt-decoder.h | 18 +++
> 3 files changed, 29 insertions(+), 28 deletions(-)
>
> diff --git a/tools/perf/util/arm-spe-decoder/arm-spe-decoder.h
> b/tools/perf/util/arm-spe-decoder/arm-spe-decoder.h
> index a5111a8d4360..24727b8ca7ff 100644
> --- a/tools/perf/util/arm-spe-decoder/arm-spe-decoder.h
> +++ b/tools/perf/util/arm-spe-decoder/arm-spe-decoder.h
> @@ -13,23 +13,6 @@
>
> #include "arm-spe-pkt-decoder.h"
>
> -enum arm_spe_events {
> - EV_EXCEPTION_GEN= 0,
> - EV_RETIRED = 1,
> - EV_L1D_ACCESS = 2,
> - EV_L1D_REFILL = 3,
> - EV_TLB_ACCESS = 4,
> - EV_TLB_WALK = 5,
> - EV_NOT_TAKEN= 6,
> - EV_MISPRED = 7,
> - EV_LLC_ACCESS = 8,
> - EV_LLC_MISS = 9,
> - EV_REMOTE_ACCESS= 10,
> - EV_ALIGNMENT= 11,
> - EV_PARTIAL_PREDICATE= 17,
> - EV_EMPTY_PREDICATE = 18,
> -};
> -
> enum arm_spe_sample_type {
> ARM_SPE_L1D_ACCESS = 1 << 0,
> ARM_SPE_L1D_MISS= 1 << 1,
> diff --git a/tools/perf/util/arm-spe-decoder/arm-spe-pkt-decoder.c
> b/tools/perf/util/arm-spe-decoder/arm-spe-pkt-decoder.c
> index 8a6b50f32a52..58a1390b7a43 100644
> --- a/tools/perf/util/arm-spe-decoder/arm-spe-pkt-decoder.c
> +++ b/tools/perf/util/arm-spe-decoder/arm-spe-pkt-decoder.c
> @@ -277,58 +277,58 @@ static int arm_spe_pkt_desc_event(const struct
> arm_spe_pkt *packet,
> if (ret < 0)
> return ret;
>
> - if (payload & 0x1) {
> + if (payload & BIT(EV_EXCEPTION_GEN)) {
> ret = arm_spe_pkt_snprintf(&buf, &blen, " EXCEPTION-GEN");
> if (ret < 0)
> return ret;
> }
> - if (payload & 0x2) {
> + if (payload & BIT(EV_RETIRED)) {
> ret = arm_spe_pkt_snprintf(&buf, &blen, " RETIRED");
> if (ret < 0)
> return ret;
> }
> - if (payload & 0x4) {
> + if (payload & BIT(EV_L1D_ACCESS)) {
> ret = arm_spe_pkt_snprintf(&buf, &blen, " L1D-ACCESS");
> if (ret < 0)
> return ret;
> }
> - if (payload & 0x8) {
> + if (payload & BIT(EV_L1D_REFILL)) {
> ret = arm_spe_pkt_snprintf(&buf, &blen, " L1D-REFILL");
> if (ret < 0)
> return ret;
> }
> - if (payload & 0x10) {
> + if (payload & BIT(EV_TLB_ACCESS)) {
> ret = arm_spe_pkt_snprintf(&buf, &blen, " TLB-ACCESS");
> if (ret < 0)
> return ret;
> }
> - if (payload & 0x20) {
> + if (payload & BIT(EV_TLB_WALK)) {
> ret = arm_spe_pkt_snprintf(&buf, &blen, " TLB-REFILL");
> if (ret < 0)
> return ret;
> }
> - if (payload & 0x40) {
> + if (payload & BIT(EV_NOT_TAKEN)) {
> ret = arm_spe_pkt_snprintf(&buf, &blen, " NOT-TAKEN");
> if (ret < 0)
> return ret;
> }
> - if (payload & 0x80) {
> + if (payload & BIT(EV_MISPRED)) {
> ret = arm_spe_pkt_snprintf(&buf, &blen, " MISPRED");
> if (ret < 0)
> return ret;
> }
> if (packet->index > 1) {
> - if (payload & 0x100) {
> + if (payload & BIT(EV_LLC_ACCESS)) {
> ret = arm_spe_pkt_snprintf(&buf, &blen, " LLC-ACCESS");
> if (ret < 0)
> return ret;
> }
> - if (payload & 0x200) {
> + if (payload & BIT(EV_LLC_MISS)) {
> ret = arm_spe_pkt_snprintf(&buf, &blen, " LLC-REFILL");
> if (ret < 0)
> return ret;
> }
> - if (payload & 0x400) {
> + if (payload & BIT(EV_REMOTE_ACCESS)) {
> ret = arm_spe_pkt_snprintf(&buf, &blen, "
> REMOTE-ACCESS");
> if (ret < 0)
> return ret;
> diff --git a/tools/perf/util/arm-spe-decoder/arm-spe-pkt-decoder.h
> b/tools/perf/util/arm-spe-decoder/arm-spe-pkt-decoder.h
> index 8a291f451ef8..12c344454cf1 100644
> --- a/tools/perf/util/arm-spe-decoder/arm-spe-pkt-decoder.h
> +++ b/tools/perf/util/arm-spe-decoder/arm-spe-pkt-decoder.h
> @@ -92,6 +92,24 @@ struct arm_spe_pkt {
> #define SPE_CNT_PKT_HD
Re: [PATCH v3 12/20] perf arm-spe: Refactor counter packet handling
On 22/10/2020 15:58, Leo Yan wrote:
Hi,
> This patch defines macros for counter packet header, and uses macros to
> replace hard code values in functions arm_spe_get_counter() and
> arm_spe_pkt_desc().
>
> In the function arm_spe_get_counter(), adds a new line for more
> readable.
>
> Signed-off-by: Leo Yan
> ---
> tools/perf/util/arm-spe-decoder/arm-spe-pkt-decoder.c | 11 ++-
> tools/perf/util/arm-spe-decoder/arm-spe-pkt-decoder.h | 8
> 2 files changed, 14 insertions(+), 5 deletions(-)
>
> diff --git a/tools/perf/util/arm-spe-decoder/arm-spe-pkt-decoder.c
> b/tools/perf/util/arm-spe-decoder/arm-spe-pkt-decoder.c
> index 023bcc9be3cc..6eebd30f3d78 100644
> --- a/tools/perf/util/arm-spe-decoder/arm-spe-pkt-decoder.c
> +++ b/tools/perf/util/arm-spe-decoder/arm-spe-pkt-decoder.c
> @@ -152,10 +152,11 @@ static int arm_spe_get_counter(const unsigned char
> *buf, size_t len,
> const unsigned char ext_hdr, struct arm_spe_pkt
> *packet)
> {
> packet->type = ARM_SPE_COUNTER;
> +
> if (ext_hdr)
> - packet->index = ((buf[0] & 0x3) << 3) | (buf[1] & 0x7);
> + packet->index = SPE_CNT_PKT_HDR_EXTENDED_INDEX(buf[0], buf[1]);
> else
> - packet->index = buf[0] & 0x7;
> + packet->index = SPE_CNT_PKT_HDR_SHORT_INDEX(buf[0]);
>
> return arm_spe_get_payload(buf, len, ext_hdr, packet);
> }
> @@ -307,17 +308,17 @@ static int arm_spe_pkt_desc_counter(const struct
> arm_spe_pkt *packet,
> return ret;
>
> switch (packet->index) {
> - case 0:
> + case SPE_CNT_PKT_HDR_INDEX_TOTAL_LAT:
> ret = arm_spe_pkt_snprintf(&buf, &blen, "TOT");
> if (ret < 0)
> return ret;
> break;
> - case 1:
> + case SPE_CNT_PKT_HDR_INDEX_ISSUE_LAT:
> ret = arm_spe_pkt_snprintf(&buf, &blen, "ISSUE");
> if (ret < 0)
> return ret;
> break;
> - case 2:
> + case SPE_CNT_PKT_HDR_INDEX_TRANS_LAT:
> ret = arm_spe_pkt_snprintf(&buf, &blen, "XLAT");
> if (ret < 0)
> return ret;
> diff --git a/tools/perf/util/arm-spe-decoder/arm-spe-pkt-decoder.h
> b/tools/perf/util/arm-spe-decoder/arm-spe-pkt-decoder.h
> index 8808f2d0b6e4..8a291f451ef8 100644
> --- a/tools/perf/util/arm-spe-decoder/arm-spe-pkt-decoder.h
> +++ b/tools/perf/util/arm-spe-decoder/arm-spe-pkt-decoder.h
> @@ -84,6 +84,14 @@ struct arm_spe_pkt {
> /* Context packet header */
> #define SPE_CTX_PKT_HDR_INDEX(h) ((h) & GENMASK_ULL(1, 0))
>
> +/* Counter packet header */
> +#define SPE_CNT_PKT_HDR_SHORT_INDEX(h) ((h) & GENMASK_ULL(2,
> 0))
> +#define SPE_CNT_PKT_HDR_EXTENDED_INDEX(h0, h1) (((h0) & GENMASK_ULL(1,
> 0)) << 3 | \
> +
> SPE_ADDR_PKT_HDR_SHORT_INDEX(h1))
I would still like to see this merged with the SPE_ADDR_PKT_HDR_*_INDEX
definition in patch 10/20.
Otherwise this patch is fine.
Cheers,
Andre
> +#define SPE_CNT_PKT_HDR_INDEX_TOTAL_LAT 0x0
> +#define SPE_CNT_PKT_HDR_INDEX_ISSUE_LAT 0x1
> +#define SPE_CNT_PKT_HDR_INDEX_TRANS_LAT 0x2
> +
> const char *arm_spe_pkt_name(enum arm_spe_pkt_type);
>
> int arm_spe_get_packet(const unsigned char *buf, size_t len,
>
Re: [PATCH v2] ASoC: cs42l51: manage mclk shutdown delay
On Tue, 20 Oct 2020 17:01:09 +0200, Olivier Moysan wrote: > A delay must be introduced before the shutdown down of the mclk, > as stated in CS42L51 datasheet. Otherwise the codec may > produce some noise after the end of DAPM power down sequence. > The delay between DAC and CLOCK_SUPPLY widgets is too short. > Add a delay in mclk shutdown request to manage the shutdown delay > explicitly. From experiments, at least 10ms delay is necessary. > Set delay to 20ms as recommended in Documentation/timers/timers-howto.rst > when using msleep(). Applied to https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next Thanks! [1/1] ASoC: cs42l51: manage mclk shutdown delay commit: 20afe581c9b980848ad097c4d54dde9bec7593ef All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent to Linus during the next merge window (or sooner if it is a bug fix), however if problems are discovered then the patch may be dropped or reverted. You may get further e-mails resulting from automated or manual testing and review of the tree, please engage with people reporting problems and send followup patches addressing any issues that are reported if needed. If any updates are required or you are submitting further changes they should be sent as incremental updates against current git, existing patches will not be replaced. Please add any relevant lists and maintainers to the CCs when replying to this mail. Thanks, Mark
Re: [PATCH] ASoC: qcom: sdm845: set driver name correctly
On Fri, 23 Oct 2020 10:58:49 +0100, Srinivas Kandagatla wrote: > With the current state of code, we would endup with something like > below in /proc/asound/cards for 2 machines based on this driver. > > Machine 1: > 0 [DB845c]: DB845c - DB845c >DB845c > Machine 2: > 0 [LenovoYOGAC6301]: Lenovo-YOGA-C63 - Lenovo-YOGA-C630-13Q50 > LENOVO-81JL-LenovoYOGAC630_13Q50-LNVNB161216 > > [...] Applied to https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next Thanks! [1/1] ASoC: qcom: sdm845: set driver name correctly commit: 3f48b6eba15ea342ef4cb420b580f5ed6605669f All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent to Linus during the next merge window (or sooner if it is a bug fix), however if problems are discovered then the patch may be dropped or reverted. You may get further e-mails resulting from automated or manual testing and review of the tree, please engage with people reporting problems and send followup patches addressing any issues that are reported if needed. If any updates are required or you are submitting further changes they should be sent as incremental updates against current git, existing patches will not be replaced. Please add any relevant lists and maintainers to the CCs when replying to this mail. Thanks, Mark
Re: [PATCH] ASoC: codecs: wsa881x: add missing stream rates and format
On Thu, 22 Oct 2020 14:05:18 +0100, Srinivas Kandagatla wrote: > Add missing supported rates and formats for the stream, without > which attempt to do playback will fail to find any matching rates/format. Applied to https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next Thanks! [1/1] ASoC: codecs: wsa881x: add missing stream rates and format commit: f47d0742515748162d3fc35f04331c5b81c0ed47 All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent to Linus during the next merge window (or sooner if it is a bug fix), however if problems are discovered then the patch may be dropped or reverted. You may get further e-mails resulting from automated or manual testing and review of the tree, please engage with people reporting problems and send followup patches addressing any issues that are reported if needed. If any updates are required or you are submitting further changes they should be sent as incremental updates against current git, existing patches will not be replaced. Please add any relevant lists and maintainers to the CCs when replying to this mail. Thanks, Mark
Re: [RFC PATCH v3 5/9] ipu3-cio2: Add T: entry to MAINTAINERS
Hi Daniel, Thank you for the patch. On Mon, Oct 19, 2020 at 11:58:59PM +0100, Daniel Scally wrote: > Development for the ipu3-cio2 driver is taking place in media_tree, but > there's no T: entry in MAINTAINERS to denote that - rectify that oversight > > Signed-off-by: Daniel Scally Reviewed-by: Laurent Pinchart > --- > Changes in v3: > - patch introduced. > > MAINTAINERS | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/MAINTAINERS b/MAINTAINERS > index 43a025039..5d768d5ad 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -8851,6 +8851,7 @@ M: Bingbu Cao > R: Tianshu Qiu > L: linux-me...@vger.kernel.org > S: Maintained > +T: git git://linuxtv.org/media_tree.git > F: Documentation/userspace-api/media/v4l/pixfmt-srggb10-ipu3.rst > F: drivers/media/pci/intel/ipu3/ -- Regards, Laurent Pinchart
Re: [PATCH] MAINTAINERS: Add entry for Qualcomm IPQ4019 VQMMC regulator
On Fri, 16 Oct 2020 22:44:04 +0200, Robert Marko wrote: > Add maintainers entry for the Qualcomm IPQ4019 VQMMC regulator driver. Applied to https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git for-next Thanks! [1/1] MAINTAINERS: Add entry for Qualcomm IPQ4019 VQMMC regulator commit: 43c3e148830aae5469c411a2bf951d4fe7fcea29 All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent to Linus during the next merge window (or sooner if it is a bug fix), however if problems are discovered then the patch may be dropped or reverted. You may get further e-mails resulting from automated or manual testing and review of the tree, please engage with people reporting problems and send followup patches addressing any issues that are reported if needed. If any updates are required or you are submitting further changes they should be sent as incremental updates against current git, existing patches will not be replaced. Please add any relevant lists and maintainers to the CCs when replying to this mail. Thanks, Mark
Re: [PATCH v4] checkpatch: fix false positives in REPEATED_WORD warning
On 24/10/20 5:38 am, Aditya Srivastava wrote:
> Presence of hexadecimal address or symbol results in false warning
> message by checkpatch.pl.
>
> For example, running checkpatch on commit b8ad540dd4e4 ("mptcp: fix
> memory leak in mptcp_subflow_create_socket()") results in warning:
>
> WARNING:REPEATED_WORD: Possible repeated word: 'ff'
> 00 00 00 00 00 00 00 00 00 2f 30 0a 81 88 ff ff ./0.
>
> Similarly, the presence of list command output in commit results in
> an unnecessary warning.
>
> For example, running checkpatch on commit 899e5ffbf246 ("perf record:
> Introduce --switch-output-event") gives:
>
> WARNING:REPEATED_WORD: Possible repeated word: 'root'
> dr-xr-x---. 12 root root4096 Apr 27 17:46 ..
>
> Here, it reports 'ff' and 'root to be repeated, but it is in fact part
> of some address or code, where it has to be repeated.
>
> In these cases, the intent of the warning to find stylistic issues in
> commit messages is not met and the warning is just completely wrong in
> this case.
>
> To avoid these warnings, add additional regex check for the
> directory permission pattern and avoid checking the line for this
> class of warning. Similarly, to avoid hex pattern, check if the word
> consists of hex symbols and skip this warning if it is not among the
> common english words formed using hex letters.
>
> A quick evaluation on v5.6..v5.8 showed that this fix reduces
> REPEATED_WORD warnings from 2797 to 907.
>
> A quick manual check found all cases are related to hex output or
> list command outputs in commit messages.
>
> Signed-off-by: Aditya Srivastava
> ---
> scripts/checkpatch.pl | 15 ++-
> 1 file changed, 14 insertions(+), 1 deletion(-)
>
> diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
> index 7e505688257a..1d42d08d520b 100755
> --- a/scripts/checkpatch.pl
> +++ b/scripts/checkpatch.pl
> @@ -3049,7 +3049,9 @@ sub process {
> }
>
> # check for repeated words separated by a single space
> - if ($rawline =~ /^\+/ || $in_commit_log) {
> +# avoid false positive from list command eg, '-rw-r--r-- 1 root root'
> + if (($rawline =~ /^\+/ || $in_commit_log) &&
> +$rawline !~ /[bcCdDlMnpPs\?-][rwxsStT-]{9}/) {
> pos($rawline) = 1 if (!$in_commit_log);
> while ($rawline =~ /\b($word_pattern)
> (?=($word_pattern))/g) {
>
> @@ -3074,6 +3076,17 @@ sub process {
> next if ($start_char =~ /^\S$/);
> next if (index(" \t.,;?!", $end_char) == -1);
>
> +# avoid repeating hex occurrences like 'ff
> ff fe 09 ...'
> +my %allow_repeated_words = (
> +add => '',
> +added => '',
> +bad => '',
> +be => '',
> +);
> +if ($first =~ /\b[0-9a-f]{2,}\b/) {
> +next if
> (!exists($allow_repeated_words{lc($first)}));
> +}
> +
> if (WARN("REPEATED_WORD",
>"Possible repeated word: '$first'\n" .
> $herecurr) &&
> $fix) {
>
Changes made in v4:
- Fix indentation
- Reduce the dictionary size for allowed words
- Apply changes over Dwaipayan's patch
(https://lore.kernel.org/linux-kernel-mentees/20201017162732.152351-1-dwaipayanr...@gmail.com/)
Re: [GIT PULL] ring-buffer: Updates for 5.10
The pull request you sent on Fri, 23 Oct 2020 12:07:50 -0400: > git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace.git > trace-v5.10-3 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/a5e5c274c920f693d9c1ab65440d8e53a4530aca Thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/prtracker.html
Re: [GIT PULL] Documentation fixes for 5.10
The pull request you sent on Fri, 23 Oct 2020 13:17:19 -0600: > git://git.lwn.net/linux.git tags/docs-5.10-2 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/c80e42a4963b3f593d53fb8f565e5bbca61a6531 Thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/prtracker.html
Re: [GIT PULL] xfs: fixes for 5.10-rc1
The pull request you sent on Fri, 23 Oct 2020 14:55:46 -0700: > git://git.kernel.org/pub/scm/fs/xfs/xfs-linux.git tags/xfs-5.10-merge-7 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/f11901ed723d1351843771c3a84b03a253bbf8b2 Thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/prtracker.html
[PATCH 1/2] mm: reorganize internal_get_user_pages_fast()
The next patch in this series makes the lockless flow a little more
complex, so move the entire block into a new function and remove a level
of indention. Tidy a bit of cruft:
- addr is always the same as start, so use start
- Use the modern check_add_overflow() for computing end = start + len
- nr_pinned << PAGE_SHIFT needs an unsigned long cast, like nr_pages
- The handling of ret and nr_pinned can be streamlined a bit
No functional change.
Signed-off-by: Jason Gunthorpe
---
mm/gup.c | 88 +---
1 file changed, 46 insertions(+), 42 deletions(-)
diff --git a/mm/gup.c b/mm/gup.c
index 102877ed77a4b4..ecbe1639ea2af7 100644
--- a/mm/gup.c
+++ b/mm/gup.c
@@ -2671,13 +2671,42 @@ static int __gup_longterm_unlocked(unsigned long start,
int nr_pages,
return ret;
}
+static unsigned int lockless_pages_from_mm(unsigned long addr,
+ unsigned long end,
+ unsigned int gup_flags,
+ struct page **pages)
+{
+ unsigned long flags;
+ int nr_pinned = 0;
+
+ if (!IS_ENABLED(CONFIG_HAVE_FAST_GUP) ||
+ !gup_fast_permitted(addr, end))
+ return 0;
+
+ /*
+* Disable interrupts. The nested form is used, in order to allow full,
+* general purpose use of this routine.
+*
+* With interrupts disabled, we block page table pages from being freed
+* from under us. See struct mmu_table_batch comments in
+* include/asm-generic/tlb.h for more details.
+*
+* We do not adopt an rcu_read_lock(.) here as we also want to block
+* IPIs that come from THPs splitting.
+*/
+ local_irq_save(flags);
+ gup_pgd_range(addr, end, gup_flags, pages, &nr_pinned);
+ local_irq_restore(flags);
+ return nr_pinned;
+}
+
static int internal_get_user_pages_fast(unsigned long start, int nr_pages,
unsigned int gup_flags,
struct page **pages)
{
- unsigned long addr, len, end;
- unsigned long flags;
- int nr_pinned = 0, ret = 0;
+ unsigned long len, end;
+ unsigned int nr_pinned;
+ int ret;
if (WARN_ON_ONCE(gup_flags & ~(FOLL_WRITE | FOLL_LONGTERM |
FOLL_FORCE | FOLL_PIN | FOLL_GET |
@@ -2691,53 +2720,28 @@ static int internal_get_user_pages_fast(unsigned long
start, int nr_pages,
might_lock_read(¤t->mm->mmap_lock);
start = untagged_addr(start) & PAGE_MASK;
- addr = start;
len = (unsigned long) nr_pages << PAGE_SHIFT;
- end = start + len;
-
- if (end <= start)
+ if (check_add_overflow(start, len, &end))
return 0;
if (unlikely(!access_ok((void __user *)start, len)))
return -EFAULT;
- /*
-* Disable interrupts. The nested form is used, in order to allow
-* full, general purpose use of this routine.
-*
-* With interrupts disabled, we block page table pages from being
-* freed from under us. See struct mmu_table_batch comments in
-* include/asm-generic/tlb.h for more details.
-*
-* We do not adopt an rcu_read_lock(.) here as we also want to
-* block IPIs that come from THPs splitting.
-*/
- if (IS_ENABLED(CONFIG_HAVE_FAST_GUP) && gup_fast_permitted(start, end))
{
- unsigned long fast_flags = gup_flags;
-
- local_irq_save(flags);
- gup_pgd_range(addr, end, fast_flags, pages, &nr_pinned);
- local_irq_restore(flags);
- ret = nr_pinned;
- }
-
- if (nr_pinned < nr_pages && !(gup_flags & FOLL_FAST_ONLY)) {
- /* Try to get the remaining pages with get_user_pages */
- start += nr_pinned << PAGE_SHIFT;
- pages += nr_pinned;
-
- ret = __gup_longterm_unlocked(start, nr_pages - nr_pinned,
- gup_flags, pages);
+ nr_pinned = lockless_pages_from_mm(start, end, gup_flags, pages);
+ if (nr_pinned == nr_pages || gup_flags & FOLL_FAST_ONLY)
+ return nr_pinned;
+ /* Try to get the remaining pages with get_user_pages */
+ start += (unsigned long)nr_pinned << PAGE_SHIFT;
+ pages += nr_pinned;
+ ret = __gup_longterm_unlocked(start, nr_pages - nr_pinned, gup_flags,
+ pages);
+ if (ret < 0) {
/* Have to be a bit careful with return values */
- if (nr_pinned > 0) {
- if (ret < 0)
- ret = nr_pinned;
- else
- ret += nr_pinned;
- }
+ if (nr_pinned)
+ return
Re: [RFC] Have insn decoder functions return success/failure
On Fri, Oct 23, 2020 at 4:27 PM Borislav Petkov wrote: > > On Fri, Oct 23, 2020 at 07:47:04PM +0900, Masami Hiramatsu wrote: > > Thanks! I look forward to it. > > Ok, here's a first stab, it is a single big diff and totally untested > but it should show what I mean. I've made some notes while converting, > as I went along. > > Have a look at insn_decode() and its call sites: they are almost trivial > now because caller needs simply to do: > > if (insn_decode(insn, buffer, ...)) > > and not care about any helper functions. > > For some of the call sites it still makes sense to do a piecemeal insn > decoding and I've left them this way but they can be converted too, if > one wants. > > In any case, just have a look please and lemme know if that looks OKish. > I'll do the actual splitting and testing afterwards. > > And what Andy wants can't be done with the decoder because it already > gets a fixed size buffer and length - it doesn't do the fetching. The > caller does. > > What you wanna do: > > > len = min(15, remaining bytes in page); > > fetch len bytes; > > insn_init(); > > ret = insn_decode_fully(); > > <--- you can't always know here whether the insn is valid if you don't > have all the bytes. But you can always fetch *all* bytes and then give > it to the decoder for checking. > > Also, this doesn't make any sense: try insn decode on a subset of bytes > and then if it fails, try it on the whole set of bytes. Why even try the > subset - it will almost always fail. I disagree. A real CPU does exactly what I'm describing. If I stick 0xcc at the end of a page and a make the next page not-present, I get #BP, not #PF. But if I stick 0x0F at the end of a page and mark the next page not-present, I get #PF. If we're trying to decode an instruction in user memory, we can kludge it by trying to fetch 15 bytes and handling -EFAULT by fetching fewer bytes, but that's gross and doesn't really have the right semantics. What we actually want is to fetch up to the page boundary and try to decode it. If it's a valid instruction or if it's definitely invalid, we're done. Otherwise we fetch across the page boundary. Eventually we should wrap this whole mess up in an insn_decode_user() helper that does the right thing. And we can then make that helper extra fancy by getting PKRU and EPT-hacker-execute-only right, whereas we currently get these cases wrong. Does this make sense?
[PATCH v4] checkpatch: fix false positives in REPEATED_WORD warning
Presence of hexadecimal address or symbol results in false warning
message by checkpatch.pl.
For example, running checkpatch on commit b8ad540dd4e4 ("mptcp: fix
memory leak in mptcp_subflow_create_socket()") results in warning:
WARNING:REPEATED_WORD: Possible repeated word: 'ff'
00 00 00 00 00 00 00 00 00 2f 30 0a 81 88 ff ff ./0.
Similarly, the presence of list command output in commit results in
an unnecessary warning.
For example, running checkpatch on commit 899e5ffbf246 ("perf record:
Introduce --switch-output-event") gives:
WARNING:REPEATED_WORD: Possible repeated word: 'root'
dr-xr-x---. 12 root root4096 Apr 27 17:46 ..
Here, it reports 'ff' and 'root to be repeated, but it is in fact part
of some address or code, where it has to be repeated.
In these cases, the intent of the warning to find stylistic issues in
commit messages is not met and the warning is just completely wrong in
this case.
To avoid these warnings, add additional regex check for the
directory permission pattern and avoid checking the line for this
class of warning. Similarly, to avoid hex pattern, check if the word
consists of hex symbols and skip this warning if it is not among the
common english words formed using hex letters.
A quick evaluation on v5.6..v5.8 showed that this fix reduces
REPEATED_WORD warnings from 2797 to 907.
A quick manual check found all cases are related to hex output or
list command outputs in commit messages.
Signed-off-by: Aditya Srivastava
---
scripts/checkpatch.pl | 15 ++-
1 file changed, 14 insertions(+), 1 deletion(-)
diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
index 7e505688257a..1d42d08d520b 100755
--- a/scripts/checkpatch.pl
+++ b/scripts/checkpatch.pl
@@ -3049,7 +3049,9 @@ sub process {
}
# check for repeated words separated by a single space
- if ($rawline =~ /^\+/ || $in_commit_log) {
+# avoid false positive from list command eg, '-rw-r--r-- 1 root root'
+ if (($rawline =~ /^\+/ || $in_commit_log) &&
+$rawline !~ /[bcCdDlMnpPs\?-][rwxsStT-]{9}/) {
pos($rawline) = 1 if (!$in_commit_log);
while ($rawline =~ /\b($word_pattern)
(?=($word_pattern))/g) {
@@ -3074,6 +3076,17 @@ sub process {
next if ($start_char =~ /^\S$/);
next if (index(" \t.,;?!", $end_char) == -1);
+# avoid repeating hex occurrences like 'ff ff
fe 09 ...'
+my %allow_repeated_words = (
+add => '',
+added => '',
+bad => '',
+be => '',
+);
+if ($first =~ /\b[0-9a-f]{2,}\b/) {
+next if
(!exists($allow_repeated_words{lc($first)}));
+}
+
if (WARN("REPEATED_WORD",
"Possible repeated word: '$first'\n" .
$herecurr) &&
$fix) {
--
2.17.1
Re: [PATCH] checkpatch: Allow not using -f with files that are in git
On Sun, Oct 18, 2020 at 11:26:59AM -0700, Joe Perches wrote: > I'll post it again as a reply to this email with a > with a sign-off and a better commit description and > Linus/Andrew can decide if it's better to revert > f5f613259f3f or apply it separately. Gentle reminder on this, it is the last weekday of the merge window and checkpatch is still failing on Linus's latest (b76f733c).. Global symbol "$gitroot" requires explicit package name (did you forget to declare "my $gitroot"?) at scripts/checkpatch.pl line 980. Thanks, Jason
Re: [PATCH] sunrpc: raise kernel RPC channel buffer size
On Fri, Oct 23, 2020 at 11:44:38AM +0200, Geert Uytterhoeven wrote:
> Hi Bruce, Roberto,
>
> On Mon, 19 Oct 2020, J. Bruce Fields wrote:
> >On Mon, Oct 19, 2020 at 11:33:56AM +0200, Roberto Bergantinos Corpas wrote:
> >>Its possible that using AUTH_SYS and mountd manage-gids option a
> >>user may hit the 8k RPC channel buffer limit. This have been observed
> >>on field, causing unanswered RPCs on clients after mountd fails to
> >>write on channel :
> >>
> >>rpc.mountd[11231]: auth_unix_gid: error writing reply
> >>
> >>Userland nfs-utils uses a buffer size of 32k (RPC_CHAN_BUF_SIZE), so
> >>lets match those two.
> >
> >Thanks, applying.
> >
> >That should allow about 4000 group memberships. If that doesn't do it
> >then maybe it's time to rethink
> >
> >--b.
> >
> >>
> >>Signed-off-by: Roberto Bergantinos Corpas
> >>---
> >> net/sunrpc/cache.c | 2 +-
> >> 1 file changed, 1 insertion(+), 1 deletion(-)
> >>
> >>diff --git a/net/sunrpc/cache.c b/net/sunrpc/cache.c
> >>index baef5ee43dbb..08df4c599ab3 100644
> >>--- a/net/sunrpc/cache.c
> >>+++ b/net/sunrpc/cache.c
> >>@@ -908,7 +908,7 @@ static ssize_t cache_do_downcall(char *kaddr, const
> >>char __user *buf,
> >> static ssize_t cache_slow_downcall(const char __user *buf,
> >> size_t count, struct cache_detail *cd)
> >> {
> >>- static char write_buf[8192]; /* protected by queue_io_mutex */
> >>+ static char write_buf[32768]; /* protected by queue_io_mutex */
> >>ssize_t ret = -EINVAL;
> >>
> >>if (count >= sizeof(write_buf))
>
> This is now commit 27a1e8a0f79e643d ("sunrpc: raise kernel RPC channel
> buffer size") upstream, and increases kernel size by 24 KiB, even if
> RPC is not used.
>
> Can this buffer allocated dynamically instead? This code path seems to
> be a slow path anyway. If it's critical, perhaps this buffer can be
> allocated on first use?
Sure. Actually it is using an allocated buffer typically, see
cache_downcall().
Looking back at the history That was added by Trond in 2009
(da77005f0d64 "SUNRPC: Remove the global temporary write buffer in
net/sunrpc/cache.c").
Before that there's a pre-git change from 2004 which replaced a simple
kmalloc(PAGE_SIZE).
So I guess the point was to be careful about higher-order allocations,
but probably it was overkill.
How about making it a kvmalloc?
--b.
include/linux/irq.h:744: undefined reference to `extcon_find_edev_by_node'
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: 40a03b750bb3ded71a0f21a0b7dfbf3b24068dcb
commit: eff8728fe69880d3f7983bec3fb6cea4c306261f vmlinux.lds.h: Add PGO and
AutoFDO input sections
date: 8 weeks ago
config: riscv-randconfig-r001-20201023 (attached as .config)
compiler: riscv64-linux-gcc (GCC) 9.3.0
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
#
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=eff8728fe69880d3f7983bec3fb6cea4c306261f
git remote add linus
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
git fetch --no-tags linus master
git checkout eff8728fe69880d3f7983bec3fb6cea4c306261f
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross
ARCH=riscv
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All errors (new ones prefixed by >>):
riscv64-linux-ld: drivers/gpu/drm/bridge/sil-sii8620.o: in function
`sii8620_remove':
drivers/gpu/drm/bridge/sil-sii8620.c:2354: undefined reference to
`extcon_unregister_notifier'
riscv64-linux-ld: drivers/gpu/drm/bridge/sil-sii8620.o: in function
`irq_set_status_flags':
>> include/linux/irq.h:744: undefined reference to `extcon_find_edev_by_node'
riscv64-linux-ld: drivers/gpu/drm/bridge/sil-sii8620.o: in function `IS_ERR':
>> include/linux/err.h:36: undefined reference to `extcon_register_notifier'
riscv64-linux-ld: drivers/gpu/drm/bridge/sil-sii8620.o: in function
`lockdep_init_map_wait':
>> include/linux/lockdep.h:191: undefined reference to `extcon_get_state'
vim +744 include/linux/irq.h
442471848f5abb Thomas Gleixner 2010-09-28 741
442471848f5abb Thomas Gleixner 2010-09-28 742 static inline void
irq_set_status_flags(unsigned int irq, unsigned long set)
442471848f5abb Thomas Gleixner 2010-09-28 743 {
442471848f5abb Thomas Gleixner 2010-09-28 @744 irq_modify_status(irq,
0, set);
442471848f5abb Thomas Gleixner 2010-09-28 745 }
442471848f5abb Thomas Gleixner 2010-09-28 746
:: The code at line 744 was first introduced by commit
:: 442471848f5abb55b99cba1229301655f67492b4 genirq: Provide status modifier
:: TO: Thomas Gleixner
:: CC: Thomas Gleixner
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
.config.gz
Description: application/gzip
[PATCH] fix scheduler regression from "sched/fair: Rework load_balance()"
Hi everyone, We’re validating a new kernel in the fleet, and compared with v5.2, performance is ~2-3% lower for some of our workloads. After some digging, Johannes found that our involuntary context switch rate was ~2x higher, and we were leaving a CPU idle a higher percentage of the time, even though the workload was trying to saturate the system. We were able to reproduce the problem with schbench, and Johannes bisected down to: commit 0b0695f2b34a4afa3f6e9aa1ff0e5336d8dad912 Author: Vincent Guittot Date: Fri Oct 18 15:26:31 2019 +0200 sched/fair: Rework load_balance() Our working theory is the load balancing changes are leaving processes behind busy CPUs instead of moving them onto idle ones. I made a few schbench modifications to make this easier to demonstrate: https://git.kernel.org/pub/scm/linux/kernel/git/mason/schbench.git/ My VM has 40 cpus (20 cores, 2 threads per core), and my schbench command line is: schbench -t 20 -r 0 -c 100 -s 1000 -i 30 -z 120 This has two message threads, and 20 workers per message thread. Once woken up, the workers think for a full second, which means you’ll have some long latencies if you’re stuck behind one of these workers in the runqueue. The message thread does a little bit of work and then sleeps, so we end up with 40 threads hammering full blast on the CPU and 2 threads popping in and out of idle. schbench times the delay from when a message thread wakes a worker to when the worker runs. On a good kernel, the output looks like this: Latency percentiles (usec) runtime 1290 (s) (3280 total samples) 50.0th: 155 (1653 samples) 75.0th: 189 (808 samples) 90.0th: 216 (501 samples) 95.0th: 227 (163 samples) *99.0th: 256 (123 samples) 99.5th: 1510 (16 samples) 99.9th: 3132 (13 samples) min=21, max=3286 With 0b0695f2b34a, we get this: Latency percentiles (usec) runtime 1440 (s) (4480 total samples) 50.0th: 147 (2261 samples) 75.0th: 182 (1116 samples) 90.0th: 205 (671 samples) 95.0th: 224 (215 samples) *99.0th: 12240 (173 samples) <—— much higher p99 and up 99.5th: 12752 (22 samples) 99.9th: 13104 (18 samples) min=21, max=13172 Since the idea is to fully load the machine with schbench, use schbench -t , and make sure the box doesn’t have other stuff running in the background. I used a VM because it ended up giving more consistent results on our kernel test machines, which have some periodic noise running in the background. We’ve tried a few different approaches, but don’t quite have a solid fix yet. I thought I’d kick off the discussion with my most useful hunks so far: diff a/kernel/sched/fair.c b/kernel/sched/fair.c --- a/kernel/sched/fair.c +++ b/kernel/sched/fair.c -chris
Re: [GIT PULL] More power management updates for v5.10-rc1
The pull request you sent on Fri, 23 Oct 2020 19:29:43 +0200: > git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git > pm-5.10-rc1-2 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/41f762a15a6324f67c3f084ece694c26f196cece Thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/prtracker.html
Re: [GIT PULL] final round of SCSI updates for the 5.9+ merge window
The pull request you sent on Fri, 23 Oct 2020 11:46:21 -0700: > git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi.git scsi-misc has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/af995383eb653f875c4e4e2349d5b0b4ba839eaa Thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/prtracker.html
Re: [git pull] Input updates for v5.10-rc0
The pull request you sent on Thu, 22 Oct 2020 21:54:21 -0700: > git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git for-linus has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/bd7e8c996f5aba542f416ee6d19e91fd3668674f Thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/prtracker.html
Re: [GIT PULL] More ACPI updates for v5.10-rc1
The pull request you sent on Fri, 23 Oct 2020 19:31:24 +0200: > git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git > acpi-5.10-rc1-2 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/b76f733c3ff83089cf1e3f9ae233533649f999b3 Thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/prtracker.html
RE: [PATCH] x86/uaccess: fix code generation in put_user()
On October 23, 2020 2:52:16 PM PDT, David Laight wrote: >From: Linus Torvalds >> Sent: 23 October 2020 22:11 >> >> On Fri, Oct 23, 2020 at 2:00 PM wrote: >> > >> > There is no same reason to mess around with hacks when we are >talking about dx:ax, though. >> >> Sure there is. >> >> "A" doesn't actually mean %edx:%eax like you seem to think. >> >> It actually means %eax OR %edx, and then if given a 64-bit value, it >> will use the combination (with %edx being the high bits). >> >> So using "A" unconditionally doesn't work - it gives random behavior >> for 32-bit (or smaller) types. >> >> Or you'd have to cast the value to always be 64-bit, and have the >> extra code generation. >> >> IOW, an unconditional "A" is wrong. >> >> And the alternative is to just duplicate things, and go back to the >> explicit size testing, but honestly, I really think that's much worse >> than relying on a documented feature of "register asm()" that gcc >> _documents_ is for this kind of inline asm use. > >Could do_put_user() do an initial check for 64 bit >then expand a different #define that contains the actual >code passing either "a" or "A" for the constriant. > >Apart from another level of indirection nothing is duplicated. > > David > >- >Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, >MK1 1PT, UK >Registration No: 1397386 (Wales) Maybe #define ASM_AX64 or some such. -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Re: [PATCH v2 2/3] dt-bindings: HID: i2c-hid: Introduce bindings for the Goodix GT7375P
Hi,
On Fri, Oct 23, 2020 at 4:23 PM Douglas Anderson wrote:
>
> +examples:
> + - |
> +#include
> +#include
> +#include
> +
> +i2c {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + ap_ts: touchscreen@5d {
> +compatible = "hid-over-i2c";
You always find one more problem right after you hit send, don't you?
Or is that just me?
Obviously the above should say
compatible = "goodix,gt7375p";
Luckily when I change that "dt_binding_check" still passes. Whew!
I won't send a v3 yet and I'll wait for feedback. On the off chance
that there are no other problems with this binding and the maintainer
wants to land this, I don't have any objections to the maintainer
fixing this when the patch lands.
-Doug
Re: [RFC] Have insn decoder functions return success/failure
On Fri, Oct 23, 2020 at 07:47:04PM +0900, Masami Hiramatsu wrote:
> Thanks! I look forward to it.
Ok, here's a first stab, it is a single big diff and totally untested
but it should show what I mean. I've made some notes while converting,
as I went along.
Have a look at insn_decode() and its call sites: they are almost trivial
now because caller needs simply to do:
if (insn_decode(insn, buffer, ...))
and not care about any helper functions.
For some of the call sites it still makes sense to do a piecemeal insn
decoding and I've left them this way but they can be converted too, if
one wants.
In any case, just have a look please and lemme know if that looks OKish.
I'll do the actual splitting and testing afterwards.
And what Andy wants can't be done with the decoder because it already
gets a fixed size buffer and length - it doesn't do the fetching. The
caller does.
What you wanna do:
> len = min(15, remaining bytes in page);
> fetch len bytes;
> insn_init();
> ret = insn_decode_fully();
<--- you can't always know here whether the insn is valid if you don't
have all the bytes. But you can always fetch *all* bytes and then give
it to the decoder for checking.
Also, this doesn't make any sense: try insn decode on a subset of bytes
and then if it fails, try it on the whole set of bytes. Why even try the
subset - it will almost always fail.
> if (ret == -EAGAIN) {
> fetch remaining 15 - len bytes;
> insn_init();
> ret = insn_decode_fully();
Ok, good night and good luck. :-)
Author: Borislav Petkov
Date: Fri Oct 23 12:15:59 2020 +0200
insn: Reorg
- Rename insn_decode() to insn_decode_regs() to denote that it receives
regs as param and free the name for the generic version.
- intel/ds.c needs only the insn length so it uses the appropriate
helper instead of a full decode.
- make insn_get_opcode() return an errval, make it more stricter as
to whether what has seen so far is a valid insn and if not, signal an
error.
- lbr.c doesn't need to call the full insn_decode() because it doesn't
need it in all cases thus the separate calls.
- Add enum insn_mode to insn_decode() to call kernel_insn_init() too.
diff --git a/arch/x86/boot/compressed/sev-es.c
b/arch/x86/boot/compressed/sev-es.c
index 954cb2702e23..8d95f859e439 100644
--- a/arch/x86/boot/compressed/sev-es.c
+++ b/arch/x86/boot/compressed/sev-es.c
@@ -79,16 +79,13 @@ static inline void sev_es_wr_ghcb_msr(u64 val)
static enum es_result vc_decode_insn(struct es_em_ctxt *ctxt)
{
char buffer[MAX_INSN_SIZE];
- enum es_result ret;
memcpy(buffer, (unsigned char *)ctxt->regs->ip, MAX_INSN_SIZE);
- insn_init(&ctxt->insn, buffer, MAX_INSN_SIZE, 1);
- insn_get_length(&ctxt->insn);
+ if (insn_decode(&ctxt->insn, buffer, MAX_INSN_SIZE, INSN_MODE_64))
+ return ES_DECODE_FAILED;
- ret = ctxt->insn.immediate.got ? ES_OK : ES_DECODE_FAILED;
-
- return ret;
+ return ES_OK;
}
static enum es_result vc_write_mem(struct es_em_ctxt *ctxt,
diff --git a/arch/x86/events/intel/ds.c b/arch/x86/events/intel/ds.c
index 404315df1e16..aa72e8d305dd 100644
--- a/arch/x86/events/intel/ds.c
+++ b/arch/x86/events/intel/ds.c
@@ -1262,14 +1262,14 @@ static int intel_pmu_pebs_fixup_ip(struct pt_regs *regs)
is_64bit = kernel_ip(to) || !test_thread_flag(TIF_IA32);
#endif
insn_init(&insn, kaddr, size, is_64bit);
- insn_get_length(&insn);
+
/*
* Make sure there was not a problem decoding the
* instruction and getting the length. This is
* doubly important because we have an infinite
* loop if insn.length=0.
*/
- if (!insn.length)
+ if (insn_get_length(&insn) || !insn.length)
break;
to += insn.length;
diff --git a/arch/x86/events/intel/lbr.c b/arch/x86/events/intel/lbr.c
index 8961653c5dd2..d23f7d3108a8 100644
--- a/arch/x86/events/intel/lbr.c
+++ b/arch/x86/events/intel/lbr.c
@@ -1224,8 +1224,7 @@ static int branch_type(unsigned long from, unsigned long
to, int abort)
is64 = kernel_ip((unsigned long)addr) || !test_thread_flag(TIF_IA32);
#endif
insn_init(&insn, addr, bytes_read, is64);
- insn_get_opcode(&insn);
- if (!insn.opcode.got)
+ if (insn_get_opcode(&insn))
return X86_BR_ABORT;
switch (insn.opcode.bytes[0]) {
@@ -1262,8 +1261,7 @@ static int branch_type(unsigned long from, unsigned long
to, int abort)
ret = X86_BR_INT;
break;
case 0xe8: /* call near rel */
- insn_get_immediate(&insn);
- if (insn.immediate1.value == 0) {
+ if (insn_get_immediate(&insn) || insn.immediate1.value == 0) {
/* zero length call */
[PATCH] mm: remove kzfree() compatibility definition
From: Eric Biggers
Commit 453431a54934 ("mm, treewide: rename kzfree() to
kfree_sensitive()") renamed kzfree() to kfree_sensitive(), but it left a
compatibility definition of kzfree() to avoid being too disruptive.
Since then a few more instances of kzfree() have slipped in. Just get
rid of them and remove the compatibility definition once and for all.
Signed-off-by: Eric Biggers
---
Linus, are you interested in applying this around the time of v5.10-rc1?
There's not really any reason to keep this around, and people will
otherwise keep introducing new uses.
drivers/staging/rtl8192e/rtllib_crypt_tkip.c | 2 +-
drivers/staging/rtl8192e/rtllib_crypt_wep.c | 2 +-
drivers/staging/rtl8192u/ieee80211/ieee80211_crypt_tkip.c | 2 +-
drivers/staging/rtl8192u/ieee80211/ieee80211_crypt_wep.c | 2 +-
include/linux/slab.h | 2 --
net/tipc/crypto.c | 4 ++--
6 files changed, 6 insertions(+), 8 deletions(-)
diff --git a/drivers/staging/rtl8192e/rtllib_crypt_tkip.c
b/drivers/staging/rtl8192e/rtllib_crypt_tkip.c
index 8c2ff37b2d3a..238387d6221b 100644
--- a/drivers/staging/rtl8192e/rtllib_crypt_tkip.c
+++ b/drivers/staging/rtl8192e/rtllib_crypt_tkip.c
@@ -100,7 +100,7 @@ static void rtllib_tkip_deinit(void *priv)
crypto_free_shash(_priv->tx_tfm_michael);
crypto_free_shash(_priv->rx_tfm_michael);
}
- kzfree(priv);
+ kfree_sensitive(priv);
}
diff --git a/drivers/staging/rtl8192e/rtllib_crypt_wep.c
b/drivers/staging/rtl8192e/rtllib_crypt_wep.c
index 7cdd17f907fa..7790271a6a40 100644
--- a/drivers/staging/rtl8192e/rtllib_crypt_wep.c
+++ b/drivers/staging/rtl8192e/rtllib_crypt_wep.c
@@ -49,7 +49,7 @@ static void *prism2_wep_init(int keyidx)
static void prism2_wep_deinit(void *priv)
{
- kzfree(priv);
+ kfree_sensitive(priv);
}
/* Perform WEP encryption on given skb that has at least 4 bytes of headroom
diff --git a/drivers/staging/rtl8192u/ieee80211/ieee80211_crypt_tkip.c
b/drivers/staging/rtl8192u/ieee80211/ieee80211_crypt_tkip.c
index 4b415cc76715..e8fa1d385f24 100644
--- a/drivers/staging/rtl8192u/ieee80211/ieee80211_crypt_tkip.c
+++ b/drivers/staging/rtl8192u/ieee80211/ieee80211_crypt_tkip.c
@@ -107,7 +107,7 @@ static void ieee80211_tkip_deinit(void *priv)
crypto_free_shash(_priv->tx_tfm_michael);
crypto_free_shash(_priv->rx_tfm_michael);
}
- kzfree(priv);
+ kfree_sensitive(priv);
}
diff --git a/drivers/staging/rtl8192u/ieee80211/ieee80211_crypt_wep.c
b/drivers/staging/rtl8192u/ieee80211/ieee80211_crypt_wep.c
index 1c56e2d03aae..a41b6510481b 100644
--- a/drivers/staging/rtl8192u/ieee80211/ieee80211_crypt_wep.c
+++ b/drivers/staging/rtl8192u/ieee80211/ieee80211_crypt_wep.c
@@ -54,7 +54,7 @@ static void *prism2_wep_init(int keyidx)
static void prism2_wep_deinit(void *priv)
{
- kzfree(priv);
+ kfree_sensitive(priv);
}
/* Perform WEP encryption on given skb that has at least 4 bytes of headroom
diff --git a/include/linux/slab.h b/include/linux/slab.h
index 9e155cc83b8a..dd6897f62010 100644
--- a/include/linux/slab.h
+++ b/include/linux/slab.h
@@ -187,8 +187,6 @@ void kfree_sensitive(const void *);
size_t __ksize(const void *);
size_t ksize(const void *);
-#define kzfree(x) kfree_sensitive(x) /* For backward compatibility */
-
#ifdef CONFIG_HAVE_HARDENED_USERCOPY_ALLOCATOR
void __check_heap_object(const void *ptr, unsigned long n, struct page *page,
bool to_user);
diff --git a/net/tipc/crypto.c b/net/tipc/crypto.c
index 40c44101fe8e..740ab9ae41a6 100644
--- a/net/tipc/crypto.c
+++ b/net/tipc/crypto.c
@@ -418,7 +418,7 @@ static void tipc_aead_free(struct rcu_head *rp)
kfree(head);
}
free_percpu(aead->tfm_entry);
- kzfree(aead->key);
+ kfree_sensitive(aead->key);
kfree(aead);
}
@@ -2452,7 +2452,7 @@ static void tipc_crypto_work_tx(struct work_struct *work)
tipc_crypto_key_init(tx, skey, PER_NODE_KEY, false);
if (likely(rc > 0))
rc = tipc_crypto_key_distr(tx, rc, NULL);
- kzfree(skey);
+ kfree_sensitive(skey);
}
if (unlikely(rc))
--
2.29.0.rc1.297.gfa9743e501-goog
[PATCH v2 1/3] dt-bindings: HID: i2c-hid: Label this binding as deprecated
As pointed out by Rob Herring [1], we should have a device-specific
compatible string. This means people shouldn't be using the
"i2c-over-hid" compatible string anymore, or at least not without a
more specific compatible string before it. Specifically:
1. For newly added devices we should just have the device-specific
device string (no "hid-over-i2c" fallback) and infer the timings
and hid-descr-addr from there.
2. If there's a need for a device tree to be backward compatible, we
should list the device-specific compatible string and add the
"hid-over-i2c" fallback and the various timings.
[1] https://lore.kernel.org/r/20201019211036.GA3595039@bogus
Signed-off-by: Douglas Anderson
---
Changes in v2:
- ("dt-bindings: HID: i2c-hid: Label this binding as deprecated") new in v2.
Documentation/devicetree/bindings/input/hid-over-i2c.txt | 3 +++
1 file changed, 3 insertions(+)
diff --git a/Documentation/devicetree/bindings/input/hid-over-i2c.txt
b/Documentation/devicetree/bindings/input/hid-over-i2c.txt
index c76bafaf98d2..733a5f053280 100644
--- a/Documentation/devicetree/bindings/input/hid-over-i2c.txt
+++ b/Documentation/devicetree/bindings/input/hid-over-i2c.txt
@@ -1,5 +1,8 @@
* HID over I2C Device-Tree bindings
+WARNING: this binding is deprecated. Instead of using this, create specific
+bindings for each hid-over-i2c device.
+
HID over I2C provides support for various Human Interface Devices over the
I2C bus. These devices can be for example touchpads, keyboards, touch screens
or sensors.
--
2.29.0.rc1.297.gfa9743e501-goog
[PATCH v2 2/3] dt-bindings: HID: i2c-hid: Introduce bindings for the Goodix GT7375P
This adds new bindings for the Goodix GT7375P touchscreen. While this
touchscreen works with generic "i2c-over-hid", the current advice is
to give it its own compatible string. The cleanest way to do this is
to give it its own bindings.
Among other things, this has the advantage that we can list the two
possible i2c addresses for this device, which gives extra checking.
Signed-off-by: Douglas Anderson
---
Changes in v2:
- ("dt-bindings: HID: i2c-hid: Introduce bindings for the Goodix GT7375P") new
in v2.
.../bindings/input/goodix,gt7375p.yaml| 64 +++
1 file changed, 64 insertions(+)
create mode 100644 Documentation/devicetree/bindings/input/goodix,gt7375p.yaml
diff --git a/Documentation/devicetree/bindings/input/goodix,gt7375p.yaml
b/Documentation/devicetree/bindings/input/goodix,gt7375p.yaml
new file mode 100644
index ..b5008f89e26c
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/goodix,gt7375p.yaml
@@ -0,0 +1,64 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/input/goodix,gt7375p.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Goodix GT7375P touchscreen
+
+maintainers:
+ - Benjamin Tissoires
+ - Douglas Anderson
+
+description:
+ Supports the Goodix GT7375P touchscreen.
+
+properties:
+ compatible:
+items:
+ - const: goodix,gt7375p
+
+ reg:
+enum:
+ - 0x5d
+ - 0x14
+
+ interrupts:
+maxItems: 1
+
+ reset-gpios:
+true
+
+ vdd-supply:
+description: The 3.3V supply to the touchscreen.
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - reset-gpios
+ - vdd-supply
+
+additionalProperties: false
+
+examples:
+ - |
+#include
+#include
+#include
+
+i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ap_ts: touchscreen@5d {
+compatible = "hid-over-i2c";
+reg = <0x5d>;
+
+interrupt-parent = <&tlmm>;
+interrupts = <9 IRQ_TYPE_LEVEL_LOW>;
+
+reset-gpios = <&tlmm 8 GPIO_ACTIVE_LOW>;
+vdd-supply = <&pp3300_ts>;
+ };
+};
--
2.29.0.rc1.297.gfa9743e501-goog
[PATCH v2 3/3] HID: i2c-hid: Support the Goodix GT7375P touchscreen
The Goodix GT7375P touchscreen uses i2c-hid so we can support it with
just a few changes to the i2c-hid driver. Specifically this
touchscreen needs to control a reset GPIO during its power sequencing.
The Goodix timing diagram shows this:
+--
|
AVDD +
+--
| (a) |
RESET -+
+-
| (b) |
I2C comm OK -+
Where (a) is 10 ms and (b) is 120 ms.
While we could just add some properties and specify this generically
in the device tree, the guidance from the device tree maintainer is
that it's better to list the specific model and infer everything from
there. Thus that's what this patch implements.
Signed-off-by: Douglas Anderson
---
Changes in v2:
- Use a separate compatible string for this new touchscreen.
- Get timings based on the compatible string.
drivers/hid/i2c-hid/i2c-hid-core.c| 50 ++-
include/linux/platform_data/i2c-hid.h | 5 +++
2 files changed, 54 insertions(+), 1 deletion(-)
diff --git a/drivers/hid/i2c-hid/i2c-hid-core.c
b/drivers/hid/i2c-hid/i2c-hid-core.c
index 786e3e9af1c9..0b2cd78b05e1 100644
--- a/drivers/hid/i2c-hid/i2c-hid-core.c
+++ b/drivers/hid/i2c-hid/i2c-hid-core.c
@@ -71,6 +71,12 @@ do {
\
dev_printk(KERN_DEBUG, &(ihid)->client->dev, fmt, ##arg); \
} while (0)
+struct i2c_hid_match_data {
+ u16 hid_descriptor_address;
+ int post_power_delay_ms;
+ int post_gpio_reset_delay_ms;
+};
+
struct i2c_hid_desc {
__le16 wHIDDescLength;
__le16 bcdVersion;
@@ -962,6 +968,21 @@ static inline void i2c_hid_acpi_enable_wakeup(struct
device *dev) {}
#endif
#ifdef CONFIG_OF
+static bool i2c_hid_init_from_of_match(struct device *dev,
+ struct i2c_hid_platform_data *pdata)
+{
+ const struct i2c_hid_match_data *match_data =
device_get_match_data(dev);
+
+ if (!match_data)
+ return false;
+
+ pdata->hid_descriptor_address = match_data->hid_descriptor_address;
+ pdata->post_power_delay_ms = match_data->post_power_delay_ms;
+ pdata->post_gpio_reset_delay_ms = match_data->post_gpio_reset_delay_ms;
+
+ return true;
+}
+
static int i2c_hid_of_probe(struct i2c_client *client,
struct i2c_hid_platform_data *pdata)
{
@@ -969,6 +990,11 @@ static int i2c_hid_of_probe(struct i2c_client *client,
u32 val;
int ret;
+ /* Try getting everything based on the compatible string first */
+ if (i2c_hid_init_from_of_match(&client->dev, pdata))
+ return 0;
+
+ /* Fallback to getting hid-descr-addr from a property */
ret = of_property_read_u32(dev->of_node, "hid-descr-addr", &val);
if (ret) {
dev_err(&client->dev, "HID register address not provided\n");
@@ -984,8 +1010,15 @@ static int i2c_hid_of_probe(struct i2c_client *client,
return 0;
}
+static const struct i2c_hid_match_data goodix_gt7375p_match_data = {
+ .hid_descriptor_address = 0x0001,
+ .post_power_delay_ms = 10,
+ .post_gpio_reset_delay_ms = 120,
+};
+
static const struct of_device_id i2c_hid_of_match[] = {
- { .compatible = "hid-over-i2c" },
+ { .compatible = "goodix,gt7375p", .data = &goodix_gt7375p_match_data },
+ { .compatible = "hid-over-i2c" }, /* Deprecated */
{},
};
MODULE_DEVICE_TABLE(of, i2c_hid_of_match);
@@ -1053,6 +1086,12 @@ static int i2c_hid_probe(struct i2c_client *client,
ihid->pdata.supplies[0].supply = "vdd";
ihid->pdata.supplies[1].supply = "vddl";
+ /* Start out with reset asserted */
+ ihid->pdata.reset_gpio =
+ devm_gpiod_get_optional(&client->dev, "reset", GPIOD_OUT_HIGH);
+ if (IS_ERR(ihid->pdata.reset_gpio))
+ return PTR_ERR(ihid->pdata.reset_gpio);
+
ret = devm_regulator_bulk_get(&client->dev,
ARRAY_SIZE(ihid->pdata.supplies),
ihid->pdata.supplies);
@@ -1067,6 +1106,10 @@ static int i2c_hid_probe(struct i2c_client *client,
if (ihid->pdata.post_power_delay_ms)
msleep(ihid->pdata.post_power_delay_ms);
+ gpiod_set_value_cansleep(ihid->pdata.reset_gpio, 0);
+ if (ihid->pdata.post_gpio_reset_delay_ms)
+ msleep(ihid->pdata.post_gpio_reset_delay_ms);
+
i2c_set_clientdata(client, ihid);
ihid->client = client;
@@ -1163,6 +1206,7 @@ static int i2c_hid_remove(struct i2c_client *client)
if (ihid->bufsize)
i2c_hid_free_buffers(ihid);
+ gpiod_set_value_cansleep(ihid->pdata.reset_gpio, 1);
regulator_bulk_disable(ARRAY_SIZE(ihid->pdata.supplies),
ihid->pdata.supplies);
@@ -1228,6 +1272,10 @@ static int i2c_
[PATCH 4.9-stable] scripts/setlocalversion: make git describe output more reliable
commit 548b8b5168c90c42e88f70fcf041b4ce0b8e7aa8 upstream.
When building for an embedded target using Yocto, we're sometimes
observing that the version string that gets built into vmlinux (and
thus what uname -a reports) differs from the path under /lib/modules/
where modules get installed in the rootfs, but only in the length of
the -gabc123def suffix. Hence modprobe always fails.
The problem is that Yocto has the concept of "sstate" (shared state),
which allows different developers/buildbots/etc. to share build
artifacts, based on a hash of all the metadata that went into building
that artifact - and that metadata includes all dependencies (e.g. the
compiler used etc.). That normally works quite well; usually a clean
build (without using any sstate cache) done by one developer ends up
being binary identical to a build done on another host. However, one
thing that can cause two developers to end up with different builds
[and thus make one's vmlinux package incompatible with the other's
kernel-dev package], which is not captured by the metadata hashing, is
this `git describe`: The output of that can be affected by
(1) git version: before 2.11 git defaulted to a minimum of 7, since
2.11 (git.git commit e6c587) the default is dynamic based on the
number of objects in the repo
(2) hence even if both run the same git version, the output can differ
based on how many remotes are being tracked (or just lots of local
development branches or plain old garbage)
(3) and of course somebody could have a core.abbrev config setting in
~/.gitconfig
So in order to avoid `uname -a` output relying on such random details
of the build environment which are rather hard to ensure are
consistent between developers and buildbots, make sure the abbreviated
sha1 always consists of exactly 12 hex characters. That is consistent
with the current rule for -stable patches, and is almost always enough
to identify the head commit unambigously - in the few cases where it
does not, the v5.4.3-00021- prefix would certainly nail it down.
[Adapt to `` vs $() differences between 4.9 and upstream.]
Signed-off-by: Rasmus Villemoes
Signed-off-by: Masahiro Yamada
---
scripts/setlocalversion | 21 -
1 file changed, 16 insertions(+), 5 deletions(-)
diff --git a/scripts/setlocalversion b/scripts/setlocalversion
index aa28c3f29809314bfa58..0c8741b795d0c82a38c9 100755
--- a/scripts/setlocalversion
+++ b/scripts/setlocalversion
@@ -44,7 +44,7 @@ scm_version()
# Check for git and a git repo.
if test -z "$(git rev-parse --show-cdup 2>/dev/null)" &&
- head=`git rev-parse --verify --short HEAD 2>/dev/null`; then
+ head=$(git rev-parse --verify HEAD 2>/dev/null); then
# If we are at a tagged commit (like "v2.6.30-rc6"), we ignore
# it, because this version is defined in the top level Makefile.
@@ -58,11 +58,22 @@ scm_version()
fi
# If we are past a tagged commit (like
# "v2.6.30-rc5-302-g72357d5"), we pretty print it.
- if atag="`git describe 2>/dev/null`"; then
- echo "$atag" | awk -F- '{printf("-%05d-%s",
$(NF-1),$(NF))}'
-
- # If we don't have a tag at all we print -g{commitish}.
+ #
+ # Ensure the abbreviated sha1 has exactly 12
+ # hex characters, to make the output
+ # independent of git version, local
+ # core.abbrev settings and/or total number of
+ # objects in the current repository - passing
+ # --abbrev=12 ensures a minimum of 12, and the
+ # awk substr() then picks the 'g' and first 12
+ # hex chars.
+ if atag="$(git describe --abbrev=12 2>/dev/null)"; then
+ echo "$atag" | awk -F- '{printf("-%05d-%s",
$(NF-1),substr($(NF),0,13))}'
+
+ # If we don't have a tag at all we print -g{commitish},
+ # again using exactly 12 hex chars.
else
+ head="$(echo $head | cut -c1-12)"
printf '%s%s' -g $head
fi
fi
--
2.23.0
[PATCH 4.4-stable] scripts/setlocalversion: make git describe output more reliable
commit 548b8b5168c90c42e88f70fcf041b4ce0b8e7aa8 upstream.
When building for an embedded target using Yocto, we're sometimes
observing that the version string that gets built into vmlinux (and
thus what uname -a reports) differs from the path under /lib/modules/
where modules get installed in the rootfs, but only in the length of
the -gabc123def suffix. Hence modprobe always fails.
The problem is that Yocto has the concept of "sstate" (shared state),
which allows different developers/buildbots/etc. to share build
artifacts, based on a hash of all the metadata that went into building
that artifact - and that metadata includes all dependencies (e.g. the
compiler used etc.). That normally works quite well; usually a clean
build (without using any sstate cache) done by one developer ends up
being binary identical to a build done on another host. However, one
thing that can cause two developers to end up with different builds
[and thus make one's vmlinux package incompatible with the other's
kernel-dev package], which is not captured by the metadata hashing, is
this `git describe`: The output of that can be affected by
(1) git version: before 2.11 git defaulted to a minimum of 7, since
2.11 (git.git commit e6c587) the default is dynamic based on the
number of objects in the repo
(2) hence even if both run the same git version, the output can differ
based on how many remotes are being tracked (or just lots of local
development branches or plain old garbage)
(3) and of course somebody could have a core.abbrev config setting in
~/.gitconfig
So in order to avoid `uname -a` output relying on such random details
of the build environment which are rather hard to ensure are
consistent between developers and buildbots, make sure the abbreviated
sha1 always consists of exactly 12 hex characters. That is consistent
with the current rule for -stable patches, and is almost always enough
to identify the head commit unambigously - in the few cases where it
does not, the v5.4.3-00021- prefix would certainly nail it down.
[Adapt to `` vs $() differences between 4.4 and upstream.]
Signed-off-by: Rasmus Villemoes
Signed-off-by: Masahiro Yamada
---
scripts/setlocalversion | 21 -
1 file changed, 16 insertions(+), 5 deletions(-)
diff --git a/scripts/setlocalversion b/scripts/setlocalversion
index aa28c3f29809314bfa58..0c8741b795d0c82a38c9 100755
--- a/scripts/setlocalversion
+++ b/scripts/setlocalversion
@@ -44,7 +44,7 @@ scm_version()
# Check for git and a git repo.
if test -z "$(git rev-parse --show-cdup 2>/dev/null)" &&
- head=`git rev-parse --verify --short HEAD 2>/dev/null`; then
+ head=$(git rev-parse --verify HEAD 2>/dev/null); then
# If we are at a tagged commit (like "v2.6.30-rc6"), we ignore
# it, because this version is defined in the top level Makefile.
@@ -58,11 +58,22 @@ scm_version()
fi
# If we are past a tagged commit (like
# "v2.6.30-rc5-302-g72357d5"), we pretty print it.
- if atag="`git describe 2>/dev/null`"; then
- echo "$atag" | awk -F- '{printf("-%05d-%s",
$(NF-1),$(NF))}'
-
- # If we don't have a tag at all we print -g{commitish}.
+ #
+ # Ensure the abbreviated sha1 has exactly 12
+ # hex characters, to make the output
+ # independent of git version, local
+ # core.abbrev settings and/or total number of
+ # objects in the current repository - passing
+ # --abbrev=12 ensures a minimum of 12, and the
+ # awk substr() then picks the 'g' and first 12
+ # hex chars.
+ if atag="$(git describe --abbrev=12 2>/dev/null)"; then
+ echo "$atag" | awk -F- '{printf("-%05d-%s",
$(NF-1),substr($(NF),0,13))}'
+
+ # If we don't have a tag at all we print -g{commitish},
+ # again using exactly 12 hex chars.
else
+ head="$(echo $head | cut -c1-12)"
printf '%s%s' -g $head
fi
fi
--
2.23.0
[PATCH v9 1/4] bus: mhi: core: Add helper API to return number of free TREs
Introduce mhi_get_free_desc_count() API to return number
of TREs available to queue buffer. MHI clients can use this
API to know before hand if ring is full without calling queue
API.
Signed-off-by: Hemant Kumar
Reviewed-by: Jeffrey Hugo
Reviewed-by: Manivannan Sadhasivam
---
drivers/bus/mhi/core/main.c | 12
include/linux/mhi.h | 9 +
2 files changed, 21 insertions(+)
diff --git a/drivers/bus/mhi/core/main.c b/drivers/bus/mhi/core/main.c
index 2cff5dd..3950792 100644
--- a/drivers/bus/mhi/core/main.c
+++ b/drivers/bus/mhi/core/main.c
@@ -258,6 +258,18 @@ int mhi_destroy_device(struct device *dev, void *data)
return 0;
}
+int mhi_get_free_desc_count(struct mhi_device *mhi_dev,
+ enum dma_data_direction dir)
+{
+ struct mhi_controller *mhi_cntrl = mhi_dev->mhi_cntrl;
+ struct mhi_chan *mhi_chan = (dir == DMA_TO_DEVICE) ?
+ mhi_dev->ul_chan : mhi_dev->dl_chan;
+ struct mhi_ring *tre_ring = &mhi_chan->tre_ring;
+
+ return get_nr_avail_ring_elements(mhi_cntrl, tre_ring);
+}
+EXPORT_SYMBOL_GPL(mhi_get_free_desc_count);
+
void mhi_notify(struct mhi_device *mhi_dev, enum mhi_callback cb_reason)
{
struct mhi_driver *mhi_drv;
diff --git a/include/linux/mhi.h b/include/linux/mhi.h
index d4841e5..7829b1d 100644
--- a/include/linux/mhi.h
+++ b/include/linux/mhi.h
@@ -597,6 +597,15 @@ void mhi_set_mhi_state(struct mhi_controller *mhi_cntrl,
void mhi_notify(struct mhi_device *mhi_dev, enum mhi_callback cb_reason);
/**
+ * mhi_get_free_desc_count - Get transfer ring length
+ * Get # of TD available to queue buffers
+ * @mhi_dev: Device associated with the channels
+ * @dir: Direction of the channel
+ */
+int mhi_get_free_desc_count(struct mhi_device *mhi_dev,
+ enum dma_data_direction dir);
+
+/**
* mhi_prepare_for_power_up - Do pre-initialization before power up.
*This is optional, call this before power up if
*the controller does not want bus framework to
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
[PATCH v9 2/4] bus: mhi: core: Move MHI_MAX_MTU to external header file
Currently this macro is defined in internal MHI header as
a TRE length mask. Moving it to external header allows MHI
client drivers to set this upper bound for the transmit
buffer size.
Signed-off-by: Hemant Kumar
Reviewed-by: Jeffrey Hugo
Reviewed-by: Manivannan Sadhasivam
---
drivers/bus/mhi/core/internal.h | 1 -
include/linux/mhi.h | 3 +++
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/bus/mhi/core/internal.h b/drivers/bus/mhi/core/internal.h
index 7989269..4abf0cf 100644
--- a/drivers/bus/mhi/core/internal.h
+++ b/drivers/bus/mhi/core/internal.h
@@ -453,7 +453,6 @@ enum mhi_pm_state {
#define CMD_EL_PER_RING128
#define PRIMARY_CMD_RING 0
#define MHI_DEV_WAKE_DB127
-#define MHI_MAX_MTU0x
#define MHI_RANDOM_U32_NONZERO(bmsk) (prandom_u32_max(bmsk) + 1)
enum mhi_er_type {
diff --git a/include/linux/mhi.h b/include/linux/mhi.h
index 7829b1d..6e1122c 100644
--- a/include/linux/mhi.h
+++ b/include/linux/mhi.h
@@ -15,6 +15,9 @@
#include
#include
+/* MHI client drivers to set this upper bound for tx buffer */
+#define MHI_MAX_MTU 0x
+
#define MHI_MAX_OEM_PK_HASH_SEGMENTS 16
struct mhi_chan;
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
[PATCH v9 4/4] bus: mhi: Add userspace client interface driver
This MHI client driver allows userspace clients to transfer
raw data between MHI device and host using standard file operations.
Driver instantiates UCI device object which is associated to device
file node. UCI device object instantiates UCI channel object when device
file node is opened. UCI channel object is used to manage MHI channels
by calling MHI core APIs for read and write operations. MHI channels
are started as part of device open(). MHI channels remain in start
state until last release() is called on UCI device file node. Device
file node is created with format
/dev/mhi__
Currently it supports LOOPBACK channel.
Signed-off-by: Hemant Kumar
---
drivers/bus/mhi/Kconfig | 13 +
drivers/bus/mhi/Makefile | 4 +
drivers/bus/mhi/uci.c| 658 +++
3 files changed, 675 insertions(+)
create mode 100644 drivers/bus/mhi/uci.c
diff --git a/drivers/bus/mhi/Kconfig b/drivers/bus/mhi/Kconfig
index e841c10..476cc55 100644
--- a/drivers/bus/mhi/Kconfig
+++ b/drivers/bus/mhi/Kconfig
@@ -20,3 +20,16 @@ config MHI_BUS_DEBUG
Enable debugfs support for use with the MHI transport. Allows
reading and/or modifying some values within the MHI controller
for debug and test purposes.
+
+config MHI_UCI
+ tristate "MHI UCI"
+ depends on MHI_BUS
+ help
+ MHI based Userspace Client Interface (UCI) driver is used for
+ transferring raw data between host and device using standard file
+ operations from userspace. Open, read, write, and close operations
+ are supported by this driver. Please check mhi_uci_match_table for
+ all supported channels that are exposed to userspace.
+
+ To compile this driver as a module, choose M here: the module will be
+ called mhi_uci.
diff --git a/drivers/bus/mhi/Makefile b/drivers/bus/mhi/Makefile
index 19e6443..80feefb 100644
--- a/drivers/bus/mhi/Makefile
+++ b/drivers/bus/mhi/Makefile
@@ -1,2 +1,6 @@
# core layer
obj-y += core/
+
+# MHI client
+mhi_uci-y := uci.o
+obj-$(CONFIG_MHI_UCI) += mhi_uci.o
diff --git a/drivers/bus/mhi/uci.c b/drivers/bus/mhi/uci.c
new file mode 100644
index 000..6c64356
--- /dev/null
+++ b/drivers/bus/mhi/uci.c
@@ -0,0 +1,658 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/* Copyright (c) 2018-2020, The Linux Foundation. All rights reserved.*/
+
+#include
+#include
+#include
+#include
+#include
+
+#define DEVICE_NAME "mhi"
+#define MHI_UCI_DRIVER_NAME "mhi_uci"
+#define MAX_UCI_MINORS 128
+
+static DEFINE_IDR(uci_idr);
+static DEFINE_MUTEX(uci_drv_mutex);
+static struct class *uci_dev_class;
+static int uci_dev_major;
+
+/**
+ * struct uci_chan - MHI channel for a UCI device
+ * @udev: associated UCI device object
+ * @ul_wq: wait queue for writer
+ * @write_lock: mutex write lock for ul channel
+ * @dl_wq: wait queue for reader
+ * @read_lock: mutex read lock for dl channel
+ * @dl_pending_lock: spin lock for dl_pending list
+ * @dl_pending: list of dl buffers userspace is waiting to read
+ * @cur_buf: current buffer userspace is reading
+ * @dl_size: size of the current dl buffer userspace is reading
+ * @ref_count: uci_chan reference count
+ */
+struct uci_chan {
+ struct uci_dev *udev;
+ wait_queue_head_t ul_wq;
+
+ /* ul channel lock to synchronize multiple writes */
+ struct mutex write_lock;
+
+ wait_queue_head_t dl_wq;
+
+ /* dl channel lock to synchronize multiple reads */
+ struct mutex read_lock;
+
+ /*
+* protects pending list in bh context, channel release, read and
+* poll
+*/
+ spinlock_t dl_pending_lock;
+
+ struct list_head dl_pending;
+ struct uci_buf *cur_buf;
+ size_t dl_size;
+ struct kref ref_count;
+};
+
+/**
+ * struct uci_buf - UCI buffer
+ * @data: data buffer
+ * @len: length of data buffer
+ * @node: list node of the UCI buffer
+ */
+struct uci_buf {
+ void *data;
+ size_t len;
+ struct list_head node;
+};
+
+/**
+ * struct uci_dev - MHI UCI device
+ * @minor: UCI device node minor number
+ * @mhi_dev: associated mhi device object
+ * @uchan: UCI uplink and downlink channel object
+ * @mtu: max TRE buffer length
+ * @enabled: Flag to track the state of the UCI device
+ * @lock: mutex lock to manage uchan object
+ * @ref_count: uci_dev reference count
+ */
+struct uci_dev {
+ unsigned int minor;
+ struct mhi_device *mhi_dev;
+ struct uci_chan *uchan;
+ size_t mtu;
+ bool enabled;
+
+ /* synchronize open, release and driver remove */
+ struct mutex lock;
+ struct kref ref_count;
+};
+
+static void mhi_uci_dev_chan_release(struct kref *ref)
+{
+ struct uci_buf *buf_itr, *tmp;
+ struct uci_chan *uchan =
+ container_of(ref, struct uci_chan, ref_count);
+
+ if (uchan->udev->enabled)
+ mhi_unprepare_from_transfer(uchan->udev->mhi_dev);
+
+ spin_lock_bh(&uchan->dl_pend
[PATCH v9 3/4] docs: Add documentation for userspace client interface
MHI userspace client driver is creating device file node for user application to perform file operations. File operations are handled by MHI core driver. Currently Loopback MHI channel is supported by this driver. Signed-off-by: Hemant Kumar --- Documentation/mhi/index.rst | 1 + Documentation/mhi/uci.rst | 83 + 2 files changed, 84 insertions(+) create mode 100644 Documentation/mhi/uci.rst diff --git a/Documentation/mhi/index.rst b/Documentation/mhi/index.rst index 1d8dec3..c75a371 100644 --- a/Documentation/mhi/index.rst +++ b/Documentation/mhi/index.rst @@ -9,6 +9,7 @@ MHI mhi topology + uci .. only:: subproject and html diff --git a/Documentation/mhi/uci.rst b/Documentation/mhi/uci.rst new file mode 100644 index 000..fe901c4 --- /dev/null +++ b/Documentation/mhi/uci.rst @@ -0,0 +1,83 @@ +.. SPDX-License-Identifier: GPL-2.0 + += +Userspace Client Interface (UCI) += + +UCI driver enables userspace clients to communicate to external MHI devices +like modem and WLAN. UCI driver probe creates standard character device file +nodes for userspace clients to perform open, read, write, poll and release file +operations. + +Operations +== + +open + + +Instantiates UCI channel object and starts MHI channels to move it to running +state. Inbound buffers are queued to downlink channel transfer ring. Every +subsequent open() increments UCI device reference count as well as UCI channel +reference count. + +read + + +When data transfer is completed on downlink channel, TRE buffer is copied to +pending list. Reader is unblocked and data is copied to userspace buffer. TRE +buffer is queued back to downlink channel transfer ring. + +write +- + +Write buffer is queued to uplink channel transfer ring if ring is not full. Upon +uplink transfer completion buffer is freed. + +poll + + +Returns EPOLLIN | EPOLLRDNORM mask if pending list has buffers to be read by +userspace. Returns EPOLLOUT | EPOLLWRNORM mask if MHI uplink channel transfer +ring is not empty. Returns EPOLLERR when UCI driver is removed. MHI channels +move to disabled state upon driver remove. + +release +--- + +Decrements UCI device reference count and UCI channel reference count upon last +release(). UCI channel clean up is performed. MHI channel moves to disabled +state and inbound buffers are freed. + +Usage += + +Device file node is created with format:- + +/dev/mhi__ + +controller_name is the name of underlying bus used to transfer data. mhi_device +name is the name of the MHI channel being used by MHI client in userspace to +send or receive data using MHI protocol. + +There is a separate character device file node created for each channel +specified in mhi device id table. MHI channels are statically defined by MHI +specification. The list of supported channels is in the channel list variable +of mhi_device_id table in UCI driver. + +LOOPBACK Channel + + +Userspace MHI client using LOOPBACK channel opens device file node. As part of +open operation TREs to transfer ring of LOOPBACK channel 1 gets queued and channel +doorbell is rung. When userspace MHI client performs write operation on device node, +data buffer gets queued as a TRE to transfer ring of LOOPBACK channel 0. MHI Core +driver rings the channel doorbell for MHI device to move data over underlying bus. +When userspace MHI client driver performs read operation, same data gets looped back +to MHI host using LOOPBACK channel 1. LOOPBACK channel is used to verify data path +and data integrity between MHI Host and MHI device. + +Other Use Cases +--- + +Getting MHI device specific diagnostics information to userspace MHI diag client +using DIAG channel 4 (Host to device) and 5 (Device to Host). -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project
[PATCH v9 0/4] userspace MHI client interface driver
This patch series adds support for UCI driver. UCI driver enables userspace clients to communicate to external MHI devices like modem and WLAN. UCI driver probe creates standard character device file nodes for userspace clients to perform open, read, write, poll and release file operations. These file operations call MHI core layer APIs to perform data transfer using MHI bus to communicate with MHI device. Patch is tested using arm64 based platform. V9: - Renamed dl_lock to dl_pending _lock and pending list to dl_pending for clarity. - Used read lock to protect cur_buf. - Change transfer status check logic and only consider 0 and -EOVERFLOW as only success. - Added __int to module init function. - Print channel name instead of minor number upon successful probe. V8: - Fixed kernel test robot compilation error by changing %lu to %zu for size_t. - Replaced uci with UCI in Kconfig, commit text, and comments in driver code. - Fixed minor style related comments. V7: - Decoupled uci device and uci channel objects. uci device is associated with device file node. uci channel is associated with MHI channels. uci device refers to uci channel to perform MHI channel operations for device file operations like read() and write(). uci device increments its reference count for every open(). uci device calls mhi_uci_dev_start_chan() to start the MHI channel. uci channel object is tracking number of times MHI channel is referred. This allows to keep the MHI channel in start state until last release() is called. After that uci channel reference count goes to 0 and uci channel clean up is performed which stops the MHI channel. After the last call to release() if driver is removed uci reference count becomes 0 and uci object is cleaned up. - Use separate uci channel read and write lock to fine grain locking between reader and writer. - Use uci device lock to synchronize open, release and driver remove. - Optimize for downlink only or uplink only UCI device. V6: - Moved uci.c to mhi directory. - Updated Kconfig to add module information. - Updated Makefile to rename uci object file name as mhi_uci - Removed kref for open count V5: - Removed mhi_uci_drv structure. - Used idr instead of creating global list of uci devices. - Used kref instead of local ref counting for uci device and open count. - Removed unlikely macro. V4: - Fix locking to protect proper struct members. - Updated documentation describing uci client driver use cases. - Fixed uci ref counting in mhi_uci_open for error case. - Addressed style related review comments. V3: Added documentation for MHI UCI driver. V2: Added mutex lock to prevent multiple readers to access same mhi buffer which can result into use after free. Hemant Kumar (4): bus: mhi: core: Add helper API to return number of free TREs bus: mhi: core: Move MHI_MAX_MTU to external header file docs: Add documentation for userspace client interface bus: mhi: Add userspace client interface driver Documentation/mhi/index.rst | 1 + Documentation/mhi/uci.rst | 83 + drivers/bus/mhi/Kconfig | 13 + drivers/bus/mhi/Makefile| 4 + drivers/bus/mhi/core/internal.h | 1 - drivers/bus/mhi/core/main.c | 12 + drivers/bus/mhi/uci.c | 658 include/linux/mhi.h | 12 + 8 files changed, 783 insertions(+), 1 deletion(-) create mode 100644 Documentation/mhi/uci.rst create mode 100644 drivers/bus/mhi/uci.c -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project
Re: [PATCH 0/3] drm/amd/display: Fix kernel panic by breakpoint
On 2020-10-23 03:46, Takashi Iwai wrote: > Hi, > > the amdgpu driver's ASSERT_CRITICAL() macro calls the > kgdb_breakpoing() even if no debug option is set, and this leads to a > kernel panic on distro kernels. The first two patches are the > oneliner fixes for those, while the last one is the cleanup of those > debug macros. This looks like good work and solid. Hopefully it gets picked up. Regards, Luben > > > Takashi > > === > > Takashi Iwai (3): > drm/amd/display: Fix kernel panic by dal_gpio_open() error > drm/amd/display: Don't invoke kgdb_breakpoint() unconditionally > drm/amd/display: Clean up debug macros > > drivers/gpu/drm/amd/display/Kconfig | 1 + > drivers/gpu/drm/amd/display/dc/gpio/gpio_base.c | 4 +-- > drivers/gpu/drm/amd/display/dc/os_types.h | 33 > + > 3 files changed, 15 insertions(+), 23 deletions(-) >
