Re: [PATCH v4 2/3] dt-bindings: mtd: Add a property to declare secure regions in NAND chips
On Mon, 8 Mar 2021 19:01:34 +0530 Manivannan Sadhasivam wrote: > On Mon, Mar 08, 2021 at 10:10:59AM +0100, Boris Brezillon wrote: > > On Mon, 8 Mar 2021 11:14:46 +0530 > > Manivannan Sadhasivam wrote: > > > > > On a typical end product, a vendor may choose to secure some regions in > > > the NAND memory which are supposed to stay intact between FW upgrades. > > > The access to those regions will be blocked by a secure element like > > > Trustzone. So the normal world software like Linux kernel should not > > > touch these regions (including reading). > > > > > > So let's add a property for declaring such secure regions so that the > > > drivers can skip touching them. > > > > > > Signed-off-by: Manivannan Sadhasivam > > > --- > > > Documentation/devicetree/bindings/mtd/nand-controller.yaml | 7 +++ > > > 1 file changed, 7 insertions(+) > > > > > > diff --git a/Documentation/devicetree/bindings/mtd/nand-controller.yaml > > > b/Documentation/devicetree/bindings/mtd/nand-controller.yaml > > > index d0e422f4b3e0..15a674bedca3 100644 > > > --- a/Documentation/devicetree/bindings/mtd/nand-controller.yaml > > > +++ b/Documentation/devicetree/bindings/mtd/nand-controller.yaml > > > @@ -143,6 +143,13 @@ patternProperties: > > >Ready/Busy pins. Active state refers to the NAND ready state > > > and > > >should be set to GPIOD_ACTIVE_HIGH unless the signal is > > > inverted. > > > > > > + secure-regions: > > > +$ref: /schemas/types.yaml#/definitions/uint32-matrix > > > +description: > > > + Regions in the NAND chip which are protected using a secure > > > element > > > + like Trustzone. This property contains the start address and > > > size of > > > + the secure regions present. > > > + > > > > Since you declare this as a generic property, I think it'd be simpler > > to do the check at the core level. > > > > Hmm, so have the parsing logic in qcom driver and check in core or both > parsing > and check in core? Both in the core.
Re: [PATCH v2 1/2] mm: disable LRU pagevec during the migration temporarily
Hi Minchan,
I love your patch! Perhaps something to improve:
[auto build test WARNING on linux/master]
[also build test WARNING on linus/master v5.12-rc2 next-20210309]
[cannot apply to hnaz-linux-mm/master]
[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/Minchan-Kim/mm-disable-LRU-pagevec-during-the-migration-temporarily/20210309-131826
base: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
144c79ef33536b4ecb4951e07dbc1f2b7fa99d32
config: arm64-randconfig-r023-20210308 (attached as .config)
compiler: clang version 13.0.0 (https://github.com/llvm/llvm-project
820f508b08d7c94b2dd7847e9710d2bc36d3dd45)
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://github.com/0day-ci/linux/commit/e746db1a2ab13441890fa2cad8604bbec190b401
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review
Minchan-Kim/mm-disable-LRU-pagevec-during-the-migration-temporarily/20210309-131826
git checkout e746db1a2ab13441890fa2cad8604bbec190b401
# 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 >>):
mm/swap.c:244:4: error: implicit declaration of function
'lru_cache_disabled' [-Werror,-Wimplicit-function-declaration]
lru_cache_disabled())
^
mm/swap.c:244:4: note: did you mean 'lru_cache_disable'?
include/linux/swap.h:342:13: note: 'lru_cache_disable' declared here
extern void lru_cache_disable(void);
^
>> mm/swap.c:743:6: warning: no previous prototype for function
>> '__lru_add_drain_all' [-Wmissing-prototypes]
void __lru_add_drain_all(bool force_all_cpus)
^
mm/swap.c:743:1: note: declare 'static' if the function is not intended to
be used outside of this translation unit
void __lru_add_drain_all(bool force_all_cpus)
^
static
mm/swap.c:858:6: error: conflicting types for 'lru_cache_disabled'
bool lru_cache_disabled(void)
^
mm/swap.c:244:4: note: previous implicit declaration is here
lru_cache_disabled())
^
1 warning and 2 errors generated.
vim +/__lru_add_drain_all +743 mm/swap.c
742
> 743 void __lru_add_drain_all(bool force_all_cpus)
744 {
745 /*
746 * lru_drain_gen - Global pages generation number
747 *
748 * (A) Definition: global lru_drain_gen = x implies that all
generations
749 * 0 < n <= x are already *scheduled* for draining.
750 *
751 * This is an optimization for the highly-contended use case
where a
752 * user space workload keeps constantly generating a flow of
pages for
753 * each CPU.
754 */
755 static unsigned int lru_drain_gen;
756 static struct cpumask has_work;
757 static DEFINE_MUTEX(lock);
758 unsigned cpu, this_gen;
759
760 /*
761 * Make sure nobody triggers this path before mm_percpu_wq is
fully
762 * initialized.
763 */
764 if (WARN_ON(!mm_percpu_wq))
765 return;
766
767 /*
768 * Guarantee pagevec counter stores visible by this CPU are
visible to
769 * other CPUs before loading the current drain generation.
770 */
771 smp_mb();
772
773 /*
774 * (B) Locally cache global LRU draining generation number
775 *
776 * The read barrier ensures that the counter is loaded before
the mutex
777 * is taken. It pairs with smp_mb() inside the mutex critical
section
778 * at (D).
779 */
780 this_gen = smp_load_acquire(_drain_gen);
781
782 mutex_lock();
783
784 /*
785 * (C) Exit the draining operation if a newer generation, from
another
786 * lru_add_drain_all(), was already scheduled for draining.
Check (A).
787 */
788 if (unlikely(this_gen != lru_drain_gen && !force_all_cpus))
789 goto done;
790
791 /*
792 * (D) Increment global generation number
793 *
794 *
Re: [PATCH v2 4/7] CMDLINE: powerpc: convert to generic builtin command line
Le 09/03/2021 à 01:02, Daniel Walker a écrit :
This updates the powerpc code to use the CONFIG_GENERIC_CMDLINE
option.
Cc: xe-linux-exter...@cisco.com
Signed-off-by: Ruslan Ruslichenko
Signed-off-by: Ruslan Bilovol
Signed-off-by: Daniel Walker
---
arch/powerpc/Kconfig| 37 +
arch/powerpc/kernel/prom.c | 1 +
arch/powerpc/kernel/prom_init.c | 35 ++-
3 files changed, 23 insertions(+), 50 deletions(-)
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 107bb4319e0e..276b06d5c961 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -167,6 +167,7 @@ config PPC
select EDAC_SUPPORT
select GENERIC_ATOMIC64 if PPC32
select GENERIC_CLOCKEVENTS_BROADCASTif SMP
+ select GENERIC_CMDLINE
select GENERIC_CMOS_UPDATE
select GENERIC_CPU_AUTOPROBE
select GENERIC_CPU_VULNERABILITIES if PPC_BARRIER_NOSPEC
@@ -906,42 +907,6 @@ config PPC_DENORMALISATION
Add support for handling denormalisation of single precision
values. Useful for bare metal only. If unsure say Y here.
-config CMDLINE
- string "Initial kernel command string"
- default ""
- help
- On some platforms, there is currently no way for the boot loader to
- pass arguments to the kernel. For these platforms, you can supply
- some command-line options at build time by entering them here. In
- most cases you will need to specify the root device here.
-
-choice
- prompt "Kernel command line type" if CMDLINE != ""
- default CMDLINE_FROM_BOOTLOADER
-
-config CMDLINE_FROM_BOOTLOADER
- bool "Use bootloader kernel arguments if available"
- help
- Uses the command-line options passed by the boot loader. If
- the boot loader doesn't provide any, the default kernel command
- string provided in CMDLINE will be used.
-
-config CMDLINE_EXTEND
- bool "Extend bootloader kernel arguments"
- help
- The command-line arguments provided by the boot loader will be
- appended to the default kernel command string.
-
-config CMDLINE_FORCE
- bool "Always use the default kernel command string"
- help
- Always use the default kernel command string, even if the boot
- loader passes other arguments to the kernel.
- This is useful if you cannot or don't want to change the
- command-line options your boot loader passes to the kernel.
-
-endchoice
-
config EXTRA_TARGETS
string "Additional default image types"
help
diff --git a/arch/powerpc/kernel/prom.c b/arch/powerpc/kernel/prom.c
index ae3c41730367..96d0a01be1b4 100644
--- a/arch/powerpc/kernel/prom.c
+++ b/arch/powerpc/kernel/prom.c
@@ -27,6 +27,7 @@
#include
#include
#include
+#include
Why is this needed in prom.c ?
#include
#include
#include
diff --git a/arch/powerpc/kernel/prom_init.c b/arch/powerpc/kernel/prom_init.c
index e9d4eb6144e1..657241534d69 100644
--- a/arch/powerpc/kernel/prom_init.c
+++ b/arch/powerpc/kernel/prom_init.c
@@ -27,6 +27,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -242,15 +243,6 @@ static int __init prom_strcmp(const char *cs, const char
*ct)
return 0;
}
-static char __init *prom_strcpy(char *dest, const char *src)
-{
- char *tmp = dest;
-
- while ((*dest++ = *src++) != '\0')
- /* nothing */;
- return tmp;
-}
-
This game with prom_strcpy() should go a separate preceeding patch.
Also, it looks like checkpatch.pl recommends to use strscpy() instead of
strlcpy().
static int __init prom_strncmp(const char *cs, const char *ct, size_t count)
{
unsigned char c1, c2;
@@ -276,6 +268,20 @@ static size_t __init prom_strlen(const char *s)
return sc - s;
}
+static size_t __init prom_strlcpy(char *dest, const char *src, size_t size)
+{
+ size_t ret = prom_strlen(src);
+
+ if (size) {
+ size_t len = (ret >= size) ? size - 1 : ret;
+
+ memcpy(dest, src, len);
+ dest[len] = '\0';
+ }
+ return ret;
+}
+
+
static int __init prom_memcmp(const void *cs, const void *ct, size_t count)
{
const unsigned char *su1, *su2;
@@ -304,6 +310,7 @@ static char __init *prom_strstr(const char *s1, const char
*s2)
return NULL;
}
+#ifdef GENERIC_CMDLINE_NEED_STRLCAT
static size_t __init prom_strlcat(char *dest, const char *src, size_t count)
{
size_t dsize = prom_strlen(dest);
@@ -323,6 +330,7 @@ static size_t __init prom_strlcat(char *dest, const char
*src, size_t count)
return res;
}
+#endif
#ifdef CONFIG_PPC_PSERIES
static int __init prom_strtobool(const char *s, bool *res)
@@ -775,12 +783,11 @@ static void __init early_cmdline_parse(void)
prom_cmd_line[0] = 0;
p =
Re: [PATCH v4 4/5] perf stat: Enable iostat mode for x86 platforms
Hi Alexander,
On 2021/2/3 21:58, Alexander Antonov wrote:
This functionality is based on recently introduced sysfs attributes
for Intel® Xeon® Scalable processor family (code name Skylake-SP):
Commit bb42b3d39781 ("perf/x86/intel/uncore: Expose an Uncore unit to
IIO PMON mapping")
Mode is intended to provide four I/O performance metrics in MB per each
PCIe root port:
- Inbound Read: I/O devices below root port read from the host memory
- Inbound Write: I/O devices below root port write to the host memory
- Outbound Read: CPU reads from I/O devices below root port
- Outbound Write: CPU writes to I/O devices below root port
Each metric requiries only one uncore event which increments at every 4B
transfer in corresponding direction. The formulas to compute metrics
are generic:
#EventCount * 4B / (1024 * 1024)
Signed-off-by: Alexander Antonov
---
tools/perf/Documentation/perf-iostat.txt | 88 ++
tools/perf/Makefile.perf | 5 +-
tools/perf/arch/x86/util/Build | 1 +
tools/perf/arch/x86/util/iostat.c| 345 +++
tools/perf/command-list.txt | 1 +
tools/perf/perf-iostat.sh| 12 +
6 files changed, 451 insertions(+), 1 deletion(-)
create mode 100644 tools/perf/Documentation/perf-iostat.txt
create mode 100644 tools/perf/perf-iostat.sh
diff --git a/tools/perf/Documentation/perf-iostat.txt
b/tools/perf/Documentation/perf-iostat.txt
new file mode 100644
index ..165176944031
--- /dev/null
+++ b/tools/perf/Documentation/perf-iostat.txt
@@ -0,0 +1,88 @@
+perf-iostat(1)
+===
+
+NAME
+
+perf-iostat - Show I/O performance metrics
+
+SYNOPSIS
+
+[verse]
+'perf iostat' list
+'perf iostat' -- []
+
+DESCRIPTION
+---
+Mode is intended to provide four I/O performance metrics per each PCIe root
port:
+
+- Inbound Read - I/O devices below root port read from the host memory, in MB
+
+- Inbound Write - I/O devices below root port write to the host memory, in MB
+
+- Outbound Read - CPU reads from I/O devices below root port, in MB
+
+- Outbound Write - CPU writes to I/O devices below root port, in MB
+
+OPTIONS
+---
+...::
+ Any command you can specify in a shell.
+
+list::
+ List all PCIe root ports.
I noticed that "iostat" commond and cmd_iostat() callback function is
not registered in cmd_struct in perf.c. So I think "perf iostat list"
perhaps can not work properly.
I also test this patchset on x86 platform, and here is the log:
root@ubuntu:/home/lq# ./perf iostat list
perf: 'iostat' is not a perf-command. See 'perf --help'.
root@ubuntu:/home/lq# ./perf stat --iostat
^C
Performance counter stats for 'system wide':
port Inbound Read(MB)Inbound Write(MB)Outbound
Read(MB) Outbound Write(MB)
:00000
0
:80000
0
:17000
0
:85000
0
:3a000
0
:ae000
0
:5d000
0
:d7000
0
0.611303832 seconds time elapsed
root@ubuntu:/home/lq# ./perf stat --iostat=:17
^C
Performance counter stats for 'system wide':
port Inbound Read(MB)Inbound Write(MB)Outbound
Read(MB) Outbound Write(MB)
:17000
0
0.521317572 seconds time elapsed
So how does following perf iostat list work, did I miss something?
Thanks,
Qi
+
+::
+ Select the root ports for monitoring. Comma-separated list is supported.
+
+EXAMPLES
+
+
+1. List all PCIe root ports (example for 2-S platform):
+
+ $ perf iostat list
+ S0-uncore_iio_0<:00>
+ S1-uncore_iio_0<:80>
+ S0-uncore_iio_1<:17>
+ S1-uncore_iio_1<:85>
+ S0-uncore_iio_2<:3a>
+ S1-uncore_iio_2<:ae>
+ S0-uncore_iio_3<:5d>
+ S1-uncore_iio_3<:d7>
[PATCH] selftests/timers: remove unneeded semicolon
Fix the following coccicheck warnings: ./tools/testing/selftests/timers/nanosleep.c:75:2-3: Unneeded semicolon Reported-by: Abaci Robot Signed-off-by: Jiapeng Chong --- tools/testing/selftests/timers/nanosleep.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/testing/selftests/timers/nanosleep.c b/tools/testing/selftests/timers/nanosleep.c index 71b5441..433a096 100644 --- a/tools/testing/selftests/timers/nanosleep.c +++ b/tools/testing/selftests/timers/nanosleep.c @@ -72,7 +72,7 @@ char *clockstring(int clockid) return "CLOCK_BOOTTIME_ALARM"; case CLOCK_TAI: return "CLOCK_TAI"; - }; + } return "UNKNOWN_CLOCKID"; } -- 1.8.3.1
Re: [PATCH 3/3] power: supply: max8997_charger: Switch to new binding
On Mon, 1 Feb 2021 19:03:35 +0100, Krzysztof Kozlowski wrote:
> On Mon, Feb 01, 2021 at 09:26:42AM +, Timon Baetz wrote:
> > On Sun, 31 Jan 2021 18:28:40 +0100, Krzysztof Kozlowski wrote:
> > > On Sat, Jan 30, 2021 at 05:30:14PM +, Timon Baetz wrote:
> > > > Get regulator from parent device's node and extcon by name.
> > > >
> > > > Signed-off-by: Timon Baetz
> > > > ---
> > > > drivers/power/supply/max8997_charger.c | 12
> > > > 1 file changed, 8 insertions(+), 4 deletions(-)
> > > >
> > > > diff --git a/drivers/power/supply/max8997_charger.c
> > > > b/drivers/power/supply/max8997_charger.c
> > > > index 321bd6b8ee41..625d8cc4312a 100644
> > > > --- a/drivers/power/supply/max8997_charger.c
> > > > +++ b/drivers/power/supply/max8997_charger.c
> > > > @@ -168,6 +168,7 @@ static int max8997_battery_probe(struct
> > > > platform_device *pdev)
> > > > int ret = 0;
> > > > struct charger_data *charger;
> > > > struct max8997_dev *iodev = dev_get_drvdata(pdev->dev.parent);
> > > > + struct device_node *np = pdev->dev.of_node;
> > > > struct i2c_client *i2c = iodev->i2c;
> > > > struct max8997_platform_data *pdata = iodev->pdata;
> > > > struct power_supply_config psy_cfg = {};
> > > > @@ -237,20 +238,23 @@ static int max8997_battery_probe(struct
> > > > platform_device *pdev)
> > > > return PTR_ERR(charger->battery);
> > > > }
> > > >
> > > > + // grab regulator from parent device's node
> > > > + pdev->dev.of_node = iodev->dev->of_node;
> > > > charger->reg = devm_regulator_get_optional(>dev,
> > > > "charger");
> > > > + pdev->dev.of_node = np;
> > >
> > > I think the device does not have its own node anymore. Or did I miss
> > > something?
> >
> > The idea is to reset of_node to whatever it was before (NULL) and basically
> > leave the device unchanged. Probe might run again because of deferral.
>
> Good point.
>
> >
> > > > if (IS_ERR(charger->reg)) {
> > > > if (PTR_ERR(charger->reg) == -EPROBE_DEFER)
> > > > return -EPROBE_DEFER;
> > > > dev_info(>dev, "couldn't get charger
> > > > regulator\n");
> > > > }
> > > > - charger->edev = extcon_get_edev_by_phandle(>dev, 0);
> > > > - if (IS_ERR(charger->edev)) {
> > > > - if (PTR_ERR(charger->edev) == -EPROBE_DEFER)
> > > > + charger->edev = extcon_get_extcon_dev("max8997-muic");
> > > > + if (IS_ERR_OR_NULL(charger->edev)) {
> > > > + if (!charger->edev)
> > >
> > > Isn't NULL returned when there is simply no extcon? It's different than
> > > deferred probe. Returning here EPROBE_DEFER might lead to infinite probe
> > > tries (on every new device probe) instead of just failing it.
> >
> > extcon_get_extcon_dev() just loops through all registered extcon devices
> > and compared names. It will return NULL when "max8997-muic" isn't
> > registered yet. extcon_get_extcon_dev() never returns EPROBE_DEFER so
> > checking for NULL seems to be the only way. Other drivers using that
> > function also do NULL check and return EPROBE_DEFER.
>
> Indeed, thanks for clarification. Looks good:
>
> Reviewed-by: Krzysztof Kozlowski
Is something blocking this from being accepted?
Timon
Re: [PATCH] x86/perf: Fix guest_get_msrs static call if there is no PMU
On Mon, Mar 08, 2021 at 12:40:44PM -0800, Sean Christopherson wrote: > On Mon, Mar 08, 2021, Peter Zijlstra wrote: > > Given the one user in atomic_switch_perf_msrs() that should work because > > it doesn't seem to care about nr_msrs when !msrs. > > Uh, that commit quite cleary says: D0h! I got static_call_cond() and __static_call_return0 mixed up. Anyway, let me see if I can make something work here.
Re: [PATCH v2 3/7] powerpc: convert config files to generic cmdline
Le 09/03/2021 à 01:02, Daniel Walker a écrit : This is a scripted mass convert of the config files to use the new generic cmdline. There is a bit of a trim effect here. It would seems that some of the config haven't been trimmed in a while. If you do that in a separate patch, you loose bisectability. I think it would have been better to do things in a different way, more or less like I did in my series: 1/ Provide GENERIC cmdline at the same functionnality level as what is spread in the different architectures 2/ Convert architectures to the generic with least churn. 3/ Add new features to the generic The bash script used to convert is as follows, if [[ -z "$1" || -z "$2" ]]; then echo "Two arguments are needed." exit 1 fi mkdir $1 cp $2 $1/.config sed -i 's/CONFIG_CMDLINE=/CONFIG_CMDLINE_BOOL=y\nCONFIG_CMDLINE_PREPEND=/g' $1/.config This is not correct. By default, on powerpc the provided command line is used only if the bootloader doesn't provide one. Otherwise: - the builtin command line is appended to the one provided by the bootloader if CONFIG_CMDLINE_EXTEND is selected - the builtin command line replaces to the one provided by the bootloader if CONFIG_CMDLINE_FORCE is selected make ARCH=$1 O=$1 olddefconfig make ARCH=$1 O=$1 savedefconfig cp $1/defconfig $2 rm -Rf $1 Cc: xe-linux-exter...@cisco.com Signed-off-by: Daniel Walker --- arch/powerpc/configs/44x/fsp2_defconfig | 33 +-- arch/powerpc/configs/44x/iss476-smp_defconfig | 25 +++--- arch/powerpc/configs/44x/warp_defconfig | 17 +- arch/powerpc/configs/holly_defconfig | 13 arch/powerpc/configs/mvme5100_defconfig | 23 ++--- arch/powerpc/configs/skiroot_defconfig| 12 +++ arch/powerpc/configs/storcenter_defconfig | 18 -- 7 files changed, 66 insertions(+), 75 deletions(-) diff --git a/arch/powerpc/configs/44x/fsp2_defconfig b/arch/powerpc/configs/44x/fsp2_defconfig index 30845ce0885a..4993db054589 100644 --- a/arch/powerpc/configs/44x/fsp2_defconfig +++ b/arch/powerpc/configs/44x/fsp2_defconfig @@ -1,8 +1,6 @@ -CONFIG_44x=y # CONFIG_SWAP is not set CONFIG_SYSVIPC=y # CONFIG_CROSS_MEMORY_ATTACH is not set -# CONFIG_FHANDLE is not set CONFIG_NO_HZ=y CONFIG_HIGH_RES_TIMERS=y CONFIG_IKCONFIG=y @@ -13,24 +11,25 @@ CONFIG_BLK_DEV_INITRD=y # CONFIG_RD_XZ is not set # CONFIG_RD_LZO is not set # CONFIG_RD_LZ4 is not set +# CONFIG_FHANDLE is not set CONFIG_KALLSYMS_ALL=y CONFIG_BPF_SYSCALL=y CONFIG_EMBEDDED=y CONFIG_PROFILING=y -CONFIG_OPROFILE=y -CONFIG_MODULES=y -CONFIG_MODULE_UNLOAD=y -# CONFIG_BLK_DEV_BSG is not set +CONFIG_CMDLINE_BOOL=y +CONFIG_CMDLINE_PREPEND="ip=on rw" +CONFIG_44x=y CONFIG_PPC_47x=y # CONFIG_EBONY is not set CONFIG_FSP2=y CONFIG_476FPE_ERR46=y -CONFIG_SWIOTLB=y CONFIG_KEXEC=y CONFIG_CRASH_DUMP=y -CONFIG_CMDLINE="ip=on rw" # CONFIG_SUSPEND is not set -# CONFIG_PCI is not set +CONFIG_OPROFILE=y +CONFIG_MODULES=y +CONFIG_MODULE_UNLOAD=y +# CONFIG_BLK_DEV_BSG is not set CONFIG_NET=y CONFIG_PACKET=y CONFIG_UNIX=y @@ -47,14 +46,12 @@ CONFIG_MTD=y CONFIG_MTD_BLOCK=y CONFIG_MTD_JEDECPROBE=y CONFIG_MTD_CFI_AMDSTD=y -CONFIG_MTD_PHYSMAP_OF=y CONFIG_BLK_DEV_RAM=y CONFIG_BLK_DEV_RAM_SIZE=35000 # CONFIG_SCSI_PROC_FS is not set CONFIG_BLK_DEV_SD=y # CONFIG_SCSI_LOWLEVEL is not set CONFIG_ATA=y -# CONFIG_SATA_PMP is not set # CONFIG_ATA_SFF is not set CONFIG_NETDEVICES=y CONFIG_BONDING=m @@ -63,7 +60,6 @@ CONFIG_IBM_EMAC=m # CONFIG_SERIO is not set # CONFIG_VT is not set # CONFIG_LEGACY_PTYS is not set -# CONFIG_DEVMEM is not set CONFIG_SERIAL_8250=y CONFIG_SERIAL_8250_CONSOLE=y CONFIG_SERIAL_8250_NR_UARTS=32 @@ -72,6 +68,7 @@ CONFIG_SERIAL_8250_EXTENDED=y CONFIG_SERIAL_8250_SHARE_IRQ=y CONFIG_SERIAL_OF_PLATFORM=y # CONFIG_HW_RANDOM is not set +# CONFIG_DEVMEM is not set CONFIG_I2C=y CONFIG_I2C_IBM_IIC=y CONFIG_PTP_1588_CLOCK=y @@ -107,6 +104,12 @@ CONFIG_NFS_V3_ACL=y CONFIG_NFS_V4=y CONFIG_ROOT_NFS=y CONFIG_NLS_DEFAULT="n" +CONFIG_CRYPTO_CBC=y +CONFIG_CRYPTO_ECB=y +CONFIG_CRYPTO_PCBC=y +CONFIG_CRYPTO_MD5=y +CONFIG_CRYPTO_DES=y +# CONFIG_CRYPTO_HW is not set CONFIG_XZ_DEC=y CONFIG_PRINTK_TIME=y CONFIG_MESSAGE_LOGLEVEL_DEFAULT=3 @@ -114,9 +117,3 @@ CONFIG_DYNAMIC_DEBUG=y CONFIG_DEBUG_INFO=y CONFIG_MAGIC_SYSRQ=y CONFIG_DETECT_HUNG_TASK=y -CONFIG_CRYPTO_CBC=y -CONFIG_CRYPTO_ECB=y -CONFIG_CRYPTO_PCBC=y -CONFIG_CRYPTO_MD5=y -CONFIG_CRYPTO_DES=y -# CONFIG_CRYPTO_HW is not set diff --git a/arch/powerpc/configs/44x/iss476-smp_defconfig b/arch/powerpc/configs/44x/iss476-smp_defconfig index 2c3834eebca3..b8d97061517a 100644 --- a/arch/powerpc/configs/44x/iss476-smp_defconfig +++ b/arch/powerpc/configs/44x/iss476-smp_defconfig @@ -1,5 +1,3 @@ -CONFIG_44x=y -CONFIG_SMP=y CONFIG_SYSVIPC=y CONFIG_POSIX_MQUEUE=y CONFIG_LOG_BUF_SHIFT=14 @@ -7,20 +5,22 @@ CONFIG_BLK_DEV_INITRD=y
[PATCH] scsi: ufs: Remove unnecessary null checks in ufshcd_find_max_sup_active_icc_level()
From: Yue Hu Since vcc/vccq/vccq2 have already been null checked before using. Signed-off-by: Yue Hu --- drivers/scsi/ufs/ufshcd.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c index 7b3267e..f941bc3 100644 --- a/drivers/scsi/ufs/ufshcd.c +++ b/drivers/scsi/ufs/ufshcd.c @@ -7145,19 +7145,19 @@ static u32 ufshcd_find_max_sup_active_icc_level(struct ufs_hba *hba, goto out; } - if (hba->vreg_info.vcc && hba->vreg_info.vcc->max_uA) + if (hba->vreg_info.vcc->max_uA) icc_level = ufshcd_get_max_icc_level( hba->vreg_info.vcc->max_uA, POWER_DESC_MAX_ACTV_ICC_LVLS - 1, _buf[PWR_DESC_ACTIVE_LVLS_VCC_0]); - if (hba->vreg_info.vccq && hba->vreg_info.vccq->max_uA) + if (hba->vreg_info.vccq->max_uA) icc_level = ufshcd_get_max_icc_level( hba->vreg_info.vccq->max_uA, icc_level, _buf[PWR_DESC_ACTIVE_LVLS_VCCQ_0]); - if (hba->vreg_info.vccq2 && hba->vreg_info.vccq2->max_uA) + if (hba->vreg_info.vccq2->max_uA) icc_level = ufshcd_get_max_icc_level( hba->vreg_info.vccq2->max_uA, icc_level, -- 1.9.1
Re: [PATCH 1/2] dt-bindings: misc: add binding for generic ripple counter
On 08/03/2021 22.38, Rob Herring wrote: > On Mon, Mar 08, 2021 at 09:02:29PM +0100, Rasmus Villemoes wrote: >> On 08/03/2021 18.21, Rob Herring wrote: >>> On Fri, Feb 26, 2021 at 03:14:10PM +0100, Rasmus Villemoes wrote: While a ripple counter can not usually be interfaced with (directly) from software, it may still be a crucial component in a board layout. To prevent its input clock from being disabled by the clock core because it apparently has no consumer, one needs to be able to represent that consumer in DT. >>> >>> I'm okay with this as it is describing h/w, but we already >>> 'protected-clocks' property which should work. >> >> Hm. Unless >> https://lore.kernel.org/lkml/20200903040015.5627-2-sam...@sholland.org/ >> gets merged, I don't see how this would work out-of-the-box. > > Hum, no really clear what the hold up is there given it seems it was > asked for. Letting it sit for 5 months is certainly not the way > to get it merged. Anyways, that's the kernel's problem, not mine as far > as DT bindings are concerned. > >> >> Note that I sent a completely different v2, which made the gpio-wdt the >> clock consumer based on feedback from Guenter and Arnd, but that v2 >> isn't suitable for our case because it post-poned handling of the >> watchdog till after i2c is ready, which is too late. Somewhat similar to >> https://lore.kernel.org/lkml/20210222171247.97609-2-sebastian.reic...@collabora.com/ >> it seems. > > Now at that one in my queue... I think 'protected-clocks' is the best > way to avoid any driver probe ordering issues. It's the only thing that > really captures don't turn off this clock. Agreed, and I did start by looking for a generic way to mark the clock as either "hands off, kernel" (relying on the bootloader to enable it), or better "make sure it's enabled". The closest I found was of_clk_detect_critical(), but the comment above that one says not to use it, so adding a call to some random RTC driver to support the clock-critical property just for my use case didn't seem like the right way to go. I didn't know about protected-clocks until you mentioned it, and it does seem to be the right way to handle these situations (which are apparently more common than I thought). The ripple counter binding > doesn't really capture that or what it is related to. Agreed, it was a "hail mary" and why I explained what I was really trying to achieve in the cover letter. Also, the > ripple-counter driver could be a module and you'd still have the same > issue as v2. Well, not quite. First of all, for a board like this, one always uses a tailor-made .config, where one would never set that to be a module (and even more obviously one wouldn't make the gpio-wdt driver a module). Second, it wouldn't be the same issue as v2. Rather, if the clock only gets enabled later when the ripple counter module would get loaded, there would be a period of time where the watchdog was rendered useless - the problem with v2 was that the watchdog wouldn't be petted in time, so the board would be reset before it booted completely. +Required properties: +- compatible: Must be "linux,ripple-ctr". >>> >>> Nothing linux specific about this. >> >> True, but I was following the lead of the existing gpio-wdt binding. Is >> there some other "vendor" name one can and should use for completely >> generic and simple components like these? "generic"? > > Most 'generic' and GPIO based interfaces have no vendor prefix. Ah, I see. Can we add just plain "wdt-gpio" to the gpio-wdt binding, and deprecate the "linux,wdt-gpio"? It's a little awkward to handle a "linux,wdt-gpio" compatible in a U-Boot driver. Rasmus
Re: [PATCH v6 1/1] iio/scmi: Adding support for IIO SCMI Based Sensors
Hi On Tue, Mar 09, 2021 at 06:37:27AM +, Sudeep Holla wrote: > On Mon, Mar 08, 2021 at 07:48:41PM +, Jonathan Cameron wrote: > > On Mon, 8 Mar 2021 04:28:42 + > > Sudeep Holla wrote: > > > > > Hi Jonathan, > > > > > > On Tue, Feb 23, 2021 at 10:30:37AM -0800, Jyoti Bhayana wrote: > > > > Hi Jonathan, > > > > > > > > Thanks for the detailed and careful review of this patch. Good to hear > > > > that v7 is not required. Please find below answers to your > > > > questions. Looking forward to seeing this patch merged in the next > > > > cycle. Thanks for your help in making this happen. > > > > > > > > > > Any update on this ? Please share the branch with is patch so that I > > > can pull and ask Cristian to make his changes on top. > > Running a bit behind at the moment. > > > > No worries. > > > Anyhow, there should now be an ib-iio-scmi-5.12-rc1 branch > > on https://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio.git > > > > Thanks > > > Includes making the various long long local variables explicitly > > s64 and u64 as relevant. > > > > Based on the rc1 that eats babies so handle with care :) > > > > > > > I've also merge this into the togreg branch of iio.git. > > As explained above that wasn't entirely trivial so Jyoti > > please take a quick look and check that changes are fine. > > Pushed out as testing to let the autobuilders poke at it. > > Assuming they don't find anything, it should be fine > > for Sudeep to merge that ib and everything will unwind > > nicely in Linus' tree next cycle. > > > > Hope so. > > > There is a bit of an ongoing discussion of an earlier patch > > in the IIO tree, so I might end up redoing this merge > > if I need to rebase to sort that out, but I'll make sure > > the diff is the same (git ID might change). > > > > I can wait for a week or 2 if you think things will settle down by then. > We can avoid 2 different git IDs if possible. The main intention was to > give some reference to Cristian to rebase/post his series. I am all > fine to wait for a week or 2 for final branch. > In the meantime, I've anyway started reworking just based on -rc2 and barely cherry-picked Jyoti v6 on top of it just to able to start porting early the iiodev to the new SCMI API and be able to fully test it out (no problems so far); I will finally rebase on whatever final base branch Sudeep will pick but as Sudeep said I can wait, since I'm not expecting so much work still to do in that final rebase to -rc1-smh-final (...last famous words o_O) Side question for Jyoti/Jonathan, for basic testing of this IIO SCMI driver (given that I'm not really familiar with IIO and I have not a full Android CTS/VTS suite to use it for testing), I'm doing something like: (debian-arm64)root@debarm64:~# cd /sys/bus/iio/devices/iio\:device0 (debian-arm64)root@debarm64:/sys/bus/iio/devices/iio:device0# echo 1 > scan_elements/in_accel_x_en (debian-arm64)root@debarm64:/sys/bus/iio/devices/iio:device0# echo 1 > scan_elements/in_accel_y_en (debian-arm64)root@debarm64:/sys/bus/iio/devices/iio:device0# echo 1 > scan_elements/in_accel_z_en (debian-arm64)root@debarm64:/sys/bus/iio/devices/iio:device0# echo 1 > scan_elements/in_timestamp_en (debian-arm64)root@debarm64:/sys/bus/iio/devices/iio:device0# echo 1 > buffer/enable && cat /dev/iio\:device0 | xxd : 08da 10da 0010: 18da 00b8 d3a0 c09b 6a16 ..j. 0020: 08da 10da 0030: 18da 0082 6edc c09b 6a16 ..n...j. 0040: 08da 10da 0050: 18da 004c 0918 c19b 6a16 .Lj. 0060: 08da 10da 0070: 18da 0016 a453 c19b 6a16 ...S..j. 0080: 08da 10da 0090: 18da 00aa d9ca c19b 6a16 ..j. 00a0: 08da 10da 00b0: 18da 0074 7406 c29b 6a16 .tt...j. ^C (debian-arm64)root@debarm64:/sys/bus/iio/devices/iio:device0# echo 0 > buffer/enable (plus a bunch of DEBUG in my series to track notifs flows...) Is this any good ? Thanks Cristian > -- > Regards, > Sudeep
Re: [PATCH v2 2/7] CMDLINE: drivers: of: ifdef out cmdline section
Le 09/03/2021 à 01:02, Daniel Walker a écrit :
It looks like there's some seepage of cmdline stuff into
the generic device tree code. This conflicts with the
generic cmdline implementation so I remove it in the case
when that's enabled.
Cc: xe-linux-exter...@cisco.com
Signed-off-by: Ruslan Ruslichenko
Signed-off-by: Daniel Walker
---
drivers/of/fdt.c | 12
1 file changed, 12 insertions(+)
diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
index feb0f2d67fc5..e25240d84632 100644
--- a/drivers/of/fdt.c
+++ b/drivers/of/fdt.c
@@ -25,6 +25,7 @@
#include
#include
#include
+#include
#include /* for COMMAND_LINE_SIZE */
#include
@@ -1050,6 +1051,16 @@ int __init early_init_dt_scan_chosen(unsigned long node,
const char *uname,
/* Retrieve command line */
p = of_get_flat_dt_prop(node, "bootargs", );
+
+#ifdef CONFIG_GENERIC_CMDLINE
+ /*
+* The builtin command line will be added here, or it can override
+* with the DT bootargs.
+*/
+ cmdline_add_builtin(data,
+ (l > 0 ? p : NULL), /* This is sanity checking */
+ COMMAND_LINE_SIZE);
I don't think the comment is needed.
Without the comment, it should fit on a single line, would be better for
readability and grepability.
+#else
if (p != NULL && l > 0)
strlcpy(data, p, min(l, COMMAND_LINE_SIZE));
@@ -1070,6 +1081,7 @@ int __init early_init_dt_scan_chosen(unsigned long node, const char *uname,
strlcpy(data, CONFIG_CMDLINE, COMMAND_LINE_SIZE);
#endif
#endif /* CONFIG_CMDLINE */
+#endif /* CONFIG_GENERIC_CMDLINE */
pr_debug("Command line is: %s\n", (char *)data);
Christophe
Re: [PATCH RFCv2] mm/madvise: introduce MADV_POPULATE_(READ|WRITE) to prefault/prealloc memory
diff --git a/mm/internal.h b/mm/internal.h index 9902648f2206..a5c4ed23b1db 100644 --- a/mm/internal.h +++ b/mm/internal.h @@ -340,6 +340,9 @@ void __vma_unlink_list(struct mm_struct *mm, struct vm_area_struct *vma); #ifdef CONFIG_MMU extern long populate_vma_page_range(struct vm_area_struct *vma, unsigned long start, unsigned long end, int *nonblocking); +extern long faultin_vma_page_range(struct vm_area_struct *vma, + unsigned long start, unsigned long end, + bool write, int *nonblocking); extern void munlock_vma_pages_range(struct vm_area_struct *vma, unsigned long start, unsigned long end); static inline void munlock_vma_pages_all(struct vm_area_struct *vma) The parameter name does not match the one in the implementation. Otherwise the implementation looks fine AFAICT. Eike
Re: [PATCH v2 1/7] CMDLINE: add generic builtin command line
Le 09/03/2021 à 01:02, Daniel Walker a écrit :
This code allows architectures to use a generic builtin command line.
The state of the builtin command line options across architecture is
diverse. On x86 and mips they have pretty much the same code and the
code prepends the builtin command line onto the boot loader provided
one. On powerpc there is only a builtin override and nothing else.
Same comment as in v1: The above is not correct for powerpc.
The code in this commit unifies the code into a generic
header file under the CONFIG_GENERIC_CMDLINE option. When this
option is enabled the architecture can call the cmdline_add_builtin()
to add the builtin command line.
Cc: xe-linux-exter...@cisco.com
Signed-off-by: Ruslan Bilovol
Signed-off-by: Daniel Walker
---
include/linux/cmdline.h | 89 +
init/Kconfig| 68 +++
2 files changed, 157 insertions(+)
create mode 100644 include/linux/cmdline.h
diff --git a/include/linux/cmdline.h b/include/linux/cmdline.h
new file mode 100644
index ..00929b6e49e6
--- /dev/null
+++ b/include/linux/cmdline.h
@@ -0,0 +1,89 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#ifndef _LINUX_CMDLINE_H
+#define _LINUX_CMDLINE_H
+
+/*
+ *
+ * Copyright (C) 2006,2021. Cisco Systems, Inc.
+ *
+ * Generic Append/Prepend cmdline support.
+ */
+
+#if defined(CONFIG_GENERIC_CMDLINE) && defined(CONFIG_CMDLINE_BOOL)
+
+#ifndef CONFIG_CMDLINE_OVERRIDE
+#define GENERIC_CMDLINE_NEED_STRLCAT
+/*
+ * This function will append or prepend a builtin command line to the command
+ * line provided by the bootloader. Kconfig options can be used to alter
+ * the behavior of this builtin command line.
+ * @dest: The destination of the final appended/prepended string
+ * @src: The starting string or NULL if there isn't one.
+ * @tmp: temporary space used for prepending
+ * @length: the maximum length of the strings above.
+ * @cmdline_strlcpy: point to a compatible strlcpy
+ * @cmdline_strlcat: point to a compatible strlcat
+ */
+static inline void
+__cmdline_add_builtin(char *dest, const char *src, char *tmp, unsigned long
length,
+ size_t (*cmdline_strlcpy)(char *dest, const char *src, size_t
size),
+ size_t (*cmdline_strlcat)(char *dest, const char *src, size_t
count))
+{
+ if (src != dest && src != NULL) {
+ cmdline_strlcpy(dest, " ", length);
+ cmdline_strlcat(dest, src, length);
+ }
+
+ if (sizeof(CONFIG_CMDLINE_APPEND) > 1)
This test can probably be avoided. if CONFIG_CMDLINE_APPEND is empty, it will add a space at the end
of dest, that's harmless.
+ cmdline_strlcat(dest, " " CONFIG_CMDLINE_APPEND, length);
+
+ if (sizeof(CONFIG_CMDLINE_PREPEND) > 1) {
Same. Keep it simple. Provide tmp all the time, have only one logic.
+ cmdline_strlcpy(tmp, CONFIG_CMDLINE_PREPEND " ", length);
+ cmdline_strlcat(tmp, dest, length);
+ cmdline_strlcpy(dest, tmp, length);
+ }
+}
+
+#define cmdline_add_builtin_custom(dest, src, length, label, cmdline_strlcpy,
cmdline_strlcat) \
+{
\
+ if (sizeof(CONFIG_CMDLINE_PREPEND) > 1) {
\
+ static label char cmdline_tmp_space[length];
\
+ __cmdline_add_builtin(dest, src, cmdline_tmp_space, length,
cmdline_strlcpy, cmdline_strlcat); \
+ } else if (sizeof(CONFIG_CMDLINE_APPEND) > 1) {
\
+ __cmdline_add_builtin(dest, src, NULL, length, cmdline_strlcpy,
cmdline_strlcat); \
+ }
\
No need to micro-optimise this, you can provide cmdline_tmp_space all the time and only keep on leg
of the if/elseif
+}
+#define cmdline_add_builtin(dest, src, length) \
+ cmdline_add_builtin_custom(dest, src, length, __initdata, strlcpy,
strlcat)
+
+#else /* CONFIG_CMDLINE_OVERRIDE */
+
+static inline void
+__cmdline_add_builtin_custom(char *dest, const char *src, unsigned long length,
+ size_t (*cmdline_strlcpy)(char *dest, const char *src, size_t
size))
Argh ! So the same function as different semantics whether CONFIG_CMDLINE_OVERRIDE and/or
CONFIG_CMDLINE_BOOL is selected ? It means the architecture will have to know it as well in order to
call it right ? That looks like micro-optimisation, I think it is not worth it.
+{
+ cmdline_strlcpy(dest, CONFIG_CMDLINE_PREPEND " " CONFIG_CMDLINE_APPEND,
length);
+}
+#define cmdline_add_builtin_custom(dest, src, length, label, cmdline_strlcpy,
cmdline_strlcat) \
+
[PATCH 1/2] dt-bindings:pci: Set LTSSM Detect.Quiet state delay.
The parameter detect-quiet-min-delay can be used to program the minimum time that LTSSM waits on entering Detect.Quiet state. 00 : 0us minimum wait time in Detect.Quiet state. 01 : 100us minimum wait time in Detect.Quiet state. 10 : 1000us minimum wait time in Detect.Quiet state. 11 : 2000us minimum wait time in Detect.Quiet state. Signed-off-by: Nadeem Athani --- .../devicetree/bindings/pci/cdns,cdns-pcie-host.yaml| 13 + 1 file changed, 13 insertions(+) diff --git a/Documentation/devicetree/bindings/pci/cdns,cdns-pcie-host.yaml b/Documentation/devicetree/bindings/pci/cdns,cdns-pcie-host.yaml index 293b8ec318bc..a1d56e0be419 100644 --- a/Documentation/devicetree/bindings/pci/cdns,cdns-pcie-host.yaml +++ b/Documentation/devicetree/bindings/pci/cdns,cdns-pcie-host.yaml @@ -27,6 +27,18 @@ properties: msi-parent: true + detect-quiet-min-delay: +description: + LTSSM Detect.Quiet state minimum delay. + 00 : 0us minimum wait time + 01 : 100us minimum wait time + 10 : 1000us minimum wait time + 11 : 2000us minimum wait time +$ref: /schemas/types.yaml#/definitions/uint32 +minimum: 0 +maximum: 3 +default: 0 + required: - reg - reg-names @@ -48,6 +60,7 @@ examples: linux,pci-domain = <0>; vendor-id = <0x17cd>; device-id = <0x0200>; +detect-quiet-min-delay = <0>; reg = <0x0 0xfb00 0x0 0x0100>, <0x0 0x4100 0x0 0x1000>; -- 2.15.0
[PATCH 2/2] PCI: cadence: Set LTSSM Detect.Quiet state delay.
The parameter detect_quiet_min_delay can be used to program the minimum
time that LTSSM waits on entering Detect.Quiet state.
00 : 0us minimum wait time in Detect.Quiet state.
01 : 100us minimum wait time in Detect.Quiet state.
10 : 1000us minimum wait time in Detect.Quiet state.
11 : 2000us minimum wait time in Detect.Quiet state.
As per PCIe specification, all Receivers must meet the Z-RX-DC
specification for 2.5 GT/s within 1000us of entering Detect.Quiet LTSSM
substate. The LTSSM must stay in this substate until the ZRXDC
specification for 2.5 GT/s is met.
Signed-off-by: Nadeem Athani
---
drivers/pci/controller/cadence/pcie-cadence-host.c | 22 ++
drivers/pci/controller/cadence/pcie-cadence.h | 10 ++
2 files changed, 32 insertions(+)
diff --git a/drivers/pci/controller/cadence/pcie-cadence-host.c
b/drivers/pci/controller/cadence/pcie-cadence-host.c
index 73dcf8cf98fb..056161b3fe65 100644
--- a/drivers/pci/controller/cadence/pcie-cadence-host.c
+++ b/drivers/pci/controller/cadence/pcie-cadence-host.c
@@ -461,6 +461,20 @@ static int cdns_pcie_host_init(struct device *dev,
return cdns_pcie_host_init_address_translation(rc);
}
+static void cdns_pcie_detect_quiet_min_delay_set(struct cdns_pcie_rc *rc)
+{
+ struct cdns_pcie *pcie = >pcie;
+ u32 delay = rc->detect_quiet_min_delay;
+ u32 ltssm_control_cap;
+
+ ltssm_control_cap = cdns_pcie_readl(pcie, CDNS_PCIE_LTSSM_CONTROL_CAP);
+ ltssm_control_cap = ((ltssm_control_cap &
+~CDNS_PCIE_DETECT_QUIET_MIN_DELAY_MASK) |
+ CDNS_PCIE_DETECT_QUIET_MIN_DELAY(delay));
+
+ cdns_pcie_writel(pcie, CDNS_PCIE_LTSSM_CONTROL_CAP, ltssm_control_cap);
+}
+
int cdns_pcie_host_setup(struct cdns_pcie_rc *rc)
{
struct device *dev = rc->pcie.dev;
@@ -485,6 +499,10 @@ int cdns_pcie_host_setup(struct cdns_pcie_rc *rc)
rc->device_id = 0x;
of_property_read_u32(np, "device-id", >device_id);
+ rc->detect_quiet_min_delay = 0;
+ of_property_read_u32(np, "detect-quiet-min-delay",
+>detect_quiet_min_delay);
+
pcie->reg_base = devm_platform_ioremap_resource_byname(pdev, "reg");
if (IS_ERR(pcie->reg_base)) {
dev_err(dev, "missing \"reg\"\n");
@@ -497,6 +515,10 @@ int cdns_pcie_host_setup(struct cdns_pcie_rc *rc)
return PTR_ERR(rc->cfg_base);
rc->cfg_res = res;
+ /* Default Detect.Quiet state delay is 0 */
+ if (rc->detect_quiet_min_delay)
+ cdns_pcie_detect_quiet_min_delay_set(rc);
+
ret = cdns_pcie_start_link(pcie);
if (ret) {
dev_err(dev, "Failed to start link\n");
diff --git a/drivers/pci/controller/cadence/pcie-cadence.h
b/drivers/pci/controller/cadence/pcie-cadence.h
index 254d2570f8c9..f2d3cca2c707 100644
--- a/drivers/pci/controller/cadence/pcie-cadence.h
+++ b/drivers/pci/controller/cadence/pcie-cadence.h
@@ -189,6 +189,14 @@
/* AXI link down register */
#define CDNS_PCIE_AT_LINKDOWN (CDNS_PCIE_AT_BASE + 0x0824)
+/* LTSSM Capabilities register */
+#define CDNS_PCIE_LTSSM_CONTROL_CAP (CDNS_PCIE_LM_BASE + 0x0054)
+#define CDNS_PCIE_DETECT_QUIET_MIN_DELAY_MASK GENMASK(2, 1)
+#define CDNS_PCIE_DETECT_QUIET_MIN_DELAY_SHIFT 1
+#define CDNS_PCIE_DETECT_QUIET_MIN_DELAY(delay) \
+ (((delay) << CDNS_PCIE_DETECT_QUIET_MIN_DELAY_SHIFT) & \
+ CDNS_PCIE_DETECT_QUIET_MIN_DELAY_MASK)
+
enum cdns_pcie_rp_bar {
RP_BAR_UNDEFINED = -1,
RP_BAR0,
@@ -289,6 +297,7 @@ struct cdns_pcie {
*single function at a time
* @vendor_id: PCI vendor ID
* @device_id: PCI device ID
+ * @detect_quiet_min_delay: LTSSM Detect Quite state min. delay
* @avail_ib_bar: Satus of RP_BAR0, RP_BAR1 andRP_NO_BAR if it's free
or
*available
* @quirk_retrain_flag: Retrain link as quirk for PCIe Gen2
@@ -299,6 +308,7 @@ struct cdns_pcie_rc {
void __iomem*cfg_base;
u32 vendor_id;
u32 device_id;
+ u32 detect_quiet_min_delay;
boolavail_ib_bar[CDNS_PCIE_RP_MAX_IB];
boolquirk_retrain_flag;
};
--
2.15.0
[PATCH 0/2] PCI: cadence: Set LTSSM Detect.Quiet state delay.
This patch includes a set of two patches. First patch for adding a new property detect-quiet-min-delay in yaml file. Second patch programs the delay value in host pcie driver. The parameter detect-quiet-min-delay can be used to program the minimum time that LTSSM waits on entering Detect.Quiet state. 00 : 0us minimum wait time in Detect.Quiet state. 01 : 100us minimum wait time in Detect.Quiet state. 10 : 1000us minimum wait time in Detect.Quiet state. 11 : 2000us minimum wait time in Detect.Quiet state. Nadeem Athani (2): dt-bindings:pci: Set LTSSM Detect.Quiet state delay. PCI: cadence: Set LTSSM Detect.Quiet state delay. .../bindings/pci/cdns,cdns-pcie-host.yaml | 13 + drivers/pci/controller/cadence/pcie-cadence-host.c | 22 ++ drivers/pci/controller/cadence/pcie-cadence.h | 10 ++ 3 files changed, 45 insertions(+) -- 2.15.0
Re: [PATCH] libnvdimm: Let revalidate_disk() revalidate region read-only
On Mon, Mar 08, 2021 at 10:54:22PM -0800, Dan Williams wrote: > Previous kernels allowed the BLKROSET to override the disk's read-only > status. With that situation fixed the pmem driver needs to rely on > revalidate_disk() to clear the disk read-only status after the host > region has been marked read-write. > > Recall that when libnvdimm determines that the persistent memory has > lost persistence (for example lack of energy to flush from DRAM to FLASH > on an NVDIMM-N device) it marks the region read-only, but that state can > be overridden by the user via: > >echo 0 > /sys/bus/nd/devices/regionX/read_only > > ...to date there is no notification that the region has restored > persistence, so the user override is the only recovery. I've just resent my series to kill of ->revalidate_disk for good, so this obvious makes me a little unhappy. Given that ->revalidate_disk only ends up beeing called from the same path that ->open is called, why can't you just hook this up from the open method? Also any reason the sysfs attribute can't just directly propagate the information to the disk?
Re: [PATCH 0/4] kbuild: build speed improvment of CONFIG_TRIM_UNUSED_KSYMS
On Fri, Feb 26, 2021 at 4:24 AM Nicolas Pitre wrote: > > On Fri, 26 Feb 2021, Masahiro Yamada wrote: > > > On Fri, Feb 26, 2021 at 2:20 AM Nicolas Pitre wrote: > > > > > > On Fri, 26 Feb 2021, Masahiro Yamada wrote: > > > > > > > > > > > Now CONFIG_TRIM_UNUSED_KSYMS is revived, but Linus is still unhappy > > > > about the build speed. > > > > > > > > I re-implemented this feature, and the build time cost is now > > > > almost unnoticeable level. > > > > > > > > I hope this makes Linus happy. > > > > > > :-) > > > > > > I'm surprised to see that Linus is using this feature. When disabled > > > (the default) this should have had no impact on the build time. > > > > Linus is not using this feature, but does build tests. > > After pulling the module subsystem pull request in this merge window, > > CONFIG_TRIM_UNUSED_KSYMS was enabled by allmodconfig. > > If CONFIG_TRIM_UNUSED_KSYMS is enabled then build time willincrease. > That comes with the feature. This patch set intends to change this. TRIM_UNUSED_KSYMS will build without additional cost, like LD_DEAD_CODE_DATA_ELIMINATION. > > > > This feature provides a nice security advantage by significantly > > > reducing the kernel input surface. And people are using that also to > > > better what third party vendor can and cannot do with a distro kernel, > > > etc. But that's not the reason why I implemented this feature in the > > > first place. > > > > > > My primary goal was to efficiently reduce the kernel binary size using > > > LTO even with kernel modules enabled. > > > > > > Clang LTO landed in this MW. > > > > Do you think it will reduce the kernel binary size? > > No, opposite. > > LTO ought to reduce binary size. It is rather broken otherwise. > Having a global view before optimizing allows for the compiler to do > project wide constant propagation and dead code elimination. > > > CONFIG_LTO_CLANG cannot trim any code even if it > > is obviously unused. > > Hence, it never reduces the kernel binary size. > > Rather, it produces a bigger kernel. > > Then what's the point? Presumably, reducing the size is not the main interest for Googlers. > > > The reason is Clang LTO was implemented against > > relocatable ELF (vmlinux.o) . > > That's not true LTO then. This is the same as what I said in the review process. :-) https://lore.kernel.org/linux-kbuild/cak7lnasqpogohtuyzbm6n54pzpln35kdxc7vbvwzx8qwumq...@mail.gmail.com/ > > > I pointed out this flaw in the review process, but > > it was dismissed. > > > > This is the main reason why I did not give any Ack > > (but it was merged via Kees Cook's tree). > > > So, the help text of this option should be revised: > > > > This option allows for unused exported symbols to be dropped from > > the build. In turn, this provides the compiler more opportunities > > (especially when using LTO) for optimizing the code and reducing > > binary size. This might have some security advantages as well. > > > > Clang LTO is opposite to your expectation. > > Then Clang LTO is a misnomer. That is the option to revise not this one. > > > > Each EXPORT_SYMBOL() created a > > > symbol dependency that prevented LTO from optimizing out the related > > > code even though a tiny fraction of those exported symbols were needed. > > > > > > The idea behind the recursion was to catch those cases where disabling > > > an exported symbol within a module would optimize out references to more > > > exported symbols that, in turn, could be disabled and possibly trigger > > > yet more code elimination. There is no way that can be achieved without > > > extra compiler passes in a recursive manner. > > > > I do not understand. > > > > Modules are relocatable ELF. > > Clang LTO cannot eliminate any code. > > GCC LTO does not work with relocatable ELF > > in the first place. > > I don't think I follow you here. What relocatable ELF has to do with LTO? What is important is, GCC LTO is the feature of gcc, not binutils. That is, LD_FINAL is $(CC). GCC LTO can be implemented for the final link stage by using $(CC) as the linker driver. Then, it can determine which code is unreachable. In other words, GCC LTO works only when building the final executable. On the other hand, a relocatable ELF is created by $(LD) -r by combining some objects together. The relocatable ELF can be fed to another $(LD) -r, or the final link stage. vmlinux is an executable ELF. modules (*.ko files) are relocatable ELFs. You can confirm it easily by using the 'file' command. masahiro@oscar:~/ref/linux$ file vmlinux vmlinux: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), statically linked, BuildID[sha1]=ee0cef2ff3d9f490e0f5ee1d7e74b19aa167933b, not stripped masahiro@oscar:~/ref/linux$ file net/ipv4/netfilter/iptable_nat.ko net/ipv4/netfilter/iptable_nat.ko: ELF 64-bit LSB relocatable, x86-64, version 1 (SYSV), BuildID[sha1]=4829e82f9b9e7fd65be3c19c1cf0e16a7ddf0967, not stripped Modules are not filled
Re: [PATCH v2 4/5] mtd: spi-nor: Move Software Write Protection logic out of the core
On 3/8/21 7:28 PM, Vignesh Raghavendra wrote: > EXTERNAL EMAIL: Do not click links or open attachments unless you know the > content is safe > > On 3/6/21 3:20 PM, Tudor Ambarus wrote: >> It makes the core file a bit smaller and provides better separation >> between the Software Write Protection features and the core logic. >> All the next generic software write protection features (e.g. Individual >> Block Protection) will reside in swp.c. >> >> Signed-off-by: Tudor Ambarus >> --- >> drivers/mtd/spi-nor/Makefile | 2 +- >> drivers/mtd/spi-nor/core.c | 407 +- >> drivers/mtd/spi-nor/core.h | 4 + >> drivers/mtd/spi-nor/swp.c| 419 +++ > > Hmmm, name swp.c does not seem intuitive to me. How about expanding it a > bit: > > soft-wr-protect.c or software-write-protect.c ? > I thought about the SWP configs that we have. How about keeping swp.c and rename configs to: s/MTD_SPI_NOR_SWP_DISABLE/MTD_SPI_NOR_DISABLE_BOOT_SWP s/MTD_SPI_NOR_SWP_DISABLE_ON_VOLATILE/MTD_SPI_DISABLE_BOOT_SWP_ON_VOLATILE s/MTD_SPI_NOR_SWP_KEEP/MTD_SPI_NOR_KEEP_BOOT_SWP The renamed configs should better indicate that the software write protection is disabled just at boot time, while the locking support is still enabled. Otherwise one may think that with a MTD_SPI_NOR_SWP_DISABLE, all the software write protection features are stripped/not available. Cheers, ta
Re: [PATCH v2 3/4] arm64: dts: ti: Add support for Siemens IOT2050 boards
On 04.03.21 07:58, Vignesh Raghavendra wrote:
> Hi,
>
> On 2/12/21 1:02 AM, Jan Kiszka wrote:
>> From: Jan Kiszka
>>
>> Add support for two Siemens SIMATIC IOT2050 variants, Basic and
>> Advanced. They are based on the TI AM6528 GP and AM6548 SOCs HS, thus
>> differ in their number of cores and availability of security features.
>> Furthermore the Advanced version comes with more RAM, an eMMC and a few
>> internal differences.
>>
>> Based on original version by Le Jin.
>>
>> Link:
>> https://new.siemens.com/global/en/products/automation/pc-based/iot-gateways/simatic-iot2050.html
>> Link: https://github.com/siemens/meta-iot2050
>> Signed-off-by: Jan Kiszka
>
> Reviewed-by: Vignesh Raghavendra
>
Thanks!
> Few minor comments below:
>
> [...]
>
>> +
>> +_i2c0 {
>> +pinctrl-names = "default";
>> +pinctrl-0 = <_i2c0_pins_default>;
>> +clock-frequency = <40>;
>> +
>> +psu: tps62363@60 {
>
> Please use generic node names:
>
> psu: regulator@60 { ... };
>
Done.
>> +compatible = "ti,tps62363";
>> +reg = <0x60>;
>> +regulator-name = "tps62363-vout";
>> +regulator-min-microvolt = <50>;
>> +regulator-max-microvolt = <150>;
>> +regulator-boot-on;
>> +ti,vsel0-state-high;
>> +ti,vsel1-state-high;
>> +ti,enable-vout-discharge;
>> +};
>> +
>> +/* D4200 */
>> +pcal9535_1: gpio@20 {
>> +compatible = "nxp,pcal9535";
>> +reg = <0x20>;
>> +#gpio-cells = <2>;
>> +gpio-controller;
>> +gpio-line-names =
>> +"A0-pull", "A1-pull", "A2-pull", "A3-pull", "A4-pull",
>> +"A5-pull", "", "",
>> +"IO14-enable", "IO15-enable", "IO16-enable",
>> +"IO17-enable", "IO18-enable", "IO19-enable";
>> +};
>> +
>> +/* D4201 */
>> +pcal9535_2: gpio@21 {
>> +compatible = "nxp,pcal9535";
>> +reg = <0x21>;
>> +#gpio-cells = <2>;
>> +gpio-controller;
>> +gpio-line-names =
>> +"IO0-direction", "IO1-direction", "IO2-direction",
>> +"IO3-direction", "IO4-direction", "IO5-direction",
>> +"IO6-direction", "IO7-direction",
>> +"IO8-direction", "IO9-direction", "IO10-direction",
>> +"IO11-direction", "IO12-direction", "IO13-direction",
>> +"IO19-direction";
>> +};
>> +
>> +/* D4202 */
>> +pcal9535_3: gpio@25 {
>> +compatible = "nxp,pcal9535";
>> +reg = <0x25>;
>> +#gpio-cells = <2>;
>> +gpio-controller;
>> +gpio-line-names =
>> +"IO0-pull", "IO1-pull", "IO2-pull", "IO3-pull",
>> +"IO4-pull", "IO5-pull", "IO6-pull", "IO7-pull",
>> +"IO8-pull", "IO9-pull", "IO10-pull", "IO11-pull",
>> +"IO12-pull", "IO13-pull";
>> +};
>> +};
>
> [...]
>
>> +_0 {
>> +status = "okay";
>> +};
>> +
>> +_phy {
>> +status = "okay";
>> +};
>> +
>
> These nodes are enabled by default right? Above is redundant.
Seems like historic left-overs here - fixed.
>
>> + {
>> +pinctrl-names = "default";
>> +pinctrl-0 = <_pins_default>;
>> +dr_mode = "host";
>> +};
>> +
>> +_1 {
>> +status = "okay";
>> +};
>> +
>> +_phy {
>> +status = "okay";
>> +};
>> +
>
> Same here...
Also fixed.
>
>> + {
>> +pinctrl-names = "default";
>> +pinctrl-0 = <_pins_default>;
>> +dr_mode = "host";
>> +};
>> +
>
> [...]
>
>> +_spi0 {
>> +pinctrl-names = "default";
>> +pinctrl-0 = <_spi0_pins_default>;
>> +
>> +#address-cells = <1>;
>> +#size-cells= <0>;
>> +ti,pindir-d0-out-d1-in = <1>;
>> +
>> +spidev@0 {
>> +compatible = "rohm,dh2228fv";
>> +spi-max-frequency = <2000>;
>> +reg = <0>;
>> +};
>
> Is the device really dh2228fv?
At least to my understanding, "rohm,dh2228fv" is commonly used for
declaring spidev, and this is what we need for userland here.
>
>> +};
>> +
>> + {
>> +status = "disabled";
>> +};
>> +
>> + {
>> +adc {
>> +ti,adc-channels = <0 1 2 3 4 5>;
>> +};
>> +};
>> +
>> + {
>> +pinctrl-names = "default";
>> +pinctrl-0 = <_fss0_ospi0_pins_default>;
>> +
>> +flash@0 {
>> +compatible = "jedec,spi-nor";
>> +reg = <0x0>;
>> +spi-tx-bus-width = <1>;
>> +spi-rx-bus-width = <1>;
>> +spi-max-frequency = <5000>;
>> +cdns,tshsl-ns = <60>;
>> +cdns,tsd2d-ns = <60>;
>> +cdns,tchsh-ns = <60>;
>> +cdns,tslch-ns = <60>;
>> +cdns,read-delay = <2>;
>> +#address-cells = <1>;
>> +#size-cells = <1>;
>> +};
>> +};
>> +
>> + {
>> +status = "okay";
>> +
>
> Node is enabled
Re: [RFC PATCH 2/6] clk: sifive: Use reset-simple in prci driver for PCIe driver
Philipp Zabel 於 2021年3月4日 週四 下午7:58寫道：
>
> On Tue, 2021-03-02 at 18:59 +0800, Greentime Hu wrote:
> > We use reset-simple in this patch so that pcie driver can use
> > devm_reset_control_get() to get this reset data structure and use
> > reset_control_deassert() to deassert pcie_power_up_rst_n.
> >
> > Signed-off-by: Greentime Hu
> > ---
> > drivers/clk/sifive/Kconfig | 2 ++
> > drivers/clk/sifive/sifive-prci.c | 14 ++
> > drivers/clk/sifive/sifive-prci.h | 4
> > drivers/reset/Kconfig| 3 ++-
> > 4 files changed, 22 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/clk/sifive/Kconfig b/drivers/clk/sifive/Kconfig
> > index 1c14eb20c066..9132c3c4aa86 100644
> > --- a/drivers/clk/sifive/Kconfig
> > +++ b/drivers/clk/sifive/Kconfig
> > @@ -10,6 +10,8 @@ if CLK_SIFIVE
> >
> > config CLK_SIFIVE_PRCI
> > bool "PRCI driver for SiFive SoCs"
> > + select RESET_CONTROLLER
> > + select RESET_SIMPLE
> > select CLK_ANALOGBITS_WRPLL_CLN28HPC
> > help
> > Supports the Power Reset Clock interface (PRCI) IP block found in
> > diff --git a/drivers/clk/sifive/sifive-prci.c
> > b/drivers/clk/sifive/sifive-prci.c
> > index baf7313dac92..925affc6de55 100644
> > --- a/drivers/clk/sifive/sifive-prci.c
> > +++ b/drivers/clk/sifive/sifive-prci.c
> > @@ -583,7 +583,21 @@ static int sifive_prci_probe(struct platform_device
> > *pdev)
> > if (IS_ERR(pd->va))
> > return PTR_ERR(pd->va);
> >
> > + pd->reset.rcdev.owner = THIS_MODULE;
> > + pd->reset.rcdev.nr_resets = PRCI_RST_NR;
> > + pd->reset.rcdev.ops = _simple_ops;
> > + pd->reset.rcdev.of_node = pdev->dev.of_node;
> > + pd->reset.active_low = true;
> > + pd->reset.membase = pd->va + PRCI_DEVICESRESETREG_OFFSET;
> > + spin_lock_init(>reset.lock);
> > +
> > + r = devm_reset_controller_register(>dev, >reset.rcdev);
> > + if (r) {
> > + dev_err(dev, "could not register reset controller: %d\n", r);
> > + return r;
> > + }
> > r = __prci_register_clocks(dev, pd, desc);
> > +
>
> Accidental whitespace?
>
> Otherwise,
>
> Reviewed-by: Philipp Zabel
Thank you, Philipp.
Yes, it is an accidental whitespace. I'll remove it in my next version patch.
[PATCH] char: lp: remove redundant space around (inside) parenthesized expressions
These two lines of code don't meet the linux kernel style,
and use a space after these keywords:
if, switch, case, for, do, while.
Do not add spaces around (inside) parenthesized expressions.
So remove the redundant space.
Signed-off-by: Qiang Ma
---
drivers/char/lp.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/char/lp.c b/drivers/char/lp.c
index 862c2fd933c7..0e22e3b0a04e 100644
--- a/drivers/char/lp.c
+++ b/drivers/char/lp.c
@@ -546,7 +546,7 @@ static int lp_open(struct inode *inode, struct file *file)
}
/* Determine if the peripheral supports ECP mode */
lp_claim_parport_or_block(_table[minor]);
- if ( (lp_table[minor].dev->port->modes & PARPORT_MODE_ECP) &&
+ if ((lp_table[minor].dev->port->modes & PARPORT_MODE_ECP) &&
!parport_negotiate(lp_table[minor].dev->port,
IEEE1284_MODE_ECP)) {
printk(KERN_INFO "lp%d: ECP mode\n", minor);
@@ -590,7 +590,7 @@ static int lp_do_ioctl(unsigned int minor, unsigned int cmd,
return -ENODEV;
if ((LP_F(minor) & LP_EXIST) == 0)
return -ENODEV;
- switch ( cmd ) {
+ switch (cmd) {
case LPTIME:
if (arg > UINT_MAX / HZ)
return -EINVAL;
--
2.20.1
[PATCH] firewire: Use bitwise instead of arithmetic operator for flags
Fix the following coccicheck warnings:
./drivers/firewire/core-device.c:973:22-23: WARNING: sum of probable
bitmasks, consider |.
./drivers/firewire/core-device.c:954:22-23: WARNING: sum of probable
bitmasks, consider |.
Reported-by: Abaci Robot
Signed-off-by: Jiapeng Chong
---
drivers/firewire/core-device.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/firewire/core-device.c b/drivers/firewire/core-device.c
index 6821698..e04832d 100644
--- a/drivers/firewire/core-device.c
+++ b/drivers/firewire/core-device.c
@@ -951,7 +951,7 @@ static void set_broadcast_channel(struct fw_device *device,
int generation)
if (device->bc_implemented == BC_UNKNOWN) {
rcode = fw_run_transaction(card, TCODE_READ_QUADLET_REQUEST,
device->node_id, generation, device->max_speed,
- CSR_REGISTER_BASE + CSR_BROADCAST_CHANNEL,
+ CSR_REGISTER_BASE | CSR_BROADCAST_CHANNEL,
, 4);
switch (rcode) {
case RCODE_COMPLETE:
@@ -970,7 +970,7 @@ static void set_broadcast_channel(struct fw_device *device,
int generation)
BROADCAST_CHANNEL_VALID);
fw_run_transaction(card, TCODE_WRITE_QUADLET_REQUEST,
device->node_id, generation, device->max_speed,
- CSR_REGISTER_BASE + CSR_BROADCAST_CHANNEL,
+ CSR_REGISTER_BASE | CSR_BROADCAST_CHANNEL,
, 4);
}
}
--
1.8.3.1
Re: [Intel-wired-lan] [PATCH] e1000e: Fix error handling in e1000_set_d0_lplu_state_82571
On 28/02/2021 11:44, Dinghao Liu wrote:
There is one e1e_wphy() call in e1000_set_d0_lplu_state_82571
that we have caught its return value but lack further handling.
Check and terminate the execution flow just like other e1e_wphy()
in this function.
Signed-off-by: Dinghao Liu
---
drivers/net/ethernet/intel/e1000e/82571.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/net/ethernet/intel/e1000e/82571.c
b/drivers/net/ethernet/intel/e1000e/82571.c
index 88faf05e23ba..0b1e890dd583 100644
--- a/drivers/net/ethernet/intel/e1000e/82571.c
+++ b/drivers/net/ethernet/intel/e1000e/82571.c
@@ -899,6 +899,8 @@ static s32 e1000_set_d0_lplu_state_82571(struct e1000_hw
*hw, bool active)
} else {
data &= ~IGP02E1000_PM_D0_LPLU;
ret_val = e1e_wphy(hw, IGP02E1000_PHY_POWER_MGMT, data);
+ if (ret_val)
+ return ret_val;
/* LPLU and SmartSpeed are mutually exclusive. LPLU is used
* during Dx states where the power conservation is most
* important. During driver activity we should enable
Tested-by: Dvora Fuxbrumer
[tip:master] BUILD SUCCESS 361316d29e5718c52c92ee4a4d8d6ccb9d5d60a9
randconfig-a006-20210308 x86_64 randconfig-a001-20210308 x86_64 randconfig-a004-20210308 x86_64 randconfig-a002-20210308 x86_64 randconfig-a005-20210308 x86_64 randconfig-a003-20210308 i386 randconfig-a005-20210309 i386 randconfig-a003-20210309 i386 randconfig-a002-20210309 i386 randconfig-a006-20210309 i386 randconfig-a004-20210309 i386 randconfig-a001-20210309 i386 randconfig-a005-20210308 i386 randconfig-a003-20210308 i386 randconfig-a002-20210308 i386 randconfig-a006-20210308 i386 randconfig-a004-20210308 i386 randconfig-a001-20210308 x86_64 randconfig-a013-20210309 x86_64 randconfig-a016-20210309 x86_64 randconfig-a015-20210309 x86_64 randconfig-a014-20210309 x86_64 randconfig-a011-20210309 x86_64 randconfig-a012-20210309 i386 randconfig-a016-20210309 i386 randconfig-a012-20210309 i386 randconfig-a014-20210309 i386 randconfig-a013-20210309 i386 randconfig-a011-20210309 i386 randconfig-a015-20210309 riscvnommu_k210_defconfig riscvallyesconfig riscvnommu_virt_defconfig riscv allnoconfig riscv defconfig riscv rv32_defconfig riscvallmodconfig x86_64rhel-7.6-kselftests x86_64 defconfig x86_64 rhel-8.3 x86_64 rhel-8.3-kbuiltin x86_64 kexec clang tested configs: x86_64 randconfig-a013-20210308 x86_64 randconfig-a016-20210308 x86_64 randconfig-a015-20210308 x86_64 randconfig-a014-20210308 x86_64 randconfig-a011-20210308 x86_64 randconfig-a012-20210308 x86_64 randconfig-a006-20210309 x86_64 randconfig-a001-20210309 x86_64 randconfig-a004-20210309 x86_64 randconfig-a002-20210309 x86_64 randconfig-a005-20210309 x86_64 randconfig-a003-20210309 --- 0-DAY CI Kernel Test Service, Intel Corporation https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
Re: [syzbot] upstream boot error: WARNING in kvm_wait
On Sat, Mar 6, 2021 at 12:37 PM Dmitry Vyukov wrote: > > On Fri, Mar 5, 2021 at 9:56 PM syzbot > wrote: > > > > Hello, > > > > syzbot found the following issue on: > > > > HEAD commit:280d542f Merge tag 'drm-fixes-2021-03-05' of git://anongit.. > > git tree: upstream > > console output: https://syzkaller.appspot.com/x/log.txt?x=138c7a92d0 > > kernel config: https://syzkaller.appspot.com/x/.config?x=dc4003509ab3fc78 > > dashboard link: https://syzkaller.appspot.com/bug?extid=a4c8bc1d1dc7b620630d > > > > IMPORTANT: if you fix the issue, please add the following tag to the commit: > > Reported-by: syzbot+a4c8bc1d1dc7b6206...@syzkaller.appspotmail.com > > +Mark, I've enabled CONFIG_DEBUG_IRQFLAGS on syzbot and it led to this > breakage. > Is it a bug in kvm_wait or in the debugging code itself? If it's a > real bug, I would assume it's pretty bad as it happens all the time. Wanpeng posted a fix for this: https://lore.kernel.org/kvm/1614057902-23774-1-git-send-email-wanpen...@tencent.com/ #syz fix: x86/kvm: Fix broken irq restoration in kvm_wait > > [ cut here ] > > raw_local_irq_restore() called with IRQs enabled > > WARNING: CPU: 2 PID: 213 at kernel/locking/irqflag-debug.c:10 > > warn_bogus_irq_restore+0x1d/0x20 kernel/locking/irqflag-debug.c:10 > > Modules linked in: > > CPU: 2 PID: 213 Comm: kworker/u17:4 Not tainted 5.12.0-rc1-syzkaller #0 > > Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.14.0-2 04/01/2014 > > Workqueue: events_unbound call_usermodehelper_exec_work > > > > RIP: 0010:warn_bogus_irq_restore+0x1d/0x20 kernel/locking/irqflag-debug.c:10 > > Code: be ff cc cc cc cc cc cc cc cc cc cc cc 80 3d e4 38 af 04 00 74 01 c3 > > 48 c7 c7 a0 8f 6b 89 c6 05 d3 38 af 04 01 e8 e7 b9 be ff <0f> 0b c3 48 39 > > 77 10 0f 84 97 00 00 00 66 f7 47 22 f0 ff 74 4b 48 > > RSP: :c9fe7770 EFLAGS: 00010286 > > > > RAX: RBX: 8c0e9c68 RCX: > > RDX: 8880116bc3c0 RSI: 815c0cf5 RDI: f520001fcee0 > > RBP: 0200 R08: R09: 0001 > > R10: 815b9a5e R11: R12: 0003 > > R13: fbfff181d38d R14: 0001 R15: 88802cc36000 > > FS: () GS:88802cc0() knlGS: > > CS: 0010 DS: ES: CR0: 80050033 > > CR2: CR3: 0bc8e000 CR4: 00150ee0 > > DR0: DR1: DR2: > > DR3: DR6: fffe0ff0 DR7: 0400 > > Call Trace: > > kvm_wait arch/x86/kernel/kvm.c:860 [inline] > > kvm_wait+0xc9/0xe0 arch/x86/kernel/kvm.c:837 > > pv_wait arch/x86/include/asm/paravirt.h:564 [inline] > > pv_wait_head_or_lock kernel/locking/qspinlock_paravirt.h:470 [inline] > > __pv_queued_spin_lock_slowpath+0x8b8/0xb40 kernel/locking/qspinlock.c:508 > > pv_queued_spin_lock_slowpath arch/x86/include/asm/paravirt.h:554 [inline] > > queued_spin_lock_slowpath arch/x86/include/asm/qspinlock.h:51 [inline] > > queued_spin_lock include/asm-generic/qspinlock.h:85 [inline] > > do_raw_spin_lock+0x200/0x2b0 kernel/locking/spinlock_debug.c:113 > > spin_lock include/linux/spinlock.h:354 [inline] > > copy_fs_struct+0x1c8/0x340 fs/fs_struct.c:123 > > copy_fs kernel/fork.c:1443 [inline] > > copy_process+0x4dc2/0x6fd0 kernel/fork.c:2088 > > kernel_clone+0xe7/0xab0 kernel/fork.c:2462 > > kernel_thread+0xb5/0xf0 kernel/fork.c:2514 > > call_usermodehelper_exec_work kernel/umh.c:172 [inline] > > call_usermodehelper_exec_work+0xcc/0x180 kernel/umh.c:158 > > process_one_work+0x98d/0x1600 kernel/workqueue.c:2275 > > worker_thread+0x64c/0x1120 kernel/workqueue.c:2421 > > kthread+0x3b1/0x4a0 kernel/kthread.c:292 > > ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:294 > > > > > > --- > > This report is generated by a bot. It may contain errors. > > See https://goo.gl/tpsmEJ for more information about syzbot. > > syzbot engineers can be reached at syzkal...@googlegroups.com. > > > > syzbot will keep track of this issue. See: > > https://goo.gl/tpsmEJ#status for how to communicate with syzbot. > > > > -- > > You received this message because you are subscribed to the Google Groups > > "syzkaller-bugs" group. > > To unsubscribe from this group and stop receiving emails from it, send an > > email to syzkaller-bugs+unsubscr...@googlegroups.com. > > To view this discussion on the web visit > > https://groups.google.com/d/msgid/syzkaller-bugs/ccbedd05bcd0504e%40google.com.
Re: [syzbot] net-next boot error: WARNING in kvm_wait
On Fri, Mar 5, 2021 at 9:57 PM syzbot wrote: > > Hello, > > syzbot found the following issue on: > > HEAD commit:d310ec03 Merge tag 'perf-core-2021-02-17' of git://git.ker.. > git tree: net-next > console output: https://syzkaller.appspot.com/x/log.txt?x=1532e4c6d0 > kernel config: https://syzkaller.appspot.com/x/.config?x=66df2ca4f2dd3022 > dashboard link: https://syzkaller.appspot.com/bug?extid=05a8c6cb8281f23c8915 > > IMPORTANT: if you fix the issue, please add the following tag to the commit: > Reported-by: syzbot+05a8c6cb8281f23c8...@syzkaller.appspotmail.com #syz dup: upstream boot error: WARNING in kvm_wait > [ cut here ] > raw_local_irq_restore() called with IRQs enabled > WARNING: CPU: 0 PID: 4818 at kernel/locking/irqflag-debug.c:10 > warn_bogus_irq_restore+0x1d/0x20 kernel/locking/irqflag-debug.c:10 > Modules linked in: > CPU: 0 PID: 4818 Comm: selinux-autorel Not tainted 5.11.0-syzkaller #0 > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS > Google 01/01/2011 > RIP: 0010:warn_bogus_irq_restore+0x1d/0x20 kernel/locking/irqflag-debug.c:10 > Code: bf ff cc cc cc cc cc cc cc cc cc cc cc 80 3d 8a 88 b1 04 00 74 01 c3 48 > c7 c7 40 a2 6b 89 c6 05 79 88 b1 04 01 e8 b8 37 bf ff <0f> 0b c3 48 39 77 10 > 0f 84 97 00 00 00 66 f7 47 22 f0 ff 74 4b 48 > RSP: 0018:c900015cfc40 EFLAGS: 00010282 > RAX: RBX: 8be287a0 RCX: > RDX: 888022b31bc0 RSI: 815b6845 RDI: f520002b9f7a > RBP: 0200 R08: R09: 0001 > R10: 815af71e R11: R12: 0003 > R13: fbfff17c50f4 R14: 0001 R15: 8880b9c35f40 > FS: () GS:8880b9c0() knlGS: > CS: 0010 DS: ES: CR0: 80050033 > CR2: 7ff7c1ccab04 CR3: 0bc8e000 CR4: 001506f0 > DR0: DR1: DR2: > DR3: DR6: fffe0ff0 DR7: 0400 > Call Trace: > kvm_wait arch/x86/kernel/kvm.c:860 [inline] > kvm_wait+0xc9/0xe0 arch/x86/kernel/kvm.c:837 > pv_wait arch/x86/include/asm/paravirt.h:564 [inline] > pv_wait_head_or_lock kernel/locking/qspinlock_paravirt.h:470 [inline] > __pv_queued_spin_lock_slowpath+0x8b8/0xb40 kernel/locking/qspinlock.c:508 > pv_queued_spin_lock_slowpath arch/x86/include/asm/paravirt.h:554 [inline] > queued_spin_lock_slowpath arch/x86/include/asm/qspinlock.h:51 [inline] > queued_spin_lock include/asm-generic/qspinlock.h:85 [inline] > do_raw_spin_lock+0x200/0x2b0 kernel/locking/spinlock_debug.c:113 > spin_lock include/linux/spinlock.h:354 [inline] > check_stack_usage kernel/exit.c:715 [inline] > do_exit+0x1d6a/0x2ae0 kernel/exit.c:868 > do_group_exit+0x125/0x310 kernel/exit.c:922 > __do_sys_exit_group kernel/exit.c:933 [inline] > __se_sys_exit_group kernel/exit.c:931 [inline] > __x64_sys_exit_group+0x3a/0x50 kernel/exit.c:931 > do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46 > entry_SYSCALL_64_after_hwframe+0x44/0xae > RIP: 0033:0x7ff7c19e9618 > Code: Unable to access opcode bytes at RIP 0x7ff7c19e95ee. > RSP: 002b:7fff88573528 EFLAGS: 0246 ORIG_RAX: 00e7 > RAX: ffda RBX: RCX: 7ff7c19e9618 > RDX: RSI: 003c RDI: > RBP: 55658b8146e0 R08: 00e7 R09: ff98 > R10: 55658bead6c0 R11: 0246 R12: 55658b8037a0 > R13: 7fff88573810 R14: R15: > > > --- > This report is generated by a bot. It may contain errors. > See https://goo.gl/tpsmEJ for more information about syzbot. > syzbot engineers can be reached at syzkal...@googlegroups.com. > > syzbot will keep track of this issue. See: > https://goo.gl/tpsmEJ#status for how to communicate with syzbot. > > -- > You received this message because you are subscribed to the Google Groups > "syzkaller-bugs" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to syzkaller-bugs+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/syzkaller-bugs/4b43a605bcd0545c%40google.com.
Re: [syzbot] bpf boot error: WARNING in kvm_wait
On Sat, Mar 6, 2021 at 12:28 PM syzbot wrote: > > Hello, > > syzbot found the following issue on: > > HEAD commit:edbea922 veth: Store queue_mapping independently of XDP pr.. > git tree: bpf > console output: https://syzkaller.appspot.com/x/log.txt?x=113ae02ad0 > kernel config: https://syzkaller.appspot.com/x/.config?x=402784bff477e1ac > dashboard link: https://syzkaller.appspot.com/bug?extid=46fc491326a456ff8127 > > IMPORTANT: if you fix the issue, please add the following tag to the commit: > Reported-by: syzbot+46fc491326a456ff8...@syzkaller.appspotmail.com #syz dup: upstream boot error: WARNING in kvm_wait > [ cut here ] > raw_local_irq_restore() called with IRQs enabled > WARNING: CPU: 0 PID: 4787 at kernel/locking/irqflag-debug.c:10 > warn_bogus_irq_restore+0x1d/0x20 kernel/locking/irqflag-debug.c:10 > Modules linked in: > CPU: 0 PID: 4787 Comm: systemd-getty-g Not tainted 5.11.0-syzkaller #0 > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS > Google 01/01/2011 > RIP: 0010:warn_bogus_irq_restore+0x1d/0x20 kernel/locking/irqflag-debug.c:10 > Code: be ff cc cc cc cc cc cc cc cc cc cc cc 80 3d 1e 62 b0 04 00 74 01 c3 48 > c7 c7 a0 8e 6b 89 c6 05 0d 62 b0 04 01 e8 57 da be ff <0f> 0b c3 48 39 77 10 > 0f 84 97 00 00 00 66 f7 47 22 f0 ff 74 4b 48 > RSP: 0018:c900012efc40 EFLAGS: 00010282 > RAX: RBX: 8be28b80 RCX: > RDX: 888023de5340 RSI: 815bea35 RDI: f5200025df7a > RBP: 0200 R08: R09: 0001 > R10: 815b77be R11: R12: 0003 > R13: fbfff17c5170 R14: 0001 R15: 8880b9c35f40 > FS: () GS:8880b9c0() knlGS: > CS: 0010 DS: ES: CR0: 80050033 > CR2: 7fa257bcaab4 CR3: 0bc8e000 CR4: 001506f0 > DR0: DR1: DR2: > DR3: DR6: fffe0ff0 DR7: 0400 > Call Trace: > kvm_wait arch/x86/kernel/kvm.c:860 [inline] > kvm_wait+0xc9/0xe0 arch/x86/kernel/kvm.c:837 > pv_wait arch/x86/include/asm/paravirt.h:564 [inline] > pv_wait_head_or_lock kernel/locking/qspinlock_paravirt.h:470 [inline] > __pv_queued_spin_lock_slowpath+0x8b8/0xb40 kernel/locking/qspinlock.c:508 > pv_queued_spin_lock_slowpath arch/x86/include/asm/paravirt.h:554 [inline] > queued_spin_lock_slowpath arch/x86/include/asm/qspinlock.h:51 [inline] > queued_spin_lock include/asm-generic/qspinlock.h:85 [inline] > do_raw_spin_lock+0x200/0x2b0 kernel/locking/spinlock_debug.c:113 > spin_lock include/linux/spinlock.h:354 [inline] > check_stack_usage kernel/exit.c:715 [inline] > do_exit+0x1d6a/0x2ae0 kernel/exit.c:868 > do_group_exit+0x125/0x310 kernel/exit.c:922 > __do_sys_exit_group kernel/exit.c:933 [inline] > __se_sys_exit_group kernel/exit.c:931 [inline] > __x64_sys_exit_group+0x3a/0x50 kernel/exit.c:931 > do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46 > entry_SYSCALL_64_after_hwframe+0x44/0xae > RIP: 0033:0x7fa2592a3618 > Code: Unable to access opcode bytes at RIP 0x7fa2592a35ee. > RSP: 002b:7ffc579980b8 EFLAGS: 0246 ORIG_RAX: 00e7 > RAX: ffda RBX: RCX: 7fa2592a3618 > RDX: RSI: 003c RDI: > RBP: 7fa2595808e0 R08: 00e7 R09: fee8 > R10: 7fa25775e158 R11: 0246 R12: 7fa2595808e0 > R13: 7fa259585c20 R14: R15: > > > --- > This report is generated by a bot. It may contain errors. > See https://goo.gl/tpsmEJ for more information about syzbot. > syzbot engineers can be reached at syzkal...@googlegroups.com. > > syzbot will keep track of this issue. See: > https://goo.gl/tpsmEJ#status for how to communicate with syzbot. > > -- > You received this message because you are subscribed to the Google Groups > "syzkaller-bugs" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to syzkaller-bugs+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/syzkaller-bugs/4094ff05bcdc7ffb%40google.com.
Re: [syzbot] net boot error: WARNING in kvm_wait
On Sat, Mar 6, 2021 at 8:37 AM syzbot wrote: > > Hello, > > syzbot found the following issue on: > > HEAD commit:ad5d07f4 cipso,calipso: resolve a number of problems with .. > git tree: net > console output: https://syzkaller.appspot.com/x/log.txt?x=12aca7cad0 > kernel config: https://syzkaller.appspot.com/x/.config?x=402784bff477e1ac > dashboard link: https://syzkaller.appspot.com/bug?extid=9e58a3a510889fa4af50 > > IMPORTANT: if you fix the issue, please add the following tag to the commit: > Reported-by: syzbot+9e58a3a510889fa4a...@syzkaller.appspotmail.com #syz dup: upstream boot error: WARNING in kvm_wait > [ cut here ] > raw_local_irq_restore() called with IRQs enabled > WARNING: CPU: 0 PID: 4788 at kernel/locking/irqflag-debug.c:10 > warn_bogus_irq_restore+0x1d/0x20 kernel/locking/irqflag-debug.c:10 > Modules linked in: > CPU: 0 PID: 4788 Comm: systemd-cryptse Not tainted 5.11.0-syzkaller #0 > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS > Google 01/01/2011 > RIP: 0010:warn_bogus_irq_restore+0x1d/0x20 kernel/locking/irqflag-debug.c:10 > Code: be ff cc cc cc cc cc cc cc cc cc cc cc 80 3d 1e 61 b0 04 00 74 01 c3 48 > c7 c7 a0 8e 6b 89 c6 05 0d 61 b0 04 01 e8 57 da be ff <0f> 0b c3 48 39 77 10 > 0f 84 97 00 00 00 66 f7 47 22 f0 ff 74 4b 48 > RSP: 0018:c9edfc40 EFLAGS: 00010282 > RAX: RBX: 8be28b80 RCX: > RDX: 888023441bc0 RSI: 815bea35 RDI: f520001dbf7a > RBP: 0200 R08: R09: 0001 > R10: 815b77be R11: R12: 0003 > R13: fbfff17c5170 R14: 0001 R15: 8880b9c35f40 > FS: () GS:8880b9c0() knlGS: > CS: 0010 DS: ES: CR0: 80050033 > CR2: 7f95c090fab4 CR3: 0bc8e000 CR4: 001506f0 > DR0: DR1: DR2: > DR3: DR6: fffe0ff0 DR7: 0400 > Call Trace: > kvm_wait arch/x86/kernel/kvm.c:860 [inline] > kvm_wait+0xc9/0xe0 arch/x86/kernel/kvm.c:837 > pv_wait arch/x86/include/asm/paravirt.h:564 [inline] > pv_wait_head_or_lock kernel/locking/qspinlock_paravirt.h:470 [inline] > __pv_queued_spin_lock_slowpath+0x8b8/0xb40 kernel/locking/qspinlock.c:508 > pv_queued_spin_lock_slowpath arch/x86/include/asm/paravirt.h:554 [inline] > queued_spin_lock_slowpath arch/x86/include/asm/qspinlock.h:51 [inline] > queued_spin_lock include/asm-generic/qspinlock.h:85 [inline] > do_raw_spin_lock+0x200/0x2b0 kernel/locking/spinlock_debug.c:113 > spin_lock include/linux/spinlock.h:354 [inline] > check_stack_usage kernel/exit.c:715 [inline] > do_exit+0x1d6a/0x2ae0 kernel/exit.c:868 > do_group_exit+0x125/0x310 kernel/exit.c:922 > __do_sys_exit_group kernel/exit.c:933 [inline] > __se_sys_exit_group kernel/exit.c:931 [inline] > __x64_sys_exit_group+0x3a/0x50 kernel/exit.c:931 > do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46 > entry_SYSCALL_64_after_hwframe+0x44/0xae > RIP: 0033:0x7f95c1fe8618 > Code: Unable to access opcode bytes at RIP 0x7f95c1fe85ee. > RSP: 002b:7fff576bc048 EFLAGS: 0246 ORIG_RAX: 00e7 > RAX: ffda RBX: RCX: 7f95c1fe8618 > RDX: RSI: 003c RDI: > RBP: 7f95c22c58e0 R08: 00e7 R09: fee8 > R10: 7f95c04a3158 R11: 0246 R12: 7f95c22c58e0 > R13: 7f95c22cac20 R14: R15: > > > --- > This report is generated by a bot. It may contain errors. > See https://goo.gl/tpsmEJ for more information about syzbot. > syzbot engineers can be reached at syzkal...@googlegroups.com. > > syzbot will keep track of this issue. See: > https://goo.gl/tpsmEJ#status for how to communicate with syzbot. > > -- > You received this message because you are subscribed to the Google Groups > "syzkaller-bugs" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to syzkaller-bugs+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/syzkaller-bugs/64c71f05bcd94585%40google.com.
Re: [syzbot] bpf-next boot error: WARNING in kvm_wait
On Sat, Mar 6, 2021 at 8:37 AM syzbot wrote: > > Hello, > > syzbot found the following issue on: > > HEAD commit:d01b59c9 bpf: Add bpf_skb_adjust_room flag BPF_F_ADJ_ROOM_.. > git tree: bpf-next > console output: https://syzkaller.appspot.com/x/log.txt?x=1592bd66d0 > kernel config: https://syzkaller.appspot.com/x/.config?x=66df2ca4f2dd3022 > dashboard link: https://syzkaller.appspot.com/bug?extid=72d60f48cda58f46375a > > IMPORTANT: if you fix the issue, please add the following tag to the commit: > Reported-by: syzbot+72d60f48cda58f463...@syzkaller.appspotmail.com #syz dup: upstream boot error: WARNING in kvm_wait > [ cut here ] > raw_local_irq_restore() called with IRQs enabled > WARNING: CPU: 0 PID: 4813 at kernel/locking/irqflag-debug.c:10 > warn_bogus_irq_restore+0x1d/0x20 kernel/locking/irqflag-debug.c:10 > Modules linked in: > CPU: 0 PID: 4813 Comm: systemd-cryptse Not tainted 5.11.0-syzkaller #0 > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS > Google 01/01/2011 > RIP: 0010:warn_bogus_irq_restore+0x1d/0x20 kernel/locking/irqflag-debug.c:10 > Code: bf ff cc cc cc cc cc cc cc cc cc cc cc 80 3d ca 72 b1 04 00 74 01 c3 48 > c7 c7 40 a2 6b 89 c6 05 b9 72 b1 04 01 e8 b8 37 bf ff <0f> 0b c3 48 39 77 10 > 0f 84 97 00 00 00 66 f7 47 22 f0 ff 74 4b 48 > RSP: 0018:c900012dfc40 EFLAGS: 00010282 > RAX: RBX: 8be287a0 RCX: > RDX: 88802383 RSI: 815b6895 RDI: f5200025bf7a > RBP: 0200 R08: R09: 0001 > R10: 815af76e R11: R12: 0003 > R13: fbfff17c50f4 R14: 0001 R15: 8880b9c35f40 > FS: () GS:8880b9c0() knlGS: > CS: 0010 DS: ES: CR0: 80050033 > CR2: 7f1b759e04b0 CR3: 0bc8e000 CR4: 001506f0 > DR0: DR1: DR2: > DR3: DR6: fffe0ff0 DR7: 0400 > Call Trace: > kvm_wait arch/x86/kernel/kvm.c:860 [inline] > kvm_wait+0xc9/0xe0 arch/x86/kernel/kvm.c:837 > pv_wait arch/x86/include/asm/paravirt.h:564 [inline] > pv_wait_head_or_lock kernel/locking/qspinlock_paravirt.h:470 [inline] > __pv_queued_spin_lock_slowpath+0x8b8/0xb40 kernel/locking/qspinlock.c:508 > pv_queued_spin_lock_slowpath arch/x86/include/asm/paravirt.h:554 [inline] > queued_spin_lock_slowpath arch/x86/include/asm/qspinlock.h:51 [inline] > queued_spin_lock include/asm-generic/qspinlock.h:85 [inline] > do_raw_spin_lock+0x200/0x2b0 kernel/locking/spinlock_debug.c:113 > spin_lock include/linux/spinlock.h:354 [inline] > check_stack_usage kernel/exit.c:715 [inline] > do_exit+0x1d6a/0x2ae0 kernel/exit.c:868 > do_group_exit+0x125/0x310 kernel/exit.c:922 > __do_sys_exit_group kernel/exit.c:933 [inline] > __se_sys_exit_group kernel/exit.c:931 [inline] > __x64_sys_exit_group+0x3a/0x50 kernel/exit.c:931 > do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46 > entry_SYSCALL_64_after_hwframe+0x44/0xae > RIP: 0033:0x7fed7b5d0618 > Code: Unable to access opcode bytes at RIP 0x7fed7b5d05ee. > RSP: 002b:7fff094428a8 EFLAGS: 0246 ORIG_RAX: 00e7 > RAX: ffda RBX: RCX: 7fed7b5d0618 > RDX: RSI: 003c RDI: > RBP: 7fed7b8ad8e0 R08: 00e7 R09: fee8 > R10: 7fed79a8b158 R11: 0246 R12: 7fed7b8ad8e0 > R13: 7fed7b8b2c20 R14: R15: > > > --- > This report is generated by a bot. It may contain errors. > See https://goo.gl/tpsmEJ for more information about syzbot. > syzbot engineers can be reached at syzkal...@googlegroups.com. > > syzbot will keep track of this issue. See: > https://goo.gl/tpsmEJ#status for how to communicate with syzbot. > > -- > You received this message because you are subscribed to the Google Groups > "syzkaller-bugs" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to syzkaller-bugs+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/syzkaller-bugs/67a89205bcd94527%40google.com.
Re: [syzbot] WARNING in kvm_wait
On Tue, Mar 9, 2021 at 12:29 AM 'Sean Christopherson' via syzkaller-bugs wrote: > > On Mon, Mar 08, 2021, syzbot wrote: > > Hello, > > > > syzbot found the following issue on: > > > > HEAD commit:a38fd874 Linux 5.12-rc2 > > git tree: upstream > > console output: https://syzkaller.appspot.com/x/log.txt?x=14158fdad0 > > kernel config: https://syzkaller.appspot.com/x/.config?x=db9c6adb4986f2f2 > > dashboard link: https://syzkaller.appspot.com/bug?extid=3c2bc6358072ede0f11b > > syz repro: https://syzkaller.appspot.com/x/repro.syz?x=1096d35cd0 > > C reproducer: https://syzkaller.appspot.com/x/repro.c?x=16bf1e52d0 > > > > IMPORTANT: if you fix the issue, please add the following tag to the commit: > > Reported-by: syzbot+3c2bc6358072ede0f...@syzkaller.appspotmail.com > > Wanpeng has a patch posted to fix this[*], is there a way to retroactively > point > syzbot at that fix? > > [*] > https://lkml.kernel.org/r/1614057902-23774-1-git-send-email-wanpen...@tencent.com Great! Yes, it can be communicated to syzbot with: #syz fix: x86/kvm: Fix broken irq restoration in kvm_wait For details see: http://bit.do/syzbot#communication-with-syzbot
[PATCH] libnvdimm: Let revalidate_disk() revalidate region read-only
Previous kernels allowed the BLKROSET to override the disk's read-only
status. With that situation fixed the pmem driver needs to rely on
revalidate_disk() to clear the disk read-only status after the host
region has been marked read-write.
Recall that when libnvdimm determines that the persistent memory has
lost persistence (for example lack of energy to flush from DRAM to FLASH
on an NVDIMM-N device) it marks the region read-only, but that state can
be overridden by the user via:
echo 0 > /sys/bus/nd/devices/regionX/read_only
...to date there is no notification that the region has restored
persistence, so the user override is the only recovery.
Fixes: 52f019d43c22 ("block: add a hard-readonly flag to struct gendisk")
Cc: Christoph Hellwig
Cc: Ming Lei
Cc: Martin K. Petersen
Cc: Hannes Reinecke
Cc: Jens Axboe
Reported-by: kernel test robot
Reported-by: Vishal Verma
Signed-off-by: Dan Williams
---
drivers/nvdimm/btt.c |7 +++
drivers/nvdimm/bus.c | 14 ++
drivers/nvdimm/pmem.c |7 +++
3 files changed, 20 insertions(+), 8 deletions(-)
diff --git a/drivers/nvdimm/btt.c b/drivers/nvdimm/btt.c
index 41aa1f01fc07..73d3bf5aa208 100644
--- a/drivers/nvdimm/btt.c
+++ b/drivers/nvdimm/btt.c
@@ -1508,11 +1508,18 @@ static int btt_getgeo(struct block_device *bd, struct
hd_geometry *geo)
return 0;
}
+static int btt_revalidate(struct gendisk *disk)
+{
+ nvdimm_check_and_set_ro(disk);
+ return 0;
+}
+
static const struct block_device_operations btt_fops = {
.owner =THIS_MODULE,
.submit_bio = btt_submit_bio,
.rw_page = btt_rw_page,
.getgeo = btt_getgeo,
+ .revalidate_disk = btt_revalidate,
};
static int btt_blk_init(struct btt *btt)
diff --git a/drivers/nvdimm/bus.c b/drivers/nvdimm/bus.c
index 48f0985ca8a0..3a777d0073b7 100644
--- a/drivers/nvdimm/bus.c
+++ b/drivers/nvdimm/bus.c
@@ -631,16 +631,14 @@ void nvdimm_check_and_set_ro(struct gendisk *disk)
struct nd_region *nd_region = to_nd_region(dev->parent);
int disk_ro = get_disk_ro(disk);
- /*
-* Upgrade to read-only if the region is read-only preserve as
-* read-only if the disk is already read-only.
-*/
- if (disk_ro || nd_region->ro == disk_ro)
+ /* catch the disk up with the region ro state */
+ if (disk_ro == nd_region->ro)
return;
- dev_info(dev, "%s read-only, marking %s read-only\n",
- dev_name(_region->dev), disk->disk_name);
- set_disk_ro(disk, 1);
+ dev_info(dev, "%s read-%s, marking %s read-%s\n",
+dev_name(_region->dev), nd_region->ro ? "only" : "write",
+disk->disk_name, nd_region->ro ? "only" : "write");
+ set_disk_ro(disk, nd_region->ro);
}
EXPORT_SYMBOL(nvdimm_check_and_set_ro);
diff --git a/drivers/nvdimm/pmem.c b/drivers/nvdimm/pmem.c
index b8a85bfb2e95..af204fce1b1c 100644
--- a/drivers/nvdimm/pmem.c
+++ b/drivers/nvdimm/pmem.c
@@ -276,10 +276,17 @@ __weak long __pmem_direct_access(struct pmem_device
*pmem, pgoff_t pgoff,
return PHYS_PFN(pmem->size - pmem->pfn_pad - offset);
}
+static int pmem_revalidate(struct gendisk *disk)
+{
+ nvdimm_check_and_set_ro(disk);
+ return 0;
+}
+
static const struct block_device_operations pmem_fops = {
.owner =THIS_MODULE,
.submit_bio = pmem_submit_bio,
.rw_page = pmem_rw_page,
+ .revalidate_disk = pmem_revalidate,
};
static int pmem_dax_zero_page_range(struct dax_device *dax_dev, pgoff_t pgoff,
[PATCH] mmc: via-sdmmc: remove unneeded variable 'ret'
Fix the following coccicheck warning:
./drivers/mmc/host/via-sdmmc.c:1274:5-8: Unneeded variable: "ret".
Return "0" on line 1295
Reported-by: Abaci Robot
Signed-off-by: Yang Li
---
drivers/mmc/host/via-sdmmc.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/mmc/host/via-sdmmc.c b/drivers/mmc/host/via-sdmmc.c
index 4f4c081..a1d0985 100644
--- a/drivers/mmc/host/via-sdmmc.c
+++ b/drivers/mmc/host/via-sdmmc.c
@@ -1271,7 +1271,6 @@ static int __maybe_unused via_sd_suspend(struct device
*dev)
static int __maybe_unused via_sd_resume(struct device *dev)
{
struct via_crdr_mmc_host *sdhost;
- int ret = 0;
u8 gatt;
sdhost = dev_get_drvdata(dev);
@@ -1292,7 +1291,7 @@ static int __maybe_unused via_sd_resume(struct device
*dev)
via_restore_pcictrlreg(sdhost);
via_init_sdc_pm(sdhost);
- return ret;
+ return 0;
}
static SIMPLE_DEV_PM_OPS(via_sd_pm_ops, via_sd_suspend, via_sd_resume);
--
1.8.3.1
Re: linux-next: manual merge of the vhost tree with the sound tree
On Tue, 09 Mar 2021 02:58:33 +0100,
Stephen Rothwell wrote:
>
> Hi all,
>
> Today's linux-next merge of the vhost tree got conflicts in:
>
> sound/virtio/virtio_card.c
> sound/virtio/virtio_card.h
> sound/virtio/virtio_ctl_msg.c
> sound/virtio/virtio_pcm.c
> sound/virtio/virtio_pcm.h
> sound/virtio/virtio_pcm_msg.c
> sound/virtio/virtio_pcm_ops.c
>
> between commits:
>
> de3a9980d8c3 ("ALSA: virtio: add virtio sound driver")
> 9d45e514da88 ("ALSA: virtio: handling control messages")
> 29b96bf50ba9 ("ALSA: virtio: build PCM devices and substream hardware
> descriptors")
> f40a28679e0b ("ALSA: virtio: handling control and I/O messages for the PCM
> device")
> da76e9f3e43a ("ALSA: virtio: PCM substream operators")
> ca61a41f389c ("ALSA: virtio: introduce jack support")
> 19325fedf245 ("ALSA: virtio: introduce PCM channel map support")
> 575483e90a32 ("ALSA: virtio: introduce device suspend/resume support")
>
> from the sound tree and commits:
>
> 1e2fb08629e5 ("ALSA: virtio: add virtio sound driver")
> 3fb7ce161568 ("ALSA: virtio: handling control messages")
> 83ec5db56076 ("ALSA: virtio: build PCM devices and substream hardware
> descriptors")
> 68742d8557b8 ("ALSA: virtio: handling control and I/O messages for the PCM
> device")
> def2208d373b ("ALSA: virtio: PCM substream operators")
> 613515055d34 ("ALSA: virtio: introduce jack support")
> 96db428c31f1 ("ALSA: virtio: introduce PCM channel map support")
> 1f77f124f2f2 ("ALSA: virtio: introduce device suspend/resume support")
>
> from the vhost tree.
>
> I fixed it up (the sound tree commits have newer author dates, so I just
> used them) and can carry the fix as necessary. This is now fixed as far as
> linux-next is concerned, but any non trivial conflicts should be mentioned
> to your upstream maintainer when your tree is submitted for merging.
> You may also want to consider cooperating with the maintainer of the
> conflicting tree to minimise any particularly complex conflicts.
Michael, could you drop those? These must be the old versions that
contained lots of bugs. As already announced, you can pull from my
immutable branch, tagged virtio_snd-5.12-rc2, too.
Sorry for the mess!
Takashi
Re: [PATCH] crypto: sun8i-ss: Fix memory leak of object d when dma_iv fails to map
Le Tue, Mar 02, 2021 at 04:34:46PM +, Colin King a écrit :
> From: Colin Ian King
>
> In the case where the dma_iv mapping fails, the return error path leaks
> the memory allocated to object d. Fix this by adding a new error return
> label and jumping to this to ensure d is free'd before the return.
>
> Addresses-Coverity: ("Resource leak")
> Fixes: ac2614d721de ("crypto: sun8i-ss - Add support for the PRNG")
> Signed-off-by: Colin Ian King
> ---
> drivers/crypto/allwinner/sun8i-ss/sun8i-ss-prng.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/crypto/allwinner/sun8i-ss/sun8i-ss-prng.c
> b/drivers/crypto/allwinner/sun8i-ss/sun8i-ss-prng.c
> index 08a1473b2145..3191527928e4 100644
> --- a/drivers/crypto/allwinner/sun8i-ss/sun8i-ss-prng.c
> +++ b/drivers/crypto/allwinner/sun8i-ss/sun8i-ss-prng.c
> @@ -103,7 +103,8 @@ int sun8i_ss_prng_generate(struct crypto_rng *tfm, const
> u8 *src,
> dma_iv = dma_map_single(ss->dev, ctx->seed, ctx->slen, DMA_TO_DEVICE);
> if (dma_mapping_error(ss->dev, dma_iv)) {
> dev_err(ss->dev, "Cannot DMA MAP IV\n");
> - return -EFAULT;
> + err = -EFAULT;
> + goto err_free;
> }
>
> dma_dst = dma_map_single(ss->dev, d, todo, DMA_FROM_DEVICE);
> @@ -167,6 +168,7 @@ int sun8i_ss_prng_generate(struct crypto_rng *tfm, const
> u8 *src,
> memcpy(ctx->seed, d + dlen, ctx->slen);
> }
> memzero_explicit(d, todo);
> +err_free:
> kfree(d);
>
> return err;
> --
> 2.30.0
>
Hello
Tested-by: Corentin Labbe
Acked-by: Corentin Labbe
Thanks
Re: [PATCH] crypto: allwinner: sun8i-ce: fix error return code in sun8i_ce_prng_generate()
Le Thu, Mar 04, 2021 at 05:57:17PM -0800, Jia-Ju Bai a écrit :
> When dma_mapping_error() returns an error, no error return code of
> sun8i_ce_prng_generate() is assigned.
> To fix this bug, err is assigned with -EFAULT as error return code.
>
> Reported-by: TOTE Robot
> Signed-off-by: Jia-Ju Bai
> ---
> drivers/crypto/allwinner/sun8i-ce/sun8i-ce-prng.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/crypto/allwinner/sun8i-ce/sun8i-ce-prng.c
> b/drivers/crypto/allwinner/sun8i-ce/sun8i-ce-prng.c
> index cfde9ee4356b..cd1baee424a1 100644
> --- a/drivers/crypto/allwinner/sun8i-ce/sun8i-ce-prng.c
> +++ b/drivers/crypto/allwinner/sun8i-ce/sun8i-ce-prng.c
> @@ -99,6 +99,7 @@ int sun8i_ce_prng_generate(struct crypto_rng *tfm, const u8
> *src,
> dma_iv = dma_map_single(ce->dev, ctx->seed, ctx->slen, DMA_TO_DEVICE);
> if (dma_mapping_error(ce->dev, dma_iv)) {
> dev_err(ce->dev, "Cannot DMA MAP IV\n");
> + err = -EFAULT;
> goto err_iv;
> }
>
> --
> 2.17.1
>
Hello
Tested-by: Corentin Labbe
Acked-by: Corentin Labbe
Thanks
Re: [EXT] [PATCH v2 2/4] dt-bindings: spi: add compatible entry for imx8mp in FlexSPI controller
Hello Kuldeep, On 09.03.21 07:29, Kuldeep Singh wrote: >> Hi! >> >> On 09.03.21 06:56, Kuldeep Singh wrote: >>> Hi Heiko, >>> -Original Message- From: Heiko Schocher Sent: Tuesday, March 9, 2021 11:01 AM To: linux-arm-ker...@lists.infradead.org Cc: Heiko Schocher ; Ashish Kumar ; Mark Brown ; Rob Herring ; Yogesh Gaur ; devicet...@vger.kernel.org; linux- ker...@vger.kernel.org; linux-...@vger.kernel.org Subject: [EXT] [PATCH v2 2/4] dt-bindings: spi: add compatible entry for imx8mp in FlexSPI controller Caution: EXT Email add compatible entry "nxp,imx8mp-fspi" in NXP FlexSPI controller Signed-off-by: Heiko Schocher --- (no changes since v1) Documentation/devicetree/bindings/spi/spi-nxp-fspi.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/spi/spi-nxp-fspi.txt b/Documentation/devicetree/bindings/spi/spi-nxp-fspi.txt index 7ac60d9fe3571..fd5f081f6d91b 100644 --- a/Documentation/devicetree/bindings/spi/spi-nxp-fspi.txt +++ b/Documentation/devicetree/bindings/spi/spi-nxp-fspi.txt @@ -4,6 +4,7 @@ Required properties: - compatible : Should be "nxp,lx2160a-fspi" "nxp,imx8qxp-fspi" "nxp,imx8mm-fspi" + "nxp,imx8mp-fspi" >>> >>> It seems the changes are not on top of tree. Please see[1] for latest >>> changes >> including imx8dxl entry. >>> Snippet below: >>> >>> Required properties: >>> - compatible : Should be "nxp,lx2160a-fspi" >>> "nxp,imx8qxp-fspi" >>> "nxp,imx8mm-fspi" >>> "nxp,imx8dxl-fspi" >> >> My patches are based on mainline.. >> * 144c79ef33536 - (origin/master, origin/HEAD) Merge tag >> 'perf-tools-fixes-for- >> v5.12-2020-03-07' >> of git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux (vor 32 Stunden) >> >> >> Should I post this patch rebased on [1] or may all patches rebased on [1] ? > > Hi Heiko, > > As per cover letter, I can identify that first two are driver/Documentation > patches and other two are device-tree patches. > Device-tree patches(3/4 and 4/4) will go via Shawn tree > (git://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux.git) > And initial two driver patches(1/4 and 2/4) will go via Mark's tree > (git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git) > > One approach I can think of is to send driver patches first and later send > device-tree patches mentioning dependency on first two patches. Yep, seems a good approach to me. > Maybe Mark can comment here if he has any other opinion. Yep, will wait for more comments, and if all is fine with this patchset, I can split it into 2 series. Thanks! bye, Heiko -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-52 Fax: +49-8142-66989-80 Email: h...@denx.de
Re: [PATCH next 2/2] sound: usb: fix use after free in usb_audio_disconnect
On Mon, 08 Mar 2021 23:30:57 +0100,
Pavel Skripkin wrote:
>
> The problem was in wrong "if" placement. chip->quirk_type is freed
> in snd_card_free_when_closed(), but inside if statement it's accesed.
>
> Fixes: 9799110825db ("ALSA: usb-audio: Disable USB autosuspend properly in
> setup_disable_autosuspend()"
> Signed-off-by: Pavel Skripkin
Thanks, applied now.
Takashi
Re: [PATCH v2 7/7] CMDLINE: x86: convert to generic builtin command line
On Tue, 9 Mar 2021 at 01:03, Daniel Walker wrote:
>
> This updates the x86 code to use the CONFIG_GENERIC_CMDLINE
> option.
>
> Cc: xe-linux-exter...@cisco.com
> Signed-off-by: Ruslan Ruslichenko
> Signed-off-by: Ruslan Bilovol
> Signed-off-by: Daniel Walker
> ---
> arch/x86/Kconfig| 44 +
> arch/x86/kernel/setup.c | 18 ++
> drivers/firmware/efi/libstub/x86-stub.c | 2 +-
> 3 files changed, 4 insertions(+), 60 deletions(-)
>
> diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
> index 21f851179ff0..3950f9bf9855 100644
> --- a/arch/x86/Kconfig
> +++ b/arch/x86/Kconfig
> @@ -115,6 +115,7 @@ config X86
> select EDAC_SUPPORT
> select GENERIC_CLOCKEVENTS_BROADCASTif X86_64 || (X86_32 &&
> X86_LOCAL_APIC)
> select GENERIC_CLOCKEVENTS_MIN_ADJUST
> + select GENERIC_CMDLINE
> select GENERIC_CMOS_UPDATE
> select GENERIC_CPU_AUTOPROBE
> select GENERIC_CPU_VULNERABILITIES
> @@ -2368,49 +2369,6 @@ choice
>
> endchoice
>
> -config CMDLINE_BOOL
> - bool "Built-in kernel command line"
> - help
> - Allow for specifying boot arguments to the kernel at
> - build time. On some systems (e.g. embedded ones), it is
> - necessary or convenient to provide some or all of the
> - kernel boot arguments with the kernel itself (that is,
> - to not rely on the boot loader to provide them.)
> -
> - To compile command line arguments into the kernel,
> - set this option to 'Y', then fill in the
> - boot arguments in CONFIG_CMDLINE.
> -
> - Systems with fully functional boot loaders (i.e. non-embedded)
> - should leave this option set to 'N'.
> -
> -config CMDLINE
> - string "Built-in kernel command string"
> - depends on CMDLINE_BOOL
> - default ""
> - help
> - Enter arguments here that should be compiled into the kernel
> - image and used at boot time. If the boot loader provides a
> - command line at boot time, it is appended to this string to
> - form the full kernel command line, when the system boots.
> -
> - However, you can use the CONFIG_CMDLINE_OVERRIDE option to
> - change this behavior.
> -
> - In most cases, the command line (whether built-in or provided
> - by the boot loader) should specify the device for the root
> - file system.
> -
> -config CMDLINE_OVERRIDE
> - bool "Built-in command line overrides boot loader arguments"
> - depends on CMDLINE_BOOL && CMDLINE != ""
> - help
> - Set this option to 'Y' to have the kernel ignore the boot loader
> - command line, and use ONLY the built-in command line.
> -
> - This is used to work around broken boot loaders. This should
> - be set to 'N' under normal conditions.
> -
> config MODIFY_LDT_SYSCALL
> bool "Enable the LDT (local descriptor table)" if EXPERT
> default y
> diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
> index 740f3bdb3f61..e748c3e5c1ae 100644
> --- a/arch/x86/kernel/setup.c
> +++ b/arch/x86/kernel/setup.c
> @@ -48,6 +48,7 @@
> #include
> #include
> #include
> +#include
>
> /*
> * max_low_pfn_mapped: highest directly mapped pfn < 4 GB
> @@ -162,9 +163,6 @@ unsigned long saved_video_mode;
> #define RAMDISK_LOAD_FLAG 0x4000
>
> static char __initdata command_line[COMMAND_LINE_SIZE];
> -#ifdef CONFIG_CMDLINE_BOOL
> -static char __initdata builtin_cmdline[COMMAND_LINE_SIZE] = CONFIG_CMDLINE;
> -#endif
>
> #if defined(CONFIG_EDD) || defined(CONFIG_EDD_MODULE)
> struct edd edd;
> @@ -884,19 +882,7 @@ void __init setup_arch(char **cmdline_p)
> bss_resource.start = __pa_symbol(__bss_start);
> bss_resource.end = __pa_symbol(__bss_stop)-1;
>
> -#ifdef CONFIG_CMDLINE_BOOL
> -#ifdef CONFIG_CMDLINE_OVERRIDE
> - strlcpy(boot_command_line, builtin_cmdline, COMMAND_LINE_SIZE);
> -#else
> - if (builtin_cmdline[0]) {
> - /* append boot loader cmdline to builtin */
> - strlcat(builtin_cmdline, " ", COMMAND_LINE_SIZE);
> - strlcat(builtin_cmdline, boot_command_line,
> COMMAND_LINE_SIZE);
> - strlcpy(boot_command_line, builtin_cmdline,
> COMMAND_LINE_SIZE);
> - }
> -#endif
> -#endif
> -
> + cmdline_add_builtin(boot_command_line, NULL, COMMAND_LINE_SIZE);
> strlcpy(command_line, boot_command_line, COMMAND_LINE_SIZE);
> *cmdline_p = command_line;
>
> diff --git a/drivers/firmware/efi/libstub/x86-stub.c
> b/drivers/firmware/efi/libstub/x86-stub.c
> index f14c4ff5839f..9538c9d4a0bc 100644
> --- a/drivers/firmware/efi/libstub/x86-stub.c
> +++ b/drivers/firmware/efi/libstub/x86-stub.c
> @@ -736,7 +736,7 @@ unsigned long efi_main(efi_handle_t handle,
> }
>
> #ifdef CONFIG_CMDLINE_BOOL
Does this CMDLINE_BOOL check need to be dropped as well?
[PATCH] scsi: 3w-sas: remove unneeded variable 'retval'
Fix the following coccicheck warning: ./drivers/scsi/3w-sas.c:866:5-11: Unneeded variable: "retval". Return "1" on line 898 Reported-by: Abaci Robot Signed-off-by: Yang Li --- drivers/scsi/3w-sas.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/scsi/3w-sas.c b/drivers/scsi/3w-sas.c index 3db0e42..eae706e 100644 --- a/drivers/scsi/3w-sas.c +++ b/drivers/scsi/3w-sas.c @@ -863,7 +863,6 @@ static int twl_fill_sense(TW_Device_Extension *tw_dev, int i, int request_id, in TW_Command_Full *full_command_packet; unsigned short error; char *error_str; - int retval = 1; header = tw_dev->sense_buffer_virt[i]; full_command_packet = tw_dev->command_packet_virt[request_id]; @@ -895,7 +894,7 @@ static int twl_fill_sense(TW_Device_Extension *tw_dev, int i, int request_id, in goto out; } out: - return retval; + return 1; } /* End twl_fill_sense() */ /* This function will free up device extension resources */ -- 1.8.3.1
Re: [PATCH 2/3] iommu/io-pgtable-arm: Add IOMMU_LLC page protection flag
Hi, On 2021-02-05 17:38, Sai Prakash Ranjan wrote: On 2021-02-04 03:16, Will Deacon wrote: On Tue, Feb 02, 2021 at 11:56:27AM +0530, Sai Prakash Ranjan wrote: On 2021-02-01 23:50, Jordan Crouse wrote: > On Mon, Feb 01, 2021 at 08:20:44AM -0800, Rob Clark wrote: > > On Mon, Feb 1, 2021 at 3:16 AM Will Deacon wrote: > > > On Fri, Jan 29, 2021 at 03:12:59PM +0530, Sai Prakash Ranjan wrote: > > > > On 2021-01-29 14:35, Will Deacon wrote: > > > > > On Mon, Jan 11, 2021 at 07:45:04PM +0530, Sai Prakash Ranjan wrote: > > > > > > +#define IOMMU_LLC(1 << 6) > > > > > > > > > > On reflection, I'm a bit worried about exposing this because I think it > > > > > will > > > > > introduce a mismatched virtual alias with the CPU (we don't even have a > > > > > MAIR > > > > > set up for this memory type). Now, we also have that issue for the PTW, > > > > > but > > > > > since we always use cache maintenance (i.e. the streaming API) for > > > > > publishing the page-tables to a non-coheren walker, it works out. > > > > > However, > > > > > if somebody expects IOMMU_LLC to be coherent with a DMA API coherent > > > > > allocation, then they're potentially in for a nasty surprise due to the > > > > > mismatched outer-cacheability attributes. > > > > > > > > > > > > > Can't we add the syscached memory type similar to what is done on android? > > > > > > Maybe. How does the GPU driver map these things on the CPU side? > > > > Currently we use writecombine mappings for everything, although there > > are some cases that we'd like to use cached (but have not merged > > patches that would give userspace a way to flush/invalidate) > > > > LLC/system cache doesn't have a relationship with the CPU cache. Its > just a > little accelerator that sits on the connection from the GPU to DDR and > caches > accesses. The hint that Sai is suggesting is used to mark the buffers as > 'no-write-allocate' to prevent GPU write operations from being cached in > the LLC > which a) isn't interesting and b) takes up cache space for read > operations. > > Its easiest to think of the LLC as a bonus accelerator that has no cost > for > us to use outside of the unfortunate per buffer hint. > > We do have to worry about the CPU cache w.r.t I/O coherency (which is a > different hint) and in that case we have all of concerns that Will > identified. > For mismatched outer cacheability attributes which Will mentioned, I was referring to [1] in android kernel. I've lost track of the conversation here :/ When the GPU has a buffer mapped with IOMMU_LLC, is the buffer also mapped into the CPU and with what attributes? Rob said "writecombine for everything" -- does that mean ioremap_wc() / MEMREMAP_WC? Rob answered this. Finally, we need to be careful when we use the word "hint" as "allocation hint" has a specific meaning in the architecture, and if we only mismatch on those then we're actually ok. But I think IOMMU_LLC is more than just a hint, since it actually drives eviction policy (i.e. it enables writeback). Sorry for the pedantry, but I just want to make sure we're all talking about the same things! Sorry for the confusion which probably was caused by my mentioning of android, NWA(no write allocate) is an allocation hint which we can ignore for now as it is not introduced yet in upstream. Any chance of taking this forward? We do not want to miss out on small fps gain when the product gets released. Thanks, Sai -- QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
Re: [PATCH v2 00/10] fsdax,xfs: Add reflink support for fsdax
hi, First thanks for your patchset. I'd like to know whether your patchset pass fstests? Thanks. Regards, Xiaoguang Wang This patchset is attempt to add CoW support for fsdax, and take XFS, which has both reflink and fsdax feature, as an example. Changes from V1: - Factor some helper functions to simplify dax fault code - Introduce iomap_apply2() for dax_dedupe_file_range_compare() - Fix mistakes and other problems - Rebased on v5.11 One of the key mechanism need to be implemented in fsdax is CoW. Copy the data from srcmap before we actually write data to the destance iomap. And we just copy range in which data won't be changed. Another mechanism is range comparison. In page cache case, readpage() is used to load data on disk to page cache in order to be able to compare data. In fsdax case, readpage() does not work. So, we need another compare data with direct access support. With the two mechanism implemented in fsdax, we are able to make reflink and fsdax work together in XFS. Some of the patches are picked up from Goldwyn's patchset. I made some changes to adapt to this patchset. (Rebased on v5.11) == Shiyang Ruan (10): fsdax: Factor helpers to simplify dax fault code fsdax: Factor helper: dax_fault_actor() fsdax: Output address in dax_iomap_pfn() and rename it fsdax: Introduce dax_iomap_cow_copy() fsdax: Replace mmap entry in case of CoW fsdax: Add dax_iomap_cow_copy() for dax_iomap_zero iomap: Introduce iomap_apply2() for operations on two files fsdax: Dedup file range to use a compare function fs/xfs: Handle CoW for fsdax write() path fs/xfs: Add dedupe support for fsdax fs/dax.c | 532 +++-- fs/iomap/apply.c | 51 fs/iomap/buffered-io.c | 2 +- fs/remap_range.c | 45 +++- fs/xfs/xfs_bmap_util.c | 3 +- fs/xfs/xfs_file.c | 29 ++- fs/xfs/xfs_inode.c | 8 +- fs/xfs/xfs_inode.h | 1 + fs/xfs/xfs_iomap.c | 30 ++- fs/xfs/xfs_iomap.h | 1 + fs/xfs/xfs_iops.c | 11 +- fs/xfs/xfs_reflink.c | 16 +- include/linux/dax.h| 7 +- include/linux/fs.h | 15 +- include/linux/iomap.h | 7 +- 15 files changed, 550 insertions(+), 208 deletions(-)
[PATCH v5] coccinelle: misc: add minmax script
Check for opencoded min(), max() implementations.
Signed-off-by: Denis Efremov
---
Changes in v2:
- <... ...> instead of ... when any
- org mode reports fixed
- patch rule to drop excessive ()
Changes in v3:
- "depends on patch && (pmax || pmaxif || pmin || pminif)" fixed
Changes in v4:
- refarmatting rule removed
- () brackets added to the patch rules to omit excessive ones
- org/report prints changed to cycle (for p0 in p: ...)
Changes in v5:
- parentheses droppped in pminif and pmaxif rules (max_val = x ...)
scripts/coccinelle/misc/minmax.cocci | 206 +++
1 file changed, 206 insertions(+)
create mode 100644 scripts/coccinelle/misc/minmax.cocci
diff --git a/scripts/coccinelle/misc/minmax.cocci
b/scripts/coccinelle/misc/minmax.cocci
new file mode 100644
index ..eccdd3eb3452
--- /dev/null
+++ b/scripts/coccinelle/misc/minmax.cocci
@@ -0,0 +1,206 @@
+// SPDX-License-Identifier: GPL-2.0-only
+///
+/// Check for opencoded min(), max() implementations.
+/// Generated patches sometimes require adding a cast to fix compile warning.
+/// Warnings/patches scope intentionally limited to a function body.
+///
+// Confidence: Medium
+// Copyright: (C) 2021 Denis Efremov ISPRAS
+// Options: --no-includes --include-headers
+//
+// Keywords: min, max
+//
+
+
+virtual report
+virtual org
+virtual context
+virtual patch
+
+@rmax depends on !patch@
+identifier func;
+expression x, y;
+binary operator cmp = {>, >=};
+position p;
+@@
+
+func(...)
+{
+ <...
+* ((x) cmp@p (y) ? (x) : (y))
+ ...>
+}
+
+@rmaxif depends on !patch@
+identifier func;
+expression x, y;
+expression max_val;
+binary operator cmp = {>, >=};
+position p;
+@@
+
+func(...)
+{
+ <...
+* if ((x) cmp@p (y)) {
+* max_val = (x);
+* } else {
+* max_val = (y);
+* }
+ ...>
+}
+
+@rmin depends on !patch@
+identifier func;
+expression x, y;
+binary operator cmp = {<, <=};
+position p;
+@@
+
+func(...)
+{
+ <...
+* ((x) cmp@p (y) ? (x) : (y))
+ ...>
+}
+
+@rminif depends on !patch@
+identifier func;
+expression x, y;
+expression min_val;
+binary operator cmp = {<, <=};
+position p;
+@@
+
+func(...)
+{
+ <...
+* if ((x) cmp@p (y)) {
+* min_val = (x);
+* } else {
+* min_val = (y);
+* }
+ ...>
+}
+
+@pmax depends on patch@
+identifier func;
+expression x, y;
+binary operator cmp = {>=, >};
+@@
+
+func(...)
+{
+ <...
+- ((x) cmp (y) ? (x) : (y))
++ max(x, y)
+ ...>
+}
+
+@pmaxif depends on patch@
+identifier func;
+expression x, y;
+expression max_val;
+binary operator cmp = {>=, >};
+@@
+
+func(...)
+{
+ <...
+- if ((x) cmp (y)) {
+- max_val = x;
+- } else {
+- max_val = y;
+- }
++ max_val = max(x, y);
+ ...>
+}
+
+@pmin depends on patch@
+identifier func;
+expression x, y;
+binary operator cmp = {<=, <};
+@@
+
+func(...)
+{
+ <...
+- ((x) cmp (y) ? (x) : (y))
++ min(x, y)
+ ...>
+}
+
+@pminif depends on patch@
+identifier func;
+expression x, y;
+expression min_val;
+binary operator cmp = {<=, <};
+@@
+
+func(...)
+{
+ <...
+- if ((x) cmp (y)) {
+- min_val = x;
+- } else {
+- min_val = y;
+- }
++ min_val = min(x, y);
+ ...>
+}
+
+@script:python depends on report@
+p << rmax.p;
+@@
+
+for p0 in p:
+ coccilib.report.print_report(p0, "WARNING opportunity for max()")
+
+@script:python depends on org@
+p << rmax.p;
+@@
+
+for p0 in p:
+ coccilib.org.print_todo(p0, "WARNING opportunity for max()")
+
+@script:python depends on report@
+p << rmaxif.p;
+@@
+
+for p0 in p:
+ coccilib.report.print_report(p0, "WARNING opportunity for max()")
+
+@script:python depends on org@
+p << rmaxif.p;
+@@
+
+for p0 in p:
+ coccilib.org.print_todo(p0, "WARNING opportunity for max()")
+
+@script:python depends on report@
+p << rmin.p;
+@@
+
+for p0 in p:
+ coccilib.report.print_report(p0, "WARNING opportunity for min()")
+
+@script:python depends on org@
+p << rmin.p;
+@@
+
+for p0 in p:
+ coccilib.org.print_todo(p0, "WARNING opportunity for min()")
+
+@script:python depends on report@
+p << rminif.p;
+@@
+
+for p0 in p:
+ coccilib.report.print_report(p0, "WARNING opportunity for min()")
+
+@script:python depends on org@
+p << rminif.p;
+@@
+
+for p0 in p:
+ coccilib.org.print_todo(p0, "WARNING opportunity for min()")
--
2.26.2
Re: [PATCHv2 0/4] perf/core: Add support to exclude kernel mode PMU tracing
Hi Andi, On 2021-03-05 01:47, Andi Kleen wrote: > Andi Kleen writes: >> >> Normally disk encryption is in specialized work queues. It's total >> overkill to restrict all of the kernel if you just want to restrict >> those work queues. >> >> I would suggest some more analysis where secrets are actually stored >> and handled first. > > Also thinking about this more: > > You really only want to limit data tracing here. > > If tracing branches could reveal secrets the crypto code would be > already insecure due to timing side channels. If that's the > case it would already require fixing the crypto code. > The disk encryption is just one example and there might be others which we might not be aware of yet and we are not suspecting there is something wrong with the crypto code that needs to be fixed. Here the idea was to restrict an external(in the sense that its not related to crypto or any other security related component) entity such as hardware assisted tracing like ARM coresight and so on. I don't see why or how the crypto code needs to be fixed for something that is not related to it although it is affected. The analogy would be like of the victims and a perpetrator. Lets take coresight as an example for perpetrator and crypto as the victim here. Now we can try to harden the protection and safeguard the victims which may or may not be successful but it will be possible only if we know the victims beforehand. If we just know one victim (lets say crypto code here), what happens to the others which we haven't identified yet? Do we just wait for someone to write an exploit based on this and then scramble to fix it? Now the other foolproof way of saving the victims would be locking down the perpetrator which would definitely save all the victims but that needs the perpetrator to be identified. In our case, the perpetrator (coresight or any other hw tracing) is already known, so we want to lock it down or restrict it so that if there is actually a vulnerability in crypto or other areas, then this HW assisted tracing wouldn't be able to help exploit it. Initial change was to restrict this only to HW assisted instruction tracing [1] but Peter wasn't convinced that this applies to only instruction tracing. Hence this change for all kernel level pmu tracing. And this is a configurable option via kernel config so that we don't force it on everyone. This config is also required for coresight etm drivers because they have a sysfs mode of tracing as well in addition to perf mode. [1] https://lore.kernel.org/lkml/cover.1611909025.git.saiprakash.ran...@codeaurora.org/ Thanks, Sai -- QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
Re: [PATCH] mm/memory-failure: Use a mutex to avoid memory_failure() races
On Tue, 9 Mar 2021 06:04:41 +
HORIGUCHI NAOYA(堀口 直也) wrote:
> ...
> >
> > If others are OK with this method, then I am OK too.
> > But I have two concerns, May you take into account:
> >
> > 1. The memory_failure with 0 return code for race condition, then the
> > kill_me_maybe() goes into branch:
> > if (!memory_failure(p->mce_addr >> PAGE_SHIFT, flags) &&
> > !(p->mce_kflags & MCE_IN_KERNEL_COPYIN)) {
> > set_mce_nospec(p->mce_addr >> PAGE_SHIFT, p->mce_whole_page);
> > sync_core();
> > return;
> > }
> >
> > while we place set_mce_nospec() here is for a reason, please see commit
> > fd0e786d9d09024f67b.
> >
> > 2. When memory_failure return 0 and maybe return to user process, and it
> > may re-execute the instruction triggering previous fault, this behavior
> > assume an implicit dependence that the related pte has been correctly set.
> > or if not correctlily set, it will lead to infinite loop again.
>
> These seem to be separate issues from memory_failure()'s concurrency issue,
> so I'm still expecting that your patch is to be merged. Maybe do you want
> to update it based on the discussion (if it's concluded)?
>
> Thanks,
> Naoya Horiguchi
I have submitted a v2 patch, and please help review.
Thanks!
--
Thanks!
Aili Yao
Re: [PATCH v6 1/1] iio/scmi: Adding support for IIO SCMI Based Sensors
On Mon, Mar 08, 2021 at 07:48:41PM +, Jonathan Cameron wrote: > On Mon, 8 Mar 2021 04:28:42 + > Sudeep Holla wrote: > > > Hi Jonathan, > > > > On Tue, Feb 23, 2021 at 10:30:37AM -0800, Jyoti Bhayana wrote: > > > Hi Jonathan, > > > > > > Thanks for the detailed and careful review of this patch. Good to hear > > > that v7 is not required. Please find below answers to your > > > questions. Looking forward to seeing this patch merged in the next > > > cycle. Thanks for your help in making this happen. > > > > > > > Any update on this ? Please share the branch with is patch so that I > > can pull and ask Cristian to make his changes on top. > Running a bit behind at the moment. > No worries. > Anyhow, there should now be an ib-iio-scmi-5.12-rc1 branch > on https://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio.git > Thanks > Includes making the various long long local variables explicitly > s64 and u64 as relevant. > > Based on the rc1 that eats babies so handle with care :) > > I've also merge this into the togreg branch of iio.git. > As explained above that wasn't entirely trivial so Jyoti > please take a quick look and check that changes are fine. > Pushed out as testing to let the autobuilders poke at it. > Assuming they don't find anything, it should be fine > for Sudeep to merge that ib and everything will unwind > nicely in Linus' tree next cycle. > Hope so. > There is a bit of an ongoing discussion of an earlier patch > in the IIO tree, so I might end up redoing this merge > if I need to rebase to sort that out, but I'll make sure > the diff is the same (git ID might change). > I can wait for a week or 2 if you think things will settle down by then. We can avoid 2 different git IDs if possible. The main intention was to give some reference to Cristian to rebase/post his series. I am all fine to wait for a week or 2 for final branch. -- Regards, Sudeep
Re: [PATCH next 1/2] sound: usb: fix NULL ptr dereference in usb_audio_probe
On Mon, 08 Mar 2021 23:30:36 +0100,
Pavel Skripkin wrote:
>
> syzbot reported null pointer dereference in usb_audio_probe.
> The problem was in case, when quirk == NULL. It's not an
> error condition, so quirk must be checked before dereferencing.
>
> Call Trace:
> usb_probe_interface+0x315/0x7f0 drivers/usb/core/driver.c:396
> really_probe+0x291/0xe60 drivers/base/dd.c:554
> driver_probe_device+0x26b/0x3d0 drivers/base/dd.c:740
> __device_attach_driver+0x1d1/0x290 drivers/base/dd.c:846
> bus_for_each_drv+0x15f/0x1e0 drivers/base/bus.c:431
> __device_attach+0x228/0x4a0 drivers/base/dd.c:914
> bus_probe_device+0x1e4/0x290 drivers/base/bus.c:491
> device_add+0xbdb/0x1db0 drivers/base/core.c:3242
> usb_set_configuration+0x113f/0x1910 drivers/usb/core/message.c:2164
> usb_generic_driver_probe+0xba/0x100 drivers/usb/core/generic.c:238
> usb_probe_device+0xd9/0x2c0 drivers/usb/core/driver.c:293
> really_probe+0x291/0xe60 drivers/base/dd.c:554
> driver_probe_device+0x26b/0x3d0 drivers/base/dd.c:740
> __device_attach_driver+0x1d1/0x290 drivers/base/dd.c:846
> bus_for_each_drv+0x15f/0x1e0 drivers/base/bus.c:431
> __device_attach+0x228/0x4a0 drivers/base/dd.c:914
> bus_probe_device+0x1e4/0x290 drivers/base/bus.c:491
> device_add+0xbdb/0x1db0 drivers/base/core.c:3242
> usb_new_device.cold+0x721/0x1058 drivers/usb/core/hub.c:2555
> hub_port_connect drivers/usb/core/hub.c:5223 [inline]
> hub_port_connect_change drivers/usb/core/hub.c:5363 [inline]
> port_event drivers/usb/core/hub.c:5509 [inline]
> hub_event+0x2357/0x4320 drivers/usb/core/hub.c:5591
> process_one_work+0x98d/0x1600 kernel/workqueue.c:2275
> worker_thread+0x64c/0x1120 kernel/workqueue.c:2421
> kthread+0x3b1/0x4a0 kernel/kthread.c:292
> ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:294
>
> Reported-by: syzbot+719da9b149a931f51...@syzkaller.appspotmail.com
> Fixes: 9799110825db ("ALSA: usb-audio: Disable USB autosuspend properly in
> setup_disable_autosuspend()")
> Signed-off-by: Pavel Skripkin
Thanks, applied now.
Takashi
[PATCH v2] mm,hwpoison: return -EBUSY when page already poisoned
When the page is already poisoned, another memory_failure() call in the
same page now return 0, meaning OK. For nested memory mce handling, this
behavior may lead to mce looping, Example:
1.When LCME is enabled, and there are two processes A && B running on
different core X && Y separately, which will access one same page, then
the page corrupted when process A access it, a MCE will be rasied to
core X and the error process is just underway.
2.Then B access the page and trigger another MCE to core Y, it will also
do error process, it will see TestSetPageHWPoison be true, and 0 is
returned.
3.The kill_me_maybe will check the return:
1244 static void kill_me_maybe(struct callback_head *cb)
1245 {
1254 if (!memory_failure(p->mce_addr >> PAGE_SHIFT, flags) &&
1255 !(p->mce_kflags & MCE_IN_KERNEL_COPYIN)) {
1256 set_mce_nospec(p->mce_addr >> PAGE_SHIFT,
p->mce_whole_page);
1257 sync_core();
1258 return;
1259 }
1267 }
4. The error process for B will end, and may nothing happened if
kill-early is not set, The process B will re-excute instruction and get
into mce again and then loop happens. And also the set_mce_nospec()
here is not proper, may refer to commit fd0e786d9d09 ("x86/mm,
mm/hwpoison: Don't unconditionally unmap kernel 1:1 pages").
For other cases which care the return value of memory_failure() should
check why they want to process a memory error which have already been
processed. This behavior seems reasonable.
Signed-off-by: Aili Yao
---
mm/memory-failure.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/mm/memory-failure.c b/mm/memory-failure.c
index 24210c9bd843..b6bc77460ee1 100644
--- a/mm/memory-failure.c
+++ b/mm/memory-failure.c
@@ -1228,7 +1228,7 @@ static int memory_failure_hugetlb(unsigned long pfn, int
flags)
if (TestSetPageHWPoison(head)) {
pr_err("Memory failure: %#lx: already hardware poisoned\n",
pfn);
- return 0;
+ return -EBUSY;
}
num_poisoned_pages_inc();
@@ -1430,7 +1430,7 @@ int memory_failure(unsigned long pfn, int flags)
if (TestSetPageHWPoison(p)) {
pr_err("Memory failure: %#lx: already hardware poisoned\n",
pfn);
- return 0;
+ return -EBUSY;
}
orig_head = hpage = compound_head(p);
--
2.25.1
Re: [PATCH] SOUND: pci: hda: Add Sound BlasterX AE-5 Plus support
On Mon, 08 Mar 2021 19:48:35 +0100, Simeon Simeonoff wrote: > > > The new AE-5 Plus model has a different Subsystem ID compared to the > non-plus model. Adding the new id to the list of quirks. > > Signed-off-by: Simeon Simeonoff Thanks, applied now. Takashi
[PATCH v1 1/1] PCI: pciehp: Skip DLLSC handling if DPC is triggered
From: Kuppuswamy Sathyanarayanan
When hotplug and DPC are both enabled on a Root port or
Downstream Port, during DPC events that cause a DLLSC link
down/up events, such events must be suppressed to let the DPC
driver own the recovery path.
When DPC is present and enabled, hardware will put the port in
containment state to allow SW to recover from the error condition
in the seamless manner. But, during the DPC error recovery process,
since the link is in disabled state, it will also raise the DLLSC
event. In Linux kernel architecture, DPC events are handled by DPC
driver and DLLSC events are handled by hotplug driver. If a hotplug
driver is allowed to handle such DLLSC event (triggered by DPC
containment), then we will have a race condition between error
recovery handler (in DPC driver) and hotplug handler in recovering
the contained port. Allowing such a race leads to a lot of stability
issues while recovering the device. So skip DLLSC handling in the
hotplug driver when the PCIe port associated with the hotplug event is
in DPC triggered state and let the DPC driver be responsible for the
port recovery.
Following is the sample dmesg log which shows the contention
between hotplug handler and error recovery handler. In this
case, hotplug handler won the race and error recovery
handler reported failure.
[ 724.974237] pcieport :97:02.0: pciehp: Slot(4): Link Down
[ 724.974266] pcieport :97:02.0: DPC: containment event, status:0x1f01
source:0x
[ 724.974269] pcieport :97:02.0: DPC: unmasked uncorrectable error detected
[ 724.974275] pcieport :97:02.0: PCIe Bus Error: severity=Uncorrected
(Non-Fatal), type=Transaction Layer, (Requester ID)
[ 724.974283] pcieport :97:02.0: device [8086:347a] error
status/mask=4000/00100020
[ 724.974288] pcieport :97:02.0:[14] CmpltTO(First)
[ 724.999181] pci :98:00.0: AER: can't recover (no error_detected callback)
[ 724.999227] pci :98:00.0: Removing from iommu group 181
[ 726.063125] pcieport :97:02.0: pciehp: Slot(4): Card present
[ 726.221117] pcieport :97:02.0: DPC: Data Link Layer Link Active not set
in 1000 msec
[ 726.221122] pcieport :97:02.0: AER: subordinate device reset failed
[ 726.221162] pcieport :97:02.0: AER: device recovery failed
[ 727.227176] pci :98:00.0: [8086:0953] type 00 class 0x010802
[ 727.227202] pci :98:00.0: reg 0x10: [mem 0x-0x3fff 64bit]
[ 727.227234] pci :98:00.0: reg 0x30: [mem 0x-0x pref]
[ 727.227246] pci :98:00.0: Max Payload Size set to 256 (was 128, max 256)
[ 727.227251] pci :98:00.0: enabling Extended Tags
[ 727.227736] pci :98:00.0: Adding to iommu group 181
[ 727.231150] pci :98:00.0: BAR 6: assigned [mem 0xd100-0xd100
pref]
[ 727.231156] pci :98:00.0: BAR 0: assigned [mem 0xd101-0xd1013fff
64bit]
[ 727.231170] pcieport :97:02.0: PCI bridge to [bus 98]
[ 727.231174] pcieport :97:02.0: bridge window [io 0xc000-0xcfff]
[ 727.231181] pcieport :97:02.0: bridge window [mem
0xd100-0xd10f]
[ 727.231186] pcieport :97:02.0: bridge window [mem
0x2060-0x2060001f 64bit pref]
[ 727.231555] nvme nvme1: pci function :98:00.0
[ 727.231581] nvme :98:00.0: enabling device (0140 -> 0142)
[ 737.141132] nvme nvme1: 31/0/0 default/read/poll queues
[ 737.146211] nvme1n2: p1
Signed-off-by: Kuppuswamy Sathyanarayanan
Reviewed-by: Dan Williams
Reviewed-by: Raj Ashok
---
drivers/pci/hotplug/pciehp_hpc.c | 18 +
drivers/pci/pci.h| 2 ++
drivers/pci/pcie/dpc.c | 33 ++--
include/linux/pci.h | 1 +
4 files changed, 52 insertions(+), 2 deletions(-)
diff --git a/drivers/pci/hotplug/pciehp_hpc.c b/drivers/pci/hotplug/pciehp_hpc.c
index fb3840e222ad..8e7916abc60e 100644
--- a/drivers/pci/hotplug/pciehp_hpc.c
+++ b/drivers/pci/hotplug/pciehp_hpc.c
@@ -691,6 +691,24 @@ static irqreturn_t pciehp_ist(int irq, void *dev_id)
goto out;
}
+ /*
+* If the DLLSC link up/down event is generated due to DPC containment
+* in the PCIe port, skip the DLLSC event handling and let the DPC
driver
+* own the port recovery. Allowing both hotplug DLLSC event handler and
DPC
+* event trigger handler attempt recovery on the same port leads to
stability
+* issues. if DPC recovery is successful, is_dpc_reset_active() will
return
+* false and the hotplug handler will not suppress the DLLSC event. If
DPC
+* recovery fails and the link is left in disabled state, once the user
+* changes the faulty card, the hotplug handler can still handle the
PRESENCE
+* change event and bring the device back up.
+*/
+ if ((events == PCI_EXP_SLTSTA_DLLSC) && is_dpc_reset_active(pdev)) {
+ ctrl_info(ctrl, "Slot(%s): DLLSC event(DPC), skipped\n",
+
Re: [PATCH v3 1/2] usb: dwc3: Trigger a GCTL soft reset when switching modes in DRD
On 3/8/2021 7:05 PM, Thinh Nguyen wrote: > Wesley Cheng wrote: >> >> On 3/6/2021 3:41 PM, Thinh Nguyen wrote: >>> Wesley Cheng wrote: On 1/8/2021 4:44 PM, Thinh Nguyen wrote: > Hi, > > John Stultz wrote: >> On Fri, Jan 8, 2021 at 4:26 AM Felipe Balbi wrote: >>> Hi, >>> >>> John Stultz writes: From: Yu Chen Just resending this, as discussion died out a bit and I'm not sure how to make further progress. See here for debug data that was requested last time around: https://urldefense.com/v3/__https://lore.kernel.org/lkml/calaqxlxdnaufjkx0an9xwwtfwvjmwigppy2aqsnj56yvnbu...@mail.gmail.com/__;!!A4F2R9G_pg!LNzuprAeg-O80SgolYkIkW4-ne-M-yLWCDUY9MygAIrQC398Z6gRJ9wnsnlqd3w$ With the current dwc3 code on the HiKey960 we often see the COREIDLE flag get stuck off in __dwc3_gadget_start(), which seems to prevent the reset irq and causes the USB gadget to fail to initialize. We had seen occasional initialization failures with older kernels but with recent 5.x era kernels it seemed to be becoming much more common, so I dug back through some older trees and realized I dropped this quirk from Yu Chen during upstreaming as I couldn't provide a proper rational for it and it didn't seem to be necessary. I now realize I was wrong. After resubmitting the quirk, Thinh Nguyen pointed out that it shouldn't be a quirk at all and it is actually mentioned in the programming guide that it should be done when switching modes in DRD. So, to avoid these !COREIDLE lockups seen on HiKey960, this patch issues GCTL soft reset when switching modes if the controller is in DRD mode. Cc: Felipe Balbi Cc: Tejas Joglekar Cc: Yang Fei Cc: YongQin Liu Cc: Andrzej Pietrasiewicz Cc: Thinh Nguyen Cc: Jun Li Cc: Mauro Carvalho Chehab Cc: Greg Kroah-Hartman Cc: linux-...@vger.kernel.org Signed-off-by: Yu Chen Signed-off-by: John Stultz --- v2: * Rework to always call the GCTL soft reset in DRD mode, rather then using a quirk as suggested by Thinh Nguyen v3: * Move GCTL soft reset under the spinlock as suggested by Thinh Nguyen >>> Because this is such an invasive change, I would prefer that we get >>> Tested-By tags from a good fraction of the users before applying these >>> two changes. >> I'm happy to reach out to folks to try to get that. Though I'm >> wondering if it would be better to put it behind a dts quirk flag, as >> originally proposed? >> >> https://urldefense.com/v3/__https://lore.kernel.org/lkml/20201021181803.79650-1-john.stu...@linaro.org/__;!!A4F2R9G_pg!LNzuprAeg-O80SgolYkIkW4-ne-M-yLWCDUY9MygAIrQC398Z6gRJ9wnRWITZfc$ >> >> >> That way folks can enable it for devices as they need? >> >> Again, I'm not trying to force this in as-is, just mostly sending it >> out again for discussion to understand what other approach might work. >> >> thanks >> -john > A quirk would imply something is broken/diverged from the design right? > But it's not the case here, and at least this is needed for HiKey960. > Also, I think Rob will be ok with not adding 1 more quirk to the dwc3 > devicetree. :) > > BR, > Thinh > Hi All, Sorry for jumping in, but I checked the SNPS v1.90a databook, and that seemed to remove the requirement for the GCTL.softreset before writing to PRTCAPDIR. Should we consider adding a controller version/IP check? >>> Hi Wesley, >>> >>> From what I see in the v1.90a databook and others, the flow remains the >>> same. I need to check internally, but I'm not aware of the change. >>> >> Hi Thinh, >> >> Hmmm, can you help check the register description for the PRTCAPDIR on >> your v1.90a databook? (Table 1-19 Fields for Register: GCTL (Continued) >> Pg73) When we compared the sequence in the description there to the >> previous versions it removed the GCTL.softreset. If it still shows up >> on yours, then maybe my v1.90a isn't the final version? >> >> Thanks >> Wesley Cheng >> > > Hi Wesley, > > Actually your IP version type may use the newer flow. Can you print your > DWC3_VER_TYPE? I still need to verify internally to know which versions > need the update if any. > > Thanks, > Thinh > Hi Thinh, Sure, my DWC3_VER_TYPE output = 0x67612A2A Thanks Wesley Cheng -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project
Re: [PATCH 0/6] clk: Ingenic JZ4760(B) support
Hi Paul,
On 2021/3/7 下午10:17, Paul Cercueil wrote:
Hi,
Here are a set of patches to add support for the Ingenic JZ4760(B) SoCs.
One thing to note is that the ingenic,jz4760-tcu is undocumented for now,
as I will update the TCU documentation in a different patchset.
Zhou: the CGU code now supports overriding the PLL M/N/OD calc
algorithm, please tell me if it works for you.
After set "od = 1;", the overriding works, but I think we still need
some further improvements related to OD,
because there is no OD bits in the I2S PLL, this will cause error in
"ingenic_pll_recalc_rate()", and may cause
"ingenic_pll_calc()" to also have error(if we will introduce support for
non 1 od values).
I think maybe we can add codes to detect if there is an
"pll_od_encoding". If it is NULL, it means no OD bits, then
do some corresponding processing( for example, setting corresponding
variable to 1) to ensure proper calculation.
Thanks and best regards!
Cheers,
-Paul
Paul Cercueil (6):
dt-bindings: clock: ingenic: Add ingenic,jz4760{,b}-cgu compatibles
clk: Support bypassing dividers
clk: ingenic: Read bypass register only when there is one
clk: ingenic: Remove pll_info.no_bypass_bit
clk: ingenic: Support overriding PLLs M/N/OD calc algorithm
clk: ingenic: Add support for the JZ4760
.../bindings/clock/ingenic,cgu.yaml | 4 +
drivers/clk/ingenic/Kconfig | 10 +
drivers/clk/ingenic/Makefile | 1 +
drivers/clk/ingenic/cgu.c | 92 ++--
drivers/clk/ingenic/cgu.h | 12 +-
drivers/clk/ingenic/jz4725b-cgu.c | 12 +-
drivers/clk/ingenic/jz4740-cgu.c | 12 +-
drivers/clk/ingenic/jz4760-cgu.c | 433 ++
drivers/clk/ingenic/jz4770-cgu.c | 15 +-
drivers/clk/ingenic/tcu.c | 2 +
include/dt-bindings/clock/jz4760-cgu.h| 54 +++
11 files changed, 591 insertions(+), 56 deletions(-)
create mode 100644 drivers/clk/ingenic/jz4760-cgu.c
create mode 100644 include/dt-bindings/clock/jz4760-cgu.h
[PATCH] io_uring: remove unneeded variable 'ret'
Fix the following coccicheck warning:
./fs/io_uring.c:8984:5-8: Unneeded variable: "ret". Return "0" on line
8998
Reported-by: Abaci Robot
Signed-off-by: Yang Li
---
fs/io_uring.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/fs/io_uring.c b/fs/io_uring.c
index 92c25b5..387dbb7 100644
--- a/fs/io_uring.c
+++ b/fs/io_uring.c
@@ -8981,7 +8981,6 @@ static unsigned long
io_uring_nommu_get_unmapped_area(struct file *file,
static int io_sqpoll_wait_sq(struct io_ring_ctx *ctx)
{
- int ret = 0;
DEFINE_WAIT(wait);
do {
@@ -8995,7 +8994,7 @@ static int io_sqpoll_wait_sq(struct io_ring_ctx *ctx)
} while (!signal_pending(current));
finish_wait(>sqo_sq_wait, );
- return ret;
+ return 0;
}
static int io_get_ext_arg(unsigned flags, const void __user *argp, size_t
*argsz,
--
1.8.3.1
RE: [EXT] [PATCH v2 2/4] dt-bindings: spi: add compatible entry for imx8mp in FlexSPI controller
> Hi! > > On 09.03.21 06:56, Kuldeep Singh wrote: > > Hi Heiko, > > > >> -Original Message- > >> From: Heiko Schocher > >> Sent: Tuesday, March 9, 2021 11:01 AM > >> To: linux-arm-ker...@lists.infradead.org > >> Cc: Heiko Schocher ; Ashish Kumar ; > >> Mark Brown ; Rob Herring ; > >> Yogesh Gaur ; devicet...@vger.kernel.org; > >> linux- ker...@vger.kernel.org; linux-...@vger.kernel.org > >> Subject: [EXT] [PATCH v2 2/4] dt-bindings: spi: add compatible entry > >> for imx8mp in FlexSPI controller > >> > >> Caution: EXT Email > >> > >> add compatible entry "nxp,imx8mp-fspi" in NXP FlexSPI controller > >> > >> Signed-off-by: Heiko Schocher > >> --- > >> > >> (no changes since v1) > >> > >> Documentation/devicetree/bindings/spi/spi-nxp-fspi.txt | 1 + > >> 1 file changed, 1 insertion(+) > >> > >> diff --git a/Documentation/devicetree/bindings/spi/spi-nxp-fspi.txt > >> b/Documentation/devicetree/bindings/spi/spi-nxp-fspi.txt > >> index 7ac60d9fe3571..fd5f081f6d91b 100644 > >> --- a/Documentation/devicetree/bindings/spi/spi-nxp-fspi.txt > >> +++ b/Documentation/devicetree/bindings/spi/spi-nxp-fspi.txt > >> @@ -4,6 +4,7 @@ Required properties: > >>- compatible : Should be "nxp,lx2160a-fspi" > >> "nxp,imx8qxp-fspi" > >> "nxp,imx8mm-fspi" > >> + "nxp,imx8mp-fspi" > > > > It seems the changes are not on top of tree. Please see[1] for latest > > changes > including imx8dxl entry. > > Snippet below: > > > > Required properties: > > - compatible : Should be "nxp,lx2160a-fspi" > > "nxp,imx8qxp-fspi" > > "nxp,imx8mm-fspi" > > "nxp,imx8dxl-fspi" > > My patches are based on mainline.. > * 144c79ef33536 - (origin/master, origin/HEAD) Merge tag > 'perf-tools-fixes-for- > v5.12-2020-03-07' > of git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux (vor 32 Stunden) > > > Should I post this patch rebased on [1] or may all patches rebased on [1] ? Hi Heiko, As per cover letter, I can identify that first two are driver/Documentation patches and other two are device-tree patches. Device-tree patches(3/4 and 4/4) will go via Shawn tree (git://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux.git) And initial two driver patches(1/4 and 2/4) will go via Mark's tree (git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git) One approach I can think of is to send driver patches first and later send device-tree patches mentioning dependency on first two patches. Maybe Mark can comment here if he has any other opinion. Thanks Kuldeep
Re: Re: [PATCH] Input: elan_i2c - Reduce the resume time for new dev ices
Hi 'Dmitry,
url:
https://github.com/0day-ci/linux/commits/Dmitry-Torokhov/Re-PATCH-Input-elan_i2c-Reduce-the-resume-time-for-new-dev-ices/20210308-111956
base: https://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git next
config: x86_64-randconfig-m001-20210308 (attached as .config)
compiler: gcc-9 (Debian 9.3.0-22) 9.3.0
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
Reported-by: Dan Carpenter
smatch warnings:
drivers/input/mouse/elan_i2c_core.c:122 elan_i2c_lookup_quirks() warn: ignoring
unreachable code.
vim +122 drivers/input/mouse/elan_i2c_core.c
5b1301343b8d29 Dmitry Torokhov 2021-03-07 100 static u32
elan_i2c_lookup_quirks(u16 ic_type, u16 product_id)
5b1301343b8d29 Dmitry Torokhov 2021-03-07 101 {
5b1301343b8d29 Dmitry Torokhov 2021-03-07 102 static const struct {
5b1301343b8d29 Dmitry Torokhov 2021-03-07 103 u16 ic_type;
5b1301343b8d29 Dmitry Torokhov 2021-03-07 104 u16 product_id;
5b1301343b8d29 Dmitry Torokhov 2021-03-07 105 u32 quirks;
5b1301343b8d29 Dmitry Torokhov 2021-03-07 106 } elan_i2c_quirks[] = {
5b1301343b8d29 Dmitry Torokhov 2021-03-07 107 { 0x0D,
ETP_PRODUCT_ID_DELBIN, ETP_QUIRK_QUICK_WAKEUP },
5b1301343b8d29 Dmitry Torokhov 2021-03-07 108 { 0x10,
ETP_PRODUCT_ID_VOXEL, ETP_QUIRK_QUICK_WAKEUP },
5b1301343b8d29 Dmitry Torokhov 2021-03-07 109 { 0x14,
ETP_PRODUCT_ID_MAGPIE, ETP_QUIRK_QUICK_WAKEUP },
5b1301343b8d29 Dmitry Torokhov 2021-03-07 110 { 0x14,
ETP_PRODUCT_ID_BOBBA, ETP_QUIRK_QUICK_WAKEUP },
6696777c6506fa Duson Lin 2014-10-03 111 };
5b1301343b8d29 Dmitry Torokhov 2021-03-07 112 u32 quirks = 0;
5b1301343b8d29 Dmitry Torokhov 2021-03-07 113 int i;
5b1301343b8d29 Dmitry Torokhov 2021-03-07 114
5b1301343b8d29 Dmitry Torokhov 2021-03-07 115 for (i = 0;
ARRAY_SIZE(elan_i2c_quirks); i++) {
^^^
The "i < " part of this condition is missing.
5b1301343b8d29 Dmitry Torokhov 2021-03-07 116 if
(elan_i2c_quirks[i].ic_type == ic_type &&
5b1301343b8d29 Dmitry Torokhov 2021-03-07 117
elan_i2c_quirks[i].product_id == product_id) {
5b1301343b8d29 Dmitry Torokhov 2021-03-07 118 quirks
= elan_i2c_quirks[i].quirks;
5b1301343b8d29 Dmitry Torokhov 2021-03-07 119 }
5b1301343b8d29 Dmitry Torokhov 2021-03-07 120 }
5b1301343b8d29 Dmitry Torokhov 2021-03-07 121
5b1301343b8d29 Dmitry Torokhov 2021-03-07 @122 if (ic_type >= 0x0D &&
product_id >= 0x123)
5b1301343b8d29 Dmitry Torokhov 2021-03-07 123 quirks |=
ETP_QUIRK_QUICK_WAKEUP;
5b1301343b8d29 Dmitry Torokhov 2021-03-07 124
5b1301343b8d29 Dmitry Torokhov 2021-03-07 125 return quirks;
5b1301343b8d29 Dmitry Torokhov 2021-03-07 126 }
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
.config.gz
Description: application/gzip
Re: [PATCH v2 0/6] arm/arm64: Allow the rescheduling IPI to bypass irq_enter/exit
Hi Marc, Mark > Mark is working on this, I believe. I'll let him comment on the current > state of things. I understand. Mark, Could you tell me current state? Thanks, Yuichi Ito
[PATCH v4] mm: cma: support sysfs
Since CMA is getting used more widely, it's more important to
keep monitoring CMA statistics for system health since it's
directly related to user experience.
This patch introduces sysfs statistics for CMA, in order to provide
some basic monitoring of the CMA allocator.
* the number of CMA page successful allocations
* the number of CMA page allocation failures
These two values allow the user to calcuate the allocation
failure rate for each CMA area.
e.g.)
/sys/kernel/mm/cma/WIFI/alloc_pages_[success|fail]
/sys/kernel/mm/cma/SENSOR/alloc_pages_[success|fail]
/sys/kernel/mm/cma/BLUETOOTH/alloc_pages_[success|fail]
The cma_stat was intentionally allocated by dynamic allocation
to harmonize with kobject lifetime management.
https://lore.kernel.org/linux-mm/ycoamxqt6dzkc...@kroah.com/
Reviewed-by: Greg Kroah-Hartman
Reviewed-by: John Hubbard
Signed-off-by: Minchan Kim
---
>From v3 -
>https://lore.kernel.org/linux-mm/20210303205053.2906924-1-minc...@kernel.org/
* fix ZERO_OR_NULL_PTR - kernel test robot
* remove prefix cma - david@
* resolve conflict with vmstat cma in mmotm - akpm@
* rename stat name with success|fail
>From v2 -
>https://lore.kernel.org/linux-mm/20210208180142.2765456-1-minc...@kernel.org/
* sysfs doc and description modification - jhubbard
>From v1 -
>https://lore.kernel.org/linux-mm/20210203155001.4121868-1-minc...@kernel.org/
* fix sysfs build and refactoring - willy
* rename and drop some attributes - jhubbard
Documentation/ABI/testing/sysfs-kernel-mm-cma | 25
mm/Kconfig| 7 ++
mm/Makefile | 1 +
mm/cma.c | 7 +-
mm/cma.h | 20
mm/cma_sysfs.c| 110 ++
6 files changed, 168 insertions(+), 2 deletions(-)
create mode 100644 Documentation/ABI/testing/sysfs-kernel-mm-cma
create mode 100644 mm/cma_sysfs.c
diff --git a/Documentation/ABI/testing/sysfs-kernel-mm-cma
b/Documentation/ABI/testing/sysfs-kernel-mm-cma
new file mode 100644
index ..02b2bb60c296
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-kernel-mm-cma
@@ -0,0 +1,25 @@
+What: /sys/kernel/mm/cma/
+Date: Feb 2021
+Contact: Minchan Kim
+Description:
+ /sys/kernel/mm/cma/ contains a subdirectory for each CMA
+ heap name (also sometimes called CMA areas).
+
+ Each CMA heap subdirectory (that is, each
+ /sys/kernel/mm/cma/ directory) contains the
+ following items:
+
+ alloc_pages_success
+ alloc_pages_fail
+
+What: /sys/kernel/mm/cma//alloc_pages_success
+Date: Feb 2021
+Contact: Minchan Kim
+Description:
+ the number of pages CMA API succeeded to allocate
+
+What: /sys/kernel/mm/cma//alloc_pages_fail
+Date: Feb 2021
+Contact: Minchan Kim
+Description:
+ the number of pages CMA API failed to allocate
diff --git a/mm/Kconfig b/mm/Kconfig
index 24c045b24b95..febb7e8e24de 100644
--- a/mm/Kconfig
+++ b/mm/Kconfig
@@ -513,6 +513,13 @@ config CMA_DEBUGFS
help
Turns on the DebugFS interface for CMA.
+config CMA_SYSFS
+ bool "CMA information through sysfs interface"
+ depends on CMA && SYSFS
+ help
+ This option exposes some sysfs attributes to get information
+ from CMA.
+
config CMA_AREAS
int "Maximum count of the CMA areas"
depends on CMA
diff --git a/mm/Makefile b/mm/Makefile
index 72227b24a616..56968b23ed7a 100644
--- a/mm/Makefile
+++ b/mm/Makefile
@@ -109,6 +109,7 @@ obj-$(CONFIG_CMA) += cma.o
obj-$(CONFIG_MEMORY_BALLOON) += balloon_compaction.o
obj-$(CONFIG_PAGE_EXTENSION) += page_ext.o
obj-$(CONFIG_CMA_DEBUGFS) += cma_debug.o
+obj-$(CONFIG_CMA_SYSFS) += cma_sysfs.o
obj-$(CONFIG_USERFAULTFD) += userfaultfd.o
obj-$(CONFIG_IDLE_PAGE_TRACKING) += page_idle.o
obj-$(CONFIG_DEBUG_PAGE_REF) += debug_page_ref.o
diff --git a/mm/cma.c b/mm/cma.c
index 908f04775686..ac050359faae 100644
--- a/mm/cma.c
+++ b/mm/cma.c
@@ -507,10 +507,13 @@ struct page *cma_alloc(struct cma *cma, size_t count,
unsigned int align,
pr_debug("%s(): returned %p\n", __func__, page);
out:
- if (page)
+ if (page) {
count_vm_event(CMA_ALLOC_SUCCESS);
- else
+ cma_sysfs_alloc_pages_count(cma, count);
+ } else {
count_vm_event(CMA_ALLOC_FAIL);
+ cma_sysfs_fail_pages_count(cma, count);
+ }
return page;
}
diff --git a/mm/cma.h b/mm/cma.h
index 42ae082cb067..95d1aa2d808a 100644
--- a/mm/cma.h
+++ b/mm/cma.h
@@ -3,6 +3,16 @@
#define __MM_CMA_H__
#include
+#include
+
+struct cma_stat {
+ spinlock_t lock;
+ /* the number of CMA page successful allocations */
+ unsigned long nr_pages_succeeded;
+ /*
RE: [PATCH v2] arm64/ras: Update code to trace out more data for ARM processor
Hi All,
May I know whether this patch can be merged or not?
Thanks.
Jason
-Original Message-
From: Shiju Jose
Sent: Thursday, February 25, 2021 1:44 AM
To: Jason Tian OS ; linux-kernel@vger.kernel.org;
linux-e...@vger.kernel.org; linux-arm-ker...@lists.infradead.org;
james.mo...@arm.com; Tyler Baicar OS
Cc: Frank Wang
Subject: RE: [PATCH v2] arm64/ras: Update code to trace out more data for ARM
processor
>-Original Message-
>From: linux-arm-kernel
>[mailto:linux-arm-kernel-boun...@lists.infradead.org]
>On Behalf Of Jason Tian
>Sent: 05 February 2021 02:22
>To: linux-kernel@vger.kernel.org; linux-e...@vger.kernel.org;
>linux-arm- ker...@lists.infradead.org; james.mo...@arm.com;
>bai...@os.amperecomputing.com
>Cc: zw...@amperecomputing.com; ja...@os.amperecomputing.com
>Subject: [PATCH v2] arm64/ras: Update code to trace out more data for
>ARM processor
>
>The original arm_event trace code only traces out ARM processor error
>information data. According to UEFI_2_8_A_Feb14 specification chapter
>N2.4.4, the ARM processor error section includes several ARM processor
>error information, several ARM processor context information and
>several vendor specific error information structures.
>
>Add code to trace out all ARM processor context information and vendor
>specific error information with raw hex format.
>
>Signed-off-by: Jason Tian
>---
> drivers/ras/ras.c | 22 +-
> include/ras/ras_event.h | 41 +++---
>---
> 2 files changed, 56 insertions(+), 7 deletions(-)
>
Tested-by: Shiju Jose
>diff --git a/drivers/ras/ras.c b/drivers/ras/ras.c index
>95540ea8dd9d..6f3269da9476 100644
>--- a/drivers/ras/ras.c
>+++ b/drivers/ras/ras.c
>@@ -23,7 +23,27 @@ void log_non_standard_event(const guid_t *sec_type,
>const guid_t *fru_id,
>
> void log_arm_hw_error(struct cper_sec_proc_arm *err) {
>- trace_arm_event(err);
>+ u32 pei_len;
>+ u32 ctx_len;
>+ u32 vsei_len;
>+ u8 *pei_err;
>+ u8 *ctx_err;
>+ u8 *ven_err_data;
>+
>+ pei_len = sizeof(struct cper_arm_err_info) * err->err_info_num;
>+ pei_err = (u8 *) err + sizeof(struct cper_sec_proc_arm);
>+
>+ ctx_len = sizeof(struct cper_arm_ctx_info) * err->context_info_num;
>+ ctx_err = pei_err + sizeof(struct cper_arm_err_info) *
>+ err->err_info_num;
>+
>+ vsei_len = err->section_length - (sizeof(struct cper_sec_proc_arm) +
>+pei_len + ctx_len);
>+ ven_err_data = ctx_err + sizeof(struct cper_arm_ctx_info) *
>+err->context_info_num;
>+
>+ trace_arm_event(err, pei_err, pei_len, ctx_err, ctx_len,
>+ ven_err_data, vsei_len);
> }
>
> static int __init ras_init(void)
>diff --git a/include/ras/ras_event.h b/include/ras/ras_event.h index
>0bdbc0d17d2f..fd9201214be8 100644
>--- a/include/ras/ras_event.h
>+++ b/include/ras/ras_event.h
>@@ -168,11 +168,22 @@ TRACE_EVENT(mc_event,
> * This event is generated when hardware detects an ARM processor
>error
> * has occurred. UEFI 2.6 spec section N.2.4.4.
> */
>+ #define APEIL "ARM Processor Err Info data len"
>+ #define APEID "ARM Processor Err Info raw data"
>+ #define APECIL "ARM Processor Err Context Info data len"
>+ #define APECID "ARM Processor Err Context Info raw data"
>+ #define VSEIL "Vendor Specific Err Info data len"
>+ #define VSEID "Vendor Specific Err Info raw data"
> TRACE_EVENT(arm_event,
>
>- TP_PROTO(const struct cper_sec_proc_arm *proc),
>+ TP_PROTO(const struct cper_sec_proc_arm *proc, const u8 *pei_err,
>+ const u32 pei_len,
>+ const u8 *ctx_err,
>+ const u32 ctx_len,
>+ const u8 *oem,
>+ const u32 oem_len),
>
>- TP_ARGS(proc),
>+ TP_ARGS(proc, pei_err, pei_len, ctx_err, ctx_len, oem, oem_len),
>
> TP_STRUCT__entry(
> __field(u64, mpidr)
>@@ -180,6 +191,12 @@ TRACE_EVENT(arm_event,
> __field(u32, running_state)
> __field(u32, psci_state)
> __field(u8, affinity)
>+ __field(u32, pei_len)
>+ __dynamic_array(u8, buf, pei_len)
>+ __field(u32, ctx_len)
>+ __dynamic_array(u8, buf1, ctx_len)
>+ __field(u32, oem_len)
>+ __dynamic_array(u8, buf2, oem_len)
> ),
>
> TP_fast_assign(
>@@ -199,12 +216,24 @@ TRACE_EVENT(arm_event,
> __entry->running_state = ~0;
> __entry->psci_state = ~0;
> }
>+ __entry->pei_len = pei_len;
>+ memcpy(__get_dynamic_array(buf), pei_err, pei_len);
>+ __entry->ctx_len = ctx_len;
>+ memcpy(__get_dynamic_array(buf1), ctx_err, ctx_len);
>+ __entry->oem_len = oem_len;
>+ memcpy(__get_dynamic_array(buf2), oem, oem_len);
> ),
>
>- TP_printk("affinity level:
[RFC PATCH v2 6/6] vfio: Add nested IOPF support
To set up nested mode, drivers such as vfio_pci have to register
a handler to receive stage/level 1 faults from the IOMMU, but
since currently each device can only have one iommu dev fault
handler, and if stage 2 IOPF is already enabled (VFIO_IOMMU_ENABLE_IOPF),
we choose to update the registered handler (a combined one) via
flags (set IOPF_REPORT_NESTED_L1_CONCERNED), and further deliver
the received stage 1 faults in the handler to the guest through
a newly added vfio_device_ops callback.
Signed-off-by: Shenming Lu
---
drivers/vfio/vfio.c | 83 +
drivers/vfio/vfio_iommu_type1.c | 37 +++
include/linux/vfio.h| 9
3 files changed, 129 insertions(+)
diff --git a/drivers/vfio/vfio.c b/drivers/vfio/vfio.c
index 77b29bbd3027..c6a01d947d0d 100644
--- a/drivers/vfio/vfio.c
+++ b/drivers/vfio/vfio.c
@@ -2389,6 +2389,89 @@ int vfio_iommu_dev_fault_handler(struct iommu_fault
*fault, void *data)
}
EXPORT_SYMBOL_GPL(vfio_iommu_dev_fault_handler);
+int vfio_iommu_dev_fault_handler_unregister_nested(struct device *dev)
+{
+ struct vfio_container *container;
+ struct vfio_group *group;
+ struct vfio_iommu_driver *driver;
+ int ret;
+
+ if (!dev)
+ return -EINVAL;
+
+ group = vfio_group_get_from_dev(dev);
+ if (!group)
+ return -ENODEV;
+
+ ret = vfio_group_add_container_user(group);
+ if (ret)
+ goto out;
+
+ container = group->container;
+ driver = container->iommu_driver;
+ if (likely(driver && driver->ops->unregister_hdlr_nested))
+ ret = driver->ops->unregister_hdlr_nested(container->iommu_data,
+ dev);
+ else
+ ret = -ENOTTY;
+
+ vfio_group_try_dissolve_container(group);
+
+out:
+ vfio_group_put(group);
+ return ret;
+}
+EXPORT_SYMBOL_GPL(vfio_iommu_dev_fault_handler_unregister_nested);
+
+/*
+ * Register/Update the VFIO page fault handler
+ * to receive nested stage/level 1 faults.
+ */
+int vfio_iommu_dev_fault_handler_register_nested(struct device *dev)
+{
+ struct vfio_container *container;
+ struct vfio_group *group;
+ struct vfio_iommu_driver *driver;
+ int ret;
+
+ if (!dev)
+ return -EINVAL;
+
+ group = vfio_group_get_from_dev(dev);
+ if (!group)
+ return -ENODEV;
+
+ ret = vfio_group_add_container_user(group);
+ if (ret)
+ goto out;
+
+ container = group->container;
+ driver = container->iommu_driver;
+ if (likely(driver && driver->ops->register_hdlr_nested))
+ ret = driver->ops->register_hdlr_nested(container->iommu_data,
+ dev);
+ else
+ ret = -ENOTTY;
+
+ vfio_group_try_dissolve_container(group);
+
+out:
+ vfio_group_put(group);
+ return ret;
+}
+EXPORT_SYMBOL_GPL(vfio_iommu_dev_fault_handler_register_nested);
+
+int vfio_transfer_dev_fault(struct device *dev, struct iommu_fault *fault)
+{
+ struct vfio_device *device = dev_get_drvdata(dev);
+
+ if (unlikely(!device->ops->transfer))
+ return -EOPNOTSUPP;
+
+ return device->ops->transfer(device->device_data, fault);
+}
+EXPORT_SYMBOL_GPL(vfio_transfer_dev_fault);
+
/**
* Module/class support
*/
diff --git a/drivers/vfio/vfio_iommu_type1.c b/drivers/vfio/vfio_iommu_type1.c
index 8d14ced649a6..62ad4a47de4a 100644
--- a/drivers/vfio/vfio_iommu_type1.c
+++ b/drivers/vfio/vfio_iommu_type1.c
@@ -3581,6 +3581,13 @@ static int vfio_iommu_type1_dma_map_iopf(void
*iommu_data,
enum iommu_page_response_code status = IOMMU_PAGE_RESP_INVALID;
struct iommu_page_response resp = {0};
+ /*
+* When configured in nested mode, further deliver
+* stage/level 1 faults to the guest.
+*/
+ if (iommu->nesting && !(fault->prm.flags & IOMMU_FAULT_PAGE_REQUEST_L2))
+ return vfio_transfer_dev_fault(dev, fault);
+
mutex_lock(>lock);
dma = vfio_find_dma(iommu, iova, PAGE_SIZE);
@@ -3654,6 +3661,34 @@ static int vfio_iommu_type1_dma_map_iopf(void
*iommu_data,
return 0;
}
+static int vfio_iommu_type1_register_hdlr_nested(void *iommu_data,
+struct device *dev)
+{
+ struct vfio_iommu *iommu = iommu_data;
+
+ if (iommu->iopf_enabled)
+ return iommu_update_device_fault_handler(dev, ~0,
+ IOPF_REPORT_NESTED_L1_CONCERNED);
+ else
+ return iommu_register_device_fault_handler(dev,
+ vfio_iommu_dev_fault_handler,
+ IOPF_REPORT_NESTED |
+ IOPF_REPORT_NESTED_L1_CONCERNED,
+
[RFC PATCH v2 4/6] vfio: VFIO_IOMMU_ENABLE_IOPF
Since enabling IOPF for devices may lead to a slow ramp up of
performance, we add an VFIO_IOMMU_ENABLE_IOPF ioctl to make it
configurable. And the IOPF enabling of a VFIO device includes
setting IOMMU_DEV_FEAT_IOPF and registering the VFIO page fault
handler. Note that VFIO_IOMMU_DISABLE_IOPF is not supported
since there may be inflight page faults when disabling.
Signed-off-by: Shenming Lu
---
drivers/vfio/vfio_iommu_type1.c | 139 +++-
include/uapi/linux/vfio.h | 6 ++
2 files changed, 142 insertions(+), 3 deletions(-)
diff --git a/drivers/vfio/vfio_iommu_type1.c b/drivers/vfio/vfio_iommu_type1.c
index 167d52c1468b..3997473be4a7 100644
--- a/drivers/vfio/vfio_iommu_type1.c
+++ b/drivers/vfio/vfio_iommu_type1.c
@@ -71,6 +71,7 @@ struct vfio_iommu {
struct rb_root dma_list;
struct blocking_notifier_head notifier;
struct mmu_notifier mn;
+ struct mm_struct*mm;
unsigned intdma_avail;
unsigned intvaddr_invalid_count;
uint64_tpgsize_bitmap;
@@ -81,6 +82,7 @@ struct vfio_iommu {
booldirty_page_tracking;
boolpinned_page_dirty_scope;
boolcontainer_open;
+ booliopf_enabled;
};
struct vfio_domain {
@@ -2278,6 +2280,62 @@ static void vfio_iommu_iova_insert_copy(struct
vfio_iommu *iommu,
list_splice_tail(iova_copy, iova);
}
+static int dev_disable_iopf(struct device *dev, void *data)
+{
+ int *enabled_dev_cnt = data;
+
+ if (enabled_dev_cnt && *enabled_dev_cnt <= 0)
+ return -1;
+
+ iommu_unregister_device_fault_handler(dev);
+ iommu_dev_disable_feature(dev, IOMMU_DEV_FEAT_IOPF);
+
+ if (enabled_dev_cnt)
+ (*enabled_dev_cnt)--;
+
+ return 0;
+}
+
+static int dev_enable_iopf(struct device *dev, void *data)
+{
+ int *enabled_dev_cnt = data;
+ struct iommu_domain *domain;
+ int nested;
+ u32 flags;
+ int ret;
+
+ ret = iommu_dev_enable_feature(dev, IOMMU_DEV_FEAT_IOPF);
+ if (ret)
+ return ret;
+
+ domain = iommu_get_domain_for_dev(dev);
+ if (!domain) {
+ ret = -ENODEV;
+ goto out_disable;
+ }
+
+ ret = iommu_domain_get_attr(domain, DOMAIN_ATTR_NESTING, );
+ if (ret)
+ goto out_disable;
+
+ if (nested)
+ flags = IOPF_REPORT_NESTED | IOPF_REPORT_NESTED_L2_CONCERNED;
+ else
+ flags = IOPF_REPORT_FLAT;
+
+ ret = iommu_register_device_fault_handler(dev,
+ vfio_iommu_dev_fault_handler, flags, dev);
+ if (ret)
+ goto out_disable;
+
+ (*enabled_dev_cnt)++;
+ return 0;
+
+out_disable:
+ iommu_dev_disable_feature(dev, IOMMU_DEV_FEAT_IOPF);
+ return ret;
+}
+
static int vfio_iommu_type1_attach_group(void *iommu_data,
struct iommu_group *iommu_group)
{
@@ -2291,6 +2349,7 @@ static int vfio_iommu_type1_attach_group(void *iommu_data,
struct iommu_domain_geometry geo;
LIST_HEAD(iova_copy);
LIST_HEAD(group_resv_regions);
+ int iopf_enabled_dev_cnt = 0;
mutex_lock(>lock);
@@ -2368,6 +2427,13 @@ static int vfio_iommu_type1_attach_group(void
*iommu_data,
if (ret)
goto out_domain;
+ if (iommu->iopf_enabled) {
+ ret = iommu_group_for_each_dev(iommu_group,
_enabled_dev_cnt,
+ dev_enable_iopf);
+ if (ret)
+ goto out_detach;
+ }
+
/* Get aperture info */
iommu_domain_get_attr(domain->domain, DOMAIN_ATTR_GEOMETRY, );
@@ -2449,9 +2515,11 @@ static int vfio_iommu_type1_attach_group(void
*iommu_data,
vfio_test_domain_fgsp(domain);
/* replay mappings on new domains */
- ret = vfio_iommu_replay(iommu, domain);
- if (ret)
- goto out_detach;
+ if (!iommu->iopf_enabled) {
+ ret = vfio_iommu_replay(iommu, domain);
+ if (ret)
+ goto out_detach;
+ }
if (resv_msi) {
ret = iommu_get_msi_cookie(domain->domain, resv_msi_base);
@@ -2482,6 +2550,8 @@ static int vfio_iommu_type1_attach_group(void *iommu_data,
iommu_domain_free(domain->domain);
vfio_iommu_iova_free(_copy);
vfio_iommu_resv_free(_resv_regions);
+ iommu_group_for_each_dev(iommu_group, _enabled_dev_cnt,
+dev_disable_iopf);
out_free:
kfree(domain);
kfree(group);
@@ -2643,6 +2713,10 @@ static void vfio_iommu_type1_detach_group(void
*iommu_data,
if (!group)
continue;
+ if (iommu->iopf_enabled)
+
[RFC PATCH v2 2/6] vfio: Add an MMU notifier to avoid pinning
To avoid pinning pages when they are mapped in IOMMU page tables,
we add an MMU notifier to tell the addresses which are no longer
valid and try to unmap them.
Signed-off-by: Shenming Lu
---
drivers/vfio/vfio_iommu_type1.c | 68 +
1 file changed, 68 insertions(+)
diff --git a/drivers/vfio/vfio_iommu_type1.c b/drivers/vfio/vfio_iommu_type1.c
index 4bb162c1d649..03ccc11057af 100644
--- a/drivers/vfio/vfio_iommu_type1.c
+++ b/drivers/vfio/vfio_iommu_type1.c
@@ -40,6 +40,7 @@
#include
#include
#include
+#include
#define DRIVER_VERSION "0.2"
#define DRIVER_AUTHOR "Alex Williamson "
@@ -69,6 +70,7 @@ struct vfio_iommu {
struct mutexlock;
struct rb_root dma_list;
struct blocking_notifier_head notifier;
+ struct mmu_notifier mn;
unsigned intdma_avail;
unsigned intvaddr_invalid_count;
uint64_tpgsize_bitmap;
@@ -101,6 +103,7 @@ struct vfio_dma {
struct task_struct *task;
struct rb_root pfn_list; /* Ex-user pinned pfn list */
unsigned long *bitmap;
+ unsigned long *iopf_mapped_bitmap;
};
struct vfio_batch {
@@ -157,6 +160,10 @@ struct vfio_regions {
#define DIRTY_BITMAP_PAGES_MAX ((u64)INT_MAX)
#define DIRTY_BITMAP_SIZE_MAX DIRTY_BITMAP_BYTES(DIRTY_BITMAP_PAGES_MAX)
+#define IOPF_MAPPED_BITMAP_GET(dma, i) \
+ ((dma->iopf_mapped_bitmap[(i) / BITS_PER_LONG]
\
+ >> ((i) % BITS_PER_LONG)) & 0x1)
+
#define WAITED 1
static int put_pfn(unsigned long pfn, int prot);
@@ -1149,6 +1156,35 @@ static long vfio_unmap_unpin(struct vfio_iommu *iommu,
struct vfio_dma *dma,
return unlocked;
}
+static void vfio_unmap_partial_iopf(struct vfio_iommu *iommu,
+ struct vfio_dma *dma,
+ dma_addr_t start, dma_addr_t end)
+{
+ unsigned long bit_offset;
+ size_t len;
+ struct vfio_domain *d;
+
+ while (start < end) {
+ bit_offset = (start - dma->iova) >> PAGE_SHIFT;
+
+ for (len = 0; start + len < end; len += PAGE_SIZE) {
+ if (!IOPF_MAPPED_BITMAP_GET(dma,
+ bit_offset + (len >> PAGE_SHIFT)))
+ break;
+ }
+
+ if (len) {
+ list_for_each_entry(d, >domain_list, next)
+ iommu_unmap(d->domain, start, len);
+
+ bitmap_clear(dma->iopf_mapped_bitmap,
+bit_offset, len >> PAGE_SHIFT);
+ }
+
+ start += (len + PAGE_SIZE);
+ }
+}
+
static void vfio_remove_dma(struct vfio_iommu *iommu, struct vfio_dma *dma)
{
WARN_ON(!RB_EMPTY_ROOT(>pfn_list));
@@ -3096,6 +3132,38 @@ static int vfio_iommu_type1_dirty_pages(struct
vfio_iommu *iommu,
return -EINVAL;
}
+static void mn_invalidate_range(struct mmu_notifier *mn, struct mm_struct *mm,
+ unsigned long start, unsigned long end)
+{
+ struct vfio_iommu *iommu = container_of(mn, struct vfio_iommu, mn);
+ struct rb_node *n;
+
+ mutex_lock(>lock);
+
+ for (n = rb_first(>dma_list); n; n = rb_next(n)) {
+ struct vfio_dma *dma = rb_entry(n, struct vfio_dma, node);
+ unsigned long start_n, end_n;
+
+ if (end <= dma->vaddr || start >= dma->vaddr + dma->size)
+ continue;
+
+ start_n = ALIGN_DOWN(max_t(unsigned long, start, dma->vaddr),
+PAGE_SIZE);
+ end_n = ALIGN(min_t(unsigned long, end, dma->vaddr + dma->size),
+ PAGE_SIZE);
+
+ vfio_unmap_partial_iopf(iommu, dma,
+ start_n - dma->vaddr + dma->iova,
+ end_n - dma->vaddr + dma->iova);
+ }
+
+ mutex_unlock(>lock);
+}
+
+static const struct mmu_notifier_ops vfio_iommu_type1_mn_ops = {
+ .invalidate_range = mn_invalidate_range,
+};
+
static long vfio_iommu_type1_ioctl(void *iommu_data,
unsigned int cmd, unsigned long arg)
{
--
2.19.1
[RFC PATCH v2 5/6] vfio: No need to statically pin and map if IOPF enabled
If IOPF enabled for the VFIO container, there is no need to
statically pin and map the entire DMA range, we can do it on
demand. And unmap according to the IOPF mapped bitmap when
removing vfio_dma.
Signed-off-by: Shenming Lu
---
drivers/vfio/vfio_iommu_type1.c | 35 -
1 file changed, 30 insertions(+), 5 deletions(-)
diff --git a/drivers/vfio/vfio_iommu_type1.c b/drivers/vfio/vfio_iommu_type1.c
index 3997473be4a7..8d14ced649a6 100644
--- a/drivers/vfio/vfio_iommu_type1.c
+++ b/drivers/vfio/vfio_iommu_type1.c
@@ -165,6 +165,7 @@ struct vfio_regions {
#define IOPF_MAPPED_BITMAP_GET(dma, i) \
((dma->iopf_mapped_bitmap[(i) / BITS_PER_LONG]
\
>> ((i) % BITS_PER_LONG)) & 0x1)
+#define IOPF_MAPPED_BITMAP_BYTES(n)DIRTY_BITMAP_BYTES(n)
#define WAITED 1
@@ -877,7 +878,8 @@ static int vfio_iommu_type1_pin_pages(void *iommu_data,
* already pinned and accounted. Accouting should be done if there is no
* iommu capable domain in the container.
*/
- do_accounting = !IS_IOMMU_CAP_DOMAIN_IN_CONTAINER(iommu);
+ do_accounting = !IS_IOMMU_CAP_DOMAIN_IN_CONTAINER(iommu) ||
+ iommu->iopf_enabled;
for (i = 0; i < npage; i++) {
struct vfio_pfn *vpfn;
@@ -966,7 +968,8 @@ static int vfio_iommu_type1_unpin_pages(void *iommu_data,
mutex_lock(>lock);
- do_accounting = !IS_IOMMU_CAP_DOMAIN_IN_CONTAINER(iommu);
+ do_accounting = !IS_IOMMU_CAP_DOMAIN_IN_CONTAINER(iommu) ||
+ iommu->iopf_enabled;
for (i = 0; i < npage; i++) {
struct vfio_dma *dma;
dma_addr_t iova;
@@ -1087,7 +1090,7 @@ static long vfio_unmap_unpin(struct vfio_iommu *iommu,
struct vfio_dma *dma,
if (!dma->size)
return 0;
- if (!IS_IOMMU_CAP_DOMAIN_IN_CONTAINER(iommu))
+ if (!IS_IOMMU_CAP_DOMAIN_IN_CONTAINER(iommu) || iommu->iopf_enabled)
return 0;
/*
@@ -1187,11 +1190,20 @@ static void vfio_unmap_partial_iopf(struct vfio_iommu
*iommu,
}
}
+static void vfio_dma_clean_iopf(struct vfio_iommu *iommu, struct vfio_dma *dma)
+{
+ vfio_unmap_partial_iopf(iommu, dma, dma->iova, dma->iova + dma->size);
+
+ kfree(dma->iopf_mapped_bitmap);
+}
+
static void vfio_remove_dma(struct vfio_iommu *iommu, struct vfio_dma *dma)
{
WARN_ON(!RB_EMPTY_ROOT(>pfn_list));
vfio_unmap_unpin(iommu, dma, true);
vfio_unlink_dma(iommu, dma);
+ if (iommu->iopf_enabled)
+ vfio_dma_clean_iopf(iommu, dma);
put_task_struct(dma->task);
vfio_dma_bitmap_free(dma);
if (dma->vaddr_invalid) {
@@ -1655,6 +1667,16 @@ static int vfio_dma_do_map(struct vfio_iommu *iommu,
goto out_unlock;
}
+ if (iommu->iopf_enabled) {
+ dma->iopf_mapped_bitmap = kvzalloc(IOPF_MAPPED_BITMAP_BYTES(
+ size >> PAGE_SHIFT),
GFP_KERNEL);
+ if (!dma->iopf_mapped_bitmap) {
+ ret = -ENOMEM;
+ kfree(dma);
+ goto out_unlock;
+ }
+ }
+
iommu->dma_avail--;
dma->iova = iova;
dma->vaddr = vaddr;
@@ -1694,8 +1716,11 @@ static int vfio_dma_do_map(struct vfio_iommu *iommu,
/* Insert zero-sized and grow as we map chunks of it */
vfio_link_dma(iommu, dma);
- /* Don't pin and map if container doesn't contain IOMMU capable domain*/
- if (!IS_IOMMU_CAP_DOMAIN_IN_CONTAINER(iommu))
+ /*
+* Don't pin and map if container doesn't contain IOMMU capable domain,
+* or IOPF enabled for the container.
+*/
+ if (!IS_IOMMU_CAP_DOMAIN_IN_CONTAINER(iommu) || iommu->iopf_enabled)
dma->size = size;
else
ret = vfio_pin_map_dma(iommu, dma, size);
--
2.19.1
[RFC PATCH v2 1/6] iommu: Evolve to support more scenarios of using IOPF
This patch follows the discussion here:
https://lore.kernel.org/linux-acpi/YAaxjmJW+ZMvrhac@myrica/
In order to support more scenarios of using IOPF (mainly consider
the nested extension), besides keeping IOMMU_DEV_FEAT_IOPF as a
general capability for whether delivering faults through the IOMMU,
we extend iommu_register_fault_handler() with flags and introduce
IOPF_REPORT_FLAT and IOPF_REPORT_NESTED to describe the page fault
reporting capability under a specific configuration.
IOPF_REPORT_NESTED needs additional info to indicate which level/stage
is concerned since the fault client may be interested in only one
level.
Signed-off-by: Shenming Lu
---
.../iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c | 3 +-
drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 11 ++--
drivers/iommu/io-pgfault.c| 4 --
drivers/iommu/iommu.c | 56 ++-
include/linux/iommu.h | 21 ++-
include/uapi/linux/iommu.h| 3 +
6 files changed, 85 insertions(+), 13 deletions(-)
diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c
b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c
index ee66d1f4cb81..5de9432349d4 100644
--- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c
+++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c
@@ -482,7 +482,8 @@ static int arm_smmu_master_sva_enable_iopf(struct
arm_smmu_master *master)
if (ret)
return ret;
- ret = iommu_register_device_fault_handler(dev, iommu_queue_iopf, dev);
+ ret = iommu_register_device_fault_handler(dev, iommu_queue_iopf,
+ IOPF_REPORT_FLAT, dev);
if (ret) {
iopf_queue_remove_device(master->smmu->evtq.iopf, dev);
return ret;
diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
index 363744df8d51..f40529d0075d 100644
--- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
+++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
@@ -1447,10 +1447,6 @@ static int arm_smmu_handle_evt(struct arm_smmu_device
*smmu, u64 *evt)
return -EOPNOTSUPP;
}
- /* Stage-2 is always pinned at the moment */
- if (evt[1] & EVTQ_1_S2)
- return -EFAULT;
-
if (evt[1] & EVTQ_1_RnW)
perm |= IOMMU_FAULT_PERM_READ;
else
@@ -1468,13 +1464,18 @@ static int arm_smmu_handle_evt(struct arm_smmu_device
*smmu, u64 *evt)
.flags = IOMMU_FAULT_PAGE_REQUEST_LAST_PAGE,
.grpid = FIELD_GET(EVTQ_1_STAG, evt[1]),
.perm = perm,
- .addr = FIELD_GET(EVTQ_2_ADDR, evt[2]),
};
if (ssid_valid) {
flt->prm.flags |= IOMMU_FAULT_PAGE_REQUEST_PASID_VALID;
flt->prm.pasid = FIELD_GET(EVTQ_0_SSID, evt[0]);
}
+
+ if (evt[1] & EVTQ_1_S2) {
+ flt->prm.flags |= IOMMU_FAULT_PAGE_REQUEST_L2;
+ flt->prm.addr = FIELD_GET(EVTQ_3_IPA, evt[3]);
+ } else
+ flt->prm.addr = FIELD_GET(EVTQ_2_ADDR, evt[2]);
} else {
flt->type = IOMMU_FAULT_DMA_UNRECOV;
flt->event = (struct iommu_fault_unrecoverable) {
diff --git a/drivers/iommu/io-pgfault.c b/drivers/iommu/io-pgfault.c
index 1df8c1dcae77..abf16e06bcf5 100644
--- a/drivers/iommu/io-pgfault.c
+++ b/drivers/iommu/io-pgfault.c
@@ -195,10 +195,6 @@ int iommu_queue_iopf(struct iommu_fault *fault, void
*cookie)
lockdep_assert_held(>lock);
- if (fault->type != IOMMU_FAULT_PAGE_REQ)
- /* Not a recoverable page fault */
- return -EOPNOTSUPP;
-
/*
* As long as we're holding param->lock, the queue can't be unlinked
* from the device and therefore cannot disappear.
diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
index d0b0a15dba84..cb1d93b00f7d 100644
--- a/drivers/iommu/iommu.c
+++ b/drivers/iommu/iommu.c
@@ -1056,6 +1056,40 @@ int iommu_group_unregister_notifier(struct iommu_group
*group,
}
EXPORT_SYMBOL_GPL(iommu_group_unregister_notifier);
+/*
+ * iommu_update_device_fault_handler - Update the device fault handler via
flags
+ * @dev: the device
+ * @mask: bits(not set) to clear
+ * @set: bits to set
+ *
+ * Update the device fault handler installed by
+ * iommu_register_device_fault_handler().
+ *
+ * Return 0 on success, or an error.
+ */
+int iommu_update_device_fault_handler(struct device *dev, u32 mask, u32 set)
+{
+ struct dev_iommu *param = dev->iommu;
+ int ret = 0;
+
+ if (!param)
+ return -EINVAL;
+
+ mutex_lock(>lock);
+
+ if (param->fault_param) {
+ ret = -EINVAL;
+ goto out_unlock;
+ }
+
+ param->fault_param->flags = (param->fault_param->flags & mask) |
[RFC PATCH v2 3/6] vfio: Add a page fault handler
VFIO manages the DMA mapping itself. To support IOPF for VFIO
devices, we add a VFIO page fault handler to serve the reported
page faults from the IOMMU driver. Besides, we can pre-map more
pages than requested at once to optimize for fewer page fault
handlings.
Signed-off-by: Shenming Lu
---
drivers/vfio/vfio.c | 35 +++
drivers/vfio/vfio_iommu_type1.c | 167
include/linux/vfio.h| 5 +
3 files changed, 207 insertions(+)
diff --git a/drivers/vfio/vfio.c b/drivers/vfio/vfio.c
index 38779e6fd80c..77b29bbd3027 100644
--- a/drivers/vfio/vfio.c
+++ b/drivers/vfio/vfio.c
@@ -2354,6 +2354,41 @@ struct iommu_domain *vfio_group_iommu_domain(struct
vfio_group *group)
}
EXPORT_SYMBOL_GPL(vfio_group_iommu_domain);
+int vfio_iommu_dev_fault_handler(struct iommu_fault *fault, void *data)
+{
+ struct device *dev = (struct device *)data;
+ struct vfio_container *container;
+ struct vfio_group *group;
+ struct vfio_iommu_driver *driver;
+ int ret;
+
+ if (!dev)
+ return -EINVAL;
+
+ group = vfio_group_get_from_dev(dev);
+ if (!group)
+ return -ENODEV;
+
+ ret = vfio_group_add_container_user(group);
+ if (ret)
+ goto out;
+
+ container = group->container;
+ driver = container->iommu_driver;
+ if (likely(driver && driver->ops->dma_map_iopf))
+ ret = driver->ops->dma_map_iopf(container->iommu_data,
+ fault, dev);
+ else
+ ret = -ENOTTY;
+
+ vfio_group_try_dissolve_container(group);
+
+out:
+ vfio_group_put(group);
+ return ret;
+}
+EXPORT_SYMBOL_GPL(vfio_iommu_dev_fault_handler);
+
/**
* Module/class support
*/
diff --git a/drivers/vfio/vfio_iommu_type1.c b/drivers/vfio/vfio_iommu_type1.c
index 03ccc11057af..167d52c1468b 100644
--- a/drivers/vfio/vfio_iommu_type1.c
+++ b/drivers/vfio/vfio_iommu_type1.c
@@ -3330,6 +3330,172 @@ static void vfio_iommu_type1_notify(void *iommu_data,
wake_up_all(>vaddr_wait);
}
+/*
+ * To optimize for fewer page fault handlings, try to
+ * pre-map more pages than requested.
+ */
+#define IOPF_PREMAP_LEN512
+
+static void unpin_pages_iopf(struct vfio_dma *dma,
+unsigned long pfn, unsigned long npages)
+{
+ while (npages--)
+ put_pfn(pfn++, dma->prot);
+}
+
+/*
+ * Return 0 on success or a negative error code, the
+ * number of pages contiguously pinned is in @*pinned.
+ */
+static int pin_pages_iopf(struct vfio_dma *dma, unsigned long vaddr,
+ unsigned long npages, unsigned long *pfn_base,
+ unsigned long *pinned, struct vfio_batch *batch)
+{
+ struct mm_struct *mm;
+ unsigned long pfn;
+ int ret = 0;
+ *pinned = 0;
+
+ mm = get_task_mm(dma->task);
+ if (!mm)
+ return -ENODEV;
+
+ if (batch->size) {
+ *pfn_base = page_to_pfn(batch->pages[batch->offset]);
+ pfn = *pfn_base;
+ } else
+ *pfn_base = 0;
+
+ while (npages) {
+ if (!batch->size) {
+ unsigned long req_pages = min_t(unsigned long, npages,
+ batch->capacity);
+
+ ret = vaddr_get_pfns(mm, vaddr, req_pages, dma->prot,
+, batch->pages);
+ if (ret < 0)
+ goto out;
+
+ batch->size = ret;
+ batch->offset = 0;
+ ret = 0;
+
+ if (!*pfn_base)
+ *pfn_base = pfn;
+ }
+
+ while (true) {
+ if (pfn != *pfn_base + *pinned)
+ goto out;
+
+ (*pinned)++;
+ npages--;
+ vaddr += PAGE_SIZE;
+ batch->offset++;
+ batch->size--;
+
+ if (!batch->size)
+ break;
+
+ pfn = page_to_pfn(batch->pages[batch->offset]);
+ }
+
+ if (unlikely(disable_hugepages))
+ break;
+ }
+
+out:
+ mmput(mm);
+ return ret;
+}
+
+static int vfio_iommu_type1_dma_map_iopf(void *iommu_data,
+struct iommu_fault *fault,
+struct device *dev)
+{
+ struct vfio_iommu *iommu = iommu_data;
+ dma_addr_t iova = ALIGN_DOWN(fault->prm.addr, PAGE_SIZE);
+ struct vfio_dma *dma;
+ int access_flags = 0;
+ size_t premap_len, map_len, mapped_len = 0;
+ unsigned long bit_offset, npages, i, vaddr, pfn;
+ struct vfio_batch batch;
[RFC PATCH v2 0/6] Add IOPF support for VFIO passthrough
Hi, The static pinning and mapping problem in VFIO and possible solutions have been discussed a lot [1, 2]. One of the solutions is to add I/O page fault support for VFIO devices. Different from those relatively complicated software approaches such as presenting a vIOMMU that provides the DMA buffer information (might include para-virtualized optimizations), IOPF mainly depends on the hardware faulting capability, such as the PCIe PRI extension or Arm SMMU stall model. What's more, the IOPF support in the IOMMU driver is being implemented in SVA [3]. So we add IOPF support for VFIO passthrough based on the IOPF part of SVA in this series. We have measured its performance with UADK [4] (passthrough an accelerator to a VM) on Hisilicon Kunpeng920 board: Run hisi_sec_test... - with varying message lengths and sending times - with/without stage 2 IOPF enabled when msg_len = 1MB and PREMAP_LEN (in patch 3) = 1: speed (KB/s) times w/o IOPFwith IOPF (num of faults)degradation 1 325596 119152 (518) 36.6% 100 7524985 5804659 (1058) 77.1% 1000 8661817 8440209 (1071) 97.4% 5000 8804512 8724368 (1216) 99.1% If we use the same region to send messages, since page faults occur almost only when first accessing, more times, less degradation. when msg_len = 10MB and PREMAP_LEN = 512: speed (KB/s) times w/o IOPFwith IOPF (num of faults)degradation 1 1012758 682257 (13) 67.4% 100 8680688 8374154 (26) 96.5% 1000 8860861 8719918 (26) 98.4% We see that pre-mapping can help. And we also measured the performance of host SVA with the same params: when msg_len = 1MB: speed (KB/s) times w/o IOPFwith IOPF (num of faults)degradation 1 951672 163866 (512) 17.2% 100 8691961 4529971 (1024) 52.1% 1000 9158721 8376346 (1024) 91.5% 5000 9184532 9008739 (1024) 98.1% Besides, the avg time spent in vfio_iommu_dev_fault_handler() (in patch 3) is little less than iopf_handle_group() (in SVA) (1.6 us vs 2.0 us). History: v1 -> v2 - Numerous improvements following the suggestions. Thanks a lot to all of you. Yet TODO: - Add support for PRI. - Consider selective-faulting. (suggested by Kevin) ... Links: [1] Lesokhin I, et al. Page Fault Support for Network Controllers. In ASPLOS, 2016. [2] Tian K, et al. coIOMMU: A Virtual IOMMU with Cooperative DMA Buffer Tracking for Efficient Memory Management in Direct I/O. In USENIX ATC, 2020. [3] https://patchwork.kernel.org/project/linux-arm-kernel/cover/20210302092644.2553014-1-jean-phili...@linaro.org/ [4] https://github.com/Linaro/uadk Any comments and suggestions are very welcome. :-) Thanks, Shenming Shenming Lu (6): iommu: Evolve to support more scenarios of using IOPF vfio: Add an MMU notifier to avoid pinning vfio: Add a page fault handler vfio: VFIO_IOMMU_ENABLE_IOPF vfio: No need to statically pin and map if IOPF enabled vfio: Add nested IOPF support .../iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c | 3 +- drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 11 +- drivers/iommu/io-pgfault.c| 4 - drivers/iommu/iommu.c | 56 ++- drivers/vfio/vfio.c | 118 + drivers/vfio/vfio_iommu_type1.c | 446 +- include/linux/iommu.h | 21 +- include/linux/vfio.h | 14 + include/uapi/linux/iommu.h| 3 + include/uapi/linux/vfio.h | 6 + 10 files changed, 661 insertions(+), 21 deletions(-) -- 2.19.1
[Resend]Re: [PATCH] [v26,1/4] scsi: ufs: Introduce HPB feature
>The Following is experiment environment: > - kernel version: 4.4.0 > - RAM: 8GB > - UFS 2.1 (64GB) > >Result: >+---+--+--+---+ >| cycle | baseline | with HPB | diff | >+---+--+--+---+ >| 1 | 272.4| 264.9| -7.5 | >| 2 | 250.4| 248.2| -2.2 | >| 3 | 226.2| 215.6| -10.6 | >| 4 | 230.6| 214.8| -15.8 | >| 5 | 232.0| 218.1| -13.9 | >| 6 | 231.9| 212.6| -19.3 | >+---+--+--+---+ > >We also measured HPB performance using iozone. >Here is my iozone script: >iozone -r 4k -+n -i2 -ecI -t 16 -l 16 -u 16 >-s $IO_RANGE/16 -F mnt/tmp_1 mnt/tmp_2 mnt/tmp_3 mnt/tmp_4 mnt/tmp_5 >mnt/tmp_6 mnt/tmp_7 mnt/tmp_8 mnt/tmp_9 mnt/tmp_10 mnt/tmp_11 mnt/tmp_12 >mnt/tmp_13 mnt/tmp_14 mnt/tmp_15 mnt/tmp_16 > >Result: >+--++-+ >| IO range | HPB on | HPB off | >+--++-+ >| 1 GB | 294.8 | 300.87 | >| 4 GB | 293.51 | 179.35 | >| 8 GB | 294.85 | 162.52 | >| 16 GB | 293.45 | 156.26 | >| 32 GB | 277.4 | 153.25 | >+--++-+ According to Samsung's iozone test result, HPB is going to boost random performance of rom on mobile, we believe it will help our customers on several occasions. WangQing
Re: [PATCH v5 11/12] x86/paravirt: switch functions with custom code to ALTERNATIVE
On 08.03.21 19:30, Borislav Petkov wrote:
On Mon, Mar 08, 2021 at 01:28:43PM +0100, Juergen Gross wrote:
diff --git a/arch/x86/include/asm/paravirt.h b/arch/x86/include/asm/paravirt.h
index 36cd71fa097f..04b3067f31b5 100644
--- a/arch/x86/include/asm/paravirt.h
+++ b/arch/x86/include/asm/paravirt.h
@@ -137,7 +137,8 @@ static inline void write_cr0(unsigned long x)
static inline unsigned long read_cr2(void)
{
- return PVOP_CALLEE0(unsigned long, mmu.read_cr2);
+ return PVOP_ALT_CALLEE0(unsigned long, mmu.read_cr2,
+ "mov %%cr2, %%rax;", ~X86_FEATURE_XENPV);
Just some cursory poking first - indepth review later.
Do I see this correctly that the negated feature can be expressed with, to use
this example here:
ALTERNATIVE_TERNARY(mmu.read_cr2, X86_FEATURE_XENPV, "", "mov %%cr2,
%%rax;");
?
No.
This would leave the Xen-pv case with a nop, while we need it to call
mmu.read_cr2().
In the Xen-pv case there must be _no_ alternative patching in order to
have the paravirt patching do its patching (indirect->direct call).
This is exactly the reason why I need to "not feature".
The only other solution I can think of would be a "split static_call"
handling using ALTERNATIVE_TERNARY():
ALTERNATIVE_TERNARY(initial_static_call(mmu.read_cr2),
X86_FEATURE_XENPV,
final_static_call(mmu.read_cr2),
"mov %%cr2, %%rax;");
with initial_static_call() doing an indirect call, while
final_static_call() would do a direct call.
Not sure we really want that.
Juergen
OpenPGP_0xB0DE9DD628BF132F.asc
Description: application/pgp-keys
OpenPGP_signature
Description: OpenPGP digital signature
[PATCH] powerpc/vdso32: Add missing _restgpr_31_x to fix build failure
With some defconfig including CONFIG_CC_OPTIMIZE_FOR_SIZE,
(for instance mvme5100_defconfig and ps3_defconfig), gcc 5
generates a call to _restgpr_31_x.
Until recently it went unnoticed, but
commit 42ed6d56ade2 ("powerpc/vdso: Block R_PPC_REL24 relocations")
made it rise to the surface.
Provide that function (copied from lib/crtsavres.S) in
gettimeofday.S
Fixes: ab037dd87a2f ("powerpc/vdso: Switch VDSO to generic C implementation.")
Signed-off-by: Christophe Leroy
---
I don't know if there is a way to tell GCC not to emit that call, because at
the end we get more instructions than needed.
---
arch/powerpc/kernel/vdso32/gettimeofday.S | 11 +++
1 file changed, 11 insertions(+)
diff --git a/arch/powerpc/kernel/vdso32/gettimeofday.S
b/arch/powerpc/kernel/vdso32/gettimeofday.S
index a6e29f880e0e..d21d08140a5e 100644
--- a/arch/powerpc/kernel/vdso32/gettimeofday.S
+++ b/arch/powerpc/kernel/vdso32/gettimeofday.S
@@ -65,3 +65,14 @@ V_FUNCTION_END(__kernel_clock_getres)
V_FUNCTION_BEGIN(__kernel_time)
cvdso_call_time __c_kernel_time
V_FUNCTION_END(__kernel_time)
+
+/* Routines for restoring integer registers, called by the compiler. */
+/* Called with r11 pointing to the stack header word of the caller of the */
+/* function, just beyond the end of the integer restore area. */
+_GLOBAL(_restgpr_31_x)
+_GLOBAL(_rest32gpr_31_x)
+ lwz r0,4(r11)
+ lwz r31,-4(r11)
+ mtlrr0
+ mr r1,r11
+ blr
--
2.25.0
[PATCH] ARM: dts: imx6ull: fix ubi mount failed on MYS-6ULX-IOT board
From: dillon min This patch intend to fix ubi filesystem mount failed on MYS-6ULX-IOT board, from Micron MT29F2G08ABAEAWP's datasheets, we need to choose 4-bit ECC. Table 18: Error Management Details Description Requirement Minimum number of valid blocks (NVB) per LUN2008 Total available blocks per LUN 2048 First spare area location x8: byte 2048 x16: word 1024 Bad-block mark x8: 00h x16: h Minimum required ECC4-bit ECC per 528 bytes Minimum ECC with internal ECC enabled 4-bit ECC per 516 bytes (user data) + 8 bytes (parity data) Minimum required ECC for block 0 if PROGRAM/ ERASE cycles are less than 1000 1-bit ECC per 528 bytes dillon min (1): ARM: dts: imx6ull: fix ubi filesystem mount failed arch/arm/boot/dts/imx6ull-myir-mys-6ulx-eval.dts | 1 + 1 file changed, 1 insertion(+) -- 2.7.4
[PATCH] ARM: dts: imx6ull: fix ubi filesystem mount failed
From: dillon min
since Micron MT29F2G08ABAEAWP's ecc error management:
|Description| Requirement
|Minimum required ECC | 4-bit ECC per 528 bytes
|Minimum ECC with internal ECC enabled | 4-bit ECC per 516 bytes (user data) +
8bytes (parity data)
to avoid unnecessary overheads related to bigger ecc calculations.
need choose to use fsl,use-minimum-ecc, else will run into ecc error.
[9.449265] ubi0: scanning is finished
[9.463968] ubi0 warning: ubi_io_read: error -74 (ECC error) while reading
22528 bytes from PEB 513:4096, read only 22528 bytes, retry
[9.486940] ubi0 warning: ubi_io_read: error -74 (ECC error) while reading
22528 bytes from PEB 513:4096, read only 22528 bytes, retry
[9.509906] ubi0 warning: ubi_io_read: error -74 (ECC error) while reading
22528 bytes from PEB 513:4096, read only 22528 bytes, retry
[9.532845] ubi0 error: ubi_io_read: error -74 (ECC error) while reading
22528 bytes from PEB 513:4096, read 22528 bytes
Fixes: f9ecf10cb88c ("ARM: dts: imx6ull: add MYiR MYS-6ULX SBC")
Signed-off-by: dillon min
---
arch/arm/boot/dts/imx6ull-myir-mys-6ulx-eval.dts | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/boot/dts/imx6ull-myir-mys-6ulx-eval.dts
b/arch/arm/boot/dts/imx6ull-myir-mys-6ulx-eval.dts
index ecbb2cc5b9ab..79cc45728cd2 100644
--- a/arch/arm/boot/dts/imx6ull-myir-mys-6ulx-eval.dts
+++ b/arch/arm/boot/dts/imx6ull-myir-mys-6ulx-eval.dts
@@ -14,5 +14,6 @@
};
{
+ fsl,use-minimum-ecc;
status = "okay";
};
--
2.7.4
Re: [PATCH v5 02/12] x86/paravirt: switch time pvops functions to use static_call()
On 08.03.21 18:00, Boris Ostrovsky wrote:
On 3/8/21 7:28 AM, Juergen Gross wrote:
--- a/arch/x86/xen/time.c
+++ b/arch/x86/xen/time.c
@@ -379,11 +379,6 @@ void xen_timer_resume(void)
}
}
-static const struct pv_time_ops xen_time_ops __initconst = {
- .sched_clock = xen_sched_clock,
- .steal_clock = xen_steal_clock,
-};
-
static struct pvclock_vsyscall_time_info *xen_clock __read_mostly;
static u64 xen_clock_value_saved;
@@ -528,7 +523,8 @@ static void __init xen_time_init(void)
void __init xen_init_time_ops(void)
{
xen_sched_clock_offset = xen_clocksource_read();
- pv_ops.time = xen_time_ops;
+ static_call_update(pv_steal_clock, xen_steal_clock);
+ paravirt_set_sched_clock(xen_sched_clock);
x86_init.timers.timer_init = xen_time_init;
x86_init.timers.setup_percpu_clockev = x86_init_noop;
@@ -570,7 +566,8 @@ void __init xen_hvm_init_time_ops(void)
}
xen_sched_clock_offset = xen_clocksource_read();
- pv_ops.time = xen_time_ops;
+ static_call_update(pv_steal_clock, xen_steal_clock);
+ paravirt_set_sched_clock(xen_sched_clock);
x86_init.timers.setup_percpu_clockev = xen_time_init;
x86_cpuinit.setup_percpu_clockev = xen_hvm_setup_cpu_clockevents;
There is a bunch of stuff that's common between the two cases so it can be
factored out.
Yes.
diff --git a/drivers/xen/time.c b/drivers/xen/time.c
index 108edbcbc040..152dd33bb223 100644
--- a/drivers/xen/time.c
+++ b/drivers/xen/time.c
@@ -7,6 +7,7 @@
#include
#include
#include
+#include
#include
#include
@@ -175,7 +176,7 @@ void __init xen_time_setup_guest(void)
xen_runstate_remote = !HYPERVISOR_vm_assist(VMASST_CMD_enable,
VMASST_TYPE_runstate_update_flag);
- pv_ops.time.steal_clock = xen_steal_clock;
+ static_call_update(pv_steal_clock, xen_steal_clock);
Do we actually need this? We've already set this up in xen_init_time_ops().
(But maybe for ARM).
Correct. Arm needs this.
Juergen
OpenPGP_0xB0DE9DD628BF132F.asc
Description: application/pgp-keys
OpenPGP_signature
Description: OpenPGP digital signature
Re: mmotm 2021-03-08-21-52 uploaded
Hi Andrew, On Mon, 08 Mar 2021 21:52:55 -0800 a...@linux-foundation.org wrote: > > * mm-mempool-minor-coding-style-tweaks.patch . . > * mm-mempool-minor-coding-style-tweaks.patch This patch appears twice (I just dropped the second one). -- Cheers, Stephen Rothwell pgpEU5FIiKg1t.pgp Description: OpenPGP digital signature
Re: [EXT] [PATCH v2 2/4] dt-bindings: spi: add compatible entry for imx8mp in FlexSPI controller
Hi! On 09.03.21 06:56, Kuldeep Singh wrote: > Hi Heiko, > >> -Original Message- >> From: Heiko Schocher >> Sent: Tuesday, March 9, 2021 11:01 AM >> To: linux-arm-ker...@lists.infradead.org >> Cc: Heiko Schocher ; Ashish Kumar ; >> Mark Brown ; Rob Herring ; Yogesh >> Gaur ; devicet...@vger.kernel.org; linux- >> ker...@vger.kernel.org; linux-...@vger.kernel.org >> Subject: [EXT] [PATCH v2 2/4] dt-bindings: spi: add compatible entry for >> imx8mp in >> FlexSPI controller >> >> Caution: EXT Email >> >> add compatible entry "nxp,imx8mp-fspi" in NXP FlexSPI controller >> >> Signed-off-by: Heiko Schocher >> --- >> >> (no changes since v1) >> >> Documentation/devicetree/bindings/spi/spi-nxp-fspi.txt | 1 + >> 1 file changed, 1 insertion(+) >> >> diff --git a/Documentation/devicetree/bindings/spi/spi-nxp-fspi.txt >> b/Documentation/devicetree/bindings/spi/spi-nxp-fspi.txt >> index 7ac60d9fe3571..fd5f081f6d91b 100644 >> --- a/Documentation/devicetree/bindings/spi/spi-nxp-fspi.txt >> +++ b/Documentation/devicetree/bindings/spi/spi-nxp-fspi.txt >> @@ -4,6 +4,7 @@ Required properties: >>- compatible : Should be "nxp,lx2160a-fspi" >> "nxp,imx8qxp-fspi" >> "nxp,imx8mm-fspi" >> + "nxp,imx8mp-fspi" > > It seems the changes are not on top of tree. Please see[1] for latest changes > including imx8dxl entry. > Snippet below: > > Required properties: > - compatible : Should be "nxp,lx2160a-fspi" > "nxp,imx8qxp-fspi" > "nxp,imx8mm-fspi" > "nxp,imx8dxl-fspi" My patches are based on mainline.. * 144c79ef33536 - (origin/master, origin/HEAD) Merge tag 'perf-tools-fixes-for-v5.12-2020-03-07' of git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux (vor 32 Stunden) Should I post this patch rebased on [1] or may all patches rebased on [1] ? Thanks! bye, Heiko > > Thanks > Kuldeep > [1] > https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git/tree/Documentation/devicetree/bindings/spi/spi-nxp-fspi.txt > -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-52 Fax: +49-8142-66989-80 Email: h...@denx.de
Re: [PATCH] mm/memory-failure: Use a mutex to avoid memory_failure() races
On Tue, Mar 09, 2021 at 10:04:21AM +0800, Aili Yao wrote:
> On Mon, 8 Mar 2021 14:55:04 -0800
> "Luck, Tony" wrote:
>
> > There can be races when multiple CPUs consume poison from the same
> > page. The first into memory_failure() atomically sets the HWPoison
> > page flag and begins hunting for tasks that map this page. Eventually
> > it invalidates those mappings and may send a SIGBUS to the affected
> > tasks.
> >
> > But while all that work is going on, other CPUs see a "success"
> > return code from memory_failure() and so they believe the error
> > has been handled and continue executing.
> >
> > Fix by wrapping most of the internal parts of memory_failure() in
> > a mutex.
> >
> > Signed-off-by: Tony Luck
> > ---
...
>
> If others are OK with this method, then I am OK too.
> But I have two concerns, May you take into account:
>
> 1. The memory_failure with 0 return code for race condition, then the
> kill_me_maybe() goes into branch:
> if (!memory_failure(p->mce_addr >> PAGE_SHIFT, flags) &&
> !(p->mce_kflags & MCE_IN_KERNEL_COPYIN)) {
> set_mce_nospec(p->mce_addr >> PAGE_SHIFT, p->mce_whole_page);
> sync_core();
> return;
> }
>
> while we place set_mce_nospec() here is for a reason, please see commit
> fd0e786d9d09024f67b.
>
> 2. When memory_failure return 0 and maybe return to user process, and it may
> re-execute the instruction triggering previous fault, this behavior
> assume an implicit dependence that the related pte has been correctly set. or
> if not correctlily set, it will lead to infinite loop again.
These seem to be separate issues from memory_failure()'s concurrency issue,
so I'm still expecting that your patch is to be merged. Maybe do you want
to update it based on the discussion (if it's concluded)?
Thanks,
Naoya Horiguchi
Re: kernel panic: Attempted to kill init!
On Mon, Mar 8, 2021 at 10:50 PM Al Viro wrote:
> I'd suggest to add printk(KERN_ERR "got to %d", __LINE__); in fs/fhandle.c at
> beginning of do_handle_open()
> right before each copy_from_user() in handle_to_path()
> right before and right after the call of do_handle_to_path() (in the
> same)
> and try your reproducers on the resulting kernel.
While applying this diff and re-running the reproducer, I see the following:
diff --git a/fs/fhandle.c b/fs/fhandle.c
index 01263ffbc4c0..4e0b171ec9af 100644
--- a/fs/fhandle.c
+++ b/fs/fhandle.c
@@ -180,6 +180,7 @@ static int handle_to_path(int mountdirfd, struct
file_handle __user *ufh,
retval = -EPERM;
goto out_err;
}
+ printk(KERN_ERR "got to %d", __LINE__);
if (copy_from_user(_handle, ufh, sizeof(struct file_handle))) {
retval = -EFAULT;
goto out_err;
@@ -197,14 +198,16 @@ static int handle_to_path(int mountdirfd, struct
file_handle __user *ufh,
}
/* copy the full handle */
*handle = f_handle;
+ printk(KERN_ERR "got to %d", __LINE__);
if (copy_from_user(>f_handle,
>f_handle,
f_handle.handle_bytes)) {
retval = -EFAULT;
goto out_handle;
}
-
+ printk(KERN_ERR "got to %d", __LINE__);
retval = do_handle_to_path(mountdirfd, handle, path);
+ printk(KERN_ERR "got to %d", __LINE__);
out_handle:
kfree(handle);
@@ -215,6 +218,7 @@ static int handle_to_path(int mountdirfd, struct
file_handle __user *ufh,
static long do_handle_open(int mountdirfd, struct file_handle __user *ufh,
int open_flag)
{
+ printk(KERN_ERR "got to %d", __LINE__);
long retval = 0;
struct path path;
struct file *file
root@sandbox:~# ./repro
[8.325247] got to 221
[8.325270] got to 183
[8.326433] got to 201
[8.327620] got to 208
[8.328983] got to 210
[8.360955] Kernel panic - not syncing: Attempted to kill init!
exitcode=0x000b
[8.362261] CPU: 0 PID: 1 Comm: systemd Not tainted 5.11.2+ #20
[8.363015] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996),
BIOS 1.14.0-1 04/01/2014
[8.364044] Call Trace:
[8.364357] dump_stack+0xb2/0xe4
[8.364782] panic+0x196/0x502
[8.365171] do_exit.cold+0x70/0x108
[8.365624] do_group_exit+0x78/0x120
[8.366087] get_signal+0x22e/0xd60
[8.366528] arch_do_signal_or_restart+0xef/0x890
[8.367120] exit_to_user_mode_prepare+0x102/0x190
[8.367724] irqentry_exit_to_user_mode+0x9/0x20
[8.368303] irqentry_exit+0x19/0x30
[8.368759] exc_page_fault+0xc3/0x240
[8.369220] ? asm_exc_page_fault+0x8/0x30
[8.369726] asm_exc_page_fault+0x1e/0x30
[8.370217] RIP: 0033:0x7fa902b4cf10
[8.370661] Code: Unable to access opcode bytes at RIP 0x7fa902b4cee6.
[8.371444] RSP: 002b:7ffc391b20b8 EFLAGS: 00010246
[8.372081] RAX: RBX: 559276a67f40 RCX: 7fa902b7d2e3
[8.372935] RDX: 7ffc391b2240 RSI: 7ffc391b2370 RDI: 0007
[8.373860] RBP: 0007 R08: R09: 000b
[8.374714] R10: R11: 0246 R12: 7ffc399afaa0
[8.375568] R13: 0001 R14: R15: 0002
[8.376574] Kernel Offset: disabled
[8.376992] ---[ end Kernel panic - not syncing: Attempted to kill
init! exitcode=0x000b ]---
When I add this change on top of the previous diff:
@@ -263,6 +267,7 @@ SYSCALL_DEFINE3(open_by_handle_at, int, mountdirfd,
flags |= O_LARGEFILE;
ret = do_handle_open(mountdirfd, handle, flags);
+ printk(KERN_ERR "got to %d", __LINE__);
return ret;
}
I observe the following result(notice the segfault in systemd):
root@sandbox:~# ./repro
[9.457767] got to 221
[9.457791] got to 183
[9.459144] got to 201
[9.459471] got to 208
[9.459773] got to 210
[9.462602] got to 270
[9.488551] systemd[1]: segfault at 7ffe59fd7fb8 ip
55be8f20b466 sp 7ffe59fd7fc0 error 6 in
systemd[55be8f15f000+ed000]
[9.490723] Code: 00 00 00 00 41 57 41 56 41 55 41 54 55 53 89 fd
48 81 ec 48 01 00 00 64 48 8b 04 25 28 00 00 00 48 89 84 24 38 01 00
00 31 c0 f5 bf f7 ff 83 f8 01 0f 84 b7 00 00 00 48 8d 9c 240
[9.492637] Kernel panic - not syncing: Attempted to kill init!
exitcode=0x000b
[9.493421] CPU: 0 PID: 1 Comm: systemd Not tainted 5.11.2+ #22
[9.494067] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996),
BIOS 1.14.0-1 04/01/2014
[9.495082] Call Trace:
[9.495348] dump_stack+0xb2/0xe4
[9.495709] panic+0x196/0x502
[9.496041] do_exit.cold+0x70/0x108
[9.496429] do_group_exit+0x78/0x120
[9.496822] get_signal+0x22e/0xd60
[9.497205] arch_do_signal_or_restart+0xef/0x890
[9.497708] exit_to_user_mode_prepare+0x102/0x190
[
Re: [PATCH 8/9] arm64: dts: qcom: sc7280: Add AOSS QMP node
On 2021-02-27 19:26, Sai Prakash Ranjan wrote:
On 2021-02-27 00:16, Stephen Boyd wrote:
Quoting Sai Prakash Ranjan (2021-02-25 23:51:00)
On 2021-02-26 01:11, Stephen Boyd wrote:
> Quoting Sai Prakash Ranjan (2021-02-25 01:30:24)
>> Add a DT node for the AOSS QMP on SC7280 SoC.
>>
>> Signed-off-by: Sai Prakash Ranjan
>> ---
>> arch/arm64/boot/dts/qcom/sc7280.dtsi | 14 ++
>> 1 file changed, 14 insertions(+)
>>
>> diff --git a/arch/arm64/boot/dts/qcom/sc7280.dtsi
>> b/arch/arm64/boot/dts/qcom/sc7280.dtsi
>> index 65c1e0f2fb56..cbd567ccc04e 100644
>> --- a/arch/arm64/boot/dts/qcom/sc7280.dtsi
>> +++ b/arch/arm64/boot/dts/qcom/sc7280.dtsi
>> @@ -9,6 +9,7 @@
>> #include
>> #include
>> #include
>> +#include
>> #include
>>
>> / {
>> @@ -368,6 +369,19 @@ pdc: interrupt-controller@b22 {
>> interrupt-controller;
>> };
>>
>> + aoss_qmp: qmp@c30 {
>
> power-domain-controller@c30? power-controller@c30?
>
Its an AOSS message RAM and all other SM* SoCs have as qmp@
and the dt binding as well, I see only SM8150 with power-controller,
that should probably be fixed?
Node name should be generic while still being meaningful. Nobody knows
what qmp is, but power-controller makes sense. Can you fix this and
the
others to be power-controller?
we probably would be changing them back
to qmp or something more generic soon
since the consensus was qmp wasn't a
power-controller. So not sure if its
worth the effort here.
Ok makes sense, I will post changing others as well and see if we get
any comments there.
Thanks,
Sai
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project.
RE: [PATCH 2/2] iio:magnetometer: Support for ST magnetic sensors
Hi Jonathan, Thanks for your input, I will integrate into existing magnetometers driver! Best Regards ** Li Qingwu (Terry) ** -Original Message- From: Jonathan Cameron Sent: Sunday, March 7, 2021 12:42 AM To: LI Qingwu Cc: l...@metafoo.de; pme...@pmeerw.net; robh...@kernel.org; denis.cio...@st.com; linux-...@vger.kernel.org; devicet...@vger.kernel.org; linux-kernel@vger.kernel.org; TERTYCHNYI Grygorii ; ZHIZHIKIN Andrey ; Lorenzo Bianconi Subject: Re: [PATCH 2/2] iio:magnetometer: Support for ST magnetic sensors This email is not from Hexagon’s Office 365 instance. Please be careful while clicking links, opening attachments, or replying to this email. On Fri, 5 Mar 2021 07:05:36 + LI Qingwu wrote: > Add support for STMicroelectronics digital magnetic sensors, > LSM303AH,LSM303AGR,LIS2MDL,ISM303DAC,IIS2MDC. > > The patch tested with IIS2MDC instrument. > > Signed-off-by: LI Qingwu Hi, Given that at least two parts in here is supported by the existing driver in iio/magnetometers/st_magn_*.c (lsm303agr) can you confirm that it doesn't make sense to simply extend that driver to support the other parts? This is particularly true when the WHO AM I register reads 0x40 for all these parts. I've done a fairly superficial review whilst here, but please check you can't just add the relevant entries to the existing driver. Jonathan +CC Lorenzo > --- > drivers/iio/magnetometer/Kconfig | 23 ++ > drivers/iio/magnetometer/Makefile | 4 + > drivers/iio/magnetometer/st_mag40_buffer.c | 191 +++ > drivers/iio/magnetometer/st_mag40_core.c | 371 + > drivers/iio/magnetometer/st_mag40_core.h | 136 > drivers/iio/magnetometer/st_mag40_i2c.c| 180 ++ > drivers/iio/magnetometer/st_mag40_spi.c| 188 +++ > 7 files changed, 1093 insertions(+) > create mode 100644 drivers/iio/magnetometer/st_mag40_buffer.c > create mode 100644 drivers/iio/magnetometer/st_mag40_core.c > create mode 100644 drivers/iio/magnetometer/st_mag40_core.h > create mode 100644 drivers/iio/magnetometer/st_mag40_i2c.c > create mode 100644 drivers/iio/magnetometer/st_mag40_spi.c > > diff --git a/drivers/iio/magnetometer/Kconfig > b/drivers/iio/magnetometer/Kconfig > index 1697a8c03506..bfd2866faa99 100644 > --- a/drivers/iio/magnetometer/Kconfig > +++ b/drivers/iio/magnetometer/Kconfig > @@ -205,4 +205,27 @@ config SENSORS_RM3100_SPI > To compile this driver as a module, choose M here: the module > will be called rm3100-spi. > > +config ST_MAG40_IIO > + tristate "STMicroelectronics > LIS2MDL/LSM303AH/LSM303AGR/ISM303DAC/IIS2MDC sensor" > + depends on (I2C || SPI) && SYSFS > + select IIO_BUFFER > + select IIO_TRIGGERED_BUFFER > + select ST_MAG40_I2C_IIO if (I2C) > + select ST_MAG40_SPI_IIO if (SPI) > + help > + Say yes here to build support for STMicroelectronics magnetometers: > + LIS2MDL, LSM303AH, LSM303AGR, ISM303DAC, IIS2MDC. > + > + To compile this driver as a module, choose M here. The module > + will be called st_mag40. > + > +config ST_MAG40_I2C_IIO > + tristate > + depends on ST_MAG40_IIO > + depends on I2C > + > +config ST_MAG40_SPI_IIO > + tristate > + depends on ST_MAG40_IIO > + depends on SPI > endmenu > diff --git a/drivers/iio/magnetometer/Makefile > b/drivers/iio/magnetometer/Makefile > index ba1bc34b82fa..b6b427cfc284 100644 > --- a/drivers/iio/magnetometer/Makefile > +++ b/drivers/iio/magnetometer/Makefile > @@ -25,6 +25,10 @@ obj-$(CONFIG_SENSORS_HMC5843) += > hmc5843_core.o > obj-$(CONFIG_SENSORS_HMC5843_I2C)+= hmc5843_i2c.o > obj-$(CONFIG_SENSORS_HMC5843_SPI)+= hmc5843_spi.o > > +st_mag40-y += st_mag40_buffer.o st_mag40_core.o > +obj-$(CONFIG_ST_MAG40_IIO) += st_mag40.o > +obj-$(CONFIG_ST_MAG40_I2C_IIO) += st_mag40_i2c.o > +obj-$(CONFIG_ST_MAG40_SPI_IIO) += st_mag40_spi.o > obj-$(CONFIG_SENSORS_RM3100) += rm3100-core.o > obj-$(CONFIG_SENSORS_RM3100_I2C) += rm3100-i2c.o > obj-$(CONFIG_SENSORS_RM3100_SPI) += rm3100-spi.o > diff --git a/drivers/iio/magnetometer/st_mag40_buffer.c > b/drivers/iio/magnetometer/st_mag40_buffer.c > new file mode 100644 > index ..d2a67c9dae5e > --- /dev/null > +++ b/drivers/iio/magnetometer/st_mag40_buffer.c > @@ -0,0 +1,191 @@ > +// SPDX-License-Identifier: GPL-2.0 > +/* > + * STMicroelectronics st_mag40 driver > + * > + * Copyright 2016 STMicroelectronics Inc. > + * > + * Matteo Dameno > + * Armando Visconti > + * Lorenzo Bianconi > + * > + * Licensed under the GPL-2. > + */ > + > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include #include > + > + > +#include "st_mag40_core.h" > + > +#define ST_MAG40_EWMA_DIV128 > +static inline s64 st_mag40_ewma(s64 old,
RE: [EXT] [PATCH v2 2/4] dt-bindings: spi: add compatible entry for imx8mp in FlexSPI controller
Hi Heiko, > -Original Message- > From: Heiko Schocher > Sent: Tuesday, March 9, 2021 11:01 AM > To: linux-arm-ker...@lists.infradead.org > Cc: Heiko Schocher ; Ashish Kumar ; > Mark Brown ; Rob Herring ; Yogesh > Gaur ; devicet...@vger.kernel.org; linux- > ker...@vger.kernel.org; linux-...@vger.kernel.org > Subject: [EXT] [PATCH v2 2/4] dt-bindings: spi: add compatible entry for > imx8mp in > FlexSPI controller > > Caution: EXT Email > > add compatible entry "nxp,imx8mp-fspi" in NXP FlexSPI controller > > Signed-off-by: Heiko Schocher > --- > > (no changes since v1) > > Documentation/devicetree/bindings/spi/spi-nxp-fspi.txt | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/Documentation/devicetree/bindings/spi/spi-nxp-fspi.txt > b/Documentation/devicetree/bindings/spi/spi-nxp-fspi.txt > index 7ac60d9fe3571..fd5f081f6d91b 100644 > --- a/Documentation/devicetree/bindings/spi/spi-nxp-fspi.txt > +++ b/Documentation/devicetree/bindings/spi/spi-nxp-fspi.txt > @@ -4,6 +4,7 @@ Required properties: >- compatible : Should be "nxp,lx2160a-fspi" > "nxp,imx8qxp-fspi" > "nxp,imx8mm-fspi" > + "nxp,imx8mp-fspi" It seems the changes are not on top of tree. Please see[1] for latest changes including imx8dxl entry. Snippet below: Required properties: - compatible : Should be "nxp,lx2160a-fspi" "nxp,imx8qxp-fspi" "nxp,imx8mm-fspi" "nxp,imx8dxl-fspi" Thanks Kuldeep [1] https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git/tree/Documentation/devicetree/bindings/spi/spi-nxp-fspi.txt
mmotm 2021-03-08-21-52 uploaded
The mm-of-the-moment snapshot 2021-03-08-21-52 has been uploaded to https://www.ozlabs.org/~akpm/mmotm/ mmotm-readme.txt says README for mm-of-the-moment: https://www.ozlabs.org/~akpm/mmotm/ This is a snapshot of my -mm patch queue. Uploaded at random hopefully more than once a week. You will need quilt to apply these patches to the latest Linus release (5.x or 5.x-rcY). The series file is in broken-out.tar.gz and is duplicated in https://ozlabs.org/~akpm/mmotm/series The file broken-out.tar.gz contains two datestamp files: .DATE and .DATE--mm-dd-hh-mm-ss. Both contain the string -mm-dd-hh-mm-ss, followed by the base kernel version against which this patch series is to be applied. This tree is partially included in linux-next. To see which patches are included in linux-next, consult the `series' file. Only the patches within the #NEXT_PATCHES_START/#NEXT_PATCHES_END markers are included in linux-next. A full copy of the full kernel tree with the linux-next and mmotm patches already applied is available through git within an hour of the mmotm release. Individual mmotm releases are tagged. The master branch always points to the latest release, so it's constantly rebasing. https://github.com/hnaz/linux-mm The directory https://www.ozlabs.org/~akpm/mmots/ (mm-of-the-second) contains daily snapshots of the -mm tree. It is updated more frequently than mmotm, and is untested. A git copy of this tree is also available at https://github.com/hnaz/linux-mm This mmotm tree contains the following patches against 5.12-rc2: (patches marked "*" will be included in linux-next) origin.patch * memblock-fix-section-mismatch-warning.patch * stop_machine-mark-helpers-__always_inline.patch * init-kconfig-make-compile_test-depend-on-has_iomem.patch * mm-page_allocc-refactor-initialization-of-struct-page-for-holes-in-memory-layout.patch * mm-page_allocc-refactor-initialization-of-struct-page-for-holes-in-memory-layout-fix.patch * mm-fork-clear-pasid-for-new-mm.patch * hugetlb_cgroup-fix-imbalanced-css_get-and-css_put-pair-for-shared-mappings.patch * fix-zero_user_segments-with-start-end.patch * binfmt_misc-fix-possible-deadlock-in-bm_register_write.patch * maintainers-exclude-uapi-directories-in-api-abi-section.patch * linux-compiler-clangh-define-have_builtin_bswap.patch * kfence-fix-printk-format-for-ptrdiff_t.patch * kfence-slab-fix-cache_alloc_debugcheck_after-for-bulk-allocations.patch * kfence-fix-reports-if-constant-function-prefixes-exist.patch * mm-use-rcu_dereference-in-in_vfork.patch * mm-madvise-replace-ptrace-attach-requirement-for-process_madvise.patch * ia64-fix-ia64_syscall_get_set_arguments-for-break-based-syscalls.patch * ia64-fix-ptraceptrace_syscall_info_exit-sign.patch * kasan-mm-fix-crash-with-hw_tags-and-debug_pagealloc.patch * kasan-fix-kasan_stack-dependency-for-hw_tags.patch * mm-userfaultfd-fix-memory-corruption-due-to-writeprotect.patch * mm-hwpoison-do-not-lock-page-again-when-me_huge_page-successfully-recovers.patch * hugetlb-dedup-the-code-to-add-a-new-file_region.patch * hugetlg-break-earlier-in-add_reservation_in_range-when-we-can.patch * mm-introduce-page_needs_cow_for_dma-for-deciding-whether-cow.patch * mm-use-is_cow_mapping-across-tree-where-proper.patch * hugetlb-do-early-cow-when-page-pinned-on-src-mm.patch * mm-memcg-rename-mem_cgroup_split_huge_fixup-to-split_page_memcg.patch * mm-memcg-set-memcg-when-split-page.patch * proc-kpageflags-prevent-an-integer-overflow-in-stable_page_flags.patch * proc-kpageflags-do-not-use-uninitialized-struct-pages.patch * module-remove-duplicate-include-in-arch-ia64-kernel-heads.patch * sparse-can-do-constant-folding-of-__builtin_bswap.patch * scripts-spellingtxt-add-overlfow.patch * scripts-spellingtxt-add-diabled-typo.patch * scripts-spellingtxt-add-overflw.patch * sh-remove-duplicate-include-in-tlbh.patch * ocfs2-replace-define_simple_attribute-with-define_debugfs_attribute.patch * ocfs2-clear-links-count-in-ocfs2_mknod-if-an-error-occurs.patch * ocfs2-fix-ocfs2-corrupt-when-iputting-an-inode.patch * kernel-watchdog-flush-all-printk-nmi-buffers-when-hardlockup-detected.patch mm.patch * mm-page_owner-record-the-timestamp-of-all-pages-during-free.patch * mm-provide-filemap_range_needs_writeback-helper.patch * mm-use-filemap_range_needs_writeback-for-o_direct-reads.patch * iomap-use-filemap_range_needs_writeback-for-o_direct-reads.patch * mm-filemap-use-filemap_read_page-in-filemap_fault.patch * mm-filemap-drop-check-for-truncated-page-after-i-o.patch * mm-page-writeback-simplify-memcg-handling-in-test_clear_page_writeback.patch * mm-msync-exit-early-when-the-flags-is-an-ms_async-and-start-vm_start.patch * mm-memremap-fixes-improper-spdx-comment-style.patch * mm-memcontrol-fix-kernel-stack-account.patch * memcg-cleanup-root-memcg-checks.patch * memcg-enable-memcg-oom-kill-for-__gfp_nofail.patch * memcg-charge-before-adding-to-swapcache-on-swapin.patch *
[PATCH 5/6] reset: qcom: Add PDC Global reset signals for WPSS
Add PDC Global reset signals for Wireless Processor Subsystem (WPSS)
on SC7280 SoCs.
Signed-off-by: Sibi Sankar
---
drivers/reset/reset-qcom-pdc.c | 62 ++
1 file changed, 51 insertions(+), 11 deletions(-)
diff --git a/drivers/reset/reset-qcom-pdc.c b/drivers/reset/reset-qcom-pdc.c
index ab74bccd4a5b..bb7113ae6232 100644
--- a/drivers/reset/reset-qcom-pdc.c
+++ b/drivers/reset/reset-qcom-pdc.c
@@ -11,18 +11,26 @@
#include
-#define RPMH_PDC_SYNC_RESET0x100
+#define RPMH_SDM845_PDC_SYNC_RESET 0x100
+#define RPMH_SC7280_PDC_SYNC_RESET 0x1000
struct qcom_pdc_reset_map {
u8 bit;
};
+struct qcom_pdc_reset_desc {
+ const struct qcom_pdc_reset_map *resets;
+ unsigned int offset;
+ size_t num_resets;
+};
+
struct qcom_pdc_reset_data {
struct reset_controller_dev rcdev;
struct regmap *regmap;
+ const struct qcom_pdc_reset_desc *desc;
};
-static const struct regmap_config sdm845_pdc_regmap_config = {
+static const struct regmap_config pdc_regmap_config = {
.name = "pdc-reset",
.reg_bits = 32,
.reg_stride = 4,
@@ -44,6 +52,33 @@ static const struct qcom_pdc_reset_map sdm845_pdc_resets[] =
{
[PDC_MODEM_SYNC_RESET] = {9},
};
+static const struct qcom_pdc_reset_desc sdm845_pdc_reset_desc = {
+ .resets = sdm845_pdc_resets,
+ .offset = RPMH_SDM845_PDC_SYNC_RESET,
+ .num_resets = ARRAY_SIZE(sdm845_pdc_resets),
+};
+
+static const struct qcom_pdc_reset_map sc7280_pdc_resets[] = {
+ [PDC_APPS_SYNC_RESET] = {0},
+ [PDC_SP_SYNC_RESET] = {1},
+ [PDC_AUDIO_SYNC_RESET] = {2},
+ [PDC_SENSORS_SYNC_RESET] = {3},
+ [PDC_AOP_SYNC_RESET] = {4},
+ [PDC_DEBUG_SYNC_RESET] = {5},
+ [PDC_GPU_SYNC_RESET] = {6},
+ [PDC_DISPLAY_SYNC_RESET] = {7},
+ [PDC_COMPUTE_SYNC_RESET] = {8},
+ [PDC_MODEM_SYNC_RESET] = {9},
+ [PDC_WLAN_RF_SYNC_RESET] = {10},
+ [PDC_WPSS_SYNC_RESET] = {11},
+};
+
+static const struct qcom_pdc_reset_desc sc7280_pdc_reset_desc = {
+ .resets = sc7280_pdc_resets,
+ .offset = RPMH_SC7280_PDC_SYNC_RESET,
+ .num_resets = ARRAY_SIZE(sc7280_pdc_resets),
+};
+
static inline struct qcom_pdc_reset_data *to_qcom_pdc_reset_data(
struct reset_controller_dev *rcdev)
{
@@ -54,19 +89,18 @@ static int qcom_pdc_control_assert(struct
reset_controller_dev *rcdev,
unsigned long idx)
{
struct qcom_pdc_reset_data *data = to_qcom_pdc_reset_data(rcdev);
+ const struct qcom_pdc_reset_map *map = >desc->resets[idx];
- return regmap_update_bits(data->regmap, RPMH_PDC_SYNC_RESET,
- BIT(sdm845_pdc_resets[idx].bit),
- BIT(sdm845_pdc_resets[idx].bit));
+ return regmap_update_bits(data->regmap, data->desc->offset,
BIT(map->bit), BIT(map->bit));
}
static int qcom_pdc_control_deassert(struct reset_controller_dev *rcdev,
unsigned long idx)
{
struct qcom_pdc_reset_data *data = to_qcom_pdc_reset_data(rcdev);
+ const struct qcom_pdc_reset_map *map = >desc->resets[idx];
- return regmap_update_bits(data->regmap, RPMH_PDC_SYNC_RESET,
- BIT(sdm845_pdc_resets[idx].bit), 0);
+ return regmap_update_bits(data->regmap, data->desc->offset,
BIT(map->bit), 0);
}
static const struct reset_control_ops qcom_pdc_reset_ops = {
@@ -76,22 +110,27 @@ static const struct reset_control_ops qcom_pdc_reset_ops =
{
static int qcom_pdc_reset_probe(struct platform_device *pdev)
{
+ const struct qcom_pdc_reset_desc *desc;
struct qcom_pdc_reset_data *data;
struct device *dev = >dev;
void __iomem *base;
struct resource *res;
+ desc = device_get_match_data(>dev);
+ if (!desc)
+ return -EINVAL;
+
data = devm_kzalloc(dev, sizeof(*data), GFP_KERNEL);
if (!data)
return -ENOMEM;
+ data->desc = desc;
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
base = devm_ioremap_resource(dev, res);
if (IS_ERR(base))
return PTR_ERR(base);
- data->regmap = devm_regmap_init_mmio(dev, base,
-_pdc_regmap_config);
+ data->regmap = devm_regmap_init_mmio(dev, base, _regmap_config);
if (IS_ERR(data->regmap)) {
dev_err(dev, "Unable to initialize regmap\n");
return PTR_ERR(data->regmap);
@@ -99,14 +138,15 @@ static int qcom_pdc_reset_probe(struct platform_device
*pdev)
data->rcdev.owner = THIS_MODULE;
data->rcdev.ops = _pdc_reset_ops;
- data->rcdev.nr_resets = ARRAY_SIZE(sdm845_pdc_resets);
+ data->rcdev.nr_resets = desc->num_resets;
data->rcdev.of_node = dev->of_node;
[PATCH 4/6] dt-bindings: reset: pdc: Add PDC Global bindings
Add PDC Global reset controller bindings for SC7280 SoCs. Signed-off-by: Sibi Sankar --- Documentation/devicetree/bindings/reset/qcom,pdc-global.yaml | 4 include/dt-bindings/reset/qcom,sdm845-pdc.h | 2 ++ 2 files changed, 6 insertions(+) diff --git a/Documentation/devicetree/bindings/reset/qcom,pdc-global.yaml b/Documentation/devicetree/bindings/reset/qcom,pdc-global.yaml index d7d8cec9419f..831ea8d5d83f 100644 --- a/Documentation/devicetree/bindings/reset/qcom,pdc-global.yaml +++ b/Documentation/devicetree/bindings/reset/qcom,pdc-global.yaml @@ -21,6 +21,10 @@ properties: - const: "qcom,sc7180-pdc-global" - const: "qcom,sdm845-pdc-global" + - description: on SC7280 SoCs the following compatibles must be specified +items: + - const: "qcom,sc7280-pdc-global" + - description: on SDM845 SoCs the following compatibles must be specified items: - const: "qcom,sdm845-pdc-global" diff --git a/include/dt-bindings/reset/qcom,sdm845-pdc.h b/include/dt-bindings/reset/qcom,sdm845-pdc.h index 53c37f9c319a..03a0c0eb8147 100644 --- a/include/dt-bindings/reset/qcom,sdm845-pdc.h +++ b/include/dt-bindings/reset/qcom,sdm845-pdc.h @@ -16,5 +16,7 @@ #define PDC_DISPLAY_SYNC_RESET 7 #define PDC_COMPUTE_SYNC_RESET 8 #define PDC_MODEM_SYNC_RESET 9 +#define PDC_WLAN_RF_SYNC_RESET 10 +#define PDC_WPSS_SYNC_RESET11 #endif -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project
[PATCH 6/6] arm64: dts: qcom: sc7280: Add nodes to boot WPSS
Add miscellaneous nodes to boot the Wireless Processor Subsystem on
SC7280 SoCs.
Signed-off-by: Sibi Sankar
---
https://patchwork.kernel.org/project/linux-arm-msm/list/?series=438217
Depends on ipcc dt node enablement from ^^
arch/arm64/boot/dts/qcom/sc7280.dtsi | 143 +++
1 file changed, 143 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sc7280.dtsi
b/arch/arm64/boot/dts/qcom/sc7280.dtsi
index 18637c369c1d..4f03c468df51 100644
--- a/arch/arm64/boot/dts/qcom/sc7280.dtsi
+++ b/arch/arm64/boot/dts/qcom/sc7280.dtsi
@@ -10,6 +10,8 @@
#include
#include
#include
+#include
+#include
#include
/ {
@@ -50,6 +52,11 @@
no-map;
};
+ smem_mem: memory@8090 {
+ reg = <0x0 0x8090 0x0 0x20>;
+ no-map;
+ };
+
cpucp_mem: memory@80b0 {
no-map;
reg = <0x0 0x80b0 0x0 0x10>;
@@ -244,12 +251,131 @@
reg = <0 0x8000 0 0>;
};
+ tcsr_mutex: hwlock {
+ compatible = "qcom,tcsr-mutex";
+ syscon = <_mutex_regs 0 0x1000>;
+ #hwlock-cells = <1>;
+ };
+
+ smem {
+ compatible = "qcom,smem";
+ memory-region = <_mem>;
+ hwlocks = <_mutex 3>;
+ };
+
firmware {
scm {
compatible = "qcom,scm-sc7280", "qcom,scm";
};
};
+ smp2p-adsp {
+ compatible = "qcom,smp2p";
+ qcom,smem = <443>, <429>;
+ interrupts-extended = < IPCC_CLIENT_LPASS
+IPCC_MPROC_SIGNAL_SMP2P
+IRQ_TYPE_EDGE_RISING>;
+ mboxes = < IPCC_CLIENT_LPASS
+ IPCC_MPROC_SIGNAL_SMP2P>;
+
+ qcom,local-pid = <0>;
+ qcom,remote-pid = <2>;
+
+ adsp_smp2p_out: master-kernel {
+ qcom,entry-name = "master-kernel";
+ #qcom,smem-state-cells = <1>;
+ };
+
+ adsp_smp2p_in: slave-kernel {
+ qcom,entry-name = "slave-kernel";
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ };
+ };
+
+ smp2p-cdsp {
+ compatible = "qcom,smp2p";
+ qcom,smem = <94>, <432>;
+ interrupts-extended = < IPCC_CLIENT_CDSP
+IPCC_MPROC_SIGNAL_SMP2P
+IRQ_TYPE_EDGE_RISING>;
+ mboxes = < IPCC_CLIENT_CDSP
+ IPCC_MPROC_SIGNAL_SMP2P>;
+
+ qcom,local-pid = <0>;
+ qcom,remote-pid = <5>;
+
+ cdsp_smp2p_out: master-kernel {
+ qcom,entry-name = "master-kernel";
+ #qcom,smem-state-cells = <1>;
+ };
+
+ cdsp_smp2p_in: slave-kernel {
+ qcom,entry-name = "slave-kernel";
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ };
+ };
+
+ smp2p-mpss {
+ compatible = "qcom,smp2p";
+ qcom,smem = <435>, <428>;
+ interrupts-extended = < IPCC_CLIENT_MPSS
+IPCC_MPROC_SIGNAL_SMP2P
+IRQ_TYPE_EDGE_RISING>;
+ mboxes = < IPCC_CLIENT_MPSS
+ IPCC_MPROC_SIGNAL_SMP2P>;
+
+ qcom,local-pid = <0>;
+ qcom,remote-pid = <1>;
+
+ modem_smp2p_out: master-kernel {
+ qcom,entry-name = "master-kernel";
+ #qcom,smem-state-cells = <1>;
+ };
+
+ modem_smp2p_in: slave-kernel {
+ qcom,entry-name = "slave-kernel";
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ };
+
+ ipa_smp2p_out: ipa-ap-to-modem {
+ qcom,entry-name = "ipa";
+ #qcom,smem-state-cells = <1>;
+ };
+
+ ipa_smp2p_in: ipa-modem-to-ap {
+ qcom,entry-name = "ipa";
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ };
+ };
+
+ smp2p-wpss {
+ compatible = "qcom,smp2p";
+ qcom,smem = <617>, <616>;
+ interrupts-extended = < IPCC_CLIENT_WPSS
+IPCC_MPROC_SIGNAL_SMP2P
+IRQ_TYPE_EDGE_RISING>;
+ mboxes = < IPCC_CLIENT_WPSS
+
[PATCH 2/6] dt-bindings: mailbox: Add WPSS client index to IPCC
Add WPSS remote processor client index to Inter-Processor Communication Controller (IPCC) block. Signed-off-by: Sibi Sankar --- include/dt-bindings/mailbox/qcom-ipcc.h | 1 + 1 file changed, 1 insertion(+) diff --git a/include/dt-bindings/mailbox/qcom-ipcc.h b/include/dt-bindings/mailbox/qcom-ipcc.h index 4c23eefed5f3..eb91a6c05b71 100644 --- a/include/dt-bindings/mailbox/qcom-ipcc.h +++ b/include/dt-bindings/mailbox/qcom-ipcc.h @@ -29,5 +29,6 @@ #define IPCC_CLIENT_PCIE1 14 #define IPCC_CLIENT_PCIE2 15 #define IPCC_CLIENT_SPSS 16 +#define IPCC_CLIENT_WPSS 24 #endif -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project
[PATCH 1/6] soc: qcom: smem: Update max processor count
Update max processor count to reflect the number of co-processors on SC7280 SoCs. Signed-off-by: Sibi Sankar --- drivers/soc/qcom/smem.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/soc/qcom/smem.c b/drivers/soc/qcom/smem.c index cc4e0655a47b..4fb5aeeb0843 100644 --- a/drivers/soc/qcom/smem.c +++ b/drivers/soc/qcom/smem.c @@ -84,7 +84,7 @@ #define SMEM_GLOBAL_HOST 0xfffe /* Max number of processors/hosts in a system */ -#define SMEM_HOST_COUNT11 +#define SMEM_HOST_COUNT14 /** * struct smem_proc_comm - proc_comm communication struct (legacy) -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project
[PATCH 3/6] dt-bindings: reset: aoss: Add AOSS reset controller binding
Add AOSS reset controller bindings for SC7280 SoCs. Signed-off-by: Sibi Sankar --- Documentation/devicetree/bindings/reset/qcom,aoss-reset.yaml | 5 + 1 file changed, 5 insertions(+) diff --git a/Documentation/devicetree/bindings/reset/qcom,aoss-reset.yaml b/Documentation/devicetree/bindings/reset/qcom,aoss-reset.yaml index e2d85a1e1d63..a054757f4d9f 100644 --- a/Documentation/devicetree/bindings/reset/qcom,aoss-reset.yaml +++ b/Documentation/devicetree/bindings/reset/qcom,aoss-reset.yaml @@ -21,6 +21,11 @@ properties: - const: "qcom,sc7180-aoss-cc" - const: "qcom,sdm845-aoss-cc" + - description: on SC7280 SoCs the following compatibles must be specified +items: + - const: "qcom,sc7280-aoss-cc" + - const: "qcom,sdm845-aoss-cc" + - description: on SDM845 SoCs the following compatibles must be specified items: - const: "qcom,sdm845-aoss-cc" -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project
[PATCH 0/6] Enable miscellaneous hardware blocks to boot WPSS
This series enables miscellaneous hardware blocks to boot Wireless Processor Subsystem (WPSS) on SC7280 SoC. [1] https://lore.kernel.org/patchwork/cover/1389010/ The series depends on ^^ Sibi Sankar (6): soc: qcom: smem: Update max processor count dt-bindings: mailbox: Add WPSS client index to IPCC dt-bindings: reset: aoss: Add AOSS reset controller binding dt-bindings: reset: pdc: Add PDC Global bindings reset: qcom: Add PDC Global reset signals for WPSS arm64: dts: qcom: sc7280: Add nodes to boot WPSS .../devicetree/bindings/reset/qcom,aoss-reset.yaml | 5 + .../devicetree/bindings/reset/qcom,pdc-global.yaml | 4 + arch/arm64/boot/dts/qcom/sc7280.dtsi | 143 + drivers/reset/reset-qcom-pdc.c | 62 +++-- drivers/soc/qcom/smem.c| 2 +- include/dt-bindings/mailbox/qcom-ipcc.h| 1 + include/dt-bindings/reset/qcom,sdm845-pdc.h| 2 + 7 files changed, 207 insertions(+), 12 deletions(-) -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project
Re: [PATCH v2 0/3] add "delay" clock support to gpio_wdt
On 3/4/21 2:12 PM, Rasmus Villemoes wrote: > As Arnd and Guenther suggested, this adds support to the gpio_wdt > driver for being a consumer of the clock driving the ripple > counter. However, I don't think it should be merged as-is, see below. > > The first patch makes sense on its own, quick grepping suggests plenty > of places that could benefit from this, and I thought it would be odd > to have to re-introduce a .remove callback in the gpio_wdt driver. > This has zero chance to be accepted. As suggested in the patch, just use devm_add_action(), like many other watchdog drivers. > Unfortunately, this turns out to be a bit of an "operation succeeded, > patient (almost) died": We use CONFIG_GPIO_WATCHDOG_ARCH_INITCALL > because the watchdog has a rather short timeout (1.0-2.25s, 1.6s > typical according to data sheet). At first, I put the new code right > after the devm_gpiod_get(), but the problem is that this early, we get > -EPROBE_DEFER since the clock provider (the RTC which sits off i2c) > isn't probed yet. But then the board would reset because it takes way > too long for the rest of the machine to initialize. [The bootloader > makes sure to turn on the RTC's clock output so the watchdog is > actually functional, the task here is to figure out the proper way to > prevent clk_disable_unused() from disabling it.] > Is there a property indicating always-on for clocks, similar to regulator-always-on ? The idea seems to exist, but it looks like it is always explict (ie mentioned somewhere in the code that a clock is always on, or "safe"). It would help if the clock in question can be marked as always-on without explicit consumer. Thanks, Guenter > Moving the logic to after the first "is it always-running and if so > give it an initial ping" made the board survive, but unfortunately the > second, and succesful, probe happens a little more than a second > later, which happens to work on this particular board, but is > obviously not suitable for production given that it's already above > what the spec says, and other random changes in the future might make > the gap even wider. > > So I don't know. The hardware is obviously misdesigned, and I don't > know how far the mainline kernel should stretch to support this; OTOH > the kernel does contain lots of workarounds for quirks and hardware > bugs. > > > > > Rasmus Villemoes (3): > clk: add devm_clk_prepare_enable() helper > dt-bindings: watchdog: add optional "delay" clock to gpio-wdt binding > watchdog: gpio_wdt: implement support for optional "delay" clock > > .../devicetree/bindings/watchdog/gpio-wdt.txt | 6 > .../driver-api/driver-model/devres.rst| 1 + > drivers/clk/clk-devres.c | 29 +++ > drivers/watchdog/gpio_wdt.c | 9 ++ > include/linux/clk.h | 13 + > 5 files changed, 58 insertions(+) >
Re: [PATCH V2 2/4] vDPA/ifcvf: enable Intel C5000X-PL virtio-net for vDPA
On 3/9/2021 10:42 AM, Jason Wang wrote:
On 2021/3/9 10:28 上午, Zhu, Lingshan wrote:
On 3/9/2021 10:23 AM, Jason Wang wrote:
On 2021/3/8 4:35 下午, Zhu Lingshan wrote:
This commit enabled Intel FPGA SmartNIC C5000X-PL virtio-net
for vDPA
Signed-off-by: Zhu Lingshan
---
drivers/vdpa/ifcvf/ifcvf_base.h | 5 +
drivers/vdpa/ifcvf/ifcvf_main.c | 5 +
2 files changed, 10 insertions(+)
diff --git a/drivers/vdpa/ifcvf/ifcvf_base.h
b/drivers/vdpa/ifcvf/ifcvf_base.h
index 64696d63fe07..75d9a8052039 100644
--- a/drivers/vdpa/ifcvf/ifcvf_base.h
+++ b/drivers/vdpa/ifcvf/ifcvf_base.h
@@ -23,6 +23,11 @@
#define IFCVF_SUBSYS_VENDOR_ID 0x8086
#define IFCVF_SUBSYS_DEVICE_ID 0x001A
+#define C5000X_PL_VENDOR_ID 0x1AF4
+#define C5000X_PL_DEVICE_ID 0x1000
+#define C5000X_PL_SUBSYS_VENDOR_ID 0x8086
+#define C5000X_PL_SUBSYS_DEVICE_ID 0x0001
I just notice that the device is a transtitional one. Any reason for
doing this?
Note that IFCVF is a moden device anyhow (0x1041). Supporting legacy
drive may bring many issues (e.g the definition is non-nomartive).
One example is the support of VIRTIO_F_IOMMU_PLATFORM, legacy driver
may assume the device can bypass IOMMU.
Thanks
Hi Jason,
This device will support virtio1.0 by default, so has
VIRTIO_F_IOMMU_PLATFORM by default.
If you device want to force VIRTIO_F_IOMMU_PLATFORM you probably need
to do what has been done by mlx5 (verify_min_features).
According to the spec, if VIRTIO_F_IOMMU_PLATFORM is not mandatory,
when it's not negotiated, device needs to disable or bypass IOMMU:
"
If this feature bit is set to 0, then the device has same access to
memory addresses supplied to it as the driver has. In particular, the
device will always use physical addresses matching addresses used by
the driver (typically meaning physical addresses used by the CPU) and
not translated further, and can access any address supplied to it by
the driver.
"
sure, I can implement code to check the feature bits.
Transitional device gives the software a chance to fall back to
virtio 0.95.
This only applies if you want to passthrough the card to guest
directly without the help of vDPA.
If we go with vDPA, it doesn't hlep. For virtio-vdpa, we know it will
negotiated IOMMU_PLATFORM. For vhost-vdpa, Qemu can provide a legacy
or transitional device on top of a modern vDPA device.
Thanks
For some cases, users may run quite out of date OS does not have vDPA
nor virtio 1.0 support, transitional characters give them a chance to
use the devices.
Thanks
Zhu Lingshan
ifcvf drives this device in virtio 1.0 mode, set features
VIRTIO_F_IOMMU_PLATFORM successfully.
Thanks,
Zhu Lingshan
+
#define IFCVF_SUPPORTED_FEATURES \
((1ULL << VIRTIO_NET_F_MAC) | \
(1ULL << VIRTIO_F_ANY_LAYOUT) | \
diff --git a/drivers/vdpa/ifcvf/ifcvf_main.c
b/drivers/vdpa/ifcvf/ifcvf_main.c
index e501ee07de17..26a2dab7ca66 100644
--- a/drivers/vdpa/ifcvf/ifcvf_main.c
+++ b/drivers/vdpa/ifcvf/ifcvf_main.c
@@ -484,6 +484,11 @@ static struct pci_device_id ifcvf_pci_ids[] = {
IFCVF_DEVICE_ID,
IFCVF_SUBSYS_VENDOR_ID,
IFCVF_SUBSYS_DEVICE_ID) },
+ { PCI_DEVICE_SUB(C5000X_PL_VENDOR_ID,
+ C5000X_PL_DEVICE_ID,
+ C5000X_PL_SUBSYS_VENDOR_ID,
+ C5000X_PL_SUBSYS_DEVICE_ID) },
+
{ 0 },
};
MODULE_DEVICE_TABLE(pci, ifcvf_pci_ids);
Re: [PATCH] arch: x86: kernel: Adjust the words to suit sentences in the file vmlinux.lds.S
On 21:10 Mon 08 Mar 2021, Randy Dunlap wrote: On 3/8/21 7:41 PM, Bhaskar Chowdhury wrote: s/percpu/per CPU/ s/baremetal/bare metal/ Signed-off-by: Bhaskar Chowdhury Yeah, "bare metal" is a little better than "baremetal". OTOH, "percpu" is a kernel construct's name. It doesn't have to be proper English IMHO. (2 cents worth) My bad disregard...pls...will be careful ... --- arch/x86/kernel/vmlinux.lds.S | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/x86/kernel/vmlinux.lds.S b/arch/x86/kernel/vmlinux.lds.S index efd9e9ea17f2..592a44ad13b1 100644 --- a/arch/x86/kernel/vmlinux.lds.S +++ b/arch/x86/kernel/vmlinux.lds.S @@ -217,7 +217,7 @@ SECTIONS #if defined(CONFIG_X86_64) && defined(CONFIG_SMP) /* -* percpu offsets are zero-based on SMP. PERCPU_VADDR() changes the +* per CPU offsets are zero-based on SMP. PERCPU_VADDR() changes the * output PHDR, so the next output section - .init.text - should * start another segment - init. */ @@ -262,7 +262,7 @@ SECTIONS /* * start address and size of operations which during runtime * can be patched with virtualization friendly instructions or -* baremetal native ones. Think page table operations. +* bare metal native ones. Think page table operations. * Details in paravirt_types.h */ . = ALIGN(8); -- -- ~Randy signature.asc Description: PGP signature
RE: [PATCH] usb: cdns3: Coherent memory allocation optimization
Hi Peter,
> On 21-03-05 17:01:11, Sanket Parmar wrote:
> > Allocation of DMA coherent memory in atomic context using
> > dma_alloc_coherent() might fail on some platform. To fix it,
> > Replaced dma_alloc_coherent() with dma_pool API to allocate a
> > smaller chunk of DMA coherent memory for TRB rings.
> >
> > Also in cdns3_prepare_aligned_request_buf(), replaced
> > dma_alloc_coherent() with kmalloc and dma_map API to allocate
> > aligned request buffer of dynamic length.
> >
>
> You do two changes in one commit, would you please split this one as
> two patches?
>
> > Fixes: commit 7733f6c32e36 ("usb: cdns3: Add Cadence USB3 DRD Driver")
>
> "commit" is not needed
>
> > Reported by: Aswath Govindraju
>
> Reported-by:
>
I have split the change into two patches.
New patch series has been posted already.
> > Signed-off-by: Sanket Parmar
> > ---
> > drivers/usb/cdns3/cdns3-gadget.c | 115 ++
> ---
> > drivers/usb/cdns3/cdns3-gadget.h |3 +
> > 2 files changed, 71 insertions(+), 47 deletions(-)
> >
> > diff --git a/drivers/usb/cdns3/cdns3-gadget.c b/drivers/usb/cdns3/cdns3-
> gadget.c
> > index 582bfec..5fd6993 100644
> > --- a/drivers/usb/cdns3/cdns3-gadget.c
> > +++ b/drivers/usb/cdns3/cdns3-gadget.c
> > @@ -59,6 +59,7 @@
> > #include
> > #include
> > #include
> > +#include
> > #include
> >
> > #include "core.h"
> > @@ -190,29 +191,13 @@ dma_addr_t cdns3_trb_virt_to_dma(struct
> cdns3_endpoint *priv_ep,
> > return priv_ep->trb_pool_dma + offset;
> > }
> >
> > -static int cdns3_ring_size(struct cdns3_endpoint *priv_ep)
> > -{
> > - switch (priv_ep->type) {
> > - case USB_ENDPOINT_XFER_ISOC:
> > - return TRB_ISO_RING_SIZE;
> > - case USB_ENDPOINT_XFER_CONTROL:
> > - return TRB_CTRL_RING_SIZE;
> > - default:
> > - if (priv_ep->use_streams)
> > - return TRB_STREAM_RING_SIZE;
> > - else
> > - return TRB_RING_SIZE;
> > - }
> > -}
> > -
> > static void cdns3_free_trb_pool(struct cdns3_endpoint *priv_ep)
> > {
> > struct cdns3_device *priv_dev = priv_ep->cdns3_dev;
> >
> > if (priv_ep->trb_pool) {
> > - dma_free_coherent(priv_dev->sysdev,
> > - cdns3_ring_size(priv_ep),
> > - priv_ep->trb_pool, priv_ep->trb_pool_dma);
> > + dma_pool_free(priv_dev->eps_dma_pool,
> > + priv_ep->trb_pool, priv_ep->trb_pool_dma);
> > priv_ep->trb_pool = NULL;
> > }
> > }
> > @@ -226,7 +211,7 @@ static void cdns3_free_trb_pool(struct
> cdns3_endpoint *priv_ep)
> > int cdns3_allocate_trb_pool(struct cdns3_endpoint *priv_ep)
> > {
> > struct cdns3_device *priv_dev = priv_ep->cdns3_dev;
> > - int ring_size = cdns3_ring_size(priv_ep);
> > + int ring_size = TRB_RING_SIZE;
>
> You will use the same size for TRB ring region for control/bulk/isoc
> endpoint.
>
As single DMA pool is used to allocate the ring buffer, different TRB ring
size is not possible for different EP. Hence, TRB_RING_SIZE(600 * 12 B) which
fits
for all type of EPs is used.
> > int num_trbs = ring_size / TRB_SIZE;
> > struct cdns3_trb *link_trb;
> >
> > @@ -234,10 +219,10 @@ int cdns3_allocate_trb_pool(struct
> cdns3_endpoint *priv_ep)
> > cdns3_free_trb_pool(priv_ep);
> >
> > if (!priv_ep->trb_pool) {
> > - priv_ep->trb_pool = dma_alloc_coherent(priv_dev->sysdev,
> > - ring_size,
> > - _ep->trb_pool_dma,
> > - GFP_DMA32 |
> GFP_ATOMIC);
> > + priv_ep->trb_pool = dma_pool_alloc(priv_dev-
> >eps_dma_pool,
> > + GFP_DMA32 | GFP_ATOMIC,
> > + _ep->trb_pool_dma);
>
> dma_pool_alloc also allocates the whole thunk of TRB region. See the
> kernel-doc for dma_pool_create.
>
> * Given one of these pools, dma_pool_alloc()
> * may be used to allocate memory. Such memory will all have "consistent"
Yes, dma_pool_alloc allocates the whole chunk of TRB region for enabled EPs
from the
pool. Currently the block size of the DMA pool is 7.2KB. So dma_pool_alloc
allocates at least
7.2KB for TRB region per enabled EP.
> > +
> > if (!priv_ep->trb_pool)
> > return -ENOMEM;
> >
> > @@ -833,10 +818,26 @@ void cdns3_gadget_giveback(struct
> cdns3_endpoint *priv_ep,
> > usb_gadget_unmap_request_by_dev(priv_dev->sysdev, request,
> > priv_ep->dir);
> >
> > - if ((priv_req->flags & REQUEST_UNALIGNED) &&
> > - priv_ep->dir == USB_DIR_OUT && !request->status)
> > - memcpy(request->buf, priv_req->aligned_buf->buf,
> > - request->length);
> > + if ((priv_req->flags & REQUEST_UNALIGNED) && priv_req-
> >aligned_buf) {
> > +
Re: [PATCH] Squashfs: fix xattr id and id lookup sanity checks
On Mon, 1 Mar 2021 07:27:57 + (GMT) Phillip Lougher wrote: > The checks for maximum metadata block size is > missing SQUASHFS_BLOCK_OFFSET (the two byte length > count). There is no definition of SQUASHFS_BLOCK_OFFSET. Makes compiler unhappy.
[PATCH v2 3/4] arm64: dts: imx8mp: add flexspi node
add node for the flexspi modul on imx8mp.
Signed-off-by: Heiko Schocher
---
Changes in v2:
- work in comments from Marco
- add own compatible entry "nxp,imx8mp-fspi"
- reworked order of properties as Marco mentioned
arch/arm64/boot/dts/freescale/imx8mp.dtsi | 16
1 file changed, 16 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/imx8mp.dtsi
b/arch/arm64/boot/dts/freescale/imx8mp.dtsi
index c7523fd4eae9b..18023d97235ed 100644
--- a/arch/arm64/boot/dts/freescale/imx8mp.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mp.dtsi
@@ -36,6 +36,7 @@ aliases {
serial1 =
serial2 =
serial3 =
+ spi0 =
};
cpus {
@@ -744,6 +745,21 @@ usdhc3: mmc@30b6 {
status = "disabled";
};
+ flexspi: spi@30bb {
+ compatible = "nxp,imx8mp-fspi";
+ reg = <0x30bb 0x1>, <0x800
0x1000>;
+ reg-names = "fspi_base", "fspi_mmap";
+ interrupts = ;
+ clocks = < IMX8MP_CLK_QSPI_ROOT>,
+< IMX8MP_CLK_QSPI_ROOT>;
+ clock-names = "fspi", "fspi_en";
+ assigned-clock-rates = <8000>;
+ assigned-clocks = < IMX8MP_CLK_QSPI>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
+
sdma1: dma-controller@30bd {
compatible = "fsl,imx8mp-sdma",
"fsl,imx8mq-sdma";
reg = <0x30bd 0x1>;
--
2.29.2
[PATCH v2 4/4] arm64: imx8mp: imx8mp-phycore-som enable spi nor
enable the mt25qu256aba spi nor on the imx8mp-phycore-som.
Signed-off-by: Heiko Schocher
---
Changes in v2:
- work in comments from Marco and Teresa
- rename node into "'som_flash: flash@0 { }"
- compatible is now first entry
- removed #size-cells and #address-cells
as no child node. If bootloader adds them bootloader
can add them too.
.../dts/freescale/imx8mp-phycore-som.dtsi | 25 +++
1 file changed, 25 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/imx8mp-phycore-som.dtsi
b/arch/arm64/boot/dts/freescale/imx8mp-phycore-som.dtsi
index 44a8c2337cee4..e648b1b6acdaa 100644
--- a/arch/arm64/boot/dts/freescale/imx8mp-phycore-som.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mp-phycore-som.dtsi
@@ -65,6 +65,20 @@ ethphy1: ethernet-phy@0 {
};
};
+ {
+ pinctrl-names = "default";
+ pinctrl-0 = <_flexspi0>;
+ status = "okay";
+
+ som_flash: flash@0 {
+ compatible = "jedec,spi-nor";
+ reg = <0>;
+ spi-max-frequency = <8000>;
+ spi-tx-bus-width = <4>;
+ spi-rx-bus-width = <4>;
+ };
+};
+
{
clock-frequency = <40>;
pinctrl-names = "default";
@@ -217,6 +231,17 @@ MX8MP_IOMUXC_GPIO1_IO15__GPIO1_IO150x11
>;
};
+ pinctrl_flexspi0: flexspi0grp {
+ fsl,pins = <
+ MX8MP_IOMUXC_NAND_ALE__FLEXSPI_A_SCLK 0x1c2
+ MX8MP_IOMUXC_NAND_CE0_B__FLEXSPI_A_SS0_B0x82
+ MX8MP_IOMUXC_NAND_DATA00__FLEXSPI_A_DATA00 0x82
+ MX8MP_IOMUXC_NAND_DATA01__FLEXSPI_A_DATA01 0x82
+ MX8MP_IOMUXC_NAND_DATA02__FLEXSPI_A_DATA02 0x82
+ MX8MP_IOMUXC_NAND_DATA03__FLEXSPI_A_DATA03 0x82
+ >;
+ };
+
pinctrl_i2c1: i2c1grp {
fsl,pins = <
MX8MP_IOMUXC_I2C1_SCL__I2C1_SCL 0x41c3
--
2.29.2
[PATCH v2 2/4] dt-bindings: spi: add compatible entry for imx8mp in FlexSPI controller
add compatible entry "nxp,imx8mp-fspi" in NXP FlexSPI controller Signed-off-by: Heiko Schocher --- (no changes since v1) Documentation/devicetree/bindings/spi/spi-nxp-fspi.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/spi/spi-nxp-fspi.txt b/Documentation/devicetree/bindings/spi/spi-nxp-fspi.txt index 7ac60d9fe3571..fd5f081f6d91b 100644 --- a/Documentation/devicetree/bindings/spi/spi-nxp-fspi.txt +++ b/Documentation/devicetree/bindings/spi/spi-nxp-fspi.txt @@ -4,6 +4,7 @@ Required properties: - compatible : Should be "nxp,lx2160a-fspi" "nxp,imx8qxp-fspi" "nxp,imx8mm-fspi" + "nxp,imx8mp-fspi" - reg :First contains the register location and length, Second contains the memory mapping address and length -- 2.29.2
[PATCH v2 0/4] enable flexspi support on imx8mp
This series enables support for the SPI NOR on the
imx8mp based phyboard-pollux-rdk board.
Patches new in v2:
"spi: fspi: enable fspi driver for on imx8mp"
which adds own compatible entry for imx8mp
and seperate in own patch the documentation entry in
patch "dt-bindings: spi: add compatible entry for imx8mp in FlexSPI controller"
as checkpatch says:
warning: DT binding docs and includes should be a separate patch. See:
Documentation/devicetree/bindings/submitting-patches.rst
Changes in v2:
- work in comments from Marco
add own compatible entry for imx8mp
- work in comments from Marco
- add own compatible entry "nxp,imx8mp-fspi"
- reworked order of properties as Marco mentioned
- work in comments from Marco and Teresa
- rename node into "'som_flash: flash@0 { }"
- compatible is now first entry
- removed #size-cells and #address-cells
as no child node. If bootloader adds them bootloader
can add them too.
Heiko Schocher (4):
spi: fspi: enable fspi driver for on imx8mp
dt-bindings: spi: add compatible entry for imx8mp in FlexSPI
controller
arm64: dts: imx8mp: add flexspi node
arm64: imx8mp: imx8mp-phycore-som enable spi nor
.../devicetree/bindings/spi/spi-nxp-fspi.txt | 1 +
.../dts/freescale/imx8mp-phycore-som.dtsi | 25 +++
arch/arm64/boot/dts/freescale/imx8mp.dtsi | 16
drivers/spi/spi-nxp-fspi.c| 1 +
4 files changed, 43 insertions(+)
--
2.29.2
[PATCH v2 1/4] spi: fspi: enable fspi driver for on imx8mp
add compatible entry in nxp_fspi driver for imx8mp.
Signed-off-by: Heiko Schocher
---
Changes in v2:
- work in comments from Marco
add own compatible entry for imx8mp
drivers/spi/spi-nxp-fspi.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/spi/spi-nxp-fspi.c b/drivers/spi/spi-nxp-fspi.c
index ab9035662717a..19ce4a854cc97 100644
--- a/drivers/spi/spi-nxp-fspi.c
+++ b/drivers/spi/spi-nxp-fspi.c
@@ -1151,6 +1151,7 @@ static int nxp_fspi_resume(struct device *dev)
static const struct of_device_id nxp_fspi_dt_ids[] = {
{ .compatible = "nxp,lx2160a-fspi", .data = (void *)_data, },
{ .compatible = "nxp,imx8mm-fspi", .data = (void *)_data, },
+ { .compatible = "nxp,imx8mp-fspi", .data = (void *)_data, },
{ .compatible = "nxp,imx8qxp-fspi", .data = (void *)_data, },
{ /* sentinel */ }
};
--
2.29.2
Re: [PATCH v2] KVM: x86: Revise guest_fpu xcomp_bv field
On 3/2/2021 7:59 AM, Sean Christopherson wrote:
On Thu, Feb 25, 2021, Jing Liu wrote:
XCOMP_BV[63] field indicates that the save area is in the compacted
format and XCOMP_BV[62:0] indicates the states that have space allocated
in the save area, including both XCR0 and XSS bits enabled by the host
kernel. Use xfeatures_mask_all for calculating xcomp_bv and reuse
XCOMP_BV_COMPACTED_FORMAT defined by kernel.
Signed-off-by: Jing Liu
---
arch/x86/kvm/x86.c | 8 ++--
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 1b404e4d7dd8..f115493f577d 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -4435,8 +4435,6 @@ static int kvm_vcpu_ioctl_x86_set_debugregs(struct
kvm_vcpu *vcpu,
return 0;
}
-#define XSTATE_COMPACTION_ENABLED (1ULL << 63)
-
static void fill_xsave(u8 *dest, struct kvm_vcpu *vcpu)
{
struct xregs_state *xsave = >arch.guest_fpu->state.xsave;
@@ -4494,7 +4492,8 @@ static void load_xsave(struct kvm_vcpu *vcpu, u8 *src)
/* Set XSTATE_BV and possibly XCOMP_BV. */
xsave->header.xfeatures = xstate_bv;
if (boot_cpu_has(X86_FEATURE_XSAVES))
- xsave->header.xcomp_bv = host_xcr0 | XSTATE_COMPACTION_ENABLED;
+ xsave->header.xcomp_bv = XCOMP_BV_COMPACTED_FORMAT |
+xfeatures_mask_all;
Doesn't fill_xsave also need to be updated? Not with xfeatures_mask_all, but
to account for arch.ia32_xss? I believe it's a nop with the current code, since
supported_xss is zero, but it should be fixed, no?
Yes. For the arch.ia32_xss, I noticed CET
(https://lkml.org/lkml/2020/7/15/1412)
has posted related change so I didn't touch xstate_bv for fill_xsave for
now.
Finally, fill_xsave() need e.g. arch.guest_supported_xss for xstate_bv,
for xcomp_bv, xfeatures_mask_all is ok.
/*
* Copy each region from the non-compacted offset to the
@@ -9912,9 +9911,6 @@ static void fx_init(struct kvm_vcpu *vcpu)
return;
fpstate_init(>arch.guest_fpu->state);
- if (boot_cpu_has(X86_FEATURE_XSAVES))
- vcpu->arch.guest_fpu->state.xsave.header.xcomp_bv =
- host_xcr0 | XSTATE_COMPACTION_ENABLED;
Ugh, this _really_ needs a comment in the changelog. It took me a while to
realize fpstate_init() does exactly what the new fill_xave() is doing.
How about introducing that "fx_init()->fpstate_init() initializes xcomp_bv
of guest_fpu so no need to set again in later fill_xsave() and
load_xsave()"
in commit message?
And isn't the code in load_xsave() redundant and can be removed?
Oh, yes. Keep fx_init() initializing xcomp_bv for guest_fpu is enough.
Let me remove it in load_xsave later.
And for fill_xsave(), I think no need to set xcomp_bv there.
Any code that
uses get_xsave_addr() would be have a dependency on load_xsave() if it's not
redundant, and I can't see how that would work.
Sorry I didn't quite understand why get_xsave_addr() has dependency on
load_xsave(), do you mean the xstate_bv instead of xcomp_bv, that
load_xsave()
uses it to get the addr?
Thanks,
Jing
/*
* Ensure guest xcr0 is valid for loading
--
2.18.4
Re: [PATCH v2 1/3] clk: add devm_clk_prepare_enable() helper
On 3/4/21 2:12 PM, Rasmus Villemoes wrote: > Add a managed wrapper for clk_prepare_enable(). > > Signed-off-by: Rasmus Villemoes That has been tried several times, including by yours truly, and has always been rejected. Just use devm_add_action_or_reset() like many other watchdog drivers. Guenter
Re: linux-next: Signed-off-by missing for commit in the rcu tree
On Mon, Mar 08, 2021 at 05:03:27PM +1100, Stephen Rothwell wrote:
> Hi all,
>
> Commit
>
> 3e90d423e754 ("EXP net: phy: make mdio_bus_phy_suspend/resume as
> __maybe_unused")
>
> is missing a Signed-off-by from its committer.
Fixed, thank you and apologies!
Thanx, Paul
