Re: [PATCH v6 1/4] mfd: rt4831: Adds support for Richtek RT4831
Hi, Linux mfd reviewers:
It's been three weeks not to get any response from you.
Is there something wrong about this mfd patch?
If yes, please feel free to let me know.
cy_huang 於 2021年3月28日 週日 下午11:24寫道：
>
> From: ChiYuan Huang
>
> This adds support Richtek RT4831 core. It includes four channel WLED driver
> and Display Bias Voltage outputs.
>
> Signed-off-by: ChiYuan Huang
> ---
> The RT4831 regulator patches are already on main stream, and can be referred
> to
> 9351ab8b0cb6 regulator: rt4831: Adds support for Richtek RT4831 DSV regulator
> 934b05e81862 regulator: rt4831: Adds DT binding document for Richtek RT4831
> DSV regulator
>
> since v6
> - Respin the date from 2020 to 2021.
> - Rmove the shutdown routine.
> - Change the macro OF_MFD_CELL to MFD_CELL_OF.
>
>
> since v5
> - Rename file name from rt4831-core.c to rt4831.c
> - Change RICHTEK_VID to RICHTEK_VENDOR_ID.
> - Change gpio_desc nameing from 'enable' to 'enable_gpio' in probe.
> - Change variable 'val' to the meaningful name 'chip_id'.
> - Refine the error log when vendor id is not matched.
> - Remove of_match_ptr.
>
> since v2
> - Refine Kconfig descriptions.
> - Add copyright.
> - Refine error logs in probe.
> - Refine comment lines in remove and shutdown.
> ---
> drivers/mfd/Kconfig | 10 +
> drivers/mfd/Makefile | 1 +
> drivers/mfd/rt4831.c | 115
> +++
> 3 files changed, 126 insertions(+)
> create mode 100644 drivers/mfd/rt4831.c
>
> diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
> index b74efa4..3f43834 100644
> --- a/drivers/mfd/Kconfig
> +++ b/drivers/mfd/Kconfig
> @@ -1065,6 +1065,16 @@ config MFD_RDC321X
> southbridge which provides access to GPIOs and Watchdog using the
> southbridge PCI device configuration space.
>
> +config MFD_RT4831
> + tristate "Richtek RT4831 four channel WLED and Display Bias Voltage"
> + depends on I2C
> + select MFD_CORE
> + select REGMAP_I2C
> + help
> + This enables support for the Richtek RT4831 that includes 4 channel
> + WLED driving and Display Bias Voltage. It's commonly used to provide
> + power to the LCD display and LCD backlight.
> +
> config MFD_RT5033
> tristate "Richtek RT5033 Power Management IC"
> depends on I2C
> diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
> index 834f546..5986914 100644
> --- a/drivers/mfd/Makefile
> +++ b/drivers/mfd/Makefile
> @@ -235,6 +235,7 @@ obj-$(CONFIG_MFD_MENF21BMC) += menf21bmc.o
> obj-$(CONFIG_MFD_HI6421_PMIC) += hi6421-pmic-core.o
> obj-$(CONFIG_MFD_HI655X_PMIC) += hi655x-pmic.o
> obj-$(CONFIG_MFD_DLN2) += dln2.o
> +obj-$(CONFIG_MFD_RT4831) += rt4831.o
> obj-$(CONFIG_MFD_RT5033) += rt5033.o
> obj-$(CONFIG_MFD_SKY81452) += sky81452.o
>
> diff --git a/drivers/mfd/rt4831.c b/drivers/mfd/rt4831.c
> new file mode 100644
> index ..b169781
> --- /dev/null
> +++ b/drivers/mfd/rt4831.c
> @@ -0,0 +1,115 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Copyright (c) 2021 Richtek Technology Corp.
> + *
> + * Author: ChiYuan Huang
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#define RT4831_REG_REVISION0x01
> +#define RT4831_REG_ENABLE 0x08
> +#define RT4831_REG_I2CPROT 0x15
> +
> +#define RICHTEK_VENDOR_ID 0x03
> +#define RT4831_VID_MASKGENMASK(1, 0)
> +#define RT4831_RESET_MASK BIT(7)
> +#define RT4831_I2CSAFETMR_MASK BIT(0)
> +
> +static const struct mfd_cell rt4831_subdevs[] = {
> + MFD_CELL_OF("rt4831-backlight", NULL, NULL, 0, 0,
> "richtek,rt4831-backlight"),
> + MFD_CELL_NAME("rt4831-regulator")
> +};
> +
> +static bool rt4831_is_accessible_reg(struct device *dev, unsigned int reg)
> +{
> + if (reg >= RT4831_REG_REVISION && reg <= RT4831_REG_I2CPROT)
> + return true;
> + return false;
> +}
> +
> +static const struct regmap_config rt4831_regmap_config = {
> + .reg_bits = 8,
> + .val_bits = 8,
> + .max_register = RT4831_REG_I2CPROT,
> +
> + .readable_reg = rt4831_is_accessible_reg,
> + .writeable_reg = rt4831_is_accessible_reg,
> +};
> +
> +static int rt4831_probe(struct i2c_client *client)
> +{
> + struct gpio_desc *enable_gpio;
> + struct regmap *regmap;
> + unsigned int chip_id;
> + int ret;
> +
> + enable_gpio = devm_gpiod_get_optional(>dev, "enable",
> GPIOD_OUT_HIGH);
> + if (IS_ERR(enable_gpio)) {
> + dev_err(>dev, "Failed to get 'enable' GPIO\n");
> + return PTR_ERR(enable_gpio);
> + }
> +
> + regmap = devm_regmap_init_i2c(client, _regmap_config);
> + if (IS_ERR(regmap)) {
> + dev_err(>dev, "Failed to initialize regmap\n");
> + return PTR_ERR(regmap);
> + }
> +
> + ret = regmap_read(regmap, RT4831_REG_REVISION, _id);
> + if (ret) {
> +
[PATCH v2] MIPS: Makefile: Replace -pg with CC_FLAGS_FTRACE
In preparation for mips supporting ftrace built on other compiler options, let's have the mips Makefiles remove the $(CC_FLAGS_FTRACE) flags, whatever these may be, rather than assuming '-pg'. Signed-off-by: zhaoxiao --- v2:add this same change be appropriate to all of the below Makefile. arch/mips/boot/compressed/Makefile | 2 +- arch/mips/kernel/Makefile | 8 arch/mips/vdso/Makefile| 4 ++-- 3 files changed, 7 insertions(+), 7 deletions(-) diff --git a/arch/mips/boot/compressed/Makefile b/arch/mips/boot/compressed/Makefile index f93f72bcba97..e4b7839293e1 100644 --- a/arch/mips/boot/compressed/Makefile +++ b/arch/mips/boot/compressed/Makefile @@ -18,7 +18,7 @@ include $(srctree)/arch/mips/Kbuild.platforms BOOT_HEAP_SIZE := 0x40 # Disable Function Tracer -KBUILD_CFLAGS := $(filter-out -pg, $(KBUILD_CFLAGS)) +KBUILD_CFLAGS := $(filter-out $(CC_FLAGS_FTRACE), $(KBUILD_CFLAGS)) KBUILD_CFLAGS := $(filter-out -fstack-protector, $(KBUILD_CFLAGS)) diff --git a/arch/mips/kernel/Makefile b/arch/mips/kernel/Makefile index b4a57f1de772..814b3da30501 100644 --- a/arch/mips/kernel/Makefile +++ b/arch/mips/kernel/Makefile @@ -17,10 +17,10 @@ obj-y += cpu-probe.o endif ifdef CONFIG_FUNCTION_TRACER -CFLAGS_REMOVE_ftrace.o = -pg -CFLAGS_REMOVE_early_printk.o = -pg -CFLAGS_REMOVE_perf_event.o = -pg -CFLAGS_REMOVE_perf_event_mipsxx.o = -pg +CFLAGS_REMOVE_ftrace.o = $(CC_FLAGS_FTRACE) +CFLAGS_REMOVE_early_printk.o = $(CC_FLAGS_FTRACE) +CFLAGS_REMOVE_perf_event.o = $(CC_FLAGS_FTRACE) +CFLAGS_REMOVE_perf_event_mipsxx.o = $(CC_FLAGS_FTRACE) endif obj-$(CONFIG_CEVT_BCM1480) += cevt-bcm1480.o diff --git a/arch/mips/vdso/Makefile b/arch/mips/vdso/Makefile index 2131d3fd7333..1b2ea34c3d3b 100644 --- a/arch/mips/vdso/Makefile +++ b/arch/mips/vdso/Makefile @@ -46,7 +46,7 @@ CFLAGS_vgettimeofday-o32.o = -include $(srctree)/$(src)/config-n32-o32-env.c -in CFLAGS_vgettimeofday-n32.o = -include $(srctree)/$(src)/config-n32-o32-env.c -include $(c-gettimeofday-y) endif -CFLAGS_REMOVE_vgettimeofday.o = -pg +CFLAGS_REMOVE_vgettimeofday.o = $(CC_FLAGS_FTRACE) ifdef CONFIG_MIPS_DISABLE_VDSO ifndef CONFIG_MIPS_LD_CAN_LINK_VDSO @@ -60,7 +60,7 @@ ldflags-y := -Bsymbolic --no-undefined -soname=linux-vdso.so.1 \ $(filter -E%,$(KBUILD_CFLAGS)) -nostdlib -shared \ -G 0 --eh-frame-hdr --hash-style=sysv --build-id=sha1 -T -CFLAGS_REMOVE_vdso.o = -pg +CFLAGS_REMOVE_vdso.o = $(CC_FLAGS_FTRACE) GCOV_PROFILE := n UBSAN_SANITIZE := n -- 2.20.1
I need your assistance,
I need your assistance, Reply for more details. davidbrown1...@juno.com or Call: + 1 918 397 9602
Re: [PATCH] ecryptfs: fix kernel panic with null dev_name
On 2021-02-26 15:00:23, Jeffrey Mitchell wrote:
> When mounting eCryptfs, a null "dev_name" argument to ecryptfs_mount()
> causes a kernel panic if the parsed options are valid. The easiest way to
> reproduce this is to call mount() from userspace with an existing
> eCryptfs mount's options and a "source" argument of 0.
>
> Error out if "dev_name" is null in ecryptfs_mount()
>
> Signed-off-by: Jeffrey Mitchell
Thanks for the fix! I reproduced this on a 4.15 and, while I didn't try
anything older than that, I think it affects the first kernel release
with eCryptfs. I've added the following Fixes tag:
Fixes: 237fead61998 ("[PATCH] ecryptfs: fs/Makefile and fs/Kconfig")
I've pushed it to the next branch of tyhicks/ecryptfs.git.
Tyler
> ---
> fs/ecryptfs/main.c | 6 ++
> 1 file changed, 6 insertions(+)
>
> diff --git a/fs/ecryptfs/main.c b/fs/ecryptfs/main.c
> index e63259fdef28..b2f6a1937d23 100644
> --- a/fs/ecryptfs/main.c
> +++ b/fs/ecryptfs/main.c
> @@ -492,6 +492,12 @@ static struct dentry *ecryptfs_mount(struct
> file_system_type *fs_type, int flags
> goto out;
> }
>
> + if (!dev_name) {
> + rc = -EINVAL;
> + err = "Device name cannot be null";
> + goto out;
> + }
> +
> rc = ecryptfs_parse_options(sbi, raw_data, _ruid);
> if (rc) {
> err = "Error parsing options";
> --
> 2.25.1
>
RE: [EXTERNAL] Re: [PATCH 4.19 013/247] cifs: Set CIFS_MOUNT_USE_PREFIX_PATH flag on setting cifs_sb->prepath.
Hi Salvatore,
Attached is a proposed fix from Paulo for older kernels.
Can you please confirm that this works for you too?
Regards,
Shyam
-Original Message-
From: Salvatore Bonaccorso On Behalf Of
Salvatore Bonaccorso
Sent: Sunday, April 18, 2021 6:11 PM
To: Greg Kroah-Hartman
Cc: Shyam Prasad ; linux-kernel@vger.kernel.org;
sta...@vger.kernel.org; Aurelien Aptel ; Steven French
; Sasha Levin
Subject: Re: [EXTERNAL] Re: [PATCH 4.19 013/247] cifs: Set
CIFS_MOUNT_USE_PREFIX_PATH flag on setting cifs_sb->prepath.
Hi Greg,
On Mon, Apr 12, 2021 at 10:01:33AM +0200, Greg Kroah-Hartman wrote:
> On Thu, Apr 08, 2021 at 01:41:05PM +0200, Salvatore Bonaccorso wrote:
> > Hi Shyam,
> >
> > On Tue, Apr 06, 2021 at 05:01:17PM +0200, Salvatore Bonaccorso wrote:
> > > Hi,
> > >
> > > On Tue, Apr 06, 2021 at 02:00:48PM +, Shyam Prasad wrote:
> > > > Hi Greg,
> > > > We'll need to debug this further to understand what's going on.
> > >
> > > Greg asked it the same happens with 5.4 as well, I do not know I
> > > was not able to test 5.4.y (yet) but only 5.10.y and 4.19.y.
> > > >
> > > > Hi Salvatore,
> > > > Any chance that you'll be able to provide us the cifsFYI logs from the
> > > > time of mount failure?
> > > > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%
> > > > 2Fwiki.samba.org%2Findex.php%2FLinuxCIFS_troubleshooting%23Enabl
> > > > ing_Debuggingdata=04%7C01%7CShyam.Prasad%40microsoft.com%7C
> > > > 3f7f5a39dd974cacf6aa08d902674040%7C72f988bf86f141af91ab2d7cd011d
> > > > b47%7C1%7C0%7C637543465194151840%7CUnknown%7CTWFpbGZsb3d8eyJWIjo
> > > > iMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C10
> > > > 00sdata=nH2tcSzqFzzqLZ2RIARR008%2FuvBEdDHEnjKpVXhzIdk%3D
> > > > p;reserved=0
> > >
> > > Please find it attached. Is this enough information?
> > >
> > > The mentioned home DFS link 'home' is a DFS link to
> > > msdfs:SECONDHOST\REDACTED on a Samba host.
> > >
> > > The mount is triggered as
> > >
> > > mount -t cifs //HOSTIP/REDACTED/home /mnt --verbose -o
> > > username='REDACTED,domain=DOMAIN'
> >
> > So I can confirm the issue is both present in 4.19.185 and 5.4.110
> > upstream (without any Debian patches applied, we do not anyway apply
> > any cifs related one on top of the respetive upstream version).
> >
> > The issue is not present in 5.10.28.
> >
> > So I think there are commits as dependency of a738c93fb1c1 ("cifs:
> > Set CIFS_MOUNT_USE_PREFIX_PATH flag on setting cifs_sb->prepath.")
> > which are required and not applied in the released before 5.10.y
> > which make introducing the regression.
>
> Ok, I've dropped this from 5.4 and older kernel trees now, thanks for
> the report.
Thanks Greg! Shyam, Steven, now the commit was reverted for the older brnaches.
But did you got a chance to find why it breaks for the older series?
Regards,
Salvatore
0001-cifs-fix-prefix-path-in-dfs-mounts.patch
Description: 0001-cifs-fix-prefix-path-in-dfs-mounts.patch
Re: [PATCH 3/3] powerpc/mm/hash: Avoid multiple HPT resize-downs on memory hotunplug
On Fri, Apr 09, 2021 at 12:31:03AM -0300, Leonardo Bras wrote:
> Hello David, thanks for commenting.
>
> On Tue, 2021-03-23 at 10:45 +1100, David Gibson wrote:
> > > @@ -805,6 +808,10 @@ static int resize_hpt_for_hotplug(unsigned long
> > > new_mem_size, bool shrinking)
> > > if (shrinking) {
> > >
> > > + /* When batch removing entries, only resizes HPT at the end. */
> > > + if (atomic_read_acquire(_resize_disable))
> > > + return 0;
> > > +
> >
> > I'm not quite convinced by this locking. Couldn't hpt_resize_disable
> > be set after this point, but while you're still inside
> > resize_hpt_for_hotplug()? Probably better to use an explicit mutex
> > (and mutex_trylock()) to make the critical sections clearer.
>
> Sure, I can do that for v2.
>
> > Except... do we even need the fancy mechanics to suppress the resizes
> > in one place to do them elswhere. Couldn't we just replace the
> > existing resize calls with the batched ones?
>
> How do you think of having batched resizes-down in HPT?
I think it's a good idea. We still have to have the loop to resize
bigger if we can't fit everything into the smallest target size, but
that still only makes the worst case as bad at the always-case is
currently.
> Other than the current approach, I could only think of a way that would
> touch a lot of generic code, and/or duplicate some functions, as
> dlpar_add_lmb() does a lot of other stuff.
>
> > > +void hash_memory_batch_shrink_end(void)
> > > +{
> > > + unsigned long newsize;
> > > +
> > > + /* Re-enables HPT resize-down after hot-unplug */
> > > + atomic_set_release(_resize_disable, 0);
> > > +
> > > + newsize = memblock_phys_mem_size();
> > > + /* Resize to smallest SHIFT possible */
> > > + while (resize_hpt_for_hotplug(newsize, true) == -ENOSPC) {
> > > + newsize *= 2;
> >
> > As noted earlier, doing this without an explicit cap on the new hpt
> > size (of the existing size) this makes me nervous.
> >
>
> I can add a stop in v2.
>
> > Less so, but doing
> > the calculations on memory size, rather than explictly on HPT size /
> > HPT order also seems kinda clunky.
>
> Agree, but at this point, it would seem kind of a waste to find the
> shift from newsize, then calculate (1 << shift) for each retry of
> resize_hpt_for_hotplug() only to point that we are retrying the order
> value.
Yeah, I see your poiint.
>
> But sure, if you think it looks better, I can change that.
>
> > > +void memory_batch_shrink_begin(void)
> > > +{
> > > + if (!radix_enabled())
> > > + hash_memory_batch_shrink_begin();
> > > +}
> > > +
> > > +void memory_batch_shrink_end(void)
> > > +{
> > > + if (!radix_enabled())
> > > + hash_memory_batch_shrink_end();
> > > +}
> >
> > Again, these wrappers don't seem particularly useful to me.
>
> Options would be add 'if (!radix_enabled())' to hotplug-memory.c
> functions or to hash* functions, which look kind of wrong.
I think the if !radix_enabled in hotplug-memory.c isn't too bad, in
fact possibly helpful as a hint that this is HPT only logic.
>
> > > + memory_batch_shrink_end();
> >
> > remove_by_index only removes a single LMB, so there's no real point to
> > batching here.
>
> Sure, will be fixed for v2.
>
> > > @@ -700,6 +712,7 @@ static int dlpar_memory_add_by_count(u32 lmbs_to_add)
> > > if (lmbs_added != lmbs_to_add) {
> > > pr_err("Memory hot-add failed, removing any added LMBs\n");
> > >
> > > + memory_batch_shrink_begin();
> >
> >
> > The effect of these on the memory grow path is far from clear.
> >
>
> On hotplug, HPT is resized-up before adding LMBs.
> On hotunplug, HPT is resized-down after removing LMBs.
> And each one has it's own mechanism to batch HPT resizes...
>
> I can't understand exactly how using it on hotplug fail path can be any
> different than using it on hotunplug.
> >
>
> Can you please help me understanding this?
>
> Best regards,
> Leonardo Bras
>
--
David Gibson| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
signature.asc
Description: PGP signature
Re: [PATCH 2/3] powerpc/mm/hash: Avoid multiple HPT resize-ups on memory hotplug
On Thu, Apr 08, 2021 at 11:51:36PM -0300, Leonardo Bras wrote:
> Hello David, thanks for the feedback!
>
> On Mon, 2021-03-22 at 18:55 +1100, David Gibson wrote:
> > > +void hash_memory_batch_expand_prepare(unsigned long newsize)
> > > +{
> > > + /*
> > > + * Resizing-up HPT should never fail, but there are some cases system
> > > starts with higher
> > > + * SHIFT than required, and we go through the funny case of resizing
> > > HPT down while
> > > + * adding memory
> > > + */
> > > +
> > > + while (resize_hpt_for_hotplug(newsize, false) == -ENOSPC) {
> > > + newsize *= 2;
> > > + pr_warn("Hash collision while resizing HPT\n");
> >
> > This unbounded increase in newsize makes me nervous - we should be
> > bounded by the current size of the HPT at least. In practice we
> > should be fine, since the resize should always succeed by the time we
> > reach our current HPT size, but that's far from obvious from this
> > point in the code.
>
> Sure, I will add bounds in v2.
>
> >
> > And... you're doubling newsize which is a value which might not be a
> > power of 2. I'm wondering if there's an edge case where this could
> > actually cause us to skip the current size and erroneously resize to
> > one bigger than we have currently.
>
> I also though that at the start, but it seems quite reliable.
> Before using this value, htab_shift_for_mem_size() will always round it
> to next power of 2.
> Ex.
> Any value between 0b0101 and 0b1000 will be rounded to 0b1000 for shift
> calculation. If we multiply it by 2 (same as << 1), we have that
> anything between 0b01010 and 0b1 will be rounded to 0b1.
Ah, good point.
> This works just fine as long as we are multiplying.
> Division may have the behavior you expect, as 0b0101 >> 1 would become
> 0b010 and skip a shift.
>
> > > +void memory_batch_expand_prepare(unsigned long newsize)
> >
> > This wrapper doesn't seem useful.
>
> Yeah, it does little, but I can't just jump into hash_* functions
> directly from hotplug-memory.c, without even knowing if it's using hash
> pagetables. (in case the suggestion would be test for disable_radix
> inside hash_memory_batch*)
>
> >
> > > +{
> > > + if (!radix_enabled())
> > > + hash_memory_batch_expand_prepare(newsize);
> > > +}
> > > #endif /* CONFIG_MEMORY_HOTPLUG */
> > >
> > >
> > > + memory_batch_expand_prepare(memblock_phys_mem_size() +
> > > + drmem_info->n_lmbs * drmem_lmb_size());
> >
> > This doesn't look right. memory_add_by_index() is adding a *single*
> > LMB, I think using drmem_info->n_lmbs here means you're counting this
> > as adding again as much memory as you already have hotplugged.
>
> Yeah, my mistake. This makes sense.
> I will change it to something like
> memblock_phys_mem_size() + drmem_lmb_size()
>
> > >
> > > + memory_batch_expand_prepare(memblock_phys_mem_size() + lmbs_to_add *
> > > drmem_lmb_size());
> > > +
> > > for_each_drmem_lmb_in_range(lmb, start_lmb, end_lmb) {
> > > if (lmb->flags & DRCONF_MEM_ASSIGNED)
> > > continue;
> >
> > I don't see memory_batch_expand_prepare() suppressing any existing HPT
> > resizes. Won't this just resize to the right size for the full add,
> > then resize several times again as we perform the add? Or.. I guess
> > that will be suppressed by patch 1/3.
>
> Correct.
>
> > That's seems kinda fragile, though.
>
> What do you mean by fragile here?
> What would you suggest doing different?
>
> Best regards,
> Leonardo Bras
>
--
David Gibson| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
signature.asc
Description: PGP signature
I need your assistance,
I need your assistance, Reply for more details. davidbrown1...@juno.com or Call: + 1 918 397 9602
[PATCH 4/4] soundwire: bus: add missing \n in dynamic debug
From: Pierre-Louis Bossart
They were missed in previous contributions.
Signed-off-by: Pierre-Louis Bossart
Reviewed-by: Guennadi Liakhovetski
Reviewed-by: Rander Wang
Signed-off-by: Bard Liao
---
drivers/soundwire/bus.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/soundwire/bus.c b/drivers/soundwire/bus.c
index 100d904bf700..85bcf60f9697 100644
--- a/drivers/soundwire/bus.c
+++ b/drivers/soundwire/bus.c
@@ -886,7 +886,7 @@ static int sdw_bus_wait_for_clk_prep_deprep(struct sdw_bus
*bus, u16 dev_num)
}
val &= SDW_SCP_STAT_CLK_STP_NF;
if (!val) {
- dev_dbg(bus->dev, "clock stop prep/de-prep done
slave:%d",
+ dev_dbg(bus->dev, "clock stop prep/de-prep done
slave:%d\n",
dev_num);
return 0;
}
@@ -895,7 +895,7 @@ static int sdw_bus_wait_for_clk_prep_deprep(struct sdw_bus
*bus, u16 dev_num)
retry--;
} while (retry);
- dev_err(bus->dev, "clock stop prep/de-prep failed slave:%d",
+ dev_err(bus->dev, "clock stop prep/de-prep failed slave:%d\n",
dev_num);
return -ETIMEDOUT;
--
2.17.1
[PATCH 3/4] soundwire: bus: handle -ENODATA errors in clock stop/start sequences
From: Pierre-Louis Bossart
If a device lost sync and can no longer ACK a command, it may not be
able to enter a lower-power state but it will still be able to resync
when the clock restarts. In those cases, we want to continue with the
clock stop sequence.
This patch modifies the behavior during clock stop sequences to only
log errors unrelated to -ENODATA/Command_Ignored. The flow is also
modified so that loops continue to prepare/deprepare other devices
even when one seems to have lost sync.
When resuming the clocks, all issues are logged with a dev_warn(),
previously only some of them were checked. This is the only part that
now differs between the clock stop entry and clock stop exit
sequences: while we don't want to stop the suspend flow, we do want
information on potential issues while resuming, as they may have
ripple effects.
For consistency the log messages are also modified to be unique and
self-explanatory. Errors in sdw_slave_clk_stop_callback() were
removed, they are now handled in the caller.
Signed-off-by: Pierre-Louis Bossart
Reviewed-by: Guennadi Liakhovetski
Reviewed-by: Rander Wang
Signed-off-by: Bard Liao
---
drivers/soundwire/bus.c | 69 +
1 file changed, 36 insertions(+), 33 deletions(-)
diff --git a/drivers/soundwire/bus.c b/drivers/soundwire/bus.c
index dc4033b6f2e9..100d904bf700 100644
--- a/drivers/soundwire/bus.c
+++ b/drivers/soundwire/bus.c
@@ -829,11 +829,8 @@ static int sdw_slave_clk_stop_callback(struct sdw_slave
*slave,
if (slave->ops && slave->ops->clk_stop) {
ret = slave->ops->clk_stop(slave, mode, type);
- if (ret < 0) {
- dev_err(>dev,
- "Clk Stop type =%d failed: %d\n", type, ret);
+ if (ret < 0)
return ret;
- }
}
return 0;
@@ -860,7 +857,8 @@ static int sdw_slave_clk_stop_prepare(struct sdw_slave
*slave,
} else {
ret = sdw_read_no_pm(slave, SDW_SCP_SYSTEMCTRL);
if (ret < 0) {
- dev_err(>dev, "SDW_SCP_SYSTEMCTRL read
failed:%d\n", ret);
+ if (ret != -ENODATA)
+ dev_err(>dev, "SDW_SCP_SYSTEMCTRL read
failed:%d\n", ret);
return ret;
}
val = ret;
@@ -869,9 +867,8 @@ static int sdw_slave_clk_stop_prepare(struct sdw_slave
*slave,
ret = sdw_write_no_pm(slave, SDW_SCP_SYSTEMCTRL, val);
- if (ret < 0)
- dev_err(>dev,
- "Clock Stop prepare failed for slave: %d", ret);
+ if (ret < 0 && ret != -ENODATA)
+ dev_err(>dev, "SDW_SCP_SYSTEMCTRL write failed:%d\n",
ret);
return ret;
}
@@ -922,6 +919,9 @@ int sdw_bus_prep_clk_stop(struct sdw_bus *bus)
* In order to save on transition time, prepare
* each Slave and then wait for all Slave(s) to be
* prepared for clock stop.
+* If one of the Slave devices has lost sync and
+* replies with Command Ignored/-ENODATA, we continue
+* the loop
*/
list_for_each_entry(slave, >slaves, node) {
if (!slave->dev_num)
@@ -937,9 +937,8 @@ int sdw_bus_prep_clk_stop(struct sdw_bus *bus)
ret = sdw_slave_clk_stop_callback(slave,
SDW_CLK_STOP_MODE0,
SDW_CLK_PRE_PREPARE);
- if (ret < 0) {
- dev_err(>dev,
- "pre-prepare failed:%d", ret);
+ if (ret < 0 && ret != -ENODATA) {
+ dev_err(>dev, "clock stop pre-prepare cb
failed:%d\n", ret);
return ret;
}
@@ -950,9 +949,8 @@ int sdw_bus_prep_clk_stop(struct sdw_bus *bus)
ret = sdw_slave_clk_stop_prepare(slave,
SDW_CLK_STOP_MODE0,
true);
- if (ret < 0) {
- dev_err(>dev,
- "pre-prepare failed:%d", ret);
+ if (ret < 0 && ret != -ENODATA) {
+ dev_err(>dev, "clock stop prepare
failed:%d\n", ret);
return ret;
}
}
@@ -960,7 +958,7 @@ int sdw_bus_prep_clk_stop(struct sdw_bus *bus)
/* Skip remaining clock stop preparation if no Slave is attached */
if (!is_slave)
- return ret;
+ return 0;
/*
* Don't wait for all Slaves to be ready if they follow the simple
@@ -969,6 +967,12 @@ int sdw_bus_prep_clk_stop(struct sdw_bus *bus)
if (!simple_clk_stop) {
ret =
[PATCH 2/4] soundwire: add missing kernel-doc description
From: Pierre-Louis Bossart
For some reason we never added a description for the clk_stop
callback.
Signed-off-by: Pierre-Louis Bossart
Reviewed-by: Guennadi Liakhovetski
Reviewed-by: Rander Wang
Signed-off-by: Bard Liao
---
include/linux/soundwire/sdw.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/include/linux/soundwire/sdw.h b/include/linux/soundwire/sdw.h
index 5d93d9949653..8ca736e92d5a 100644
--- a/include/linux/soundwire/sdw.h
+++ b/include/linux/soundwire/sdw.h
@@ -612,6 +612,7 @@ struct sdw_bus_params {
* @update_status: Update Slave status
* @bus_config: Update the bus config for Slave
* @port_prep: Prepare the port with parameters
+ * @clk_stop: handle imp-def sequences before and after prepare and de-prepare
*/
struct sdw_slave_ops {
int (*read_prop)(struct sdw_slave *sdw);
--
2.17.1
[PATCH 1/4] soundwire: bus: only use CLOCK_STOP_MODE0 and fix confusions
From: Pierre-Louis Bossart
Existing devices and implementations only support the required
CLOCK_STOP_MODE0. All the code related to CLOCK_STOP_MODE1 has not
been tested and is highly questionable, with a clear confusion between
CLOCK_STOP_MODE1 and the simple clock stop state machine.
This patch removes all usages of CLOCK_STOP_MODE1 - which has no
impact on any solution - and fixes the use of the simple clock stop
state machine. The resulting code should be a lot more symmetrical and
easier to maintain.
Note that CLOCK_STOP_MODE1 is not supported in the SoundWire Device
Class specification so it's rather unlikely that we need to re-add
this mode later.
Signed-off-by: Pierre-Louis Bossart
Reviewed-by: Guennadi Liakhovetski
Reviewed-by: Rander Wang
Signed-off-by: Bard Liao
---
drivers/soundwire/bus.c | 100 ++
include/linux/soundwire/sdw.h | 2 -
2 files changed, 40 insertions(+), 62 deletions(-)
diff --git a/drivers/soundwire/bus.c b/drivers/soundwire/bus.c
index a9e0aa72654d..dc4033b6f2e9 100644
--- a/drivers/soundwire/bus.c
+++ b/drivers/soundwire/bus.c
@@ -821,26 +821,6 @@ static void sdw_modify_slave_status(struct sdw_slave
*slave,
mutex_unlock(>bus_lock);
}
-static enum sdw_clk_stop_mode sdw_get_clk_stop_mode(struct sdw_slave *slave)
-{
- enum sdw_clk_stop_mode mode;
-
- /*
-* Query for clock stop mode if Slave implements
-* ops->get_clk_stop_mode, else read from property.
-*/
- if (slave->ops && slave->ops->get_clk_stop_mode) {
- mode = slave->ops->get_clk_stop_mode(slave);
- } else {
- if (slave->prop.clk_stop_mode1)
- mode = SDW_CLK_STOP_MODE1;
- else
- mode = SDW_CLK_STOP_MODE0;
- }
-
- return mode;
-}
-
static int sdw_slave_clk_stop_callback(struct sdw_slave *slave,
enum sdw_clk_stop_mode mode,
enum sdw_clk_stop_type type)
@@ -933,7 +913,6 @@ static int sdw_bus_wait_for_clk_prep_deprep(struct sdw_bus
*bus, u16 dev_num)
*/
int sdw_bus_prep_clk_stop(struct sdw_bus *bus)
{
- enum sdw_clk_stop_mode slave_mode;
bool simple_clk_stop = true;
struct sdw_slave *slave;
bool is_slave = false;
@@ -955,10 +934,8 @@ int sdw_bus_prep_clk_stop(struct sdw_bus *bus)
/* Identify if Slave(s) are available on Bus */
is_slave = true;
- slave_mode = sdw_get_clk_stop_mode(slave);
- slave->curr_clk_stop_mode = slave_mode;
-
- ret = sdw_slave_clk_stop_callback(slave, slave_mode,
+ ret = sdw_slave_clk_stop_callback(slave,
+ SDW_CLK_STOP_MODE0,
SDW_CLK_PRE_PREPARE);
if (ret < 0) {
dev_err(>dev,
@@ -966,22 +943,29 @@ int sdw_bus_prep_clk_stop(struct sdw_bus *bus)
return ret;
}
- ret = sdw_slave_clk_stop_prepare(slave,
-slave_mode, true);
- if (ret < 0) {
- dev_err(>dev,
- "pre-prepare failed:%d", ret);
- return ret;
- }
-
- if (slave_mode == SDW_CLK_STOP_MODE1)
+ /* Only prepare a Slave device if needed */
+ if (!slave->prop.simple_clk_stop_capable) {
simple_clk_stop = false;
+
+ ret = sdw_slave_clk_stop_prepare(slave,
+SDW_CLK_STOP_MODE0,
+true);
+ if (ret < 0) {
+ dev_err(>dev,
+ "pre-prepare failed:%d", ret);
+ return ret;
+ }
+ }
}
/* Skip remaining clock stop preparation if no Slave is attached */
if (!is_slave)
return ret;
+ /*
+* Don't wait for all Slaves to be ready if they follow the simple
+* state machine
+*/
if (!simple_clk_stop) {
ret = sdw_bus_wait_for_clk_prep_deprep(bus,
SDW_BROADCAST_DEV_NUM);
@@ -998,17 +982,13 @@ int sdw_bus_prep_clk_stop(struct sdw_bus *bus)
slave->status != SDW_SLAVE_ALERT)
continue;
- slave_mode = slave->curr_clk_stop_mode;
+ ret = sdw_slave_clk_stop_callback(slave,
+ SDW_CLK_STOP_MODE0,
+ SDW_CLK_POST_PREPARE);
- if (slave_mode == SDW_CLK_STOP_MODE1) {
-
[PATCH 0/4] soundwire: only use CLOCK_STOP_MODE0 and handle -ENODATA
Existing devices and implementations only support the required CLOCK_STOP_MODE0. All the code related to CLOCK_STOP_MODE1 has not been tested and is highly questionable, with a clear confusion between CLOCK_STOP_MODE1 and the simple clock stop state machine. This patch removes all usages of CLOCK_STOP_MODE1 - which has no impact on any solution - and fixes the use of the simple clock stop state machine. The resulting code should be a lot more symmetrical and easier to maintain. Note that CLOCK_STOP_MODE1 is not supported in the SoundWire Device Class specification so it's rather unlikely that we need to re-add this mode later. If a device lost sync and can no longer ACK a command, it may not be able to enter a lower-power state but it will still be able to resync when the clock restarts. In those cases, we want to continue with the clock stop sequence. This patch modifies the behavior during clock stop sequences to only log errors unrelated to -ENODATA/Command_Ignored. The flow is also modified so that loops continue to prepare/deprepare other devices even when one seems to have lost sync. When resuming the clocks, all issues are logged with a dev_warn(), previously only some of them were checked. This is the only part that now differs between the clock stop entry and clock stop exit sequences: while we don't want to stop the suspend flow, we do want information on potential issues while resuming, as they may have ripple effects. For consistency the log messages are also modified to be unique and self-explanatory. Errors in sdw_slave_clk_stop_callback() were removed, they are now handled in the caller. Pierre-Louis Bossart (4): soundwire: bus: only use CLOCK_STOP_MODE0 and fix confusions soundwire: add missing kernel-doc description soundwire: bus: handle -ENODATA errors in clock stop/start sequences soundwire: bus: add missing \n in dynamic debug drivers/soundwire/bus.c | 155 +++--- include/linux/soundwire/sdw.h | 3 +- 2 files changed, 70 insertions(+), 88 deletions(-) -- 2.17.1
RE: [PATCH 3/3] fpga: region: Adds runtime PM support
Hi Moritz,
Please find my response inline.
> -Original Message-
> From: Moritz Fischer
> Sent: Saturday, April 10, 2021 3:01 AM
> To: Nava kishore Manne
> Cc: m...@kernel.org; t...@redhat.com; robh...@kernel.org; Michal Simek
> ; linux-f...@vger.kernel.org;
> devicet...@vger.kernel.org; linux-kernel@vger.kernel.org; linux-arm-
> ker...@lists.infradead.org; git
> Subject: Re: [PATCH 3/3] fpga: region: Adds runtime PM support
>
> On Fri, Apr 02, 2021 at 02:50:49PM +0530, Nava kishore Manne wrote:
> > Adds support to handle FPGA/PL power domain. With this patch, the PL
> > power domain will be turned on before loading the bitstream and turned
> > off while removing/unloading the bitstream using overlays.
> > This can be achieved by adding the runtime PM support.
> >
> > Signed-off-by: Nava kishore Manne
> > ---
> > drivers/fpga/of-fpga-region.c | 18 +-
> > 1 file changed, 17 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/fpga/of-fpga-region.c
> > b/drivers/fpga/of-fpga-region.c index e405309baadc..35fc2f3d4bd8
> > 100644
> > --- a/drivers/fpga/of-fpga-region.c
> > +++ b/drivers/fpga/of-fpga-region.c
> > @@ -15,6 +15,7 @@
> > #include
> > #include
> > #include
> > +#include
> >
> > static const struct of_device_id fpga_region_of_match[] = {
> > { .compatible = "fpga-region", },
> > @@ -302,6 +303,7 @@ static int of_fpga_region_notify_pre_apply(struct
> fpga_region *region,
> > }
> >
> > region->info = info;
> > + pm_runtime_get_sync(dev->parent);
> > ret = fpga_region_program_fpga(region);
> > if (ret) {
> > /* error; reject overlay */
> > @@ -324,10 +326,13 @@ static int
> > of_fpga_region_notify_pre_apply(struct fpga_region *region, static void
> of_fpga_region_notify_post_remove(struct fpga_region *region,
> > struct of_overlay_notify_data
> *nd) {
> > + struct device *dev = >dev;
> > +
> > fpga_bridges_disable(>bridge_list);
> > fpga_bridges_put(>bridge_list);
> > fpga_image_info_free(region->info);
> > region->info = NULL;
> > + pm_runtime_put(dev->parent);
> > }
> >
> > /**
> > @@ -411,9 +416,16 @@ static int of_fpga_region_probe(struct
> platform_device *pdev)
> > goto eprobe_mgr_put;
> > }
> >
> > + pm_runtime_enable(>dev);
> > + ret = pm_runtime_get_sync(>dev);
> > + if (ret < 0)
> > + goto err_pm;
> > +
> > + pm_runtime_put(>dev);
> > +
> > ret = fpga_region_register(region);
> > if (ret)
> > - goto eprobe_mgr_put;
> > + goto err_pm;
> >
> > of_platform_populate(np, fpga_region_of_match, NULL,
> >dev);
> > platform_set_drvdata(pdev, region);
> > @@ -422,6 +434,9 @@ static int of_fpga_region_probe(struct
> > platform_device *pdev)
> >
> > return 0;
> >
> > +err_pm:
> > + pm_runtime_put(>dev);
> > + pm_runtime_disable(>dev);
> > eprobe_mgr_put:
> > fpga_mgr_put(mgr);
> > return ret;
> > @@ -434,6 +449,7 @@ static int of_fpga_region_remove(struct
> > platform_device *pdev)
> >
> > fpga_region_unregister(region);
> > fpga_mgr_put(mgr);
> > + pm_runtime_disable(region->dev.parent);
> >
> > return 0;
> > }
> > --
> > 2.18.0
> >
>
> Does this add a dependency on CONFIG_PM?
>
Yes, the newly added functionality has a dependency on CONFIG_PM if it's
disabled the expected power domain (in our cases it's PL) will not powered
ON/OFF dynamically at runtime and this is as an expected behavior. Other than
this it will not impact the any of the driver existing functionality.
Regards,
Navakishore.
Re: [PATCH net-next v3 2/5] mm: add a signature in struct page
On Wed, Apr 14, 2021 at 01:09:47PM -0700, Shakeel Butt wrote: > On Wed, Apr 14, 2021 at 12:42 PM Jesper Dangaard Brouer > wrote: > > > [...] > > > > > > > > Can this page_pool be used for TCP RX zerocopy? If yes then PageType > > > > can not be used. > > > > > > Yes it can, since it's going to be used as your default allocator for > > > payloads, which might end up on an SKB. > > > > I'm not sure we want or should "allow" page_pool be used for TCP RX > > zerocopy. > > For several reasons. > > > > (1) This implies mapping these pages page to userspace, which AFAIK > > means using page->mapping and page->index members (right?). > > > > No, only page->_mapcount is used. > I am not sure I like leaving out TCP RX zerocopy. Since we want driver to adopt the recycling mechanism we should try preserving the current functionality of the network stack. The question is how does it work with the current drivers that already have an internal page recycling mechanism. > > (2) It feels wrong (security wise) to keep the DMA-mapping (for the > > device) and also map this page into userspace. > > > > I think this is already the case i.e pages still DMA-mapped and also > mapped into userspace. > > > (3) The page_pool is optimized for refcnt==1 case, and AFAIK TCP-RX > > zerocopy will bump the refcnt, which means the page_pool will not > > recycle the page when it see the elevated refcnt (it will instead > > release its DMA-mapping). > > Yes this is right but the userspace might have already consumed and > unmapped the page before the driver considers to recycle the page. Same question here. I'll have a closer look in a few days and make sure we are not breaking anything wrt zerocopy. > > > > > (4) I remember vaguely that this code path for (TCP RX zerocopy) uses > > page->private for tricks. And our patch [3/5] use page->private for > > storing xdp_mem_info. > > > > IMHO when the SKB travel into this TCP RX zerocopy code path, we should > > call page_pool_release_page() to release its DMA-mapping. > > > > I will let TCP RX zerocopy experts respond to this but from my high > level code inspection, I didn't see page->private usage. Shakeel are you aware of any 'easy' way I can have rx zerocopy running? Thanks! /Ilias
Re: [PATCH v3] USB: Don't set USB_PORT_FEAT_SUSPEND on WD19's Realtek Hub
On Fri, Apr 16, 2021 at 11:39 AM Alan Stern wrote: > > On Fri, Apr 16, 2021 at 09:24:30AM +0800, Chris Chiu wrote: > > On Fri, Apr 16, 2021 at 2:46 AM Alan Stern > > wrote: > > > > > > On Fri, Apr 16, 2021 at 12:13:43AM +0800, Chris Chiu wrote: > > > > One thing worth mentioning here, I never hit the hub_ext_port_status -71 > > > > problem if I resume by waking up from the keyboard connected to the hub. > > > > > > I thought you said earlier that the port got into trouble while it was > > > suspending, not while it was resuming. You wrote: > > > > > > > [ 2789.679812] usb 3-4-port3: can't suspend, status -110 > > > > > > So if the problem occurs during suspend, how can it be possible to avoid > > > the problem by taking some particular action later while resuming? > > > > > > > The ETIMEDOUT is still there, but the port can resume w/o problems and I > > don't really know what the hub did. I can only reset_resume the hub to > > bring it > > back if I'm not waking up from the connected keyboard. > > What if two devices are plugged into the hub, only one of them is > runtime suspended, and you need to runtime resume that device? Then you > can't do a reset-resume of the hub, because the hub isn't suspended. > > > > > But the usbcore kernel log shows me wPortStatus: 0503 wPortChane: 0004 > > > > of that port while resuming. In normal cases, they are 0507:. > > > > > > The 0004 bit of wPortChange means that the suspend status has changed; > > > the port is no longer suspended because the device attached to that port > > > (your keyboard) issued a wakeup request. > > > > > > > I don't know how to SetPortFeature() with setting the status change > > > > bit only. > > > > > > You can't. Only the hub itself can set the wPortChange bits. > > > > > > > Or maybe it's just some kind of timing issue of the > > > > idle/suspend/resume signaling. > > > > > > Not timing. It's because you woke the system up from the attached > > > keyboard. > > > > > > Alan Stern > > > > Got it. I'm just confused by the USB 2.0 spec 11.24.2.7.2 that > > "Hubs may allow setting of the status change bits with a SetPortFeature() > > request for diagnostic purposes." > > Yeah, I don't think very many hubs actually do that. > > > So for this case, I think USB_QUIRK_RESET_RESUME would be a > > better option to at least bring back the port. Any suggestion about what > > kind of test I can do on this hub? Thanks > > I'm not sure what you're proposing. > > If (as mentioned above) the hub doesn't handle the > Set-Port-Feature(suspend) request properly, then we should avoid issuing > that request. Which means runtime suspend attempts should not be > allowed, as in your most recent patch. > > Alan Stern Sorry that I didn't make myself clear. I found that if I applied RESET_RESUME quirk on the problematic hub, the Set-Port-Feature(suspend) timeout error disappeared. SInce the timeout is not happening for each suspend by default, I suspect maybe reset-resume take everything back to clean state for the hub and the Set-Port-Feature(suspend) can be taken care of w/o problems. I didn't like RESET_RESUME because runtime PM would not work on the quirked device. But if the Set-Port-Feature(suspend) can't be handled and skipped, I can't expect the runtime PM to work for all devices connected to the hub either. Is that right? If what I proposed in the patch can not get better result than existing quirk, I think using the RESET_RESUME would be a better option. Any suggestions? Chris
Re: [PATCH 00/31] Rid W=1 warnings from GFS2 and EncryptFS
On 2021-03-30 17:44:27, Lee Jones wrote: > This set is part of a larger effort attempting to clean-up W=1 > kernel builds, which are currently overwhelmingly riddled with > niggly little warnings. > > There is more to do in filesystems. Another set will follow. > > Lee Jones (31): ... > fs: ecryptfs: read_write: File headers do not make good candidates for > kernel-doc > fs: ecryptfs: debug: Demote a couple of kernel-doc abuses > fs: ecryptfs: dentry: File headers are not good candidates for > kernel-doc > fs: ecryptfs: kthread: Demote file header and provide description for > 'cred' > fs: ecryptfs: file: Demote kernel-doc abuses > fs: ecryptfs: super: Fix formatting, naming and kernel-doc abuses > fs: ecryptfs: messaging: Add missing param descriptions and demote > abuses > fs: ecryptfs: main: Demote a bunch of non-conformant kernel-doc > headers > fs: ecryptfs: miscdev: File headers are not good kernel-doc candidates > fs: ecryptfs: crypto: Supply some missing param descriptions and > demote abuses > fs: ecryptfs: mmap: Help out one function header and demote other > abuses > fs: ecryptfs: inode: Help out nearly-there header and demote > non-conformant ones > fs: ecryptfs: keystore: Fix some kernel-doc issues and demote > non-conformant headers I've applied the eCryptfs fixes to the next branch of tyhicks/ecryptfs.git. Thanks for the clean-up! Tyler
[PATCH] iommu: Use passthrough mode for the Intel IPUs
Intel IPU(Image Processing Unit) has its own (IO)MMU hardware,
The IPU driver allocates its own page table that is not mapped
via the DMA, and thus the Intel IOMMU driver blocks access giving
this error:
DMAR: DRHD: handling fault status reg 3
DMAR: [DMA Read] Request device [00:05.0] PASID
fault addr 76406000 [fault reason 06] PTE Read access is not set
As IPU is not an external facing device which is not risky, so use
IOMMU passthrough mode for Intel IPUs.
Signed-off-by: Bingbu Cao
---
drivers/iommu/intel/iommu.c | 35 +++
drivers/staging/media/ipu3/ipu3.c | 2 +-
include/linux/pci_ids.h | 5 +
3 files changed, 41 insertions(+), 1 deletion(-)
diff --git a/drivers/iommu/intel/iommu.c b/drivers/iommu/intel/iommu.c
index ee0932307d64..59222d2fe73f 100644
--- a/drivers/iommu/intel/iommu.c
+++ b/drivers/iommu/intel/iommu.c
@@ -55,6 +55,12 @@
#define IS_GFX_DEVICE(pdev) ((pdev->class >> 16) == PCI_BASE_CLASS_DISPLAY)
#define IS_USB_DEVICE(pdev) ((pdev->class >> 8) == PCI_CLASS_SERIAL_USB)
#define IS_ISA_DEVICE(pdev) ((pdev->class >> 8) == PCI_CLASS_BRIDGE_ISA)
+#define IS_IPU_DEVICE(pdev) ((pdev)->vendor == PCI_VENDOR_ID_INTEL &&
\
+((pdev)->device == PCI_DEVICE_ID_INTEL_IPU3 ||
\
+(pdev)->device == PCI_DEVICE_ID_INTEL_IPU6 ||
\
+(pdev)->device == PCI_DEVICE_ID_INTEL_IPU6SE ||
\
+(pdev)->device == PCI_DEVICE_ID_INTEL_IPU6SE_P ||
\
+(pdev)->device == PCI_DEVICE_ID_INTEL_IPU6EP))
#define IS_AZALIA(pdev) ((pdev)->vendor == 0x8086 && (pdev)->device == 0x3a3e)
#define IOAPIC_RANGE_START (0xfee0)
@@ -360,6 +366,7 @@ int intel_iommu_enabled = 0;
EXPORT_SYMBOL_GPL(intel_iommu_enabled);
static int dmar_map_gfx = 1;
+static int dmar_map_ipu = 1;
static int dmar_forcedac;
static int intel_iommu_strict;
static int intel_iommu_superpage = 1;
@@ -368,6 +375,7 @@ static int iommu_skip_te_disable;
#define IDENTMAP_GFX 2
#define IDENTMAP_AZALIA4
+#define IDENTMAP_IPU 8
int intel_iommu_gfx_mapped;
EXPORT_SYMBOL_GPL(intel_iommu_gfx_mapped);
@@ -2839,6 +2847,9 @@ static int device_def_domain_type(struct device *dev)
if ((iommu_identity_mapping & IDENTMAP_GFX) &&
IS_GFX_DEVICE(pdev))
return IOMMU_DOMAIN_IDENTITY;
+
+ if ((iommu_identity_mapping & IDENTMAP_IPU) &&
IS_IPU_DEVICE(pdev))
+ return IOMMU_DOMAIN_IDENTITY;
}
return 0;
@@ -3278,6 +3289,9 @@ static int __init init_dmars(void)
if (!dmar_map_gfx)
iommu_identity_mapping |= IDENTMAP_GFX;
+ if (!dmar_map_ipu)
+ iommu_identity_mapping |= IDENTMAP_IPU;
+
check_tylersburg_isoch();
ret = si_domain_init(hw_pass_through);
@@ -5622,6 +5636,15 @@ static void quirk_iommu_igfx(struct pci_dev *dev)
dmar_map_gfx = 0;
}
+static void quirk_iommu_ipu(struct pci_dev *dev)
+{
+ if (risky_device(dev))
+ return;
+
+ pci_info(dev, "Passthrough IOMMU for integrated Intel IPU\n");
+ dmar_map_ipu = 0;
+}
+
/* G4x/GM45 integrated gfx dmar support is totally busted. */
DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x2a40, quirk_iommu_igfx);
DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x2e00, quirk_iommu_igfx);
@@ -5657,6 +5680,18 @@ DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x1632,
quirk_iommu_igfx);
DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x163A, quirk_iommu_igfx);
DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x163D, quirk_iommu_igfx);
+/* disable IPU dmar support */
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_IPU3,
+quirk_iommu_ipu);
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_IPU6EP,
+quirk_iommu_ipu);
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_IPU6SE_P,
+quirk_iommu_ipu);
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_IPU6,
+quirk_iommu_ipu);
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_IPU6SE,
+quirk_iommu_ipu);
+
static void quirk_iommu_rwbf(struct pci_dev *dev)
{
if (risky_device(dev))
diff --git a/drivers/staging/media/ipu3/ipu3.c
b/drivers/staging/media/ipu3/ipu3.c
index ee1bba6bdcac..aee1130ac042 100644
--- a/drivers/staging/media/ipu3/ipu3.c
+++ b/drivers/staging/media/ipu3/ipu3.c
@@ -16,7 +16,7 @@
#include "ipu3-dmamap.h"
#include "ipu3-mmu.h"
-#define IMGU_PCI_ID0x1919
+#define IMGU_PCI_IDPCI_DEVICE_ID_INTEL_IPU3
#define IMGU_PCI_BAR 0
#define IMGU_DMA_MASK DMA_BIT_MASK(39)
#define IMGU_MAX_QUEUE_DEPTH (2 + 2)
diff --git
Re: [RFC v1 PATCH 3/3] driver: update all the code that use soc_device_match
Alice Guo (OSS) wrote on Mon, Apr 19, 2021 at 12:27:22PM +0800:
> From: Alice Guo
>
> Update all the code that use soc_device_match
A single patch might be difficult to accept for all components, a each
maintainer will probably want to have a say on their subsystem?
I would suggest to split these for a non-RFC version; a this will really
need to be case-by-case handling.
> because add support for soc_device_match returning -EPROBE_DEFER.
(English does not parse here for me)
I've only commented a couple of places in the code itself, but this
doesn't seem to add much support for errors, just sweep the problem
under the rug.
> Signed-off-by: Alice Guo
> ---
>
> diff --git a/drivers/bus/ti-sysc.c b/drivers/bus/ti-sysc.c
> index 5fae60f8c135..00c59aa217c1 100644
> --- a/drivers/bus/ti-sysc.c
> +++ b/drivers/bus/ti-sysc.c
> @@ -2909,7 +2909,7 @@ static int sysc_init_soc(struct sysc *ddata)
> }
>
> match = soc_device_match(sysc_soc_feat_match);
> - if (!match)
> + if (!match || IS_ERR(match))
> return 0;
This function handles errors, I would recommend returning the error as
is if soc_device_match returned one so the probe can be retried later.
>
> if (match->data)
> diff --git a/drivers/clk/renesas/r8a7795-cpg-mssr.c
> b/drivers/clk/renesas/r8a7795-cpg-mssr.c
> index c32d2c678046..90a18336a4c3 100644
> --- a/drivers/clk/renesas/r8a7795-cpg-mssr.c
> +++ b/drivers/clk/renesas/r8a7795-cpg-mssr.c
> @@ -439,6 +439,7 @@ static const unsigned int r8a7795es2_mod_nullify[]
> __initconst = {
>
> static int __init r8a7795_cpg_mssr_init(struct device *dev)
> {
> + const struct soc_device_attribute *match;
> const struct rcar_gen3_cpg_pll_config *cpg_pll_config;
> u32 cpg_mode;
> int error;
> @@ -453,7 +454,8 @@ static int __init r8a7795_cpg_mssr_init(struct device
> *dev)
> return -EINVAL;
> }
>
> - if (soc_device_match(r8a7795es1)) {
> + match = soc_device_match(r8a7795es1);
> + if (!IS_ERR(match) && match) {
Same, return the error.
Assuming an error means no match will just lead to hard to debug
problems because the driver potentially assumed the wrong device when
it's just not ready yet.
> cpg_core_nullify_range(r8a7795_core_clks,
> ARRAY_SIZE(r8a7795_core_clks),
> R8A7795_CLK_S0D2, R8A7795_CLK_S0D12);
> [...]
> diff --git a/drivers/iommu/ipmmu-vmsa.c b/drivers/iommu/ipmmu-vmsa.c
> index eaaec0a55cc6..13a06b613379 100644
> --- a/drivers/iommu/ipmmu-vmsa.c
> +++ b/drivers/iommu/ipmmu-vmsa.c
> @@ -757,17 +757,20 @@ static const char * const devices_allowlist[] = {
>
> static bool ipmmu_device_is_allowed(struct device *dev)
> {
> + const struct soc_device_attribute *match1, *match2;
> unsigned int i;
>
> /*
>* R-Car Gen3 and RZ/G2 use the allow list to opt-in devices.
>* For Other SoCs, this returns true anyway.
>*/
> - if (!soc_device_match(soc_needs_opt_in))
> + match1 = soc_device_match(soc_needs_opt_in);
> + if (!IS_ERR(match1) && !match1)
I'm not sure what you intended to do, but !match1 already means there is
no error so the original code is identical.
In this case ipmmu_device_is_allowed does not allow errors so this is
one of the "difficult" drivers that require slightly more thinking.
It is only called in ipmmu_of_xlate which does return errors properly,
so in this case the most straightforward approach would be to make
ipmmu_device_is_allowed return an int and forward errors as well.
...
This is going to need quite some more work to be acceptable, in my
opinion, but I think it should be possible.
Thanks,
--
Dominique
Re: [RFC v1 PATCH 3/3] driver: update all the code that use soc_device_match
On Mon, Apr 19, 2021 at 12:27:22PM +0800, Alice Guo (OSS) wrote:
> From: Alice Guo
>
> Update all the code that use soc_device_match because add support for
> soc_device_match returning -EPROBE_DEFER.
>
> Signed-off-by: Alice Guo
> ---
> drivers/bus/ti-sysc.c | 2 +-
> drivers/clk/renesas/r8a7795-cpg-mssr.c| 4 +++-
> drivers/clk/renesas/rcar-gen2-cpg.c | 2 +-
> drivers/clk/renesas/rcar-gen3-cpg.c | 2 +-
> drivers/dma/fsl-dpaa2-qdma/dpaa2-qdma.c | 7 ++-
> drivers/dma/ti/k3-psil.c | 3 +++
> drivers/dma/ti/k3-udma.c | 2 +-
> drivers/gpu/drm/bridge/nwl-dsi.c | 2 +-
> drivers/gpu/drm/meson/meson_drv.c | 4 +++-
> drivers/gpu/drm/omapdrm/dss/dispc.c | 2 +-
> drivers/gpu/drm/omapdrm/dss/dpi.c | 4 +++-
> drivers/gpu/drm/omapdrm/dss/dsi.c | 3 +++
> drivers/gpu/drm/omapdrm/dss/dss.c | 3 +++
> drivers/gpu/drm/omapdrm/dss/hdmi4_core.c | 3 +++
> drivers/gpu/drm/omapdrm/dss/venc.c| 4 +++-
> drivers/gpu/drm/omapdrm/omap_drv.c| 3 +++
> drivers/gpu/drm/rcar-du/rcar_du_crtc.c| 4 +++-
> drivers/gpu/drm/rcar-du/rcar_lvds.c | 2 +-
> drivers/gpu/drm/tidss/tidss_dispc.c | 4 +++-
> drivers/iommu/ipmmu-vmsa.c| 7 +--
> drivers/media/platform/rcar-vin/rcar-core.c | 2 +-
> drivers/media/platform/rcar-vin/rcar-csi2.c | 2 +-
> drivers/media/platform/vsp1/vsp1_uif.c| 4 +++-
> drivers/mmc/host/renesas_sdhi_core.c | 2 +-
> drivers/mmc/host/renesas_sdhi_internal_dmac.c | 2 +-
> drivers/mmc/host/sdhci-of-esdhc.c | 21 ++-
> drivers/mmc/host/sdhci-omap.c | 2 +-
> drivers/mmc/host/sdhci_am654.c| 2 +-
> drivers/net/ethernet/renesas/ravb_main.c | 4 +++-
> drivers/net/ethernet/ti/am65-cpsw-nuss.c | 2 +-
> drivers/net/ethernet/ti/cpsw.c| 2 +-
> drivers/net/ethernet/ti/cpsw_new.c| 2 +-
> drivers/phy/ti/phy-omap-usb2.c| 4 +++-
> drivers/pinctrl/renesas/core.c| 2 +-
> drivers/pinctrl/renesas/pfc-r8a7790.c | 5 -
> drivers/pinctrl/renesas/pfc-r8a7794.c | 5 -
> drivers/soc/fsl/dpio/dpio-driver.c| 13
> drivers/soc/renesas/r8a774c0-sysc.c | 5 -
> drivers/soc/renesas/r8a7795-sysc.c| 2 +-
> drivers/soc/renesas/r8a77990-sysc.c | 5 -
> drivers/soc/ti/k3-ringacc.c | 2 +-
> drivers/staging/mt7621-pci/pci-mt7621.c | 2 +-
> drivers/thermal/rcar_gen3_thermal.c | 4 +++-
> drivers/thermal/ti-soc-thermal/ti-bandgap.c | 10 +++--
> drivers/usb/gadget/udc/renesas_usb3.c | 2 +-
> drivers/usb/host/ehci-platform.c | 4 +++-
> drivers/usb/host/xhci-rcar.c | 2 +-
> drivers/watchdog/renesas_wdt.c| 2 +-
> 48 files changed, 131 insertions(+), 52 deletions(-)
>
> diff --git a/drivers/bus/ti-sysc.c b/drivers/bus/ti-sysc.c
> index 5fae60f8c135..00c59aa217c1 100644
> --- a/drivers/bus/ti-sysc.c
> +++ b/drivers/bus/ti-sysc.c
> @@ -2909,7 +2909,7 @@ static int sysc_init_soc(struct sysc *ddata)
> }
>
> match = soc_device_match(sysc_soc_feat_match);
> - if (!match)
> + if (!match || IS_ERR(match))
> return 0;
>
> if (match->data)
> diff --git a/drivers/clk/renesas/r8a7795-cpg-mssr.c
> b/drivers/clk/renesas/r8a7795-cpg-mssr.c
> index c32d2c678046..90a18336a4c3 100644
> --- a/drivers/clk/renesas/r8a7795-cpg-mssr.c
> +++ b/drivers/clk/renesas/r8a7795-cpg-mssr.c
> @@ -439,6 +439,7 @@ static const unsigned int r8a7795es2_mod_nullify[]
> __initconst = {
>
> static int __init r8a7795_cpg_mssr_init(struct device *dev)
> {
> + const struct soc_device_attribute *match;
> const struct rcar_gen3_cpg_pll_config *cpg_pll_config;
> u32 cpg_mode;
> int error;
> @@ -453,7 +454,8 @@ static int __init r8a7795_cpg_mssr_init(struct device
> *dev)
> return -EINVAL;
> }
>
> - if (soc_device_match(r8a7795es1)) {
> + match = soc_device_match(r8a7795es1);
> + if (!IS_ERR(match) && match) {
"if (!IS_ERR_OR_NULL(match))" in all places.
Thanks
Re: [Qestion] Is preempt_disable/enable needed in non-preemption code path
On 4/17/21 1:26 AM, Paul E. McKenney wrote:
[Please note: This e-mail is from an EXTERNAL e-mail address]
On Fri, Apr 16, 2021 at 06:51:10PM +0800, Xu, Yanfei wrote:
On 4/16/21 1:07 AM, Paul E. McKenney wrote:
[Please note: This e-mail is from an EXTERNAL e-mail address]
On Fri, Apr 16, 2021 at 12:18:42AM +0800, Xu, Yanfei wrote:
On 4/15/21 11:43 PM, Paul E. McKenney wrote:
[Please note: This e-mail is from an EXTERNAL e-mail address]
On Thu, Apr 15, 2021 at 11:04:05PM +0800, Xu, Yanfei wrote:
Hi experts,
I am learning rcu mechanism and its codes. When looking at the
rcu_blocking_is_gp(), I found there is a pair preemption disable/enable
operation in non-preemption code path. And it has been a long time. I can't
understand why we need it? Is there some thing I missed? If not, can we
remove the unnecessary operation like blow?
Good point, you are right that preemption is disabled anyway in that block
of code. However, preempt_disable() and preempt_enable() also prevent the
compiler from moving that READ_ONCE() around. So my question to you is
whether it is safe to remove those statements entirely or whether they
should instead be replaced by barrier() or similar.
Thanks for your reply! :)
Yes, preempt_disable() and preempt_enable() defined in !preemption are
barrier(). barrier can prevent from reordering that READ_ONCE(), but base on
my current understanding, volatile in READ_ONCE can also tell the compiler
not to reorder it. So, I think it's safe?
Maybe.
Please keep in mind that although the compiler is prohibited from
reordering volatile accesses with each other, there is nothing stopping
it from reordering volatile accesses with non-volatile accesses.
Thanks for your patient explanation!
I am trying to absorb what you said. Blow are my understanding:
1. "the compiler is prohibited from reordering volatile accesses with each
other" means these situations:
int a;
foo()
{
for(;;)
READ_ONCE(a);
}
or
int a,b;
foo()
{
int c,d;
c = READ_ONCE(a);
d = READ_ONCE(b);
}
Yes, in both cases the load instructions emitted for the READ_ONCE()
macros must be emitted in order. The underlying hardware is free
to reorder.
Got it.
2. "volatile accesses with non-volatile accesses" means d=b may happen
before c=READ_ONCE(a) :
int a;
foo()
{
int b = 2
int c,d;
c = READ_ONCE(a);
d = b;
}
if we want to keep the ordering of volatile access "c=READ_ONCE(a)" and
non-volatile access "d=b", we should use stronger barrier like barrier().
Or an additional READ_ONCE() for b or a WRITE_ONCE() for d. But again,
this would constrain only the compiler, not the hardware.
But this wouldn't matter in most cases, because both b and d are local
variables whose addresses were never taken. So someone would need to
be using something crazy to poke into others' stacks for this to matter.
Agree.
Hope I didn't misunderstand.
It looks like you have most of it.
Back to rcu_blocking_is_gp(), I find this link today
https://www.spinics.net/lists/rcu/msg03985.html
With the content in this link, I still haven't got the meaning of these two
barrier(). I think I should learn knowledge about cpu-hotplug and things
which talked in the link first to make sure if I am missing something, and
then consult you. :)
That sounds like a very good approach!
Keep in mind that I am worried not just about the current state of
the code and compilers, but also their possible future states.
I see.
Thanks again.
Best regards,
Yanfei
Thanx, Paul
Best regards,
Yanfei
Thanx, Paul
Best regards,
Yanfei
Thanx, Paul
diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c
index da6f5213fb74..c6d95a00715e 100644
--- a/kernel/rcu/tree.c
+++ b/kernel/rcu/tree.c
@@ -3703,7 +3703,6 @@ static int rcu_blocking_is_gp(void)
if (IS_ENABLED(CONFIG_PREEMPTION))
return rcu_scheduler_active == RCU_SCHEDULER_INACTIVE;
might_sleep(); /* Check for RCU read-side critical section. */
- preempt_disable();
/*
* If the rcu_state.n_online_cpus counter is equal to one,
* there is only one CPU, and that CPU sees all prior accesses
@@ -3718,7 +3717,6 @@ static int rcu_blocking_is_gp(void)
* Those memory barriers are provided by CPU-hotplug code.
*/
ret = READ_ONCE(rcu_state.n_online_cpus) <= 1;
- preempt_enable();
return ret;
}
Best regards,
Yanfei
Re: [PATCH] Revert "MIPS: make userspace mapping young by default".
On Sat, Apr 17, 2021 at 12:45:59AM +0800, Zhou Yanjie wrote:
>
> On 2021/4/16 下午5:20, 黄沛 wrote:
> > Is there any log about the panic?
>
>
> Yes, below is the log:
>
>
> [ 195.436017] CPU 0 Unable to handle kernel paging request at virtual
> address 77eb8000, epc == 80117868, ra == 80118208
> [ 195.446709] Oops[#1]:
> [ 195.448977] CPU: 0 PID: 1461 Comm: Xsession Not tainted
> 5.12.0-rc6-00227-gc8fc6defbd2e-dirty #1
> [ 195.457661] $ 0 : 0001 80117864 77eb9000
> [ 195.462888] $ 4 : 77eb8000 82419600 838ea000 82482ba0
> [ 195.468116] $ 8 : 826f8b18 8306f800 72d5 8306f800
> [ 195.473343] $12 : 0002 0a03 0001 0402
> [ 195.478568] $16 : 77eb8000 809faf60 0004 82482ba0
> [ 195.483794] $20 : 77eb8000 82419600 82482ba0 8086
> [ 195.489021] $24 : 8086121c 80117864
> [ 195.494248] $28 : 838ea000 838ebd70 80118208
> [ 195.499475] Hi : 8c4e
> [ 195.502343] Lo : 4627
> [ 195.505212] epc : 80117868 r4k_blast_dcache_page_dc32+0x4/0x9c
> [ 195.511217] ra : 80118208 local_r4k_flush_cache_page+0x120/0x1b8
> [ 195.517476] Status: 10001403 KERNEL EXL IE
> [ 195.521657] Cause : 4080800c (ExcCode 03)
> [ 195.525654] BadVA : 77eb8000
> [ 195.528523] PrId : 00d00100 (Ingenic XBurst)
> [ 195.532866] Modules linked in:
> [ 195.535911] Process Xsession (pid: 1461, threadinfo=00975a3e,
> task=3724fd66, tls=77ebd690)
> [ 195.544162] Stack : 808a05ec f7edcbfd 8306f800 8086 809faf60
> 80990a3c 80117f90
> [ 195.552524] 809faf60 82419600 8306f800 801fd84c 801180b4
> 838ebe80 80110b7c
> [ 195.560887] 80990a3c 82482ba0 82482ba0 77eb8000 4627 f7edcbfd
> 838ebe80 801cbc08
> [ 195.569249] 0001 181b2000 801fa06c 83999ae0
> 8086 0004
> [ 195.577610] 80990a3c f7edcbfd 80990a3c 838ebe80 0004 80990a3c
> 82482ba0 04627685
> [ 195.585973] ...
> [ 195.588413] Call Trace:
> [ 195.590849] [<80117868>] r4k_blast_dcache_page_dc32+0x4/0x9c
> [ 195.596501] [<80118208>] local_r4k_flush_cache_page+0x120/0x1b8
> [ 195.602413] [<80117f90>] r4k_on_each_cpu.isra.8+0x24/0x58
> [ 195.607805] [<801180b4>] r4k_flush_cache_page+0x34/0x58
> [ 195.613023] [<801cbc08>] wp_page_copy+0x3a8/0x56c
> [ 195.617723] [<801ce944>] do_swap_page+0x4cc/0x558
> [ 195.622419] [<801cf3f8>] handle_mm_fault+0x790/0x93c
> [ 195.627374] [<8011025c>] do_page_fault+0x19c/0x540
> [ 195.632159] [<801142f0>] tlb_do_page_fault_1+0x10c/0x11c
> [ 195.637465]
> [ 195.638947] Code: 03e8 24831000 bc950020
> bc950040 bc950060 bc950080 bc9500a0
> [ 195.648706]
> [ 195.650243] ---[ end trace 7cc7d7f611932c42 ]---
> [ 195.654857] Kernel panic - not syncing: Fatal exception
> [ 195.660072] Rebooting in 10 seconds..
>
>
> this problem can be triggered stably (by use Microsoft Remote Desktop client
> to login to debian9 running on CU1830-Neo).
>
Could you print out the PTE value at 0x77eb8000 ?
I really have no idea of how the page_prot setting affecting the swap
handling.
>
> Thanks and best regards!
>
>
> >
> > Original Message
> > From: 周琰杰 (Zhou Yanjie)
> > Sent: 2021年4月16日星期五 16:48
> > To: tsbog...@alpha.franken.de
> > Cc: linux-m...@vger.kernel.org; linux-kernel@vger.kernel.org;
> > a...@linux-foundation.org; paul.bur...@mips.com; p...@crapouillou.net;
> > siyant...@loongson.cn; huang...@loongson.cn; ira.we...@intel.com;
> > yangtie...@loongson.cn; zhouyan...@wanyeetech.com; jun.ji...@ingenic.com;
> > dongsheng@ingenic.com; aric.p...@ingenic.com; rick.ty...@ingenic.com;
> > sernia.z...@foxmail.com
> > Subject: [PATCH] Revert "MIPS: make userspace mapping young by default".
> >
> > This reverts commit f685a533a7fab35c5d069dcd663f59c8e4171a75.
> >
> > It cause kernel panic on Ingenic X1830, so let's revert it.
> >
> > Signed-off-by: 周琰杰 (Zhou Yanjie)
> > ---
> > arch/mips/mm/cache.c | 31 ++-
> > 1 file changed, 14 insertions(+), 17 deletions(-)
> >
> > diff --git a/arch/mips/mm/cache.c b/arch/mips/mm/cache.c
> > index 7719d63..9cfd432 100644
> > --- a/arch/mips/mm/cache.c
> > +++ b/arch/mips/mm/cache.c
> > @@ -21,7 +21,6 @@
> > #include
> > #include
> > #include
> > -#include
> >
> > /* Cache operations. */
> > void (*flush_cache_all)(void);
> > @@ -157,31 +156,29 @@ unsigned long _page_cachable_default;
> > EXPORT_SYMBOL(_page_cachable_default);
> >
> > #define PM(p) __pgprot(_page_cachable_default | (p))
> > -#define PVA(p) PM(_PAGE_VALID | _PAGE_ACCESSED | (p))
> >
> > static inline void setup_protection_map(void)
> > {
> > protection_map[0] = PM(_PAGE_PRESENT | _PAGE_NO_EXEC | _PAGE_NO_READ);
> > - protection_map[1] = PVA(_PAGE_PRESENT | _PAGE_NO_EXEC);
> > - protection_map[2] = PVA(_PAGE_PRESENT | _PAGE_NO_EXEC | _PAGE_NO_READ);
> > - protection_map[3] = PVA(_PAGE_PRESENT | _PAGE_NO_EXEC);
> > - protection_map[4] = PVA(_PAGE_PRESENT);
> > - protection_map[5] =
[PATCH v9 clocksource 2/6] clocksource: Retry clock read if long delays detected
When the clocksource watchdog marks a clock as unstable, this might
be due to that clock being unstable or it might be due to delays that
happen to occur between the reads of the two clocks. Yes, interrupts are
disabled across those two reads, but there are no shortage of things that
can delay interrupts-disabled regions of code ranging from SMI handlers
to vCPU preemption. It would be good to have some indication as to why
the clock was marked unstable.
Therefore, re-read the watchdog clock on either side of the read
from the clock under test. If the watchdog clock shows an excessive
time delta between its pair of reads, the reads are retried. The
maximum number of retries is specified by a new kernel boot parameter
clocksource.max_read_retries, which defaults to three, that is, up to four
reads, one initial and up to three retries. If more than one retry was
required, a message is printed on the console (the occasional single retry
is expected behavior, especially in guest OSes). If the maximum number
of retries is exceeded, the clock under test will be marked unstable.
However, the probability of this happening due to various sorts of
delays is quite small. In addition, the reason (clock-read delays)
for the unstable marking will be apparent.
Cc: John Stultz
Cc: Thomas Gleixner
Cc: Stephen Boyd
Cc: Jonathan Corbet
Cc: Mark Rutland
Cc: Marc Zyngier
Cc: Andi Kleen
Reported-by: Chris Mason
[ paulmck: Per-clocksource retries per Neeraj Upadhyay feedback. ]
[ paulmck: Don't reset injectfail per Neeraj Upadhyay feedback. ]
[ paulmck: Apply Thomas Gleixner feedback. ]
Signed-off-by: Paul E. McKenney
---
.../admin-guide/kernel-parameters.txt | 6 +++
kernel/time/clocksource.c | 53 ---
2 files changed, 52 insertions(+), 7 deletions(-)
diff --git a/Documentation/admin-guide/kernel-parameters.txt
b/Documentation/admin-guide/kernel-parameters.txt
index 4a372037b49f..7fff95bd5504 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -599,6 +599,12 @@
will be five delay-free reads followed by three
delayed reads.
+ clocksource.max_read_retries= [KNL]
+ Number of clocksource_watchdog() retries due to
+ external delays before the clock will be marked
+ unstable. Defaults to three retries, that is,
+ four attempts to read the clock under test.
+
clearcpuid=BITNUM[,BITNUM...] [X86]
Disable CPUID feature X for the kernel. See
arch/x86/include/asm/cpufeatures.h for the valid bit
diff --git a/kernel/time/clocksource.c b/kernel/time/clocksource.c
index d77700c45f4e..facce83fcb4a 100644
--- a/kernel/time/clocksource.c
+++ b/kernel/time/clocksource.c
@@ -125,6 +125,13 @@ static void __clocksource_change_rating(struct clocksource
*cs, int rating);
#define WATCHDOG_INTERVAL (HZ >> 1)
#define WATCHDOG_THRESHOLD (NSEC_PER_SEC >> 4)
+/*
+ * Maximum permissible delay between two readouts of the watchdog
+ * clocksource surrounding a read of the clocksource being validated.
+ * This delay could be due to SMIs, NMIs, or to VCPU preemptions.
+ */
+#define WATCHDOG_MAX_SKEW (100 * NSEC_PER_USEC)
+
static void clocksource_watchdog_work(struct work_struct *work)
{
/*
@@ -189,6 +196,8 @@ static ulong inject_delay_period;
module_param(inject_delay_period, ulong, 0644);
static ulong inject_delay_repeat = 1;
module_param(inject_delay_repeat, ulong, 0644);
+static ulong max_read_retries = 3;
+module_param(max_read_retries, ulong, 0644);
static void clocksource_watchdog_inject_delay(void)
{
@@ -206,12 +215,42 @@ static void clocksource_watchdog_inject_delay(void)
invocations++;
}
+static bool cs_watchdog_read(struct clocksource *cs, u64 *csnow, u64 *wdnow)
+{
+ unsigned int nretries;
+ u64 wd_end, wd_delta;
+ int64_t wd_delay;
+
+ for (nretries = 0; nretries <= max_read_retries; nretries++) {
+ local_irq_disable();
+ *wdnow = watchdog->read(watchdog);
+ clocksource_watchdog_inject_delay();
+ *csnow = cs->read(cs);
+ wd_end = watchdog->read(watchdog);
+ local_irq_enable();
+
+ wd_delta = clocksource_delta(wd_end, *wdnow, watchdog->mask);
+ wd_delay = clocksource_cyc2ns(wd_delta, watchdog->mult,
watchdog->shift);
+ if (wd_delay <= WATCHDOG_MAX_SKEW) {
+ if (nretries > 1 || nretries >= max_read_retries) {
+ pr_warn("timekeeping watchdog on CPU%d: %s
retried %d times before success\n",
+ smp_processor_id(), watchdog->name,
nretries);
+ }
+ return true;
+ }
+ }
+
+
[PATCH v9 clocksource 5/6] clocksource: Limit number of CPUs checked for clock synchronization
Currently, if skew is detected on a clock marked CLOCK_SOURCE_VERIFY_PERCPU,
that clock is checked on all CPUs. This is thorough, but might not be
what you want on a system with a few tens of CPUs, let alone a few hundred
of them.
Therefore, by default check only up to eight randomly chosen CPUs.
Also provide a new clocksource.verify_n_cpus kernel boot parameter.
A value of -1 says to check all of the CPUs, and a non-negative value says
to randomly select that number of CPUs, without concern about selecting
the same CPU multiple times. However, make use of a cpumask so that a
given CPU will be checked at most once.
Suggested-by: Thomas Gleixner # For verify_n_cpus=1.
Cc: John Stultz
Cc: Thomas Gleixner
Cc: Stephen Boyd
Cc: Jonathan Corbet
Cc: Mark Rutland
Cc: Marc Zyngier
Cc: Andi Kleen
Signed-off-by: Paul E. McKenney
---
.../admin-guide/kernel-parameters.txt | 10 +++
kernel/time/clocksource.c | 74 ++-
2 files changed, 82 insertions(+), 2 deletions(-)
diff --git a/Documentation/admin-guide/kernel-parameters.txt
b/Documentation/admin-guide/kernel-parameters.txt
index 03a8c88a6bb9..6e5b5f19fc56 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -621,6 +621,16 @@
unstable. Defaults to three retries, that is,
four attempts to read the clock under test.
+ clocksource.verify_n_cpus= [KNL]
+ Limit the number of CPUs checked for clocksources
+ marked with CLOCK_SOURCE_VERIFY_PERCPU that
+ are marked unstable due to excessive skew.
+ A negative value says to check all CPUs, while
+ zero says not to check any. Values larger than
+ nr_cpu_ids are silently truncated to nr_cpu_ids.
+ The actual CPUs are chosen randomly, with
+ no replacement if the same CPU is chosen twice.
+
clearcpuid=BITNUM[,BITNUM...] [X86]
Disable CPUID feature X for the kernel. See
arch/x86/include/asm/cpufeatures.h for the valid bit
diff --git a/kernel/time/clocksource.c b/kernel/time/clocksource.c
index edcff9fc3f44..2981e293a468 100644
--- a/kernel/time/clocksource.c
+++ b/kernel/time/clocksource.c
@@ -15,6 +15,8 @@
#include
#include
#include
+#include
+#include
#include "tick-internal.h"
#include "timekeeping_internal.h"
@@ -200,6 +202,8 @@ static int inject_delay_shift_percpu = -1;
module_param(inject_delay_shift_percpu, int, 0644);
static ulong max_read_retries = 3;
module_param(max_read_retries, ulong, 0644);
+static int verify_n_cpus = 8;
+module_param(verify_n_cpus, int, 0644);
static void clocksource_watchdog_inject_delay(void)
{
@@ -250,6 +254,55 @@ static bool cs_watchdog_read(struct clocksource *cs, u64
*csnow, u64 *wdnow)
static u64 csnow_mid;
static cpumask_t cpus_ahead;
static cpumask_t cpus_behind;
+static cpumask_t cpus_chosen;
+
+static void clocksource_verify_choose_cpus(void)
+{
+ int cpu, i, n = verify_n_cpus;
+
+ if (n < 0) {
+ /* Check all of the CPUs. */
+ cpumask_copy(_chosen, cpu_online_mask);
+ cpumask_clear_cpu(smp_processor_id(), _chosen);
+ return;
+ }
+
+ /* If no checking desired, or no other CPU to check, leave. */
+ cpumask_clear(_chosen);
+ if (n == 0 || num_online_cpus() <= 1)
+ return;
+
+ /* Make sure to select at least one CPU other than the current CPU. */
+ cpu = cpumask_next(-1, cpu_online_mask);
+ if (cpu == smp_processor_id())
+ cpu = cpumask_next(cpu, cpu_online_mask);
+ if (WARN_ON_ONCE(cpu >= nr_cpu_ids))
+ return;
+ cpumask_set_cpu(cpu, _chosen);
+
+ /* Force a sane value for the boot parameter. */
+ if (n > nr_cpu_ids)
+ n = nr_cpu_ids - 1;
+
+ /*
+* Randomly select the specified number of CPUs. If the same
+* CPU is selected multiple times, that CPU is checked only once,
+* and no replacement CPU is selected. This gracefully handles
+* situations where verify_n_cpus is greater than the number of
+* CPUs that are currently online.
+*/
+ for (i = 1; i < n; i++) {
+ cpu = prandom_u32() % n;
+ cpu = cpumask_next(cpu - 1, cpu_online_mask);
+ if (cpu >= nr_cpu_ids)
+ cpu = cpumask_next(-1, cpu_online_mask);
+ if (!WARN_ON_ONCE(cpu >= nr_cpu_ids))
+ cpumask_set_cpu(cpu, _chosen);
+ }
+
+ /* Don't verify ourselves. */
+ cpumask_clear_cpu(smp_processor_id(), _chosen);
+}
static void clocksource_verify_one_cpu(void *csin)
{
@@ -271,12 +324,22 @@ static void clocksource_verify_percpu(struct clocksource
[PATCH v9 clocksource 6/6] clocksource: Reduce WATCHDOG_THRESHOLD
Currently, WATCHDOG_THRESHOLD is set to detect a 62.5-millisecond skew in
a 500-millisecond WATCHDOG_INTERVAL. This requires that clocks be skewed
by more than 12.5% in order to be marked unstable. Except that a clock
that is skewed by that much is probably destroying unsuspecting software
right and left. And given that there are now checks for false-positive
skews due to delays between reading the two clocks, and given that current
hardware clocks all increment well in excess of 1MHz, it should be possible
to greatly decrease WATCHDOG_THRESHOLD.
Therefore, decrease WATCHDOG_THRESHOLD from the current 62.5 milliseconds
down to 200 microseconds.
Suggested-by: Thomas Gleixner
Cc: John Stultz
Cc: Stephen Boyd
Cc: Jonathan Corbet
Cc: Mark Rutland
Cc: Marc Zyngier
Cc: Andi Kleen
[ paulmck: Apply Rik van Riel feedback. ]
Reported-by: Chris Mason
Signed-off-by: Paul E. McKenney
---
kernel/time/clocksource.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/kernel/time/clocksource.c b/kernel/time/clocksource.c
index 2981e293a468..d82ad0492777 100644
--- a/kernel/time/clocksource.c
+++ b/kernel/time/clocksource.c
@@ -125,14 +125,14 @@ static void __clocksource_change_rating(struct
clocksource *cs, int rating);
* Interval: 0.5sec Threshold: 0.0625s
*/
#define WATCHDOG_INTERVAL (HZ >> 1)
-#define WATCHDOG_THRESHOLD (NSEC_PER_SEC >> 4)
+#define WATCHDOG_THRESHOLD (200 * NSEC_PER_USEC)
/*
* Maximum permissible delay between two readouts of the watchdog
* clocksource surrounding a read of the clocksource being validated.
* This delay could be due to SMIs, NMIs, or to VCPU preemptions.
*/
-#define WATCHDOG_MAX_SKEW (100 * NSEC_PER_USEC)
+#define WATCHDOG_MAX_SKEW (50 * NSEC_PER_USEC)
static void clocksource_watchdog_work(struct work_struct *work)
{
--
2.31.1.189.g2e36527f23
[PATCH v9 clocksource 4/6] clocksource: Provide a module parameter to fuzz per-CPU clock checking
Code that checks for clock desynchronization must itself be tested, so
create a new clocksource.inject_delay_shift_percpu= kernel boot parameter
that adds or subtracts a large value from the check read, using the
specified bit of the CPU ID to determine whether to add or to subtract.
Cc: John Stultz
Cc: Thomas Gleixner
Cc: Stephen Boyd
Cc: Jonathan Corbet
Cc: Mark Rutland
Cc: Marc Zyngier
Cc: Andi Kleen
Reported-by: Chris Mason
[ paulmck: Apply Randy Dunlap feedback. ]
Signed-off-by: Paul E. McKenney
---
Documentation/admin-guide/kernel-parameters.txt | 16
kernel/time/clocksource.c | 10 +-
2 files changed, 25 insertions(+), 1 deletion(-)
diff --git a/Documentation/admin-guide/kernel-parameters.txt
b/Documentation/admin-guide/kernel-parameters.txt
index 7fff95bd5504..03a8c88a6bb9 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -599,6 +599,22 @@
will be five delay-free reads followed by three
delayed reads.
+ clocksource.inject_delay_shift_percpu= [KNL]
+ Clocksource delay injection partitions the CPUs
+ into two sets, one whose clocks are moved ahead
+ and the other whose clocks are moved behind.
+ This kernel parameter selects the CPU-number
+ bit that determines which of these two sets the
+ corresponding CPU is placed into. For example,
+ setting this parameter to the value 4 will result
+ in the first set containing alternating groups
+ of 16 CPUs whose clocks are moved ahead, while
+ the second set will contain the rest of the CPUs,
+ whose clocks are moved behind.
+
+ The default value of -1 disables this type of
+ error injection.
+
clocksource.max_read_retries= [KNL]
Number of clocksource_watchdog() retries due to
external delays before the clock will be marked
diff --git a/kernel/time/clocksource.c b/kernel/time/clocksource.c
index ee33f14be44d..edcff9fc3f44 100644
--- a/kernel/time/clocksource.c
+++ b/kernel/time/clocksource.c
@@ -196,6 +196,8 @@ static ulong inject_delay_period;
module_param(inject_delay_period, ulong, 0644);
static ulong inject_delay_repeat = 1;
module_param(inject_delay_repeat, ulong, 0644);
+static int inject_delay_shift_percpu = -1;
+module_param(inject_delay_shift_percpu, int, 0644);
static ulong max_read_retries = 3;
module_param(max_read_retries, ulong, 0644);
@@ -252,8 +254,14 @@ static cpumask_t cpus_behind;
static void clocksource_verify_one_cpu(void *csin)
{
struct clocksource *cs = (struct clocksource *)csin;
+ s64 delta = 0;
+ int sign;
- csnow_mid = cs->read(cs);
+ if (inject_delay_shift_percpu >= 0) {
+ sign = ((smp_processor_id() >> inject_delay_shift_percpu) &
0x1) * 2 - 1;
+ delta = sign * NSEC_PER_SEC;
+ }
+ csnow_mid = cs->read(cs) + delta;
}
static void clocksource_verify_percpu(struct clocksource *cs)
--
2.31.1.189.g2e36527f23
[PATCH v9 clocksource 3/6] clocksource: Check per-CPU clock synchronization when marked unstable
Some sorts of per-CPU clock sources have a history of going out of
synchronization with each other. However, this problem has purportedy
been solved in the past ten years. Except that it is all too possible
that the problem has instead simply been made less likely, which might
mean that some of the occasional "Marking clocksource 'tsc' as unstable"
messages might be due to desynchronization. How would anyone know?
Therefore apply CPU-to-CPU synchronization checking to newly unstable
clocksource that are marked with the new CLOCK_SOURCE_VERIFY_PERCPU flag.
Lists of desynchronized CPUs are printed, with the caveat that if it
is the reporting CPU that is itself desynchronized, it will appear that
all the other clocks are wrong. Just like in real life.
Cc: John Stultz
Cc: Thomas Gleixner
Cc: Stephen Boyd
Cc: Jonathan Corbet
Cc: Mark Rutland
Cc: Marc Zyngier
Cc: Andi Kleen
Reported-by: Chris Mason
[ paulmck: Add "static" to clocksource_verify_one_cpu() per kernel test robot
feedback. ]
[ paulmck: Apply Thomas Gleixner feedback. ]
Signed-off-by: Paul E. McKenney
---
arch/x86/kernel/tsc.c | 3 +-
include/linux/clocksource.h | 2 +-
kernel/time/clocksource.c | 60 +
3 files changed, 63 insertions(+), 2 deletions(-)
diff --git a/arch/x86/kernel/tsc.c b/arch/x86/kernel/tsc.c
index f70dffc2771f..56289170753c 100644
--- a/arch/x86/kernel/tsc.c
+++ b/arch/x86/kernel/tsc.c
@@ -1151,7 +1151,8 @@ static struct clocksource clocksource_tsc = {
.mask = CLOCKSOURCE_MASK(64),
.flags = CLOCK_SOURCE_IS_CONTINUOUS |
CLOCK_SOURCE_VALID_FOR_HRES |
- CLOCK_SOURCE_MUST_VERIFY,
+ CLOCK_SOURCE_MUST_VERIFY |
+ CLOCK_SOURCE_VERIFY_PERCPU,
.vdso_clock_mode= VDSO_CLOCKMODE_TSC,
.enable = tsc_cs_enable,
.resume = tsc_resume,
diff --git a/include/linux/clocksource.h b/include/linux/clocksource.h
index 86d143db6523..83a3ebff7456 100644
--- a/include/linux/clocksource.h
+++ b/include/linux/clocksource.h
@@ -131,7 +131,7 @@ struct clocksource {
#define CLOCK_SOURCE_UNSTABLE 0x40
#define CLOCK_SOURCE_SUSPEND_NONSTOP 0x80
#define CLOCK_SOURCE_RESELECT 0x100
-
+#define CLOCK_SOURCE_VERIFY_PERCPU 0x200
/* simplify initialization of mask field */
#define CLOCKSOURCE_MASK(bits) GENMASK_ULL((bits) - 1, 0)
diff --git a/kernel/time/clocksource.c b/kernel/time/clocksource.c
index facce83fcb4a..ee33f14be44d 100644
--- a/kernel/time/clocksource.c
+++ b/kernel/time/clocksource.c
@@ -245,6 +245,60 @@ static bool cs_watchdog_read(struct clocksource *cs, u64
*csnow, u64 *wdnow)
return false;
}
+static u64 csnow_mid;
+static cpumask_t cpus_ahead;
+static cpumask_t cpus_behind;
+
+static void clocksource_verify_one_cpu(void *csin)
+{
+ struct clocksource *cs = (struct clocksource *)csin;
+
+ csnow_mid = cs->read(cs);
+}
+
+static void clocksource_verify_percpu(struct clocksource *cs)
+{
+ int64_t cs_nsec, cs_nsec_max = 0, cs_nsec_min = LLONG_MAX;
+ u64 csnow_begin, csnow_end;
+ int cpu, testcpu;
+ s64 delta;
+
+ cpumask_clear(_ahead);
+ cpumask_clear(_behind);
+ preempt_disable();
+ testcpu = smp_processor_id();
+ pr_warn("Checking clocksource %s synchronization from CPU %d.\n",
cs->name, testcpu);
+ for_each_online_cpu(cpu) {
+ if (cpu == testcpu)
+ continue;
+ csnow_begin = cs->read(cs);
+ smp_call_function_single(cpu, clocksource_verify_one_cpu, cs,
1);
+ csnow_end = cs->read(cs);
+ delta = (s64)((csnow_mid - csnow_begin) & cs->mask);
+ if (delta < 0)
+ cpumask_set_cpu(cpu, _behind);
+ delta = (csnow_end - csnow_mid) & cs->mask;
+ if (delta < 0)
+ cpumask_set_cpu(cpu, _ahead);
+ delta = clocksource_delta(csnow_end, csnow_begin, cs->mask);
+ cs_nsec = clocksource_cyc2ns(delta, cs->mult, cs->shift);
+ if (cs_nsec > cs_nsec_max)
+ cs_nsec_max = cs_nsec;
+ if (cs_nsec < cs_nsec_min)
+ cs_nsec_min = cs_nsec;
+ }
+ preempt_enable();
+ if (!cpumask_empty(_ahead))
+ pr_warn("CPUs %*pbl ahead of CPU %d for clocksource
%s.\n",
+ cpumask_pr_args(_ahead), testcpu, cs->name);
+ if (!cpumask_empty(_behind))
+ pr_warn("CPUs %*pbl behind CPU %d for clocksource
%s.\n",
+ cpumask_pr_args(_behind), testcpu, cs->name);
+ if (!cpumask_empty(_ahead) || !cpumask_empty(_behind))
+ pr_warn("CPU %d check durations %lldns -
[PATCH v9 clocksource 1/6] clocksource: Provide module parameters to inject delays in watchdog
When the clocksource watchdog marks a clock as unstable, this might be due
to that clock being unstable or it might be due to delays that happen to
occur between the reads of the two clocks. Yes, interrupts are disabled
across those two reads, but there are no shortage of things that can
delay interrupts-disabled regions of code ranging from SMI handlers to
vCPU preemption. It would be good to have some indication as to why
the clock was marked unstable.
The first step is a way of injecting such delays. Therefore, provide
clocksource.inject_delay_freq and clocksource.inject_delay_run kernel boot
parameters that specify that sufficient delay be injected to cause the
clocksource_watchdog() function to mark a clock unstable. This delay is
injected every Nth set of M calls to clocksource_watchdog(), where N is
the value specified for the inject_delay_freq boot parameter and M is the
value specified for the inject_delay_run boot parameter. Values of zero
or less for either parameter disable delay injection, and the default for
clocksource.inject_delay_freq is zero, that is, disabled. The default for
clocksource.inject_delay_run is the value one, that is single-call runs.
This facility is intended for diagnostic use only, and should be avoided
on production systems.
Cc: John Stultz
Cc: Thomas Gleixner
Cc: Stephen Boyd
Cc: Jonathan Corbet
Cc: Mark Rutland
Cc: Marc Zyngier
Cc: Andi Kleen
[ paulmck: Apply Rik van Riel feedback. ]
[ paulmck: Apply Thomas Gleixner feedback. ]
Reported-by: Chris Mason
Signed-off-by: Paul E. McKenney
---
.../admin-guide/kernel-parameters.txt | 16 +
kernel/time/clocksource.c | 23 +++
2 files changed, 39 insertions(+)
diff --git a/Documentation/admin-guide/kernel-parameters.txt
b/Documentation/admin-guide/kernel-parameters.txt
index 04545725f187..4a372037b49f 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -583,6 +583,22 @@
loops can be debugged more effectively on production
systems.
+ clocksource.inject_delay_period= [KNL]
+ Number of calls to clocksource_watchdog() before
+ delays are injected between reads from the
+ two clocksources. Values of zero disable this
+ delay injection. These delays can cause clocks
+ to be marked unstable, so use of this parameter
+ should therefore be avoided on production systems.
+ Defaults to zero (disabled).
+
+ clocksource.inject_delay_repeat= [KNL]
+ Number of repeated clocksource_watchdog() delay
+ injections per period. If inject_delay_period
+ is five and inject_delay_repeat is three, there
+ will be five delay-free reads followed by three
+ delayed reads.
+
clearcpuid=BITNUM[,BITNUM...] [X86]
Disable CPUID feature X for the kernel. See
arch/x86/include/asm/cpufeatures.h for the valid bit
diff --git a/kernel/time/clocksource.c b/kernel/time/clocksource.c
index cce484a2cc7c..d77700c45f4e 100644
--- a/kernel/time/clocksource.c
+++ b/kernel/time/clocksource.c
@@ -14,6 +14,7 @@
#include /* for spin_unlock_irq() using preempt_count() m68k */
#include
#include
+#include
#include "tick-internal.h"
#include "timekeeping_internal.h"
@@ -184,6 +185,27 @@ void clocksource_mark_unstable(struct clocksource *cs)
spin_unlock_irqrestore(_lock, flags);
}
+static ulong inject_delay_period;
+module_param(inject_delay_period, ulong, 0644);
+static ulong inject_delay_repeat = 1;
+module_param(inject_delay_repeat, ulong, 0644);
+
+static void clocksource_watchdog_inject_delay(void)
+{
+ static unsigned int invocations = 1, injections;
+
+ if (!inject_delay_period || !inject_delay_repeat)
+ return;
+ if (!(invocations % inject_delay_period)) {
+ pr_warn("%s(): Injecting delay.\n", __func__);
+ mdelay(2 * WATCHDOG_THRESHOLD / NSEC_PER_MSEC);
+ if (++injections < inject_delay_repeat)
+ return;
+ injections = 0;
+ }
+ invocations++;
+}
+
static void clocksource_watchdog(struct timer_list *unused)
{
struct clocksource *cs;
@@ -208,6 +230,7 @@ static void clocksource_watchdog(struct timer_list *unused)
local_irq_disable();
csnow = cs->read(cs);
+ clocksource_watchdog_inject_delay();
wdnow = watchdog->read(watchdog);
local_irq_enable();
--
2.31.1.189.g2e36527f23
[PATCH v9 clocksource 0/6] Do not mark clocks unstable due to delays for v5.13
Hello! If there is a sufficient delay between reading the watchdog clock and the clock under test, the clock under test will be marked unstable through no fault of its own. This series checks for this, doing limited retries to get a good set of clock reads. If the clock is marked unstable and is marked as being per-CPU, cross-CPU synchronization is checked. This series also provides delay injection, which may be enabled via kernel boot parameters to test the checking for delays. Note that "sufficient delay" can be provided by SMIs, NMIs, and of course vCPU preemption. 1. Provide module parameters to inject delays in watchdog. 2. Retry clock read if long delays detected. 3. Check per-CPU clock synchronization when marked unstable. 4. Provide a module parameter to fuzz per-CPU clock checking. 5. Limit number of CPUs checked for clock synchronization. 6. Reduce the clock-skew limit to 200us and the maximum permissible clock read delay to 50us. Changes since v8, based on Thomas Gleixner feedback: o Reduced clock-skew threshold to 200us and delay limit to 50us. o Split out a cs_watchdog_read() function. o Removed the pointless CLOCK_SOURCE_VERIFY_PERCPU from kvm_clock. o Initialized cs_nsec_max and cs_nsec_min to avoid firsttime checks. Changes since v7, based on Thomas Gleixner feedback: o Fix embarrassing git-format-patch operator error. o Merge pairwise clock-desynchronization checking into the checking of per-CPU clock synchronization when marked unstable. o Do selective per-CPU checking rather than blindly checking all CPUs. Provide a clocksource.verify_n_cpus kernel boot parameter to control this behavior, with the value -1 choosing the old check-all-CPUs behavior. The default is to randomly check 8 CPUs. o Fix the clock-desynchronization checking to avoid a potential use-after-free error for dynamically allocated clocksource structures. o Remove redundance "wdagain_nsec < 0" from clocksource_watchdog() clocksource skew checking. o Update commit logs and do code-style updates. Changes since v5: o Rebased to v5.12-rc5. Changes since v4: o Rebased to v5.12-rc1. Changes since v3: o Rebased to v5.11. o Apply Randy Dunlap feedback. Changes since v2: o Rebased to v5.11-rc6. o Updated Cc: list. Changes since v1: o Applied feedback from Rik van Riel. o Rebased to v5.11-rc3. o Stripped "RFC" from the subject lines. Thanx, Paul Documentation/admin-guide/kernel-parameters.txt | 32 +++ b/Documentation/admin-guide/kernel-parameters.txt | 16 + b/arch/x86/kernel/tsc.c |3 b/include/linux/clocksource.h |2 b/kernel/time/clocksource.c | 23 ++ kernel/time/clocksource.c | 201 -- 6 files changed, 263 insertions(+), 14 deletions(-)
Re: [RFC v1 PATCH 1/3] drivers: soc: add support for soc_device_match returning -EPROBE_DEFER
First comment overall for the whole serie:
Since it is the solution I had suggested when I reported the problem[1]
I have no qualm on the approach, comments for individual patches
follow.
[1] http://lore.kernel.org/r/YGGZJjAxA1IO+/v...@atmark-techno.com
Alice Guo (OSS) wrote on Mon, Apr 19, 2021 at 12:27:20PM +0800:
> From: Alice Guo
>
> In i.MX8M boards, the registration of SoC device is later than caam
> driver which needs it. Caam driver needs soc_device_match to provide
> -EPROBE_DEFER when no SoC device is registered and no
> early_soc_dev_attr.
This patch should be last in the set: you can't have soc_device_match
return an error before its callers handle it.
> Signed-off-by: Alice Guo
As the one who reported the problem I would have been appreciated being
at least added to Ccs... I only happened to notice you posted this by
chance.
There is also not a single Fixes tag -- I believe this commit should
have Fixes: 7d981405d0fd ("soc: imx8m: change to use platform driver")
but I'm not sure how such tags should be handled in case of multiple
patches fixing something.
--
Dominique
[RFC v1 PATCH 3/3] driver: update all the code that use soc_device_match
From: Alice Guo
Update all the code that use soc_device_match because add support for
soc_device_match returning -EPROBE_DEFER.
Signed-off-by: Alice Guo
---
drivers/bus/ti-sysc.c | 2 +-
drivers/clk/renesas/r8a7795-cpg-mssr.c| 4 +++-
drivers/clk/renesas/rcar-gen2-cpg.c | 2 +-
drivers/clk/renesas/rcar-gen3-cpg.c | 2 +-
drivers/dma/fsl-dpaa2-qdma/dpaa2-qdma.c | 7 ++-
drivers/dma/ti/k3-psil.c | 3 +++
drivers/dma/ti/k3-udma.c | 2 +-
drivers/gpu/drm/bridge/nwl-dsi.c | 2 +-
drivers/gpu/drm/meson/meson_drv.c | 4 +++-
drivers/gpu/drm/omapdrm/dss/dispc.c | 2 +-
drivers/gpu/drm/omapdrm/dss/dpi.c | 4 +++-
drivers/gpu/drm/omapdrm/dss/dsi.c | 3 +++
drivers/gpu/drm/omapdrm/dss/dss.c | 3 +++
drivers/gpu/drm/omapdrm/dss/hdmi4_core.c | 3 +++
drivers/gpu/drm/omapdrm/dss/venc.c| 4 +++-
drivers/gpu/drm/omapdrm/omap_drv.c| 3 +++
drivers/gpu/drm/rcar-du/rcar_du_crtc.c| 4 +++-
drivers/gpu/drm/rcar-du/rcar_lvds.c | 2 +-
drivers/gpu/drm/tidss/tidss_dispc.c | 4 +++-
drivers/iommu/ipmmu-vmsa.c| 7 +--
drivers/media/platform/rcar-vin/rcar-core.c | 2 +-
drivers/media/platform/rcar-vin/rcar-csi2.c | 2 +-
drivers/media/platform/vsp1/vsp1_uif.c| 4 +++-
drivers/mmc/host/renesas_sdhi_core.c | 2 +-
drivers/mmc/host/renesas_sdhi_internal_dmac.c | 2 +-
drivers/mmc/host/sdhci-of-esdhc.c | 21 ++-
drivers/mmc/host/sdhci-omap.c | 2 +-
drivers/mmc/host/sdhci_am654.c| 2 +-
drivers/net/ethernet/renesas/ravb_main.c | 4 +++-
drivers/net/ethernet/ti/am65-cpsw-nuss.c | 2 +-
drivers/net/ethernet/ti/cpsw.c| 2 +-
drivers/net/ethernet/ti/cpsw_new.c| 2 +-
drivers/phy/ti/phy-omap-usb2.c| 4 +++-
drivers/pinctrl/renesas/core.c| 2 +-
drivers/pinctrl/renesas/pfc-r8a7790.c | 5 -
drivers/pinctrl/renesas/pfc-r8a7794.c | 5 -
drivers/soc/fsl/dpio/dpio-driver.c| 13
drivers/soc/renesas/r8a774c0-sysc.c | 5 -
drivers/soc/renesas/r8a7795-sysc.c| 2 +-
drivers/soc/renesas/r8a77990-sysc.c | 5 -
drivers/soc/ti/k3-ringacc.c | 2 +-
drivers/staging/mt7621-pci/pci-mt7621.c | 2 +-
drivers/thermal/rcar_gen3_thermal.c | 4 +++-
drivers/thermal/ti-soc-thermal/ti-bandgap.c | 10 +++--
drivers/usb/gadget/udc/renesas_usb3.c | 2 +-
drivers/usb/host/ehci-platform.c | 4 +++-
drivers/usb/host/xhci-rcar.c | 2 +-
drivers/watchdog/renesas_wdt.c| 2 +-
48 files changed, 131 insertions(+), 52 deletions(-)
diff --git a/drivers/bus/ti-sysc.c b/drivers/bus/ti-sysc.c
index 5fae60f8c135..00c59aa217c1 100644
--- a/drivers/bus/ti-sysc.c
+++ b/drivers/bus/ti-sysc.c
@@ -2909,7 +2909,7 @@ static int sysc_init_soc(struct sysc *ddata)
}
match = soc_device_match(sysc_soc_feat_match);
- if (!match)
+ if (!match || IS_ERR(match))
return 0;
if (match->data)
diff --git a/drivers/clk/renesas/r8a7795-cpg-mssr.c
b/drivers/clk/renesas/r8a7795-cpg-mssr.c
index c32d2c678046..90a18336a4c3 100644
--- a/drivers/clk/renesas/r8a7795-cpg-mssr.c
+++ b/drivers/clk/renesas/r8a7795-cpg-mssr.c
@@ -439,6 +439,7 @@ static const unsigned int r8a7795es2_mod_nullify[]
__initconst = {
static int __init r8a7795_cpg_mssr_init(struct device *dev)
{
+ const struct soc_device_attribute *match;
const struct rcar_gen3_cpg_pll_config *cpg_pll_config;
u32 cpg_mode;
int error;
@@ -453,7 +454,8 @@ static int __init r8a7795_cpg_mssr_init(struct device *dev)
return -EINVAL;
}
- if (soc_device_match(r8a7795es1)) {
+ match = soc_device_match(r8a7795es1);
+ if (!IS_ERR(match) && match) {
cpg_core_nullify_range(r8a7795_core_clks,
ARRAY_SIZE(r8a7795_core_clks),
R8A7795_CLK_S0D2, R8A7795_CLK_S0D12);
diff --git a/drivers/clk/renesas/rcar-gen2-cpg.c
b/drivers/clk/renesas/rcar-gen2-cpg.c
index edae874fa2b6..946f82634d23 100644
--- a/drivers/clk/renesas/rcar-gen2-cpg.c
+++ b/drivers/clk/renesas/rcar-gen2-cpg.c
@@ -383,7 +383,7 @@ int __init rcar_gen2_cpg_init(const struct
rcar_gen2_cpg_pll_config *config,
cpg_pll0_div = pll0_div;
cpg_mode = mode;
attr = soc_device_match(cpg_quirks_match);
- if (attr)
+ if (!IS_ERR(attr) && attr)
cpg_quirks = (uintptr_t)attr->data;
pr_debug("%s: mode = 0x%x quirks = 0x%x\n", __func__, mode, cpg_quirks);
diff --git a/drivers/clk/renesas/rcar-gen3-cpg.c
[RFC v1 PATCH 2/3] caam: add defer probe when the caam driver cannot identify SoC
From: Alice Guo
When imx8_soc_info_driver uses module_platform_driver() to regitser
itself, the caam driver cannot identify the SoC in the machine because
the SoC driver is probed later, so that add return -EPROBE_DEFER.
Signed-off-by: Alice Guo
---
drivers/crypto/caam/ctrl.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/crypto/caam/ctrl.c b/drivers/crypto/caam/ctrl.c
index ca0361b2dbb0..d08f8cc4131f 100644
--- a/drivers/crypto/caam/ctrl.c
+++ b/drivers/crypto/caam/ctrl.c
@@ -635,6 +635,9 @@ static int caam_probe(struct platform_device *pdev)
nprop = pdev->dev.of_node;
imx_soc_match = soc_device_match(caam_imx_soc_table);
+ if (IS_ERR(imx_soc_match))
+ return PTR_ERR(imx_soc_match);
+
caam_imx = (bool)imx_soc_match;
if (imx_soc_match) {
--
2.17.1
[RFC v1 PATCH 1/3] drivers: soc: add support for soc_device_match returning -EPROBE_DEFER
From: Alice Guo
In i.MX8M boards, the registration of SoC device is later than caam
driver which needs it. Caam driver needs soc_device_match to provide
-EPROBE_DEFER when no SoC device is registered and no
early_soc_dev_attr.
Signed-off-by: Alice Guo
---
drivers/base/soc.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/base/soc.c b/drivers/base/soc.c
index 0af5363a582c..12a22f9cf5c8 100644
--- a/drivers/base/soc.c
+++ b/drivers/base/soc.c
@@ -110,6 +110,7 @@ static void soc_release(struct device *dev)
}
static struct soc_device_attribute *early_soc_dev_attr;
+static bool soc_dev_attr_init_done = false;
struct soc_device *soc_device_register(struct soc_device_attribute
*soc_dev_attr)
{
@@ -157,6 +158,7 @@ struct soc_device *soc_device_register(struct
soc_device_attribute *soc_dev_attr
return ERR_PTR(ret);
}
+ soc_dev_attr_init_done = true;
return soc_dev;
out3:
@@ -246,6 +248,9 @@ const struct soc_device_attribute *soc_device_match(
if (!matches)
return NULL;
+ if (!soc_dev_attr_init_done && !early_soc_dev_attr)
+ return ERR_PTR(-EPROBE_DEFER);
+
while (!ret) {
if (!(matches->machine || matches->family ||
matches->revision || matches->soc_id))
--
2.17.1
[RFC v1 PATCH 0/3] support soc_device_match to return -EPROBE_DEFER
From: Alice Guo In patch "soc: imx8m: change to use platform driver", change soc-imx8m.c to use module platform driver and use NVMEM APIs to ocotp register, the reason is that directly reading ocotp egister causes kexec kernel hang because kernel will disable unused clks after kernel boots up. This patch makes the SoC driver ready. This patch makes the SoC driver ready later than before, and causes device depends on soc_device_match() for initialization are affected, resulting in kernel boot error. CAAM driver is one of these affected drivers. It uses soc_device_match() to find the first matching entry of caam_imx_soc_table, if none of them match, the next instruction will be executed without any processing because CAAM driver is used not only on i.MX and LS, but also PPC and Vybrid. We hope that soc_device_match() could support to return -EPROBE_DEFER(or some other error code, e.g. -ENODEV, but not NULL) in case of “no SoC device registered” to SoC bus. We tried it and updated all the code that is using soc_device_match() throughout the tree. Alice Guo (3): drivers: soc: add support for soc_device_match returning -EPROBE_DEFER caam: add defer probe when the caam driver cannot identify SoC driver: update all the code that use soc_device_match drivers/base/soc.c| 5 + drivers/bus/ti-sysc.c | 2 +- drivers/clk/renesas/r8a7795-cpg-mssr.c| 4 +++- drivers/clk/renesas/rcar-gen2-cpg.c | 2 +- drivers/clk/renesas/rcar-gen3-cpg.c | 2 +- drivers/crypto/caam/ctrl.c| 3 +++ drivers/dma/fsl-dpaa2-qdma/dpaa2-qdma.c | 7 ++- drivers/dma/ti/k3-psil.c | 3 +++ drivers/dma/ti/k3-udma.c | 2 +- drivers/gpu/drm/bridge/nwl-dsi.c | 2 +- drivers/gpu/drm/meson/meson_drv.c | 4 +++- drivers/gpu/drm/omapdrm/dss/dispc.c | 2 +- drivers/gpu/drm/omapdrm/dss/dpi.c | 4 +++- drivers/gpu/drm/omapdrm/dss/dsi.c | 3 +++ drivers/gpu/drm/omapdrm/dss/dss.c | 3 +++ drivers/gpu/drm/omapdrm/dss/hdmi4_core.c | 3 +++ drivers/gpu/drm/omapdrm/dss/venc.c| 4 +++- drivers/gpu/drm/omapdrm/omap_drv.c| 3 +++ drivers/gpu/drm/rcar-du/rcar_du_crtc.c| 4 +++- drivers/gpu/drm/rcar-du/rcar_lvds.c | 2 +- drivers/gpu/drm/tidss/tidss_dispc.c | 4 +++- drivers/iommu/ipmmu-vmsa.c| 7 +-- drivers/media/platform/rcar-vin/rcar-core.c | 2 +- drivers/media/platform/rcar-vin/rcar-csi2.c | 2 +- drivers/media/platform/vsp1/vsp1_uif.c| 4 +++- drivers/mmc/host/renesas_sdhi_core.c | 2 +- drivers/mmc/host/renesas_sdhi_internal_dmac.c | 2 +- drivers/mmc/host/sdhci-of-esdhc.c | 21 ++- drivers/mmc/host/sdhci-omap.c | 2 +- drivers/mmc/host/sdhci_am654.c| 2 +- drivers/net/ethernet/renesas/ravb_main.c | 4 +++- drivers/net/ethernet/ti/am65-cpsw-nuss.c | 2 +- drivers/net/ethernet/ti/cpsw.c| 2 +- drivers/net/ethernet/ti/cpsw_new.c| 2 +- drivers/phy/ti/phy-omap-usb2.c| 4 +++- drivers/pinctrl/renesas/core.c| 2 +- drivers/pinctrl/renesas/pfc-r8a7790.c | 5 - drivers/pinctrl/renesas/pfc-r8a7794.c | 5 - drivers/soc/fsl/dpio/dpio-driver.c| 13 drivers/soc/renesas/r8a774c0-sysc.c | 5 - drivers/soc/renesas/r8a7795-sysc.c| 2 +- drivers/soc/renesas/r8a77990-sysc.c | 5 - drivers/soc/ti/k3-ringacc.c | 2 +- drivers/staging/mt7621-pci/pci-mt7621.c | 2 +- drivers/thermal/rcar_gen3_thermal.c | 4 +++- drivers/thermal/ti-soc-thermal/ti-bandgap.c | 10 +++-- drivers/usb/gadget/udc/renesas_usb3.c | 2 +- drivers/usb/host/ehci-platform.c | 4 +++- drivers/usb/host/xhci-rcar.c | 2 +- drivers/watchdog/renesas_wdt.c| 2 +- 50 files changed, 139 insertions(+), 52 deletions(-) -- 2.17.1
[PATCH] sched/isolation: reconcile rcu_nocbs= and nohz_full=
We have a mismatch between RCU and isolation -- in relation to what is
considered the maximum valid CPU number.
This matters because nohz_full= and rcu_nocbs= are joined at the hip; in
fact the former will enforce the latter. So we don't want a CPU mask to
be valid for one and denied for the other.
The difference 1st appeared as of v4.15; further details are below.
As it is confusing to anyone who isn't looking at the code regularly, a
reminder is in order; three values exist here:
CONFIG_NR_CPUS - compiled in maximum cap on number of CPUs supported.
nr_cpu_ids - possible # of CPUs (typically reflects what ACPI says)
cpus_present- actual number of present/detected/installed CPUs.
For this example, I'll refer to NR_CPUS=64 from "make defconfig" and
nr_cpu_ids=6 for ACPI reporting on a board that could run a six core,
and present=4 for a quad that is physically in the socket. From dmesg:
smpboot: Allowing 6 CPUs, 2 hotplug CPUs
setup_percpu: NR_CPUS:64 nr_cpumask_bits:64 nr_cpu_ids:6 nr_node_ids:1
rcu: RCU restricting CPUs from NR_CPUS=64 to nr_cpu_ids=6.
smp: Brought up 1 node, 4 CPUs
And from userspace, see:
paul@trash:/sys/devices/system/cpu$ cat present
0-3
paul@trash:/sys/devices/system/cpu$ cat possible
0-5
paul@trash:/sys/devices/system/cpu$ cat kernel_max
63
Everything is fine if we boot 5x5 for rcu/nohz:
Command line: BOOT_IMAGE=/boot/bzImage nohz_full=2-5 rcu_nocbs=2-5
root=/dev/sda1 ro
NO_HZ: Full dynticks CPUs: 2-5.
rcu: Offload RCU callbacks from CPUs: 2-5.
..even though there is no CPU 4 or 5. Both RCU and nohz_full are OK.
Now we push that > 6 but less than NR_CPU and with 15x15 we get:
Command line: BOOT_IMAGE=/boot/bzImage rcu_nocbs=2-15 nohz_full=2-15
root=/dev/sda1 ro
rcu: Note: kernel parameter 'rcu_nocbs=', 'nohz_full', or 'isolcpus='
contains nonexistent CPUs.
rcu: Offload RCU callbacks from CPUs: 2-5.
These are both functionally equivalent, as we are only changing flags on
phantom CPUs that don't exist, but note the kernel interpretation changes.
And worse, it only changes for one of the two - which is the problem.
RCU doesn't care if you want to restrict the flags on phantom CPUs but
clearly nohz_full does after this change from v4.15 (edb9382175c3):
- if (cpulist_parse(str, non_housekeeping_mask) < 0) {
- pr_warn("Housekeeping: Incorrect nohz_full cpumask\n");
+ err = cpulist_parse(str, non_housekeeping_mask);
+ if (err < 0 || cpumask_last(non_housekeeping_mask) >= nr_cpu_ids) {
+ pr_warn("Housekeeping: nohz_full= or isolcpus= incorrect CPU
range\n");
To be clear, the sanity check on "possible" (nr_cpu_ids) is new here.
The goal was reasonable ; not wanting housekeeping to land on a
not-possible CPU, but note two things:
1) this is an exclusion list, not an inclusion list; we are tracking
non_housekeeping CPUs; not ones who are explicitly assigned housekeeping
2) we went one further in 9219565aa890 - ensuring that housekeeping was
sanity checking against present and not just possible CPUs.
To be clear, this means the check added in v4.15 is doubly redundant.
And more importantly, overly strict/restrictive.
We care now, because the bitmap boot arg parsing now knows that a value
of "N" is NR_CPUS; the size of the bitmap, but the bitmap code doesn't
know anything about the subtleties of our max/possible/present CPU
specifics as outlined above.
So drop the check added in v4.15 (edb9382175c3) and make RCU and
nohz_full both in alignment again on NR_CPUS so "N" works for both,
and then they can fall back to nr_cpu_ids internally just as before.
Command line: BOOT_IMAGE=/boot/bzImage nohz_full=2-N rcu_nocbs=2-N
root=/dev/sda1 ro
NO_HZ: Full dynticks CPUs: 2-5.
rcu: Offload RCU callbacks from CPUs: 2-5.
As shown above, with this change, RCU and nohz_full are in sync, even
with the use of the "N" placeholder. Same result is achieved with "15".
Cc: Ingo Molnar
Cc: Peter Zijlstra
Cc: Paul E. McKenney
Cc: Frederic Weisbecker
Signed-off-by: Paul Gortmaker
diff --git a/kernel/sched/isolation.c b/kernel/sched/isolation.c
index 5a6ea03f9882..7f06eaf12818 100644
--- a/kernel/sched/isolation.c
+++ b/kernel/sched/isolation.c
@@ -81,11 +81,9 @@ static int __init housekeeping_setup(char *str, enum
hk_flags flags)
{
cpumask_var_t non_housekeeping_mask;
cpumask_var_t tmp;
- int err;
alloc_bootmem_cpumask_var(_housekeeping_mask);
- err = cpulist_parse(str, non_housekeeping_mask);
- if (err < 0 || cpumask_last(non_housekeeping_mask) >= nr_cpu_ids) {
+ if (cpulist_parse(str, non_housekeeping_mask) < 0) {
pr_warn("Housekeeping: nohz_full= or isolcpus= incorrect CPU
range\n");
free_bootmem_cpumask_var(non_housekeeping_mask);
return 0;
--
2.25.1
Re: [PATCH v3] powerpc: fix EDEADLOCK redefinition error in uapi/asm/errno.h
On Thu, 17 Sep 2020 06:54:37 -0700, Tony Ambardar wrote: > A few archs like powerpc have different errno.h values for macros > EDEADLOCK and EDEADLK. In code including both libc and linux versions of > errno.h, this can result in multiple definitions of EDEADLOCK in the > include chain. Definitions to the same value (e.g. seen with mips) do > not raise warnings, but on powerpc there are redefinitions changing the > value, which raise warnings and errors (if using "-Werror"). > > [...] Applied to powerpc/next. [1/1] powerpc: fix EDEADLOCK redefinition error in uapi/asm/errno.h https://git.kernel.org/powerpc/c/7de21e679e6a789f3729e8402bc440b623a28eae cheers
Re: [PATCH] windfarm: make symbol 'wf_thread' static
On Wed, 7 Apr 2021 20:57:38 +0800, Yu Kuai wrote: > The sparse tool complains as follows: > > drivers/macintosh/windfarm_core.c:59:20: warning: > symbol 'wf_thread' was not declared. Should it be static? > > This symbol is not used outside of windfarm_core.c, so this > commit marks it static. Applied to powerpc/next. [1/1] windfarm: make symbol 'wf_thread' static https://git.kernel.org/powerpc/c/4204ecd598cb0a044e6fcfd48e569080955347f4 cheers
Re: [PATCH] powerpc/smp: Make some symbols static
On Wed, 7 Apr 2021 20:59:03 +0800, Yu Kuai wrote: > The sparse tool complains as follows: > > arch/powerpc/kernel/smp.c:86:1: warning: > symbol '__pcpu_scope_cpu_coregroup_map' was not declared. Should it be > static? > arch/powerpc/kernel/smp.c:125:1: warning: > symbol '__pcpu_scope_thread_group_l1_cache_map' was not declared. Should it > be static? > arch/powerpc/kernel/smp.c:132:1: warning: > symbol '__pcpu_scope_thread_group_l2_cache_map' was not declared. Should it > be static? > > [...] Applied to powerpc/next. [1/1] powerpc/smp: Make some symbols static https://git.kernel.org/powerpc/c/078277acbd7c3fdb25c01a3cd5b4a1a875a1ab2f cheers
Re: [PATCH] macintosh/windfarm: Make symbol 'pm121_sys_state' static
On Wed, 7 Apr 2021 20:57:12 +0800, Yu Kuai wrote: > The sparse tool complains as follows: > > drivers/macintosh/windfarm_pm121.c:436:24: warning: > symbol 'pm121_sys_state' was not declared. Should it be static? > > This symbol is not used outside of windfarm_pm121.c, so this > commit marks it static. Applied to powerpc/next. [1/1] macintosh/windfarm: Make symbol 'pm121_sys_state' static https://git.kernel.org/powerpc/c/13ddd0e3acf988a98b46800178ae691640b0cd00 cheers
Re: [PATCH] macintosh/via-pmu: Make some symbols static
On Wed, 7 Apr 2021 20:58:03 +0800, Yu Kuai wrote: > The sparse tool complains as follows: > > drivers/macintosh/via-pmu.c:183:5: warning: > symbol 'pmu_cur_battery' was not declared. Should it be static? > drivers/macintosh/via-pmu.c:190:5: warning: > symbol '__fake_sleep' was not declared. Should it be static? > > [...] Applied to powerpc/next. [1/1] macintosh/via-pmu: Make some symbols static https://git.kernel.org/powerpc/c/95d143923379ffb0e706b064305681d44c05ec4b cheers
Re: [PATCH] powerpc/pseries: extract host bridge from pci_bus prior to bus removal
On Thu, 11 Feb 2021 12:24:35 -0600, Tyrel Datwyler wrote: > The pci_bus->bridge reference may no longer be valid after > pci_bus_remove() resulting in passing a bad value to device_unregister() > for the associated bridge device. > > Store the host_bridge reference in a separate variable prior to > pci_bus_remove(). Applied to powerpc/next. [1/1] powerpc/pseries: extract host bridge from pci_bus prior to bus removal https://git.kernel.org/powerpc/c/38d0b1c9cec71e6d0f3bddef0bbce41d05a3e796 cheers
Re: [PATCH v5] powerpc/traps: Enhance readability for trap types
On Wed, 14 Apr 2021 19:00:33 +0800, Xiongwei Song wrote: > Define macros to list ppc interrupt types in interttupt.h, replace the > reference of the trap hex values with these macros. > > Referred the hex numbers in arch/powerpc/kernel/exceptions-64e.S, > arch/powerpc/kernel/exceptions-64s.S, arch/powerpc/kernel/head_*.S, > arch/powerpc/kernel/head_booke.h and arch/powerpc/include/asm/kvm_asm.h. > > [...] Applied to powerpc/next. [1/1] powerpc/traps: Enhance readability for trap types https://git.kernel.org/powerpc/c/7153d4bf0b373428d0393c001019da4d0483fddb cheers
Re: [PATCH -next] powerpc/fadump: make symbol 'rtas_fadump_set_regval' static
On Thu, 8 Apr 2021 14:20:12 +0800, Pu Lehui wrote: > Fix sparse warnings: > > arch/powerpc/platforms/pseries/rtas-fadump.c:250:6: warning: > symbol 'rtas_fadump_set_regval' was not declared. Should it be static? Applied to powerpc/next. [1/1] powerpc/fadump: make symbol 'rtas_fadump_set_regval' static https://git.kernel.org/powerpc/c/59fd366b9bef2d048af763e27cd1622ee5a1dfd4 cheers
Re: [PATCH -next] powerpc/xmon: Make symbol 'spu_inst_dump' static
On Fri, 9 Apr 2021 15:01:51 +0800, Pu Lehui wrote: > Fix sparse warning: > > arch/powerpc/xmon/xmon.c:4216:1: warning: > symbol 'spu_inst_dump' was not declared. Should it be static? > > This symbol is not used outside of xmon.c, so make it static. Applied to powerpc/next. [1/1] powerpc/xmon: Make symbol 'spu_inst_dump' static https://git.kernel.org/powerpc/c/f234ad405a35262ed2d8dd2d29fc633908dce955 cheers
Re: [PATCH -next] powerpc/mce: Make symbol 'mce_ue_event_work' static
On Thu, 8 Apr 2021 11:58:02 +0800, Li Huafei wrote: > The sparse tool complains as follows: > > arch/powerpc/kernel/mce.c:43:1: warning: > symbol 'mce_ue_event_work' was not declared. Should it be static? > > This symbol is not used outside of mce.c, so this commit marks it > static. Applied to powerpc/next. [1/1] powerpc/mce: Make symbol 'mce_ue_event_work' static https://git.kernel.org/powerpc/c/f6f1f48e8b3b242dfa684d6e1b930d239d87533a cheers
Re: [PATCH v3 1/1] powerpc/iommu: Enable remaining IOMMU Pagesizes present in LoPAR
On Thu, 8 Apr 2021 17:19:16 -0300, Leonardo Bras wrote: > According to LoPAR, ibm,query-pe-dma-window output named "IO Page Sizes" > will let the OS know all possible pagesizes that can be used for creating a > new DDW. > > Currently Linux will only try using 3 of the 8 available options: > 4K, 64K and 16M. According to LoPAR, Hypervisor may also offer 32M, 64M, > 128M, 256M and 16G. > > [...] Applied to powerpc/next. [1/1] powerpc/iommu: Enable remaining IOMMU Pagesizes present in LoPAR https://git.kernel.org/powerpc/c/472724111f0f72042deb6a9dcee9578e5398a1a1 cheers
Re: [PATCH -next] powerpc/perf/hv-24x7: Make some symbols static
On Fri, 9 Apr 2021 17:01:24 +0800, Bixuan Cui wrote: > The sparse tool complains as follows: > > arch/powerpc/perf/hv-24x7.c:229:1: warning: > symbol '__pcpu_scope_hv_24x7_txn_flags' was not declared. Should it be > static? > arch/powerpc/perf/hv-24x7.c:230:1: warning: > symbol '__pcpu_scope_hv_24x7_txn_err' was not declared. Should it be static? > arch/powerpc/perf/hv-24x7.c:236:1: warning: > symbol '__pcpu_scope_hv_24x7_hw' was not declared. Should it be static? > arch/powerpc/perf/hv-24x7.c:244:1: warning: > symbol '__pcpu_scope_hv_24x7_reqb' was not declared. Should it be static? > arch/powerpc/perf/hv-24x7.c:245:1: warning: > symbol '__pcpu_scope_hv_24x7_resb' was not declared. Should it be static? > > [...] Applied to powerpc/next. [1/1] powerpc/perf/hv-24x7: Make some symbols static https://git.kernel.org/powerpc/c/cc331eee03eadd750af1fb957d020b3f24e5e056 cheers
Re: [PATCH -next] powerpc/security: Make symbol 'stf_barrier' static
On Thu, 8 Apr 2021 11:39:51 +0800, Li Huafei wrote: > The sparse tool complains as follows: > > arch/powerpc/kernel/security.c:253:6: warning: > symbol 'stf_barrier' was not declared. Should it be static? > > This symbol is not used outside of security.c, so this commit marks it > static. Applied to powerpc/next. [1/1] powerpc/security: Make symbol 'stf_barrier' static https://git.kernel.org/powerpc/c/7f262b4dcf7edf75097c3946e676d6c6d77fc599 cheers
Re: [PATCH 1/2] powerpc: syscalls: switch to generic syscalltbl.sh
On Tue, 2 Mar 2021 00:30:18 +0900, Masahiro Yamada wrote: > Many architectures duplicate similar shell scripts. > > This commit converts powerpc to use scripts/syscalltbl.sh. This also > unifies syscall_table_32.h and syscall_table_c32.h. Applied to powerpc/next. [1/2] powerpc: syscalls: switch to generic syscalltbl.sh https://git.kernel.org/powerpc/c/14b3c9d24a7a5c274a9df27d245516f466d3bc5f [2/2] powerpc: syscalls: switch to generic syscallhdr.sh https://git.kernel.org/powerpc/c/672bff581e19d5d7bef993f910ed385c4054cbbc cheers
Re: [PATCH] powerpc/vdso: Separate vvar vma from vdso
On Fri, 26 Mar 2021 19:17:20 +, Dmitry Safonov wrote:
> Since commit 511157ab641e ("powerpc/vdso: Move vdso datapage up front")
> VVAR page is in front of the VDSO area. In result it breaks CRIU
> (Checkpoint Restore In Userspace) [1], where CRIU expects that "[vdso]"
> from /proc/../maps points at ELF/vdso image, rather than at VVAR data page.
> Laurent made a patch to keep CRIU working (by reading aux vector).
> But I think it still makes sence to separate two mappings into different
> VMAs. It will also make ppc64 less "special" for userspace and as
> a side-bonus will make VVAR page un-writable by debugger (which previously
> would COW page and can be unexpected).
>
> [...]
Applied to powerpc/next.
[1/1] powerpc/vdso: Separate vvar vma from vdso
https://git.kernel.org/powerpc/c/1c4bce6753857dc409a0197342d18764e7f4b741
cheers
Re: [PATCH -next] powerpc/pseries/pmem: Make symbol 'drc_pmem_match' static
On Fri, 9 Apr 2021 17:01:14 +0800, Bixuan Cui wrote: > The sparse tool complains as follows: > > arch/powerpc/platforms/pseries/pmem.c:142:27: warning: > symbol 'drc_pmem_match' was not declared. Should it be static? > > This symbol is not used outside of pmem.c, so this > commit marks it static. Applied to powerpc/next. [1/1] powerpc/pseries/pmem: Make symbol 'drc_pmem_match' static https://git.kernel.org/powerpc/c/2235dea17d56238642121a8085b71d68598534bb cheers
Re: [PATCH -next] powerpc/pseries: Make symbol '__pcpu_scope_hcall_stats' static
On Fri, 9 Apr 2021 17:01:09 +0800, Bixuan Cui wrote: > The sparse tool complains as follows: > > arch/powerpc/platforms/pseries/hvCall_inst.c:29:1: warning: > symbol '__pcpu_scope_hcall_stats' was not declared. Should it be static? > > This symbol is not used outside of hvCall_inst.c, so this > commit marks it static. Applied to powerpc/next. [1/1] powerpc/pseries: Make symbol '__pcpu_scope_hcall_stats' static https://git.kernel.org/powerpc/c/193e4cd8ed9dd01092d01df7706a6b344c946af4 cheers
Re: [PATCH -next] powerpc/powernv: make symbol 'mpipl_kobj' static
On Fri, 9 Apr 2021 14:38:55 +0800, Bixuan Cui wrote: > The sparse tool complains as follows: > > arch/powerpc/platforms/powernv/opal-core.c:74:16: warning: > symbol 'mpipl_kobj' was not declared. > > This symbol is not used outside of opal-core.c, so marks it static. Applied to powerpc/next. [1/1] powerpc/powernv: make symbol 'mpipl_kobj' static https://git.kernel.org/powerpc/c/ff0b4155ae9903539d1299a9a4c8717fb7eb6009 cheers
Re: [PATCH -next] powerpc/perf: Make symbol 'isa207_pmu_format_attr' static
On Fri, 9 Apr 2021 17:01:19 +0800, Bixuan Cui wrote: > The sparse tool complains as follows: > > arch/powerpc/perf/isa207-common.c:24:18: warning: > symbol 'isa207_pmu_format_attr' was not declared. Should it be static? > > This symbol is not used outside of isa207-common.c, so this > commit marks it static. Applied to powerpc/next. [1/1] powerpc/perf: Make symbol 'isa207_pmu_format_attr' static https://git.kernel.org/powerpc/c/107dadb046178173dea18e0a78ff8ea3cc27c213 cheers
Re: [PATCH RESEND v1 0/4] powerpc/vdso: Add support for time namespaces
On Wed, 31 Mar 2021 16:48:43 + (UTC), Christophe Leroy wrote: > [Sorry, resending with complete destination list, I used the wrong script on > the first delivery] > > This series adds support for time namespaces on powerpc. > > All timens selftests are successfull. > > Christophe Leroy (3): > lib/vdso: Mark do_hres_timens() and do_coarse_timens() > __always_inline() > lib/vdso: Add vdso_data pointer as input to > __arch_get_timens_vdso_data() > powerpc/vdso: Add support for time namespaces > > [...] Applied to powerpc/next. [1/4] lib/vdso: Mark do_hres_timens() and do_coarse_timens() __always_inline() https://git.kernel.org/powerpc/c/58efe9f696cf908f40d6672aeca81cb2ad2bc762 [2/4] lib/vdso: Add vdso_data pointer as input to __arch_get_timens_vdso_data() https://git.kernel.org/powerpc/c/808094fcbf4196be0feb17afbbdc182ec95c8cec [3/4] powerpc/vdso: Separate vvar vma from vdso https://git.kernel.org/powerpc/c/1c4bce6753857dc409a0197342d18764e7f4b741 [4/4] powerpc/vdso: Add support for time namespaces https://git.kernel.org/powerpc/c/74205b3fc2effde821b219d955c70e727dc43cc6 cheers
Re: [PATCH v2 1/9] powerpc/mem: Move cache flushing functions into mm/cacheflush.c
On Thu, 8 Apr 2021 15:30:24 + (UTC), Christophe Leroy wrote: > Cache flushing functions are in the middle of completely > unrelated stuff in mm/mem.c > > Create a dedicated mm/cacheflush.c for those functions. > > Also cleanup the list of included headers. Applied to powerpc/next. [1/9] powerpc/mem: Move cache flushing functions into mm/cacheflush.c https://git.kernel.org/powerpc/c/b26e8f27253a47bff90972b987112fd8396e9b8d [2/9] powerpc/mem: Declare __flush_dcache_icache() static https://git.kernel.org/powerpc/c/bf26e0bbd2f82b52605cd7c880245eefe67e09f3 [3/9] powerpc/mem: Remove address argument to flush_coherent_icache() https://git.kernel.org/powerpc/c/131637a17dc97fde3d007ab224e30c7ff4e62f6e [4/9] powerpc/mem: Call flush_coherent_icache() at higher level https://git.kernel.org/powerpc/c/e618c7aea1f2a2d615a99948f1f5cb4c11b6bf57 [5/9] powerpc/mem: Optimise flush_dcache_icache_hugepage() https://git.kernel.org/powerpc/c/cd97d9e8b5aa45a7f867a10e99f1d6ce0a5deb8b [6/9] powerpc/mem: flush_dcache_icache_phys() is for HIGHMEM pages only https://git.kernel.org/powerpc/c/52d490437ffb1bab0a63ab7b1a64514d8c17dd4d [7/9] powerpc/mem: Help GCC realise __flush_dcache_icache() flushes single pages https://git.kernel.org/powerpc/c/67b8e6af191a6ed717be548307eb15048f8181d8 [8/9] powerpc/mem: Inline flush_dcache_page() https://git.kernel.org/powerpc/c/6c96020882b17fb6f4fbf7f8cef8c606460fc14d [9/9] powerpc/mem: Use kmap_local_page() in flushing functions https://git.kernel.org/powerpc/c/7e9ab144c128df7660a2f33c9c6d1422fe798060 cheers
[PATCH net-next 2/2] net: ethernet: mediatek: support custom GMAC label
The MAC device name can now be set within DTS file instead of always
being "ethX". This is helpful for DSA to clearly label the DSA master
device and distinguish it from DSA slave ports.
For example, some devices, such as the Ubiquiti EdgeRouter X, may have
ports labeled ethX. Labeling the master GMAC with a different prefix
than DSA ports helps with clarity.
Suggested-by: René van Dorst
Signed-off-by: Ilya Lipnitskiy
---
drivers/net/ethernet/mediatek/mtk_eth_soc.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/net/ethernet/mediatek/mtk_eth_soc.c
b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
index 6b00c12c6c43..4c0ce4fb7735 100644
--- a/drivers/net/ethernet/mediatek/mtk_eth_soc.c
+++ b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
@@ -2845,6 +2845,7 @@ static const struct net_device_ops mtk_netdev_ops = {
static int mtk_add_mac(struct mtk_eth *eth, struct device_node *np)
{
+ const char *label = of_get_property(np, "label", NULL);
const __be32 *_id = of_get_property(np, "reg", NULL);
phy_interface_t phy_mode;
struct phylink *phylink;
@@ -2940,6 +2941,9 @@ static int mtk_add_mac(struct mtk_eth *eth, struct
device_node *np)
else
eth->netdev[id]->max_mtu = MTK_MAX_RX_LENGTH_2K -
MTK_RX_ETH_HLEN;
+ if (label)
+ strscpy(eth->netdev[id]->name, label, IFNAMSIZ);
+
return 0;
free_netdev:
--
2.31.1
Re: [PATCH] powerpc/signal32: Fix build failure with CONFIG_SPE
On Sun, 11 Apr 2021 16:39:53 + (UTC), Christophe Leroy wrote: > Add missing fault exit label in unsafe_copy_from_user() in order to > avoid following build failure with CONFIG_SPE > > CC arch/powerpc/kernel/signal_32.o > arch/powerpc/kernel/signal_32.c: In function 'restore_user_regs': > arch/powerpc/kernel/signal_32.c:565:36: error: macro "unsafe_copy_from_user" > requires 4 arguments, but only 3 given > 565 | ELF_NEVRREG * sizeof(u32)); > |^ > In file included from ./include/linux/uaccess.h:11, > from ./include/linux/sched/task.h:11, > from ./include/linux/sched/signal.h:9, > from ./include/linux/rcuwait.h:6, > from ./include/linux/percpu-rwsem.h:7, > from ./include/linux/fs.h:33, > from ./include/linux/huge_mm.h:8, > from ./include/linux/mm.h:707, > from arch/powerpc/kernel/signal_32.c:17: > ./arch/powerpc/include/asm/uaccess.h:428: note: macro "unsafe_copy_from_user" > defined here > 428 | #define unsafe_copy_from_user(d, s, l, e) \ > | > arch/powerpc/kernel/signal_32.c:564:3: error: 'unsafe_copy_from_user' > undeclared (first use in this function); did you mean 'raw_copy_from_user'? > 564 | unsafe_copy_from_user(current->thread.evr, >mc_vregs, > | ^ > | raw_copy_from_user > arch/powerpc/kernel/signal_32.c:564:3: note: each undeclared identifier is > reported only once for each function it appears in > make[3]: *** [arch/powerpc/kernel/signal_32.o] Error 1 Applied to powerpc/next. [1/1] powerpc/signal32: Fix build failure with CONFIG_SPE https://git.kernel.org/powerpc/c/af072b1a9d4d9edc24da84a071b0671e147026cb cheers
[PATCH net-next 1/2] dt-bindings: net: mediatek: add optional GMAC labels
Document the mediatek ethernet driver change that adds support for
custom labels and provide an example.
Signed-off-by: Ilya Lipnitskiy
---
Documentation/devicetree/bindings/net/mediatek-net.txt | 6 ++
1 file changed, 6 insertions(+)
diff --git a/Documentation/devicetree/bindings/net/mediatek-net.txt
b/Documentation/devicetree/bindings/net/mediatek-net.txt
index 72d03e07cf7c..500bf9351010 100644
--- a/Documentation/devicetree/bindings/net/mediatek-net.txt
+++ b/Documentation/devicetree/bindings/net/mediatek-net.txt
@@ -51,6 +51,10 @@ Required properties:
is equal to 0 and the MAC uses fixed-link to connect
with internal switch such as MT7530.
+Optional properties:
+- label: overrides the default netdevice name. Useful when a custom name for
the
+ DSA master interface is desired.
+
Example:
eth: ethernet@1b10 {
@@ -74,12 +78,14 @@ eth: ethernet@1b10 {
gmac1: mac@0 {
compatible = "mediatek,eth-mac";
+ label = "gmac1";
reg = <0>;
phy-handle = <>;
};
gmac2: mac@1 {
compatible = "mediatek,eth-mac";
+ label = "gmac2";
reg = <1>;
phy-handle = <>;
};
--
2.31.1
Re: [PATCH 1/3] powerpc/modules: Load modules closer to kernel text
On Thu, 1 Apr 2021 13:30:41 + (UTC), Christophe Leroy wrote: > On book3s/32, when STRICT_KERNEL_RWX is selected, modules are > allocated on the segment just before kernel text, ie on the > 0xb000-0xbfff when PAGE_OFFSET is 0xc000. > > On the 8xx, TASK_SIZE is 0x8000. The space between TASK_SIZE and > PAGE_OFFSET is not used and could be used for modules. > > [...] Applied to powerpc/next. [1/3] powerpc/modules: Load modules closer to kernel text https://git.kernel.org/powerpc/c/2ec13df167040cd153c25c4d96d0ffc573ac4c40 [2/3] powerpc/8xx: Define a MODULE area below kernel text https://git.kernel.org/powerpc/c/9132a2e82adc6e5a1c7c7385df3bfb25576bdd80 [3/3] powerpc/32s: Define a MODULE area below kernel text all the time https://git.kernel.org/powerpc/c/80edc68e0479bafdc4869ec3351e42316b824596 cheers
[PATCH net-next 0/2] net: ethernet: mediatek: support custom GMAC label
Add support for specifying GMAC label via DTS. Useful when it is desired to use a master DSA interface name that is different from the "eth%d" pattern. Ilya Lipnitskiy (2): dt-bindings: net: mediatek: add optional GMAC labels net: ethernet: mediatek: support custom GMAC label Documentation/devicetree/bindings/net/mediatek-net.txt | 6 ++ drivers/net/ethernet/mediatek/mtk_eth_soc.c| 4 2 files changed, 10 insertions(+) -- 2.31.1
Re: [PATCH] [v2] usb: cdns3: Fix runtime PM imbalance on error
On 21-04-12 13:49:07, Dinghao Liu wrote:
> When cdns3_gadget_start() fails, a pairing PM usage counter
> decrement is needed to keep the counter balanced.
>
> Signed-off-by: Dinghao Liu
Applied, thanks.
Peter
> ---
>
> Changelog:
>
> v2: - Use pm_runtime_put_sync() to decrease refcount.
> ---
> drivers/usb/cdns3/cdns3-gadget.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/usb/cdns3/cdns3-gadget.c
> b/drivers/usb/cdns3/cdns3-gadget.c
> index 582bfeceedb4..a49fc68ec2ef 100644
> --- a/drivers/usb/cdns3/cdns3-gadget.c
> +++ b/drivers/usb/cdns3/cdns3-gadget.c
> @@ -3255,8 +3255,10 @@ static int __cdns3_gadget_init(struct cdns *cdns)
> pm_runtime_get_sync(cdns->dev);
>
> ret = cdns3_gadget_start(cdns);
> - if (ret)
> + if (ret) {
> + pm_runtime_put_sync(cdns->dev);
> return ret;
> + }
>
> /*
>* Because interrupt line can be shared with other components in
> --
> 2.17.1
>
--
Thanks,
Peter Chen
Re: [PATCH V2] mm/page_alloc: Ensure that HUGETLB_PAGE_ORDER is less than MAX_ORDER
On 4/12/21 2:17 PM, David Hildenbrand wrote:
> On 12.04.21 10:06, Anshuman Khandual wrote:
>> + linuxppc-...@lists.ozlabs.org
>> + linux-i...@vger.kernel.org
>>
>> On 4/12/21 9:18 AM, Anshuman Khandual wrote:
>>> pageblock_order must always be less than MAX_ORDER, otherwise it might lead
>>> to an warning during boot. A similar problem got fixed on arm64 platform
>>> with the commit 79cc2ed5a716 ("arm64/mm: Drop THP conditionality from
>>> FORCE_MAX_ZONEORDER"). Assert the above condition before HUGETLB_PAGE_ORDER
>>> gets assigned as pageblock_order. This will help detect the problem earlier
>>> on platforms where HUGETLB_PAGE_SIZE_VARIABLE is enabled.
>>>
>>> Cc: David Hildenbrand
>>> Cc: Andrew Morton
>>> Cc: linux...@kvack.org
>>> Cc: linux-kernel@vger.kernel.org
>>> Signed-off-by: Anshuman Khandual
>>> ---
>>> Changes in V2:
>>>
>>> - Changed WARN_ON() to BUILD_BUG_ON() per David
>>>
>>> Changes in V1:
>>>
>>> https://patchwork.kernel.org/project/linux-mm/patch/1617947717-2424-1-git-send-email-anshuman.khand...@arm.com/
>>>
>>> mm/page_alloc.c | 11 +--
>>> 1 file changed, 9 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
>>> index cfc72873961d..19283bff4bec 100644
>>> --- a/mm/page_alloc.c
>>> +++ b/mm/page_alloc.c
>>> @@ -6875,10 +6875,17 @@ void __init set_pageblock_order(void)
>>> if (pageblock_order)
>>> return;
>>> - if (HPAGE_SHIFT > PAGE_SHIFT)
>>> + if (HPAGE_SHIFT > PAGE_SHIFT) {
>>> + /*
>>> + * pageblock_order must always be less than
>>> + * MAX_ORDER. So does HUGETLB_PAGE_ORDER if
>>> + * that is being assigned here.
>>> + */
>>> + BUILD_BUG_ON(HUGETLB_PAGE_ORDER >= MAX_ORDER);
>>
>> Unfortunately the build test fails on both the platforms (powerpc and ia64)
>> which subscribe HUGETLB_PAGE_SIZE_VARIABLE and where this check would make
>> sense. I some how overlooked the cross compile build failure that actually
>> detected this problem.
>>
>> But wondering why this assert is not holding true ? and how these platforms
>> do not see the warning during boot (or do they ?) at mm/vmscan.c:1092 like
>> arm64 did.
>>
>> static int __fragmentation_index(unsigned int order, struct contig_page_info
>> *info)
>> {
>> unsigned long requested = 1UL << order;
>>
>> if (WARN_ON_ONCE(order >= MAX_ORDER))
>> return 0;
>>
>>
>> Can pageblock_order really exceed MAX_ORDER - 1 ?
>
> Ehm, for now I was under the impression that such configurations wouldn't
> exist.
>
> And originally, HUGETLB_PAGE_SIZE_VARIABLE was introduced to handle hugepage
> sizes that all *smaller* than MAX_ORDER - 1: See d9c234005227 ("Do not depend
> on MAX_ORDER when grouping pages by mobility")
Right.
>
>
> However, looking into init_cma_reserved_pageblock():
>
> if (pageblock_order >= MAX_ORDER) {
> i = pageblock_nr_pages;
> ...
> }
>
>
> But it's kind of weird, isn't it? Let's assume we have MAX_ORDER - 1
> correspond to 4 MiB and pageblock_order correspond to 8 MiB.
>
> Sure, we'd be grouping pages in 8 MiB chunks, however, we cannot even
> allocate 8 MiB chunks via the buddy. So only alloc_contig_range() could
> really grab them (IOW: gigantic pages).
Right.
>
> Further, we have code like deferred_free_range(), where we end up calling
> __free_pages_core()->...->__free_one_page() with pageblock_order. Wouldn't we
> end up setting the buddy order to something > MAX_ORDER -1 on that path?
Agreed.
>
> Having pageblock_order > MAX_ORDER feels wrong and looks shaky.
>
Agreed, definitely does not look right. Lets see what other folks
might have to say on this.
+ Christoph Lameter
Re: [PATCH v2 3/3] mm,hwpoison: add kill_accessing_process() to find error virtual address
On Mon, 19 Apr 2021 11:36:58 +0900 Naoya Horiguchi wrote: > > > 2. In the function hwpoison_pte_range(): > > > if (pfn <= hwp->pfn && hwp->pfn < pfn + PMD_SIZE) this check seem we > > > should use PMD_SIZE/PAGE_SIZE or some macro like this? > > > > Thanks, that's right. HPAGE_PMD_NR seems to fit here. > > We also need "#ifdef CONFIG_TRANSPARENT_HUGEPAGE" to use it. > > I found that the #ifdef is not necessary because the whole > "if (ptl)" is compiled out. So I don't add #ifdef. > > Here's the v2 of 3/3. > > Aili, could you test with it? > > Thanks, > Naoya Horiguchi > I tested this v2 version, In my test, this patches worked as expected and the previous issues didn't happen again. Test-by: Aili Yao Thanks, Aili Yao > - > From: Naoya Horiguchi > Date: Tue, 13 Apr 2021 07:26:25 +0900 > Subject: [PATCH v2 3/3] mm,hwpoison: add kill_accessing_process() to find > error > virtual address > > The previous patch solves the infinite MCE loop issue when multiple > MCE events races. The remaining issue is to make sure that all threads > processing Action Required MCEs send to the current processes the > SIGBUS with the proper virtual address and the error size. > > This patch suggests to do page table walk to find the error virtual > address. If we find multiple virtual addresses in walking, we now can't > determine which one is correct, so we fall back to sending SIGBUS in > kill_me_maybe() without error info as we do now. This corner case needs > to be solved in the future. > > Signed-off-by: Naoya Horiguchi > --- > change log v1 -> v2: > - initialize local variables in check_hwpoisoned_entry() and > hwpoison_pte_range() > - fix and improve logic to calculate error address offset. > --- > arch/x86/kernel/cpu/mce/core.c | 13 ++- > include/linux/swapops.h| 5 ++ > mm/memory-failure.c| 147 - > 3 files changed, 161 insertions(+), 4 deletions(-) >
[PATCH] dt-bindings: net: mediatek: support MT7621 SoC
Add missing binding documentation for SoC support that has been in place
since v5.1
Fixes: 889bcbdeee57 ("net: ethernet: mediatek: support MT7621 SoC ethernet
hardware")
Cc: Bjørn Mork
Signed-off-by: Ilya Lipnitskiy
---
Documentation/devicetree/bindings/net/mediatek-net.txt | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/net/mediatek-net.txt
b/Documentation/devicetree/bindings/net/mediatek-net.txt
index 72d03e07cf7c..950ef6af20b1 100644
--- a/Documentation/devicetree/bindings/net/mediatek-net.txt
+++ b/Documentation/devicetree/bindings/net/mediatek-net.txt
@@ -10,6 +10,7 @@ Required properties:
- compatible: Should be
"mediatek,mt2701-eth": for MT2701 SoC
"mediatek,mt7623-eth", "mediatek,mt2701-eth": for MT7623 SoC
+ "mediatek,mt7621-eth": for MT7621 SoC
"mediatek,mt7622-eth": for MT7622 SoC
"mediatek,mt7629-eth": for MT7629 SoC
"ralink,rt5350-eth": for Ralink Rt5350F and MT7628/88 SoC
--
2.31.1
linux-next: build warning after merge of the sound-asoc tree
Hi all,
After merging the sound-asoc tree, today's linux-next build (arm
multi_v7_defconfig) produced this warning:
sound/soc/generic/simple-card.c: In function 'simple_parse_of':
sound/soc/generic/simple-card.c:478:1: warning: the frame size of 1552 bytes is
larger than 1024 bytes [-Wframe-larger-than=]
478 | }
| ^
sound/soc/generic/simple-card.c: In function 'asoc_simple_probe':
sound/soc/generic/simple-card.c:706:1: warning: the frame size of 1552 bytes is
larger than 1024 bytes [-Wframe-larger-than=]
706 | }
| ^
sound/soc/generic/audio-graph-card.c: In function 'audio_graph_parse_of':
sound/soc/generic/audio-graph-card.c:612:1: warning: the frame size of 1552
bytes is larger than 1024 bytes [-Wframe-larger-than=]
612 | }
| ^
Presumably introduced by commit
343e55e71877 ("ASoC: simple-card-utils: Increase maximum number of links to
128")
--
Cheers,
Stephen Rothwell
pgpSxmQ9sIt8x.pgp
Description: OpenPGP digital signature
[PATCH v2] usb: gadget: dummy_hcd: fix gpf in gadget_setup
Fix a general protection fault reported by syzbot due to a race between
gadget_setup() and gadget_unbind() in raw_gadget.
The gadget core is supposed to guarantee that there won't be any more
callbacks to the gadget driver once the driver's unbind routine is
called. That guarantee is enforced in usb_gadget_remove_driver as
follows:
usb_gadget_disconnect(udc->gadget);
if (udc->gadget->irq)
synchronize_irq(udc->gadget->irq);
udc->driver->unbind(udc->gadget);
usb_gadget_udc_stop(udc);
usb_gadget_disconnect turns off the pullup resistor, telling the host
that the gadget is no longer connected and preventing the transmission
of any more USB packets. Any packets that have already been received
are sure to processed by the UDC driver's interrupt handler by the time
synchronize_irq returns.
But this doesn't work with dummy_hcd, because dummy_hcd doesn't use
interrupts; it uses a timer instead. It does have code to emulate the
effect of synchronize_irq, but that code doesn't get invoked at the
right time -- it currently runs in usb_gadget_udc_stop, after the unbind
callback instead of before. Indeed, there's no way for
usb_gadget_remove_driver to invoke this code before the unbind callback.
To fix this, move the synchronize_irq() emulation code to dummy_pullup
so that it runs before unbind. Also, add a comment explaining why it is
necessary to have it there.
Suggested-by: Alan Stern
Reported-by: syzbot+eb4674092e6cc8d9e...@syzkaller.appspotmail.com
Acked-by: Alan Stern
Signed-off-by: Anirudh Rayabharam
---
Changes in v2:
Improvements in the comment as suggested by Alan Stern.
v1: https://lore.kernel.org/lkml/20210417125212.6274-1-m...@anirudhrb.com/
---
drivers/usb/gadget/udc/dummy_hcd.c | 23 +++
1 file changed, 15 insertions(+), 8 deletions(-)
diff --git a/drivers/usb/gadget/udc/dummy_hcd.c
b/drivers/usb/gadget/udc/dummy_hcd.c
index ce24d4f28f2a..7db773c87379 100644
--- a/drivers/usb/gadget/udc/dummy_hcd.c
+++ b/drivers/usb/gadget/udc/dummy_hcd.c
@@ -903,6 +903,21 @@ static int dummy_pullup(struct usb_gadget *_gadget, int
value)
spin_lock_irqsave(>lock, flags);
dum->pullup = (value != 0);
set_link_state(dum_hcd);
+ if (value == 0) {
+ /*
+* Emulate synchronize_irq(): wait for callbacks to finish.
+* This seems to be the best place to emulate the call to
+* synchronize_irq() that's in usb_gadget_remove_driver().
+* Doing it in dummy_udc_stop() would be too late since it
+* is called after the unbind callback and unbind shouldn't
+* be invoked until all the other callbacks are finished.
+*/
+ while (dum->callback_usage > 0) {
+ spin_unlock_irqrestore(>lock, flags);
+ usleep_range(1000, 2000);
+ spin_lock_irqsave(>lock, flags);
+ }
+ }
spin_unlock_irqrestore(>lock, flags);
usb_hcd_poll_rh_status(dummy_hcd_to_hcd(dum_hcd));
@@ -1004,14 +1019,6 @@ static int dummy_udc_stop(struct usb_gadget *g)
spin_lock_irq(>lock);
dum->ints_enabled = 0;
stop_activity(dum);
-
- /* emulate synchronize_irq(): wait for callbacks to finish */
- while (dum->callback_usage > 0) {
- spin_unlock_irq(>lock);
- usleep_range(1000, 2000);
- spin_lock_irq(>lock);
- }
-
dum->driver = NULL;
spin_unlock_irq(>lock);
--
2.26.2
Re: [PATCH v2 01/12] docs: path-lookup: update follow_managed() part
On Mon, Apr 19, 2021 at 11:25 AM Matthew Wilcox wrote:
>
> On Mon, Apr 19, 2021 at 10:33:00AM +0800, Fox Chen wrote:
> > On Mon, Apr 19, 2021 at 10:17 AM Matthew Wilcox wrote:
> > >
> > > On Tue, Mar 16, 2021 at 01:47:16PM +0800, Fox Chen wrote:
> > > > -In the absence of symbolic links, ``walk_component()`` creates a new
> > > > +As the last step of ``walk_component()``, ``step_into()`` will be
> > > > called either
> > >
> > > You can drop ``..`` from around function named which are followed with
> > > (). d74b0d31ddde ("Docs: An initial automarkup extension for sphinx")
> > > marks them up automatically.
> > >
> >
> > Got it, thanks for letting me know. But I will still use them in this
> > patch series to keep consistency with the remaining parts of the
> > document.
>
> Well, you weren't. For example:
>
> +As the last step of ``walk_component()``, ``step_into()`` will be called
> either
> +directly from walk_component() or from handle_dots(). It calls
> +``handle_mount()``, to check and handle mount points, in which a new
>
> Neither of the functions on the second line were using ``.
Oh, That was a mistake, They should've been wrapped with ``.
Thanks for pointing it out. I will go through the whole patch set and
fix this type of inconsistency in V3.
thanks,
fox
Re: [PATCH -next v2 1/2] mm/debug_vm_pgtable: Move {pmd/pud}_huge_tests out of CONFIG_TRANSPARENT_HUGEPAGE
On 4/9/21 9:35 AM, Anshuman Khandual wrote:
>
> On 4/6/21 10:18 AM, Shixin Liu wrote:
>> v1->v2:
>> Modified the commit message.
>
> Please avoid change log in the commit message, it should be after '---'
> below the SOB statement.
>
>>
>> The functions {pmd/pud}_set_huge and {pmd/pud}_clear_huge ars not dependent
>> on THP.
>
> typo ^ s/ars/are
>
> Also there is a checkpatch.pl warning.
>
> WARNING: Possible unwrapped commit description (prefer a maximum 75 chars per
> line)
> #10:
> The functions {pmd/pud}_set_huge and {pmd/pud}_clear_huge ars not dependent
> on THP.
>
> total: 0 errors, 1 warnings, 121 lines checked
>
> As I had mentioned in the earlier version, the commit message should be some
> thing like ..
>
>
> The functions {pmd/pud}_set_huge and {pmd/pud}_clear_huge are not dependent
> on THP. Hence move {pmd/pud}_huge_tests out of CONFIG_TRANSPARENT_HUGEPAGE.
>
>
>>
>> Signed-off-by: Shixin Liu
>> ---
>> mm/debug_vm_pgtable.c | 91 +++
>> 1 file changed, 39 insertions(+), 52 deletions(-)
>>
>> diff --git a/mm/debug_vm_pgtable.c b/mm/debug_vm_pgtable.c
>> index 05efe98a9ac2..d3cf178621d9 100644
>> --- a/mm/debug_vm_pgtable.c
>> +++ b/mm/debug_vm_pgtable.c
>> @@ -242,29 +242,6 @@ static void __init pmd_leaf_tests(unsigned long pfn,
>> pgprot_t prot)
>> WARN_ON(!pmd_leaf(pmd));
>> }
>>
>> -#ifdef CONFIG_HAVE_ARCH_HUGE_VMAP
>> -static void __init pmd_huge_tests(pmd_t *pmdp, unsigned long pfn, pgprot_t
>> prot)
>> -{
>> -pmd_t pmd;
>> -
>> -if (!arch_vmap_pmd_supported(prot))
>> -return;
>> -
>> -pr_debug("Validating PMD huge\n");
>> -/*
>> - * X86 defined pmd_set_huge() verifies that the given
>> - * PMD is not a populated non-leaf entry.
>> - */
>> -WRITE_ONCE(*pmdp, __pmd(0));
>> -WARN_ON(!pmd_set_huge(pmdp, __pfn_to_phys(pfn), prot));
>> -WARN_ON(!pmd_clear_huge(pmdp));
>> -pmd = READ_ONCE(*pmdp);
>> -WARN_ON(!pmd_none(pmd));
>> -}
>> -#else /* CONFIG_HAVE_ARCH_HUGE_VMAP */
>> -static void __init pmd_huge_tests(pmd_t *pmdp, unsigned long pfn, pgprot_t
>> prot) { }
>> -#endif /* CONFIG_HAVE_ARCH_HUGE_VMAP */
>> -
>> static void __init pmd_savedwrite_tests(unsigned long pfn, pgprot_t prot)
>> {
>> pmd_t pmd = pfn_pmd(pfn, prot);
>> @@ -379,30 +356,6 @@ static void __init pud_leaf_tests(unsigned long pfn,
>> pgprot_t prot)
>> pud = pud_mkhuge(pud);
>> WARN_ON(!pud_leaf(pud));
>> }
>> -
>> -#ifdef CONFIG_HAVE_ARCH_HUGE_VMAP
>> -static void __init pud_huge_tests(pud_t *pudp, unsigned long pfn, pgprot_t
>> prot)
>> -{
>> -pud_t pud;
>> -
>> -if (!arch_vmap_pud_supported(prot))
>> -return;
>> -
>> -pr_debug("Validating PUD huge\n");
>> -/*
>> - * X86 defined pud_set_huge() verifies that the given
>> - * PUD is not a populated non-leaf entry.
>> - */
>> -WRITE_ONCE(*pudp, __pud(0));
>> -WARN_ON(!pud_set_huge(pudp, __pfn_to_phys(pfn), prot));
>> -WARN_ON(!pud_clear_huge(pudp));
>> -pud = READ_ONCE(*pudp);
>> -WARN_ON(!pud_none(pud));
>> -}
>> -#else /* !CONFIG_HAVE_ARCH_HUGE_VMAP */
>> -static void __init pud_huge_tests(pud_t *pudp, unsigned long pfn, pgprot_t
>> prot) { }
>> -#endif /* !CONFIG_HAVE_ARCH_HUGE_VMAP */
>> -
>> #else /* !CONFIG_HAVE_ARCH_TRANSPARENT_HUGEPAGE_PUD */
>> static void __init pud_basic_tests(struct mm_struct *mm, unsigned long pfn,
>> int idx) { }
>> static void __init pud_advanced_tests(struct mm_struct *mm,
>> @@ -412,9 +365,6 @@ static void __init pud_advanced_tests(struct mm_struct
>> *mm,
>> {
>> }
>> static void __init pud_leaf_tests(unsigned long pfn, pgprot_t prot) { }
>> -static void __init pud_huge_tests(pud_t *pudp, unsigned long pfn, pgprot_t
>> prot)
>> -{
>> -}
>> #endif /* CONFIG_HAVE_ARCH_TRANSPARENT_HUGEPAGE_PUD */
>> #else /* !CONFIG_TRANSPARENT_HUGEPAGE */
>> static void __init pmd_basic_tests(unsigned long pfn, int idx) { }
>> @@ -433,14 +383,51 @@ static void __init pud_advanced_tests(struct mm_struct
>> *mm,
>> }
>> static void __init pmd_leaf_tests(unsigned long pfn, pgprot_t prot) { }
>> static void __init pud_leaf_tests(unsigned long pfn, pgprot_t prot) { }
>> +static void __init pmd_savedwrite_tests(unsigned long pfn, pgprot_t prot) {
>> }
>> +#endif /* CONFIG_TRANSPARENT_HUGEPAGE */
>> +
>> +#ifdef CONFIG_HAVE_ARCH_HUGE_VMAP
>> static void __init pmd_huge_tests(pmd_t *pmdp, unsigned long pfn, pgprot_t
>> prot)
>> {
>> +pmd_t pmd;
>> +
>> +if (!arch_vmap_pmd_supported(prot))
>> +return;
>> +
>> +pr_debug("Validating PMD huge\n");
>> +/*
>> + * X86 defined pmd_set_huge() verifies that the given
>> + * PMD is not a populated non-leaf entry.
>> + */
>> +WRITE_ONCE(*pmdp, __pmd(0));
>> +WARN_ON(!pmd_set_huge(pmdp, __pfn_to_phys(pfn), prot));
>> +WARN_ON(!pmd_clear_huge(pmdp));
>> +pmd = READ_ONCE(*pmdp);
>> +
Re: [PATCH v2 01/12] docs: path-lookup: update follow_managed() part
On Mon, Apr 19, 2021 at 10:33:00AM +0800, Fox Chen wrote:
> On Mon, Apr 19, 2021 at 10:17 AM Matthew Wilcox wrote:
> >
> > On Tue, Mar 16, 2021 at 01:47:16PM +0800, Fox Chen wrote:
> > > -In the absence of symbolic links, ``walk_component()`` creates a new
> > > +As the last step of ``walk_component()``, ``step_into()`` will be called
> > > either
> >
> > You can drop ``..`` from around function named which are followed with
> > (). d74b0d31ddde ("Docs: An initial automarkup extension for sphinx")
> > marks them up automatically.
> >
>
> Got it, thanks for letting me know. But I will still use them in this
> patch series to keep consistency with the remaining parts of the
> document.
Well, you weren't. For example:
+As the last step of ``walk_component()``, ``step_into()`` will be called either
+directly from walk_component() or from handle_dots(). It calls
+``handle_mount()``, to check and handle mount points, in which a new
Neither of the functions on the second line were using ``.
Re: [PATCH V3 3/3] vDPA/ifcvf: get_config_size should return dev specific config size
在 2021/4/16 下午3:16, Zhu Lingshan 写道:
get_config_size() should return the size based on the decected
device type.
Signed-off-by: Zhu Lingshan
Acked-by: Jason Wang
---
drivers/vdpa/ifcvf/ifcvf_main.c | 19 ++-
1 file changed, 18 insertions(+), 1 deletion(-)
diff --git a/drivers/vdpa/ifcvf/ifcvf_main.c b/drivers/vdpa/ifcvf/ifcvf_main.c
index 376b2014916a..3b6f7862dbb8 100644
--- a/drivers/vdpa/ifcvf/ifcvf_main.c
+++ b/drivers/vdpa/ifcvf/ifcvf_main.c
@@ -356,7 +356,24 @@ static u32 ifcvf_vdpa_get_vq_align(struct vdpa_device
*vdpa_dev)
static size_t ifcvf_vdpa_get_config_size(struct vdpa_device *vdpa_dev)
{
- return sizeof(struct virtio_net_config);
+ struct ifcvf_adapter *adapter = vdpa_to_adapter(vdpa_dev);
+ struct ifcvf_hw *vf = vdpa_to_vf(vdpa_dev);
+ struct pci_dev *pdev = adapter->pdev;
+ size_t size;
+
+ switch (vf->dev_type) {
+ case VIRTIO_ID_NET:
+ size = sizeof(struct virtio_net_config);
+ break;
+ case VIRTIO_ID_BLOCK:
+ size = sizeof(struct virtio_blk_config);
+ break;
+ default:
+ size = 0;
+ IFCVF_ERR(pdev, "VIRTIO ID %u not supported\n", vf->dev_type);
+ }
+
+ return size;
}
static void ifcvf_vdpa_get_config(struct vdpa_device *vdpa_dev,
Re: [PATCH 0/2] sunxi: Enforce consistent MMC numbering
Hi, On Mon, Apr 19, 2021 at 10:52 AM Samuel Holland wrote: > > Dealing with the inconsistent numbering has been a major pain, and > there is a solution with (as far as I can tell) no tangible downsides. > So let's use it. > > Yes, I know the kernel supports UUIDs for root=. But UUIDs do not help > when referencing the whole, unpartitioned device, like is needed for > updating the bootloader and firmware. So for the use case of "write a > bootloader to the SD card, regardless of where the board is currently > booted from", I know of two options: > - Dig around in sysfs to find the mmc number from the MMIO address, > which means I have to know the MMIO addresses for every SoC, or > - Apply patches like these. > > Samuel Holland (2): > ARM: dts: sunxi: h3/h5: Enforce consistent MMC numbering > arm64: dts: allwinner: Enforce consistent MMC numbering > > arch/arm/boot/dts/sunxi-h3-h5.dtsi| 6 ++ > arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 6 ++ > arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi | 6 ++ At least with Rockchip this is now done at the board level. IIRC it was a request from other people to not do it at the SoC level. I don't recall exactly who though. ChenYu > 3 files changed, 18 insertions(+) > > -- > 2.26.3 > >
Re: [Patch v2 6/7] crypto: qce: common: Add support for AEAD algorithms
On Sat 17 Apr 08:25 CDT 2021, Thara Gopinath wrote:
> Add register programming sequence for enabling AEAD
> algorithms on the Qualcomm crypto engine.
>
> Signed-off-by: Thara Gopinath
> ---
>
> v1->v2:
> - Minor fixes like removing not needed initializing of variables
> and using bool values in lieu of 0 and 1 as pointed out by Bjorn.
> - Introduced qce_be32_to_cpu_array which converts the u8 string in big
> endian order to array of u32 and returns back total number of words,
> as per Bjorn's review comments. Presently this function is used only
> by
> qce_setup_regs_aead to format keys, iv and nonce. cipher and hash
> algorithms can be made to use this function as a separate clean up
> patch.
Thanks for reworking the patch Thara, I think it looks much more
reasonable now, just a few small questions/nits below.
>
> drivers/crypto/qce/common.c | 164 +++-
> 1 file changed, 162 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/crypto/qce/common.c b/drivers/crypto/qce/common.c
> index 7b3d6caec1b2..ffbf866842a3 100644
> --- a/drivers/crypto/qce/common.c
> +++ b/drivers/crypto/qce/common.c
> @@ -15,6 +15,16 @@
> #include "core.h"
> #include "regs-v5.h"
> #include "sha.h"
> +#include "aead.h"
> +
> +static const u32 std_iv_sha1[SHA256_DIGEST_SIZE / sizeof(u32)] = {
> + SHA1_H0, SHA1_H1, SHA1_H2, SHA1_H3, SHA1_H4, 0, 0, 0
> +};
> +
> +static const u32 std_iv_sha256[SHA256_DIGEST_SIZE / sizeof(u32)] = {
> + SHA256_H0, SHA256_H1, SHA256_H2, SHA256_H3,
> + SHA256_H4, SHA256_H5, SHA256_H6, SHA256_H7
> +};
>
> static inline u32 qce_read(struct qce_device *qce, u32 offset)
> {
> @@ -76,6 +86,21 @@ void qce_cpu_to_be32p_array(__be32 *dst, const u8 *src,
> unsigned int len)
> }
> }
>
> +static unsigned int qce_be32_to_cpu_array(u32 *dst, const u8 *src, unsigned
> int len)
> +{
> + __be32 *d = (__be32 *)dst;
> + const u8 *s = src;
> + unsigned int n;
> +
> + n = len / sizeof(u32);
> + for (; n > 0; n--) {
> + *d = cpu_to_be32p((const __u32 *)s);
The output is CPU endian, so this should be be32_to_cpup()
That also means that 'd' is u32 and you don't have to play tricks and
cast dst to a __be32*.
> + s += sizeof(u32);
> + d++;
> + }
> + return DIV_ROUND_UP(len, sizeof(u32));
> +}
> +
> static void qce_setup_config(struct qce_device *qce)
> {
> u32 config;
> @@ -96,7 +121,7 @@ static inline void qce_crypto_go(struct qce_device *qce,
> bool result_dump)
> qce_write(qce, REG_GOPROC, BIT(GO_SHIFT));
> }
>
> -#ifdef CONFIG_CRYPTO_DEV_QCE_SHA
> +#if defined(CONFIG_CRYPTO_DEV_QCE_SHA) || defined(CONFIG_CRYPTO_DEV_QCE_AEAD)
> static u32 qce_auth_cfg(unsigned long flags, u32 key_size, u32 auth_size)
> {
> u32 cfg = 0;
> @@ -139,7 +164,9 @@ static u32 qce_auth_cfg(unsigned long flags, u32
> key_size, u32 auth_size)
>
> return cfg;
> }
> +#endif
>
> +#ifdef CONFIG_CRYPTO_DEV_QCE_SHA
> static int qce_setup_regs_ahash(struct crypto_async_request *async_req)
> {
> struct ahash_request *req = ahash_request_cast(async_req);
> @@ -225,7 +252,7 @@ static int qce_setup_regs_ahash(struct
> crypto_async_request *async_req)
> }
> #endif
>
> -#ifdef CONFIG_CRYPTO_DEV_QCE_SKCIPHER
> +#if defined(CONFIG_CRYPTO_DEV_QCE_SKCIPHER) ||
> defined(CONFIG_CRYPTO_DEV_QCE_AEAD)
> static u32 qce_encr_cfg(unsigned long flags, u32 aes_key_size)
> {
> u32 cfg = 0;
> @@ -271,7 +298,9 @@ static u32 qce_encr_cfg(unsigned long flags, u32
> aes_key_size)
>
> return cfg;
> }
> +#endif
>
> +#ifdef CONFIG_CRYPTO_DEV_QCE_SKCIPHER
> static void qce_xts_swapiv(__be32 *dst, const u8 *src, unsigned int ivsize)
> {
> u8 swap[QCE_AES_IV_LENGTH];
> @@ -386,6 +415,133 @@ static int qce_setup_regs_skcipher(struct
> crypto_async_request *async_req)
> }
> #endif
>
> +#ifdef CONFIG_CRYPTO_DEV_QCE_AEAD
> +static int qce_setup_regs_aead(struct crypto_async_request *async_req)
> +{
> + struct aead_request *req = aead_request_cast(async_req);
> + struct qce_aead_reqctx *rctx = aead_request_ctx(req);
> + struct qce_aead_ctx *ctx = crypto_tfm_ctx(async_req->tfm);
> + struct qce_alg_template *tmpl = to_aead_tmpl(crypto_aead_reqtfm(req));
> + struct qce_device *qce = tmpl->qce;
> + u32 enckey[QCE_MAX_CIPHER_KEY_SIZE / sizeof(u32)] = {0};
> + u32 enciv[QCE_MAX_IV_SIZE / sizeof(u32)] = {0};
> + u32 authkey[QCE_SHA_HMAC_KEY_SIZE / sizeof(u32)] = {0};
> + u32 authiv[SHA256_DIGEST_SIZE / sizeof(u32)] = {0};
> + u32 authnonce[QCE_MAX_NONCE / sizeof(u32)] = {0};
> + unsigned int enc_keylen = ctx->enc_keylen;
> + unsigned int auth_keylen = ctx->auth_keylen;
> + unsigned int enc_ivsize = rctx->ivsize;
> + unsigned int auth_ivsize;
> + unsigned int enckey_words, enciv_words;
> + unsigned int authkey_words, authiv_words, authnonce_words;
> +
Re: [PATCH V3 2/3] vDPA/ifcvf: enable Intel C5000X-PL virtio-block for vDPA
在 2021/4/16 下午3:16, Zhu Lingshan 写道:
This commit enabled Intel FPGA SmartNIC C5000X-PL virtio-block
for vDPA.
Signed-off-by: Zhu Lingshan
Acked-by: Jason Wang
---
drivers/vdpa/ifcvf/ifcvf_base.h | 8 +++-
drivers/vdpa/ifcvf/ifcvf_main.c | 19 ++-
2 files changed, 25 insertions(+), 2 deletions(-)
diff --git a/drivers/vdpa/ifcvf/ifcvf_base.h b/drivers/vdpa/ifcvf/ifcvf_base.h
index 1c04cd256fa7..0111bfdeb342 100644
--- a/drivers/vdpa/ifcvf/ifcvf_base.h
+++ b/drivers/vdpa/ifcvf/ifcvf_base.h
@@ -15,6 +15,7 @@
#include
#include
#include
+#include
#include
#include
@@ -28,7 +29,12 @@
#define C5000X_PL_SUBSYS_VENDOR_ID0x8086
#define C5000X_PL_SUBSYS_DEVICE_ID0x0001
-#define IFCVF_SUPPORTED_FEATURES \
+#define C5000X_PL_BLK_VENDOR_ID0x1AF4
+#define C5000X_PL_BLK_DEVICE_ID0x1001
+#define C5000X_PL_BLK_SUBSYS_VENDOR_ID 0x8086
+#define C5000X_PL_BLK_SUBSYS_DEVICE_ID 0x0002
+
+#define IFCVF_NET_SUPPORTED_FEATURES \
((1ULL << VIRTIO_NET_F_MAC) | \
(1ULL << VIRTIO_F_ANY_LAYOUT)| \
(1ULL << VIRTIO_F_VERSION_1) | \
diff --git a/drivers/vdpa/ifcvf/ifcvf_main.c b/drivers/vdpa/ifcvf/ifcvf_main.c
index 469a9b5737b7..376b2014916a 100644
--- a/drivers/vdpa/ifcvf/ifcvf_main.c
+++ b/drivers/vdpa/ifcvf/ifcvf_main.c
@@ -168,10 +168,23 @@ static struct ifcvf_hw *vdpa_to_vf(struct vdpa_device
*vdpa_dev)
static u64 ifcvf_vdpa_get_features(struct vdpa_device *vdpa_dev)
{
+ struct ifcvf_adapter *adapter = vdpa_to_adapter(vdpa_dev);
struct ifcvf_hw *vf = vdpa_to_vf(vdpa_dev);
+ struct pci_dev *pdev = adapter->pdev;
+
u64 features;
- features = ifcvf_get_features(vf) & IFCVF_SUPPORTED_FEATURES;
+ switch (vf->dev_type) {
+ case VIRTIO_ID_NET:
+ features = ifcvf_get_features(vf) &
IFCVF_NET_SUPPORTED_FEATURES;
+ break;
+ case VIRTIO_ID_BLOCK:
+ features = ifcvf_get_features(vf);
+ break;
+ default:
+ features = 0;
+ IFCVF_ERR(pdev, "VIRTIO ID %u not supported\n", vf->dev_type);
+ }
return features;
}
@@ -517,6 +530,10 @@ static struct pci_device_id ifcvf_pci_ids[] = {
C5000X_PL_DEVICE_ID,
C5000X_PL_SUBSYS_VENDOR_ID,
C5000X_PL_SUBSYS_DEVICE_ID) },
+ { PCI_DEVICE_SUB(C5000X_PL_BLK_VENDOR_ID,
+C5000X_PL_BLK_DEVICE_ID,
+C5000X_PL_BLK_SUBSYS_VENDOR_ID,
+C5000X_PL_BLK_SUBSYS_DEVICE_ID) },
{ 0 },
};
[PATCH] soundwire: cadence_master: always set CMD_ACCEPT
From: Pierre-Louis Bossart
The Cadence IP can be configured in two different ways to deal with
CMD_IGNORED replies to broadcast commands. The CMD_ACCEPT bitfield
controls whether the command is discarded or if the IP proceeds with
the change (typically a bank switch or clock stop command).
The existing code seems to be inconsistent:
a) For some historical reason, we set this CMD_ACCEPT bitfield during
the initialization, but we don't during a resume from a clock-stoppped
state.
b) In addition, the loop used in the clock-stop sequence is quite
racy, it's possible that a device has lost sync but it's still tagged
as ATTACHED.
c) If somehow a Device loses sync and is unable to ack a broadcast
command, we do not have an error handling mechanism anyways. The IP
should go ahead and let the Device regain sync at a later time.
Make sure the CMD_ACCEPT bit is always set.
Signed-off-by: Pierre-Louis Bossart
Reviewed-by: Guennadi Liakhovetski
Reviewed-by: Rander Wang
Signed-off-by: Bard Liao
---
drivers/soundwire/cadence_master.c | 21 ++---
1 file changed, 2 insertions(+), 19 deletions(-)
diff --git a/drivers/soundwire/cadence_master.c
b/drivers/soundwire/cadence_master.c
index 192dac10f0c2..25950422b085 100644
--- a/drivers/soundwire/cadence_master.c
+++ b/drivers/soundwire/cadence_master.c
@@ -1428,20 +1428,6 @@ int sdw_cdns_clock_stop(struct sdw_cdns *cdns, bool
block_wake)
}
}
- /*
-* This CMD_ACCEPT should be used when there are no devices
-* attached on the link when entering clock stop mode. If this is
-* not set and there is a broadcast write then the command ignored
-* will be treated as a failure
-*/
- if (!slave_present)
- cdns_updatel(cdns, CDNS_MCP_CONTROL,
-CDNS_MCP_CONTROL_CMD_ACCEPT,
-CDNS_MCP_CONTROL_CMD_ACCEPT);
- else
- cdns_updatel(cdns, CDNS_MCP_CONTROL,
-CDNS_MCP_CONTROL_CMD_ACCEPT, 0);
-
/* commit changes */
ret = cdns_config_update(cdns);
if (ret < 0) {
@@ -1508,11 +1494,8 @@ int sdw_cdns_clock_restart(struct sdw_cdns *cdns, bool
bus_reset)
cdns_updatel(cdns, CDNS_MCP_CONTROL,
CDNS_MCP_CONTROL_BLOCK_WAKEUP, 0);
- /*
-* clear CMD_ACCEPT so that the command ignored
-* will be treated as a failure during a broadcast write
-*/
- cdns_updatel(cdns, CDNS_MCP_CONTROL, CDNS_MCP_CONTROL_CMD_ACCEPT, 0);
+ cdns_updatel(cdns, CDNS_MCP_CONTROL, CDNS_MCP_CONTROL_CMD_ACCEPT,
+CDNS_MCP_CONTROL_CMD_ACCEPT);
if (!bus_reset) {
--
2.17.1
Re: [PATCH V3 1/3] vDPA/ifcvf: deduce VIRTIO device ID when probe
在 2021/4/16 下午3:16, Zhu Lingshan 写道:
This commit deduces VIRTIO device ID as device type when probe,
then ifcvf_vdpa_get_device_id() can simply return the ID.
ifcvf_vdpa_get_features() and ifcvf_vdpa_get_config_size()
can work properly based on the device ID.
Signed-off-by: Zhu Lingshan
---
drivers/vdpa/ifcvf/ifcvf_base.h | 1 +
drivers/vdpa/ifcvf/ifcvf_main.c | 30 ++
2 files changed, 19 insertions(+), 12 deletions(-)
diff --git a/drivers/vdpa/ifcvf/ifcvf_base.h b/drivers/vdpa/ifcvf/ifcvf_base.h
index b2eeb16b9c2c..1c04cd256fa7 100644
--- a/drivers/vdpa/ifcvf/ifcvf_base.h
+++ b/drivers/vdpa/ifcvf/ifcvf_base.h
@@ -84,6 +84,7 @@ struct ifcvf_hw {
u32 notify_off_multiplier;
u64 req_features;
u64 hw_features;
+ u32 dev_type;
struct virtio_pci_common_cfg __iomem *common_cfg;
void __iomem *net_cfg;
struct vring_info vring[IFCVF_MAX_QUEUE_PAIRS * 2];
diff --git a/drivers/vdpa/ifcvf/ifcvf_main.c b/drivers/vdpa/ifcvf/ifcvf_main.c
index 44d7586019da..469a9b5737b7 100644
--- a/drivers/vdpa/ifcvf/ifcvf_main.c
+++ b/drivers/vdpa/ifcvf/ifcvf_main.c
@@ -323,19 +323,9 @@ static u32 ifcvf_vdpa_get_generation(struct vdpa_device
*vdpa_dev)
static u32 ifcvf_vdpa_get_device_id(struct vdpa_device *vdpa_dev)
{
- struct ifcvf_adapter *adapter = vdpa_to_adapter(vdpa_dev);
- struct pci_dev *pdev = adapter->pdev;
- u32 ret = -ENODEV;
-
- if (pdev->device < 0x1000 || pdev->device > 0x107f)
- return ret;
-
- if (pdev->device < 0x1040)
- ret = pdev->subsystem_device;
- else
- ret = pdev->device - 0x1040;
+ struct ifcvf_hw *vf = vdpa_to_vf(vdpa_dev);
- return ret;
+ return vf->dev_type;
}
static u32 ifcvf_vdpa_get_vendor_id(struct vdpa_device *vdpa_dev)
@@ -466,6 +456,22 @@ static int ifcvf_probe(struct pci_dev *pdev, const struct
pci_device_id *id)
pci_set_drvdata(pdev, adapter);
vf = >vf;
+
+ /* This drirver drives both modern virtio devices and transitional
+* devices in modern mode.
+* vDPA requires feature bit VIRTIO_F_ACCESS_PLATFORM,
+* so legacy devices and transitional devices in legacy
+* mode will not work for vDPA, this driver will not
+* drive devices with legacy interface.
+*/
+ if (pdev->device < 0x1000 || pdev->device > 0x107f)
+ return -EOPNOTSUPP;
So this seems useless, id_table has already did that for us:
The driver supports:
#define IFCVF_DEVICE_ID 0x1041
and
#define C5000X_PL_BLK_DEVICE_ID 0x1001
I think we can never reach the condition above.
Thanks
+
+ if (pdev->device < 0x1040)
+ vf->dev_type = pdev->subsystem_device;
+ else
+ vf->dev_type = pdev->device - 0x1040;
+
vf->base = pcim_iomap_table(pdev);
adapter->pdev = pdev;
Re: [PATCHv2 2/2] iommu/arm-smmu-qcom: Move the adreno smmu specific impl earlier
On 2021-04-05 14:12, Sai Prakash Ranjan wrote: Hi Bjorn, On 2021-03-25 20:35, Will Deacon wrote: On Thu, Mar 25, 2021 at 01:10:12PM +0530, Sai Prakash Ranjan wrote: ... I think there is consensus on this series. I can resend if required but it still applies cleanly, let me know if you have any comments? Please resend with the bindings patch, and I'd like Bjorn's Ack as well. Can we have your review/ack in case there is nothing pending here? Gentle Ping! Thanks, Sai -- QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
[PATCH] ALSA: hda/realtek: GA503 use same quirks as GA401
The GA503 has almost exactly the same default setup as the GA401
model with the same issues. The GA401 quirks solve all the issues
so we will use the full quirk chain.
Signed-off-by: Luke D Jones
---
sound/pci/hda/patch_realtek.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c
index 290645516313..9a5546df1e6a 100644
--- a/sound/pci/hda/patch_realtek.c
+++ b/sound/pci/hda/patch_realtek.c
@@ -8019,6 +8019,7 @@ static const struct snd_pci_quirk alc269_fixup_tbl[] = {
SND_PCI_QUIRK(0x1043, 0x1ccd, "ASUS X555UB", ALC256_FIXUP_ASUS_MIC),
SND_PCI_QUIRK(0x1043, 0x1d4e, "ASUS TM420", ALC256_FIXUP_ASUS_HPE),
SND_PCI_QUIRK(0x1043, 0x1e11, "ASUS Zephyrus G15",
ALC289_FIXUP_ASUS_GA502),
+ SND_PCI_QUIRK(0x1043, 0x1e8e, "ASUS Zephyrus G15",
ALC289_FIXUP_ASUS_GA401),
SND_PCI_QUIRK(0x1043, 0x1f11, "ASUS Zephyrus G14",
ALC289_FIXUP_ASUS_GA401),
SND_PCI_QUIRK(0x1043, 0x1881, "ASUS Zephyrus S/M",
ALC294_FIXUP_ASUS_GX502_PINS),
SND_PCI_QUIRK(0x1043, 0x3030, "ASUS ZN270IE",
ALC256_FIXUP_ASUS_AIO_GPIO2),
--
2.31.1
Re: [Patch v2 3/7] crypto: qce: Add mode for rfc4309
On Sat 17 Apr 08:24 CDT 2021, Thara Gopinath wrote: > rf4309 is the specification that uses aes ccm algorithms with IPsec > security packets. Add a submode to identify rfc4309 ccm(aes) algorithm > in the crypto driver. > Reviewed-by: Bjorn Andersson > Signed-off-by: Thara Gopinath > --- > > v1->v2: > - Moved up the QCE_ENCRYPT AND QCE_DECRYPT bit positions so that > addition of other algorithms in future will not affect these > macros. > > drivers/crypto/qce/common.h | 7 +-- > 1 file changed, 5 insertions(+), 2 deletions(-) > > diff --git a/drivers/crypto/qce/common.h b/drivers/crypto/qce/common.h > index 3bc244bcca2d..b135440bf72b 100644 > --- a/drivers/crypto/qce/common.h > +++ b/drivers/crypto/qce/common.h > @@ -51,9 +51,11 @@ > #define QCE_MODE_CCM BIT(12) > #define QCE_MODE_MASKGENMASK(12, 8) > > +#define QCE_MODE_CCM_RFC4309 BIT(13) > + > /* cipher encryption/decryption operations */ > -#define QCE_ENCRYPT BIT(13) > -#define QCE_DECRYPT BIT(14) > +#define QCE_ENCRYPT BIT(30) > +#define QCE_DECRYPT BIT(31) > > #define IS_DES(flags)(flags & QCE_ALG_DES) > #define IS_3DES(flags) (flags & QCE_ALG_3DES) > @@ -73,6 +75,7 @@ > #define IS_CTR(mode) (mode & QCE_MODE_CTR) > #define IS_XTS(mode) (mode & QCE_MODE_XTS) > #define IS_CCM(mode) (mode & QCE_MODE_CCM) > +#define IS_CCM_RFC4309(mode) ((mode) & QCE_MODE_CCM_RFC4309) > > #define IS_ENCRYPT(dir) (dir & QCE_ENCRYPT) > #define IS_DECRYPT(dir) (dir & QCE_DECRYPT) > -- > 2.25.1 >
Re: [Patch v2 1/7] crypto: qce: common: Add MAC failed error checking
On Sat 17 Apr 08:24 CDT 2021, Thara Gopinath wrote: > MAC_FAILED gets set in the status register if authenthication fails > for ccm algorithms(during decryption). Add support to catch and flag > this error. > Reviewed-by: Bjorn Andersson Regards, Bjorn > Signed-off-by: Thara Gopinath > --- > > v1->v2: > - Split the error checking for -ENXIO and -EBADMSG into if-else clause > so that the code is more readable as per Bjorn's review comment. > > drivers/crypto/qce/common.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/drivers/crypto/qce/common.c b/drivers/crypto/qce/common.c > index dceb9579d87a..dd76175d5c62 100644 > --- a/drivers/crypto/qce/common.c > +++ b/drivers/crypto/qce/common.c > @@ -419,6 +419,8 @@ int qce_check_status(struct qce_device *qce, u32 *status) >*/ > if (*status & STATUS_ERRORS || !(*status & BIT(OPERATION_DONE_SHIFT))) > ret = -ENXIO; > + else if (*status & BIT(MAC_FAILED_SHIFT)) > + ret = -EBADMSG; > > return ret; > } > -- > 2.25.1 >
Re: [PATCH] lsm:fix a missing-check bug in smack_sb_eat_lsm_opts()
On Fri, 16 Apr 2021 13:36:01 +
Al Viro wrote:
> On Fri, Apr 16, 2021 at 05:53:03PM +0800, ?0?2Zhongjun Tan wrote:
>
> > @@ -710,13 +711,14 @@ static int smack_sb_eat_lsm_opts(char
> > *options, void **mnt_opts) token = match_opt_prefix(from, len,
> > ); if (token != Opt_error) {
> > arg = kmemdup_nul(arg, from + len - arg,
> > GFP_KERNEL);
> > + if (!arg) {
> > + rc = -ENOMEM;
> > + goto free_mnt_opts;
> > rc = smack_add_opt(token, arg, mnt_opts);
>
> if (arg)
> rc = smack_add_opt(token, arg,
> mnt_opts); else
> rc = -ENOMEM;
>
> and no other changes are needed anywhere...
update patch v3 , just four codes and no other changes are needed.
[PATCH v3] lsm:fix a missing-check bug in smack_sb_eat_lsm_opts()
From: Zhongjun Tan
In smack_sb_eat_lsm_opts(), 'arg' is allocated by kmemdup_nul().
It returns NULL when fails. So 'arg' should be checked. And 'mnt_opts'
should be freed when error.
Signed-off-by: Zhongjun Tan
---
changes in v1:
update the commit information.
changes in v2:
fix brace error
changes in v3:
As viro said, just four codes and no other changes are needed.
security/smack/smack_lsm.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/security/smack/smack_lsm.c b/security/smack/smack_lsm.c
index 223a6da..020929f 100644
--- a/security/smack/smack_lsm.c
+++ b/security/smack/smack_lsm.c
@@ -710,7 +710,10 @@ static int smack_sb_eat_lsm_opts(char *options, void
**mnt_opts)
token = match_opt_prefix(from, len, );
if (token != Opt_error) {
arg = kmemdup_nul(arg, from + len - arg, GFP_KERNEL);
- rc = smack_add_opt(token, arg, mnt_opts);
+ if (arg)
+ rc = smack_add_opt(token, arg, mnt_opts);
+ else
+ rc = -ENOMEM;
if (unlikely(rc)) {
kfree(arg);
if (*mnt_opts)
--
1.9.1
Re: [PATCH v2 0/1] arm: topology: parse the topology from the dt
Dietmar Eggemann 于2021年4月17日周六 上午1:00写道：
>
> On 16/04/2021 13:04, Ruifeng Zhang wrote:
> > Dietmar Eggemann 于2021年4月16日周五 下午6:39写道：
> >>
> >> On 16/04/2021 11:32, Valentin Schneider wrote:
> >>> On 16/04/21 15:47, Ruifeng Zhang wrote:
>
> [...]
>
> >> I'm confused. Do you have the MT bit set to 1 then? So the issue that
> >> the mpidr handling in arm32's store_cpu_topology() is not correct does
> >> not exist?
> >
> > I have reconfirmed it, the MT bit has been set to 1. I am sorry for
> > the previous messages.
> > The mpidr parse by store_cpu_topology is correct, at least for the sc9863a.
>
> Nice! This is sorted then.
>
> [...]
>
> >> Is this what you need for your arm32 kernel system? Adding the
> >> possibility to parse cpu-map to create Phantom Domains?
> >
> > Yes, I need parse DT cpu-map to create different Phantom Domains.
> > With it, the dts should be change to:
> > cpu-map {
> > cluster0 {
> > core0 {
> > cpu = <>;
> > };
> > core1 {
> > cpu = <>;
> > };
> > core2 {
> > cpu = <>;
> > };
> > core3 {
> > cpu = <>;
> > };
> > };
> >
> > cluster1 {
> > core0 {
> > cpu = <>;
> > };
> > core1 {
> > cpu = <>;
> > };
> > core2 {
> > cpu = <>;
> > };
> > core3 {
> > cpu = <>;
> > };
> > };
> > };
> >
>
> I'm afraid that this is now a much weaker case to get this into
> mainline.
But it's still a problem and it's not break the original logic ( parse
topology from MPIDR or parse capacity ), only add the support for
parse topology from DT.
I think it should still be merged into the mainline. If don't, the
DynamIQ SoC has some issue in sched and cpufreq.
>
> I'm able to run with an extra cpu-map entry:
Great.
>
> diff --git a/arch/arm/boot/dts/vexpress-v2p-ca15_a7.dts
> b/arch/arm/boot/dts/vexpress-v2p-ca15_a7.dts
> index 012d40a7228c..f60d9b448253 100644
> --- a/arch/arm/boot/dts/vexpress-v2p-ca15_a7.dts
> +++ b/arch/arm/boot/dts/vexpress-v2p-ca15_a7.dts
> @@ -35,6 +35,29 @@ cpus {
> #address-cells = <1>;
> #size-cells = <0>;
>
> + cpu-map {
> + cluster0 {
> + core0 {
> + cpu = <>;
> + };
> + core1 {
> + cpu = <>;
> + };
> + };
> +
> + cluster1 {
> + core0 {
> + cpu = <>;
> + };
> + core1 {
> + cpu = <>;
> + };
> + core2 {
> + cpu = <>;
> + };
> + };
> + };
> +
> cpu0: cpu@0 {
>
> a condensed version (see below) of your patch on my Arm32 TC2.
> The move of update_cpu_capacity() in store_cpu_topology() is only
> necessary when I use the old clock-frequency based cpu_efficiency
> approach for asymmetric CPU capacity (TC2 is a15/a7):
>
> diff --git a/arch/arm/boot/dts/vexpress-v2p-ca15_a7.dts
> b/arch/arm/boot/dts/vexpress-v2p-ca15_a7.dts
> index f60d9b448253..e0679cca40ed 100644
> --- a/arch/arm/boot/dts/vexpress-v2p-ca15_a7.dts
> +++ b/arch/arm/boot/dts/vexpress-v2p-ca15_a7.dts
> @@ -64,7 +64,7 @@ cpu0: cpu@0 {
> reg = <0>;
> cci-control-port = <_control1>;
> cpu-idle-states = <_SLEEP_BIG>;
> - capacity-dmips-mhz = <1024>;
> + clock-frequency = <10>;
> dynamic-power-coefficient = <990>;
> };
>
> @@ -74,7 +74,7 @@ cpu1: cpu@1 {
> reg = <1>;
> cci-control-port = <_control1>;
> cpu-idle-states = <_SLEEP_BIG>;
> - capacity-dmips-mhz = <1024>;
> +
Re: [PATCH v2 2/5] mm/swapfile: use percpu_ref to serialize against concurrent swapoff
Miaohe Lin writes:
> Use percpu_ref to serialize against concurrent swapoff. Also remove the
> SWP_VALID flag because it's used together with RCU solution.
>
> Signed-off-by: Miaohe Lin
> ---
> include/linux/swap.h | 3 +--
> mm/swapfile.c| 43 +--
> 2 files changed, 18 insertions(+), 28 deletions(-)
>
> diff --git a/include/linux/swap.h b/include/linux/swap.h
> index 8be36eb58b7a..993693b38109 100644
> --- a/include/linux/swap.h
> +++ b/include/linux/swap.h
> @@ -177,7 +177,6 @@ enum {
> SWP_PAGE_DISCARD = (1 << 10), /* freed swap page-cluster discards */
> SWP_STABLE_WRITES = (1 << 11), /* no overwrite PG_writeback pages */
> SWP_SYNCHRONOUS_IO = (1 << 12), /* synchronous IO is efficient */
> - SWP_VALID = (1 << 13),/* swap is valid to be operated on? */
> /* add others here before... */
> SWP_SCANNING= (1 << 14),/* refcount in scan_swap_map */
> };
> @@ -514,7 +513,7 @@ sector_t swap_page_sector(struct page *page);
>
> static inline void put_swap_device(struct swap_info_struct *si)
> {
> - rcu_read_unlock();
> + percpu_ref_put(>users);
> }
>
> #else /* CONFIG_SWAP */
> diff --git a/mm/swapfile.c b/mm/swapfile.c
> index 66515a3a2824..90e197bc2eeb 100644
> --- a/mm/swapfile.c
> +++ b/mm/swapfile.c
> @@ -1279,18 +1279,12 @@ static unsigned char __swap_entry_free_locked(struct
> swap_info_struct *p,
> * via preventing the swap device from being swapoff, until
> * put_swap_device() is called. Otherwise return NULL.
> *
> - * The entirety of the RCU read critical section must come before the
> - * return from or after the call to synchronize_rcu() in
> - * enable_swap_info() or swapoff(). So if "si->flags & SWP_VALID" is
> - * true, the si->map, si->cluster_info, etc. must be valid in the
> - * critical section.
> - *
> * Notice that swapoff or swapoff+swapon can still happen before the
> - * rcu_read_lock() in get_swap_device() or after the rcu_read_unlock()
> - * in put_swap_device() if there isn't any other way to prevent
> - * swapoff, such as page lock, page table lock, etc. The caller must
> - * be prepared for that. For example, the following situation is
> - * possible.
> + * percpu_ref_tryget_live() in get_swap_device() or after the
> + * percpu_ref_put() in put_swap_device() if there isn't any other way
> + * to prevent swapoff, such as page lock, page table lock, etc. The
> + * caller must be prepared for that. For example, the following
> + * situation is possible.
> *
> * CPU1CPU2
> * do_swap_page()
> @@ -1318,21 +1312,24 @@ struct swap_info_struct *get_swap_device(swp_entry_t
> entry)
> si = swp_swap_info(entry);
> if (!si)
> goto bad_nofile;
> -
> - rcu_read_lock();
> - if (data_race(!(si->flags & SWP_VALID)))
> - goto unlock_out;
> + if (!percpu_ref_tryget_live(>users))
> + goto out;
> + /*
> + * Guarantee we will not reference uninitialized fields
> + * of swap_info_struct.
> + */
/*
* Guarantee the si->users are checked before accessing other fields of
* swap_info_struct.
*/
> + smp_rmb();
Usually, smp_rmb() need to be paired with smp_wmb(). Some comments are
needed for that. Here smb_rmb() is paired with the spin_unlock() after
setup_swap_info() in enable_swap_info().
> offset = swp_offset(entry);
> if (offset >= si->max)
> - goto unlock_out;
> + goto put_out;
>
> return si;
> bad_nofile:
> pr_err("%s: %s%08lx\n", __func__, Bad_file, entry.val);
> out:
> return NULL;
> -unlock_out:
> - rcu_read_unlock();
> +put_out:
> + percpu_ref_put(>users);
> return NULL;
> }
>
> @@ -2475,7 +2472,7 @@ static void setup_swap_info(struct swap_info_struct *p,
> int prio,
>
> static void _enable_swap_info(struct swap_info_struct *p)
> {
> - p->flags |= SWP_WRITEOK | SWP_VALID;
> + p->flags |= SWP_WRITEOK;
> atomic_long_add(p->pages, _swap_pages);
> total_swap_pages += p->pages;
>
> @@ -2507,7 +2504,7 @@ static void enable_swap_info(struct swap_info_struct
> *p, int prio,
> spin_unlock(_lock);
> /*
>* Guarantee swap_map, cluster_info, etc. fields are valid
> - * between get/put_swap_device() if SWP_VALID bit is set
> + * between get/put_swap_device().
>*/
The comments need to be revised. Something likes below?
/* Finished initialized swap device, now it's safe to reference it */
Best Regards,
Huang, Ying
> percpu_ref_resurrect(>users);
> spin_lock(_lock);
> @@ -2625,12 +2622,6 @@ SYSCALL_DEFINE1(swapoff, const char __user *,
> specialfile)
>
> reenable_swap_slots_cache_unlock();
>
> - spin_lock(_lock);
> - spin_lock(>lock);
> - p->flags &= ~SWP_VALID; /* mark swap device as invalid */
> - spin_unlock(>lock);
> -
[PATCH 2/2] arm64: dts: allwinner: Enforce consistent MMC numbering
Traditionally, the sunxi-mmc device numbers matched the register address
order. However, that was broken by asynchronous probe, and now the MMC
device numbers are not deterministic. Add aliases to keep the device
numbers consistent between boots. Use the traditional order, since there
is no need to change it.
Signed-off-by: Samuel Holland
---
arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 6 ++
arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi | 6 ++
2 files changed, 12 insertions(+)
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
index 9b58cfbefa6d..3df70a41b3b9 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
@@ -17,6 +17,12 @@ / {
#address-cells = <1>;
#size-cells = <1>;
+ aliases {
+ mmc0 =
+ mmc1 =
+ mmc2 =
+ };
+
chosen {
#address-cells = <1>;
#size-cells = <1>;
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi
b/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi
index d8ebc1a84af9..4bdc48caf68a 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi
+++ b/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi
@@ -16,6 +16,12 @@ / {
#address-cells = <1>;
#size-cells = <1>;
+ aliases {
+ mmc0 =
+ mmc1 =
+ mmc2 =
+ };
+
cpus {
#address-cells = <1>;
#size-cells = <0>;
--
2.26.3
[PATCH 1/2] ARM: dts: sunxi: h3/h5: Enforce consistent MMC numbering
Traditionally, the sunxi-mmc device numbers matched the register address
order. However, that was broken by asynchronous probe, and now the MMC
device numbers are not deterministic. Add aliases to keep the device
numbers consistent between boots. Use the traditional order, since there
is no need to change it.
Signed-off-by: Samuel Holland
---
arch/arm/boot/dts/sunxi-h3-h5.dtsi | 6 ++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/boot/dts/sunxi-h3-h5.dtsi
b/arch/arm/boot/dts/sunxi-h3-h5.dtsi
index e27399aa052c..1cb669c835bd 100644
--- a/arch/arm/boot/dts/sunxi-h3-h5.dtsi
+++ b/arch/arm/boot/dts/sunxi-h3-h5.dtsi
@@ -53,6 +53,12 @@ / {
#address-cells = <1>;
#size-cells = <1>;
+ aliases {
+ mmc0 =
+ mmc1 =
+ mmc2 =
+ };
+
chosen {
#address-cells = <1>;
#size-cells = <1>;
--
2.26.3
[PATCH 0/2] sunxi: Enforce consistent MMC numbering
Dealing with the inconsistent numbering has been a major pain, and there is a solution with (as far as I can tell) no tangible downsides. So let's use it. Yes, I know the kernel supports UUIDs for root=. But UUIDs do not help when referencing the whole, unpartitioned device, like is needed for updating the bootloader and firmware. So for the use case of "write a bootloader to the SD card, regardless of where the board is currently booted from", I know of two options: - Dig around in sysfs to find the mmc number from the MMIO address, which means I have to know the MMIO addresses for every SoC, or - Apply patches like these. Samuel Holland (2): ARM: dts: sunxi: h3/h5: Enforce consistent MMC numbering arm64: dts: allwinner: Enforce consistent MMC numbering arch/arm/boot/dts/sunxi-h3-h5.dtsi| 6 ++ arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 6 ++ arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi | 6 ++ 3 files changed, 18 insertions(+) -- 2.26.3
Re: [PATCH v2 1/5] mm/swapfile: add percpu_ref support for swap
Miaohe Lin writes:
> We will use percpu-refcount to serialize against concurrent swapoff. This
> patch adds the percpu_ref support for swap.
>
> Signed-off-by: Miaohe Lin
> ---
> include/linux/swap.h | 3 +++
> mm/swapfile.c| 33 +
> 2 files changed, 32 insertions(+), 4 deletions(-)
>
> diff --git a/include/linux/swap.h b/include/linux/swap.h
> index 144727041e78..8be36eb58b7a 100644
> --- a/include/linux/swap.h
> +++ b/include/linux/swap.h
> @@ -240,6 +240,7 @@ struct swap_cluster_list {
> * The in-memory structure used to track swap areas.
> */
> struct swap_info_struct {
> + struct percpu_ref users;/* serialization against concurrent
> swapoff */
The comments aren't general enough. We use this to check whether the
swap device has been fully initialized, etc. May be something as below?
/* indicate and keep swap device valid */
> unsigned long flags; /* SWP_USED etc: see above */
> signed shortprio; /* swap priority of this type */
> struct plist_node list; /* entry in swap_active_head */
> @@ -260,6 +261,8 @@ struct swap_info_struct {
> struct block_device *bdev; /* swap device or bdev of swap file */
> struct file *swap_file; /* seldom referenced */
> unsigned int old_block_size;/* seldom referenced */
> + bool ref_initialized; /* seldom referenced */
> + struct completion comp; /* seldom referenced */
> #ifdef CONFIG_FRONTSWAP
> unsigned long *frontswap_map; /* frontswap in-use, one bit per page */
> atomic_t frontswap_pages; /* frontswap pages in-use counter */
> diff --git a/mm/swapfile.c b/mm/swapfile.c
> index 149e77454e3c..66515a3a2824 100644
> --- a/mm/swapfile.c
> +++ b/mm/swapfile.c
> @@ -39,6 +39,7 @@
> #include
> #include
> #include
> +#include
>
> #include
> #include
> @@ -511,6 +512,14 @@ static void swap_discard_work(struct work_struct *work)
> spin_unlock(>lock);
> }
>
> +static void swap_users_ref_free(struct percpu_ref *ref)
> +{
> + struct swap_info_struct *si;
> +
> + si = container_of(ref, struct swap_info_struct, users);
> + complete(>comp);
> +}
> +
> static void alloc_cluster(struct swap_info_struct *si, unsigned long idx)
> {
> struct swap_cluster_info *ci = si->cluster_info;
> @@ -2500,7 +2509,7 @@ static void enable_swap_info(struct swap_info_struct
> *p, int prio,
>* Guarantee swap_map, cluster_info, etc. fields are valid
>* between get/put_swap_device() if SWP_VALID bit is set
>*/
> - synchronize_rcu();
You cannot remove this without changing get/put_swap_device(). It's
better to squash at least PATCH 1-2.
> + percpu_ref_resurrect(>users);
> spin_lock(_lock);
> spin_lock(>lock);
> _enable_swap_info(p);
> @@ -2621,11 +2630,18 @@ SYSCALL_DEFINE1(swapoff, const char __user *,
> specialfile)
> p->flags &= ~SWP_VALID; /* mark swap device as invalid */
> spin_unlock(>lock);
> spin_unlock(_lock);
> +
> + percpu_ref_kill(>users);
> /*
> - * wait for swap operations protected by get/put_swap_device()
> - * to complete
> + * We need synchronize_rcu() here to protect the accessing
> + * to the swap cache data structure.
>*/
> synchronize_rcu();
> + /*
> + * Wait for swap operations protected by get/put_swap_device()
> + * to complete.
> + */
I think the comments (after some revision) can be moved before
percpu_ref_kill(). The synchronize_rcu() comments can be merged.
> + wait_for_completion(>comp);
>
> flush_work(>discard_work);
>
> @@ -3132,7 +3148,7 @@ static bool swap_discardable(struct swap_info_struct
> *si)
> SYSCALL_DEFINE2(swapon, const char __user *, specialfile, int, swap_flags)
> {
> struct swap_info_struct *p;
> - struct filename *name;
> + struct filename *name = NULL;
> struct file *swap_file = NULL;
> struct address_space *mapping;
> int prio;
> @@ -3163,6 +3179,15 @@ SYSCALL_DEFINE2(swapon, const char __user *,
> specialfile, int, swap_flags)
>
> INIT_WORK(>discard_work, swap_discard_work);
>
> + if (!p->ref_initialized) {
I don't think it's necessary to add another flag p->ref_initialized. We
can distinguish newly allocated and reused swap_info_struct in
alloc_swap_info().
Best Regards,
Huang, Ying
> + error = percpu_ref_init(>users, swap_users_ref_free,
> + PERCPU_REF_INIT_DEAD, GFP_KERNEL);
> + if (unlikely(error))
> + goto bad_swap;
> + init_completion(>comp);
> + p->ref_initialized = true;
> + }
> +
> name = getname(specialfile);
> if (IS_ERR(name)) {
> error = PTR_ERR(name);
Re: [PATCH v2 6/6] riscv: dts: Add PCIe support for the SiFive FU740-C000 SoC
Greentime Hu 於 2021年4月19日 週一 上午10:43寫道：
>
> Palmer Dabbelt 於 2021年3月31日 週三 上午8:24寫道：
> >
> > On Wed, 17 Mar 2021 23:08:13 PDT (-0700), greentime...@sifive.com wrote:
> > > Signed-off-by: Greentime Hu
> > > ---
> > > arch/riscv/boot/dts/sifive/fu740-c000.dtsi | 34 ++
> > > 1 file changed, 34 insertions(+)
> > >
> > > diff --git a/arch/riscv/boot/dts/sifive/fu740-c000.dtsi
> > > b/arch/riscv/boot/dts/sifive/fu740-c000.dtsi
> > > index d1bb22b11920..d0839739b425 100644
> > > --- a/arch/riscv/boot/dts/sifive/fu740-c000.dtsi
> > > +++ b/arch/riscv/boot/dts/sifive/fu740-c000.dtsi
> > > @@ -158,6 +158,7 @@ prci: clock-controller@1000 {
> > > reg = <0x0 0x1000 0x0 0x1000>;
> > > clocks = <>, <>;
> > > #clock-cells = <1>;
> > > + #reset-cells = <1>;
> > > };
> > > uart0: serial@1001 {
> > > compatible = "sifive,fu740-c000-uart",
> > > "sifive,uart0";
> > > @@ -288,5 +289,38 @@ gpio: gpio@1006 {
> > > clocks = < PRCI_CLK_PCLK>;
> > > status = "disabled";
> > > };
> > > + pcie@e {
> > > + #address-cells = <3>;
> > > + #interrupt-cells = <1>;
> > > + #num-lanes = <8>;
> > > + #size-cells = <2>;
> > > + compatible = "sifive,fu740-pcie";
> > > + reg = <0xe 0x 0x1 0x0
> > > +0xd 0xf000 0x0 0x1000
> > > +0x0 0x100d 0x0 0x1000>;
> > > + reg-names = "dbi", "config", "mgmt";
> > > + device_type = "pci";
> > > + dma-coherent;
> > > + bus-range = <0x0 0xff>;
> > > + ranges = <0x8100 0x0 0x6008 0x0
> > > 0x6008 0x0 0x1/* I/O */
> > > + 0x8200 0x0 0x6009 0x0
> > > 0x6009 0x0 0xff7 /* mem */
> > > + 0x8200 0x0 0x7000 0x0
> > > 0x7000 0x0 0x100 /* mem */
> > > + 0xc300 0x20 0x 0x20
> > > 0x 0x20 0x>; /* mem prefetchable */
> > > + num-lanes = <0x8>;
> > > + interrupts = <56 57 58 59 60 61 62 63 64>;
> > > + interrupt-names = "msi", "inta", "intb", "intc",
> > > "intd";
> > > + interrupt-parent = <>;
> > > + interrupt-map-mask = <0x0 0x0 0x0 0x7>;
> > > + interrupt-map = <0x0 0x0 0x0 0x1 57>,
> > > + <0x0 0x0 0x0 0x2 58>,
> > > + <0x0 0x0 0x0 0x3 59>,
> > > + <0x0 0x0 0x0 0x4 60>;
> > > + clock-names = "pcie_aux";
> > > + clocks = < PRCI_CLK_PCIE_AUX>;
> > > + pwren-gpios = < 5 0>;
> > > + perstn-gpios = < 8 0>;
> > > + resets = < 4>;
> > > + status = "okay";
> > > + };
> > > };
> > > };
> >
> > Acked-by: Palmer Dabbelt
> >
> > I'm happy to take these all through the RISC-V tree if that helps, but
> > as usual I'd like reviews or acks from the subsystem maintainers. It
> > looks like there are some issues so I'm going to drop this from my
> > inbox.
>
> Hi Palmer,
>
> Since the subsystem maintainer has pick the first 5 patches to his
> branch, would you please help to pick the 6th patch of version 6?
Sorry there is no version 6, I mean version 5. :p
> Thank you. :)
>
> https://www.spinics.net/lists/linux-clk/msg57213.html
> https://patchwork.kernel.org/project/linux-riscv/patch/20210406092634.50465-7-greentime...@sifive.com/
Re: [PATCH v2 6/6] riscv: dts: Add PCIe support for the SiFive FU740-C000 SoC
Palmer Dabbelt 於 2021年3月31日 週三 上午8:24寫道：
>
> On Wed, 17 Mar 2021 23:08:13 PDT (-0700), greentime...@sifive.com wrote:
> > Signed-off-by: Greentime Hu
> > ---
> > arch/riscv/boot/dts/sifive/fu740-c000.dtsi | 34 ++
> > 1 file changed, 34 insertions(+)
> >
> > diff --git a/arch/riscv/boot/dts/sifive/fu740-c000.dtsi
> > b/arch/riscv/boot/dts/sifive/fu740-c000.dtsi
> > index d1bb22b11920..d0839739b425 100644
> > --- a/arch/riscv/boot/dts/sifive/fu740-c000.dtsi
> > +++ b/arch/riscv/boot/dts/sifive/fu740-c000.dtsi
> > @@ -158,6 +158,7 @@ prci: clock-controller@1000 {
> > reg = <0x0 0x1000 0x0 0x1000>;
> > clocks = <>, <>;
> > #clock-cells = <1>;
> > + #reset-cells = <1>;
> > };
> > uart0: serial@1001 {
> > compatible = "sifive,fu740-c000-uart", "sifive,uart0";
> > @@ -288,5 +289,38 @@ gpio: gpio@1006 {
> > clocks = < PRCI_CLK_PCLK>;
> > status = "disabled";
> > };
> > + pcie@e {
> > + #address-cells = <3>;
> > + #interrupt-cells = <1>;
> > + #num-lanes = <8>;
> > + #size-cells = <2>;
> > + compatible = "sifive,fu740-pcie";
> > + reg = <0xe 0x 0x1 0x0
> > +0xd 0xf000 0x0 0x1000
> > +0x0 0x100d 0x0 0x1000>;
> > + reg-names = "dbi", "config", "mgmt";
> > + device_type = "pci";
> > + dma-coherent;
> > + bus-range = <0x0 0xff>;
> > + ranges = <0x8100 0x0 0x6008 0x0 0x6008
> > 0x0 0x1/* I/O */
> > + 0x8200 0x0 0x6009 0x0 0x6009
> > 0x0 0xff7 /* mem */
> > + 0x8200 0x0 0x7000 0x0 0x7000
> > 0x0 0x100 /* mem */
> > + 0xc300 0x20 0x 0x20 0x
> > 0x20 0x>; /* mem prefetchable */
> > + num-lanes = <0x8>;
> > + interrupts = <56 57 58 59 60 61 62 63 64>;
> > + interrupt-names = "msi", "inta", "intb", "intc",
> > "intd";
> > + interrupt-parent = <>;
> > + interrupt-map-mask = <0x0 0x0 0x0 0x7>;
> > + interrupt-map = <0x0 0x0 0x0 0x1 57>,
> > + <0x0 0x0 0x0 0x2 58>,
> > + <0x0 0x0 0x0 0x3 59>,
> > + <0x0 0x0 0x0 0x4 60>;
> > + clock-names = "pcie_aux";
> > + clocks = < PRCI_CLK_PCIE_AUX>;
> > + pwren-gpios = < 5 0>;
> > + perstn-gpios = < 8 0>;
> > + resets = < 4>;
> > + status = "okay";
> > + };
> > };
> > };
>
> Acked-by: Palmer Dabbelt
>
> I'm happy to take these all through the RISC-V tree if that helps, but
> as usual I'd like reviews or acks from the subsystem maintainers. It
> looks like there are some issues so I'm going to drop this from my
> inbox.
Hi Palmer,
Since the subsystem maintainer has pick the first 5 patches to his
branch, would you please help to pick the 6th patch of version 6?
Thank you. :)
https://www.spinics.net/lists/linux-clk/msg57213.html
https://patchwork.kernel.org/project/linux-riscv/patch/20210406092634.50465-7-greentime...@sifive.com/
Re: [PATCH] kernel/hung_task: Add a whitelist and blacklist mechanism.
On 2021/04/19 11:22, 周传高 wrote: > Some SOC vendors' drivers or user-mode processes may be in D state for a long > time, > and normally they do not configure HUNG TASK, so we need to ignore these > tasks if > we use HUNG TASK. Isn't that a sign that the quality of the drivers and user-mode processes is poor? Wait should be killable/interruptible if possible (for better response to e.g. OOM-killer).
[PATCH v2 3/3] mm,hwpoison: add kill_accessing_process() to find error virtual address
> > 2. In the function hwpoison_pte_range():
> > if (pfn <= hwp->pfn && hwp->pfn < pfn + PMD_SIZE) this check seem we should
> > use PMD_SIZE/PAGE_SIZE or some macro like this?
>
> Thanks, that's right. HPAGE_PMD_NR seems to fit here.
> We also need "#ifdef CONFIG_TRANSPARENT_HUGEPAGE" to use it.
I found that the #ifdef is not necessary because the whole
"if (ptl)" is compiled out. So I don't add #ifdef.
Here's the v2 of 3/3.
Aili, could you test with it?
Thanks,
Naoya Horiguchi
-
From: Naoya Horiguchi
Date: Tue, 13 Apr 2021 07:26:25 +0900
Subject: [PATCH v2 3/3] mm,hwpoison: add kill_accessing_process() to find error
virtual address
The previous patch solves the infinite MCE loop issue when multiple
MCE events races. The remaining issue is to make sure that all threads
processing Action Required MCEs send to the current processes the
SIGBUS with the proper virtual address and the error size.
This patch suggests to do page table walk to find the error virtual
address. If we find multiple virtual addresses in walking, we now can't
determine which one is correct, so we fall back to sending SIGBUS in
kill_me_maybe() without error info as we do now. This corner case needs
to be solved in the future.
Signed-off-by: Naoya Horiguchi
---
change log v1 -> v2:
- initialize local variables in check_hwpoisoned_entry() and
hwpoison_pte_range()
- fix and improve logic to calculate error address offset.
---
arch/x86/kernel/cpu/mce/core.c | 13 ++-
include/linux/swapops.h| 5 ++
mm/memory-failure.c| 147 -
3 files changed, 161 insertions(+), 4 deletions(-)
diff --git a/arch/x86/kernel/cpu/mce/core.c b/arch/x86/kernel/cpu/mce/core.c
index 7962355436da..3ce23445a48c 100644
--- a/arch/x86/kernel/cpu/mce/core.c
+++ b/arch/x86/kernel/cpu/mce/core.c
@@ -1257,19 +1257,28 @@ static void kill_me_maybe(struct callback_head *cb)
{
struct task_struct *p = container_of(cb, struct task_struct,
mce_kill_me);
int flags = MF_ACTION_REQUIRED;
+ int ret;
pr_err("Uncorrected hardware memory error in user-access at %llx",
p->mce_addr);
if (!p->mce_ripv)
flags |= MF_MUST_KILL;
- if (!memory_failure(p->mce_addr >> PAGE_SHIFT, flags) &&
- !(p->mce_kflags & MCE_IN_KERNEL_COPYIN)) {
+ ret = memory_failure(p->mce_addr >> PAGE_SHIFT, flags);
+ if (!ret && !(p->mce_kflags & MCE_IN_KERNEL_COPYIN)) {
set_mce_nospec(p->mce_addr >> PAGE_SHIFT, p->mce_whole_page);
sync_core();
return;
}
+ /*
+* -EHWPOISON from memory_failure() means that it already sent SIGBUS
+* to the current process with the proper error info, so no need to
+* send it here again.
+*/
+ if (ret == -EHWPOISON)
+ return;
+
if (p->mce_vaddr != (void __user *)-1l) {
force_sig_mceerr(BUS_MCEERR_AR, p->mce_vaddr, PAGE_SHIFT);
} else {
diff --git a/include/linux/swapops.h b/include/linux/swapops.h
index d9b7c9132c2f..98ea67fcf360 100644
--- a/include/linux/swapops.h
+++ b/include/linux/swapops.h
@@ -323,6 +323,11 @@ static inline int is_hwpoison_entry(swp_entry_t entry)
return swp_type(entry) == SWP_HWPOISON;
}
+static inline unsigned long hwpoison_entry_to_pfn(swp_entry_t entry)
+{
+ return swp_offset(entry);
+}
+
static inline void num_poisoned_pages_inc(void)
{
atomic_long_inc(_poisoned_pages);
diff --git a/mm/memory-failure.c b/mm/memory-failure.c
index 368ef77e01f9..99dd4caf43cb 100644
--- a/mm/memory-failure.c
+++ b/mm/memory-failure.c
@@ -56,6 +56,7 @@
#include
#include
#include
+#include
#include "internal.h"
#include "ras/ras_event.h"
@@ -554,6 +555,142 @@ static void collect_procs(struct page *page, struct
list_head *tokill,
collect_procs_file(page, tokill, force_early);
}
+struct hwp_walk {
+ struct to_kill tk;
+ unsigned long pfn;
+ int flags;
+};
+
+static int set_to_kill(struct to_kill *tk, unsigned long addr, short shift)
+{
+ /* Abort pagewalk when finding multiple mappings to the error page. */
+ if (tk->addr)
+ return 1;
+ tk->addr = addr;
+ tk->size_shift = shift;
+ return 0;
+}
+
+static int check_hwpoisoned_entry(pte_t pte, unsigned long addr, short shift,
+ unsigned long poisoned_pfn, struct to_kill *tk)
+{
+ unsigned long pfn = 0;
+
+ if (pte_present(pte)) {
+ pfn = pte_pfn(pte);
+ } else {
+ swp_entry_t swp = pte_to_swp_entry(pte);
+
+ if (is_hwpoison_entry(swp))
+ pfn = hwpoison_entry_to_pfn(swp);
+ }
+
+ if (!pfn || pfn != poisoned_pfn)
+ return 0;
+
+ return set_to_kill(tk, addr, shift);
+}
+
+static int hwpoison_pte_range(pmd_t *pmdp, unsigned long addr,
+ unsigned
Re: [PATCH v2 12/12] docs: path-lookup: update symlink description
On Mon, Apr 19, 2021 at 9:59 AM NeilBrown wrote: > > On Tue, Mar 16 2021, Fox Chen wrote: > > > instead of lookup_real()/vfs_create(), i_op->lookup() and > > i_op->create() will be called directly. > > > > update vfs_open() logic > > > > should_follow_link is merged into lookup_last() or open_last_lookup() > > which returns symlink name instead of an integer. > > > > Signed-off-by: Fox Chen > > --- > > Documentation/filesystems/path-lookup.rst | 13 ++--- > > 1 file changed, 6 insertions(+), 7 deletions(-) > > > > diff --git a/Documentation/filesystems/path-lookup.rst > > b/Documentation/filesystems/path-lookup.rst > > index eef6e9f68fba..adbc714740c2 100644 > > --- a/Documentation/filesystems/path-lookup.rst > > +++ b/Documentation/filesystems/path-lookup.rst > > @@ -1202,16 +1202,15 @@ the code. > > it. If the file was found in the dcache, then ``vfs_open()`` is used > > for > > this. If not, then ``lookup_open()`` will either call > > ``atomic_open()`` (if > > the filesystem provides it) to combine the final lookup with the open, > > or > > - will perform the separate ``lookup_real()`` and ``vfs_create()`` steps > > + will perform the separate ``i_op->lookup()`` and ``i_op->create()`` > > steps > > directly. In the later case the actual "open" of this newly found or > > created file will be performed by ``vfs_open()``, just as if the name > > were found in the dcache. > > > > 2. ``vfs_open()`` can fail with ``-EOPENSTALE`` if the cached information > > - wasn't quite current enough. Rather than restarting the lookup from > > - the top with ``LOOKUP_REVAL`` set, ``lookup_open()`` is called instead, > > - giving the filesystem a chance to resolve small inconsistencies. > > - If that doesn't work, only then is the lookup restarted from the top. > > + wasn't quite current enough. If it's in RCU-walk -ECHILD will be > > returned > > + otherwise will return -ESTALE. When -ESTALE is returned, the caller may > > "otherwise -ESTALE is returned". > If you don't like repeating "is returned", then maybe: > "... -ECHILD will be returned, otherwise the result is -ESTALE". > > > > + retry with LOOKUP_REVAL flag set. > > > > 3. An open with O_CREAT **does** follow a symlink in the final component, > > unlike other creation system calls (like ``mkdir``). So the sequence:: > > @@ -1221,8 +1220,8 @@ the code. > > > > will create a file called ``/tmp/bar``. This is not permitted if > > ``O_EXCL`` is set but otherwise is handled for an O_CREAT open much > > - like for a non-creating open: ``should_follow_link()`` returns ``1``, > > and > > - so does ``do_last()`` so that ``trailing_symlink()`` gets called and the > > + like for a non-creating open: ``lookup_last()`` or > > ``open_last_lookup()`` > > + returns a non ``Null`` value, and ``link_path_walk()`` gets called and > > the > > "NULL", not "Null". > > This those changes, > Reviewed-by: NeilBrown > > Thanks for a lot of all these improvements!! and apologies for the delay > in the review. Thanks for the review, I will fix them and send the next version back. > Thanks, > NeilBrown > > > > open process continues on the symlink that was found. > > > > Updating the access time > > -- > > 2.30.2 thanks, fox
Re: [PATCH v2 01/12] docs: path-lookup: update follow_managed() part
On Mon, Apr 19, 2021 at 10:17 AM Matthew Wilcox wrote:
>
> On Tue, Mar 16, 2021 at 01:47:16PM +0800, Fox Chen wrote:
> > -In the absence of symbolic links, ``walk_component()`` creates a new
> > +As the last step of ``walk_component()``, ``step_into()`` will be called
> > either
>
> You can drop ``..`` from around function named which are followed with
> (). d74b0d31ddde ("Docs: An initial automarkup extension for sphinx")
> marks them up automatically.
>
Got it, thanks for letting me know. But I will still use them in this
patch series to keep consistency with the remaining parts of the
document.
thanks,
fox
[PATCH v2] hfsplus: prevent negative dentries when casefolded
hfsplus uses the case-insensitive filenames by default, but VFS negative
dentries are incompatible with case-insensitive. For example, the
following instructions will get a cached filename 'aaa' which isn't
expected. There is no such problem in macOS.
touch aaa
rm aaa
touch AAA
This patch takes the same approach to drop negative dentires as vfat does.
The dentry is revalidated without blocking and storing to the dentry,
and should be safe in rcu-walk.
Signed-off-by: Chung-Chiang Cheng
---
fs/hfsplus/hfsplus_fs.h | 1 +
fs/hfsplus/inode.c | 1 +
fs/hfsplus/unicode.c| 32
3 files changed, 34 insertions(+)
diff --git a/fs/hfsplus/hfsplus_fs.h b/fs/hfsplus/hfsplus_fs.h
index 12b20479ed2b..e4f0cdfdac96 100644
--- a/fs/hfsplus/hfsplus_fs.h
+++ b/fs/hfsplus/hfsplus_fs.h
@@ -528,6 +528,7 @@ int hfsplus_asc2uni(struct super_block *sb, struct
hfsplus_unistr *ustr,
int hfsplus_hash_dentry(const struct dentry *dentry, struct qstr *str);
int hfsplus_compare_dentry(const struct dentry *dentry, unsigned int len,
const char *str, const struct qstr *name);
+int hfsplus_revalidate_dentry(struct dentry *dentry, unsigned int flags);
/* wrapper.c */
int hfsplus_submit_bio(struct super_block *sb, sector_t sector, void *buf,
diff --git a/fs/hfsplus/inode.c b/fs/hfsplus/inode.c
index 078c5c8a5156..772cad371371 100644
--- a/fs/hfsplus/inode.c
+++ b/fs/hfsplus/inode.c
@@ -176,6 +176,7 @@ const struct address_space_operations hfsplus_aops = {
const struct dentry_operations hfsplus_dentry_operations = {
.d_hash = hfsplus_hash_dentry,
.d_compare= hfsplus_compare_dentry,
+ .d_revalidate = hfsplus_revalidate_dentry,
};
static void hfsplus_get_perms(struct inode *inode,
diff --git a/fs/hfsplus/unicode.c b/fs/hfsplus/unicode.c
index 73342c925a4b..e336631334eb 100644
--- a/fs/hfsplus/unicode.c
+++ b/fs/hfsplus/unicode.c
@@ -10,6 +10,7 @@
*/
#include
+#include
#include
#include "hfsplus_fs.h"
#include "hfsplus_raw.h"
@@ -518,3 +519,34 @@ int hfsplus_compare_dentry(const struct dentry *dentry,
return 1;
return 0;
}
+
+int hfsplus_revalidate_dentry(struct dentry *dentry, unsigned int flags)
+{
+ /*
+* dentries are always valid when disabling casefold.
+*/
+ if (!test_bit(HFSPLUS_SB_CASEFOLD, _SB(dentry->d_sb)->flags))
+ return 1;
+
+ /*
+* Positive dentries are valid when enabling casefold.
+*
+* Note, rename() to existing directory entry will have ->d_inode, and
+* will use existing name which isn't specified name by user.
+*
+* We may be able to drop this positive dentry here. But dropping
+* positive dentry isn't good idea. So it's unsupported like
+* rename("filename", "FILENAME") for now.
+*/
+ if (d_really_is_positive(dentry))
+ return 1;
+
+ /*
+* Drop the negative dentry, in order to make sure to use the case
+* sensitive name which is specified by user if this is for creation.
+*/
+ if (flags & (LOOKUP_CREATE | LOOKUP_RENAME_TARGET))
+ return 0;
+
+ return 1;
+}
--
2.25.1
Re: [PATCH v2 3/5] swap: fix do_swap_page() race with swapoff
Miaohe Lin writes:
> When I was investigating the swap code, I found the below possible race
> window:
>
> CPU 1 CPU 2
> - -
> do_swap_page
This is OK for swap cache cases. So
if (data_race(si->flags & SWP_SYNCHRONOUS_IO))
should be shown here.
> swap_readpage(skip swap cache case)
> if (data_race(sis->flags & SWP_FS_OPS)) {
> swapoff
> p->flags = &= ~SWP_VALID;
> ..
> synchronize_rcu();
> ..
> p->swap_file = NULL;
> struct file *swap_file = sis->swap_file;
> struct address_space *mapping = swap_file->f_mapping;[oops!]
>
> Note that for the pages that are swapped in through swap cache, this isn't
> an issue. Because the page is locked, and the swap entry will be marked
> with SWAP_HAS_CACHE, so swapoff() can not proceed until the page has been
> unlocked.
>
> Using current get/put_swap_device() to guard against concurrent swapoff for
> swap_readpage() looks terrible because swap_readpage() may take really long
> time. And this race may not be really pernicious because swapoff is usually
> done when system shutdown only. To reduce the performance overhead on the
> hot-path as much as possible, it appears we can use the percpu_ref to close
> this race window(as suggested by Huang, Ying).
I still suggest to squash PATCH 1-3, at least PATCH 1-2. That will
change the relevant code together and make it easier to review.
Best Regards,
Huang, Ying
> Fixes: 0bcac06f27d7 ("mm,swap: skip swapcache for swapin of synchronous
> device")
> Reported-by: kernel test robot (auto build test ERROR)
> Signed-off-by: Miaohe Lin
> ---
> include/linux/swap.h | 9 +
> mm/memory.c | 9 +
> 2 files changed, 18 insertions(+)
>
> diff --git a/include/linux/swap.h b/include/linux/swap.h
> index 993693b38109..523c2411a135 100644
> --- a/include/linux/swap.h
> +++ b/include/linux/swap.h
> @@ -528,6 +528,15 @@ static inline struct swap_info_struct
> *swp_swap_info(swp_entry_t entry)
> return NULL;
> }
>
> +static inline struct swap_info_struct *get_swap_device(swp_entry_t entry)
> +{
> + return NULL;
> +}
> +
> +static inline void put_swap_device(struct swap_info_struct *si)
> +{
> +}
> +
> #define swap_address_space(entry)(NULL)
> #define get_nr_swap_pages() 0L
> #define total_swap_pages 0L
> diff --git a/mm/memory.c b/mm/memory.c
> index 27014c3bde9f..7a2fe12cf641 100644
> --- a/mm/memory.c
> +++ b/mm/memory.c
> @@ -3311,6 +3311,7 @@ vm_fault_t do_swap_page(struct vm_fault *vmf)
> {
> struct vm_area_struct *vma = vmf->vma;
> struct page *page = NULL, *swapcache;
> + struct swap_info_struct *si = NULL;
> swp_entry_t entry;
> pte_t pte;
> int locked;
> @@ -3338,6 +3339,10 @@ vm_fault_t do_swap_page(struct vm_fault *vmf)
> goto out;
> }
>
> + /* Prevent swapoff from happening to us. */
> + si = get_swap_device(entry);
> + if (unlikely(!si))
> + goto out;
>
> delayacct_set_flag(current, DELAYACCT_PF_SWAPIN);
> page = lookup_swap_cache(entry, vma, vmf->address);
> @@ -3514,6 +3519,8 @@ vm_fault_t do_swap_page(struct vm_fault *vmf)
> unlock:
> pte_unmap_unlock(vmf->pte, vmf->ptl);
> out:
> + if (si)
> + put_swap_device(si);
> return ret;
> out_nomap:
> pte_unmap_unlock(vmf->pte, vmf->ptl);
> @@ -3525,6 +3532,8 @@ vm_fault_t do_swap_page(struct vm_fault *vmf)
> unlock_page(swapcache);
> put_page(swapcache);
> }
> + if (si)
> + put_swap_device(si);
> return ret;
> }
Re:Re: [PATCH] kernel/hung_task: Add a whitelist and blacklist mechanism.
>On 2021/04/17 23:13, zhouchuangao wrote: >> The main purpose of this patch is to add a whitelist and blacklist >> mechanism to the hung task thread. > >We stopped using the term 'whitelist'/'blacklist' for new code in Linux kernel, >and what you are proposing is something like 'ignorelist'/'fatallist'. > >I think that matching based on comm name is poor, for comm name is subjected to >impersonation by malicious user processes. > >Moreover, speak of syzkaller testing, most of hang task reports are reaction to >somebody else consuming too much CPU resources (e.g. printk() flooding, too >many >pending workqueue requests). Even if some process is in 'ignorelist', it is >possible that some problem that should be reported is already happening. Even >if >some process is in 'fatallist', it is possible that the cause of hang is simply >somebody else is consuming too much CPU. > >By the way, I wish that khungtaskd can report recent top CPU consumers, for it >is >rare that the cause of hung is locking dependency problems / hardware problems. > Thank you for your suggestions, Some SOC vendors' drivers or user-mode processes may be in D state for a long time, and normally they do not configure HUNG TASK, so we need to ignore these tasks if we use HUNG TASK. By default, ignorelist and fatallist are empty and can be configured by the user (assuming the user knows what they are doing). I will try to implement the function of khungtaskd to report top CPU consumers. Thanks, zhouchaungao
[PATCH v3] soundwire: intel: move to auxiliary bus
From: Pierre-Louis Bossart
Now that the auxiliary_bus exists, there's no reason to use platform
devices as children of a PCI device any longer.
This patch refactors the code by extending a basic auxiliary device
with Intel link-specific structures that need to be passed between
controller and link levels. This refactoring is much cleaner with no
need for cross-pointers between device and link structures.
Note that the auxiliary bus API has separate init and add steps, which
requires more attention in the error unwinding paths. The main loop
needs to deal with kfree() and auxiliary_device_uninit() for the
current iteration before jumping to the common label which releases
everything allocated in prior iterations.
Signed-off-by: Pierre-Louis Bossart
Reviewed-by: Guennadi Liakhovetski
Reviewed-by: Ranjani Sridharan
Signed-off-by: Bard Liao
---
v2:
- add link_dev_register for all kzalloc, device_init, and device_add.
v3:
- Modify the function description of sdw_intel_probe() which was
missing in previous version.
---
drivers/soundwire/Kconfig | 1 +
drivers/soundwire/intel.c | 56 ---
drivers/soundwire/intel.h | 14 +-
drivers/soundwire/intel_init.c | 232 +++-
include/linux/soundwire/sdw_intel.h | 6 +-
5 files changed, 202 insertions(+), 107 deletions(-)
diff --git a/drivers/soundwire/Kconfig b/drivers/soundwire/Kconfig
index 016e74230bb7..2b7795233282 100644
--- a/drivers/soundwire/Kconfig
+++ b/drivers/soundwire/Kconfig
@@ -25,6 +25,7 @@ config SOUNDWIRE_INTEL
tristate "Intel SoundWire Master driver"
select SOUNDWIRE_CADENCE
select SOUNDWIRE_GENERIC_ALLOCATION
+ select AUXILIARY_BUS
depends on ACPI && SND_SOC
help
SoundWire Intel Master driver.
diff --git a/drivers/soundwire/intel.c b/drivers/soundwire/intel.c
index fd95f94630b1..c11e3d8cd308 100644
--- a/drivers/soundwire/intel.c
+++ b/drivers/soundwire/intel.c
@@ -11,7 +11,7 @@
#include
#include
#include
-#include
+#include
#include
#include
#include
@@ -1327,11 +1327,14 @@ static int intel_init(struct sdw_intel *sdw)
}
/*
- * probe and init
+ * probe and init (aux_dev_id argument is required by function prototype but
not used)
*/
-static int intel_master_probe(struct platform_device *pdev)
+static int intel_link_probe(struct auxiliary_device *auxdev,
+ const struct auxiliary_device_id *aux_dev_id)
+
{
- struct device *dev = >dev;
+ struct device *dev = >dev;
+ struct sdw_intel_link_dev *ldev =
auxiliary_dev_to_sdw_intel_link_dev(auxdev);
struct sdw_intel *sdw;
struct sdw_cdns *cdns;
struct sdw_bus *bus;
@@ -1344,14 +1347,14 @@ static int intel_master_probe(struct platform_device
*pdev)
cdns = >cdns;
bus = >bus;
- sdw->instance = pdev->id;
- sdw->link_res = dev_get_platdata(dev);
+ sdw->instance = auxdev->id;
+ sdw->link_res = >link_res;
cdns->dev = dev;
cdns->registers = sdw->link_res->registers;
cdns->instance = sdw->instance;
cdns->msg_count = 0;
- bus->link_id = pdev->id;
+ bus->link_id = auxdev->id;
sdw_cdns_probe(cdns);
@@ -1384,10 +1387,10 @@ static int intel_master_probe(struct platform_device
*pdev)
return 0;
}
-int intel_master_startup(struct platform_device *pdev)
+int intel_link_startup(struct auxiliary_device *auxdev)
{
struct sdw_cdns_stream_config config;
- struct device *dev = >dev;
+ struct device *dev = >dev;
struct sdw_cdns *cdns = dev_get_drvdata(dev);
struct sdw_intel *sdw = cdns_to_intel(cdns);
struct sdw_bus *bus = >bus;
@@ -1524,9 +1527,9 @@ int intel_master_startup(struct platform_device *pdev)
return ret;
}
-static int intel_master_remove(struct platform_device *pdev)
+static void intel_link_remove(struct auxiliary_device *auxdev)
{
- struct device *dev = >dev;
+ struct device *dev = >dev;
struct sdw_cdns *cdns = dev_get_drvdata(dev);
struct sdw_intel *sdw = cdns_to_intel(cdns);
struct sdw_bus *bus = >bus;
@@ -1542,19 +1545,17 @@ static int intel_master_remove(struct platform_device
*pdev)
snd_soc_unregister_component(dev);
}
sdw_bus_master_delete(bus);
-
- return 0;
}
-int intel_master_process_wakeen_event(struct platform_device *pdev)
+int intel_link_process_wakeen_event(struct auxiliary_device *auxdev)
{
- struct device *dev = >dev;
+ struct device *dev = >dev;
struct sdw_intel *sdw;
struct sdw_bus *bus;
void __iomem *shim;
u16 wake_sts;
- sdw = platform_get_drvdata(pdev);
+ sdw = dev_get_drvdata(dev);
bus = >cdns.bus;
if (bus->prop.hw_disabled) {
@@ -1976,17 +1977,22 @@ static const struct dev_pm_ops intel_pm = {
SET_RUNTIME_PM_OPS(intel_suspend_runtime,
[PATCH] fs: f2fs: Remove unnecessary struct declaration
struct dnode_of_data is defined at 897th line. The declaration here is unnecessary. Remove it. Signed-off-by: Wan Jiabing --- fs/f2fs/f2fs.h | 1 - 1 file changed, 1 deletion(-) diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h index e2d302ae3a46..0757f9e50fd2 100644 --- a/fs/f2fs/f2fs.h +++ b/fs/f2fs/f2fs.h @@ -3299,7 +3299,6 @@ void f2fs_hash_filename(const struct inode *dir, struct f2fs_filename *fname); /* * node.c */ -struct dnode_of_data; struct node_info; int f2fs_check_nid_range(struct f2fs_sb_info *sbi, nid_t nid); -- 2.25.1
Re: [PATCH v2 01/12] docs: path-lookup: update follow_managed() part
On Tue, Mar 16, 2021 at 01:47:16PM +0800, Fox Chen wrote:
> -In the absence of symbolic links, ``walk_component()`` creates a new
> +As the last step of ``walk_component()``, ``step_into()`` will be called
> either
You can drop ``..`` from around function named which are followed with
(). d74b0d31ddde ("Docs: An initial automarkup extension for sphinx")
marks them up automatically.
