Re: linux-next: Fixes tag needs some work in the drivers-x86 tree
Hi Hans, On Mon, 30 Nov 2020 08:43:21 +0100 Hans de Goede wrote: > > Question, how important is it to fix these ? I normally never do forced pushes > to the for-next branch. But if this is considered important to fix I guess I > can make an exception. I think it is fine to leave these, but to try to not have more in the future. > Will git rewrite the commit msg when this is set ? I'm at 2.28 and don't > have core.abbrev set. But I guess this needs to be set in the gitconfig > of the creator of the patch; and this has no impact on "git am" ? It will not rewrite the commit message. -- Cheers, Stephen Rothwell pgpfNtqAYgdmD.pgp Description: OpenPGP digital signature
Re: [PATCH] drm/amdgpu/display: remove trailing semicolon in macro definition
Am 27.11.20 um 17:26 schrieb t...@redhat.com: From: Tom Rix The macro use will already have a semicolon. Signed-off-by: Tom Rix Reviewed-by: Christian König --- drivers/gpu/drm/amd/amdgpu/amdgpu.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h b/drivers/gpu/drm/amd/amdgpu/amdgpu.h index f9c81bc21ba4..301e93c9e72a 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h @@ -1213,7 +1213,7 @@ int emu_soc_asic_init(struct amdgpu_device *adev); #define amdgpu_asic_update_umd_stable_pstate(adev, enter) \ ((adev)->asic_funcs->update_umd_stable_pstate ? (adev)->asic_funcs->update_umd_stable_pstate((adev), (enter)) : 0) -#define amdgpu_inc_vram_lost(adev) atomic_inc(&((adev)->vram_lost_counter)); +#define amdgpu_inc_vram_lost(adev) atomic_inc(&((adev)->vram_lost_counter)) /* Common functions */ bool amdgpu_device_has_job_running(struct amdgpu_device *adev);
Re: [PATCH] riscv/mm: Prevent kernel module access user-space memory without uaccess routines
On Mon, Nov 30, 2020 at 7:33 AM Eric Lin wrote: > > In the page fault handler, an access to user-space memory > without get/put_user() or copy_from/to_user() routines is > not resolved properly. Like arm and other architectures, > we need to let it die earlier in page fault handler. Fix looks good to me. Can you elaborate on how you found the issue and how the bug manifests itself? > > Signed-off-by: Eric Lin > Cc: Alan Kao > --- > arch/riscv/mm/fault.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/arch/riscv/mm/fault.c b/arch/riscv/mm/fault.c > index 3c8b9e433c67..a452cfa266a2 100644 > --- a/arch/riscv/mm/fault.c > +++ b/arch/riscv/mm/fault.c > @@ -232,6 +232,9 @@ asmlinkage void do_page_fault(struct pt_regs *regs) > if (user_mode(regs)) > flags |= FAULT_FLAG_USER; > > + if (!user_mode(regs) && addr < TASK_SIZE && unlikely(!(regs->status & > SR_SUM))) > + die(regs, "Accessing user space memory without uaccess > routines\n"); Let's introduce a die_kernel_fault() helper (similar to arm64, for example) to ensure same semantics for the different kernel faults. You can extract the helper from no_context(). > + > perf_sw_event(PERF_COUNT_SW_PAGE_FAULTS, 1, regs, addr); > > if (cause == EXC_STORE_PAGE_FAULT) > -- > 2.17.0 > > > ___ > linux-riscv mailing list > linux-ri...@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-riscv
Re: [BISECTED REGRESSION] Broken USB/GPIO on OMAP1 OSK
On Sun, Nov 29, 2020 at 12:57 PM Aaro Koskinen wrote: > On Sun, Nov 29, 2020 at 01:51:54AM +0200, Aaro Koskinen wrote: > > I tried to upgrade my OMAP1 OSK board to v5.9, but the rootfs cannot > > be accessed anymore due to broken USB. It fails to probe with the > > following logs: > > > > [9.219940] ohci ohci: cannot find GPIO chip i2c-tps65010, deferring > > [9.250366] ohci ohci: cannot find GPIO chip i2c-tps65010, deferring > > [9.731445] ohci ohci: cannot find GPIO chip i2c-tps65010, deferring > > [ 10.342102] ohci ohci: cannot find GPIO chip i2c-tps65010, deferring > > [ 10.966430] ohci ohci: cannot find GPIO chip i2c-tps65010, deferring > > > > Bisected to: > > > > commit 15d157e874437e381643c37a10922388d6e55b29 > > Author: Linus Walleij > > Date: Mon Jul 20 15:55:24 2020 +0200 > > > > usb: ohci-omap: Convert to use GPIO descriptors > > > > I suspect one of the issues is the name "i2c-tps65010" vs "tps65010": > > > > # cat > > /sys/devices/platform/omap_i2c.1/i2c-1/i2c-tps65010/gpio/gpiochip208/label > > tps65010 > > > > However changing that in the lookup table still doesn't help much; I got rid > > of the "deferring" message but the USB still doesn't work. So far the only > > workaround I have is to revert the whole commit. > > GPIO numbering goes wrong... It's now trying to poke GPIO2. Hm the old code looked like this: #define GPIO1 1 tps65010_set_gpio_out_value(GPIO1, LOW); And I missed that the code inside the tps65010 driver subtracts 1 from the passed parameter and the standard gpiolib accessors add 1 before calling the same function. I missed this. > Also gpiod_set_value_cansleep() probably should be used as tps65010 > can sleep. OK I'll send a combined patch fixing all issues (I hope). Yours, Linus Walleij
Re: [PATCH v2 net-next 3/3] nfc: s3fwrn5: extract the common phy blocks
On Sun, Nov 29, 2020 at 06:55:10PM +0900, Bongsu Jeon wrote:
> On Sat, Nov 28, 2020 at 9:49 PM Krzysztof Kozlowski wrote:
> > This is not a proper wrapping. Wrapping happens on function arguments.
> >
> > > + if (!gpio_is_valid(phy->common.gpio_en))
> > > return -ENODEV;
> > > }
> > >
> > > - phy->gpio_fw_wake = of_get_named_gpio(np, "wake-gpios", 0);
> > > - if (!gpio_is_valid(phy->gpio_fw_wake)) {
> > > + phy->common.gpio_fw_wake = of_get_named_gpio(np, "wake-gpios", 0);
> > > + if (!gpio_is_valid(phy->common.gpio_fw_wake)) {
> > > /* Support also deprecated property */
> > > - phy->gpio_fw_wake = of_get_named_gpio(np,
> > > "s3fwrn5,fw-gpios", 0);
> > > - if (!gpio_is_valid(phy->gpio_fw_wake))
> > > + phy->common.gpio_fw_wake =
> > > + of_get_named_gpio(np, "s3fwrn5,fw-gpios",
> > > 0);
> > > + if (!gpio_is_valid(phy->common.gpio_fw_wake))
> >
> > The same.
> >
>
> Even though I wrapped this as below, Second line("s3fwrn5,fw-gpios" )
> was over 80 columns.
> Is it okay as below?
> phy->gpio_fw_wake =of_get_named_gpio(np,
>
> "s3fwrn5,fw-gpios",
> 0);
Your email client breaks indentation so I cannot answer. The wrapping - as
explained in CodingStyle - would look like:
phy->common.gpio_fw_wake = of_get_named_gpio(np,
"s3fwrn5,fw-gpios",
0);
It's not a problem if single argument exceeds 80 character.
>
>
> > > return -ENODEV;
> > > }
> > >
> > > @@ -226,8 +184,8 @@ static int s3fwrn5_i2c_probe(struct i2c_client
> > > *client,
> > > if (!phy)
> > > return -ENOMEM;
> > >
> > > - mutex_init(&phy->mutex);
> > > - phy->mode = S3FWRN5_MODE_COLD;
> > > + mutex_init(&phy->common.mutex);
> > > + phy->common.mode = S3FWRN5_MODE_COLD;
> > > phy->irq_skip = true;
> > >
> > > phy->i2c_dev = client;
> > > @@ -237,17 +195,19 @@ static int s3fwrn5_i2c_probe(struct i2c_client
> > > *client,
> > > if (ret < 0)
> > > return ret;
> > >
> > > - ret = devm_gpio_request_one(&phy->i2c_dev->dev, phy->gpio_en,
> > > - GPIOF_OUT_INIT_HIGH, "s3fwrn5_en");
> > > + ret = devm_gpio_request_one(&phy->i2c_dev->dev, phy->common.gpio_en,
> > > + GPIOF_OUT_INIT_HIGH, "s3fwrn5_en");
> > > if (ret < 0)
> > > return ret;
> > >
> > > - ret = devm_gpio_request_one(&phy->i2c_dev->dev, phy->gpio_fw_wake,
> > > - GPIOF_OUT_INIT_LOW, "s3fwrn5_fw_wake");
> > > + ret = devm_gpio_request_one(&phy->i2c_dev->dev,
> > > + phy->common.gpio_fw_wake,
> > > + GPIOF_OUT_INIT_LOW, "s3fwrn5_fw_wake");
> > > if (ret < 0)
> > > return ret;
> > >
> > > - ret = s3fwrn5_probe(&phy->ndev, phy, &phy->i2c_dev->dev,
> > > &i2c_phy_ops);
> > > + ret = s3fwrn5_probe(&phy->common.ndev, phy, &phy->i2c_dev->dev,
> > > + &i2c_phy_ops);
> > > if (ret < 0)
> > > return ret;
> > >
> > > @@ -255,7 +215,7 @@ static int s3fwrn5_i2c_probe(struct i2c_client
> > > *client,
> > > s3fwrn5_i2c_irq_thread_fn, IRQF_TRIGGER_HIGH | IRQF_ONESHOT,
> > > S3FWRN5_I2C_DRIVER_NAME, phy);
> > > if (ret)
> > > - s3fwrn5_remove(phy->ndev);
> > > + s3fwrn5_remove(phy->common.ndev);
> > >
> > > return ret;
> > > }
> > > @@ -264,7 +224,7 @@ static int s3fwrn5_i2c_remove(struct i2c_client
> > > *client)
> > > {
> > > struct s3fwrn5_i2c_phy *phy = i2c_get_clientdata(client);
> > >
> > > - s3fwrn5_remove(phy->ndev);
> > > + s3fwrn5_remove(phy->common.ndev);
> > >
> > > return 0;
> > > }
> > > diff --git a/drivers/nfc/s3fwrn5/phy_common.c
> > > b/drivers/nfc/s3fwrn5/phy_common.c
> > > new file mode 100644
> > > index 000..e333764
> > > --- /dev/null
> > > +++ b/drivers/nfc/s3fwrn5/phy_common.c
> > > @@ -0,0 +1,60 @@
> > > +// SPDX-License-Identifier: GPL-2.0-or-later
> > > +/*
> > > + * Link Layer for Samsung S3FWRN5 NCI based Driver
> > > + *
> > > + * Copyright (C) 2015 Samsung Electrnoics
> > > + * Robert Baldyga
> > > + * Copyright (C) 2020 Samsung Electrnoics
> > > + * Bongsu Jeon
> > > + */
> > > +
> > > +#include
> > > +#include
> >
> > You need also mutex.h (it seems original code did not have it but since
> > you move things around it's a new code basically).
> >
> > > +
> > > +#include "s3fwrn5.h"
> > > +#include "phy_common.h"
> > > +
> > > +void s3fwrn5_phy_set_wake(void *phy_id, bool wake)
> > > +{
> > > + struct phy_common *phy = phy_id;
> > > +
> > > + mutex_lock(&phy->mutex);
> > > + gpio_set_value(phy->gpio
Re: [PATCH 1/1] efi/efi_test: read RuntimeServicesSupported
Hi Heinrich,
Thanks for the patch.
It looks good to me, but I noticed that the runtime_supported_mask was
introduced after 5.7-rc1.
Maybe we should add the kernel version checking for the old kernels.
Cheers,
Ivan
On 11/28/20 3:20 AM, Heinrich Schuchardt wrote:
> Since the UEFI 2.8A specification the UEFI enabled firmware provides a
> configuration table EFI_RT_PROPERTIES_TABLE which indicates which runtime
> services are enabled. The EFI stub reads this table and saves the value of
> the field RuntimeServicesSupported internally.
>
> The Firmware Test Suite requires the value to determine if UEFI runtime
> services are correctly implemented.
>
> With this patch an IOCTL call is provided to read the value of the field
> RuntimeServicesSupported, e.g.
>
> #define EFI_RUNTIME_GET_SUPPORTED_MASK \
> _IOR('p', 0x0C, unsigned int)
> unsigned int mask;
> fd = open("/dev/efi_test", O_RDWR);
> ret = ioctl(fd, EFI_RUNTIME_GET_SUPPORTED_MASK, &mask);
>
> Signed-off-by: Heinrich Schuchardt
> ---
> drivers/firmware/efi/test/efi_test.c | 16
> drivers/firmware/efi/test/efi_test.h | 3 +++
> 2 files changed, 19 insertions(+)
>
> diff --git a/drivers/firmware/efi/test/efi_test.c
> b/drivers/firmware/efi/test/efi_test.c
> index ddf9eae396fe..47d67bb0a516 100644
> --- a/drivers/firmware/efi/test/efi_test.c
> +++ b/drivers/firmware/efi/test/efi_test.c
> @@ -663,6 +663,19 @@ static long efi_runtime_query_capsulecaps(unsigned long
> arg)
> return rv;
> }
>
> +static long efi_runtime_get_supported_mask(unsigned long arg)
> +{
> + unsigned int __user *supported_mask;
> + int rv = 0;
> +
> + supported_mask = (unsigned int *)arg;
> +
> + if (put_user(efi.runtime_supported_mask, supported_mask))
> + rv = -EFAULT;
> +
> + return rv;
> +}
> +
> static long efi_test_ioctl(struct file *file, unsigned int cmd,
> unsigned long arg)
> {
> @@ -699,6 +712,9 @@ static long efi_test_ioctl(struct file *file, unsigned
> int cmd,
>
> case EFI_RUNTIME_RESET_SYSTEM:
> return efi_runtime_reset_system(arg);
> +
> + case EFI_RUNTIME_GET_SUPPORTED_MASK:
> + return efi_runtime_get_supported_mask(arg);
> }
>
> return -ENOTTY;
> diff --git a/drivers/firmware/efi/test/efi_test.h
> b/drivers/firmware/efi/test/efi_test.h
> index f2446aa1c2e3..117349e57993 100644
> --- a/drivers/firmware/efi/test/efi_test.h
> +++ b/drivers/firmware/efi/test/efi_test.h
> @@ -118,4 +118,7 @@ struct efi_resetsystem {
> #define EFI_RUNTIME_RESET_SYSTEM \
> _IOW('p', 0x0B, struct efi_resetsystem)
>
> +#define EFI_RUNTIME_GET_SUPPORTED_MASK \
> + _IOR('p', 0x0C, unsigned int)
> +
> #endif /* _DRIVERS_FIRMWARE_EFI_TEST_H_ */
> --
> 2.29.2
>
[PATCH v2] ARM: fix __div64_32() error when compiling with clang
>From 3a4c19e09079324a625941ea3c16fe4b0df2ed86 Mon Sep 17 00:00:00 2001
From: Antony Yu
Date: Mon, 9 Nov 2020 17:31:52 +0800
Subject: [PATCH v2] ARM: fix __div64_32() error when compiling with clang
__do_div64 clobbers the input register r0 in little endian system.
According to the inline assembly document, if an input operand is
modified, it should be tied to a output operand. This patch can
prevent compilers from reusing r0 register after asm statements.
Signed-off-by: Antony Yu
Reported-by: kernel test robot
---
changed in v2
- add kernel-test-robot tag
- fix build failure on big endian
arch/arm/include/asm/div64.h | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/arch/arm/include/asm/div64.h b/arch/arm/include/asm/div64.h
index 898e9c78a7e7..961a129eb41f 100644
--- a/arch/arm/include/asm/div64.h
+++ b/arch/arm/include/asm/div64.h
@@ -39,9 +39,10 @@ static inline uint32_t __div64_32(uint64_t *n, uint32_t base)
asm( __asmeq("%0", __xh)
__asmeq("%1", "r2")
__asmeq("%2", "r0")
- __asmeq("%3", "r4")
+ __asmeq("%3", "r0")
+ __asmeq("%4", "r4")
"bl __do_div64"
- : "=r" (__rem), "=r" (__res)
+ : "=r" (__rem), "=r" (__res), "=r" (__xl)
: "r" (__n), "r" (__base)
: "ip", "lr", "cc");
*n = __res;
--
2.29.0
Re: [v3 01/11] irqchip: ls-extirq: Add LS1043A, LS1088A external interrupt
[- jason]
On 2020-11-30 03:30, Biwen Li wrote:
From: Hou Zhiqiang
Add an new IRQ chip declaration for LS1043A and LS1088A
- compatible "fsl,ls1043a-extirq" for LS1043A, LS1046A.
- compatible "fsl,ls1088a-extirq" for LS1088A, LS208xA, LX216xA
Signed-off-by: Hou Zhiqiang
Signed-off-by: Biwen Li
---
Change in v3:
- cleanup code
- remove robust copyright
Change in v2:
- add despcription of bit reverse
- update copyright
drivers/irqchip/irq-ls-extirq.c | 17 +++--
1 file changed, 7 insertions(+), 10 deletions(-)
diff --git a/drivers/irqchip/irq-ls-extirq.c
b/drivers/irqchip/irq-ls-extirq.c
index 4d1179fed77c..47804ce78b21 100644
--- a/drivers/irqchip/irq-ls-extirq.c
+++ b/drivers/irqchip/irq-ls-extirq.c
@@ -18,7 +18,7 @@
struct ls_extirq_data {
struct regmap *syscon;
u32 intpcr;
- boolbit_reverse;
+ boolis_ls1021a_or_ls1043a;
u32 nirq;
struct irq_fwspec map[MAXIRQ];
};
@@ -30,7 +30,7 @@ ls_extirq_set_type(struct irq_data *data, unsigned
int type)
irq_hw_number_t hwirq = data->hwirq;
u32 value, mask;
- if (priv->bit_reverse)
+ if (priv->is_ls1021a_or_ls1043a)
mask = 1U << (31 - hwirq);
else
mask = 1U << hwirq;
@@ -174,14 +174,9 @@ ls_extirq_of_init(struct device_node *node,
struct device_node *parent)
if (ret)
goto out;
- if (of_device_is_compatible(node, "fsl,ls1021a-extirq")) {
- u32 revcr;
-
- ret = regmap_read(priv->syscon, LS1021A_SCFGREVCR, &revcr);
- if (ret)
- goto out;
- priv->bit_reverse = (revcr != 0);
- }
This isn't explained in the commit message. You are changing the way
you infer some properties, and that's not innocent. Please describe
all important changes in the commit message.
+ if (of_device_is_compatible(node, "fsl,ls1021a-extirq") || \
Spurious trailing \?
+ of_device_is_compatible(node, "fsl,ls1043a-extirq"))
+ priv->is_ls1021a_or_ls1043a = true;
Which is better written as:
priv->is_ls1021a_or_ls1043a = (of_device_is_compatible(node,
"fsl,ls1021a-extirq") ||
of_device_is_compatible(node,
"fsl,ls1043a-extirq"));
domain = irq_domain_add_hierarchy(parent_domain, 0, priv->nirq, node,
&extirq_domain_ops, priv);
@@ -195,3 +190,5 @@ ls_extirq_of_init(struct device_node *node, struct
device_node *parent)
}
IRQCHIP_DECLARE(ls1021a_extirq, "fsl,ls1021a-extirq",
ls_extirq_of_init);
+IRQCHIP_DECLARE(ls1043a_extirq, "fsl,ls1043a-extirq",
ls_extirq_of_init);
+IRQCHIP_DECLARE(ls1088a_extirq, "fsl,ls1088a-extirq",
ls_extirq_of_init);
Thanks,
M.
--
Jazz is not dead. It just smells funny...
[PATCH v5 0/5] clk: add driver for the SiFive FU740
Add a driver for the SiFive FU740 PRCI IP block, which handles more clocks than FU540. These patches also refactor the original implementation by spliting the dependent-code of fu540 and fu740 respectively. In v3 and v4 patch set, it fix the wrong clk enable bit field which reported by Pragnesh. We also add a separate patch for DT binding documentation of FU740 PRCI: https://patchwork.kernel.org/project/linux-riscv/patch/20201126030043.67390-1-zong...@sifive.com/ Changed in v5: - Fix copyright format - Add a link of documentation in commit message - Modify build dependency for sifive-prci.c - Add enable and disable functions by Pragnesh Patel Changed in v4: - Fix the wrong enable bit field shift for FU540 and FU740. Changed in v3: - Fix the wrong enable bit field shift for FU740. Changed in v2: - Remove the macro definition for __prci_clock_array. - Indicate the functional changes in commit message. - Using option -M and -C to create patches. - Rebase code to kernel v5.10-rc3. Pragnesh Patel (1): clk: sifive: Add clock enable and disable ops Zong Li (4): clk: sifive: Extract prci core to common base clk: sifive: Use common name for prci configuration clk: sifive: Add a driver for the SiFive FU740 PRCI IP block clk: sifive: Fix the wrong bit field shift arch/riscv/Kconfig.socs | 2 +- drivers/clk/sifive/Kconfig| 8 +- drivers/clk/sifive/Makefile | 2 +- drivers/clk/sifive/fu540-prci.c | 585 + drivers/clk/sifive/fu540-prci.h | 21 + drivers/clk/sifive/fu740-prci.c | 120 drivers/clk/sifive/fu740-prci.h | 21 + drivers/clk/sifive/sifive-prci.c | 588 ++ drivers/clk/sifive/sifive-prci.h | 301 + include/dt-bindings/clock/sifive-fu740-prci.h | 23 + 10 files changed, 1105 insertions(+), 566 deletions(-) create mode 100644 drivers/clk/sifive/fu540-prci.h create mode 100644 drivers/clk/sifive/fu740-prci.c create mode 100644 drivers/clk/sifive/fu740-prci.h create mode 100644 drivers/clk/sifive/sifive-prci.c create mode 100644 drivers/clk/sifive/sifive-prci.h create mode 100644 include/dt-bindings/clock/sifive-fu740-prci.h -- 2.29.2
[PATCH v5 1/5] clk: sifive: Extract prci core to common base
Extract common core of prci driver to an independent file, it could
allow other chips to reuse it. Separate SoCs-dependent code 'fu540'
from prci core, then we can easily add 'fu740' later.
Almost these changes are code movement. The different is adding the
private data for each SoC use, so it needs to get match data in probe
callback function, then use the data for initialization.
Signed-off-by: Zong Li
Reviewed-by: Pragnesh Patel
Acked-by: Palmer Dabbelt
---
drivers/clk/sifive/Makefile | 2 +-
drivers/clk/sifive/fu540-prci.c | 579 +-
drivers/clk/sifive/fu540-prci.h | 21 +
.../sifive/{fu540-prci.c => sifive-prci.c}| 401 +++-
drivers/clk/sifive/sifive-prci.h | 201 ++
5 files changed, 325 insertions(+), 879 deletions(-)
create mode 100644 drivers/clk/sifive/fu540-prci.h
copy drivers/clk/sifive/{fu540-prci.c => sifive-prci.c} (41%)
create mode 100644 drivers/clk/sifive/sifive-prci.h
diff --git a/drivers/clk/sifive/Makefile b/drivers/clk/sifive/Makefile
index 0797f14fef6b..51b6ebc359e4 100644
--- a/drivers/clk/sifive/Makefile
+++ b/drivers/clk/sifive/Makefile
@@ -1,2 +1,2 @@
# SPDX-License-Identifier: GPL-2.0-only
-obj-$(CONFIG_CLK_SIFIVE_FU540_PRCI)+= fu540-prci.o
+obj-$(CONFIG_CLK_SIFIVE_FU540_PRCI)+= sifive-prci.o fu540-prci.o
diff --git a/drivers/clk/sifive/fu540-prci.c b/drivers/clk/sifive/fu540-prci.c
index a8901f90a61a..34dc4ea6a3af 100644
--- a/drivers/clk/sifive/fu540-prci.c
+++ b/drivers/clk/sifive/fu540-prci.c
@@ -3,6 +3,7 @@
* Copyright (C) 2018-2019 SiFive, Inc.
* Wesley Terpstra
* Paul Walmsley
+ * Zong Li
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License version 2 as
@@ -25,463 +26,43 @@
*/
#include
-#include
-#include
-#include
-#include
-#include
-#include
#include
-#include
-#include
-#include
-#include
+#include "sifive-prci.h"
-/*
- * EXPECTED_CLK_PARENT_COUNT: how many parent clocks this driver expects:
- * hfclk and rtcclk
- */
-#define EXPECTED_CLK_PARENT_COUNT 2
-
-/*
- * Register offsets and bitmasks
- */
-
-/* COREPLLCFG0 */
-#define PRCI_COREPLLCFG0_OFFSET0x4
-# define PRCI_COREPLLCFG0_DIVR_SHIFT 0
-# define PRCI_COREPLLCFG0_DIVR_MASK(0x3f <<
PRCI_COREPLLCFG0_DIVR_SHIFT)
-# define PRCI_COREPLLCFG0_DIVF_SHIFT 6
-# define PRCI_COREPLLCFG0_DIVF_MASK(0x1ff <<
PRCI_COREPLLCFG0_DIVF_SHIFT)
-# define PRCI_COREPLLCFG0_DIVQ_SHIFT 15
-# define PRCI_COREPLLCFG0_DIVQ_MASK(0x7 <<
PRCI_COREPLLCFG0_DIVQ_SHIFT)
-# define PRCI_COREPLLCFG0_RANGE_SHIFT 18
-# define PRCI_COREPLLCFG0_RANGE_MASK (0x7 <<
PRCI_COREPLLCFG0_RANGE_SHIFT)
-# define PRCI_COREPLLCFG0_BYPASS_SHIFT 24
-# define PRCI_COREPLLCFG0_BYPASS_MASK (0x1 <<
PRCI_COREPLLCFG0_BYPASS_SHIFT)
-# define PRCI_COREPLLCFG0_FSE_SHIFT25
-# define PRCI_COREPLLCFG0_FSE_MASK (0x1 <<
PRCI_COREPLLCFG0_FSE_SHIFT)
-# define PRCI_COREPLLCFG0_LOCK_SHIFT 31
-# define PRCI_COREPLLCFG0_LOCK_MASK(0x1 <<
PRCI_COREPLLCFG0_LOCK_SHIFT)
-
-/* DDRPLLCFG0 */
-#define PRCI_DDRPLLCFG0_OFFSET 0xc
-# define PRCI_DDRPLLCFG0_DIVR_SHIFT0
-# define PRCI_DDRPLLCFG0_DIVR_MASK (0x3f <<
PRCI_DDRPLLCFG0_DIVR_SHIFT)
-# define PRCI_DDRPLLCFG0_DIVF_SHIFT6
-# define PRCI_DDRPLLCFG0_DIVF_MASK (0x1ff <<
PRCI_DDRPLLCFG0_DIVF_SHIFT)
-# define PRCI_DDRPLLCFG0_DIVQ_SHIFT15
-# define PRCI_DDRPLLCFG0_DIVQ_MASK (0x7 <<
PRCI_DDRPLLCFG0_DIVQ_SHIFT)
-# define PRCI_DDRPLLCFG0_RANGE_SHIFT 18
-# define PRCI_DDRPLLCFG0_RANGE_MASK(0x7 <<
PRCI_DDRPLLCFG0_RANGE_SHIFT)
-# define PRCI_DDRPLLCFG0_BYPASS_SHIFT 24
-# define PRCI_DDRPLLCFG0_BYPASS_MASK (0x1 <<
PRCI_DDRPLLCFG0_BYPASS_SHIFT)
-# define PRCI_DDRPLLCFG0_FSE_SHIFT 25
-# define PRCI_DDRPLLCFG0_FSE_MASK (0x1 <<
PRCI_DDRPLLCFG0_FSE_SHIFT)
-# define PRCI_DDRPLLCFG0_LOCK_SHIFT31
-# define PRCI_DDRPLLCFG0_LOCK_MASK (0x1 <<
PRCI_DDRPLLCFG0_LOCK_SHIFT)
-
-/* DDRPLLCFG1 */
-#define PRCI_DDRPLLCFG1_OFFSET 0x10
-# define PRCI_DDRPLLCFG1_CKE_SHIFT 24
-# define PRCI_DDRPLLCFG1_CKE_MASK (0x1 <<
PRCI_DDRPLLCFG1_CKE_SHIFT)
-
-/* GEMGXLPLLCFG0 */
-#define PRCI_GEMGXLPLLCFG0_OFFSET 0x1c
-# define PRCI_GEMGXLPLLCFG0_DIVR_SHIFT 0
-# define PRCI_GEMGXLPLLCFG0_DIVR_MASK (0x3f <<
PRCI_GEMGXLPLLCFG0_DIVR_SHIFT)
-# define PRCI_GEMGXLPLLCFG0_DIVF_SHIFT 6
-# define PRCI_GEMGXLPLLCFG0_DIVF_MASK (0x1ff <<
PRCI_GEMGXLPLLCFG0_DIVF_SHIFT)
-# define PRCI_GEMGXLPLLCFG0_DIVQ_SHIFT 15
-# define PRCI_GEMGXLPLLCFG0_DIVQ_MASK (0x7 <<
PRCI_GEMGXLPLLCFG0_DIVQ_SHIFT)
-# define PRCI_GEMGXLP
Re: [GIT pull] locking/urgent for v5.10-rc6
Hi Peter, Peter Zijlstra writes: > On Sun, Nov 29, 2020 at 11:31:41AM -0800, Linus Torvalds wrote: >> On Sun, Nov 29, 2020 at 5:38 AM Thomas Gleixner wrote: >> > >> > Yet two more places which invoke tracing from RCU disabled regions in the >> > idle path. Similar to the entry path the low level idle functions have to >> > be non-instrumentable. >> >> This really seems less than optimal. >> >> In particular, lookie here: >> >> > @@ -94,9 +94,35 @@ void __cpuidle default_idle_call(void) >> > >> > trace_cpu_idle(1, smp_processor_id()); >> > stop_critical_timings(); >> > + >> > + /* >> > +* arch_cpu_idle() is supposed to enable IRQs, however >> > +* we can't do that because of RCU and tracing. >> > +* >> > +* Trace IRQs enable here, then switch off RCU, and have >> > +* arch_cpu_idle() use raw_local_irq_enable(). Note that >> > +* rcu_idle_enter() relies on lockdep IRQ state, so switch >> > that >> > +* last -- this is very similar to the entry code. >> > +*/ >> > + trace_hardirqs_on_prepare(); >> > + lockdep_hardirqs_on_prepare(_THIS_IP_); >> > rcu_idle_enter(); >> > + lockdep_hardirqs_on(_THIS_IP_); >> > + >> > arch_cpu_idle(); >> > + >> > + /* >> > +* OK, so IRQs are enabled here, but RCU needs them >> > disabled to >> > +* turn itself back on.. funny thing is that disabling IRQs >> > +* will cause tracing, which needs RCU. Jump through hoops >> > to >> > +* make it 'work'. >> > +*/ >> > + raw_local_irq_disable(); >> > + lockdep_hardirqs_off(_THIS_IP_); >> > rcu_idle_exit(); >> > + lockdep_hardirqs_on(_THIS_IP_); >> > + raw_local_irq_enable(); >> > + >> > start_critical_timings(); >> > trace_cpu_idle(PWR_EVENT_EXIT, smp_processor_id()); >> > } >> >> And look at what the code generation for the idle exit path is when >> lockdep isn't even on. > > Agreed. > > The idea was to flip all of arch_cpu_idle() to not enable interrupts. > > This is suboptimal for things like x86 where arch_cpu_idle() is > basically STI;HLT, but x86 isn't likely to actually use this code path > anyway, given all the various cpuidle drivers it has. > > Many of the other archs are now doing things like arm's: > wfi();raw_local_irq_enable(). > > Doing that tree-wide interrupt-state flip was something I didn't want to > do at this late a stage, the chanse of messing that up is just too high. > > After that I need to go look at flipping cpuidle, which is even more > 'interesting'. cpuidle_enter() has the exact same semantics, and this is > the code path that x86 actually uses, and here it's inconsitent at best. On s390 this introduces the following splat: [2.962283] Testing tracer wakeup_rt: [3.017102] sched: DL replenish lagged too much [3.061777] PASSED [3.062076] Testing tracer wakeup_dl: PASSED [3.161296] [ cut here ] [3.161301] DEBUG_LOCKS_WARN_ON(current->hardirq_chain_key != current->curr_chain_key) [3.161310] WARNING: CPU: 0 PID: 0 at kernel/locking/lockdep.c:4155 lockdep_hardirqs_on+0x1ea/0x1f8 [3.161316] Modules linked in: [3.161323] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.10.0-rc6-07209-g9e30ba6d2d5c #2249 [3.161327] Hardware name: IBM 2964 NC9 702 (z/VM 6.4.0) [3.161331] Krnl PSW : 0404d0018000 00d730fe (lockdep_hardirqs_on+0x1ee/0x1f8) [3.161340]R:0 T:1 IO:0 EX:0 Key:0 M:1 W:0 P:0 AS:3 CC:1 PM:0 RI:0 EA:3 [3.161347] Krnl GPRS: c000bfff 8001 004a 001e33b8 [3.161352]03807b88 03807b80 [3.161357] 0151a610 01361500 00d81d40 [3.161362]00010400 00d88010 00d730fa 03807db8 [3.161461] Krnl Code: 00d730ee: c0200012d9adlarl %r2,00fce448 [3.161461]00d730f4: c0e5451abrasl %r14,00d5bb28 [3.161461] #00d730fa: af00mc 0,0 [3.161461] >00d730fe: a7f4ff70brc 15,00d72fde [3.161461]00d73102: 0707bcr 0,%r7 [3.161461]00d73104: 0707bcr 0,%r7 [3.161461]00d73106: 0707bcr 0,%r7 [3.161461]00d73108: c418002884eclgrl %r1,01283ae0 [3.161518] Call Trace: [3.161526] [<00d730fe>] lockdep_hardirqs_on+0x1ee/
Re: [PATCH 1/3] thermal: core: Add indication for userspace usage
> On Nov 30, 2020, at 15:57, Daniel Lezcano wrote:
>
>
> [Added Srinivas]
>
> On 28/11/2020 18:54, Kai-Heng Feng wrote:
>> We are seeing thermal shutdown on Intel based mobile workstations, the
>> shutdown happens during the first trip handle in
>> thermal_zone_device_register():
>> kernel: thermal thermal_zone15: critical temperature reached (101 C),
>> shutting down
>>
>> However, we shouldn't do a thermal shutdown here, since
>> 1) We may want to use a dedicated daemon, Intel's thermald in this case,
>> to handle thermal shutdown.
>>
>> 2) For ACPI based system, _CRT doesn't mean shutdown unless it's inside
>> ThermalZone. ACPI Spec, 11.4.4 _CRT (Critical Temperature):
>> "... If this object it present under a device, the device’s driver
>> evaluates this object to determine the device’s critical cooling
>> temperature trip point. This value may then be used by the device’s
>> driver to program an internal device temperature sensor trip point."
>>
>> So a "critical trip" here merely means we should take a more aggressive
>> cooling method.
>
> Well, actually it is stated before:
>
> "This object, when defined under a thermal zone, returns the critical
> temperature at which OSPM must shutdown the system".
This means specifically for the ACPI ThermalZone in AML, e.g.:
ThermalZone (TZ0) {
Method(_CRT) { ... }
} // end of TZ0
However the device is not under any ACPI ThermalZone.
>
> That is what does the thermal subsystem, no ?
>
>> So add an indication to let thermal core know it should leave thermal
>> device to userspace to handle.
>
> You may want to check the 'HOT' trip point and then use the notification
> mechanism to get notified in userspace and take action from there (eg.
> offline some CPUs).
For this particular issue we are facing, the thermal shutdown happens in
thermal_zone_device_register() and userspace isn't up yet.
Kai-Heng
>
>> Signed-off-by: Kai-Heng Feng
>> ---
>> drivers/thermal/thermal_core.c | 3 +++
>> include/linux/thermal.h| 2 ++
>> 2 files changed, 5 insertions(+)
>>
>> diff --git a/drivers/thermal/thermal_core.c b/drivers/thermal/thermal_core.c
>> index c6d74bc1c90b..6561e3767529 100644
>> --- a/drivers/thermal/thermal_core.c
>> +++ b/drivers/thermal/thermal_core.c
>> @@ -1477,6 +1477,9 @@ thermal_zone_device_register(const char *type, int
>> trips, int mask,
>> goto unregister;
>> }
>>
>> +if (tz->tzp && tz->tzp->userspace)
>> +thermal_zone_device_disable(tz);
>> +
>> mutex_lock(&thermal_list_lock);
>> list_add_tail(&tz->node, &thermal_tz_list);
>> mutex_unlock(&thermal_list_lock);
>> diff --git a/include/linux/thermal.h b/include/linux/thermal.h
>> index d07ea27e72a9..e8e8fac78fc8 100644
>> --- a/include/linux/thermal.h
>> +++ b/include/linux/thermal.h
>> @@ -247,6 +247,8 @@ struct thermal_zone_params {
>> */
>> bool no_hwmon;
>>
>> +bool userspace;
>> +
>> int num_tbps; /* Number of tbp entries */
>> struct thermal_bind_params *tbp;
>>
>>
>
>
> --
> Facebook |
> Twitter |
>
[PATCH v5 3/5] clk: sifive: Add a driver for the SiFive FU740 PRCI IP block
Add driver code for the SiFive FU740 PRCI IP block. This IP block
handles reset and clock control for the SiFive FU740 device and
implements SoC-level clock tree controls and dividers.
The link of unmatched as follow, and the U740-C000 manual would
be present in the same page as soon.
https://www.sifive.com/boards/hifive-unmatched
This driver contains bug fixes and contributions from
Henry Styles
Erik Danie
Pragnesh Patel
Signed-off-by: Zong Li
Reviewed-by: Pragnesh Patel
Acked-by: Palmer Dabbelt
Cc: Henry Styles
Cc: Erik Danie
Cc: Pragnesh Patel
---
drivers/clk/sifive/Kconfig| 4 +-
drivers/clk/sifive/Makefile | 2 +-
drivers/clk/sifive/fu740-prci.c | 111
drivers/clk/sifive/fu740-prci.h | 21 +++
drivers/clk/sifive/sifive-prci.c | 120 ++
drivers/clk/sifive/sifive-prci.h | 88 +
include/dt-bindings/clock/sifive-fu740-prci.h | 23
7 files changed, 366 insertions(+), 3 deletions(-)
create mode 100644 drivers/clk/sifive/fu740-prci.c
create mode 100644 drivers/clk/sifive/fu740-prci.h
create mode 100644 include/dt-bindings/clock/sifive-fu740-prci.h
diff --git a/drivers/clk/sifive/Kconfig b/drivers/clk/sifive/Kconfig
index ab48cf7e0105..1c14eb20c066 100644
--- a/drivers/clk/sifive/Kconfig
+++ b/drivers/clk/sifive/Kconfig
@@ -13,7 +13,7 @@ config CLK_SIFIVE_PRCI
select CLK_ANALOGBITS_WRPLL_CLN28HPC
help
Supports the Power Reset Clock interface (PRCI) IP block found in
- FU540 SoCs. If this kernel is meant to run on a SiFive FU540 SoC,
- enable this driver.
+ FU540/FU740 SoCs. If this kernel is meant to run on a SiFive FU540/
+ FU740 SoCs, enable this driver.
endif
diff --git a/drivers/clk/sifive/Makefile b/drivers/clk/sifive/Makefile
index 3074cdbc6009..7b06fc04e6b3 100644
--- a/drivers/clk/sifive/Makefile
+++ b/drivers/clk/sifive/Makefile
@@ -1,2 +1,2 @@
# SPDX-License-Identifier: GPL-2.0-only
-obj-$(CONFIG_CLK_SIFIVE_PRCI) += sifive-prci.o fu540-prci.o
+obj-$(CONFIG_CLK_SIFIVE_PRCI) += sifive-prci.o fu540-prci.o fu740-prci.o
diff --git a/drivers/clk/sifive/fu740-prci.c b/drivers/clk/sifive/fu740-prci.c
new file mode 100644
index ..41ddd4431497
--- /dev/null
+++ b/drivers/clk/sifive/fu740-prci.c
@@ -0,0 +1,111 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2020 SiFive, Inc.
+ * Copyright (C) 2020 Zong Li
+ */
+
+#include
+#include
+#include "sifive-prci.h"
+
+/* PRCI integration data for each WRPLL instance */
+
+static struct __prci_wrpll_data __prci_corepll_data = {
+ .cfg0_offs = PRCI_COREPLLCFG0_OFFSET,
+ .enable_bypass = sifive_prci_coreclksel_use_hfclk,
+ .disable_bypass = sifive_prci_coreclksel_use_final_corepll,
+};
+
+static struct __prci_wrpll_data __prci_ddrpll_data = {
+ .cfg0_offs = PRCI_DDRPLLCFG0_OFFSET,
+};
+
+static struct __prci_wrpll_data __prci_gemgxlpll_data = {
+ .cfg0_offs = PRCI_GEMGXLPLLCFG0_OFFSET,
+};
+
+static struct __prci_wrpll_data __prci_dvfscorepll_data = {
+ .cfg0_offs = PRCI_DVFSCOREPLLCFG0_OFFSET,
+ .enable_bypass = sifive_prci_corepllsel_use_corepll,
+ .disable_bypass = sifive_prci_corepllsel_use_dvfscorepll,
+};
+
+static struct __prci_wrpll_data __prci_hfpclkpll_data = {
+ .cfg0_offs = PRCI_HFPCLKPLLCFG0_OFFSET,
+ .enable_bypass = sifive_prci_hfpclkpllsel_use_hfclk,
+ .disable_bypass = sifive_prci_hfpclkpllsel_use_hfpclkpll,
+};
+
+static struct __prci_wrpll_data __prci_cltxpll_data = {
+ .cfg0_offs = PRCI_CLTXPLLCFG0_OFFSET,
+};
+
+/* Linux clock framework integration */
+
+static const struct clk_ops sifive_fu740_prci_wrpll_clk_ops = {
+ .set_rate = sifive_prci_wrpll_set_rate,
+ .round_rate = sifive_prci_wrpll_round_rate,
+ .recalc_rate = sifive_prci_wrpll_recalc_rate,
+};
+
+static const struct clk_ops sifive_fu740_prci_wrpll_ro_clk_ops = {
+ .recalc_rate = sifive_prci_wrpll_recalc_rate,
+};
+
+static const struct clk_ops sifive_fu740_prci_tlclksel_clk_ops = {
+ .recalc_rate = sifive_prci_tlclksel_recalc_rate,
+};
+
+static const struct clk_ops sifive_fu740_prci_hfpclkplldiv_clk_ops = {
+ .recalc_rate = sifive_prci_hfpclkplldiv_recalc_rate,
+};
+
+/* List of clock controls provided by the PRCI */
+struct __prci_clock __prci_init_clocks_fu740[] = {
+ [PRCI_CLK_COREPLL] = {
+ .name = "corepll",
+ .parent_name = "hfclk",
+ .ops = &sifive_fu740_prci_wrpll_clk_ops,
+ .pwd = &__prci_corepll_data,
+ },
+ [PRCI_CLK_DDRPLL] = {
+ .name = "ddrpll",
+ .parent_name = "hfclk",
+ .ops = &sifive_fu740_prci_wrpll_ro_clk_ops,
+ .pwd = &__prci_ddrpll_data,
+ },
+ [PRCI_CLK_GEMGXLPLL] = {
+ .name = "gemgxlpll",
+ .parent_name = "hfclk",
+ .ops = &
[PATCH v5 4/5] clk: sifive: Fix the wrong bit field shift
The clk enable bit should be 31 instead of 24. Signed-off-by: Zong Li Reported-by: Pragnesh Patel --- drivers/clk/sifive/sifive-prci.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/clk/sifive/sifive-prci.h b/drivers/clk/sifive/sifive-prci.h index 7e509dfb72d1..88493f3b9edf 100644 --- a/drivers/clk/sifive/sifive-prci.h +++ b/drivers/clk/sifive/sifive-prci.h @@ -59,7 +59,7 @@ /* DDRPLLCFG1 */ #define PRCI_DDRPLLCFG1_OFFSET 0x10 -#define PRCI_DDRPLLCFG1_CKE_SHIFT 24 +#define PRCI_DDRPLLCFG1_CKE_SHIFT 31 #define PRCI_DDRPLLCFG1_CKE_MASK (0x1 << PRCI_DDRPLLCFG1_CKE_SHIFT) /* GEMGXLPLLCFG0 */ @@ -81,7 +81,7 @@ /* GEMGXLPLLCFG1 */ #define PRCI_GEMGXLPLLCFG1_OFFSET 0x20 -#define PRCI_GEMGXLPLLCFG1_CKE_SHIFT 24 +#define PRCI_GEMGXLPLLCFG1_CKE_SHIFT 31 #define PRCI_GEMGXLPLLCFG1_CKE_MASK(0x1 << PRCI_GEMGXLPLLCFG1_CKE_SHIFT) /* CORECLKSEL */ -- 2.29.2
[PATCH v5 2/5] clk: sifive: Use common name for prci configuration
Use generic name CLK_SIFIVE_PRCI instead of CLK_SIFIVE_FU540_PRCI. This patch is prepared for fu740 support. Signed-off-by: Zong Li Reviewed-by: Palmer Dabbelt Acked-by: Palmer Dabbelt Reviewed-by: Pragnesh Patel --- arch/riscv/Kconfig.socs | 2 +- drivers/clk/sifive/Kconfig | 6 +++--- drivers/clk/sifive/Makefile | 2 +- 3 files changed, 5 insertions(+), 5 deletions(-) diff --git a/arch/riscv/Kconfig.socs b/arch/riscv/Kconfig.socs index 8a55f6156661..3284d5c291be 100644 --- a/arch/riscv/Kconfig.socs +++ b/arch/riscv/Kconfig.socs @@ -5,7 +5,7 @@ config SOC_SIFIVE select SERIAL_SIFIVE if TTY select SERIAL_SIFIVE_CONSOLE if TTY select CLK_SIFIVE - select CLK_SIFIVE_FU540_PRCI + select CLK_SIFIVE_PRCI select SIFIVE_PLIC help This enables support for SiFive SoC platform hardware. diff --git a/drivers/clk/sifive/Kconfig b/drivers/clk/sifive/Kconfig index f3b4eb9cb0f5..ab48cf7e0105 100644 --- a/drivers/clk/sifive/Kconfig +++ b/drivers/clk/sifive/Kconfig @@ -8,12 +8,12 @@ menuconfig CLK_SIFIVE if CLK_SIFIVE -config CLK_SIFIVE_FU540_PRCI - bool "PRCI driver for SiFive FU540 SoCs" +config CLK_SIFIVE_PRCI + bool "PRCI driver for SiFive SoCs" select CLK_ANALOGBITS_WRPLL_CLN28HPC help Supports the Power Reset Clock interface (PRCI) IP block found in - FU540 SoCs. If this kernel is meant to run on a SiFive FU540 SoC, + FU540 SoCs. If this kernel is meant to run on a SiFive FU540 SoC, enable this driver. endif diff --git a/drivers/clk/sifive/Makefile b/drivers/clk/sifive/Makefile index 51b6ebc359e4..3074cdbc6009 100644 --- a/drivers/clk/sifive/Makefile +++ b/drivers/clk/sifive/Makefile @@ -1,2 +1,2 @@ # SPDX-License-Identifier: GPL-2.0-only -obj-$(CONFIG_CLK_SIFIVE_FU540_PRCI)+= sifive-prci.o fu540-prci.o +obj-$(CONFIG_CLK_SIFIVE_PRCI) += sifive-prci.o fu540-prci.o -- 2.29.2
[PATCH v5 5/5] clk: sifive: Add clock enable and disable ops
From: Pragnesh Patel
Add new functions "sifive_prci_clock_enable(), sifive_prci_clock_disable()
and sifive_clk_is_enabled()" to enable or disable the PRCI clock
Signed-off-by: Pragnesh Patel
---
drivers/clk/sifive/fu540-prci.c | 6 +++
drivers/clk/sifive/fu740-prci.c | 9
drivers/clk/sifive/sifive-prci.c | 91
drivers/clk/sifive/sifive-prci.h | 12 +
4 files changed, 109 insertions(+), 9 deletions(-)
diff --git a/drivers/clk/sifive/fu540-prci.c b/drivers/clk/sifive/fu540-prci.c
index 34dc4ea6a3af..3fbee1da9701 100644
--- a/drivers/clk/sifive/fu540-prci.c
+++ b/drivers/clk/sifive/fu540-prci.c
@@ -33,16 +33,19 @@
static struct __prci_wrpll_data __prci_corepll_data = {
.cfg0_offs = PRCI_COREPLLCFG0_OFFSET,
+ .cfg1_offs = PRCI_COREPLLCFG1_OFFSET,
.enable_bypass = sifive_prci_coreclksel_use_hfclk,
.disable_bypass = sifive_prci_coreclksel_use_corepll,
};
static struct __prci_wrpll_data __prci_ddrpll_data = {
.cfg0_offs = PRCI_DDRPLLCFG0_OFFSET,
+ .cfg1_offs = PRCI_DDRPLLCFG1_OFFSET,
};
static struct __prci_wrpll_data __prci_gemgxlpll_data = {
.cfg0_offs = PRCI_GEMGXLPLLCFG0_OFFSET,
+ .cfg1_offs = PRCI_GEMGXLPLLCFG1_OFFSET,
};
/* Linux clock framework integration */
@@ -51,6 +54,9 @@ static const struct clk_ops sifive_fu540_prci_wrpll_clk_ops =
{
.set_rate = sifive_prci_wrpll_set_rate,
.round_rate = sifive_prci_wrpll_round_rate,
.recalc_rate = sifive_prci_wrpll_recalc_rate,
+ .enable = sifive_prci_clock_enable,
+ .disable = sifive_prci_clock_disable,
+ .is_enabled = sifive_clk_is_enabled,
};
static const struct clk_ops sifive_fu540_prci_wrpll_ro_clk_ops = {
diff --git a/drivers/clk/sifive/fu740-prci.c b/drivers/clk/sifive/fu740-prci.c
index 41ddd4431497..db8300223745 100644
--- a/drivers/clk/sifive/fu740-prci.c
+++ b/drivers/clk/sifive/fu740-prci.c
@@ -12,32 +12,38 @@
static struct __prci_wrpll_data __prci_corepll_data = {
.cfg0_offs = PRCI_COREPLLCFG0_OFFSET,
+ .cfg1_offs = PRCI_COREPLLCFG1_OFFSET,
.enable_bypass = sifive_prci_coreclksel_use_hfclk,
.disable_bypass = sifive_prci_coreclksel_use_final_corepll,
};
static struct __prci_wrpll_data __prci_ddrpll_data = {
.cfg0_offs = PRCI_DDRPLLCFG0_OFFSET,
+ .cfg1_offs = PRCI_DDRPLLCFG1_OFFSET,
};
static struct __prci_wrpll_data __prci_gemgxlpll_data = {
.cfg0_offs = PRCI_GEMGXLPLLCFG0_OFFSET,
+ .cfg1_offs = PRCI_GEMGXLPLLCFG1_OFFSET,
};
static struct __prci_wrpll_data __prci_dvfscorepll_data = {
.cfg0_offs = PRCI_DVFSCOREPLLCFG0_OFFSET,
+ .cfg1_offs = PRCI_DVFSCOREPLLCFG1_OFFSET,
.enable_bypass = sifive_prci_corepllsel_use_corepll,
.disable_bypass = sifive_prci_corepllsel_use_dvfscorepll,
};
static struct __prci_wrpll_data __prci_hfpclkpll_data = {
.cfg0_offs = PRCI_HFPCLKPLLCFG0_OFFSET,
+ .cfg1_offs = PRCI_HFPCLKPLLCFG1_OFFSET,
.enable_bypass = sifive_prci_hfpclkpllsel_use_hfclk,
.disable_bypass = sifive_prci_hfpclkpllsel_use_hfpclkpll,
};
static struct __prci_wrpll_data __prci_cltxpll_data = {
.cfg0_offs = PRCI_CLTXPLLCFG0_OFFSET,
+ .cfg1_offs = PRCI_CLTXPLLCFG1_OFFSET,
};
/* Linux clock framework integration */
@@ -46,6 +52,9 @@ static const struct clk_ops sifive_fu740_prci_wrpll_clk_ops =
{
.set_rate = sifive_prci_wrpll_set_rate,
.round_rate = sifive_prci_wrpll_round_rate,
.recalc_rate = sifive_prci_wrpll_recalc_rate,
+ .enable = sifive_prci_clock_enable,
+ .disable = sifive_prci_clock_disable,
+ .is_enabled = sifive_clk_is_enabled,
};
static const struct clk_ops sifive_fu740_prci_wrpll_ro_clk_ops = {
diff --git a/drivers/clk/sifive/sifive-prci.c b/drivers/clk/sifive/sifive-prci.c
index cc4b4c6b4437..5922be9edc17 100644
--- a/drivers/clk/sifive/sifive-prci.c
+++ b/drivers/clk/sifive/sifive-prci.c
@@ -113,7 +113,7 @@ static u32 __prci_wrpll_pack(const struct wrpll_cfg *c)
}
/**
- * __prci_wrpll_read_cfg() - read the WRPLL configuration from the PRCI
+ * __prci_wrpll_read_cfg0() - read the WRPLL configuration from the PRCI
* @pd: PRCI context
* @pwd: PRCI WRPLL metadata
*
@@ -124,14 +124,14 @@ static u32 __prci_wrpll_pack(const struct wrpll_cfg *c)
* Context: Any context. Caller must prevent the records pointed to by
* @pd and @pwd from changing during execution.
*/
-static void __prci_wrpll_read_cfg(struct __prci_data *pd,
- struct __prci_wrpll_data *pwd)
+static void __prci_wrpll_read_cfg0(struct __prci_data *pd,
+ struct __prci_wrpll_data *pwd)
{
__prci_wrpll_unpack(&pwd->c, __prci_readl(pd, pwd->cfg0_offs));
}
/**
- * __prci_wrpll_write_cfg() - write WRPLL configuration into the PRCI
+ * __prci_wrpll_write_cfg0() - write WRPLL configuration into the PRCI
* @pd: PRCI context
* @pwd: PR
Re: [PATCH v1 0/9] Enable root to update the blacklist keyring
On 30/11/2020 03:40, Jarkko Sakkinen wrote:
> On Fri, Nov 20, 2020 at 07:04:17PM +0100, Mickaël Salaün wrote:
>> Hi,
>>
>> This patch series mainly add a new configuration option to enable the
>> root user to load signed keys in the blacklist keyring. This keyring is
>> useful to "untrust" certificates or files. Enabling to safely update
>> this keyring without recompiling the kernel makes it more usable.
>
> I apologize for latency. This cycle has been difficult because of
> final cuts with the huge SGX patch set.
>
> I did skim through this and did not see anything striking (but it
> was a quick look).
>
> What would be easiest way to smoke test the changes?
An easy way to test it is to enable the second trusted keyring to
dynamically load certificates in the kernel. Then we can create a hash
of a valid certificate (but not loaded yet) and sign it as explained in
tools/certs/print-cert-tbs-hash.sh (patch 9/9). Once this hash is loaded
in the kernel, loading the blacklisted certificate will be denied. We
can also test it with a PKCS#7 signature chain, either with the
blacklist keyring itself, or with a signed dm-verity image.
>
>> Regards,
>>
>> Mickaël Salaün (9):
>> certs: Fix blacklisted hexadecimal hash string check
>> certs: Make blacklist_vet_description() more strict
>> certs: Factor out the blacklist hash creation
>> certs: Check that builtin blacklist hashes are valid
>> PKCS#7: Fix missing include
>> certs: Fix blacklist flag type confusion
>> certs: Allow root user to append signed hashes to the blacklist
>> keyring
>> certs: Replace K{U,G}IDT_INIT() with GLOBAL_ROOT_{U,G}ID
>> tools/certs: Add print-cert-tbs-hash.sh
>>
>> MAINTAINERS | 2 +
>> certs/.gitignore | 1 +
>> certs/Kconfig | 10 +
>> certs/Makefile| 15 +-
>> certs/blacklist.c | 210 +-
>> certs/system_keyring.c| 5 +-
>> crypto/asymmetric_keys/x509_public_key.c | 3 +-
>> include/keys/system_keyring.h | 14 +-
>> include/linux/verification.h | 2 +
>> scripts/check-blacklist-hashes.awk| 37 +++
>> .../platform_certs/keyring_handler.c | 26 +--
>> tools/certs/print-cert-tbs-hash.sh| 91
>> 12 files changed, 335 insertions(+), 81 deletions(-)
>> create mode 100755 scripts/check-blacklist-hashes.awk
>> create mode 100755 tools/certs/print-cert-tbs-hash.sh
>>
>>
>> base-commit: 09162bc32c880a791c6c0668ce0745cf7958f576
>> --
>> 2.29.2
>>
>>
>
> /Jarkko
>
RE: [EXT] Re: [v3 01/11] irqchip: ls-extirq: Add LS1043A, LS1088A external interrupt
>
> On 2020-11-30 03:30, Biwen Li wrote:
> > From: Hou Zhiqiang
> >
> > Add an new IRQ chip declaration for LS1043A and LS1088A
> > - compatible "fsl,ls1043a-extirq" for LS1043A, LS1046A.
> > - compatible "fsl,ls1088a-extirq" for LS1088A, LS208xA, LX216xA
> >
> > Signed-off-by: Hou Zhiqiang
> > Signed-off-by: Biwen Li
> > ---
> > Change in v3:
> > - cleanup code
> > - remove robust copyright
> >
> > Change in v2:
> > - add despcription of bit reverse
> > - update copyright
> >
> > drivers/irqchip/irq-ls-extirq.c | 17 +++--
> > 1 file changed, 7 insertions(+), 10 deletions(-)
> >
> > diff --git a/drivers/irqchip/irq-ls-extirq.c
> > b/drivers/irqchip/irq-ls-extirq.c index 4d1179fed77c..47804ce78b21
> > 100644
> > --- a/drivers/irqchip/irq-ls-extirq.c
> > +++ b/drivers/irqchip/irq-ls-extirq.c
> > @@ -18,7 +18,7 @@
> > struct ls_extirq_data {
> > struct regmap *syscon;
> > u32 intpcr;
> > - boolbit_reverse;
> > + boolis_ls1021a_or_ls1043a;
> > u32 nirq;
> > struct irq_fwspec map[MAXIRQ];
> > };
> > @@ -30,7 +30,7 @@ ls_extirq_set_type(struct irq_data *data, unsigned
> > int type)
> > irq_hw_number_t hwirq = data->hwirq;
> > u32 value, mask;
> >
> > - if (priv->bit_reverse)
> > + if (priv->is_ls1021a_or_ls1043a)
> > mask = 1U << (31 - hwirq);
> > else
> > mask = 1U << hwirq;
> > @@ -174,14 +174,9 @@ ls_extirq_of_init(struct device_node *node,
> > struct device_node *parent)
> > if (ret)
> > goto out;
> >
> > - if (of_device_is_compatible(node, "fsl,ls1021a-extirq")) {
> > - u32 revcr;
> > -
> > - ret = regmap_read(priv->syscon, LS1021A_SCFGREVCR,
> &revcr);
> > - if (ret)
> > - goto out;
> > - priv->bit_reverse = (revcr != 0);
> > - }
>
> This isn't explained in the commit message. You are changing the way you infer
> some properties, and that's not innocent. Please describe all important
> changes
> in the commit message.
Sure, will update commit message for this.
>
> > + if (of_device_is_compatible(node, "fsl,ls1021a-extirq") || \
>
> Spurious trailing \?
Don't need it, will remove it in v4.
>
> > + of_device_is_compatible(node, "fsl,ls1043a-extirq"))
> > + priv->is_ls1021a_or_ls1043a = true;
>
> Which is better written as:
>
> priv->is_ls1021a_or_ls1043a = (of_device_is_compatible(node,
> "fsl,ls1021a-extirq") ||
>
> of_device_is_compatible(node, "fsl,ls1043a-extirq"));
Sure, np. Will update it in v4.
> >
> > domain = irq_domain_add_hierarchy(parent_domain, 0, priv->nirq,
> node,
> > &extirq_domain_ops, priv);
> @@
> > -195,3 +190,5 @@ ls_extirq_of_init(struct device_node *node, struct
> > device_node *parent) }
> >
> > IRQCHIP_DECLARE(ls1021a_extirq, "fsl,ls1021a-extirq",
> > ls_extirq_of_init);
> > +IRQCHIP_DECLARE(ls1043a_extirq, "fsl,ls1043a-extirq",
> > ls_extirq_of_init);
> > +IRQCHIP_DECLARE(ls1088a_extirq, "fsl,ls1088a-extirq",
> > ls_extirq_of_init);
>
> Thanks,
>
> M.
> --
> Jazz is not dead. It just smells funny...
Re: [PATCH 3/6] dma-iommu: remove __iommu_dma_mmap
On Tue, Nov 24, 2020 at 04:38:42PM +0100, Ricardo Ribalda wrote: > From: Christoph Hellwig > > The function has a single caller, so open code it there and take > advantage of the precalculated page count variable. > > Signed-off-by: Christoph Hellwig It turns out this isn't really required for the series. I think it is a useful cleanup, but it should probably be picked up separately. Robin, any comments?
Re: [PATCH 2/6] dma-direct: use __GFP_ZERO in dma_direct_alloc_pages
On Tue, Nov 24, 2020 at 04:38:41PM +0100, Ricardo Ribalda wrote: > From: Christoph Hellwig > > Prepare for supporting the DMA_ATTR_NO_KERNEL_MAPPING flag in > dma_alloc_pages. > > Signed-off-by: Christoph Hellwig FYI, this patch should be dropped as I've implemented the functionality differently.
[PATCH 1/4] net: ti: am65-cpsw-nuss: Add devlink support
AM65 NUSS ethernet switch on K3 devices can be configured to work either
in independent mac mode where each port acts as independent network
interface (multi mac) or switch mode.
Add devlink hooks to provide a way to switch b/w these modes.
Signed-off-by: Vignesh Raghavendra
---
.../devlink/am65-nuss-cpsw-switch.rst | 26 ++
Documentation/networking/devlink/index.rst| 1 +
drivers/net/ethernet/ti/Kconfig | 10 +
drivers/net/ethernet/ti/am65-cpsw-nuss.c | 363 +-
drivers/net/ethernet/ti/am65-cpsw-nuss.h | 22 ++
5 files changed, 404 insertions(+), 18 deletions(-)
create mode 100644 Documentation/networking/devlink/am65-nuss-cpsw-switch.rst
diff --git a/Documentation/networking/devlink/am65-nuss-cpsw-switch.rst
b/Documentation/networking/devlink/am65-nuss-cpsw-switch.rst
new file mode 100644
index ..1e589c26abff
--- /dev/null
+++ b/Documentation/networking/devlink/am65-nuss-cpsw-switch.rst
@@ -0,0 +1,26 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+==
+am65-cpsw-nuss devlink support
+==
+
+This document describes the devlink features implemented by the
``am65-cpsw-nuss``
+device driver.
+
+Parameters
+==
+
+The ``am65-cpsw-nuss`` driver implements the following driver-specific
+parameters.
+
+.. list-table:: Driver-specific parameters implemented
+ :widths: 5 5 5 85
+
+ * - Name
+ - Type
+ - Mode
+ - Description
+ * - ``switch_mode``
+ - Boolean
+ - runtime
+ - Enable switch mode
diff --git a/Documentation/networking/devlink/index.rst
b/Documentation/networking/devlink/index.rst
index d82874760ae2..b9064d6f4a6d 100644
--- a/Documentation/networking/devlink/index.rst
+++ b/Documentation/networking/devlink/index.rst
@@ -44,3 +44,4 @@ parameters, info versions, and other features it supports.
sja1105
qed
ti-cpsw-switch
+ am65-nuss-cpsw-switch
diff --git a/drivers/net/ethernet/ti/Kconfig b/drivers/net/ethernet/ti/Kconfig
index abfc4c435d59..affcf92cd3aa 100644
--- a/drivers/net/ethernet/ti/Kconfig
+++ b/drivers/net/ethernet/ti/Kconfig
@@ -92,6 +92,7 @@ config TI_CPTS
config TI_K3_AM65_CPSW_NUSS
tristate "TI K3 AM654x/J721E CPSW Ethernet driver"
depends on ARCH_K3 && OF && TI_K3_UDMA_GLUE_LAYER
+ select NET_DEVLINK
select TI_DAVINCI_MDIO
imply PHY_TI_GMII_SEL
depends on TI_K3_AM65_CPTS || !TI_K3_AM65_CPTS
@@ -105,6 +106,15 @@ config TI_K3_AM65_CPSW_NUSS
To compile this driver as a module, choose M here: the module
will be called ti-am65-cpsw-nuss.
+config TI_K3_AM65_CPSW_SWITCHDEV
+ bool "TI K3 AM654x/J721E CPSW Switch mode support"
+ depends on TI_K3_AM65_CPSW_NUSS
+ depends on NET_SWITCHDEV
+ help
+This enables switchdev support for TI K3 CPSWxG Ethernet
+Switch. Enable this driver to support hardware switch support for AM65
+CPSW NUSS driver.
+
config TI_K3_AM65_CPTS
tristate "TI K3 AM65x CPTS"
depends on ARCH_K3 && OF
diff --git a/drivers/net/ethernet/ti/am65-cpsw-nuss.c
b/drivers/net/ethernet/ti/am65-cpsw-nuss.c
index 766e8866bbef..a635f6be7979 100644
--- a/drivers/net/ethernet/ti/am65-cpsw-nuss.c
+++ b/drivers/net/ethernet/ti/am65-cpsw-nuss.c
@@ -406,6 +406,11 @@ void am65_cpsw_nuss_set_p0_ptype(struct am65_cpsw_common
*common)
writel(val, host_p->port_base + AM65_CPSW_PORT_REG_PRI_CTL);
}
+static void am65_cpsw_init_host_port_switch(struct am65_cpsw_common *common);
+static void am65_cpsw_init_host_port_emac(struct am65_cpsw_common *common);
+static void am65_cpsw_init_port_switch_ale(struct am65_cpsw_port *port);
+static void am65_cpsw_init_port_emac_ale(struct am65_cpsw_port *port);
+
static int am65_cpsw_nuss_common_open(struct am65_cpsw_common *common,
netdev_features_t features)
{
@@ -452,9 +457,6 @@ static int am65_cpsw_nuss_common_open(struct
am65_cpsw_common *common,
ALE_DEFAULT_THREAD_ID, 0);
cpsw_ale_control_set(common->ale, HOST_PORT_NUM,
ALE_DEFAULT_THREAD_ENABLE, 1);
- if (AM65_CPSW_IS_CPSW2G(common))
- cpsw_ale_control_set(common->ale, HOST_PORT_NUM,
-ALE_PORT_NOLEARN, 1);
/* switch to vlan unaware mode */
cpsw_ale_control_set(common->ale, HOST_PORT_NUM, ALE_VLAN_AWARE, 1);
cpsw_ale_control_set(common->ale, HOST_PORT_NUM,
@@ -468,6 +470,11 @@ static int am65_cpsw_nuss_common_open(struct
am65_cpsw_common *common,
port_mask, port_mask,
port_mask & ~ALE_PORT_HOST);
+ if (common->is_emac_mode)
+ am65_cpsw_init_host_port_emac(common);
+ else
+ am65_cpsw_init_host_port_switch(common);
+
for (i = 0; i < common->rx_chns.descs_num; i++) {
skb = __netdev_alloc_skb_ip_align(NULL,
[PATCH 0/4] net: ti: am65-cpsw-nuss: Add switchdev driver
This series adds switchdev support for AM65 CPSW NUSS driver to support multi port CPSW present on J721e and AM64 SoCs. It adds devlink hook to switch b/w switch mode and multi mac mode. Vignesh Raghavendra (4): net: ti: am65-cpsw-nuss: Add devlink support net: ti: am65-cpsw-nuss: Add netdevice notifiers net: ti: am65-cpsw-nuss: Add switchdev support docs: networking: ti: Add driver doc for AM65 NUSS switch driver .../device_drivers/ethernet/index.rst | 1 + .../ethernet/ti/am65_nuss_cpsw_switchdev.rst | 143 + .../devlink/am65-nuss-cpsw-switch.rst | 26 + Documentation/networking/devlink/index.rst| 1 + drivers/net/ethernet/ti/Kconfig | 10 + drivers/net/ethernet/ti/Makefile | 1 + drivers/net/ethernet/ti/am65-cpsw-nuss.c | 511 +++- drivers/net/ethernet/ti/am65-cpsw-nuss.h | 26 + drivers/net/ethernet/ti/am65-cpsw-switchdev.c | 572 ++ drivers/net/ethernet/ti/am65-cpsw-switchdev.h | 34 ++ 10 files changed, 1306 insertions(+), 19 deletions(-) create mode 100644 Documentation/networking/device_drivers/ethernet/ti/am65_nuss_cpsw_switchdev.rst create mode 100644 Documentation/networking/devlink/am65-nuss-cpsw-switch.rst create mode 100644 drivers/net/ethernet/ti/am65-cpsw-switchdev.c create mode 100644 drivers/net/ethernet/ti/am65-cpsw-switchdev.h -- 2.29.2
[PATCH 2/4] net: ti: am65-cpsw-nuss: Add netdevice notifiers
Register netdevice notifiers in order to receive notification when
individual MAC ports are added to the HW bridge.
Signed-off-by: Vignesh Raghavendra
---
drivers/net/ethernet/ti/am65-cpsw-nuss.c | 130 ++-
drivers/net/ethernet/ti/am65-cpsw-nuss.h | 4 +
2 files changed, 133 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/ti/am65-cpsw-nuss.c
b/drivers/net/ethernet/ti/am65-cpsw-nuss.c
index a635f6be7979..a7e5a0489aec 100644
--- a/drivers/net/ethernet/ti/am65-cpsw-nuss.c
+++ b/drivers/net/ethernet/ti/am65-cpsw-nuss.c
@@ -2023,6 +2023,126 @@ static void am65_cpsw_nuss_cleanup_ndev(struct
am65_cpsw_common *common)
}
}
+static void am65_cpsw_port_offload_fwd_mark_update(struct am65_cpsw_common
*common)
+{
+ int set_val = 0;
+ int i;
+
+ if (common->br_members == (GENMASK(common->port_num, 1) &
~common->disabled_ports_mask))
+ set_val = 1;
+
+ dev_dbg(common->dev, "set offload_fwd_mark %d\n", set_val);
+
+ for (i = 1; i <= common->port_num; i++) {
+ struct am65_cpsw_port *port = am65_common_get_port(common, i);
+ struct am65_cpsw_ndev_priv *priv =
am65_ndev_to_priv(port->ndev);
+
+ priv->offload_fwd_mark = set_val;
+ }
+}
+
+bool am65_cpsw_port_dev_check(const struct net_device *ndev)
+{
+ if (ndev->netdev_ops == &am65_cpsw_nuss_netdev_ops) {
+ struct am65_cpsw_common *common = am65_ndev_to_common(ndev);
+
+ return !common->is_emac_mode;
+ }
+
+ return false;
+}
+
+static int am65_cpsw_netdevice_port_link(struct net_device *ndev, struct
net_device *br_ndev)
+{
+ struct am65_cpsw_common *common = am65_ndev_to_common(ndev);
+ struct am65_cpsw_ndev_priv *priv = am65_ndev_to_priv(ndev);
+
+ if (!common->br_members) {
+ common->hw_bridge_dev = br_ndev;
+ } else {
+ /* This is adding the port to a second bridge, this is
+* unsupported
+*/
+ if (common->hw_bridge_dev != br_ndev)
+ return -EOPNOTSUPP;
+ }
+
+ common->br_members |= BIT(priv->port->port_id);
+
+ am65_cpsw_port_offload_fwd_mark_update(common);
+
+ return NOTIFY_DONE;
+}
+
+static void am65_cpsw_netdevice_port_unlink(struct net_device *ndev)
+{
+ struct am65_cpsw_common *common = am65_ndev_to_common(ndev);
+ struct am65_cpsw_ndev_priv *priv = am65_ndev_to_priv(ndev);
+
+ common->br_members &= ~BIT(priv->port->port_id);
+
+ am65_cpsw_port_offload_fwd_mark_update(common);
+
+ if (!common->br_members)
+ common->hw_bridge_dev = NULL;
+}
+
+/* netdev notifier */
+static int am65_cpsw_netdevice_event(struct notifier_block *unused,
+unsigned long event, void *ptr)
+{
+ struct net_device *ndev = netdev_notifier_info_to_dev(ptr);
+ struct netdev_notifier_changeupper_info *info;
+ int ret = NOTIFY_DONE;
+
+ if (!am65_cpsw_port_dev_check(ndev))
+ return NOTIFY_DONE;
+
+ switch (event) {
+ case NETDEV_CHANGEUPPER:
+ info = ptr;
+
+ if (netif_is_bridge_master(info->upper_dev)) {
+ if (info->linking)
+ ret = am65_cpsw_netdevice_port_link(ndev,
info->upper_dev);
+ else
+ am65_cpsw_netdevice_port_unlink(ndev);
+ }
+ break;
+ default:
+ return NOTIFY_DONE;
+ }
+
+ return notifier_from_errno(ret);
+}
+
+static int am65_cpsw_register_notifiers(struct am65_cpsw_common *cpsw)
+{
+ int ret = 0;
+
+ if (AM65_CPSW_IS_CPSW2G(cpsw) ||
+ !IS_REACHABLE(CONFIG_TI_K3_AM65_CPSW_SWITCHDEV))
+ return 0;
+
+ cpsw->am65_cpsw_netdevice_nb.notifier_call = &am65_cpsw_netdevice_event;
+ ret = register_netdevice_notifier(&cpsw->am65_cpsw_netdevice_nb);
+ if (ret) {
+ dev_err(cpsw->dev, "can't register netdevice notifier\n");
+ return ret;
+ }
+
+ return ret;
+}
+
+static void am65_cpsw_unregister_notifiers(struct am65_cpsw_common *cpsw)
+{
+ if (AM65_CPSW_IS_CPSW2G(cpsw) ||
+ !IS_REACHABLE(CONFIG_TI_K3_AM65_CPSW_SWITCHDEV))
+ return;
+
+ unregister_netdevice_notifier(&cpsw->am65_cpsw_netdevice_nb);
+}
+
static const struct devlink_ops am65_cpsw_devlink_ops = {};
static void am65_cpsw_init_stp_ale_entry(struct am65_cpsw_common *cpsw)
@@ -2366,17 +2486,24 @@ static int am65_cpsw_nuss_register_ndevs(struct
am65_cpsw_common *common)
}
}
- ret = am65_cpsw_nuss_register_devlink(common);
+ ret = am65_cpsw_register_notifiers(common);
if (ret)
goto err_cleanup_ndev;
+ ret = am65_cpsw_nuss_register_devlink(common);
+ if (ret)
+ goto cl
[PATCH] habanalabs: put devices before driver removal
From: Ofir Bitton
Driver never puts its device and control_device objects, hence
a memory leak is introduced every driver removal.
Signed-off-by: Ofir Bitton
Reviewed-by: Oded Gabbay
Signed-off-by: Oded Gabbay
---
drivers/misc/habanalabs/common/device.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/misc/habanalabs/common/device.c
b/drivers/misc/habanalabs/common/device.c
index 20572224099a..783bbdcb1e61 100644
--- a/drivers/misc/habanalabs/common/device.c
+++ b/drivers/misc/habanalabs/common/device.c
@@ -231,16 +231,16 @@ static int device_cdev_sysfs_add(struct hl_device *hdev)
static void device_cdev_sysfs_del(struct hl_device *hdev)
{
- /* device_release() won't be called so must free devices explicitly */
- if (!hdev->cdev_sysfs_created) {
- kfree(hdev->dev_ctrl);
- kfree(hdev->dev);
- return;
- }
+ if (!hdev->cdev_sysfs_created)
+ goto put_devices;
hl_sysfs_fini(hdev);
cdev_device_del(&hdev->cdev_ctrl, hdev->dev_ctrl);
cdev_device_del(&hdev->cdev, hdev->dev);
+
+put_devices:
+ put_device(hdev->dev);
+ put_device(hdev->dev_ctrl);
}
/*
@@ -1371,9 +1371,9 @@ int hl_device_init(struct hl_device *hdev, struct class
*hclass)
early_fini:
device_early_fini(hdev);
free_dev_ctrl:
- kfree(hdev->dev_ctrl);
+ put_device(hdev->dev_ctrl);
free_dev:
- kfree(hdev->dev);
+ put_device(hdev->dev);
out_disabled:
hdev->disabled = true;
if (add_cdev_sysfs_on_err)
--
2.17.1
[PATCH 4/4] docs: networking: ti: Add driver doc for AM65 NUSS switch driver
J721e, J7200 and AM64 have multi port switches which can work in multi
mac mode and in switch mode. Add documentation explaining how to use
different modes.
Borrowed from:
Documentation/networking/device_drivers/ethernet/ti/cpsw_switchdev.rst
Signed-off-by: Vignesh Raghavendra
---
.../device_drivers/ethernet/index.rst | 1 +
.../ethernet/ti/am65_nuss_cpsw_switchdev.rst | 143 ++
2 files changed, 144 insertions(+)
create mode 100644
Documentation/networking/device_drivers/ethernet/ti/am65_nuss_cpsw_switchdev.rst
diff --git a/Documentation/networking/device_drivers/ethernet/index.rst
b/Documentation/networking/device_drivers/ethernet/index.rst
index cbb75a1818c0..6b5dc203da2b 100644
--- a/Documentation/networking/device_drivers/ethernet/index.rst
+++ b/Documentation/networking/device_drivers/ethernet/index.rst
@@ -49,6 +49,7 @@ Contents:
stmicro/stmmac
ti/cpsw
ti/cpsw_switchdev
+ ti/am65_nuss_cpsw_switchdev
ti/tlan
toshiba/spider_net
diff --git
a/Documentation/networking/device_drivers/ethernet/ti/am65_nuss_cpsw_switchdev.rst
b/Documentation/networking/device_drivers/ethernet/ti/am65_nuss_cpsw_switchdev.rst
new file mode 100644
index ..f24adfab6a1b
--- /dev/null
+++
b/Documentation/networking/device_drivers/ethernet/ti/am65_nuss_cpsw_switchdev.rst
@@ -0,0 +1,143 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+===
+Texas Instruments K3 AM65 CPSW NUSS switchdev based ethernet driver
+===
+
+:Version: 1.0
+
+Port renaming
+=
+
+In order to rename via udev::
+
+ip -d link show dev sw0p1 | grep switchid
+
+SUBSYSTEM=="net", ACTION=="add", ATTR{phys_switch_id}==, \
+ ATTR{phys_port_name}!="", NAME="sw0$attr{phys_port_name}"
+
+
+Multi mac mode
+==
+
+- The driver is operating in multi-mac mode by default, thus
+ working as N individual network interfaces.
+
+Devlink configuration parameters
+
+
+See Documentation/networking/devlink/am65-nuss-cpsw-switch.rst
+
+Enabling "switch"
+=
+
+The Switch mode can be enabled by configuring devlink driver parameter
+"switch_mode" to 1/true::
+
+devlink dev param set platform/c00.ethernet \
+name switch_mode value true cmode runtime
+
+This can be done regardless of the state of Port's netdev devices - UP/DOWN,
but
+Port's netdev devices have to be in UP before joining to the bridge to avoid
+overwriting of bridge configuration as CPSW switch driver completely reloads
its
+configuration when first port changes its state to UP.
+
+When the both interfaces joined the bridge - CPSW switch driver will enable
+marking packets with offload_fwd_mark flag.
+
+All configuration is implemented via switchdev API.
+
+Bridge setup
+
+
+::
+
+devlink dev param set platform/c00.ethernet \
+name switch_mode value true cmode runtime
+
+ ip link add name br0 type bridge
+ ip link set dev br0 type bridge ageing_time 1000
+ ip link set dev sw0p1 up
+ ip link set dev sw0p2 up
+ ip link set dev sw0p1 master br0
+ ip link set dev sw0p2 master br0
+
+ [*] bridge vlan add dev br0 vid 1 pvid untagged self
+
+ [*] if vlan_filtering=1. where default_pvid=1
+
+ Note. Steps [*] are mandatory.
+
+
+On/off STP
+==
+
+::
+
+ ip link set dev BRDEV type bridge stp_state 1/0
+
+VLAN configuration
+==
+
+::
+
+ bridge vlan add dev br0 vid 1 pvid untagged self < add cpu port to VLAN 1
+
+Note. This step is mandatory for bridge/default_pvid.
+
+Add extra VLANs
+===
+
+ 1. untagged::
+
+ bridge vlan add dev sw0p1 vid 100 pvid untagged master
+ bridge vlan add dev sw0p2 vid 100 pvid untagged master
+ bridge vlan add dev br0 vid 100 pvid untagged self < Add cpu port
to VLAN100
+
+ 2. tagged::
+
+ bridge vlan add dev sw0p1 vid 100 master
+ bridge vlan add dev sw0p2 vid 100 master
+ bridge vlan add dev br0 vid 100 pvid tagged self < Add cpu port to
VLAN100
+
+FDBs
+
+
+FDBs are automatically added on the appropriate switch port upon detection
+
+Manually adding FDBs::
+
+bridge fdb add aa:bb:cc:dd:ee:ff dev sw0p1 master vlan 100
+bridge fdb add aa:bb:cc:dd:ee:fe dev sw0p2 master < Add on all VLANs
+
+MDBs
+
+
+MDBs are automatically added on the appropriate switch port upon detection
+
+Manually adding MDBs::
+
+ bridge mdb add dev br0 port sw0p1 grp 239.1.1.1 permanent vid 100
+ bridge mdb add dev br0 port sw0p1 grp 239.1.1.1 permanent < Add on all
VLANs
+
+Multicast flooding
+==
+CPU port mcast_flooding is always on
+
+Turning flooding on/off on swithch ports:
+bridge link set dev sw0p1 mcast_flood on/off
+
+Access and Trunk port
+=
+
+::
+
+ bridge vlan add dev sw0p1 vid 100
[PATCH 3/4] net: ti: am65-cpsw-nuss: Add switchdev support
J721e, J7200 and AM64 have multi port switches which can work in multi
mac mode and in switch mode. Add support for configuring this HW in
switch mode using devlink and switchdev notifiers.
Support is similar to existing CPSW switchdev implementation of TI's 32 bit
platform like DRA7xx.
To enable switch mode:
devlink dev param set platform/c00.ethernet name switch_mode value true
cmode runtime
All configuration is implemented via switchdev API and notifiers.
Supported:
- SWITCHDEV_ATTR_ID_PORT_PRE_BRIDGE_FLAGS
- SWITCHDEV_ATTR_ID_PORT_BRIDGE_FLAGS: BR_MCAST_FLOOD
- SWITCHDEV_ATTR_ID_PORT_STP_STATE
- SWITCHDEV_OBJ_ID_PORT_VLAN
- SWITCHDEV_OBJ_ID_PORT_MDB
- SWITCHDEV_OBJ_ID_HOST_MDB
Hence AM65 CPSW switchdev driver supports:
- FDB offloading
- MDB offloading
- VLAN filtering and offloading
- STP
Signed-off-by: Vignesh Raghavendra
---
drivers/net/ethernet/ti/Makefile | 1 +
drivers/net/ethernet/ti/am65-cpsw-nuss.c | 20 +-
drivers/net/ethernet/ti/am65-cpsw-switchdev.c | 572 ++
drivers/net/ethernet/ti/am65-cpsw-switchdev.h | 34 ++
4 files changed, 626 insertions(+), 1 deletion(-)
create mode 100644 drivers/net/ethernet/ti/am65-cpsw-switchdev.c
create mode 100644 drivers/net/ethernet/ti/am65-cpsw-switchdev.h
diff --git a/drivers/net/ethernet/ti/Makefile b/drivers/net/ethernet/ti/Makefile
index 6e779292545d..75f761efbea7 100644
--- a/drivers/net/ethernet/ti/Makefile
+++ b/drivers/net/ethernet/ti/Makefile
@@ -26,4 +26,5 @@ keystone_netcp_ethss-y := netcp_ethss.o netcp_sgmii.o
netcp_xgbepcsr.o cpsw_ale.
obj-$(CONFIG_TI_K3_AM65_CPSW_NUSS) += ti-am65-cpsw-nuss.o
ti-am65-cpsw-nuss-y := am65-cpsw-nuss.o cpsw_sl.o am65-cpsw-ethtool.o
cpsw_ale.o k3-cppi-desc-pool.o am65-cpsw-qos.o
+ti-am65-cpsw-nuss-$(CONFIG_TI_K3_AM65_CPSW_SWITCHDEV) += am65-cpsw-switchdev.o
obj-$(CONFIG_TI_K3_AM65_CPTS) += am65-cpts.o
diff --git a/drivers/net/ethernet/ti/am65-cpsw-nuss.c
b/drivers/net/ethernet/ti/am65-cpsw-nuss.c
index a7e5a0489aec..69c0366f2beb 100644
--- a/drivers/net/ethernet/ti/am65-cpsw-nuss.c
+++ b/drivers/net/ethernet/ti/am65-cpsw-nuss.c
@@ -31,6 +31,7 @@
#include "cpsw_ale.h"
#include "cpsw_sl.h"
#include "am65-cpsw-nuss.h"
+#include "am65-cpsw-switchdev.h"
#include "k3-cppi-desc-pool.h"
#include "am65-cpts.h"
@@ -228,6 +229,9 @@ static int am65_cpsw_nuss_ndo_slave_add_vid(struct
net_device *ndev,
u32 port_mask, unreg_mcast = 0;
int ret;
+ if (!common->is_emac_mode)
+ return 0;
+
if (!netif_running(ndev) || !vid)
return 0;
@@ -255,6 +259,9 @@ static int am65_cpsw_nuss_ndo_slave_kill_vid(struct
net_device *ndev,
struct am65_cpsw_port *port = am65_ndev_to_port(ndev);
int ret;
+ if (!common->is_emac_mode)
+ return 0;
+
if (!netif_running(ndev) || !vid)
return 0;
@@ -277,6 +284,11 @@ static void am65_cpsw_slave_set_promisc(struct
am65_cpsw_port *port,
{
struct am65_cpsw_common *common = port->common;
+ if (promisc && !common->is_emac_mode) {
+ dev_dbg(common->dev, "promisc mode requested in switch mode");
+ return;
+ }
+
if (promisc) {
/* Enable promiscuous mode */
cpsw_ale_control_set(common->ale, port->port_id,
@@ -796,12 +808,13 @@ static int am65_cpsw_nuss_rx_packets(struct
am65_cpsw_common *common,
new_skb = netdev_alloc_skb_ip_align(ndev, AM65_CPSW_MAX_PACKET_SIZE);
if (new_skb) {
+ ndev_priv = netdev_priv(ndev);
+ am65_cpsw_nuss_set_offload_fwd_mark(skb,
ndev_priv->offload_fwd_mark);
skb_put(skb, pkt_len);
skb->protocol = eth_type_trans(skb, ndev);
am65_cpsw_nuss_rx_csum(skb, csum_info);
napi_gro_receive(&common->napi_rx, skb);
- ndev_priv = netdev_priv(ndev);
stats = this_cpu_ptr(ndev_priv->stats);
u64_stats_update_begin(&stats->syncp);
@@ -2131,6 +2144,10 @@ static int am65_cpsw_register_notifiers(struct
am65_cpsw_common *cpsw)
return ret;
}
+ ret = am65_cpsw_switchdev_register_notifiers(cpsw);
+ if (ret)
+ unregister_netdevice_notifier(&cpsw->am65_cpsw_netdevice_nb);
+
return ret;
}
@@ -2140,6 +2157,7 @@ static void am65_cpsw_unregister_notifiers(struct
am65_cpsw_common *cpsw)
!IS_REACHABLE(CONFIG_TI_K3_AM65_CPSW_SWITCHDEV))
return;
+ am65_cpsw_switchdev_unregister_notifiers(cpsw);
unregister_netdevice_notifier(&cpsw->am65_cpsw_netdevice_nb);
}
diff --git a/drivers/net/ethernet/ti/am65-cpsw-switchdev.c
b/drivers/net/ethernet/ti/am65-cpsw-switchdev.c
new file mode 100644
index ..0fd7b90e60cf
--- /dev/null
+++ b/drivers/net/ethernet/ti/am65-cpsw-switchdev.c
@@ -0,0 +1,572 @@
+/* SPDX-License-Iden
Re: [PATCH v10 00/19] Introduce memory interconnect for NVIDIA Tegra SoCs
Hi Dmitry, The v5.10-rc6 was released from linus git tree. Generally, I will send the pull-quest about devfreq to linux-pm.git maintainer after releasing the v5.1-rc7 for the integration test on linux-pm.git. The icc patches in this patch have not yet merged. If these patches are not merged before v5.10-rc7, Maybe, I'll apply the devfreq patches for v5.12-rc1. Best Regards, Chanwoo Choi On 11/23/20 9:27 AM, Dmitry Osipenko wrote: > This series brings initial support for memory interconnect to Tegra20, > Tegra30 and Tegra124 SoCs. > > For the starter only display controllers and devfreq devices are getting > interconnect API support, others could be supported later on. The display > controllers have the biggest demand for interconnect API right now because > dynamic memory frequency scaling can't be done safely without taking into > account bandwidth requirement from the displays. In particular this series > fixes distorted display output on T30 Ouya and T124 TK1 devices. > > Changelog: > > v10 - In a longer run it will be much nicer if we could support EMC > hardware versioning on Tegra20 and it's not late to support it now. > Hence I added these new patches: > > dt-bindings: memory: tegra20: emc: Document opp-supported-hw property > memory: tegra20: Support hardware versioning and clean up OPP table > initialization > > - Removed error message from tegra30-devfreq driver about missing OPP > properties in a device-tree because EMC driver already prints that > message and it uses OPP API error code instead of checking DT directly, > which is a more correct way of doing that. > > v9: - Squashed "memory: tegra30-emc: Factor out clk initialization" into > patch "tegra30: Support interconnect framework". > Suggested by Krzysztof Kozlowski. > > - Improved Kconfig in the patch "memory: tegra124-emc: Make driver > modular" > by adding CONFIG_TEGRA124_CLK_EMC entry, which makes clk-driver changes > to look a bit more cleaner. Suggested by Krzysztof Kozlowski. > > - Dropped voltage regulator support from ICC and DT patches for now > because there is a new discussion about using a power domain abstraction > for controlling the regulator, which is likely to happen. > > - Replaced direct "operating-points-v2" property checking in EMC drivers > with checking of a returned error code from dev_pm_opp_of_add_table(). > Note that I haven't touched T20 EMC driver because it's very likely > that we'll replace that code with a common helper soon anyways. > Suggested by Viresh Kumar. > > - The T30 DT patches now include EMC OPP changes for Ouya board, which > is available now in linux-next. > > Dmitry Osipenko (19): > dt-bindings: memory: tegra20: emc: Document opp-supported-hw property > memory: tegra20: Support hardware versioning and clean up OPP table > initialization > memory: tegra30: Support interconnect framework > memory: tegra124-emc: Make driver modular > memory: tegra124-emc: Continue probing if timings are missing in > device-tree > memory: tegra124: Support interconnect framework > drm/tegra: dc: Support memory bandwidth management > drm/tegra: dc: Extend debug stats with total number of events > PM / devfreq: tegra30: Support interconnect and OPPs from device-tree > PM / devfreq: tegra30: Separate configurations per-SoC generation > PM / devfreq: tegra20: Deprecate in a favor of emc-stat based driver > ARM: tegra: Correct EMC registers size in Tegra20 device-tree > ARM: tegra: Add interconnect properties to Tegra20 device-tree > ARM: tegra: Add interconnect properties to Tegra30 device-tree > ARM: tegra: Add interconnect properties to Tegra124 device-tree > ARM: tegra: Add nvidia,memory-controller phandle to Tegra20 EMC > device-tree > ARM: tegra: Add EMC OPP properties to Tegra20 device-trees > ARM: tegra: Add EMC OPP and ICC properties to Tegra30 EMC and ACTMON > device-tree nodes > ARM: tegra: Add EMC OPP and ICC properties to Tegra124 EMC and ACTMON > device-tree nodes > > .../memory-controllers/nvidia,tegra20-emc.txt | 6 + > MAINTAINERS | 1 - > arch/arm/boot/dts/tegra124-apalis-emc.dtsi| 8 + > .../arm/boot/dts/tegra124-jetson-tk1-emc.dtsi | 8 + > arch/arm/boot/dts/tegra124-nyan-big-emc.dtsi | 10 + > .../arm/boot/dts/tegra124-nyan-blaze-emc.dtsi | 10 + > .../boot/dts/tegra124-peripherals-opp.dtsi| 419 ++ > arch/arm/boot/dts/tegra124.dtsi | 31 ++ > .../boot/dts/tegra20-acer-a500-picasso.dts| 5 + > arch/arm/boot/dts/tegra20-colibri.dtsi| 4 + > arch/arm/boot/dts/tegra20-paz00.dts | 4 + > .../arm/boot/dts/tegra20-peripherals-opp.dtsi | 109 + > arch/arm/boot/dts/tegra20.dtsi| 33 +- > ...30-asus-nexus7-grouper-memory-timings.dtsi | 12 + > arch/arm/boot/dts/tegra30
Re: [PATCH] riscv/mm: Prevent kernel module access user-space memory without uaccess routines
> + if (!user_mode(regs) && addr < TASK_SIZE && unlikely(!(regs->status & > SR_SUM))) Please avoid the overly long line.
Re: [PATCH v3] s390/pci: fix CPU address in MSI for directed IRQ
On 11/27/20 4:39 PM, Halil Pasic wrote:
> On Fri, 27 Nov 2020 11:08:10 +0100
> Niklas Schnelle wrote:
>
>>
>>
>> On 11/27/20 9:56 AM, Halil Pasic wrote:
>>> On Thu, 26 Nov 2020 18:00:37 +0100
>>> Alexander Gordeev wrote:
>>>
The directed MSIs are delivered to CPUs whose address is
written to the MSI message data. The current code assumes
that a CPU logical number (as it is seen by the kernel)
is also that CPU address.
The above assumption is not correct, as the CPU address
is rather the value returned by STAP instruction. That
value does not necessarily match the kernel logical CPU
number.
Fixes: e979ce7bced2 ("s390/pci: provide support for CPU directed
interrupts")
Signed-off-by: Alexander Gordeev
---
arch/s390/pci/pci_irq.c | 14 +++---
1 file changed, 11 insertions(+), 3 deletions(-)
diff --git a/arch/s390/pci/pci_irq.c b/arch/s390/pci/pci_irq.c
index 743f257cf2cb..75217fb63d7b 100644
--- a/arch/s390/pci/pci_irq.c
+++ b/arch/s390/pci/pci_irq.c
@@ -103,9 +103,10 @@ static int zpci_set_irq_affinity(struct irq_data
*data, const struct cpumask *de
{
struct msi_desc *entry = irq_get_msi_desc(data->irq);
struct msi_msg msg = entry->msg;
+ int cpu_addr = smp_cpu_get_cpu_address(cpumask_first(dest));
msg.address_lo &= 0xffff;
- msg.address_lo |= (cpumask_first(dest) << 8);
+ msg.address_lo |= (cpu_addr << 8);
pci_write_msi_msg(data->irq, &msg);
return IRQ_SET_MASK_OK;
@@ -238,6 +239,7 @@ int arch_setup_msi_irqs(struct pci_dev *pdev, int
nvec, int type)
unsigned long bit;
struct msi_desc *msi;
struct msi_msg msg;
+ int cpu_addr;
int rc, irq;
zdev->aisb = -1UL;
@@ -287,9 +289,15 @@ int arch_setup_msi_irqs(struct pci_dev *pdev, int
nvec, int type)
handle_percpu_irq);
msg.data = hwirq - bit;
if (irq_delivery == DIRECTED) {
+ if (msi->affinity)
+ cpu = cpumask_first(&msi->affinity->mask);
+ else
+ cpu = 0;
+ cpu_addr = smp_cpu_get_cpu_address(cpu);
+
>>>
>>> I thin style wise, I would prefer keeping the ternary operator instead
>>> of rewriting it as an if-then-else, i.e.:
>>> cpu_addr = smp_cpu_get_cpu_address(msi->affinity ?
>>>
>>> cpumask_first(&msi->affinity->mask) : 0);
>>> but either way:
>>>
>>> Reviewed-by: Halil Pasic
>>
>> Thanks for your review, lets keep the if/else its certainly not less
>> readable even if it may be less pretty.
>>
>> Found another thing (not directly in the touched code) but I'm now
>> wondering about. In zpci_handle_cpu_local_irq()
>> we do
>> struct airq_iv *dibv = zpci_ibv[smp_processor_id()];
>>
>> does that also need to use some _address() variant? If it does that
>> then dicatates that the CPU addresses must start at 0.
>>
>
> I didn't go to the bottom of this, but my understanding is that it
> does not need a _address() variant. What we need is, probably, the
> mapping between the 'id' and 'address' being a stable one.
>
> Please notice that cpu_enable_directed_irq() is called on each cpu. That
> establishes the mapping/relationship between the id and the address,
> as the machine cares for the address, and cpu_enable_directed_irq()
> cares for the id:
> static void __init cpu_enable_directed_irq(void *unused)
>
> {
>
> union zpci_sic_iib iib = {{0}};
>
>
>
> iib.cdiib.dibv_addr = (u64) zpci_ibv[smp_processor_id()]->vector;
>
>
>
> __zpci_set_irq_ctrl(SIC_IRQ_MODE_SET_CPU, 0, &iib);
>
> zpci_set_irq_ctrl(SIC_IRQ_MODE_D_SINGLE, PCI_ISC);
>
> }
Thanks for the very clear and understandable explanation, I think
you're exactly right. I didn't look very closely and missed that
cpu_enable_directed_irq() uses the smp_processor_id() thereby
establishing the mapping.
>
> Now were the id <-> address mapping to change, we would be in trouble. If
> that's possible, I don't know. My guess is that it would require cpu hot
> unplug. Niklas, are you familiar with that stuff? Should we ask, Heiko
> and Vasily?
>
> Regards,
> Halil
I'm not really familiar, with it but I think this is closely related
to what I asked Bernd Nerz. I fear that if CPUs go away we might already
be in trouble at the firmware/hardware/platform level because the CPU Address
Re: [PATCH v3 5/6] media: uvcvideo: Use dma_alloc_noncontiguos API
On Thu, Nov 26, 2020 at 08:44:50PM +0900, Sergey Senozhatsky wrote: > > + uvc_urb->buffer = vmap(uvc_urb->pages, > > + PAGE_ALIGN(stream->urb_size) >> PAGE_SHIFT, > > + VM_DMA_COHERENT, PAGE_KERNEL); > > This is not related to Ricardo's patch, just a side note: > > I think VM_DMA_COHERENT needs to be renamed. I found it a bit confusing > to see DMA_COHERENT mapping being dma_sync-ed. It turned out that the > flag has different meaning. s/renamed/removed/. This is a normal VM_MAP mapping as far as the core vmalloc/vmap code is concerned. VM_DMA_COHERENT is only for internal use in the core DMA code.
Re: [PATCH v3 5/6] media: uvcvideo: Use dma_alloc_noncontiguos API
> +#ifndef CONFIG_DMA_NONCOHERENT
I think you need to drop this ifdef. This code should work just fine
on noncoherent mips and sh platforms.
> + uvc_urb->pages = dma_alloc_noncontiguous(dma_dev, stream->urb_size,
> + &uvc_urb->dma,
> + gfp_flags | __GFP_NOWARN, 0);
> + if (!uvc_urb->pages)
> + return false;
> +
> + uvc_urb->buffer = vmap(uvc_urb->pages,
> +PAGE_ALIGN(stream->urb_size) >> PAGE_SHIFT,
> +VM_DMA_COHERENT, PAGE_KERNEL);
> + if (!uvc_urb->buffer) {
> + dma_free_noncontiguous(dma_dev, stream->urb_size,
> +uvc_urb->pages, uvc_urb->dma);
> + return false;
> + }
> +
> + if (sg_alloc_table_from_pages(&uvc_urb->sgt, uvc_urb->pages,
> + PAGE_ALIGN(stream->urb_size) >> PAGE_SHIFT, 0,
> + stream->urb_size, GFP_KERNEL)) {
> + vunmap(uvc_urb->buffer);
> + dma_free_noncontiguous(dma_dev, stream->urb_size,
> +uvc_urb->pages, uvc_urb->dma);
> + return false;
> + }
> +
> + return true;
> +}
I wonder if we should lift this into a helper. On the one hand I had
proliferating struct scatterlist usage, on the other hand it is all over
the media and drm code anyway, and duplicating this doesn't help anyone.
Possibly including the fallback to the coherent allocating.
Re: [PATCH AUTOSEL 5.9 22/33] vhost scsi: add lun parser helper
On 29/11/20 22:06, Sasha Levin wrote: On Sun, Nov 29, 2020 at 06:34:01PM +0100, Paolo Bonzini wrote: On 29/11/20 05:13, Sasha Levin wrote: Which doesn't seem to be suitable for stable either... Patch 3/5 in Why not? It was sent as a fix to Linus. Dunno, 120 lines of new code? Even if it's okay for an rc, I don't see why it is would be backported to stable releases and release it without any kind of testing. Maybe for 5.9 the chances of breaking Lines of code is not everything. If you think that this needs additional testing then that's fine and we can drop it, but not picking up a fix just because it's 120 lines is not something we'd do. Starting with the first two steps in stable-kernel-rules.rst: Rules on what kind of patches are accepted, and which ones are not, into the "-stable" tree: - It must be obviously correct and tested. - It cannot be bigger than 100 lines, with context. Plus all the testing we have for the stable trees, yes. It goes beyond just compiling at this point. Your very own co-workers (https://cki-project.org/) are pushing hard on this effort around stable kernel testing, and statements like these aren't helping anyone. I am not aware of any public CI being done _at all_ done on vhost-scsi, by CKI or everyone else. So autoselection should be done only on subsystems that have very high coverage in CI. Paolo
[PATCH] audit: replace atomic_add_return()
atomic_inc_return() is a little neater
Signed-off-by: Yejune Deng
---
kernel/audit.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/audit.c b/kernel/audit.c
index e22f22b..1ffc2e0 100644
--- a/kernel/audit.c
+++ b/kernel/audit.c
@@ -1779,7 +1779,7 @@ unsigned int audit_serial(void)
{
static atomic_t serial = ATOMIC_INIT(0);
- return atomic_add_return(1, &serial);
+ return atomic_inc_return(&serial);
}
static inline void audit_get_stamp(struct audit_context *ctx,
--
1.9.1
[PATCH 1/3] dt-bindings: edac: aspeed-sdram-edac: Add ast2400/ast2600 support
Adding Aspeed AST2400 and AST2600 binding for edac driver. Signed-off-by: Troy Lee --- .../devicetree/bindings/edac/aspeed-sdram-edac.txt | 9 ++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff --git a/Documentation/devicetree/bindings/edac/aspeed-sdram-edac.txt b/Documentation/devicetree/bindings/edac/aspeed-sdram-edac.txt index 6a0f3d90d682..8ca9e0a049d8 100644 --- a/Documentation/devicetree/bindings/edac/aspeed-sdram-edac.txt +++ b/Documentation/devicetree/bindings/edac/aspeed-sdram-edac.txt @@ -1,6 +1,6 @@ -Aspeed AST2500 SoC EDAC node +Aspeed BMC SoC EDAC node -The Aspeed AST2500 SoC supports DDR3 and DDR4 memory with and without ECC (error +The Aspeed BMC SoC supports DDR3 and DDR4 memory with and without ECC (error correction check). The memory controller supports SECDED (single bit error correction, double bit @@ -11,7 +11,10 @@ Note, the bootloader must configure ECC mode in the memory controller. Required properties: -- compatible: should be "aspeed,ast2500-sdram-edac" +- compatible: should be one of + - "aspeed,ast2400-sdram-edac" + - "aspeed,ast2500-sdram-edac" + - "aspeed,ast2600-sdram-edac" - reg:sdram controller register set should be <0x1e6e 0x174> - interrupts: should be AVIC interrupt #0 -- 2.17.1
[git pull] habanalabs fixes for 5.10-rc7
Hello Greg, This pull request contains two memory leak bug fixes for 5.10-rc7. Details are in the tag. Thanks, Oded The following changes since commit f0992098cadb4c9c6a00703b66cafe604e178fea: speakup: Reject setting the speakup line discipline outside of speakup (2020-11-30 09:20:32 +0100) are available in the Git repository at: ssh://g...@gitolite.kernel.org/pub/scm/linux/kernel/git/ogabbay/linux.git tags/misc-habanalabs-fixes-2020-11-30 for you to fetch changes up to b7c56bdec7a29c789fec27f84d40f52fbdfa: habanalabs: put devices before driver removal (2020-11-30 10:30:16 +0200) This tag contains two bug fixes for v5.10-rc7: - Memory leak every time a user closes the file-descriptor of the device. The driver didn't always free all the VA range structures it maintains per user. - Memory leak every time the driver was removed. The device structure was not "put" at the device's teardown function in the driver. Ofir Bitton (2): habanalabs: free host huge va_range if not used habanalabs: put devices before driver removal drivers/misc/habanalabs/common/device.c | 16 drivers/misc/habanalabs/common/memory.c | 1 + 2 files changed, 9 insertions(+), 8 deletions(-)
[PATCH 2/3] ARM: dts: aspeed: Add AST2600 edac into common devicetree
Adding Aspeed AST2600 edac node into common devicetree.
Signed-off-by: Troy Lee
---
arch/arm/boot/dts/aspeed-g6.dtsi | 6 ++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/boot/dts/aspeed-g6.dtsi b/arch/arm/boot/dts/aspeed-g6.dtsi
index 97ca743363d7..fb144515f397 100644
--- a/arch/arm/boot/dts/aspeed-g6.dtsi
+++ b/arch/arm/boot/dts/aspeed-g6.dtsi
@@ -69,6 +69,12 @@
always-on;
};
+ edac: sdram@1e6e {
+ compatible = "aspeed,ast2600-sdram-edac", "syscon";
+ reg = <0x1e6e 0x174>;
+ interrupts = ;
+ };
+
ahb {
compatible = "simple-bus";
#address-cells = <1>;
--
2.17.1
Re: [GIT pull] locking/urgent for v5.10-rc6
On Mon, Nov 30, 2020 at 08:56:51AM +0100, Peter Zijlstra wrote:
> The idea was to flip all of arch_cpu_idle() to not enable interrupts.
>
> This is suboptimal for things like x86 where arch_cpu_idle() is
> basically STI;HLT, but x86 isn't likely to actually use this code path
> anyway, given all the various cpuidle drivers it has.
>
> Many of the other archs are now doing things like arm's:
> wfi();raw_local_irq_enable().
>
> Doing that tree-wide interrupt-state flip was something I didn't want to
> do at this late a stage, the chanse of messing that up is just too high.
It looks something like the below, but this needs to soak a bit because
who knows, I might've missed some obscure case ...
And then, after I've also flipped cpuidle, I need to go noinstr annotate
all the actual idle code :-/ (which is going to be a pain due to chasing
function pointers).
---
arch/alpha/kernel/process.c | 1 -
arch/arc/kernel/process.c| 3 +++
arch/arm/kernel/process.c| 1 -
arch/arm/mach-gemini/board-dt.c | 3 ++-
arch/arm64/kernel/process.c | 1 -
arch/c6x/kernel/process.c| 1 +
arch/csky/kernel/process.c | 1 -
arch/h8300/kernel/process.c | 1 +
arch/hexagon/kernel/process.c| 1 -
arch/ia64/kernel/process.c | 1 +
arch/microblaze/kernel/process.c | 1 -
arch/mips/kernel/idle.c | 7 +--
arch/nios2/kernel/process.c | 1 -
arch/openrisc/kernel/process.c | 1 +
arch/parisc/kernel/process.c | 2 --
arch/powerpc/kernel/idle.c | 5 ++---
arch/riscv/kernel/process.c | 1 -
arch/s390/kernel/idle.c | 1 -
arch/sh/kernel/idle.c| 1 +
arch/sparc/kernel/leon_pmc.c | 4
arch/sparc/kernel/process_32.c | 1 -
arch/sparc/kernel/process_64.c | 3 ++-
arch/um/kernel/process.c | 1 -
arch/x86/kernel/process.c| 14 --
arch/xtensa/kernel/process.c | 1 +
kernel/sched/idle.c | 10 +++---
26 files changed, 27 insertions(+), 41 deletions(-)
diff --git a/arch/alpha/kernel/process.c b/arch/alpha/kernel/process.c
index 4c7b0414a3ff..d686e8faec6e 100644
--- a/arch/alpha/kernel/process.c
+++ b/arch/alpha/kernel/process.c
@@ -57,7 +57,6 @@ EXPORT_SYMBOL(pm_power_off);
void arch_cpu_idle(void)
{
wtint(0);
- raw_local_irq_enable();
}
void arch_cpu_idle_dead(void)
diff --git a/arch/arc/kernel/process.c b/arch/arc/kernel/process.c
index 37f724ad5e39..1d0832b28d09 100644
--- a/arch/arc/kernel/process.c
+++ b/arch/arc/kernel/process.c
@@ -114,6 +114,8 @@ void arch_cpu_idle(void)
"sleep %0 \n"
:
:"I"(arg)); /* can't be "r" has to be embedded const */
+
+ raw_local_irq_disable();
}
#else /* ARC700 */
@@ -122,6 +124,7 @@ void arch_cpu_idle(void)
{
/* sleep, but enable both set E1/E2 (levels of interrutps) before
committing */
__asm__ __volatile__("sleep 0x3 \n");
+ raw_local_irq_disable();
}
#endif
diff --git a/arch/arm/kernel/process.c b/arch/arm/kernel/process.c
index 9f199b1e8383..f9c97caa52d1 100644
--- a/arch/arm/kernel/process.c
+++ b/arch/arm/kernel/process.c
@@ -71,7 +71,6 @@ void arch_cpu_idle(void)
arm_pm_idle();
else
cpu_do_idle();
- raw_local_irq_enable();
}
void arch_cpu_idle_prepare(void)
diff --git a/arch/arm/mach-gemini/board-dt.c b/arch/arm/mach-gemini/board-dt.c
index de0afcc8d94a..fbafe7475c02 100644
--- a/arch/arm/mach-gemini/board-dt.c
+++ b/arch/arm/mach-gemini/board-dt.c
@@ -42,8 +42,9 @@ static void gemini_idle(void)
*/
/* FIXME: Enabling interrupts here is racy! */
- local_irq_enable();
+ raw_local_irq_enable();
cpu_do_idle();
+ raw_local_irq_disable();
}
static void __init gemini_init_machine(void)
diff --git a/arch/arm64/kernel/process.c b/arch/arm64/kernel/process.c
index 7697a4b48b7c..07f551879dc5 100644
--- a/arch/arm64/kernel/process.c
+++ b/arch/arm64/kernel/process.c
@@ -126,7 +126,6 @@ void arch_cpu_idle(void)
* tricks
*/
cpu_do_idle();
- raw_local_irq_enable();
}
#ifdef CONFIG_HOTPLUG_CPU
diff --git a/arch/c6x/kernel/process.c b/arch/c6x/kernel/process.c
index 9f4fd6a40a10..9e638155ca76 100644
--- a/arch/c6x/kernel/process.c
+++ b/arch/c6x/kernel/process.c
@@ -45,6 +45,7 @@ void arch_cpu_idle(void)
" mvc .s2 %0,CSR\n"
"|| idle\n"
: "=b"(tmp));
+ raw_local_irq_disable();
}
static void halt_loop(void)
diff --git a/arch/csky/kernel/process.c b/arch/csky/kernel/process.c
index 69af6bc87e64..bae792dca7a3 100644
--- a/arch/csky/kernel/process.c
+++ b/arch/csky/kernel/process.c
@@ -102,6 +102,5 @@ void arch_cpu_idle(void)
#ifdef CONFIG_CPU_PM_STOP
asm volatile("stop\n");
#endif
- raw_local_irq_enable();
}
#endif
diff --git a/arch/h8300/kernel/process.c b/arch/h8300/kernel/process.c
index bc136
Re: [PATCH v10 00/19] Introduce memory interconnect for NVIDIA Tegra SoCs
On Mon, Nov 30, 2020 at 05:44:39PM +0900, Chanwoo Choi wrote: > Hi Dmitry, > > The v5.10-rc6 was released from linus git tree. > Generally, I will send the pull-quest about devfreq to linux-pm.git maintainer > after releasing the v5.1-rc7 for the integration test on linux-pm.git. > > The icc patches in this patch have not yet merged. If these patches > are not merged before v5.10-rc7, Maybe, I'll apply the devfreq patches > for v5.12-rc1. None of the patches here are going to be merged to Linus' in the current cycle. They will only go to the next so if there is dependency, everything will be broken and non-bisectable. However no such dependencies or merging requirements were mention in the cover letter. Best regards, Krzysztof
[PATCH 3/3] edac: Supporting AST2400 and AST2600 edac driver
Adding AST2400 and AST2600 edac driver support.
Signed-off-by: Troy Lee
---
drivers/edac/Kconfig | 6 +-
drivers/edac/aspeed_edac.c | 114 +
2 files changed, 94 insertions(+), 26 deletions(-)
diff --git a/drivers/edac/Kconfig b/drivers/edac/Kconfig
index fc30f2ef9782..8ea70746d0bf 100644
--- a/drivers/edac/Kconfig
+++ b/drivers/edac/Kconfig
@@ -508,10 +508,10 @@ config EDAC_QCOM
health, you should probably say 'Y' here.
config EDAC_ASPEED
- tristate "Aspeed AST 2500 SoC"
- depends on MACH_ASPEED_G5
+ tristate "Aspeed AST BMC SoC"
+ depends on (MACH_ASPEED_G4 || MACH_ASPEED_G5 || MACH_ASPEED_G6)
help
- Support for error detection and correction on the Aspeed AST 2500 SoC.
+ Support for error detection and correction on the Aspeed AST BMC SoC.
First, ECC must be configured in the bootloader. Then, this driver
will expose error counters via the EDAC kernel framework.
diff --git a/drivers/edac/aspeed_edac.c b/drivers/edac/aspeed_edac.c
index fbec28dc661d..03a3c12f6bf6 100644
--- a/drivers/edac/aspeed_edac.c
+++ b/drivers/edac/aspeed_edac.c
@@ -14,12 +14,11 @@
#include
#include "edac_module.h"
-
#define DRV_NAME "aspeed-edac"
-
#define ASPEED_MCR_PROT0x00 /* protection key register */
#define ASPEED_MCR_CONF0x04 /* configuration register */
+#define ASPEED_MCR_REQ 0x08 /* Graphics Memory Protection register */
#define ASPEED_MCR_INTR_CTRL 0x50 /* interrupt control/status register */
#define ASPEED_MCR_ADDR_UNREC 0x58 /* address of first un-recoverable error */
#define ASPEED_MCR_ADDR_REC0x5c /* address of last recoverable error */
@@ -34,10 +33,8 @@
#define ASPEED_MCR_INTR_CTRL_CNT_UNREC GENMASK(15, 12)
#define ASPEED_MCR_INTR_CTRL_ENABLE (BIT(0) | BIT(1))
-
static struct regmap *aspeed_regmap;
-
static int regmap_reg_write(void *context, unsigned int reg, unsigned int val)
{
void __iomem *regs = (void __iomem *)context;
@@ -53,7 +50,6 @@ static int regmap_reg_write(void *context, unsigned int reg,
unsigned int val)
return 0;
}
-
static int regmap_reg_read(void *context, unsigned int reg, unsigned int *val)
{
void __iomem *regs = (void __iomem *)context;
@@ -63,6 +59,76 @@ static int regmap_reg_read(void *context, unsigned int reg,
unsigned int *val)
return 0;
}
+extern void aspeed_sdmc_disable_mem_protection(u8 req)
+{
+ u32 req_val = 0;
+
+ regmap_read(aspeed_regmap, ASPEED_MCR_REQ, &req_val);
+
+ req_val &= ~BIT(req);
+
+ regmap_write(aspeed_regmap, ASPEED_MCR_REQ, req_val);
+}
+EXPORT_SYMBOL(aspeed_sdmc_disable_mem_protection);
+
+static const u32 ast2400_dram_table[] = {
+ 0x0400, //64MB
+ 0x0800, //128MB
+ 0x1000, //256MB
+ 0x2000, //512MB
+};
+
+static const u32 ast2500_dram_table[] = {
+ 0x0800, //128MB
+ 0x1000, //256MB
+ 0x2000, //512MB
+ 0x4000, //1024MB
+};
+
+static const u32 ast2600_dram_table[] = {
+ 0x1000, //256MB
+ 0x2000, //512MB
+ 0x4000, //1024MB
+ 0x8000, //2048MB
+};
+
+extern u32 aspeed_get_dram_size(void)
+{
+ u32 reg04;
+ u32 size;
+
+ regmap_read(aspeed_regmap, ASPEED_MCR_CONF, ®04);
+
+#if defined(CONFIG_MACH_ASPEED_G6)
+ size = ast2600_dram_table[reg04 & 0x3];
+#elif defined(CONFIG_MACH_ASPEED_G5)
+ size = ast2500_dram_table[reg04 & 0x3];
+#else
+ size = ast2400_dram_table[reg04 & 0x3];
+#endif
+ return size;
+}
+EXPORT_SYMBOL(aspeed_get_dram_size);
+
+static const u32 aspeed_vga_table[] = {
+ 0x80, //8MB
+ 0x100, //16MB
+ 0x200, //32MB
+ 0x400, //64MB
+};
+
+extern u32 aspeed_get_vga_size(void)
+{
+ u32 reg04;
+ u32 size;
+
+ regmap_read(aspeed_regmap, ASPEED_MCR_CONF, ®04);
+
+ size = aspeed_vga_table[((reg04 & 0xC) >> 2)];
+ return size;
+}
+EXPORT_SYMBOL(aspeed_get_vga_size);
+
static bool regmap_is_volatile(struct device *dev, unsigned int reg)
{
switch (reg) {
@@ -209,8 +275,8 @@ static int config_irq(void *ctx, struct platform_device
*pdev)
/* register interrupt handler */
irq = platform_get_irq(pdev, 0);
dev_dbg(&pdev->dev, "got irq %d\n", irq);
- if (irq < 0)
- return irq;
+ if (!irq)
+ return -ENODEV;
rc = devm_request_irq(&pdev->dev, irq, mcr_isr, IRQF_TRIGGER_HIGH,
DRV_NAME, ctx);
@@ -239,7 +305,11 @@ static int init_csrows(struct mem_ctl_info *mci)
int rc;
/* retrieve info about physical memory from device tree */
- np = of_find_node_by_path("/memory");
+#ifdef CONFIG_MACH_ASPEED_G4
+ np = of_find_node_by_path("/memory@4000");
+#else
+ np = of_find_node_by_path("/memory@80
linux-next: Tree for Nov 30
Hi all, Changes since 20201127: The dma-mapping tree lost its build failure. The net-next tree gained a conflict against the net tree. The regmap tree stll had its build failure. The tip tree lost its build failure but gained a conflict against the pci tree. The akpm tree gained conflicts against the arm64 tree. Non-merge commits (relative to Linus' tree): 8436 8043 files changed, 637772 insertions(+), 136172 deletions(-) I have created today's linux-next tree at git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git (patches at http://www.kernel.org/pub/linux/kernel/next/ ). If you are tracking the linux-next tree using git, you should not use "git pull" to do so as that will try to merge the new linux-next release with the old one. You should use "git fetch" and checkout or reset to the new master. You can see which trees have been included by looking in the Next/Trees file in the source. There are also quilt-import.log and merge.log files in the Next directory. Between each merge, the tree was built with a ppc64_defconfig for powerpc, an allmodconfig for x86_64, a multi_v7_defconfig for arm and a native build of tools/perf. After the final fixups (if any), I do an x86_64 modules_install followed by builds for x86_64 allnoconfig, powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig, allyesconfig and pseries_le_defconfig and i386, sparc and sparc64 defconfig and htmldocs. And finally, a simple boot test of the powerpc pseries_le_defconfig kernel in qemu (with and without kvm enabled). Below is a summary of the state of the merge. I am currently merging 327 trees (counting Linus' and 85 trees of bug fix patches pending for the current merge release). Stats about the size of the tree over time can be seen at http://neuling.org/linux-next-size.html . Status of my local build tests will be at http://kisskb.ellerman.id.au/linux-next . If maintainers want to give advice about cross compilers/configs that work, we are always open to add more builds. Thanks to Randy Dunlap for doing many randconfig builds. And to Paul Gortmaker for triage and bug fixes. -- Cheers, Stephen Rothwell $ git checkout master $ git reset --hard stable Merging origin/master (f91a3aa6bce4 Merge tag 'locking-urgent-2020-11-29' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip) Merging fixes/fixes (168af485621a powerpc: fix the allyesconfig build) Merging kbuild-current/fixes (d1889589a4f5 builddeb: Fix rootless build in setuid/setgid directory) Merging arc-current/for-curr (f737561c7096 ARC: stack unwinding: reorganize how initial register state setup) Merging arm-current/fixes (9fa2e7af3d53 ARM: 9019/1: kprobes: Avoid fortify_panic() when copying optprobe template) Merging arm64-fixes/for-next/fixes (ff1712f953e2 arm64: pgtable: Ensure dirty bit is preserved across pte_wrprotect()) Merging arm-soc-fixes/arm/fixes (ae597565d13f Merge tag 'optee-valid-memory-type-for-v5.11' of git://git.linaro.org/people/jens.wiklander/linux-tee into arm/fixes) Merging drivers-memory-fixes/fixes (3650b228f83a Linux 5.10-rc1) Merging m68k-current/for-linus (50c5feeea0af ide/macide: Convert Mac IDE driver to platform driver) Merging powerpc-fixes/fixes (b6b79dd53082 powerpc/64s: Fix allnoconfig build since uaccess flush) Merging s390-fixes/fixes (1179f170b6f0 s390: fix fpu restore in entry.S) Merging sparc/master (0a95a6d1a4cd sparc: use for_each_child_of_node() macro) Merging fscrypt-current/for-stable (d19d8d345eec fscrypt: fix inline encryption not used on new files) Merging net/master (4d521943f76b dt-bindings: net: correct interrupt flags in examples) Merging bpf/master (9a44bc9449cf bpf: Add MAINTAINERS entry for BPF LSM) Merging ipsec/master (48f486e13ffd net: xfrm: fix memory leak in xfrm_user_policy()) Merging netfilter/master (4d521943f76b dt-bindings: net: correct interrupt flags in examples) Merging ipvs/master (c0700dfa2cae netfilter: nf_tables: avoid false-postive lockdep splat) Merging wireless-drivers/master (fe56d05ee6c8 iwlwifi: mvm: fix kernel panic in case of assert during CSA) Merging mac80211/master (849920c70339 devlink: Add missing genlmsg_cancel() in devlink_nl_sb_port_pool_fill()) Merging rdma-fixes/for-rc (17475e104dcb RDMA/hns: Bugfix for memory window mtpt configuration) Merging sound-current/for-linus (aeedad250499 ALSA: hda/realtek: Add mute LED quirk to yet another HP x360 model) Merging sound-asoc-fixes/for-linus (356c199d0b72 Merge remote-tracking branch 'asoc/for-5.10' into asoc-linus) Merging regmap-fixes/for-linus (e6e9354b5830 regmap: Remove duplicate `type` field from regmap `regcache_sync` trace event) Merging regulator-fixes/for-linus (34c5aa2666db regulator: Kconfig: Fix REGULATOR_QCOM_RPMH dependencies to avoid build error) Merging spi-fixes/for-linus (893ff790cf6a Merge remote-tracking branch 'spi/for-5.10' into spi-linus) Merging pci-current/for-linus (cce14622a703 PCI: Add
WARNING in sk_stream_kill_queues (5)
Hello,
syzbot found the following issue on:
HEAD commit:6147c83f Add linux-next specific files for 20201126
git tree: linux-next
console output: https://syzkaller.appspot.com/x/log.txt?x=117c967950
kernel config: https://syzkaller.appspot.com/x/.config?x=9b91566da897c24f
dashboard link: https://syzkaller.appspot.com/bug?extid=7b99aafdcc2eedea6178
compiler: gcc (GCC) 10.1.0-syz 20200507
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=103bf74350
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=167c60c950
The issue was bisected to:
commit 145cd60fb481328faafba76842aa0fd242e2b163
Author: Alexander Potapenko
Date: Tue Nov 24 05:38:44 2020 +
mm, kfence: insert KFENCE hooks for SLUB
bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=13abe5b350
final oops: https://syzkaller.appspot.com/x/report.txt?x=106be5b350
console output: https://syzkaller.appspot.com/x/log.txt?x=17abe5b350
IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+7b99aafdcc2eedea6...@syzkaller.appspotmail.com
Fixes: 145cd60fb481 ("mm, kfence: insert KFENCE hooks for SLUB")
[ cut here ]
WARNING: CPU: 0 PID: 11307 at net/core/stream.c:207
sk_stream_kill_queues+0x3c3/0x530 net/core/stream.c:207
Modules linked in:
CPU: 0 PID: 11307 Comm: syz-executor673 Not tainted
5.10.0-rc5-next-20201126-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google
01/01/2011
RIP: 0010:sk_stream_kill_queues+0x3c3/0x530 net/core/stream.c:207
Code: 00 00 00 fc ff df 48 c1 ea 03 0f b6 04 02 84 c0 74 08 3c 03 0f 8e 63 01
00 00 8b ab 20 02 00 00 e9 60 ff ff ff e8 ad 24 7b fa <0f> 0b eb 97 e8 a4 24 7b
fa 0f 0b eb a0 e8 9b 24 7b fa 0f 0b e9 a5
RSP: 0018:c9000979f978 EFLAGS: 00010293
RAX: RBX: fe80 RCX: 86f5877a
RDX: 88801ebb5040 RSI: 86f587e3 RDI: 0005
RBP: 0180 R08: 0001 R09: 8ebd9817
R10: R11: 0001 R12: 8880182f3ce0
R13: 8fb178c0 R14: 8880182f3ae8 R15: 8880182f3c70
FS: () GS:8880b9e0() knlGS:
CS: 0010 DS: ES: CR0: 80050033
CR2: 004c7cd8 CR3: 0b08e000 CR4: 001506f0
DR0: DR1: DR2:
DR3: DR6: fffe0ff0 DR7: 0400
Call Trace:
inet_csk_destroy_sock+0x1a5/0x490 net/ipv4/inet_connection_sock.c:885
__tcp_close+0xd3e/0x1170 net/ipv4/tcp.c:2585
tcp_close+0x29/0xc0 net/ipv4/tcp.c:2597
inet_release+0x12e/0x280 net/ipv4/af_inet.c:431
__sock_release+0xcd/0x280 net/socket.c:596
sock_close+0x18/0x20 net/socket.c:1255
__fput+0x283/0x920 fs/file_table.c:280
task_work_run+0xdd/0x190 kernel/task_work.c:140
exit_task_work include/linux/task_work.h:30 [inline]
do_exit+0xb89/0x29e0 kernel/exit.c:823
do_group_exit+0x125/0x310 kernel/exit.c:920
get_signal+0x3ec/0x2010 kernel/signal.c:2770
arch_do_signal_or_restart+0x2a8/0x1eb0 arch/x86/kernel/signal.c:811
handle_signal_work kernel/entry/common.c:144 [inline]
exit_to_user_mode_loop kernel/entry/common.c:168 [inline]
exit_to_user_mode_prepare+0x124/0x200 kernel/entry/common.c:198
syscall_exit_to_user_mode+0x36/0x260 kernel/entry/common.c:275
entry_SYSCALL_64_after_hwframe+0x44/0xa9
RIP: 0033:0x44ea59
Code: Unable to access opcode bytes at RIP 0x44ea2f.
RSP: 002b:7fd1200f3d98 EFLAGS: 0246 ORIG_RAX: 0001
RAX: 00012255 RBX: 006e6a18 RCX: 0044ea59
RDX: 000101bd RSI: 21c0 RDI: 0003
RBP: 006e6a10 R08: R09:
R10: R11: 0246 R12: 006e6a1c
R13: 3030303030303030 R14: 3030303030303d65 R15: 2b74d0dd4a6f722c
---
This report is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkal...@googlegroups.com.
syzbot will keep track of this issue. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
For information about bisection process see: https://goo.gl/tpsmEJ#bisection
syzbot can test patches for this issue, for details see:
https://goo.gl/tpsmEJ#testing-patches
KASAN: use-after-free Write in kernfs_path_from_node_locked
Hello, syzbot found the following issue on: HEAD commit:6174f052 Add linux-next specific files for 20201127 git tree: linux-next console output: https://syzkaller.appspot.com/x/log.txt?x=1225207350 kernel config: https://syzkaller.appspot.com/x/.config?x=79c69cf2521bef9c dashboard link: https://syzkaller.appspot.com/bug?extid=19e6dd9943972fa1c58a compiler: gcc (GCC) 10.1.0-syz 20200507 syz repro: https://syzkaller.appspot.com/x/repro.syz?x=12c3351d50 C reproducer: https://syzkaller.appspot.com/x/repro.c?x=14c2880950 IMPORTANT: if you fix the issue, please add the following tag to the commit: Reported-by: syzbot+19e6dd9943972fa1c...@syzkaller.appspotmail.com == BUG: KASAN: use-after-free in strlcpy include/linux/string.h:355 [inline] BUG: KASAN: use-after-free in kernfs_path_from_node_locked+0x9b3/0xc80 fs/kernfs/dir.c:138 Write of size 1 at addr 8880235cd800 by task systemd-rfkill/8530 CPU: 1 PID: 8530 Comm: systemd-rfkill Not tainted 5.10.0-rc5-next-20201127-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:79 [inline] dump_stack+0x107/0x163 lib/dump_stack.c:120 print_address_description.constprop.0.cold+0x5b/0x2f8 mm/kasan/report.c:230 __kasan_report mm/kasan/report.c:396 [inline] kasan_report.cold+0x79/0xd5 mm/kasan/report.c:413 check_memory_region_inline mm/kasan/generic.c:180 [inline] check_memory_region+0x13d/0x180 mm/kasan/generic.c:186 memcpy+0x39/0x60 mm/kasan/shadow.c:66 strlcpy include/linux/string.h:355 [inline] kernfs_path_from_node_locked+0x9b3/0xc80 fs/kernfs/dir.c:138 kernfs_path_from_node+0x3a/0x60 fs/kernfs/dir.c:217 kernfs_path include/linux/kernfs.h:542 [inline] cgroup_path include/linux/cgroup.h:661 [inline] get_mm_memcg_path+0xb2/0xf0 mm/mmap_lock.c:130 __mmap_lock_do_trace_start_locking+0x25/0x2d0 mm/mmap_lock.c:172 __mmap_lock_trace_start_locking include/linux/mmap_lock.h:29 [inline] mmap_read_trylock include/linux/mmap_lock.h:135 [inline] do_user_addr_fault+0x638/0xc50 arch/x86/mm/fault.c:1339 handle_page_fault arch/x86/mm/fault.c:1455 [inline] exc_page_fault+0x9e/0x180 arch/x86/mm/fault.c:1511 asm_exc_page_fault+0x1e/0x30 arch/x86/include/asm/idtentry.h:580 RIP: 0033:0x7f42776d4798 Code: Unable to access opcode bytes at RIP 0x7f42776d476e. RSP: 002b:7fff34baaf68 EFLAGS: 00010202 RAX: 7f42776d4798 RBX: 7f4278d7d9e0 RCX: RDX: RSI: RDI: 7f4277918088 RBP: 7fff34bab070 R08: R09: 7f4278723808 R10: 7f4277912000 R11: 0012 R12: 7f4277910a50 R13: 7fff34baafb0 R14: 7f4278d86040 R15: Allocated by task 9024: kasan_save_stack+0x1b/0x40 mm/kasan/common.c:39 kasan_set_track mm/kasan/common.c:47 [inline] set_alloc_info mm/kasan/common.c:405 [inline] kasan_kmalloc mm/kasan/common.c:436 [inline] kasan_kmalloc.constprop.0+0xa0/0xd0 mm/kasan/common.c:408 kmalloc include/linux/slab.h:552 [inline] trace_mmap_lock_reg+0x196/0x550 mm/mmap_lock.c:58 tracepoint_add_func+0x304/0x990 kernel/tracepoint.c:257 tracepoint_probe_register_prio kernel/tracepoint.c:342 [inline] tracepoint_probe_register+0x9c/0xe0 kernel/tracepoint.c:362 trace_event_reg+0x28f/0x350 kernel/trace/trace_events.c:305 perf_trace_event_reg kernel/trace/trace_event_perf.c:129 [inline] perf_trace_event_init+0x549/0xa20 kernel/trace/trace_event_perf.c:204 perf_trace_init+0x176/0x240 kernel/trace/trace_event_perf.c:228 perf_tp_event_init+0xa2/0x120 kernel/events/core.c:9590 perf_try_init_event+0x12a/0x560 kernel/events/core.c:11058 perf_init_event kernel/events/core.c:0 [inline] perf_event_alloc.part.0+0xe3b/0x38e0 kernel/events/core.c:11388 perf_event_alloc kernel/events/core.c:11767 [inline] __do_sys_perf_event_open+0x72c/0x2cb0 kernel/events/core.c:11883 do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46 entry_SYSCALL_64_after_hwframe+0x44/0xa9 Freed by task 9024: kasan_save_stack+0x1b/0x40 mm/kasan/common.c:39 kasan_set_track+0x1c/0x30 mm/kasan/common.c:47 kasan_set_free_info+0x20/0x30 mm/kasan/generic.c:358 kasan_slab_free.part.0+0xe1/0x110 mm/kasan/common.c:366 kasan_slab_free include/linux/kasan.h:187 [inline] slab_free_hook mm/slub.c:1548 [inline] slab_free_freelist_hook+0x82/0x1d0 mm/slub.c:1586 slab_free mm/slub.c:3157 [inline] kfree+0xe5/0x5c0 mm/slub.c:4156 trace_mmap_lock_unreg+0xba/0x160 mm/mmap_lock.c:94 tracepoint_remove_func kernel/tracepoint.c:306 [inline] tracepoint_probe_unregister+0x5b6/0x890 kernel/tracepoint.c:382 trace_event_reg+0x181/0x350 kernel/trace/trace_events.c:309 perf_trace_event_unreg.isra.0+0xac/0x250 kernel/trace/trace_event_perf.c:162 perf_trace_destroy+0xb5/0xf0 kernel/trace/trace_event_perf.c:243 _free_event+0x2ee/0x1300 kernel/events/core.c:4840 put_event kernel/events/core.c:4934 [inline]
Re: WARNING: filesystem loop5 was created with 512 inodes, the real maximum is 511, mounting anyway
On Mon, Nov 30, 2020 at 5:29 AM Randy Dunlap wrote: > > On 11/27/20 4:32 AM, syzbot wrote: > > Hello, > > > > syzbot found the following issue on: > > > > HEAD commit:418baf2c Linux 5.10-rc5 > > git tree: upstream > > console output: https://syzkaller.appspot.com/x/log.txt?x=171555b950 > > kernel config: https://syzkaller.appspot.com/x/.config?x=b81aff78c272da44 > > dashboard link: https://syzkaller.appspot.com/bug?extid=3fd34060f26e766536ff > > compiler: gcc (GCC) 10.1.0-syz 20200507 > > > > Unfortunately, I don't have any reproducer for this issue yet. > > > > IMPORTANT: if you fix the issue, please add the following tag to the commit: > > Reported-by: syzbot+3fd34060f26e76653...@syzkaller.appspotmail.com > > > > BFS-fs: bfs_fill_super(): loop5 is unclean, continuing > > BFS-fs: bfs_fill_super(): WARNING: filesystem loop5 was created with 512 > > inodes, the real maximum is 511, mounting anyway > > BFS-fs: bfs_fill_super(): Last block not available on loop5: 120 > > BFS-fs: bfs_fill_super(): loop5 is unclean, continuing > > BFS-fs: bfs_fill_super(): WARNING: filesystem loop5 was created with 512 > > inodes, the real maximum is 511, mounting anyway > > BFS-fs: bfs_fill_super(): Last block not available on loop5: 120 > > > > > > --- > > This report is generated by a bot. It may contain errors. > > See https://goo.gl/tpsmEJ for more information about syzbot. > > syzbot engineers can be reached at syzkal...@googlegroups.com. > > > > syzbot will keep track of this issue. See: > > https://goo.gl/tpsmEJ#status for how to communicate with syzbot. > > > > Hi, > Can you provide the BFS image file that is being mounted? > (./file0 I think.) > > -- > ~Randy Hi Randy, I see this bug was reported with a reproducer: https://syzkaller.appspot.com/bug?id=a32ebd5db2f7c957b82cf54b97bdecf367bf0421 I assume it's a dup of this one. If you need the image itself, you can dump it to a file in the C reproducer inside of syz_mount_image before mount call. Thanks
Re: [PATCH v10 00/19] Introduce memory interconnect for NVIDIA Tegra SoCs
On 11/30/20 5:36 PM, Krzysztof Kozlowski wrote: > On Mon, Nov 30, 2020 at 05:44:39PM +0900, Chanwoo Choi wrote: >> Hi Dmitry, >> >> The v5.10-rc6 was released from linus git tree. >> Generally, I will send the pull-quest about devfreq to linux-pm.git >> maintainer >> after releasing the v5.1-rc7 for the integration test on linux-pm.git. >> >> The icc patches in this patch have not yet merged. If these patches >> are not merged before v5.10-rc7, Maybe, I'll apply the devfreq patches >> for v5.12-rc1. > > None of the patches here are going to be merged to Linus' in the current > cycle. They will only go to the next so if there is dependency, > everything will be broken and non-bisectable. > > However no such dependencies or merging requirements were mention in the > cover letter. Thanks for reply. The devfreq patch depends on the icc changes. I'll apply the devfreq patches on next time (v5.12-rc1). Thanks. -- Best Regards, Chanwoo Choi Samsung Electronics
Re: 5.10 regression caused by: "uas: fix sdev->host->dma_dev": many XHCI swiotlb buffer is full / DMAR: Device bounce map failed errors on thunderbolt connected XHCI controller
Hi,
On 11/28/20 6:15 PM, Christoph Hellwig wrote:
> Can you give this one-liner a spin?
>
> diff --git a/drivers/iommu/intel/iommu.c b/drivers/iommu/intel/iommu.c
> index c6622011d4938c..e889111b55c71d 100644
> --- a/drivers/iommu/intel/iommu.c
> +++ b/drivers/iommu/intel/iommu.c
> @@ -4007,6 +4007,7 @@ static const struct dma_map_ops bounce_dma_ops = {
> .alloc_pages= dma_common_alloc_pages,
> .free_pages = dma_common_free_pages,
> .dma_supported = dma_direct_supported,
> + .max_mapping_size = swiotlb_max_mapping_size,
> };
>
> static inline int iommu_domain_cache_init(void)
>
I'm afraid that this does not help.
Also I still find it somewhat wrong that the use of scsi_add_host_with_dma()
in uas.c, which then passed the XHCI controller as dma-dev is causing changes
to the DMA settings of the XHCI controller, impacting *other* USB devices
and these changes also are permanent, they stay around even after unbinding
the uas driver.
This just feels wrong on many levels. If some changes to the XHCI controllers
DMA settings are necessary for better uas performance then these changes
really should be made inside the XHCI driver, so that they always apply and
not have this weirdness going on where binding one USB driver permanently
changes the behavior of the entire USB bus (until rebooted).
Querying the DMA settings of the XHCI controller in the uas driver is fine,
but changing them seems like a big nono to me.
Regards,
Hans
Re: [LKP] Re: [mm/memcg] bd0b230fe1: will-it-scale.per_process_ops -22.7% regression
On Wed 25-11-20 14:24:45, Feng Tang wrote:
[...]
> I think we finally found the trick :), further debugging shows it
> is not related to the alignment inside one cacheline, but the
> adjacency of 2 adjacent cacheliens (2N and 2N+1, one pair of 128 bytes).
>
> For structure mem_cgroup, member 'vmstats_local', 'vmstats_percpu'
> sit in one cacheline, while 'vmstats[]' sits in the next cacheline,
> and when 'adjacent cacheline prefetch" is enabled, if these 2 lines
> sit in one pair (128 btyes), say 2N and 2N+1, then there seems to
> be some kind of false sharing, and if they sit in 2 pairs, say
> 2N-1 and 2N then it's fine.
>
> And with the following patch to relayout these members, the regression
> is restored and event better. while reducing 64 bytes of sizeof
> 'struct mem_cgroup'
>
> parent_commit Waiman's_commit +relayout patch
>
> result187K145K200K
>
> Also, if we disable the hw prefetch feature, the Waiman's commit
> and its parent commit will have no performance difference.
>
> Thanks,
> Feng
>
> >From 2e63af34fa4853b2dd9669867c37a3cf07f7a505 Mon Sep 17 00:00:00 2001
> From: Feng Tang
> Date: Wed, 25 Nov 2020 13:22:21 +0800
> Subject: [PATCH] mm: memcg: relayout structure mem_cgroup to avoid cache
> interfereing
>
> 0day reported one -22.7% regression for will-it-scale page_fault2
> case [1] on a 4 sockets 144 CPU platform, and bisected to it to be
> caused by Waiman's optimization (commit bd0b230fe1) of saving one
> 'struct page_counter' space for 'struct mem_cgroup'.
>
> Initially we thought it was due to the cache alignment change introduced
> by the patch, but further debug shows that it is due to some hot data
> members ('vmstats_local', 'vmstats_percpu', 'vmstats') sit in 2 adjacent
> cacheline (2N and 2N+1 cacheline), and when adjacent cache line prefetch
> is enabled, it triggers an "extended level" of cache false sharing for
> 2 adjacent cache lines.
>
> So exchange the 2 member blocks, while keeping mostly the original
> cache alignment, which can restore and even enhance the performance,
> and save 64 bytes of space for 'struct mem_cgroup' (from 2880 to 2816,
> with 0day's default RHEL-8.3 kernel config)
>
> [1]. https://lore.kernel.org/lkml/20201102091543.GM31092@shao2-debian/
>
> Fixes: bd0b230fe145 ("mm/memcg: unify swap and memsw page counters")
> Reported-by: kernel test robot
> Signed-off-by: Feng Tang
Sorry for a late reply. This is indeed surprising! I was really
expecting page counter to be the culprit. Anyway this rearrangement
looks ok as well. moving_account related stuff is still after padding
which is good because this rare operation shouldn't really interfere
with the rest of the structure. Btw. now you made me look into the
history and I have noticed e81bf9793b18 ("mem_cgroup: make sure
moving_account, move_lock_task and stat_cpu in the same cacheline") so
this is not the first time we are dealing with a regression here.
Linus has already merged the patch but for the record
Acked-by: Michal Hocko
Thanks a lot for pursuing this!
--
Michal Hocko
SUSE Labs
Re: [RFC PATCH v2 3/4] mm,memory_hotplug: Add mhp_supports_memmap_on_memory
On Fri, Nov 27, 2020 at 04:02:53PM +0100, Michal Hocko wrote: > It should also require a tunable (kernel parameter for now but maybe we > will need a more fine grained control later) to enable this explicitly. > Earlier discussions have pointed out that allocating vmemmap from each > section can lead to a sparse memory unsuitable for very large pages. > So I believe this should be an opt in. Yeah, I already had that in mind, just did not get to implement it in this RFC yet as I was more focused on the implementation per se. I thought about a tunable in /sys/device/system/memory/[file], but a kernel command line boot option would also work and for the first implementation would be less for a hassel. > Also is there any reason why this cannot be a preparatory patch for the > actual implementation? It would look more natural that way to me. I guess you are right, will re-order it in a future submission. -- Oscar Salvador SUSE L3
[GIT PULL] vhost,vdpa: bugfixes
The following changes since commit 418baf2c28f3473039f2f7377760bd8f6897ae18: Linux 5.10-rc5 (2020-11-22 15:36:08 -0800) are available in the Git repository at: https://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost.git tags/for_linus for you to fetch changes up to ad89653f79f1882d55d9df76c9b2b94f008c4e27: vhost-vdpa: fix page pinning leakage in error path (rework) (2020-11-25 04:29:07 -0500) vhost,vdpa: fixes A couple of minor fixes. Signed-off-by: Michael S. Tsirkin Mike Christie (1): vhost scsi: fix lun reset completion handling Si-Wei Liu (1): vhost-vdpa: fix page pinning leakage in error path (rework) Stefano Garzarella (1): vringh: fix vringh_iov_push_*() documentation drivers/vhost/scsi.c | 4 ++- drivers/vhost/vdpa.c | 80 ++ drivers/vhost/vringh.c | 6 ++-- 3 files changed, 68 insertions(+), 22 deletions(-)
[PATCH] infiniband: i40iw: replace atomic_add_return()
atomic_inc_return() is a little neater
Signed-off-by: Yejune Deng
---
drivers/infiniband/hw/i40iw/i40iw_cm.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/infiniband/hw/i40iw/i40iw_cm.c
b/drivers/infiniband/hw/i40iw/i40iw_cm.c
index 3053c345..26e92ae 100644
--- a/drivers/infiniband/hw/i40iw/i40iw_cm.c
+++ b/drivers/infiniband/hw/i40iw/i40iw_cm.c
@@ -2426,7 +2426,7 @@ static void i40iw_handle_rst_pkt(struct i40iw_cm_node
*cm_node,
}
break;
case I40IW_CM_STATE_MPAREQ_RCVD:
- atomic_add_return(1, &cm_node->passive_state);
+ atomic_inc_return(&cm_node->passive_state);
break;
case I40IW_CM_STATE_ESTABLISHED:
case I40IW_CM_STATE_SYN_RCVD:
@@ -3020,7 +3020,7 @@ static int i40iw_cm_reject(struct i40iw_cm_node *cm_node,
const void *pdata, u8
i40iw_cleanup_retrans_entry(cm_node);
if (!loopback) {
- passive_state = atomic_add_return(1, &cm_node->passive_state);
+ passive_state = atomic_inc_return(&cm_node->passive_state);
if (passive_state == I40IW_SEND_RESET_EVENT) {
cm_node->state = I40IW_CM_STATE_CLOSED;
i40iw_rem_ref_cm_node(cm_node);
@@ -3678,7 +3678,7 @@ int i40iw_accept(struct iw_cm_id *cm_id, struct
iw_cm_conn_param *conn_param)
return -EINVAL;
}
- passive_state = atomic_add_return(1, &cm_node->passive_state);
+ passive_state = atomic_inc_return(&cm_node->passive_state);
if (passive_state == I40IW_SEND_RESET_EVENT) {
i40iw_rem_ref_cm_node(cm_node);
return -ECONNRESET;
--
1.9.1
[PATCH] clk: renesas: r9a06g032: Drop __packed for portability
The R9A06G032 clock driver uses an array of packed structures to reduce
kernel size. However, this array contains pointers, which are no longer
aligned naturally, and cannot be relocated on PPC64. Hence when
compile-testing this driver on PPC64 with CONFIG_RELOCATABLE=y (e.g.
PowerPC allyesconfig), the following warnings are produced:
WARNING: 136 bad relocations
c0616be3 R_PPC64_UADDR64 .rodata+0x000cf338
c0616bfe R_PPC64_UADDR64 .rodata+0x000cf370
...
Fix this by dropping the __packed attribute from the r9a06g032_clkdesc
definition, trading a small size increase for portability.
This increases the 156-entry clock table by 1 byte per entry, but due to
the compiler generating more efficient code for unpacked accesses, the
net size increase is only 76 bytes (gcc 9.3.0 on arm32).
Reported-by: Stephen Rothwell
Fixes: 4c3d88526eba2143 ("clk: renesas: Renesas R9A06G032 clock driver")
Signed-off-by: Geert Uytterhoeven
---
Please take directly (ppc or clk), as this is a build fix.
https://lore.kernel.org/linux-clk/20201128122819.32187...@canb.auug.org.au/
Compile-tested only due to lack of hardware.
drivers/clk/renesas/r9a06g032-clocks.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/clk/renesas/r9a06g032-clocks.c
b/drivers/clk/renesas/r9a06g032-clocks.c
index d900f6bf53d0b944..892e91b92f2c80f5 100644
--- a/drivers/clk/renesas/r9a06g032-clocks.c
+++ b/drivers/clk/renesas/r9a06g032-clocks.c
@@ -55,7 +55,7 @@ struct r9a06g032_clkdesc {
u16 sel, g1, r1, g2, r2;
} dual;
};
-} __packed;
+};
#define I_GATE(_clk, _rst, _rdy, _midle, _scon, _mirack, _mistat) \
{ .gate = _clk, .reset = _rst, \
--
2.25.1
Re: [PATCH 17/17] realtek: rtw88: pci: Add prototypes for .probe, .remove and .shutdown
On Mon, 30 Nov 2020, Pkshih wrote: > > > > -Original Message- > > From: Lee Jones [mailto:lee.jo...@linaro.org] > > Sent: Friday, November 27, 2020 4:57 PM > > To: Pkshih > > Cc: Tony Chuang; kv...@codeaurora.org; linux-kernel@vger.kernel.org; > > linux-wirel...@vger.kernel.org; > > da...@davemloft.net; net...@vger.kernel.org; k...@kernel.org > > Subject: Re: [PATCH 17/17] realtek: rtw88: pci: Add prototypes for .probe, > > .remove and .shutdown > > > > On Fri, 27 Nov 2020, Pkshih wrote: > > > > > On Fri, 2020-11-27 at 07:38 +, Lee Jones wrote: > > > > On Fri, 27 Nov 2020, Pkshih wrote: > > > > > > > > > > > > > > The subject prefix doesn't need 'realtek:'; use 'rtw88:'. > > > > > > > > > > On Thu, 2020-11-26 at 13:31 +, Lee Jones wrote: > > > > > > Also strip out other duplicates from driver specific headers. > > > > > > > > > > > > Ensure 'main.h' is explicitly included in 'pci.h' since the latter > > > > > > uses some defines from the former. It avoids issues like: > > > > > > > > > > > > from drivers/net/wireless/realtek/rtw88/rtw8822be.c:5: > > > > > > drivers/net/wireless/realtek/rtw88/pci.h:209:28: error: > > > > > > ‘RTK_MAX_TX_QUEUE_NUM’ undeclared here (not in a function); did you > > > > > > mean > > > > > > ‘RTK_MAX_RX_DESC_NUM’? > > > > > > 209 | DECLARE_BITMAP(tx_queued, RTK_MAX_TX_QUEUE_NUM); > > > > > > | ^~~~ > > > > > > > > > > > > Fixes the following W=1 kernel build warning(s): > > > > > > > > > > > > drivers/net/wireless/realtek/rtw88/pci.c:1488:5: warning: no > > > > > > previous > > > > > > prototype for ‘rtw_pci_probe’ [-Wmissing-prototypes] > > > > > > 1488 | int rtw_pci_probe(struct pci_dev *pdev, > > > > > > | ^ > > > > > > drivers/net/wireless/realtek/rtw88/pci.c:1568:6: warning: no > > > > > > previous > > > > > > prototype for ‘rtw_pci_remove’ [-Wmissing-prototypes] > > > > > > 1568 | void rtw_pci_remove(struct pci_dev *pdev) > > > > > > | ^~ > > > > > > drivers/net/wireless/realtek/rtw88/pci.c:1590:6: warning: no > > > > > > previous > > > > > > prototype for ‘rtw_pci_shutdown’ [-Wmissing-prototypes] > > > > > > 1590 | void rtw_pci_shutdown(struct pci_dev *pdev) > > > > > > | ^~~~ > > > > > > > > > > > > Cc: Yan-Hsuan Chuang > > > > > > Cc: Kalle Valo > > > > > > Cc: "David S. Miller" > > > > > > Cc: Jakub Kicinski > > > > > > Cc: linux-wirel...@vger.kernel.org > > > > > > Cc: net...@vger.kernel.org > > > > > > Signed-off-by: Lee Jones > > > > > > --- > > > > > > drivers/net/wireless/realtek/rtw88/pci.h | 8 > > > > > > drivers/net/wireless/realtek/rtw88/rtw8723de.c | 1 + > > > > > > drivers/net/wireless/realtek/rtw88/rtw8723de.h | 4 > > > > > > drivers/net/wireless/realtek/rtw88/rtw8821ce.c | 1 + > > > > > > drivers/net/wireless/realtek/rtw88/rtw8821ce.h | 4 > > > > > > drivers/net/wireless/realtek/rtw88/rtw8822be.c | 1 + > > > > > > drivers/net/wireless/realtek/rtw88/rtw8822be.h | 4 > > > > > > drivers/net/wireless/realtek/rtw88/rtw8822ce.c | 1 + > > > > > > drivers/net/wireless/realtek/rtw88/rtw8822ce.h | 4 > > > > > > 9 files changed, 12 insertions(+), 16 deletions(-) > > > > > > > > > > > > diff --git a/drivers/net/wireless/realtek/rtw88/pci.h > > > > > > b/drivers/net/wireless/realtek/rtw88/pci.h > > > > > > index ca17aa9cf7dc7..cda56919a5f0f 100644 > > > > > > --- a/drivers/net/wireless/realtek/rtw88/pci.h > > > > > > +++ b/drivers/net/wireless/realtek/rtw88/pci.h > > > > > > @@ -5,6 +5,8 @@ > > > > > > #ifndef __RTK_PCI_H_ > > > > > > #define __RTK_PCI_H_ > > > > > > > > > > > > +#include "main.h" > > > > > > + > > > > > > > > > > Please #include "main.h" ahead of "pci.h" in each of rtw8e.c. > > > > > > > > You mean instead of in pci.h? > > > > > > > > Surely that's a hack. > > > > > > > > > > I mean don't include main.h in pci.h, but include both of them in each > > > of rtw8e.c. > > > > > > +#include "main.h" > > > +#include "pci.h" > > > > Yes, that's what I thought you meant. I think that's a hack. > > > > Source files shouldn't rely on the ordering of include files to > > resolve dependencies. In fact, a lot of subsystems require includes to > > be in alphabetical order. > > > > If a source or header file references a resource from a specific > > header file (for instance here pci.h uses defines from main.h) then it > > should explicitly include it. > > > > Can you tell me the technical reason as to why these drivers are > > handled differently please? > > > > No technical reason, but that's our coding convention that needs some > changes now. > Could you point out where kernel or subsystem describes the rules? > Or, point out the subsystem you mentioned above. > Then, I can study and follow the rules for further development. I don't think any subsystem explicitly lists this as a rule. At least not to my knowledge. However you can see the many patches enforcing the rule by doing something like: $ git
Re: [PATCH v1 2/3] drm/tiny: Add driver for ili9341 with parallel bus
Hi,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on linux/master]
[also build test ERROR on drm-intel/for-linux-next drm-exynos/exynos-drm-next
tegra-drm/drm/tegra/for-next drm-tip/drm-tip linus/master v5.10-rc6
next-20201127]
[cannot apply to drm/drm-next]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url:
https://github.com/0day-ci/linux/commits/mdurnev-gmail-com/drm-mipi-dbi-Type-B-bus-support-drm-tiny-MRB2801/20201130-142812
base: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
09162bc32c880a791c6c0668ce0745cf7958f576
config: arm64-randconfig-r024-20201130 (attached as .config)
compiler: aarch64-linux-gcc (GCC) 9.3.0
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
#
https://github.com/0day-ci/linux/commit/5883e05578f8008b00a270e8f4ebe9cb7e06a6b6
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review
mdurnev-gmail-com/drm-mipi-dbi-Type-B-bus-support-drm-tiny-MRB2801/20201130-142812
git checkout 5883e05578f8008b00a270e8f4ebe9cb7e06a6b6
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross
ARCH=arm64
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All errors (new ones prefixed by >>):
drivers/gpu/drm/drm_mipi_dbi.c: In function 'mipi_dbi_gpio_init':
>> drivers/gpu/drm/drm_mipi_dbi.c:1266:6: error: implicit declaration of
>> function 'mipi_dbi_machine_little_endian'
>> [-Werror=implicit-function-declaration]
1266 | if (mipi_dbi_machine_little_endian())
| ^~
cc1: some warnings being treated as errors
vim +/mipi_dbi_machine_little_endian +1266 drivers/gpu/drm/drm_mipi_dbi.c
12265315ac41a3e Mikhail Durnev 2020-11-30 1234
12265315ac41a3e Mikhail Durnev 2020-11-30 1235 /**
12265315ac41a3e Mikhail Durnev 2020-11-30 1236 * mipi_dbi_gpio_init -
Initialize MIPI DBI Type B interface implemented via GPIO
12265315ac41a3e Mikhail Durnev 2020-11-30 1237 * @dbi: MIPI DBI structure to
initialize
12265315ac41a3e Mikhail Durnev 2020-11-30 1238 * @dc: D/C gpio
12265315ac41a3e Mikhail Durnev 2020-11-30 1239 * @wr: W/R gpio
12265315ac41a3e Mikhail Durnev 2020-11-30 1240 * @db: DB gpios
12265315ac41a3e Mikhail Durnev 2020-11-30 1241 * @wr_up_delay: Delay after
setting DB and before changing W/R from low to high
12265315ac41a3e Mikhail Durnev 2020-11-30 1242 * @wr_down_delay: Delay after
changing W/R from low to high
12265315ac41a3e Mikhail Durnev 2020-11-30 1243 *
12265315ac41a3e Mikhail Durnev 2020-11-30 1244 * This function sets
&mipi_dbi->command, enables &mipi_dbi->read_commands for the
12265315ac41a3e Mikhail Durnev 2020-11-30 1245 * usual read commands. It
should be followed by a call to mipi_dbi_dev_init() or
12265315ac41a3e Mikhail Durnev 2020-11-30 1246 * a driver-specific init.
12265315ac41a3e Mikhail Durnev 2020-11-30 1247 *
12265315ac41a3e Mikhail Durnev 2020-11-30 1248 * Returns:
12265315ac41a3e Mikhail Durnev 2020-11-30 1249 * Zero on success, negative
error code on failure.
12265315ac41a3e Mikhail Durnev 2020-11-30 1250 */
12265315ac41a3e Mikhail Durnev 2020-11-30 1251 int mipi_dbi_gpio_init(struct
mipi_dbi *dbi, struct gpio_desc *dc,
12265315ac41a3e Mikhail Durnev 2020-11-30 1252 struct
gpio_desc *wr, struct gpio_descs *db,
12265315ac41a3e Mikhail Durnev 2020-11-30 1253 unsigned
long wr_up_delay, unsigned long wr_down_delay)
12265315ac41a3e Mikhail Durnev 2020-11-30 1254 {
12265315ac41a3e Mikhail Durnev 2020-11-30 1255 dbi->spi = NULL; /*
Type B uses GPIO lines rather than SPI */
12265315ac41a3e Mikhail Durnev 2020-11-30 1256
12265315ac41a3e Mikhail Durnev 2020-11-30 1257 dbi->read_commands =
mipi_dbi_dcs_read_commands;
12265315ac41a3e Mikhail Durnev 2020-11-30 1258 dbi->command =
mipi_dbi_gpio_command;
12265315ac41a3e Mikhail Durnev 2020-11-30 1259
12265315ac41a3e Mikhail Durnev 2020-11-30 1260 dbi->dc = dc;
12265315ac41a3e Mikhail Durnev 2020-11-30 1261 dbi->wr = wr;
12265315ac41a3e Mikhail Durnev 2020-11-30 1262 dbi->db = db;
12265315ac41a3e Mikhail Durnev 2020-11-30 1263 dbi->wr_up_delay =
wr_up_delay;
12265315ac41a3e Mikhail Durnev 2020-11-30 1264 dbi->wr_down_delay =
wr_down_delay;
12265315ac41a3e Mikhail Durnev 2020-11-30 1265
12265315ac41a3e Mikhail Durnev 2020-11-30 @1266 if
(mipi_dbi_machine_little_endian())
12265315ac41a3e Mikhail Durnev 2
RE: [RESEND PATCH V20 3/3] Input: new da7280 haptic driver
> On Mon, Nov 30, 2020 4:55 PM, Dmitry Torokhov wrote: > On Thu, Nov 26, 2020 at 01:07:39AM +0900, Roy Im wrote: > > Adds support for the Dialog DA7280 LRA/ERM Haptic Driver with multiple > > mode and integrated waveform memory and wideband support. > > It communicates via an I2C bus to the device. > > I am looking at the driver and should finish review tomorrow. If you do not > hear from me by Wednesday please poke me > again - I want to get the driver into the upcoming merge window. Thank you! I got it. Kind regards, Roy
[PATCH v2] clk: renesas: r9a06g032: Drop __packed for portability
The R9A06G032 clock driver uses an array of packed structures to reduce
kernel size. However, this array contains pointers, which are no longer
aligned naturally, and cannot be relocated on PPC64. Hence when
compile-testing this driver on PPC64 with CONFIG_RELOCATABLE=y (e.g.
PowerPC allyesconfig), the following warnings are produced:
WARNING: 136 bad relocations
c0616be3 R_PPC64_UADDR64 .rodata+0x000cf338
c0616bfe R_PPC64_UADDR64 .rodata+0x000cf370
...
Fix this by dropping the __packed attribute from the r9a06g032_clkdesc
definition, trading a small size increase for portability.
This increases the 156-entry clock table by 1 byte per entry, but due to
the compiler generating more efficient code for unpacked accesses, the
net size increase is only 76 bytes (gcc 9.3.0 on arm32).
Reported-by: Stephen Rothwell
Fixes: 4c3d88526eba2143 ("clk: renesas: Renesas R9A06G032 clock driver")
Signed-off-by: Geert Uytterhoeven
---
v2:
- Fix authorship.
---
drivers/clk/renesas/r9a06g032-clocks.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/clk/renesas/r9a06g032-clocks.c
b/drivers/clk/renesas/r9a06g032-clocks.c
index d900f6bf53d0b944..892e91b92f2c80f5 100644
--- a/drivers/clk/renesas/r9a06g032-clocks.c
+++ b/drivers/clk/renesas/r9a06g032-clocks.c
@@ -55,7 +55,7 @@ struct r9a06g032_clkdesc {
u16 sel, g1, r1, g2, r2;
} dual;
};
-} __packed;
+};
#define I_GATE(_clk, _rst, _rdy, _midle, _scon, _mirack, _mistat) \
{ .gate = _clk, .reset = _rst, \
--
2.25.1
Re: [PATCH v3] s390/pci: fix CPU address in MSI for directed IRQ
On Mon, 30 Nov 2020 09:30:33 +0100 Niklas Schnelle wrote: > I'm not really familiar, with it but I think this is closely related > to what I asked Bernd Nerz. I fear that if CPUs go away we might already > be in trouble at the firmware/hardware/platform level because the CPU Address > is > "programmed into the device" so to speak. Thus a directed interrupt from > a device may race with anything reordering/removing CPUs even if > CPU addresses of dead CPUs are not reused and the mapping is stable. From your answer, I read that CPU hot-unplug is supported for LPAR. > > Furthermore our floating fallback path will try to send a SIGP > to the target CPU which clearly doesn't work when that is permanently > gone. Either way I think these issues are out of scope for this fix > so I will go ahead and merge this. I agree, it makes on sense to delay this fix. But if CPU hot-unplug is supported, I believe we should react when a CPU is unplugged, that is a target of directed interrupts. My guess is, that in this scenario transient hiccups are unavoidable, and thus should be accepted, but we should make sure that we recover. Regards, Halil
Re: [PATCH] powerpc: fix the allyesconfig build
Hi Stephen,
On Sat, Nov 28, 2020 at 2:28 AM Stephen Rothwell wrote:
> There are 2 drivers that have arrays of packed structures that contain
> pointers that end up at unaligned offsets. These produce warnings in
> the PowerPC allyesconfig build like this:
>
> WARNING: 148 bad relocations
> ce56510b R_PPC64_UADDR64 .rodata+0x01c72378
> ce565126 R_PPC64_UADDR64 .rodata+0x01c723c0
>
> They are not drivers that are used on PowerPC (I assume), so mark them
> to not be built on PPC64 when CONFIG_RELOCATABLE is enabled.
>
> Cc: Geert Uytterhoeven
> Cc: Michael Turquette
> Cc: Stephen Boyd
> Cc: Yisen Zhuang
> Cc: Salil Mehta
> Cc: David S. Miller
> Cc: Jakub Kicinski
> Cc: Nicholas Piggin
> Cc: Daniel Axtens
> Cc: Joel Stanley
> Signed-off-by: Stephen Rothwell
Thanks for your patch!
> --- a/drivers/clk/renesas/Kconfig
> +++ b/drivers/clk/renesas/Kconfig
> @@ -151,6 +151,10 @@ config CLK_R8A779A0
> select CLK_RENESAS_CPG_MSSR
>
> config CLK_R9A06G032
> + # PPC64 RELOCATABLE kernels cannot handle relocations to
> + # unaligned locations that are produced by the array of
> + # packed structures in this driver.
> + depends on !(PPC64 && RELOCATABLE)
> bool "Renesas R9A06G032 clock driver"
> help
> This is a driver for R9A06G032 clocks
I prefer to fix this in the driver instead. The space saving by packing the
structure is minimal.
I've sent a patch
https://lore.kernel.org/r/20201130085743.1656317-1-geert+rene...@glider.be
(when lore is back)
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH] irqchip/alpine-msi: Fix freeing of interrupts on allocation error path
Hello Marc,
Quoting Marc Zyngier (2020-11-29 14:55:25)
> The alpine-msi driver has an interesting allocation error handling,
> where it frees the same interrupts repeatedly. Hilarity follows.
That's interesting indeed...
> This code is probably never executed, but let's fix it nonetheless.
>
> Fixes: e6b78f2c3e14 ("irqchip: Add the Alpine MSIX interrupt controller")
> Cc: Tsahee Zidenberg
> Cc: Antoine Tenart
> Signed-off-by: Marc Zyngier
Reviewed-by: Antoine Tenart
Thanks,
Antoine
> ---
> drivers/irqchip/irq-alpine-msi.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/drivers/irqchip/irq-alpine-msi.c
> b/drivers/irqchip/irq-alpine-msi.c
> index 23a3b877f7f1..ede02dc2bcd0 100644
> --- a/drivers/irqchip/irq-alpine-msi.c
> +++ b/drivers/irqchip/irq-alpine-msi.c
> @@ -165,8 +165,7 @@ static int alpine_msix_middle_domain_alloc(struct
> irq_domain *domain,
> return 0;
>
> err_sgi:
> - while (--i >= 0)
> - irq_domain_free_irqs_parent(domain, virq, i);
> + irq_domain_free_irqs_parent(domain, virq, i - 1);
> alpine_msix_free_sgi(priv, sgi, nr_irqs);
> return err;
> }
> --
> 2.29.2
>
Re: [PATCH] keys: remove trailing semicolon in macro definition
Jarkko Sakkinen wrote: > I'm in-between whether this is worth of merging. The commit message > does not help with that decision too much. It is worth merging. It might cause problems for someone using it in the body of an if-statement, say, if they don't put braces in, but do put a semicolon on the end. I'll add it to my branch. David
Re: [PATCH 8/8] net: ethernet: ibm: ibmvnic: Fix some kernel-doc issues
On Sun, 29 Nov 2020, Andrew Lunn wrote: > On Thu, Nov 26, 2020 at 01:38:53PM +, Lee Jones wrote: > > Fixes the following W=1 kernel build warning(s): > > > > from drivers/net/ethernet/ibm/ibmvnic.c:35: > > inlined from ‘handle_vpd_rsp’ at drivers/net/ethernet/ibm/ibmvnic.c:4124:3: > > drivers/net/ethernet/ibm/ibmvnic.c:1362: warning: Function parameter or > > member 'hdr_data' not described in 'build_hdr_data' > > drivers/net/ethernet/ibm/ibmvnic.c:1362: warning: Excess function > > parameter 'tot_len' description in 'build_hdr_data' > > drivers/net/ethernet/ibm/ibmvnic.c:1423: warning: Function parameter or > > member 'hdr_data' not described in 'create_hdr_descs' > > drivers/net/ethernet/ibm/ibmvnic.c:1423: warning: Excess function > > parameter 'data' description in 'create_hdr_descs' > > drivers/net/ethernet/ibm/ibmvnic.c:1474: warning: Function parameter or > > member 'txbuff' not described in 'build_hdr_descs_arr' > > drivers/net/ethernet/ibm/ibmvnic.c:1474: warning: Excess function > > parameter 'skb' description in 'build_hdr_descs_arr' > > drivers/net/ethernet/ibm/ibmvnic.c:1474: warning: Excess function > > parameter 'subcrq' description in 'build_hdr_descs_arr' > > Hi Lee > > It looks like this should be squashed into the previous patch to this > file. It certainly looks that way. Will fix. -- Lee Jones [李琼斯] Senior Technical Lead - Developer Services Linaro.org │ Open source software for Arm SoCs Follow Linaro: Facebook | Twitter | Blog
Re: [PATCH 1/8] net: ethernet: smsc: smc91x: Demote non-conformant kernel function header
On Sun, 29 Nov 2020, Andrew Lunn wrote:
> On Thu, Nov 26, 2020 at 01:38:46PM +, Lee Jones wrote:
> > Fixes the following W=1 kernel build warning(s):
> >
> > drivers/net/ethernet/smsc/smc91x.c:2200: warning: Function parameter or
> > member 'dev' not described in 'try_toggle_control_gpio'
> > drivers/net/ethernet/smsc/smc91x.c:2200: warning: Function parameter or
> > member 'desc' not described in 'try_toggle_control_gpio'
> > drivers/net/ethernet/smsc/smc91x.c:2200: warning: Function parameter or
> > member 'name' not described in 'try_toggle_control_gpio'
> > drivers/net/ethernet/smsc/smc91x.c:2200: warning: Function parameter or
> > member 'index' not described in 'try_toggle_control_gpio'
> > drivers/net/ethernet/smsc/smc91x.c:2200: warning: Function parameter or
> > member 'value' not described in 'try_toggle_control_gpio'
> > drivers/net/ethernet/smsc/smc91x.c:2200: warning: Function parameter or
> > member 'nsdelay' not described in 'try_toggle_control_gpio'
> >
> > Cc: Nicolas Pitre
> > Cc: "David S. Miller"
> > Cc: Jakub Kicinski
> > Cc: Erik Stahlman
> > Cc: Peter Cammaert
> > Cc: Daris A Nevil
> > Cc: Russell King
> > Cc: net...@vger.kernel.org
> > Signed-off-by: Lee Jones
> > ---
> > drivers/net/ethernet/smsc/smc91x.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/net/ethernet/smsc/smc91x.c
> > b/drivers/net/ethernet/smsc/smc91x.c
> > index 56c36798cb111..3b90dc065ff2d 100644
> > --- a/drivers/net/ethernet/smsc/smc91x.c
> > +++ b/drivers/net/ethernet/smsc/smc91x.c
> > @@ -2191,7 +2191,7 @@ static const struct of_device_id smc91x_match[] = {
> > MODULE_DEVICE_TABLE(of, smc91x_match);
> >
> > #if defined(CONFIG_GPIOLIB)
> > -/**
> > +/*
> > * of_try_set_control_gpio - configure a gpio if it exists
> > * @dev: net device
> > * @desc: where to store the GPIO descriptor, if it exists
>
> Hi Lee
>
> This is the wrong fix. The name of the function in the documentation
> should be corrected. The rest looks correct.
Yes, you're right. Will fix.
--
Lee Jones [李琼斯]
Senior Technical Lead - Developer Services
Linaro.org │ Open source software for Arm SoCs
Follow Linaro: Facebook | Twitter | Blog
Re: [PATCH] vdpa/mlx5: Use random MAC for the vdpa net instance
On Mon, Nov 30, 2020 at 08:27:46AM +0200, Eli Cohen wrote:
> On Sun, Nov 29, 2020 at 03:08:22PM -0500, Michael S. Tsirkin wrote:
> > On Sun, Nov 29, 2020 at 08:43:51AM +0200, Eli Cohen wrote:
> > > We should not try to use the VF MAC address as that is used by the
> > > regular (e.g. mlx5_core) NIC implementation. Instead, use a random
> > > generated MAC address.
> > >
> > > Suggested by: Cindy Lu
> > > Fixes: 1a86b377aa21 ("vdpa/mlx5: Add VDPA driver for supported mlx5
> > > devices")
> > > Signed-off-by: Eli Cohen
> >
> > I didn't realise it's possible to use VF in two ways
> > with and without vdpa.
>
> Using a VF you can create quite a few resources, e.g. send queues
> recieve queues, virtio_net queues etc. So you can possibly create
> several instances of vdpa net devices and nic net devices.
>
> > Could you include a bit more description on the failure
> > mode?
>
> Well, using the MAC address of the nic vport is wrong since that is the
> MAC of the regular NIC implementation of mlx5_core.
Right but ATM it doesn't coexist with vdpa so what's the problem?
> > Is switching to a random mac for such an unusual
> > configuration really justified?
>
> Since I can't use the NIC's MAC address, I have two options:
> 1. To get the MAC address as was chosen by the user administering the
>NIC. This should invoke the set_config callback. Unfortunately this
>is not implemented yet.
>
> 2. Use a random MAC address. This is OK since if (1) is implemented it
>can always override this random configuration.
>
> > It looks like changing a MAC could break some guests,
> > can it not?
> >
>
> No, it will not. The current version of mlx5 VDPA does not allow regular
> NIC driver and VDPA to co-exist. I have patches ready that enable that
> from steering point of view. I will post them here once other patches on
> which they depend will be merged.
>
> https://patchwork.ozlabs.org/project/netdev/patch/20201120230339.651609-12-sae...@nvidia.com/
Could you be more explicit on the following points:
- which configuration is broken ATM (as in, two device have identical
macs? any other issues)?
- why won't device MAC change from guest point of view?
> > > ---
> > > drivers/vdpa/mlx5/net/mlx5_vnet.c | 5 +
> > > 1 file changed, 1 insertion(+), 4 deletions(-)
> > >
> > > diff --git a/drivers/vdpa/mlx5/net/mlx5_vnet.c
> > > b/drivers/vdpa/mlx5/net/mlx5_vnet.c
> > > index 1fa6fcac8299..80d06d958b8b 100644
> > > --- a/drivers/vdpa/mlx5/net/mlx5_vnet.c
> > > +++ b/drivers/vdpa/mlx5/net/mlx5_vnet.c
> > > @@ -1955,10 +1955,7 @@ void *mlx5_vdpa_add_dev(struct mlx5_core_dev *mdev)
> > > if (err)
> > > goto err_mtu;
> > >
> > > - err = mlx5_query_nic_vport_mac_address(mdev, 0, 0, config->mac);
> > > - if (err)
> > > - goto err_mtu;
> > > -
> > > + eth_random_addr(config->mac);
> > > mvdev->vdev.dma_dev = mdev->device;
> > > err = mlx5_vdpa_alloc_resources(&ndev->mvdev);
> > > if (err)
> > > --
> > > 2.26.2
> >
Re: [RFC 1/2] dt-bindings: thermal: sprd: Add virtual thermal documentation
Hi Daniel Thank you for your the new information I have a question trouble to you We should choose which per-core thermal zone as the IPA's input reference temperature in the current kernel version? thank you. On 27/11/2020, Lukasz Luba wrote: > > > On 11/27/20 1:26 PM, Daniel Lezcano wrote: >> >> Hi Lukasz, >> >> On 27/11/2020 10:27, Lukasz Luba wrote: >>> >>> >>> On 11/27/20 8:35 AM, gao.yunxi...@gmail.com wrote: From: "jeson.gao" virtual thermal node definition description in dts file Signed-off-by: jeson.gao --- >> >> [ ... ] >> >>> It's coming back. There were attempts to solve this problem. >>> Javi tried to solved this using hierarchical thermal zones [1]. >>> It was even agreed (IIRC during LPC) but couldn't continue. Then Eduardo >>> was going to continue this (last message at [3]). Unfortunately, >>> development stopped. >>> >>> I also have out-of-tree similar implementation for my Odroid-xu4, >>> which does no have an 'SoC' sensor, but have CPU sensors and needs >>> some aggregation function to get temperature. >>> >>> I can pick up Javi's patches and continue 'hierarchical thermal zones' >>> approach. >>> >>> Javi, Daniel, Rui what do you think? >> >> I already worked on the hierarchical thermal zones and my opinion is >> that fits not really well. >> >> We want to define a new feature because the thermal framework is built >> on the 1:1 relationship between a governor and a thermal zone. >> >> Practically speaking, we want to mitigate two thermal zones from one >> governor, especially here the IPA governor. >> >> The DTPM framework is being implemented to solve that by providing an >> automatic power rebalancing between the power manageable capable devices. >> >> In our case, the IPA would stick on the 'sustainable-power' resulting on >> the aggregation of the two performance domains and set the power limit >> on the parent node. The automatic power rebalancing will ensure maximum >> throughput between the two performance domains instead of capping the >> whole. >> >> > > Make sense. Thank you for sharing valuable opinion. > > Regards, > Lukasz >
Re: [PATCH 5/8] net: ethernet: ibm: ibmvnic: Fix some kernel-doc misdemeanours
On Sun, 29 Nov 2020, Andrew Lunn wrote:
> Hi Lee
>
> > /**
> > * build_hdr_data - creates L2/L3/L4 header data buffer
> > - * @hdr_field - bitfield determining needed headers
> > - * @skb - socket buffer
> > - * @hdr_len - array of header lengths
> > - * @tot_len - total length of data
> > + * @hdr_field: bitfield determining needed headers
> > + * @skb: socket buffer
> > + * @hdr_len: array of header lengths
> > + * @tot_len: total length of data
> > *
> > * Reads hdr_field to determine which headers are needed by firmware.
> > * Builds a buffer containing these headers. Saves individual header
>
> The code is:
>
> static int build_hdr_data(u8 hdr_field, struct sk_buff *skb,
> int *hdr_len, u8 *hdr_data)
> {
>
> What about hdr_data?
>
> > /**
> > * create_hdr_descs - create header and header extension descriptors
> > - * @hdr_field - bitfield determining needed headers
> > - * @data - buffer containing header data
> > - * @len - length of data buffer
> > - * @hdr_len - array of individual header lengths
> > - * @scrq_arr - descriptor array
> > + * @hdr_field: bitfield determining needed headers
> > + * @data: buffer containing header data
> > + * @len: length of data buffer
> > + * @hdr_len: array of individual header lengths
> > + * @scrq_arr: descriptor array
>
> static int create_hdr_descs(u8 hdr_field, u8 *hdr_data, int len, int *hdr_len,
> union sub_crq *scrq_arr)
>
> There is no data parameter.
>
> It looks like you just changes - to :, but did not validate the
> parameters are actually correct.
Right. This is a 'quirk' of my current process.
I build once, then use a script to parse the output, fixing each
issue in the order the compiler presents them. Then, either after
fixing a reasonable collection, or all issues, I re-run the compile
and fix the next batch (if any).
This patch is only fixing the formatting issue(s). As you've seen,
there is a subsequent patch in the series which fixes the disparity.
I can squash them though. No problem.
--
Lee Jones [李琼斯]
Senior Technical Lead - Developer Services
Linaro.org │ Open source software for Arm SoCs
Follow Linaro: Facebook | Twitter | Blog
Loan
-- Are YOU in need of finance this COVID-19 times? You have been pre-approved for a loan. Email i...@acetrakit.com You can also visit our website GoodLuck Please do not repond to this message contact the email above for further assistance Thank you
[PATCH 0/4] Add random IR and AUD encoder controls
Hi, Here we introduce two new v4l2 controls for encoders: * V4L2_CID_MPEG_VIDEO_RANDOM_INTRA_REFRESH_MB * V4L2_CID_MPEG_VIDEO_AU_DELIMITER The patchset also includes implementation in Venus driver. Comments are welcome! regards, Stan Stanimir Varbanov (4): media: v4l2-ctrls: Add random intra-refresh control venus: venc: Add support for intra-refresh modes media: v4l2-ctrls: Add control for AUD generation venus: venc: Add support for AUD NALU control .../media/v4l/ext-ctrls-codec.rst | 11 drivers/media/platform/qcom/venus/core.h | 3 +++ drivers/media/platform/qcom/venus/venc.c | 26 +++ .../media/platform/qcom/venus/venc_ctrls.c| 16 +++- drivers/media/v4l2-core/v4l2-ctrls.c | 3 +++ include/uapi/linux/v4l2-controls.h| 2 ++ 6 files changed, 60 insertions(+), 1 deletion(-) -- 2.17.1
[PATCH 3/4] media: v4l2-ctrls: Add control for AUD generation
Add a control to enable inserting of AUD NALU into encoded
bitstream.
Signed-off-by: Stanimir Varbanov
---
Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst | 5 +
drivers/media/v4l2-core/v4l2-ctrls.c | 2 ++
include/uapi/linux/v4l2-controls.h| 1 +
3 files changed, 8 insertions(+)
diff --git a/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst
b/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst
index 59c5d3da4d95..d0a161add543 100644
--- a/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst
+++ b/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst
@@ -679,6 +679,11 @@ enum v4l2_mpeg_video_frame_skip_mode -
otherwise the decoder expects a single frame in per buffer.
Applicable to the decoder, all codecs.
+``V4L2_CID_MPEG_VIDEO_AU_DELIMITER (boolean)``
+If enabled, AUD (Access Unit Delimiter) NALU will be generated. That
+could be useful to find the start of a frame without having to fully
+parse each NALU. Applicable to the H264 and HEVC encoders.
+
``V4L2_CID_MPEG_VIDEO_H264_VUI_SAR_ENABLE (boolean)``
Enable writing sample aspect ratio in the Video Usability
Information. Applicable to the H264 encoder.
diff --git a/drivers/media/v4l2-core/v4l2-ctrls.c
b/drivers/media/v4l2-core/v4l2-ctrls.c
index 5354547ed777..887fb13974de 100644
--- a/drivers/media/v4l2-core/v4l2-ctrls.c
+++ b/drivers/media/v4l2-core/v4l2-ctrls.c
@@ -875,6 +875,7 @@ const char *v4l2_ctrl_get_name(u32 id)
case V4L2_CID_MPEG_VIDEO_HEADER_MODE: return
"Sequence Header Mode";
case V4L2_CID_MPEG_VIDEO_MAX_REF_PIC: return "Max
Number of Reference Pics";
case V4L2_CID_MPEG_VIDEO_FRAME_SKIP_MODE: return "Frame
Skip Mode";
+ case V4L2_CID_MPEG_VIDEO_AU_DELIMITER: return "Acess
Unit Delimiter";
case V4L2_CID_MPEG_VIDEO_H263_I_FRAME_QP: return "H263
I-Frame QP Value";
case V4L2_CID_MPEG_VIDEO_H263_P_FRAME_QP: return "H263
P-Frame QP Value";
case V4L2_CID_MPEG_VIDEO_H263_B_FRAME_QP: return "H263
B-Frame QP Value";
@@ -1228,6 +1229,7 @@ void v4l2_ctrl_fill(u32 id, const char **name, enum
v4l2_ctrl_type *type,
case V4L2_CID_MPEG_VIDEO_H264_VUI_SAR_ENABLE:
case V4L2_CID_MPEG_VIDEO_MPEG4_QPEL:
case V4L2_CID_MPEG_VIDEO_REPEAT_SEQ_HEADER:
+ case V4L2_CID_MPEG_VIDEO_AU_DELIMITER:
case V4L2_CID_WIDE_DYNAMIC_RANGE:
case V4L2_CID_IMAGE_STABILIZATION:
case V4L2_CID_RDS_RECEPTION:
diff --git a/include/uapi/linux/v4l2-controls.h
b/include/uapi/linux/v4l2-controls.h
index cc767667..18c4f46423bc 100644
--- a/include/uapi/linux/v4l2-controls.h
+++ b/include/uapi/linux/v4l2-controls.h
@@ -422,6 +422,7 @@ enum v4l2_mpeg_video_multi_slice_mode {
#define V4L2_CID_MPEG_VIDEO_MV_V_SEARCH_RANGE (V4L2_CID_MPEG_BASE+228)
#define V4L2_CID_MPEG_VIDEO_FORCE_KEY_FRAME(V4L2_CID_MPEG_BASE+229)
#define V4L2_CID_MPEG_VIDEO_RANDOM_INTRA_REFRESH_MB(V4L2_CID_MPEG_BASE+230)
+#define V4L2_CID_MPEG_VIDEO_AU_DELIMITER (V4L2_CID_MPEG_BASE+231)
/* CIDs for the MPEG-2 Part 2 (H.262) codec */
#define V4L2_CID_MPEG_VIDEO_MPEG2_LEVEL
(V4L2_CID_MPEG_BASE+270)
--
2.17.1
[PATCH 2/4] venus: venc: Add support for intra-refresh modes
Add support for random intra-refresh mode and number of macroblocks.
Signed-off-by: Stanimir Varbanov
---
drivers/media/platform/qcom/venus/core.h | 2 ++
drivers/media/platform/qcom/venus/venc.c | 12
drivers/media/platform/qcom/venus/venc_ctrls.c | 10 +-
3 files changed, 23 insertions(+), 1 deletion(-)
diff --git a/drivers/media/platform/qcom/venus/core.h
b/drivers/media/platform/qcom/venus/core.h
index 3bc129a4f817..52df8b3ea438 100644
--- a/drivers/media/platform/qcom/venus/core.h
+++ b/drivers/media/platform/qcom/venus/core.h
@@ -242,6 +242,8 @@ struct venc_controls {
u32 multi_slice_max_mb;
u32 header_mode;
+ u32 intra_refresh_mode;
+ u32 intra_refresh_mbs;
u32 profile;
u32 level;
diff --git a/drivers/media/platform/qcom/venus/venc.c
b/drivers/media/platform/qcom/venus/venc.c
index 0bf92cc21f3a..71b525099e45 100644
--- a/drivers/media/platform/qcom/venus/venc.c
+++ b/drivers/media/platform/qcom/venus/venc.c
@@ -536,6 +536,7 @@ static int venc_set_properties(struct venus_inst *inst)
struct hfi_idr_period idrp;
struct hfi_quantization quant;
struct hfi_quantization_range quant_range;
+ struct hfi_intra_refresh intra_refresh = {};
u32 ptype, rate_control, bitrate;
int ret;
@@ -684,6 +685,17 @@ static int venc_set_properties(struct venus_inst *inst)
if (ret)
return ret;
+ if (inst->fmt_cap->pixfmt == V4L2_PIX_FMT_H264 ||
+ inst->fmt_cap->pixfmt == V4L2_PIX_FMT_HEVC) {
+ ptype = HFI_PROPERTY_PARAM_VENC_INTRA_REFRESH;
+ intra_refresh.mode = ctr->intra_refresh_mode;
+ intra_refresh.cir_mbs = ctr->intra_refresh_mbs;
+
+ ret = hfi_session_set_property(inst, ptype, &intra_refresh);
+ if (ret)
+ return ret;
+ }
+
ret = venus_helper_set_profile_level(inst, ctr->profile, ctr->level);
if (ret)
return ret;
diff --git a/drivers/media/platform/qcom/venus/venc_ctrls.c
b/drivers/media/platform/qcom/venus/venc_ctrls.c
index 0708b3b89d0c..74b4269e2e9c 100644
--- a/drivers/media/platform/qcom/venus/venc_ctrls.c
+++ b/drivers/media/platform/qcom/venus/venc_ctrls.c
@@ -198,6 +198,10 @@ static int venc_op_s_ctrl(struct v4l2_ctrl *ctrl)
case V4L2_CID_MPEG_VIDEO_FRAME_SKIP_MODE:
ctr->frame_skip_mode = ctrl->val;
break;
+ case V4L2_CID_MPEG_VIDEO_RANDOM_INTRA_REFRESH_MB:
+ ctr->intra_refresh_mbs = ctrl->val;
+ ctr->intra_refresh_mode = HFI_INTRA_REFRESH_RANDOM;
+ break;
default:
return -EINVAL;
}
@@ -213,7 +217,7 @@ int venc_ctrl_init(struct venus_inst *inst)
{
int ret;
- ret = v4l2_ctrl_handler_init(&inst->ctrl_handler, 33);
+ ret = v4l2_ctrl_handler_init(&inst->ctrl_handler, 34);
if (ret)
return ret;
@@ -364,6 +368,10 @@ int venc_ctrl_init(struct venus_inst *inst)
(1 <<
V4L2_MPEG_VIDEO_FRAME_SKIP_MODE_BUF_LIMIT)),
V4L2_MPEG_VIDEO_FRAME_SKIP_MODE_DISABLED);
+ v4l2_ctrl_new_std(&inst->ctrl_handler, &venc_ctrl_ops,
+ V4L2_CID_MPEG_VIDEO_RANDOM_INTRA_REFRESH_MB, 0,
+ ((7680 * 4320) >> 8), 1, 0);
+
ret = inst->ctrl_handler.error;
if (ret)
goto err;
--
2.17.1
[PATCH 4/4] venus: venc: Add support for AUD NALU control
Add support for Access Unit Delimiter control into encoder.
Signed-off-by: Stanimir Varbanov
---
drivers/media/platform/qcom/venus/core.h | 1 +
drivers/media/platform/qcom/venus/venc.c | 14 ++
drivers/media/platform/qcom/venus/venc_ctrls.c | 8 +++-
3 files changed, 22 insertions(+), 1 deletion(-)
diff --git a/drivers/media/platform/qcom/venus/core.h
b/drivers/media/platform/qcom/venus/core.h
index 52df8b3ea438..041d33ad7688 100644
--- a/drivers/media/platform/qcom/venus/core.h
+++ b/drivers/media/platform/qcom/venus/core.h
@@ -244,6 +244,7 @@ struct venc_controls {
u32 header_mode;
u32 intra_refresh_mode;
u32 intra_refresh_mbs;
+ bool aud_enable;
u32 profile;
u32 level;
diff --git a/drivers/media/platform/qcom/venus/venc.c
b/drivers/media/platform/qcom/venus/venc.c
index 71b525099e45..986d33b633db 100644
--- a/drivers/media/platform/qcom/venus/venc.c
+++ b/drivers/media/platform/qcom/venus/venc.c
@@ -696,6 +696,20 @@ static int venc_set_properties(struct venus_inst *inst)
return ret;
}
+ if (inst->fmt_cap->pixfmt == V4L2_PIX_FMT_H264 ||
+ inst->fmt_cap->pixfmt == V4L2_PIX_FMT_HEVC) {
+ struct hfi_enable en = {};
+
+ ptype = HFI_PROPERTY_PARAM_VENC_H264_GENERATE_AUDNAL;
+
+ if (ctr->aud_enable)
+ en.enable = 1;
+
+ ret = hfi_session_set_property(inst, ptype, &en);
+ if (ret)
+ return ret;
+ }
+
ret = venus_helper_set_profile_level(inst, ctr->profile, ctr->level);
if (ret)
return ret;
diff --git a/drivers/media/platform/qcom/venus/venc_ctrls.c
b/drivers/media/platform/qcom/venus/venc_ctrls.c
index 74b4269e2e9c..8d34a5396306 100644
--- a/drivers/media/platform/qcom/venus/venc_ctrls.c
+++ b/drivers/media/platform/qcom/venus/venc_ctrls.c
@@ -202,6 +202,9 @@ static int venc_op_s_ctrl(struct v4l2_ctrl *ctrl)
ctr->intra_refresh_mbs = ctrl->val;
ctr->intra_refresh_mode = HFI_INTRA_REFRESH_RANDOM;
break;
+ case V4L2_CID_MPEG_VIDEO_AU_DELIMITER:
+ ctr->aud_enable = ctrl->val;
+ break;
default:
return -EINVAL;
}
@@ -217,7 +220,7 @@ int venc_ctrl_init(struct venus_inst *inst)
{
int ret;
- ret = v4l2_ctrl_handler_init(&inst->ctrl_handler, 34);
+ ret = v4l2_ctrl_handler_init(&inst->ctrl_handler, 35);
if (ret)
return ret;
@@ -372,6 +375,9 @@ int venc_ctrl_init(struct venus_inst *inst)
V4L2_CID_MPEG_VIDEO_RANDOM_INTRA_REFRESH_MB, 0,
((7680 * 4320) >> 8), 1, 0);
+ v4l2_ctrl_new_std(&inst->ctrl_handler, &venc_ctrl_ops,
+ V4L2_CID_MPEG_VIDEO_AU_DELIMITER, 0, 1, 1, 0);
+
ret = inst->ctrl_handler.error;
if (ret)
goto err;
--
2.17.1
[PATCH v3] Currently checkpatch warns us if there is no 'Signed-off-by' line for the patch.
E.g., running checkpatch on commit 9ac060a708e0 ("leaking_addresses:
Completely remove --version flag") reports this error:
ERROR: Missing Signed-off-by: line(s)
Provide a fix by adding a Signed-off-by line corresponding to the author
of the patch before the patch separator line.
Also, avoid this fix with the Non-standard signature warning, as the
missing sign off is most likely because of typo.
E.g. for commit 8cde5d5f7361 ("bus: ti-sysc: Detect omap4 type timers
for quirk") we get missing sign off as well as bad sign off warnings for:
Siganed-off-by: Tony Lindgren
Here it is probably best to fix the typo with BAD_SIGN_OFF warning and
avoid adding an additional signoff.
Suggested-by: Joe Perches
Signed-off-by: Aditya Srivastava
---
applies over next-20201120 and my last changes
at:https://lore.kernel.org/linux-kernel-mentees/db1195235752685fc85fb52ecb1b1af3f35b5394.ca...@perches.com/T/#u
Changes in v2:
Add space after 'if'
Add check for $patch_separator_linenr to be greater than 0
Changes in v3:
Give MISSING_SIGN_OFF warning irrespective of the value of
$non_standard_signature, add check with fix option instead
Modify commit message accordingly
scripts/checkpatch.pl | 14 --
1 file changed, 12 insertions(+), 2 deletions(-)
diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
index 4a026926139f..3abf34bb9b00 100755
--- a/scripts/checkpatch.pl
+++ b/scripts/checkpatch.pl
@@ -2462,6 +2462,8 @@ sub process {
my $last_blank_line = 0;
my $last_coalesced_string_linenr = -1;
+ my $patch_separator_linenr = 0;
+ my $non_standard_signature = 0;
our @report = ();
our $cnt_lines = 0;
@@ -2813,6 +2815,10 @@ sub process {
if ($line =~ /^---$/) {
$has_patch_separator = 1;
$in_commit_log = 0;
+ # to add missing signed-off-by line before diff(s)
+ if ($patch_separator_linenr == 0) {
+ $patch_separator_linenr = $linenr;
+ }
}
# Check if MAINTAINERS is being updated. If so, there's probably no need to
@@ -2842,6 +2848,7 @@ sub process {
$fixed[$fixlinenr] =~
s/$sign_off/$suggested_signature/;
}
}
+ $non_standard_signature = 1;
}
if (defined $space_before && $space_before ne "") {
if (WARN("BAD_SIGN_OFF",
@@ -7188,8 +7195,11 @@ sub process {
}
if ($is_patch && $has_commit_log && $chk_signoff) {
if ($signoff == 0) {
- ERROR("MISSING_SIGN_OFF",
- "Missing Signed-off-by: line(s)\n");
+ if (ERROR("MISSING_SIGN_OFF",
+ "Missing Signed-off-by: line(s)\n") &&
+ $fix && !$non_standard_signature &&
$patch_separator_linenr > 0) {
+ fix_insert_line($patch_separator_linenr - 1,
"Signed-off-by: $author");
+ }
} elsif ($authorsignoff != 1) {
# authorsignoff values:
# 0 -> missing sign off
--
2.17.1
[PATCH resend] clk: si5351: Wait for bit clear after PLL reset
Documentation states that SI5351_PLL_RESET_B and SI5351_PLL_RESET_A bits
are self clearing bits, so wait until they are cleared before
continuing.
This fixes a case when the clock doesn't come up properly after a PLL
reset. It worked properly when the frequency was below 900MHz, but with
900MHz it only works when we are waiting for the bit to clear.
Signed-off-by: Sascha Hauer
---
I've already sent this in October without any reaction, this is just a
resend with +Cc Stephen Boyd and +Cc linux-kernel@vger.kernel.org
drivers/clk/clk-si5351.c | 13 ++---
1 file changed, 10 insertions(+), 3 deletions(-)
diff --git a/drivers/clk/clk-si5351.c b/drivers/clk/clk-si5351.c
index 1e1702e609cb..57e4597cdf4c 100644
--- a/drivers/clk/clk-si5351.c
+++ b/drivers/clk/clk-si5351.c
@@ -902,6 +902,10 @@ static int _si5351_clkout_set_disable_state(
static void _si5351_clkout_reset_pll(struct si5351_driver_data *drvdata, int
num)
{
u8 val = si5351_reg_read(drvdata, SI5351_CLK0_CTRL + num);
+ u8 mask = val & SI5351_CLK_PLL_SELECT ? SI5351_PLL_RESET_B :
+ SI5351_PLL_RESET_A;
+ unsigned int v;
+ int err;
switch (val & SI5351_CLK_INPUT_MASK) {
case SI5351_CLK_INPUT_XTAL:
@@ -909,9 +913,12 @@ static void _si5351_clkout_reset_pll(struct
si5351_driver_data *drvdata, int num
return; /* pll not used, no need to reset */
}
- si5351_reg_write(drvdata, SI5351_PLL_RESET,
-val & SI5351_CLK_PLL_SELECT ? SI5351_PLL_RESET_B :
- SI5351_PLL_RESET_A);
+ si5351_reg_write(drvdata, SI5351_PLL_RESET, mask);
+
+ err = regmap_read_poll_timeout(drvdata->regmap, SI5351_PLL_RESET, v,
+!(v & mask), 0, 2);
+ if (err < 0)
+ dev_err(&drvdata->client->dev, "Reset bit didn't clear\n");
dev_dbg(&drvdata->client->dev, "%s - %s: pll = %d\n",
__func__, clk_hw_get_name(&drvdata->clkout[num].hw),
--
2.20.1
[PATCH 1/4] media: v4l2-ctrls: Add random intra-refresh control
Add a control to configure number of macroblocks for random
intra-refresh mode.
Signed-off-by: Stanimir Varbanov
---
Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst | 6 ++
drivers/media/v4l2-core/v4l2-ctrls.c | 1 +
include/uapi/linux/v4l2-controls.h| 1 +
3 files changed, 8 insertions(+)
diff --git a/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst
b/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst
index ce728c757eaf..59c5d3da4d95 100644
--- a/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst
+++ b/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst
@@ -1104,6 +1104,12 @@ enum v4l2_mpeg_video_h264_entropy_mode -
macroblocks is refreshed until the cycle completes and starts from
the top of the frame. Applicable to H264, H263 and MPEG4 encoder.
+``V4L2_CID_MPEG_VIDEO_RANDOM_INTRA_REFRESH_MB (integer)``
+Random intra macroblock refresh. This is the number of random
+macroblocks refreshed on every frame. Here the positions of
+macroblocks to be refreshed on every frame is random. Applicable
+to H264 and HEVC encoder.
+
``V4L2_CID_MPEG_VIDEO_FRAME_RC_ENABLE (boolean)``
Frame level rate control enable. If this control is disabled then
the quantization parameter for each frame type is constant and set
diff --git a/drivers/media/v4l2-core/v4l2-ctrls.c
b/drivers/media/v4l2-core/v4l2-ctrls.c
index ad47d00e28d6..5354547ed777 100644
--- a/drivers/media/v4l2-core/v4l2-ctrls.c
+++ b/drivers/media/v4l2-core/v4l2-ctrls.c
@@ -869,6 +869,7 @@ const char *v4l2_ctrl_get_name(u32 id)
case V4L2_CID_MPEG_VIDEO_DECODER_SLICE_INTERFACE: return "Decoder
Slice Interface";
case V4L2_CID_MPEG_VIDEO_DECODER_MPEG4_DEBLOCK_FILTER: return "MPEG4
Loop Filter Enable";
case V4L2_CID_MPEG_VIDEO_CYCLIC_INTRA_REFRESH_MB: return "Number
of Intra Refresh MBs";
+ case V4L2_CID_MPEG_VIDEO_RANDOM_INTRA_REFRESH_MB: return "Number
of Random IR MBs";
case V4L2_CID_MPEG_VIDEO_FRAME_RC_ENABLE: return "Frame
Level Rate Control Enable";
case V4L2_CID_MPEG_VIDEO_MB_RC_ENABLE: return "H264 MB
Level Rate Control";
case V4L2_CID_MPEG_VIDEO_HEADER_MODE: return
"Sequence Header Mode";
diff --git a/include/uapi/linux/v4l2-controls.h
b/include/uapi/linux/v4l2-controls.h
index 7035f4fb182c..cc767667 100644
--- a/include/uapi/linux/v4l2-controls.h
+++ b/include/uapi/linux/v4l2-controls.h
@@ -421,6 +421,7 @@ enum v4l2_mpeg_video_multi_slice_mode {
#define V4L2_CID_MPEG_VIDEO_MV_H_SEARCH_RANGE (V4L2_CID_MPEG_BASE+227)
#define V4L2_CID_MPEG_VIDEO_MV_V_SEARCH_RANGE (V4L2_CID_MPEG_BASE+228)
#define V4L2_CID_MPEG_VIDEO_FORCE_KEY_FRAME(V4L2_CID_MPEG_BASE+229)
+#define V4L2_CID_MPEG_VIDEO_RANDOM_INTRA_REFRESH_MB(V4L2_CID_MPEG_BASE+230)
/* CIDs for the MPEG-2 Part 2 (H.262) codec */
#define V4L2_CID_MPEG_VIDEO_MPEG2_LEVEL
(V4L2_CID_MPEG_BASE+270)
--
2.17.1
Re: [RFC PATCH v2 2/4] mm,memory_hotplug: Allocate memmap from the added memory range
On Fri, Nov 27, 2020 at 04:15:36PM +0100, Michal Hocko wrote: > > Vmemap page tables can map arbitrary memory. > > That means that we can simply use the beginning of each memory section and > > map struct pages there. > > Did you mean each memory block rather than section? Yes, sorry, I did not update that part. > > struct pages which back the allocated space then just need to be treated > > carefully. > > > > Implementation wise we will reuse vmem_altmap infrastructure to override > > the default allocator used by __populate_section_memmap. Once the memmap is > > allocated, we are going to need a way to mark altmap pfns used for the > > allocation. > > If MHP_MEMMAP_ON_MEMORY flag was passed, we will set up the layout of the > > altmap structure in add_memory_resouce(), and then we will call > > mhp_mark_vmemmap_pages() to properly mark those pages. > > > > Online/Offline: > > > > In the memory_block structure, a new field is created in order to > > store the number of vmemmap_pages. > > Is this really needed? We know how many pfns are required for a block of > a specific size, right? > > I have only glanced through the patch so I might be missing something > but I am really wondering why you haven't chosen to use altmap directly > here. Well, this is my bad, I did not update the changelog wrt. to the previous version so it might be confusing. I will make sure to update it for the next submission, but let me explain it here to shed some light. We no longer need to use mhp_mark_vmemap_pages to mark vmemmap pages pages. Prior to online_pages(), the whole range is offline, so no one should be messing with any pages within that range. The initialization of the pages takes places in online_pages(): We have: start_pfn = first_pfn_of_the_range buddy_start_pfn = first_pfn_of_the_range + nr_vmemmap_pages We do have: + if (nr_vmemmap_pages) + move_pfn_range_to_zone(zone, pfn, nr_vmemmap_pages, NULL, + MIGRATE_UNMOVABLE); + move_pfn_range_to_zone(zone, buddy_start_pfn, buddy_nr_pages, NULL, + MIGRATE_ISOLATE); Now, all the range is initialized and marked PageReserved, but we only send to buddy (buddy_start_pfn, end_pfn]. And so, (start_pfn, buddy_start_pfn - 1] reamins PageReserved. And we know that pfn walkers to skip Reserved pages. About the altmap part. Altmap is used in the hot-add phase in add_memory_resource. The thing is, we could avoid adding the memory_block's nr_vmemmap_pages field , but we would have to mark the vmemmap pages as we used to do in previous implementations (see [1]), but I find this way cleaner, and it adds much less code (previous implementions can be see in [2]), and as a starter I find it much better. > It would be also good to describe how does a pfn walker recognize such a > page? Most of them will simply ignore it but e.g. hotplug walker will > need to skip over those because they are not preventing offlining as > they will go away with the memory block together. Wrt. hotplug walker, same as above, we only care to migrate the (buddy_start_pfn, end_pfn], so the first pfn to migrate and isolate is set to buddy_start_pfn. Other pfns walkers should merely skip vmemmap pages because they are Reserved. > Some basic description of testing done would be suitable as well. Well, that is: - Hot-add memory to a specific numa node - Online memory - numactl -H and /proc/zoneinfo reflects the truth and nr_vmemmap_pages are extracted where they have to be - Start a memory stress program and bind it to the numa node we added memory so we make sure it gets exercised - Wait for a while and when node's free pages have decreased considerably, offline memory - Check that memory went offline and check /proc/zoneinfo and numactl -H again - Hot-remove range [1] https://patchwork.kernel.org/project/linux-mm/patch/20201022125835.26396-3-osalva...@suse.de/ [2] https://patchwork.kernel.org/project/linux-mm/cover/20201022125835.26396-1-osalva...@suse.de/ -- Oscar Salvador SUSE L3
[git pull] habanalabs pull request for kernel 5.11-rc1
Hello Greg, This is habanalabs pull request for the merge window of kernel 5.11. It contains many changes, new features, support for new firmware. Details are in the tag. Thanks, Oded The following changes since commit 3473065927a877e0a15c4d4b64f245ccaba24e3f: Merge 5.10-rc6 into char-misc-next (2020-11-30 08:33:06 +0100) are available in the Git repository at: ssh://g...@gitolite.kernel.org/pub/scm/linux/kernel/git/ogabbay/linux.git tags/misc-habanalabs-next-2020-11-30 for you to fetch changes up to f44afb5b5a5d04448da843b2fe872e01669bc317: habanalabs: Add CB IOCTL opcode to retrieve CB information (2020-11-30 10:47:38 +0200) This tag contains habanalabs driver changes for v5.11-rc1: - Add support for ability to perform collective stream sync. This is basically a synchronization between compute and network streams. - Add initialization of NIC QMANs and security configuration. This is a pre-requisite for upstreaming the NIC ETH and RDMA code. - Add option to scrub all internal memory (SRAM and DRAM) when the user closes the file-descriptor - Support new firmware that provide enhanced device security. This includes many changes that basically amounts to moving certain configurations to the firmware and stop reading registers directly and instead receiving the information from the firmware. For example: - Retrieve HBM ECC error information - Retrieve PLL configuration - Configure of internal credits, rate-limitation - Support new firmware that performs the GAUDI device reset instead of the driver. The driver now asks the firmware to do it. - Some changes were done as Pre-requisite for future ASICs support: - Add option to put the device's PCI MMU page tables on the host memory. - Support loading multiple types of firmware. - Adding option to user to inquire about usage counter of Command buffer. - Support taking timestamp of Command Submission when it completes and providing it to the user. - Change aggregate cs counters to atomic and fix the cs counters structure to support addition of new counters in the future - Update email address nad git repo of the driver in MAINTAINERS - Many small bug fixes and improvements, such as: - Refactoring in MMU code to move code from ASIC-dependant files to common code - Minimize driver prints when no errors occur - Using enums, defines instead of hard-coded values - Refactoring of Command Submission flow to make it more readable now that we have multiple types of Command Submissions. Alon Mizrahi (3): habanalabs: firmware returns 64bit argument habanalabs: fetch pll frequency from firmware habanalabs: add ull to PLL masks Guy Nisan (1): habanalabs: add boot errors prints Igor Grinberg (1): habanalabs/gaudi: remove pcie_en strap toggle Moti Haimovski (4): habanalabs: fix MMU print message habanalabs: refactor MMU to support dual residency MMU habanalabs: share a single ctx-mutex between all MMUs habanalabs: fix MMU debugfs operations Oded Gabbay (25): MAINTAINERS: update email, git repo of habanalabs driver habanalabs: change aggregate cs counters to atomic habanalabs: we need CPU queues for hwmon habanalabs: support multiple types of firmwares habanalabs: minimize prints when everything is fine habanalabs: don't init vm module if no MMU habanalabs: remove duplicate check habanalabs/gaudi: add NIC QMAN H/W and registers definitions habanalabs/gaudi: add NIC firmware-related definitions habanalabs/gaudi: add NIC security configuration habanalabs/gaudi: add support for NIC QMANs habanalabs/gaudi: monitor device memory usage habanalabs: make sure cs type is valid in cs_ioctl_signal_wait habanalabs: initialize variable before use habanalabs/gaudi: increase MAX CS to 16K habanalabs: remove duplicate print habanalabs: restore vm_pgoff after mmap habanalabs: move asic property to correct structure habanalabs: print message with correct device habanalabs: print CS type when it is stuck habanalabs: update firmware files habanalabs/gaudi: print ECC type field habanalabs: add missing counter update habanalabs/gaudi: handle reset when f/w is in preboot habanalabs: change messages to debug level Ofir Bitton (26): habanalabs/gaudi: move mmu_prepare to context init habanalabs: sync stream structures refactor habanalabs: add support for multiple SOBs per monitor habanalabs: sync stream refactor functions habanalabs: sync stream collective infrastructure habanalabs/gaudi: Set DMA5 QMAN internal habanalabs: sync stream collective support habanalabs/gaudi: remove unreachable code habanalabs: advanced FW loading habanalabs: fetc
Re: [PATCH v2 4/5] USB: gadget: f_fs: add SuperSpeed Plus support
On Fri, Nov 27, 2020 at 03:05:58PM +0100, Greg Kroah-Hartman wrote:
> From: "taehyun.cho"
>
> Setup the descriptors for SuperSpeed Plus for f_fs. This allows the
> gadget to work properly without crashing at SuperSpeed rates.
>
> Cc: Felipe Balbi
> Cc: stable
> Signed-off-by: taehyun.cho
> Signed-off-by: Will McVicker
> Reviewed-by: Peter Chen
> Signed-off-by: Greg Kroah-Hartman
> ---
> drivers/usb/gadget/function/f_fs.c | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/drivers/usb/gadget/function/f_fs.c
> b/drivers/usb/gadget/function/f_fs.c
> index 046f770a76da..a34a7c96a1ab 100644
> --- a/drivers/usb/gadget/function/f_fs.c
> +++ b/drivers/usb/gadget/function/f_fs.c
> @@ -1327,6 +1327,7 @@ static long ffs_epfile_ioctl(struct file *file,
> unsigned code,
> struct usb_endpoint_descriptor *desc;
>
> switch (epfile->ffs->gadget->speed) {
> + case USB_SPEED_SUPER_PLUS:
> case USB_SPEED_SUPER:
> desc_idx = 2;
> break;
> @@ -3222,6 +3223,10 @@ static int _ffs_func_bind(struct usb_configuration *c,
> func->function.os_desc_n =
> c->cdev->use_os_string ? ffs->interfaces_count : 0;
>
> + if (likely(super)) {
> + func->function.ssp_descriptors =
> + usb_copy_descriptors(func->function.ss_descriptors);
> + }
> /* And we're done */
> ffs_event_add(ffs, FUNCTIONFS_BIND);
> return 0;
> --
Hi Greg,
FWIW I had sent a very similar patch[1] a while back (twice in fact)
but got no response about it. Looks like Taehyun's patch already went
through Google for this, I assume it must be working on their Android
kernels so I've no problem with you or Felipe taking this instead.
Only one difference with my patch though is mine additionally clears the
func->function.ssp_descriptors member to NULL upon ffs_func_unbind() as
otherwise it could lead to a dangling reference in case the function is
re-bound and userspace does not issue SS descriptors the next time.
Realistically I don't think that's possible, except maybe when fuzzing?
[1]
https://patchwork.kernel.org/project/linux-usb/patch/20201027230731.9073-1-ja...@codeaurora.org/
Jack
--
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
[PATCH v3] checkpatch: add fix option for MISSING_SIGN_OFF
Currently checkpatch warns us if there is no 'Signed-off-by' line for
the patch.
E.g., running checkpatch on commit 9ac060a708e0 ("leaking_addresses:
Completely remove --version flag") reports this error:
ERROR: Missing Signed-off-by: line(s)
Provide a fix by adding a Signed-off-by line corresponding to the author
of the patch before the patch separator line.
Also, avoid this fix with the Non-standard signature warning, as the
missing sign off is most likely because of typo.
E.g. for commit 8cde5d5f7361 ("bus: ti-sysc: Detect omap4 type timers
for quirk") we get missing sign off as well as bad sign off warnings for:
Siganed-off-by: Tony Lindgren
Here it is probably best to fix the typo with BAD_SIGN_OFF warning and
avoid adding an additional signoff.
Suggested-by: Joe Perches
Signed-off-by: Aditya Srivastava
---
applies over next-20201120 and my last changes
at:https://lore.kernel.org/linux-kernel-mentees/db1195235752685fc85fb52ecb1b1af3f35b5394.ca...@perches.com/T/#u
Changes in v2:
Add space after 'if'
Add check for $patch_separator_linenr to be greater than 0
Changes in v3:
Give MISSING_SIGN_OFF warning irrespective of the value of
$non_standard_signature, add check with fix option instead
Modify commit message accordingly
scripts/checkpatch.pl | 14 --
1 file changed, 12 insertions(+), 2 deletions(-)
diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
index 4a026926139f..3abf34bb9b00 100755
--- a/scripts/checkpatch.pl
+++ b/scripts/checkpatch.pl
@@ -2462,6 +2462,8 @@ sub process {
my $last_blank_line = 0;
my $last_coalesced_string_linenr = -1;
+ my $patch_separator_linenr = 0;
+ my $non_standard_signature = 0;
our @report = ();
our $cnt_lines = 0;
@@ -2813,6 +2815,10 @@ sub process {
if ($line =~ /^---$/) {
$has_patch_separator = 1;
$in_commit_log = 0;
+ # to add missing signed-off-by line before diff(s)
+ if ($patch_separator_linenr == 0) {
+ $patch_separator_linenr = $linenr;
+ }
}
# Check if MAINTAINERS is being updated. If so, there's probably no need to
@@ -2842,6 +2848,7 @@ sub process {
$fixed[$fixlinenr] =~
s/$sign_off/$suggested_signature/;
}
}
+ $non_standard_signature = 1;
}
if (defined $space_before && $space_before ne "") {
if (WARN("BAD_SIGN_OFF",
@@ -7188,8 +7195,11 @@ sub process {
}
if ($is_patch && $has_commit_log && $chk_signoff) {
if ($signoff == 0) {
- ERROR("MISSING_SIGN_OFF",
- "Missing Signed-off-by: line(s)\n");
+ if (ERROR("MISSING_SIGN_OFF",
+ "Missing Signed-off-by: line(s)\n") &&
+ $fix && !$non_standard_signature &&
$patch_separator_linenr > 0) {
+ fix_insert_line($patch_separator_linenr - 1,
"Signed-off-by: $author");
+ }
} elsif ($authorsignoff != 1) {
# authorsignoff values:
# 0 -> missing sign off
--
2.17.1
Re: [PATCH v4 1/2] ARM: dts: r8a7742-iwg21d-q7-dbcm-ca: Separate out ov5640 nodes
On Thu, Nov 26, 2020 at 3:20 PM Geert Uytterhoeven wrote:
> From: Lad Prabhakar
>
> The camera daughter board can also be connected to 8-bit ov7725 sensors,
> so in preparation for configurable option to choose depending on the
> camera's connected separate out the ov5640 nodes in a dtsi file.
>
> Signed-off-by: Lad Prabhakar
> Reviewed-by: Biju Das
> [geert: describe a single camera in the .dtsi, include multiple times]
> Signed-off-by: Geert Uytterhoeven
Oops, obviously this should have been geert+rene...@glider.be.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
[RFC PATCH v1] scsi: ufs: Remove pre-defined initial VCC voltage values
UFS specficication allows different VCC configurations for UFS devices,
for example,
(1). 2.70V - 3.60V (By default)
(2). 1.70V - 1.95V (Activated if "vcc-supply-1p8" is declared in
device tree)
(3). 2.40V - 2.70V (Supported since UFS 3.x)
With the introduction of UFS 3.x products, an issue is happening that
UFS driver will use wrong "min_uV/max_uV" configuration to toggle VCC
regulator on UFU 3.x products with VCC configuration (3) used.
To solve this issue, we simply remove pre-defined initial VCC voltage
values in UFS driver with below reasons,
1. UFS specifications do not define how to detect the VCC configuration
supported by attached device.
2. Device tree already supports standard regulator properties.
Therefore VCC voltage shall be defined correctly in device tree, and
shall not be changed by UFS driver. What UFS driver needs to do is simply
enabling or disabling the VCC regulator only.
This is a RFC conceptional patch. Please help review this and feel
free to feedback any ideas. Once this concept is accepted, and then
I would post a more completed patch series to fix this issue.
Signed-off-by: Stanley Chu
---
drivers/scsi/ufs/ufshcd-pltfrm.c | 10 +-
1 file changed, 1 insertion(+), 9 deletions(-)
diff --git a/drivers/scsi/ufs/ufshcd-pltfrm.c b/drivers/scsi/ufs/ufshcd-pltfrm.c
index a6f76399b3ae..3965be03c136 100644
--- a/drivers/scsi/ufs/ufshcd-pltfrm.c
+++ b/drivers/scsi/ufs/ufshcd-pltfrm.c
@@ -133,15 +133,7 @@ static int ufshcd_populate_vreg(struct device *dev, const
char *name,
vreg->max_uA = 0;
}
- if (!strcmp(name, "vcc")) {
- if (of_property_read_bool(np, "vcc-supply-1p8")) {
- vreg->min_uV = UFS_VREG_VCC_1P8_MIN_UV;
- vreg->max_uV = UFS_VREG_VCC_1P8_MAX_UV;
- } else {
- vreg->min_uV = UFS_VREG_VCC_MIN_UV;
- vreg->max_uV = UFS_VREG_VCC_MAX_UV;
- }
- } else if (!strcmp(name, "vccq")) {
+ if (!strcmp(name, "vccq")) {
vreg->min_uV = UFS_VREG_VCCQ_MIN_UV;
vreg->max_uV = UFS_VREG_VCCQ_MAX_UV;
} else if (!strcmp(name, "vccq2")) {
--
2.18.0
Re: [PATCH] scsi: qla2xxx: remove trailing semicolon in macro definition
Hi Tom,
On Fri, Nov 27, 2020 at 10:27:41AM -0800, t...@redhat.com wrote:
> From: Tom Rix
>
> The macro use will already have a semicolon.
>
> Signed-off-by: Tom Rix
Reviewed-by: Daniel Wagner
> ---
> drivers/scsi/qla2xxx/qla_def.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/scsi/qla2xxx/qla_def.h b/drivers/scsi/qla2xxx/qla_def.h
> index ed9b10f8537d..86d249551b2d 100644
> --- a/drivers/scsi/qla2xxx/qla_def.h
> +++ b/drivers/scsi/qla2xxx/qla_def.h
> @@ -4970,7 +4970,7 @@ struct secure_flash_update_block_pk {
> } while (0)
>
> #define QLA_QPAIR_MARK_NOT_BUSY(__qpair) \
> - atomic_dec(&__qpair->ref_count);\
> + atomic_dec(&__qpair->ref_count) \
Nitpick, please insert an additional tab after the remove so that the
backlashes align again.
Thanks,
Daniel
Re: [PATCH/RFC] dt-bindings: pci: rcar-pci-ep: Document missing interrupts property
On Thu, Nov 26, 2020 at 3:20 PM Geert Uytterhoeven wrote:
> The R-Car PCIe controller does not use interrupts when configured
> for endpoint mode, hence the bindings do not document the interrupt
> property. However, all DTS files provide interrupts properties, and
> thus fail to validate.
>
> Fix this by documenting the interrupts property.
>
> Fixes: 5be478f9c24fbdf8 ("dt-bindings: Another round of adding missing
> 'additionalProperties'")
> Fixes: 4c0f80920923f103 ("dt-bindings: PCI: rcar: Add bindings for R-Car PCIe
> endpoint controller")
> Signed-off-by: Geert Uytterhoeven
Oops, this should have been geert+rene...@glider.be.
> ---
> Alternatively, the interrupts properties should be removed from the
> corresponding device nodes in the DTS files. Obviously they should be
> retained in the device nodes representing PCIe controllers configured in
> host mode, which describe the same hardware...
Anyway, waiting for your comments ;-)
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH 1/1] efi/efi_test: read RuntimeServicesSupported
On 11/30/20 9:16 AM, ivanhu wrote:
Hi Heinrich,
Thanks for the patch.
It looks good to me, but I noticed that the runtime_supported_mask was
introduced after 5.7-rc1.
Maybe we should add the kernel version checking for the old kernels.
This is a kernel patch. Why should we check the kernel version in the
kernel code?
As patches may be back-ported we should not make any assumptions in fwts
based on the kernel version. If the ioctl() call fails with errno =
ENOTTY, we know that the kernel does not implement the ioctl call and we
have to assume that all runtime services are available.
Best regards
Heinrich
Cheers,
Ivan
On 11/28/20 3:20 AM, Heinrich Schuchardt wrote:
Since the UEFI 2.8A specification the UEFI enabled firmware provides a
configuration table EFI_RT_PROPERTIES_TABLE which indicates which runtime
services are enabled. The EFI stub reads this table and saves the value of
the field RuntimeServicesSupported internally.
The Firmware Test Suite requires the value to determine if UEFI runtime
services are correctly implemented.
With this patch an IOCTL call is provided to read the value of the field
RuntimeServicesSupported, e.g.
#define EFI_RUNTIME_GET_SUPPORTED_MASK \
_IOR('p', 0x0C, unsigned int)
unsigned int mask;
fd = open("/dev/efi_test", O_RDWR);
ret = ioctl(fd, EFI_RUNTIME_GET_SUPPORTED_MASK, &mask);
Signed-off-by: Heinrich Schuchardt
---
drivers/firmware/efi/test/efi_test.c | 16
drivers/firmware/efi/test/efi_test.h | 3 +++
2 files changed, 19 insertions(+)
diff --git a/drivers/firmware/efi/test/efi_test.c
b/drivers/firmware/efi/test/efi_test.c
index ddf9eae396fe..47d67bb0a516 100644
--- a/drivers/firmware/efi/test/efi_test.c
+++ b/drivers/firmware/efi/test/efi_test.c
@@ -663,6 +663,19 @@ static long efi_runtime_query_capsulecaps(unsigned long
arg)
return rv;
}
+static long efi_runtime_get_supported_mask(unsigned long arg)
+{
+ unsigned int __user *supported_mask;
+ int rv = 0;
+
+ supported_mask = (unsigned int *)arg;
+
+ if (put_user(efi.runtime_supported_mask, supported_mask))
+ rv = -EFAULT;
+
+ return rv;
+}
+
static long efi_test_ioctl(struct file *file, unsigned int cmd,
unsigned long arg)
{
@@ -699,6 +712,9 @@ static long efi_test_ioctl(struct file *file, unsigned int
cmd,
case EFI_RUNTIME_RESET_SYSTEM:
return efi_runtime_reset_system(arg);
+
+ case EFI_RUNTIME_GET_SUPPORTED_MASK:
+ return efi_runtime_get_supported_mask(arg);
}
return -ENOTTY;
diff --git a/drivers/firmware/efi/test/efi_test.h
b/drivers/firmware/efi/test/efi_test.h
index f2446aa1c2e3..117349e57993 100644
--- a/drivers/firmware/efi/test/efi_test.h
+++ b/drivers/firmware/efi/test/efi_test.h
@@ -118,4 +118,7 @@ struct efi_resetsystem {
#define EFI_RUNTIME_RESET_SYSTEM \
_IOW('p', 0x0B, struct efi_resetsystem)
+#define EFI_RUNTIME_GET_SUPPORTED_MASK \
+ _IOR('p', 0x0C, unsigned int)
+
#endif /* _DRIVERS_FIRMWARE_EFI_TEST_H_ */
--
2.29.2
Re: [PATCH v3 1/9] arm64: dts: ls1028a: fix ENETC PTP clock input
On Sun, Nov 08, 2020 at 07:51:05PM +0100, Michael Walle wrote:
> On the LS1028A the ENETC reference clock is connected to 4th HWA output,
> see Figure 7 "Clock subsystem block diagram".
>
> The PHC may run with a wrong frequency. ptp_qoriq_auto_config() will read
> the clock speed of the clock given in the device tree. It is likely that,
> on the reference board this wasn't noticed because both clocks have the
> same frequency. But this must not be always the case. Fix it.
>
> Fixes: 49401003e260 ("arm64: dts: fsl: ls1028a: add ENETC 1588 timer node")
> Signed-off-by: Michael Walle
Applied, thanks.
Re: [PATCH v3 2/9] arm64: dts: ls1028a: fix FlexSPI clock input
On Sun, Nov 08, 2020 at 07:51:06PM +0100, Michael Walle wrote:
> On the LS1028A the FlexSPI clock is connected to the first HWA output,
> see Figure 7 "Clock subsystem block diagram".
>
> Fixes: c77fae5ba09a ("arm64: dts: ls1028a: Add FlexSPI support")
> Signed-off-by: Michael Walle
Applied, thanks.
[PATCH] cpuidle: Select polling interval based on a c-state with a longer target residency
It was noted that a few workloads that idle rapidly regressed when commit
36fcb4292473 ("cpuidle: use first valid target residency as poll time")
was merged. The workloads in question were heavy communicators that idle
rapidly and were impacted by the c-state exit latency as the active CPUs
were not polling at the time of wakeup. As they were not particularly
realistic workloads, it was not considered to be a major problem.
Unfortunately, a bug was reported for a real workload in a production
environment that relied on large numbers of threads operating in a worker
pool pattern. These threads would idle for periods of time longer than the
C1 target residency and so incurred the c-state exit latency penalty. The
application is very sensitive to wakeup latency and indirectly relying
on behaviour prior to commit on a37b969a61c1 ("cpuidle: poll_state: Add
time limit to poll_idle()") to poll for long enough to avoid the exit
latency cost.
The target residency of C1 is typically very short. On some x86 machines,
it can be as low as 2 microseconds. In poll_idle(), the clock is checked
every POLL_IDLE_RELAX_COUNT interations of cpu_relax() and even one
iteration of that loop can be over 1 microsecond so the polling interval is
very close to the granularity of what poll_idle() can detect. Furthermore,
a basic ping pong workload like perf bench pipe has a longer round-trip
time than the 2 microseconds meaning that the CPU will almost certainly
not be polling when the ping-pong completes.
This patch selects a polling interval based on an enabled c-state that
has an target residency longer than 10usec. If there is no enabled-cstate
then polling will be up to a TICK_NSEC/16 similar to what it was up until
kernel 4.20.
As an example, consider a CPU with the following c-state information from
an Intel CPU;
residency exit_latency
C1 2 2
C1E 20 10
C3 100 33
C6 400 133
The polling interval selected is 20usec. If booted with
intel_idle.max_cstate=1 then the polling interval is 250usec as the deeper
c-states were not available.
On an AMD EPYC machine, the c-state information is more limited and looks
like
residency exit_latency
C1 2 1
C2 800 400
The polling interval selected is 250usec. While C2 was considered, the
polling interval was clamped by CPUIDLE_POLL_MAX.
Note that it is not expected that polling will be a universal win. As
well as potentially trading power for performance, the performance is not
guaranteed if the extra polling prevented a turbo state being reached. The
patch allows the polling interval to be tuned in case a corner-case is
found and if a bug is filed, the tuning may advise how CPUIDLE_POLL_MIN
should be adjusted (e.g. optional overrides per architecture) or if a
different balance point than residency-exit_latency should be used.
tbench4
vanillapolling
Hmean 1497.89 ( 0.00%) 543.15 * 9.09%*
Hmean 2975.88 ( 0.00%) 1059.73 * 8.59%*
Hmean 4 1953.97 ( 0.00%) 2081.37 * 6.52%*
Hmean 8 3645.76 ( 0.00%) 4052.95 * 11.17%*
Hmean 16 6882.21 ( 0.00%) 6995.93 * 1.65%*
Hmean 32 10752.20 ( 0.00%)10731.53 * -0.19%*
Hmean 64 12875.08 ( 0.00%)12478.13 * -3.08%*
Hmean 12821500.54 ( 0.00%)21098.60 * -1.87%*
Hmean 25621253.70 ( 0.00%)21027.18 * -1.07%*
Hmean 32020813.50 ( 0.00%)20580.64 * -1.12%*
Signed-off-by: Mel Gorman
---
Documentation/admin-guide/kernel-parameters.txt | 18 +
drivers/cpuidle/cpuidle.c | 49 -
2 files changed, 65 insertions(+), 2 deletions(-)
diff --git a/Documentation/admin-guide/kernel-parameters.txt
b/Documentation/admin-guide/kernel-parameters.txt
index 526d65d8573a..5b8545022564 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -719,6 +719,24 @@
policy to use. This governor must be registered in the
kernel before the cpufreq driver probes.
+ cpuidle.poll=
+ [CPU_IDLE]
+ Format:
+ Set the time in microseconds a CPU should poll in
+ cpuidle for a new task before entering a sleep
+ state. The default is determined by either the
+ tick or the enabled c-state latencies. Tuning is
+ not generally recommended but it may be needed
+ for workloads that are both latency-sensitive
+ and idling rapidly for short durations. Limiting
+ c-states can be insufficient if the polling
+ time is still too short, the application has no
+
Re: [PATCH] arm64: dts: qcom: c630: Define eDP bridge and panel
On Fri, Nov 27, 2020 at 09:42:31PM -0600, Bjorn Andersson wrote: > The Lenovo Yoga C630 drives the Boe NV133FHM-N61 eDP display from DSI > using a TI SN65DSI86 bridge chip on I2C 10. Define the bridge and eDP > panel and enable the display blocks. > > Signed-off-by: Bjorn Andersson Acked-by: Shawn Guo
Re: [PATCH 0/9] keys: Miscellaneous fixes
Jarkko Sakkinen wrote: > I think that looks good, thank you. I'm sending PR next week. Should I > bundle those to that? I've updated the branch to include an ack from you, plus added the semicolon-removal patch and a #include-removal patch. You can try sending them on, though I don't think any of them are really critical patches (and we are in -rc6). David
[tip: irq/urgent] MAINTAINERS: Move Jason Cooper to CREDITS
The following commit has been merged into the irq/urgent branch of tip: Commit-ID: 509920aee72ae23235615a009c5148cdb38794c3 Gitweb: https://git.kernel.org/tip/509920aee72ae23235615a009c5148cdb38794c3 Author:Marc Zyngier AuthorDate:Sat, 28 Nov 2020 10:37:07 Committer: Thomas Gleixner CommitterDate: Mon, 30 Nov 2020 10:20:34 +01:00 MAINTAINERS: Move Jason Cooper to CREDITS Jason's email address has now been bouncing for weeks, and no reply was received when trying to reach out on other addresses. We really hope he is OK. But until we hear of his whereabouts, let's move him to the CREDITS file so that people stop Cc-ing him. Signed-off-by: Marc Zyngier Signed-off-by: Thomas Gleixner Acked-by: Gregory CLEMENT Acked-by: Andrew Lunn Link: https://lore.kernel.org/r/20201128103707.332874-1-...@kernel.org --- CREDITS | 5 + MAINTAINERS | 4 2 files changed, 5 insertions(+), 4 deletions(-) diff --git a/CREDITS b/CREDITS index 7483019..e88d1a7 100644 --- a/CREDITS +++ b/CREDITS @@ -740,6 +740,11 @@ S: (ask for current address) S: Portland, Oregon S: USA +N: Jason Cooper +D: ARM/Marvell SOC co-maintainer +D: irqchip co-maintainer +D: MVEBU PCI DRIVER co-maintainer + N: Robin Cornelius E: robincornel...@users.sourceforge.net D: Ralink rt2x00 WLAN driver diff --git a/MAINTAINERS b/MAINTAINERS index 2daa6ee..4f27f43 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -2014,7 +2014,6 @@ M:Philipp Zabel S: Maintained ARM/Marvell Dove/MV78xx0/Orion SOC support -M: Jason Cooper M: Andrew Lunn M: Sebastian Hesselbarth M: Gregory Clement @@ -2031,7 +2030,6 @@ F:arch/arm/plat-orion/ F: drivers/soc/dove/ ARM/Marvell Kirkwood and Armada 370, 375, 38x, 39x, XP, 3700, 7K/8K, CN9130 SOC support -M: Jason Cooper M: Andrew Lunn M: Gregory Clement M: Sebastian Hesselbarth @@ -9248,7 +9246,6 @@ F:kernel/irq/ IRQCHIP DRIVERS M: Thomas Gleixner -M: Jason Cooper M: Marc Zyngier L: linux-kernel@vger.kernel.org S: Maintained @@ -13394,7 +13391,6 @@ F: drivers/pci/controller/mobiveil/pcie-mobiveil* PCI DRIVER FOR MVEBU (Marvell Armada 370 and Armada XP SOC support) M: Thomas Petazzoni -M: Jason Cooper L: linux-...@vger.kernel.org L: linux-arm-ker...@lists.infradead.org (moderated for non-subscribers) S: Maintained
Re: [PATCH] net: flow_offload: remove trailing semicolon in macro definition
On 27/11/2020 19:37, t...@redhat.com wrote:
> From: Tom Rix
>
> The macro use will already have a semicolon.
>
> Signed-off-by: Tom Rix
> ---
> net/core/flow_offload.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/net/core/flow_offload.c b/net/core/flow_offload.c
> index d4474c812b64..59ddfd3f3876 100644
> --- a/net/core/flow_offload.c
> +++ b/net/core/flow_offload.c
> @@ -32,7 +32,7 @@ EXPORT_SYMBOL(flow_rule_alloc);
> struct flow_dissector *__d = (__m)->dissector;
> \
>
> \
> (__out)->key = skb_flow_dissector_target(__d, __type, (__m)->key);
> \
> - (__out)->mask = skb_flow_dissector_target(__d, __type, (__m)->mask);
> \
> + (__out)->mask = skb_flow_dissector_target(__d, __type, (__m)->mask)
> \
> Strictly speaking shouldn't this macro have a do {} while (0)
around it anyway?
-ed
Re: [PATCH 3/3] edac: Supporting AST2400 and AST2600 edac driver
Hello Troy, > Adding AST2400 and AST2600 edac driver support. > > Signed-off-by: Troy Lee > --- > drivers/edac/Kconfig | 6 +- > drivers/edac/aspeed_edac.c | 114 + > 2 files changed, 94 insertions(+), 26 deletions(-) Uh, there are quite some non-trivial changes. I'll have a look over the coming weekend. Testing an edac driver comes with challenges. Did you test your code? If so, how? That's how I was testing my original edac 2500 driver http://students.engr.scu.edu/~sschaeck/misc/aspeed-edac.html Stefan
Re: [PATCH 6/8] lazy tlb: shoot lazies, a non-refcounting lazy tlb option
On Sun, Nov 29, 2020 at 12:16:26PM -0800, Andy Lutomirski wrote: > On Sat, Nov 28, 2020 at 7:54 PM Andy Lutomirski wrote: > > > > On Sat, Nov 28, 2020 at 8:02 AM Nicholas Piggin wrote: > > > > > > On big systems, the mm refcount can become highly contented when doing > > > a lot of context switching with threaded applications (particularly > > > switching between the idle thread and an application thread). > > > > > > Abandoning lazy tlb slows switching down quite a bit in the important > > > user->idle->user cases, so so instead implement a non-refcounted scheme > > > that causes __mmdrop() to IPI all CPUs in the mm_cpumask and shoot down > > > any remaining lazy ones. > > > > > > Shootdown IPIs are some concern, but they have not been observed to be > > > a big problem with this scheme (the powerpc implementation generated > > > 314 additional interrupts on a 144 CPU system during a kernel compile). > > > There are a number of strategies that could be employed to reduce IPIs > > > if they turn out to be a problem for some workload. > > > > I'm still wondering whether we can do even better. > > > > Hold on a sec.. __mmput() unmaps VMAs, frees pagetables, and flushes > the TLB. On x86, this will shoot down all lazies as long as even a > single pagetable was freed. (Or at least it will if we don't have a > serious bug, but the code seems okay. We'll hit pmd_free_tlb, which > sets tlb->freed_tables, which will trigger the IPI.) So, on > architectures like x86, the shootdown approach should be free. The > only way it ought to have any excess IPIs is if we have CPUs in > mm_cpumask() that don't need IPI to free pagetables, which could > happen on paravirt. > > Can you try to figure out why you saw any increase in IPIs? It would > be nice if we can make the new code unconditional. Power doesn't do IPI based TLBI.
Hello
Hello I sent a letter to your mail but got no reply from you. Did you receive my previous mail please i wait to read your mail soon on my email address at ( mrs.suniewen...@gmail.com ) respond to me
Re: linux-next: manual merge of the akpm-current tree with the tip tree
On Fri, Nov 27 2020 at 13:54, Andy Shevchenko wrote: >> I fixed it up (see below) and can carry the fix as necessary. This >> is now fixed as far as linux-next is concerned, but any non trivial >> conflicts should be mentioned to your upstream maintainer when your tree >> is submitted for merging. You may also want to consider cooperating >> with the maintainer of the conflicting tree to minimise any particularly >> complex conflicts. > > Thanks, from my perspective looks good, dunno if scheduler part is okay. The final outcome in -next looks correct. Thanks, tglx
Re: [PATCH 6/8] lazy tlb: shoot lazies, a non-refcounting lazy tlb option
On Sat, Nov 28, 2020 at 07:54:57PM -0800, Andy Lutomirski wrote: > Version (b) seems fairly straightforward to implement -- add RCU > protection and a atomic_t special_ref_cleared (initially 0) to struct > mm_struct itself. After anyone clears a bit to mm_cpumask (which is > already a barrier), No it isn't. clear_bit() implies no barrier what so ever. That's x86 you're thinking about. > they read mm_users. If it's zero, then they scan > mm_cpumask and see if it's empty. If it is, they atomically swap > special_ref_cleared to 1. If it was zero before the swap, they do > mmdrop(). I can imagine some tweaks that could make this a big > faster, at least in the limit of a huge number of CPUs.
Re: [PATCH] vdpa/mlx5: Use random MAC for the vdpa net instance
On Mon, Nov 30, 2020 at 04:00:51AM -0500, Michael S. Tsirkin wrote:
> On Mon, Nov 30, 2020 at 08:27:46AM +0200, Eli Cohen wrote:
> > On Sun, Nov 29, 2020 at 03:08:22PM -0500, Michael S. Tsirkin wrote:
> > > On Sun, Nov 29, 2020 at 08:43:51AM +0200, Eli Cohen wrote:
> > > > We should not try to use the VF MAC address as that is used by the
> > > > regular (e.g. mlx5_core) NIC implementation. Instead, use a random
> > > > generated MAC address.
> > > >
> > > > Suggested by: Cindy Lu
> > > > Fixes: 1a86b377aa21 ("vdpa/mlx5: Add VDPA driver for supported mlx5
> > > > devices")
> > > > Signed-off-by: Eli Cohen
> > >
> > > I didn't realise it's possible to use VF in two ways
> > > with and without vdpa.
> >
> > Using a VF you can create quite a few resources, e.g. send queues
> > recieve queues, virtio_net queues etc. So you can possibly create
> > several instances of vdpa net devices and nic net devices.
> >
> > > Could you include a bit more description on the failure
> > > mode?
> >
> > Well, using the MAC address of the nic vport is wrong since that is the
> > MAC of the regular NIC implementation of mlx5_core.
>
> Right but ATM it doesn't coexist with vdpa so what's the problem?
>
This call is wrong: mlx5_query_nic_vport_mac_address()
> > > Is switching to a random mac for such an unusual
> > > configuration really justified?
> >
> > Since I can't use the NIC's MAC address, I have two options:
> > 1. To get the MAC address as was chosen by the user administering the
> >NIC. This should invoke the set_config callback. Unfortunately this
> >is not implemented yet.
> >
> > 2. Use a random MAC address. This is OK since if (1) is implemented it
> >can always override this random configuration.
> >
> > > It looks like changing a MAC could break some guests,
> > > can it not?
> > >
> >
> > No, it will not. The current version of mlx5 VDPA does not allow regular
> > NIC driver and VDPA to co-exist. I have patches ready that enable that
> > from steering point of view. I will post them here once other patches on
> > which they depend will be merged.
> >
> > https://patchwork.ozlabs.org/project/netdev/patch/20201120230339.651609-12-sae...@nvidia.com/
>
> Could you be more explicit on the following points:
> - which configuration is broken ATM (as in, two device have identical
> macs? any other issues)?
The only wrong thing is the call to mlx5_query_nic_vport_mac_address().
It's not breaking anything yet is wrong. The random MAC address setting
is required for the steering patches.
> - why won't device MAC change from guest point of view?
>
It's lack of implementation in qemu as far as I know.
>
> > > > ---
> > > > drivers/vdpa/mlx5/net/mlx5_vnet.c | 5 +
> > > > 1 file changed, 1 insertion(+), 4 deletions(-)
> > > >
> > > > diff --git a/drivers/vdpa/mlx5/net/mlx5_vnet.c
> > > > b/drivers/vdpa/mlx5/net/mlx5_vnet.c
> > > > index 1fa6fcac8299..80d06d958b8b 100644
> > > > --- a/drivers/vdpa/mlx5/net/mlx5_vnet.c
> > > > +++ b/drivers/vdpa/mlx5/net/mlx5_vnet.c
> > > > @@ -1955,10 +1955,7 @@ void *mlx5_vdpa_add_dev(struct mlx5_core_dev
> > > > *mdev)
> > > > if (err)
> > > > goto err_mtu;
> > > >
> > > > - err = mlx5_query_nic_vport_mac_address(mdev, 0, 0, config->mac);
> > > > - if (err)
> > > > - goto err_mtu;
> > > > -
> > > > + eth_random_addr(config->mac);
> > > > mvdev->vdev.dma_dev = mdev->device;
> > > > err = mlx5_vdpa_alloc_resources(&ndev->mvdev);
> > > > if (err)
> > > > --
> > > > 2.26.2
> > >
>
Re: [PATCH v4 2/2] media: i2c: Add support for the OV5648 image sensor
Hi Paul, Thanks for the update. I have a few comments on the driver, too. On Sat, Nov 28, 2020 at 03:33:50PM +0100, Paul Kocialkowski wrote: > The OV5648 is a 5 Mpx CMOS image sensor, connected via MIPI CSI-2 > in a one or two lane configuration. > > Most of the features of the hardware are supported, including: > - Auto and manual exposition/gain > - Auto and manual white balance > - Horizontal and vertical flip > - Test patterns > > But the following are still missing: > - Debanding, based on power source frequency; > - Exposition setting correlated to time units. > > Signed-off-by: Paul Kocialkowski > --- > drivers/media/i2c/Kconfig | 14 + > drivers/media/i2c/Makefile |1 + > drivers/media/i2c/ov5648.c | 2714 > 3 files changed, 2729 insertions(+) > create mode 100644 drivers/media/i2c/ov5648.c > > diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig > index 878f66ef2719..f971225893a1 100644 > --- a/drivers/media/i2c/Kconfig > +++ b/drivers/media/i2c/Kconfig > @@ -922,6 +922,20 @@ config VIDEO_OV5647 > To compile this driver as a module, choose M here: the > module will be called ov5647. > > +config VIDEO_OV5648 > + tristate "OmniVision OV5648 sensor support" > + depends on OF > + depends on I2C && VIDEO_V4L2 > + select MEDIA_CONTROLLER > + select VIDEO_V4L2_SUBDEV_API > + select V4L2_FWNODE > + help > + This is a Video4Linux2 sensor driver for the OmniVision > + OV5648 camera. > + > + To compile this driver as a module, choose M here: the > + module will be called ov5648. > + > config VIDEO_OV6650 > tristate "OmniVision OV6650 sensor support" > depends on I2C && VIDEO_V4L2 > diff --git a/drivers/media/i2c/Makefile b/drivers/media/i2c/Makefile > index f0a77473979d..15d4d6382582 100644 > --- a/drivers/media/i2c/Makefile > +++ b/drivers/media/i2c/Makefile > @@ -71,6 +71,7 @@ obj-$(CONFIG_VIDEO_OV2740) += ov2740.o > obj-$(CONFIG_VIDEO_OV5640) += ov5640.o > obj-$(CONFIG_VIDEO_OV5645) += ov5645.o > obj-$(CONFIG_VIDEO_OV5647) += ov5647.o > +obj-$(CONFIG_VIDEO_OV5648) += ov5648.o > obj-$(CONFIG_VIDEO_OV5670) += ov5670.o > obj-$(CONFIG_VIDEO_OV5675) += ov5675.o > obj-$(CONFIG_VIDEO_OV5695) += ov5695.o > diff --git a/drivers/media/i2c/ov5648.c b/drivers/media/i2c/ov5648.c > new file mode 100644 > index ..43e0c2c3ccfa > --- /dev/null > +++ b/drivers/media/i2c/ov5648.c > @@ -0,0 +1,2714 @@ > +// SPDX-License-Identifier: GPL-2.0-or-later > +/* > + * Copyright (C) 2020 Bootlin > + * Author: Paul Kocialkowski > + */ > + > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > + > +/* Clock rate */ > + > +#define OV5648_XVCLK_RATE2400 > + > +/* Register definitions */ > + > +/* System */ > + > +#define OV5648_SW_STANDBY_REG0x100 > +#define OV5648_SW_STANDBY_STREAM_ON BIT(0) > + > +#define OV5648_SW_RESET_REG 0x103 > +#define OV5648_SW_RESET_RESETBIT(0) > + > +#define OV5648_PAD_OEN0_REG 0x3000 > +#define OV5648_PAD_OEN1_REG 0x3001 > +#define OV5648_PAD_OEN2_REG 0x3002 > +#define OV5648_PAD_OUT0_REG 0x3008 > +#define OV5648_PAD_OUT1_REG 0x3009 > + > +#define OV5648_CHIP_ID_H_REG 0x300a > +#define OV5648_CHIP_ID_H_VALUE 0x56 > +#define OV5648_CHIP_ID_L_REG 0x300b > +#define OV5648_CHIP_ID_L_VALUE 0x48 > + > +#define OV5648_PAD_OUT2_REG 0x300d > +#define OV5648_PAD_SEL0_REG 0x300e > +#define OV5648_PAD_SEL1_REG 0x300f > +#define OV5648_PAD_SEL2_REG 0x3010 > +#define OV5648_PAD_PK_REG0x3011 > +#define OV5648_PAD_PK_PD_DATO_EN BIT(7) > +#define OV5648_PAD_PK_DRIVE_STRENGTH_1X (0 << 5) > +#define OV5648_PAD_PK_DRIVE_STRENGTH_2X (2 << 5) > +#define OV5648_PAD_PK_FREX_N BIT(1) > + > +#define OV5648_A_PWC_PK_O0_REG 0x3013 > +#define OV5648_A_PWC_PK_O0_BP_REGULATOR_NBIT(3) > +#define OV5648_A_PWC_PK_O1_REG 0x3014 > + > +#define OV5648_MIPI_PHY0_REG 0x3016 > +#define OV5648_MIPI_PHY1_REG 0x3017 > +#define OV5648_MIPI_SC_CTRL0_REG 0x3018 > +#define OV5648_MIPI_SC_CTRL0_MIPI_LANES(v) (((v) << 5) & GENMASK(7, 5)) > +#define OV5648_MIPI_SC_CTRL0_PHY_HS_TX_PDBIT(4) > +#define OV5648_MIPI_SC_CTRL0_PHY_LP_RX_PDBIT(3) > +#define OV5648_MIPI_SC_CTRL0_MIPI_EN BIT(2) > +#define OV5648_MIPI_SC_CTRL0_MIPI_SUSP BIT(1) > +#define OV5648_MIPI_SC_CTRL0_LANE_DIS_OP BIT(0) > +#define OV5648_MIPI_SC_CTRL1_REG 0x3019 > +#define
Re: [PATCH] arm64: dts: ls1028a: add optee node
On Sun, Nov 15, 2020 at 11:53:14PM +0100, Michael Walle wrote: > Add the optee node which can either be enabled by a specific board or by > the bootloader. > > Signed-off-by: Michael Walle Applied, thanks.
[PATCH] media: vidtv: fix read after free
`vidtv_channel_si_destroy` function has a call to
`vidtv_psi_pat_table_destroy` that frees Program Association Table.
However it is followed by a loop that iterates over the count of Program
Map Tables. This obviously accesses an invalid memory.
Eliminate this by making a copy of num_pmt before free'ing Program
Association Table and loop on it instead.
Signed-off-by: Cengiz Can
---
drivers/media/test-drivers/vidtv/vidtv_channel.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/media/test-drivers/vidtv/vidtv_channel.c
b/drivers/media/test-drivers/vidtv/vidtv_channel.c
index 8ad6c0744d36..4af39a8786a7 100644
--- a/drivers/media/test-drivers/vidtv/vidtv_channel.c
+++ b/drivers/media/test-drivers/vidtv/vidtv_channel.c
@@ -503,10 +503,13 @@ int vidtv_channel_si_init(struct vidtv_mux *m)
void vidtv_channel_si_destroy(struct vidtv_mux *m)
{
u32 i;
+ u16 num_pmt;
+
+ num_pmt = m->si.pat->num_pmt;
vidtv_psi_pat_table_destroy(m->si.pat);
- for (i = 0; i < m->si.pat->num_pmt; ++i)
+ for (i = 0; i < num_pmt; ++i)
vidtv_psi_pmt_table_destroy(m->si.pmt_secs[i]);
kfree(m->si.pmt_secs);
--
2.29.2
Re: [PATCH 6/8] lazy tlb: shoot lazies, a non-refcounting lazy tlb option
On Sat, Nov 28, 2020 at 07:54:57PM -0800, Andy Lutomirski wrote: > This means that mm_cpumask operations won't need to be full barriers > forever, and we might not want to take the implied full barriers in > set_bit() and clear_bit() for granted. There is no implied full barrier for those ops.
Re: [PATCH] arm64: dts: freescale: sl28: combine SPI MTD partitions
On Sun, Nov 15, 2020 at 11:54:35PM +0100, Michael Walle wrote:
> The upstream port, doesn't really follow the vendor partitioning. The
> bootloader partition has one U-Boot FIT image containing all needed
> bits and pieces. Even today the bootloader is already larger than the
> current "bootloader" partition. Thus, fold all the partitions into one
> and keep the environment one. The latter is still valid.
> We keep the failsafe partitions because the first half of the SPI flash
> is preinstalled by the vendor and immutable.
>
> Fixes: 815364d0424e ("arm64: dts: freescale: add Kontron sl28 support")
> Signed-off-by: Michael Walle
Applied, thanks.
Re: [PATCH v4 17/25] coresight: etm4x: Use TRCDEVARCH for component discovery
On 11/27/20 6:28 PM, Mathieu Poirier wrote: On Thu, Nov 19, 2020 at 04:45:39PM +, Suzuki K Poulose wrote: We have been using TRCIDR1 for detecting the ETM version. This is in preparation for the future IP support. Cc: Mike Leach Reviewed-by: Suzuki K Poulose You have reviewed your own code - that's great! I had a good giggle on that one. I have started reviewing this set... Yikes, sorry. It must have been a copy/paste error. It was supposed to be yours https://lore.kernel.org/linux-arm-kernel/20201106214228.GE3299843@xps15/ Cheers Suzuki
Re: [PATCH v2] ARM: mxs: Add serial number support for i.MX23, i.MX28 SoCs
On Mon, Nov 16, 2020 at 07:58:26PM +0300, Ivan Zaentsev wrote: > i.MX23 and i.MX28 SoCs unique identifiers are factory-programmed > in On-Chip OTP memory. i.MX28's 64-bit unique id is in > HW_OCOTP_OPS2:HW_OCOTP_OPS3 (see MCIMX28 Ref. Man., sec. 20.4.22-23). > > i.MX23 provides 32-bit long unique id in HW_OCOTP_OPS3. > Though not clearly documented, there is a clue in sec. 35.9.3. > > The unique id is reported in /sys/devices/soc0/serial_number > and in /proc/cpuinfo > > Signed-off-by: Ivan Zaentsev > Suggested-by: Evgeny Boger Applied, thanks.
