* [PATCH 2/4] arm64: mm: Provide prot param in trans_pgd_idmap_page()'s prototype
From: Pingfan Liu @ 2024-03-28 11:56 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Pingfan Liu, Catalin Marinas, Will Deacon, Ard Biesheuvel,
Kees Cook, Mark Rutland, Pasha Tatashin
In-Reply-To: <20240328115656.24090-1-piliu@redhat.com>
Since relocate_kernel code will build stack at the rear of the page,
it requires 'wx' on the page. Adapting the prototype of
trans_pgd_idmap_page() to make it doable.
The trans_pgd_idmap_page() can be enhanced further to support multiple
pages. But since the change has met the requirement, it is not
necessary to enhance for the time being.
Signed-off-by: Pingfan Liu <piliu@redhat.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <will@kernel.org>
Cc: Ard Biesheuvel <ardb@kernel.org>
Cc: Kees Cook <keescook@chromium.org>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Pasha Tatashin <pasha.tatashin@soleen.com>
To: linux-arm-kernel@lists.infradead.org
---
arch/arm64/include/asm/trans_pgd.h | 2 +-
arch/arm64/kernel/hibernate.c | 3 ++-
arch/arm64/kernel/machine_kexec.c | 4 ++--
arch/arm64/mm/trans_pgd.c | 4 ++--
4 files changed, 7 insertions(+), 6 deletions(-)
diff --git a/arch/arm64/include/asm/trans_pgd.h b/arch/arm64/include/asm/trans_pgd.h
index 033d400a4ea4..c55a8a5670a8 100644
--- a/arch/arm64/include/asm/trans_pgd.h
+++ b/arch/arm64/include/asm/trans_pgd.h
@@ -31,7 +31,7 @@ int trans_pgd_create_copy(struct trans_pgd_info *info, pgd_t **trans_pgd,
unsigned long start, unsigned long end);
int trans_pgd_idmap_page(struct trans_pgd_info *info, phys_addr_t *trans_ttbr0,
- unsigned long *t0sz, void *page);
+ unsigned long *t0sz, void *page, pgprot_t prot);
int trans_pgd_copy_el2_vectors(struct trans_pgd_info *info,
phys_addr_t *el2_vectors);
diff --git a/arch/arm64/kernel/hibernate.c b/arch/arm64/kernel/hibernate.c
index 02870beb271e..0c5ce99b7acf 100644
--- a/arch/arm64/kernel/hibernate.c
+++ b/arch/arm64/kernel/hibernate.c
@@ -203,7 +203,8 @@ static int create_safe_exec_page(void *src_start, size_t length,
memcpy(page, src_start, length);
caches_clean_inval_pou((unsigned long)page, (unsigned long)page + length);
- rc = trans_pgd_idmap_page(&trans_info, &trans_ttbr0, &t0sz, page);
+ rc = trans_pgd_idmap_page(&trans_info, &trans_ttbr0, &t0sz, page,
+ PAGE_KERNEL_ROX);
if (rc)
return rc;
diff --git a/arch/arm64/kernel/machine_kexec.c b/arch/arm64/kernel/machine_kexec.c
index b38aae5b488d..de4e9e0ad682 100644
--- a/arch/arm64/kernel/machine_kexec.c
+++ b/arch/arm64/kernel/machine_kexec.c
@@ -141,8 +141,8 @@ int machine_kexec_post_load(struct kimage *kimage)
reloc_size = __relocate_new_kernel_end - __relocate_new_kernel_start;
memcpy(reloc_code, __relocate_new_kernel_start, reloc_size);
kimage->arch.kern_reloc = __pa(reloc_code);
- rc = trans_pgd_idmap_page(&info, &kimage->arch.ttbr0,
- &kimage->arch.t0sz, reloc_code);
+ rc = trans_pgd_idmap_page(&info, &kimage->arch.ttbr0, &kimage->arch.t0sz,
+ reloc_code, PAGE_KERNEL_EXEC);
if (rc)
return rc;
kimage->arch.phys_offset = virt_to_phys(kimage) - (long)kimage;
diff --git a/arch/arm64/mm/trans_pgd.c b/arch/arm64/mm/trans_pgd.c
index 7b14df3c6477..4dfe6a9f9a8b 100644
--- a/arch/arm64/mm/trans_pgd.c
+++ b/arch/arm64/mm/trans_pgd.c
@@ -230,7 +230,7 @@ int trans_pgd_create_copy(struct trans_pgd_info *info, pgd_t **dst_pgdp,
* maximum T0SZ for this page.
*/
int trans_pgd_idmap_page(struct trans_pgd_info *info, phys_addr_t *trans_ttbr0,
- unsigned long *t0sz, void *page)
+ unsigned long *t0sz, void *page, pgprot_t prot)
{
phys_addr_t dst_addr = virt_to_phys(page);
unsigned long pfn = __phys_to_pfn(dst_addr);
@@ -240,7 +240,7 @@ int trans_pgd_idmap_page(struct trans_pgd_info *info, phys_addr_t *trans_ttbr0,
int this_level, index, level_lsb, level_msb;
dst_addr &= PAGE_MASK;
- prev_level_entry = pte_val(pfn_pte(pfn, PAGE_KERNEL_ROX));
+ prev_level_entry = pte_val(pfn_pte(pfn, prot));
for (this_level = 3; this_level >= 0; this_level--) {
levels[this_level] = trans_alloc(info);
--
2.41.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 0/4] arm64: kexec: translate relocate_kernel.S to C languange
From: Pingfan Liu @ 2024-03-28 11:56 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Pingfan Liu, Catalin Marinas, Will Deacon, Ard Biesheuvel,
Kees Cook, Mark Rutland, Pasha Tatashin
Translate relocate_kernel.S to C languange to make it more readable.
The relocate_kernel.c is PIE, but I am not sure whether it should locate in
kernel/pi, which runs check on the PIE code. (I can correct it in next
version)
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <will@kernel.org>
Cc: Ard Biesheuvel <ardb@kernel.org>
Cc: Kees Cook <keescook@chromium.org>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Pasha Tatashin <pasha.tatashin@soleen.com>
To: linux-arm-kernel@lists.infradead.org
---
Pingfan Liu (4):
arm64: relocate: Let __relocate_new_kernel_start align on SZ_4K
arm64: mm: Provide prot param in trans_pgd_idmap_page()'s prototype
arm64: kexec: Introduce d_size to carry cacheline size information
arm64: kexec: Change relocate_kernel to C code
arch/arm64/include/asm/kexec.h | 1 +
arch/arm64/include/asm/trans_pgd.h | 2 +-
arch/arm64/kernel/Makefile | 1 +
arch/arm64/kernel/asm-offsets.c | 10 --
arch/arm64/kernel/hibernate.c | 3 +-
arch/arm64/kernel/machine_kexec.c | 16 ++-
arch/arm64/kernel/relocate_kernel.S | 100 --------------
arch/arm64/kernel/relocate_kernel.c | 197 ++++++++++++++++++++++++++++
arch/arm64/kernel/vmlinux.lds.S | 3 +-
arch/arm64/mm/trans_pgd.c | 4 +-
10 files changed, 218 insertions(+), 119 deletions(-)
delete mode 100644 arch/arm64/kernel/relocate_kernel.S
create mode 100644 arch/arm64/kernel/relocate_kernel.c
--
2.41.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v3 2/5] mfd: rk8xx: Add RK816 support
From: Lee Jones @ 2024-03-28 11:55 UTC (permalink / raw)
To: Alex Bee
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Heiko Stuebner,
Linus Walleij, Liam Girdwood, Mark Brown, Chris Zhong, Zhang Qing,
devicetree, linux-arm-kernel, linux-rockchip, linux-kernel,
linux-gpio
In-Reply-To: <20240323132757.141861-6-knaerzche@gmail.com>
On Sat, 23 Mar 2024, Alex Bee wrote:
> This integrates RK816 support in the this existing rk8xx mfd driver.
>
> This version has unaligned interrupt registers, which requires to define a
> separate get_irq_reg callback for the regmap. Apart from that the
> integration is straightforward and the existing structures can be used as
> is. The initialization sequence has been taken from vendor kernel.
>
> Signed-off-by: Alex Bee <knaerzche@gmail.com>
> ---
> chnages since v1:
> - un-constify rk816_get_irq_reg's return type
>
> drivers/mfd/Kconfig | 4 +-
> drivers/mfd/rk8xx-core.c | 103 ++++++++++++++++++++++++++++
> drivers/mfd/rk8xx-i2c.c | 45 +++++++++++-
> include/linux/mfd/rk808.h | 141 ++++++++++++++++++++++++++++++++++++++
> 4 files changed, 290 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
> index 4b023ee229cf..2e7286cc98e4 100644
> --- a/drivers/mfd/Kconfig
> +++ b/drivers/mfd/Kconfig
> @@ -1225,7 +1225,7 @@ config MFD_RK8XX
> select MFD_CORE
>
> config MFD_RK8XX_I2C
> - tristate "Rockchip RK805/RK808/RK809/RK817/RK818 Power Management Chip"
> + tristate "Rockchip RK805/RK808/RK809/RK816/RK817/RK818 Power Management Chip"
> depends on I2C && OF
> select MFD_CORE
> select REGMAP_I2C
> @@ -1233,7 +1233,7 @@ config MFD_RK8XX_I2C
> select MFD_RK8XX
> help
> If you say yes here you get support for the RK805, RK808, RK809,
> - RK817 and RK818 Power Management chips.
> + RK816, RK817 and RK818 Power Management chips.
> This driver provides common support for accessing the device
> through I2C interface. The device supports multiple sub-devices
> including interrupts, RTC, LDO & DCDC regulators, and onkey.
> diff --git a/drivers/mfd/rk8xx-core.c b/drivers/mfd/rk8xx-core.c
> index e2261b68b844..c68a380332e7 100644
> --- a/drivers/mfd/rk8xx-core.c
> +++ b/drivers/mfd/rk8xx-core.c
> @@ -28,6 +28,10 @@ static const struct resource rtc_resources[] = {
> DEFINE_RES_IRQ(RK808_IRQ_RTC_ALARM),
> };
>
> +static const struct resource rk816_rtc_resources[] = {
> + DEFINE_RES_IRQ(RK816_IRQ_RTC_ALARM),
> +};
> +
> static const struct resource rk817_rtc_resources[] = {
> DEFINE_RES_IRQ(RK817_IRQ_RTC_ALARM),
> };
> @@ -87,6 +91,21 @@ static const struct mfd_cell rk808s[] = {
> },
> };
>
> +static const struct mfd_cell rk816s[] = {
> + { .name = "rk805-pinctrl", },
> + { .name = "rk808-clkout", },
> + { .name = "rk808-regulator", },
> + { .name = "rk805-pwrkey",
Newline after the '{'.
> + .num_resources = ARRAY_SIZE(rk805_key_resources),
> + .resources = rk805_key_resources,
> + },
> + {
> + .name = "rk808-rtc",
> + .num_resources = ARRAY_SIZE(rk816_rtc_resources),
> + .resources = rk816_rtc_resources,
> + },
> +};
> +
> static const struct mfd_cell rk817s[] = {
> { .name = "rk808-clkout", },
> { .name = "rk808-regulator", },
> @@ -148,6 +167,17 @@ static const struct rk808_reg_data rk808_pre_init_reg[] = {
> VB_LO_SEL_3500MV },
> };
>
> +static const struct rk808_reg_data rk816_pre_init_reg[] = {
> + { RK818_BUCK1_CONFIG_REG, RK817_RAMP_RATE_MASK,
> + RK817_RAMP_RATE_12_5MV_PER_US },
> + { RK818_BUCK2_CONFIG_REG, RK817_RAMP_RATE_MASK,
> + RK817_RAMP_RATE_12_5MV_PER_US },
> + { RK818_BUCK4_CONFIG_REG, BUCK_ILMIN_MASK, BUCK_ILMIN_250MA },
> + { RK808_THERMAL_REG, TEMP_HOTDIE_MSK, TEMP105C},
> + { RK808_VB_MON_REG, VBAT_LOW_VOL_MASK | VBAT_LOW_ACT_MASK,
> + RK808_VBAT_LOW_3V0 | EN_VABT_LOW_SHUT_DOWN },
> +};
> +
> static const struct rk808_reg_data rk817_pre_init_reg[] = {
> {RK817_RTC_CTRL_REG, RTC_STOP, RTC_STOP},
> /* Codec specific registers */
> @@ -350,6 +380,59 @@ static const struct regmap_irq rk808_irqs[] = {
> },
> };
>
> +static const unsigned int rk816_irq_status_offsets[] = {
> + (RK816_INT_STS_REG1 - RK816_INT_STS_REG1),
Turn this into a macro please.
> + (RK816_INT_STS_REG2 - RK816_INT_STS_REG1),
> + (RK816_INT_STS_REG3 - RK816_INT_STS_REG1),
> +};
> +
> +static const unsigned int rk816_irq_mask_offsets[] = {
> + (RK816_INT_STS_MSK_REG1 - RK816_INT_STS_MSK_REG1),
> + (RK816_INT_STS_MSK_REG2 - RK816_INT_STS_MSK_REG1),
> + (RK816_INT_STS_MSK_REG3 - RK816_INT_STS_MSK_REG1),
> +};
> +
> +static unsigned int rk816_get_irq_reg(struct regmap_irq_chip_data *data,
> + unsigned int base, int index)
> +{
> + unsigned int irq_reg = base;
> +
> + switch (base) {
> + case RK816_INT_STS_REG1:
> + irq_reg += rk816_irq_status_offsets[index];
> + break;
> + case RK816_INT_STS_MSK_REG1:
> + irq_reg += rk816_irq_mask_offsets[index];
> + break;
> + }
> +
> + return irq_reg;
> +};
> +
> +static const struct regmap_irq rk816_irqs[] = {
> + /* INT_STS_REG1 IRQs */
> + REGMAP_IRQ_REG(RK816_IRQ_PWRON_FALL, 0, RK816_INT_STS_PWRON_FALL),
> + REGMAP_IRQ_REG(RK816_IRQ_PWRON_RISE, 0, RK816_INT_STS_PWRON_RISE),
> +
> + /* INT_STS_REG2 IRQs */
> + REGMAP_IRQ_REG(RK816_IRQ_VB_LOW, 1, RK816_INT_STS_VB_LOW),
> + REGMAP_IRQ_REG(RK816_IRQ_PWRON, 1, RK816_INT_STS_PWRON),
> + REGMAP_IRQ_REG(RK816_IRQ_PWRON_LP, 1, RK816_INT_STS_PWRON_LP),
> + REGMAP_IRQ_REG(RK816_IRQ_HOTDIE, 1, RK816_INT_STS_HOTDIE),
> + REGMAP_IRQ_REG(RK816_IRQ_RTC_ALARM, 1, RK816_INT_STS_RTC_ALARM),
> + REGMAP_IRQ_REG(RK816_IRQ_RTC_PERIOD, 1, RK816_INT_STS_RTC_PERIOD),
> + REGMAP_IRQ_REG(RK816_IRQ_USB_OV, 1, RK816_INT_STS_USB_OV),
> +
> + /* INT_STS3 IRQs */
> + REGMAP_IRQ_REG(RK816_IRQ_PLUG_IN, 2, RK816_INT_STS_PLUG_IN),
> + REGMAP_IRQ_REG(RK816_IRQ_PLUG_OUT, 2, RK816_INT_STS_PLUG_OUT),
> + REGMAP_IRQ_REG(RK816_IRQ_CHG_OK, 2, RK816_INT_STS_CHG_OK),
> + REGMAP_IRQ_REG(RK816_IRQ_CHG_TE, 2, RK816_INT_STS_CHG_TE),
> + REGMAP_IRQ_REG(RK816_IRQ_CHG_TS, 2, RK816_INT_STS_CHG_TS),
> + REGMAP_IRQ_REG(RK816_IRQ_CHG_CVTLIM, 2, RK816_INT_STS_CHG_CVTLIM),
> + REGMAP_IRQ_REG(RK816_IRQ_DISCHG_ILIM, 2, RK816_INT_STS_DISCHG_ILIM),
> +};
> +
> static const struct regmap_irq rk818_irqs[] = {
> /* INT_STS */
> [RK818_IRQ_VOUT_LO] = {
> @@ -482,6 +565,18 @@ static const struct regmap_irq_chip rk808_irq_chip = {
> .init_ack_masked = true,
> };
>
> +static const struct regmap_irq_chip rk816_irq_chip = {
> + .name = "rk816",
> + .irqs = rk816_irqs,
> + .num_irqs = ARRAY_SIZE(rk816_irqs),
> + .num_regs = 3,
> + .get_irq_reg = rk816_get_irq_reg,
> + .status_base = RK816_INT_STS_REG1,
> + .mask_base = RK816_INT_STS_MSK_REG1,
> + .ack_base = RK816_INT_STS_REG1,
> + .init_ack_masked = true,
> +};
> +
> static struct regmap_irq_chip rk817_irq_chip = {
> .name = "rk817",
> .irqs = rk817_irqs,
> @@ -530,6 +625,7 @@ static int rk808_power_off(struct sys_off_data *data)
> reg = RK817_SYS_CFG(3);
> bit = DEV_OFF;
> break;
> + case RK816_ID:
> case RK818_ID:
> reg = RK818_DEVCTRL_REG;
> bit = DEV_OFF;
> @@ -637,6 +733,13 @@ int rk8xx_probe(struct device *dev, int variant, unsigned int irq, struct regmap
> cells = rk808s;
> nr_cells = ARRAY_SIZE(rk808s);
> break;
> + case RK816_ID:
> + rk808->regmap_irq_chip = &rk816_irq_chip;
> + pre_init_reg = rk816_pre_init_reg;
> + nr_pre_init_regs = ARRAY_SIZE(rk816_pre_init_reg);
> + cells = rk816s;
> + nr_cells = ARRAY_SIZE(rk816s);
> + break;
> case RK818_ID:
> rk808->regmap_irq_chip = &rk818_irq_chip;
> pre_init_reg = rk818_pre_init_reg;
> diff --git a/drivers/mfd/rk8xx-i2c.c b/drivers/mfd/rk8xx-i2c.c
> index 75b5cf09d5a0..69a6b297d723 100644
> --- a/drivers/mfd/rk8xx-i2c.c
> +++ b/drivers/mfd/rk8xx-i2c.c
> @@ -1,6 +1,6 @@
> // SPDX-License-Identifier: GPL-2.0-only
> /*
> - * Rockchip RK808/RK818 Core (I2C) driver
> + * Rockchip RK805/RK808/RK816/RK817/RK818 Core (I2C) driver
> *
> * Copyright (c) 2014, Fuzhou Rockchip Electronics Co., Ltd
> * Copyright (C) 2016 PHYTEC Messtechnik GmbH
> @@ -49,6 +49,35 @@ static bool rk808_is_volatile_reg(struct device *dev, unsigned int reg)
> return false;
> }
>
> +static bool rk816_is_volatile_reg(struct device *dev, unsigned int reg)
> +{
> + /*
> + * Technically the ROUND_30s bit makes RTC_CTRL_REG volatile, but
> + * we don't use that feature. It's better to cache.
> + */
> +
> + switch (reg) {
> + case RK808_SECONDS_REG ... RK808_WEEKS_REG:
> + case RK808_RTC_STATUS_REG:
> + case RK808_VB_MON_REG:
> + case RK808_THERMAL_REG:
> + case RK816_DCDC_EN_REG1:
> + case RK816_DCDC_EN_REG2:
> + case RK816_INT_STS_REG1:
> + case RK816_INT_STS_REG2:
> + case RK816_INT_STS_REG3:
> + case RK808_DEVCTRL_REG:
> + case RK816_SUP_STS_REG:
> + case RK816_GGSTS_REG:
> + case RK816_ZERO_CUR_ADC_REGH:
> + case RK816_ZERO_CUR_ADC_REGL:
> + case RK816_GASCNT_REG(0) ... RK816_BAT_VOL_REGL:
> + return true;
> + }
> +
> + return false;
> +}
> +
> static bool rk817_is_volatile_reg(struct device *dev, unsigned int reg)
> {
> /*
> @@ -100,6 +129,14 @@ static const struct regmap_config rk808_regmap_config = {
> .volatile_reg = rk808_is_volatile_reg,
> };
>
> +static const struct regmap_config rk816_regmap_config = {
> + .reg_bits = 8,
> + .val_bits = 8,
> + .max_register = RK816_DATA_REG(18),
> + .cache_type = REGCACHE_MAPLE,
> + .volatile_reg = rk816_is_volatile_reg,
> +};
> +
> static const struct regmap_config rk817_regmap_config = {
> .reg_bits = 8,
> .val_bits = 8,
> @@ -123,6 +160,11 @@ static const struct rk8xx_i2c_platform_data rk809_data = {
> .variant = RK809_ID,
> };
>
> +static const struct rk8xx_i2c_platform_data rk816_data = {
> + .regmap_cfg = &rk816_regmap_config,
> + .variant = RK816_ID,
> +};
> +
> static const struct rk8xx_i2c_platform_data rk817_data = {
> .regmap_cfg = &rk817_regmap_config,
> .variant = RK817_ID,
> @@ -161,6 +203,7 @@ static const struct of_device_id rk8xx_i2c_of_match[] = {
> { .compatible = "rockchip,rk805", .data = &rk805_data },
> { .compatible = "rockchip,rk808", .data = &rk808_data },
> { .compatible = "rockchip,rk809", .data = &rk809_data },
> + { .compatible = "rockchip,rk816", .data = &rk816_data },
> { .compatible = "rockchip,rk817", .data = &rk817_data },
> { .compatible = "rockchip,rk818", .data = &rk818_data },
> { },
> diff --git a/include/linux/mfd/rk808.h b/include/linux/mfd/rk808.h
> index 78e167a92483..b90d1c278790 100644
> --- a/include/linux/mfd/rk808.h
> +++ b/include/linux/mfd/rk808.h
> @@ -113,6 +113,145 @@ enum rk808_reg {
> #define RK808_INT_STS_MSK_REG2 0x4f
> #define RK808_IO_POL_REG 0x50
>
> +/* RK816 */
> +enum rk816_reg {
> + RK816_ID_DCDC1,
> + RK816_ID_DCDC2,
> + RK816_ID_DCDC3,
> + RK816_ID_DCDC4,
> + RK816_ID_LDO1,
> + RK816_ID_LDO2,
> + RK816_ID_LDO3,
> + RK816_ID_LDO4,
> + RK816_ID_LDO5,
> + RK816_ID_LDO6,
> + RK816_ID_BOOST,
> + RK816_ID_OTG_SW,
> +};
> +
> +enum rk816_irqs {
> + /* INT_STS_REG1 */
> + RK816_IRQ_PWRON_FALL,
> + RK816_IRQ_PWRON_RISE,
> +
> + /* INT_STS_REG2 */
> + RK816_IRQ_VB_LOW,
> + RK816_IRQ_PWRON,
> + RK816_IRQ_PWRON_LP,
> + RK816_IRQ_HOTDIE,
> + RK816_IRQ_RTC_ALARM,
> + RK816_IRQ_RTC_PERIOD,
> + RK816_IRQ_USB_OV,
> +
> + /* INT_STS_REG3 */
> + RK816_IRQ_PLUG_IN,
> + RK816_IRQ_PLUG_OUT,
> + RK816_IRQ_CHG_OK,
> + RK816_IRQ_CHG_TE,
> + RK816_IRQ_CHG_TS,
> + RK816_IRQ_CHG_CVTLIM,
> + RK816_IRQ_DISCHG_ILIM,
> +};
> +
> +/* power channel registers */
> +#define RK816_DCDC_EN_REG1 0x23
> +
> +#define RK816_DCDC_EN_REG2 0x24
> +#define RK816_BOOST_EN BIT(1)
> +#define RK816_OTG_EN BIT(2)
> +#define RK816_BOOST_EN_MSK BIT(5)
> +#define RK816_OTG_EN_MSK BIT(6)
> +#define RK816_BUCK_DVS_CONFIRM BIT(7)
> +
> +#define RK816_LDO_EN_REG1 0x27
> +
> +#define RK816_LDO_EN_REG2 0x28
> +
> +/* interrupt registers and irq definitions */
> +#define RK816_INT_STS_REG1 0x49
> +#define RK816_INT_STS_MSK_REG1 0x4a
> +#define RK816_INT_STS_PWRON_FALL BIT(5)
> +#define RK816_INT_STS_PWRON_RISE BIT(6)
> +
> +#define RK816_INT_STS_REG2 0x4c
> +#define RK816_INT_STS_MSK_REG2 0x4d
> +#define RK816_INT_STS_VB_LOW BIT(1)
> +#define RK816_INT_STS_PWRON BIT(2)
> +#define RK816_INT_STS_PWRON_LP BIT(3)
> +#define RK816_INT_STS_HOTDIE BIT(4)
> +#define RK816_INT_STS_RTC_ALARM BIT(5)
> +#define RK816_INT_STS_RTC_PERIOD BIT(6)
> +#define RK816_INT_STS_USB_OV BIT(7)
> +
> +#define RK816_INT_STS_REG3 0x4e
> +#define RK816_INT_STS_MSK_REG3 0x4f
> +#define RK816_INT_STS_PLUG_IN BIT(0)
> +#define RK816_INT_STS_PLUG_OUT BIT(1)
> +#define RK816_INT_STS_CHG_OK BIT(2)
> +#define RK816_INT_STS_CHG_TE BIT(3)
> +#define RK816_INT_STS_CHG_TS BIT(4)
> +#define RK816_INT_STS_CHG_CVTLIM BIT(6)
> +#define RK816_INT_STS_DISCHG_ILIM BIT(7)
> +
> +/* charger, boost and OTG registers */
> +#define RK816_OTG_BUCK_LDO_CONFIG_REG 0x2a
> +#define RK816_CHRG_CONFIG_REG 0x2b
> +#define RK816_BOOST_ON_VESL_REG 0x54
> +#define RK816_BOOST_SLP_VSEL_REG 0x55
> +#define RK816_CHRG_BOOST_CONFIG_REG 0x9a
> +#define RK816_SUP_STS_REG 0xa0
> +#define RK816_USB_CTRL_REG 0xa1
> +#define RK816_CHRG_CTRL(x) (0xa3 + (x))
> +#define RK816_BAT_CTRL_REG 0xa6
> +#define RK816_BAT_HTS_TS_REG 0xa8
> +#define RK816_BAT_LTS_TS_REG 0xa9
> +
> +/* adc and fuel gauge registers */
> +#define RK816_TS_CTRL_REG 0xac
> +#define RK816_ADC_CTRL_REG 0xad
> +#define RK816_GGCON_REG 0xb0
> +#define RK816_GGSTS_REG 0xb1
> +#define RK816_ZERO_CUR_ADC_REGH 0xb2
> +#define RK816_ZERO_CUR_ADC_REGL 0xb3
> +#define RK816_GASCNT_CAL_REG(x) (0xb7 - (x))
> +#define RK816_GASCNT_REG(x) (0xbb - (x))
> +#define RK816_BAT_CUR_AVG_REGH 0xbc
> +#define RK816_BAT_CUR_AVG_REGL 0xbd
> +#define RK816_TS_ADC_REGH 0xbe
> +#define RK816_TS_ADC_REGL 0xbf
> +#define RK816_USB_ADC_REGH 0xc0
> +#define RK816_USB_ADC_REGL 0xc1
> +#define RK816_BAT_OCV_REGH 0xc2
> +#define RK816_BAT_OCV_REGL 0xc3
> +#define RK816_BAT_VOL_REGH 0xc4
> +#define RK816_BAT_VOL_REGL 0xc5
> +#define RK816_RELAX_ENTRY_THRES_REGH 0xc6
> +#define RK816_RELAX_ENTRY_THRES_REGL 0xc7
> +#define RK816_RELAX_EXIT_THRES_REGH 0xc8
> +#define RK816_RELAX_EXIT_THRES_REGL 0xc9
> +#define RK816_RELAX_VOL1_REGH 0xca
> +#define RK816_RELAX_VOL1_REGL 0xcb
> +#define RK816_RELAX_VOL2_REGH 0xcc
> +#define RK816_RELAX_VOL2_REGL 0xcd
> +#define RK816_RELAX_CUR1_REGH 0xce
> +#define RK816_RELAX_CUR1_REGL 0xcf
> +#define RK816_RELAX_CUR2_REGH 0xd0
> +#define RK816_RELAX_CUR2_REGL 0xd1
> +#define RK816_CAL_OFFSET_REGH 0xd2
> +#define RK816_CAL_OFFSET_REGL 0xd3
> +#define RK816_NON_ACT_TIMER_CNT_REG 0xd4
> +#define RK816_VCALIB0_REGH 0xd5
> +#define RK816_VCALIB0_REGL 0xd6
> +#define RK816_VCALIB1_REGH 0xd7
> +#define RK816_VCALIB1_REGL 0xd8
> +#define RK816_FCC_GASCNT_REG(x) (0xdc - (x))
> +#define RK816_IOFFSET_REGH 0xdd
> +#define RK816_IOFFSET_REGL 0xde
> +#define RK816_SLEEP_CON_SAMP_CUR_REG 0xdf
> +
> +/* general purpose data registers 0xe0 ~ 0xf2 */
> +#define RK816_DATA_REG(x) (0xe0 + (x))
> +
> /* RK818 */
> #define RK818_DCDC1 0
> #define RK818_LDO1 4
> @@ -791,6 +930,7 @@ enum rk806_dvs_mode {
> #define VOUT_LO_INT BIT(0)
> #define CLK32KOUT2_EN BIT(0)
>
> +#define TEMP105C 0x08
> #define TEMP115C 0x0c
> #define TEMP_HOTDIE_MSK 0x0c
> #define SLP_SD_MSK (0x3 << 2)
> @@ -1191,6 +1331,7 @@ enum {
> RK806_ID = 0x8060,
> RK808_ID = 0x0000,
> RK809_ID = 0x8090,
> + RK816_ID = 0x8160,
> RK817_ID = 0x8170,
> RK818_ID = 0x8180,
> };
> --
> 2.43.2
>
--
Lee Jones [李琼斯]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v4 03/11] mfd: tps6594: add regmap config in match data
From: Lee Jones @ 2024-03-28 11:37 UTC (permalink / raw)
To: Bhargav Raviprakash
Cc: linux-kernel, m.nirmaladevi, robh+dt, krzysztof.kozlowski+dt,
conor+dt, jpanis, devicetree, arnd, gregkh, lgirdwood, broonie,
linus.walleij, linux-gpio, linux-arm-kernel, nm, vigneshr, kristo,
eblanc
In-Reply-To: <20240320102559.464981-4-bhargav.r@ltts.com>
On Wed, 20 Mar 2024, Bhargav Raviprakash wrote:
> Introduces a new struct tps6594_match_data. This struct holds fields for
> chip id and regmap config. Using this struct in of_device_id data field.
> This helps in adding support for TPS65224 PMIC.
>
> Signed-off-by: Bhargav Raviprakash <bhargav.r@ltts.com>
> Acked-by: Julien Panis <jpanis@baylibre.com>
> ---
> drivers/mfd/tps6594-i2c.c | 24 ++++++++++++++++--------
> drivers/mfd/tps6594-spi.c | 24 ++++++++++++++++--------
> include/linux/mfd/tps6594.h | 11 +++++++++++
> 3 files changed, 43 insertions(+), 16 deletions(-)
Mostly fine, just a couple of nits.
Firstly the subject lines for the entire set are inconsistent.
Please use the style set by the subsystem:
`git log --oneline -- <subsystem>` is your friend.
> diff --git a/drivers/mfd/tps6594-i2c.c b/drivers/mfd/tps6594-i2c.c
> index c125b474b..9e2ed48b7 100644
> --- a/drivers/mfd/tps6594-i2c.c
> +++ b/drivers/mfd/tps6594-i2c.c
> @@ -192,10 +192,16 @@ static const struct regmap_config tps6594_i2c_regmap_config = {
> .write = tps6594_i2c_write,
> };
>
> +static const struct tps6594_match_data match_data[] = {
> + [TPS6594] = {TPS6594, &tps6594_i2c_regmap_config},
> + [TPS6593] = {TPS6593, &tps6594_i2c_regmap_config},
> + [LP8764] = {LP8764, &tps6594_i2c_regmap_config},
Spaces after the '{' and before the '}' please.
> +};
> +
> static const struct of_device_id tps6594_i2c_of_match_table[] = {
> - { .compatible = "ti,tps6594-q1", .data = (void *)TPS6594, },
> - { .compatible = "ti,tps6593-q1", .data = (void *)TPS6593, },
> - { .compatible = "ti,lp8764-q1", .data = (void *)LP8764, },
> + { .compatible = "ti,tps6594-q1", .data = &match_data[TPS6594], },
> + { .compatible = "ti,tps6593-q1", .data = &match_data[TPS6593], },
> + { .compatible = "ti,lp8764-q1", .data = &match_data[LP8764], },
> {}
> };
> MODULE_DEVICE_TABLE(of, tps6594_i2c_of_match_table);
> @@ -205,6 +211,7 @@ static int tps6594_i2c_probe(struct i2c_client *client)
> struct device *dev = &client->dev;
> struct tps6594 *tps;
> const struct of_device_id *match;
> + const struct tps6594_match_data *mdata;
>
> tps = devm_kzalloc(dev, sizeof(*tps), GFP_KERNEL);
> if (!tps)
> @@ -216,14 +223,15 @@ static int tps6594_i2c_probe(struct i2c_client *client)
> tps->reg = client->addr;
> tps->irq = client->irq;
>
> - tps->regmap = devm_regmap_init(dev, NULL, client, &tps6594_i2c_regmap_config);
> - if (IS_ERR(tps->regmap))
> - return dev_err_probe(dev, PTR_ERR(tps->regmap), "Failed to init regmap\n");
> -
> match = of_match_device(tps6594_i2c_of_match_table, dev);
> if (!match)
> return dev_err_probe(dev, -EINVAL, "Failed to find matching chip ID\n");
> - tps->chip_id = (unsigned long)match->data;
> + mdata = (struct tps6594_match_data *)match->data;
What happens when you drop this case?
I was under the impression this was not required when casting from (void *)
> + tps->chip_id = mdata->chip_id;
> +
> + tps->regmap = devm_regmap_init(dev, NULL, client, mdata->config);
> + if (IS_ERR(tps->regmap))
> + return dev_err_probe(dev, PTR_ERR(tps->regmap), "Failed to init regmap\n");
"initialise"
>
> crc8_populate_msb(tps6594_i2c_crc_table, TPS6594_CRC8_POLYNOMIAL);
>
> diff --git a/drivers/mfd/tps6594-spi.c b/drivers/mfd/tps6594-spi.c
> index 5afb1736f..82a1c02e3 100644
> --- a/drivers/mfd/tps6594-spi.c
> +++ b/drivers/mfd/tps6594-spi.c
> @@ -77,10 +77,16 @@ static const struct regmap_config tps6594_spi_regmap_config = {
> .use_single_write = true,
> };
>
> +static const struct tps6594_match_data match_data[] = {
> + [TPS6594] = {TPS6594, &tps6594_spi_regmap_config},
> + [TPS6593] = {TPS6593, &tps6594_spi_regmap_config},
> + [LP8764] = {LP8764, &tps6594_spi_regmap_config},
As above.
> +};
> +
> static const struct of_device_id tps6594_spi_of_match_table[] = {
> - { .compatible = "ti,tps6594-q1", .data = (void *)TPS6594, },
> - { .compatible = "ti,tps6593-q1", .data = (void *)TPS6593, },
> - { .compatible = "ti,lp8764-q1", .data = (void *)LP8764, },
> + { .compatible = "ti,tps6594-q1", .data = &match_data[TPS6594], },
> + { .compatible = "ti,tps6593-q1", .data = &match_data[TPS6593], },
> + { .compatible = "ti,lp8764-q1", .data = &match_data[LP8764], },
> {}
> };
> MODULE_DEVICE_TABLE(of, tps6594_spi_of_match_table);
> @@ -90,6 +96,7 @@ static int tps6594_spi_probe(struct spi_device *spi)
> struct device *dev = &spi->dev;
> struct tps6594 *tps;
> const struct of_device_id *match;
> + const struct tps6594_match_data *mdata;
>
> tps = devm_kzalloc(dev, sizeof(*tps), GFP_KERNEL);
> if (!tps)
> @@ -101,14 +108,15 @@ static int tps6594_spi_probe(struct spi_device *spi)
> tps->reg = spi_get_chipselect(spi, 0);
> tps->irq = spi->irq;
>
> - tps->regmap = devm_regmap_init(dev, NULL, spi, &tps6594_spi_regmap_config);
> - if (IS_ERR(tps->regmap))
> - return dev_err_probe(dev, PTR_ERR(tps->regmap), "Failed to init regmap\n");
> -
> match = of_match_device(tps6594_spi_of_match_table, dev);
> if (!match)
> return dev_err_probe(dev, -EINVAL, "Failed to find matching chip ID\n");
> - tps->chip_id = (unsigned long)match->data;
> + mdata = (struct tps6594_match_data *)match->data;
> + tps->chip_id = mdata->chip_id;
> +
> + tps->regmap = devm_regmap_init(dev, NULL, spi, mdata->config);
> + if (IS_ERR(tps->regmap))
> + return dev_err_probe(dev, PTR_ERR(tps->regmap), "Failed to init regmap\n");
>
> crc8_populate_msb(tps6594_spi_crc_table, TPS6594_CRC8_POLYNOMIAL);
>
> diff --git a/include/linux/mfd/tps6594.h b/include/linux/mfd/tps6594.h
> index 16543fd4d..d781e0fe3 100644
> --- a/include/linux/mfd/tps6594.h
> +++ b/include/linux/mfd/tps6594.h
> @@ -1337,6 +1337,17 @@ struct tps6594 {
> struct regmap_irq_chip_data *irq_data;
> };
>
> +/**
> + * struct tps6594_match_data - of match data of PMIC
> + *
> + * @chip_id: chip ID of PMIC
> + * @config: regmap config of PMIC
> + */
> +struct tps6594_match_data {
> + unsigned long chip_id;
> + const struct regmap_config *config;
> +};
> +
> extern const struct regmap_access_table tps6594_volatile_table;
> extern const struct regmap_access_table tps65224_volatile_table;
>
> --
> 2.25.1
>
--
Lee Jones [李琼斯]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 3/3] clk: samsung: gs101: propagate PERIC0 USI SPI clock rate
From: Peter Griffin @ 2024-03-28 11:36 UTC (permalink / raw)
To: Tudor Ambarus
Cc: krzysztof.kozlowski, alim.akhtar, linux-arm-kernel,
linux-samsung-soc, linux-kernel, andre.draszik, willmcvicker,
kernel-team, s.nawrocki, cw00.choi, mturquette, sboyd,
semen.protsenko, linux-clk, jaewon02.kim
In-Reply-To: <20240326172813.801470-4-tudor.ambarus@linaro.org>
Hi Tudor,
On Tue, 26 Mar 2024 at 17:28, Tudor Ambarus <tudor.ambarus@linaro.org> wrote:
>
> When SPI transfer is being prepared, the spi-s3c64xx driver will call
> clk_set_rate() to change the rate of SPI source clock (IPCLK). But IPCLK
> is a gate (leaf) clock, so it must propagate the rate change up the
> clock tree, so that corresponding MUX/DIV clocks can actually change
> their values. Add CLK_SET_RATE_PARENT flag to corresponding clocks for
> all USI instances in GS101 PERIC0: USI{1-8, 14}. This change involves the
> following clocks:
>
> PERIC0 USI*:
>
> Clock Div range MUX Selection
> -------------------------------------------------------------------
> gout_peric0_peric0_top0_ipclk_* - -
> dout_peric0_usi*_usi /1..16 -
> mout_peric0_usi*_usi_user - {24.5 MHz, 400 MHz}
>
> With input clock of 400 MHz this scheme provides the following IPCLK
> rate range, for each USI block:
>
> PERIC0 USI*: 1.5 MHz ... 400 MHz
>
> Accounting for internal /4 divider in SPI blocks, and because the max
> SPI frequency is limited at 50 MHz, it gives us next SPI SCK rates:
>
> PERIC0 USI_SPI*: 384 KHz ... 49.9 MHz
>
> Which shall be fine for the applications of the SPI bus.
>
> Note that with this we allow the reparenting of the MUX_USIx clocks to
> OSCCLK. Each instance of the USI IP has its own MUX_USI clock, thus the
> reparenting of a MUX_USI clock corresponds to a single instance of the
> USI IP. The datasheet mentions OSCCLK just in the low-power mode
> context, but the downstream driver reparents too the MUX_USI clocks to
> OSCCLK. Follow the downstream driver and do the same.
>
> Fixes: 893f133a040b ("clk: samsung: gs101: add support for cmu_peric0")
> Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
> ---
Reviewed-by: Peter Griffin <peter.griffin@linaro.org>
regards,
Peter
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 3/4] arm64: dts: exynos: gs101: join lines close to 80 chars
From: Peter Griffin @ 2024-03-28 11:34 UTC (permalink / raw)
To: Tudor Ambarus
Cc: robh+dt, krzysztof.kozlowski+dt, conor+dt, alim.akhtar,
linux-arm-kernel, linux-samsung-soc, devicetree, linux-kernel,
andre.draszik, willmcvicker, kernel-team
In-Reply-To: <20240326103620.298298-4-tudor.ambarus@linaro.org>
Hi Tudor,
On Tue, 26 Mar 2024 at 10:36, Tudor Ambarus <tudor.ambarus@linaro.org> wrote:
>
> These lines fit 81 characters, which is pretty close to 80.
> Join the lines.
>
> Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
> ---
Reviewed-by: Peter Griffin <peter.griffin@linaro.org>
> arch/arm64/boot/dts/exynos/google/gs101.dtsi | 12 ++++--------
> 1 file changed, 4 insertions(+), 8 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/exynos/google/gs101.dtsi b/arch/arm64/boot/dts/exynos/google/gs101.dtsi
> index cfb3ddc7f885..690deca37e4f 100644
> --- a/arch/arm64/boot/dts/exynos/google/gs101.dtsi
> +++ b/arch/arm64/boot/dts/exynos/google/gs101.dtsi
> @@ -374,8 +374,7 @@ pinctrl_peric0: pinctrl@10840000 {
> };
>
> usi8: usi@109700c0 {
> - compatible = "google,gs101-usi",
> - "samsung,exynos850-usi";
> + compatible = "google,gs101-usi", "samsung,exynos850-usi";
> reg = <0x109700c0 0x20>;
> ranges;
> #address-cells = <1>;
> @@ -403,8 +402,7 @@ hsi2c_8: i2c@10970000 {
> };
>
> usi_uart: usi@10a000c0 {
> - compatible = "google,gs101-usi",
> - "samsung,exynos850-usi";
> + compatible = "google,gs101-usi", "samsung,exynos850-usi";
> reg = <0x10a000c0 0x20>;
> ranges;
> #address-cells = <1>;
> @@ -419,8 +417,7 @@ usi_uart: usi@10a000c0 {
> serial_0: serial@10a00000 {
> compatible = "google,gs101-uart";
> reg = <0x10a00000 0xc0>;
> - interrupts = <GIC_SPI 634
> - IRQ_TYPE_LEVEL_HIGH 0>;
> + interrupts = <GIC_SPI 634 IRQ_TYPE_LEVEL_HIGH 0>;
> clocks = <&cmu_peric0 CLK_GOUT_PERIC0_PERIC0_TOP1_PCLK_0>,
> <&cmu_peric0 CLK_GOUT_PERIC0_PERIC0_TOP1_IPCLK_0>;
> clock-names = "uart", "clk_uart_baud0";
> @@ -454,8 +451,7 @@ pinctrl_peric1: pinctrl@10c40000 {
> };
>
> usi12: usi@10d500c0 {
> - compatible = "google,gs101-usi",
> - "samsung,exynos850-usi";
> + compatible = "google,gs101-usi", "samsung,exynos850-usi";
> reg = <0x10d500c0 0x20>;
> ranges;
> #address-cells = <1>;
> --
> 2.44.0.396.g6e790dbe36-goog
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 2/3] clk: samsung: gs101: propagate PERIC1 USI SPI clock rate
From: Peter Griffin @ 2024-03-28 11:33 UTC (permalink / raw)
To: Tudor Ambarus
Cc: krzysztof.kozlowski, alim.akhtar, linux-arm-kernel,
linux-samsung-soc, linux-kernel, andre.draszik, willmcvicker,
kernel-team, s.nawrocki, cw00.choi, mturquette, sboyd,
semen.protsenko, linux-clk, jaewon02.kim
In-Reply-To: <20240326172813.801470-3-tudor.ambarus@linaro.org>
Hi Tudor,
On Tue, 26 Mar 2024 at 17:28, Tudor Ambarus <tudor.ambarus@linaro.org> wrote:
>
> When SPI transfer is being prepared, the spi-s3c64xx driver will call
> clk_set_rate() to change the rate of SPI source clock (IPCLK). But IPCLK
> is a gate (leaf) clock, so it must propagate the rate change up the
> clock tree, so that corresponding MUX/DIV clocks can actually change
> their values. Add CLK_SET_RATE_PARENT flag to corresponding clocks for
> all USI instances in GS101 PERIC1: USI{0, 9, 10, 11, 12, 13}. This change
> involves the following clocks:
>
> PERIC1 USI*:
>
> Clock Div range MUX Selection
> -------------------------------------------------------------------
> gout_peric1_peric1_top0_ipclk_* - -
> dout_peric1_usi*_usi /1..16 -
> mout_peric1_usi*_usi_user - {24.5 MHz, 400 MHz}
>
> With input clock of 400 MHz this scheme provides the following IPCLK
> rate range, for each USI block:
>
> PERIC1 USI*: 1.5 MHz ... 400 MHz
>
> Accounting for internal /4 divider in SPI blocks, and because the max
> SPI frequency is limited at 50 MHz, it gives us next SPI SCK rates:
>
> PERIC1 USI_SPI*: 384 KHz ... 49.9 MHz
>
> Which shall be fine for the applications of the SPI bus.
>
> Note that with this we allow the reparenting of the MUX_USIx clocks to
> OSCCLK. Each instance of the USI IP has its own MUX_USI clock, thus the
> reparenting of a MUX_USI clock corresponds to a single instance of the
> USI IP. The datasheet mentions OSCCLK just in the low-power mode
> context, but the downstream driver reparents too the MUX_USI clocks to
> OSCCLK. Follow the downstream driver and do the same.
>
> Fixes: 63b4bd1259d9 ("clk: samsung: gs101: add support for cmu_peric1")
> Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
> ---
Thanks Tudor for looking into this! I agree with the approach outlined above.
Given that
1) Samsung engineers OK'd it
2) Downstream clock driver does it (and also has other features
enabled like automatic clock gating enabled, which implies it should
not cause any issues there if we enable it in the future upstream).
3) We don't want to change clock frequencies of other IP instances
Reviewed-by: Peter Griffin <peter.griffin@linaro.org>
> drivers/clk/samsung/clk-gs101.c | 90 ++++++++++++++++++---------------
> 1 file changed, 48 insertions(+), 42 deletions(-)
>
> diff --git a/drivers/clk/samsung/clk-gs101.c b/drivers/clk/samsung/clk-gs101.c
> index d065e343a85d..ddf2d57eed68 100644
> --- a/drivers/clk/samsung/clk-gs101.c
> +++ b/drivers/clk/samsung/clk-gs101.c
> @@ -3230,47 +3230,53 @@ static const struct samsung_mux_clock peric1_mux_clks[] __initconst = {
> MUX(CLK_MOUT_PERIC1_I3C_USER,
> "mout_peric1_i3c_user", mout_peric1_nonbususer_p,
> PLL_CON0_MUX_CLKCMU_PERIC1_I3C_USER, 4, 1),
> - MUX(CLK_MOUT_PERIC1_USI0_USI_USER,
> - "mout_peric1_usi0_usi_user", mout_peric1_nonbususer_p,
> - PLL_CON0_MUX_CLKCMU_PERIC1_USI0_USI_USER, 4, 1),
> - MUX(CLK_MOUT_PERIC1_USI10_USI_USER,
> - "mout_peric1_usi10_usi_user", mout_peric1_nonbususer_p,
> - PLL_CON0_MUX_CLKCMU_PERIC1_USI10_USI_USER, 4, 1),
> - MUX(CLK_MOUT_PERIC1_USI11_USI_USER,
> - "mout_peric1_usi11_usi_user", mout_peric1_nonbususer_p,
> - PLL_CON0_MUX_CLKCMU_PERIC1_USI11_USI_USER, 4, 1),
> - MUX(CLK_MOUT_PERIC1_USI12_USI_USER,
> - "mout_peric1_usi12_usi_user", mout_peric1_nonbususer_p,
> - PLL_CON0_MUX_CLKCMU_PERIC1_USI12_USI_USER, 4, 1),
> - MUX(CLK_MOUT_PERIC1_USI13_USI_USER,
> - "mout_peric1_usi13_usi_user", mout_peric1_nonbususer_p,
> - PLL_CON0_MUX_CLKCMU_PERIC1_USI13_USI_USER, 4, 1),
> - MUX(CLK_MOUT_PERIC1_USI9_USI_USER,
> - "mout_peric1_usi9_usi_user", mout_peric1_nonbususer_p,
> - PLL_CON0_MUX_CLKCMU_PERIC1_USI9_USI_USER, 4, 1),
> + nMUX(CLK_MOUT_PERIC1_USI0_USI_USER,
> + "mout_peric1_usi0_usi_user", mout_peric1_nonbususer_p,
> + PLL_CON0_MUX_CLKCMU_PERIC1_USI0_USI_USER, 4, 1),
> + nMUX(CLK_MOUT_PERIC1_USI10_USI_USER,
> + "mout_peric1_usi10_usi_user", mout_peric1_nonbususer_p,
> + PLL_CON0_MUX_CLKCMU_PERIC1_USI10_USI_USER, 4, 1),
> + nMUX(CLK_MOUT_PERIC1_USI11_USI_USER,
> + "mout_peric1_usi11_usi_user", mout_peric1_nonbususer_p,
> + PLL_CON0_MUX_CLKCMU_PERIC1_USI11_USI_USER, 4, 1),
> + nMUX(CLK_MOUT_PERIC1_USI12_USI_USER,
> + "mout_peric1_usi12_usi_user", mout_peric1_nonbususer_p,
> + PLL_CON0_MUX_CLKCMU_PERIC1_USI12_USI_USER, 4, 1),
> + nMUX(CLK_MOUT_PERIC1_USI13_USI_USER,
> + "mout_peric1_usi13_usi_user", mout_peric1_nonbususer_p,
> + PLL_CON0_MUX_CLKCMU_PERIC1_USI13_USI_USER, 4, 1),
> + nMUX(CLK_MOUT_PERIC1_USI9_USI_USER,
> + "mout_peric1_usi9_usi_user", mout_peric1_nonbususer_p,
> + PLL_CON0_MUX_CLKCMU_PERIC1_USI9_USI_USER, 4, 1),
> };
>
> static const struct samsung_div_clock peric1_div_clks[] __initconst = {
> DIV(CLK_DOUT_PERIC1_I3C, "dout_peric1_i3c", "mout_peric1_i3c_user",
> CLK_CON_DIV_DIV_CLK_PERIC1_I3C, 0, 4),
> - DIV(CLK_DOUT_PERIC1_USI0_USI,
> - "dout_peric1_usi0_usi", "mout_peric1_usi0_usi_user",
> - CLK_CON_DIV_DIV_CLK_PERIC1_USI0_USI, 0, 4),
> - DIV(CLK_DOUT_PERIC1_USI10_USI,
> - "dout_peric1_usi10_usi", "mout_peric1_usi10_usi_user",
> - CLK_CON_DIV_DIV_CLK_PERIC1_USI10_USI, 0, 4),
> - DIV(CLK_DOUT_PERIC1_USI11_USI,
> - "dout_peric1_usi11_usi", "mout_peric1_usi11_usi_user",
> - CLK_CON_DIV_DIV_CLK_PERIC1_USI11_USI, 0, 4),
> - DIV(CLK_DOUT_PERIC1_USI12_USI,
> - "dout_peric1_usi12_usi", "mout_peric1_usi12_usi_user",
> - CLK_CON_DIV_DIV_CLK_PERIC1_USI12_USI, 0, 4),
> - DIV(CLK_DOUT_PERIC1_USI13_USI,
> - "dout_peric1_usi13_usi", "mout_peric1_usi13_usi_user",
> - CLK_CON_DIV_DIV_CLK_PERIC1_USI13_USI, 0, 4),
> - DIV(CLK_DOUT_PERIC1_USI9_USI,
> - "dout_peric1_usi9_usi", "mout_peric1_usi9_usi_user",
> - CLK_CON_DIV_DIV_CLK_PERIC1_USI9_USI, 0, 4),
> + DIV_F(CLK_DOUT_PERIC1_USI0_USI,
> + "dout_peric1_usi0_usi", "mout_peric1_usi0_usi_user",
> + CLK_CON_DIV_DIV_CLK_PERIC1_USI0_USI, 0, 4,
> + CLK_SET_RATE_PARENT, 0),
> + DIV_F(CLK_DOUT_PERIC1_USI10_USI,
> + "dout_peric1_usi10_usi", "mout_peric1_usi10_usi_user",
> + CLK_CON_DIV_DIV_CLK_PERIC1_USI10_USI, 0, 4,
> + CLK_SET_RATE_PARENT, 0),
> + DIV_F(CLK_DOUT_PERIC1_USI11_USI,
> + "dout_peric1_usi11_usi", "mout_peric1_usi11_usi_user",
> + CLK_CON_DIV_DIV_CLK_PERIC1_USI11_USI, 0, 4,
> + CLK_SET_RATE_PARENT, 0),
> + DIV_F(CLK_DOUT_PERIC1_USI12_USI,
> + "dout_peric1_usi12_usi", "mout_peric1_usi12_usi_user",
> + CLK_CON_DIV_DIV_CLK_PERIC1_USI12_USI, 0, 4,
> + CLK_SET_RATE_PARENT, 0),
> + DIV_F(CLK_DOUT_PERIC1_USI13_USI,
> + "dout_peric1_usi13_usi", "mout_peric1_usi13_usi_user",
> + CLK_CON_DIV_DIV_CLK_PERIC1_USI13_USI, 0, 4,
> + CLK_SET_RATE_PARENT, 0),
> + DIV_F(CLK_DOUT_PERIC1_USI9_USI,
> + "dout_peric1_usi9_usi", "mout_peric1_usi9_usi_user",
> + CLK_CON_DIV_DIV_CLK_PERIC1_USI9_USI, 0, 4,
> + CLK_SET_RATE_PARENT, 0),
> };
>
> static const struct samsung_gate_clock peric1_gate_clks[] __initconst = {
> @@ -3305,27 +3311,27 @@ static const struct samsung_gate_clock peric1_gate_clks[] __initconst = {
> GATE(CLK_GOUT_PERIC1_PERIC1_TOP0_IPCLK_1,
> "gout_peric1_peric1_top0_ipclk_1", "dout_peric1_usi0_usi",
> CLK_CON_GAT_GOUT_BLK_PERIC1_UID_PERIC1_TOP0_IPCLKPORT_IPCLK_1,
> - 21, 0, 0),
> + 21, CLK_SET_RATE_PARENT, 0),
> GATE(CLK_GOUT_PERIC1_PERIC1_TOP0_IPCLK_2,
> "gout_peric1_peric1_top0_ipclk_2", "dout_peric1_usi9_usi",
> CLK_CON_GAT_GOUT_BLK_PERIC1_UID_PERIC1_TOP0_IPCLKPORT_IPCLK_2,
> - 21, 0, 0),
> + 21, CLK_SET_RATE_PARENT, 0),
> GATE(CLK_GOUT_PERIC1_PERIC1_TOP0_IPCLK_3,
> "gout_peric1_peric1_top0_ipclk_3", "dout_peric1_usi10_usi",
> CLK_CON_GAT_GOUT_BLK_PERIC1_UID_PERIC1_TOP0_IPCLKPORT_IPCLK_3,
> - 21, 0, 0),
> + 21, CLK_SET_RATE_PARENT, 0),
> GATE(CLK_GOUT_PERIC1_PERIC1_TOP0_IPCLK_4,
> "gout_peric1_peric1_top0_ipclk_4", "dout_peric1_usi11_usi",
> CLK_CON_GAT_GOUT_BLK_PERIC1_UID_PERIC1_TOP0_IPCLKPORT_IPCLK_4,
> - 21, 0, 0),
> + 21, CLK_SET_RATE_PARENT, 0),
> GATE(CLK_GOUT_PERIC1_PERIC1_TOP0_IPCLK_5,
> "gout_peric1_peric1_top0_ipclk_5", "dout_peric1_usi12_usi",
> CLK_CON_GAT_GOUT_BLK_PERIC1_UID_PERIC1_TOP0_IPCLKPORT_IPCLK_5,
> - 21, 0, 0),
> + 21, CLK_SET_RATE_PARENT, 0),
> GATE(CLK_GOUT_PERIC1_PERIC1_TOP0_IPCLK_6,
> "gout_peric1_peric1_top0_ipclk_6", "dout_peric1_usi13_usi",
> CLK_CON_GAT_GOUT_BLK_PERIC1_UID_PERIC1_TOP0_IPCLKPORT_IPCLK_6,
> - 21, 0, 0),
> + 21, CLK_SET_RATE_PARENT, 0),
> GATE(CLK_GOUT_PERIC1_PERIC1_TOP0_IPCLK_8,
> "gout_peric1_peric1_top0_ipclk_8", "dout_peric1_i3c",
> CLK_CON_GAT_GOUT_BLK_PERIC1_UID_PERIC1_TOP0_IPCLKPORT_IPCLK_8,
> --
> 2.44.0.396.g6e790dbe36-goog
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 4/4] dt-bindings: aspeed: Add eSPI controller
From: Manojkiran Eda @ 2024-03-28 11:33 UTC (permalink / raw)
To: Krzysztof Kozlowski, patrick.rudolph, chiawei_wang, ryan_chen,
devicetree, linux-arm-kernel, linux-aspeed, linux-kernel,
linux-mtd
Cc: robh+dt, krzysztof.kozlowski+dt, conor+dt, joel, andrew,
miquel.raynal, richard, vigneshr, jk, openbmc, broonie, linux-spi
In-Reply-To: <f2a487c4-eba3-4a78-9a14-67c8754c8b61@linaro.org>
On 20/03/24 8:14 pm, Krzysztof Kozlowski wrote:
> On 20/03/2024 10:59, Manojkiran Eda wrote:
>>
>> On 19/03/24 3:26 pm, Krzysztof Kozlowski wrote:
>>> On 19/03/2024 10:34, Manojkiran Eda wrote:
>>>> This commit adds the device tree bindings for aspeed eSPI
>>>> controller.
>>>>
>>>> Although aspeed eSPI hardware supports 4 different channels,
>>>> this commit only adds the support for flash channel, the
>>>> bindings for other channels could be upstreamed when the driver
>>>> support for those are added.
>>>>
>>>> Signed-off-by: Manojkiran Eda<manojkiran.eda@gmail.com>
>>>> ---
>>>> .../bindings/soc/aspeed/aspeed,espi.yaml | 94 +++++++++++++++++++
>>>> 1 file changed, 94 insertions(+)
>>>> create mode 100644 Documentation/devicetree/bindings/soc/aspeed/aspeed,espi.yaml
>>>>
>>>> diff --git a/Documentation/devicetree/bindings/soc/aspeed/aspeed,espi.yaml b/Documentation/devicetree/bindings/soc/aspeed/aspeed,espi.yaml
>>>> new file mode 100644
>>>> index 000000000000..3d3ad528e3b3
>>>> --- /dev/null
>>>> +++ b/Documentation/devicetree/bindings/soc/aspeed/aspeed,espi.yaml
>>> Why Rob's comments got ignored?
>>>
>>> This is not a soc component.
>> I did not mean to ignore, i have few reasons listed below that provides
>> information on why i felt this belongs into soc.
>
> soc is dumping ground of things which are purely SoC specific, not
> covered by existing hardware structure in bindings. Maybe indeed this
> does not have any other place, but did you actually look?
>
Yes, i did look at existing hardware bindings, and cannot seem to find
out any other suitable place. I can definitely look again.
> Anyway, please CC SPI maintainers on future submission.
Sure, will add them.
>
>>>
>>>> @@ -0,0 +1,94 @@
>>>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
>>>> +# # Copyright (c) 2024 IBM Corporation.
>>>> +# # Copyright (c) 2021 Aspeed Technology Inc.
>>>> +%YAML 1.2
>>>> +---
>>>> +$id:http://devicetree.org/schemas/soc/aspeed/aspeed,espi.yaml#
>>>> +$schema:http://devicetree.org/meta-schemas/core.yaml#
>>>> +
>>>> +title: Aspeed eSPI Controller
>>>> +
>>>> +maintainers:
>>>> + - Manojkiran Eda<manojkiran.eda@gmail.com>
>>>> + - Patrick Rudolph<patrick.rudolph@9elements.com>
>>>> + - Chia-Wei Wang<chiawei_wang@aspeedtech.com>
>>>> + - Ryan Chen<ryan_chen@aspeedtech.com>
>>>> +
>>>> +description:
>>>> + Aspeed eSPI controller implements a device side eSPI endpoint device
>>>> + supporting the flash channel.
>>> Explain what is eSPI.
>> eSPI is a serial bus interface for client and server platforms that is
>
> Explain in description of the hardware.
Sure, i will add this description in the binding document in the future
submission.
>
>> based on SPI, using the same master and slave topology but operates
>> with a different protocol to meet new requirements. For instance, eSPI
>> uses I/O, or input/output, communication, instead of MOSI/MISO used in
>> SPI. It also includes a transaction layer on top of the SPI protocol,
>> defining packets such as command and response packets that allow both
>> the master and slave to initiate alert and reset signals. eSPI supports
>> communication between Embedded Controller (EC), Baseboard Management
>> Controller (BMC), Super-I/O (SIO) and Port-80 debug cards. I could add
>> this to the commit message as well in the next patchset.
>>>
>>>> +
>>>> +properties:
>>>> + compatible:
>>>> + items:
>>>> + - enum:
>>>> + - aspeed,ast2500-espi
>>>> + - aspeed,ast2600-espi
>>>> + - const: simple-mfd
>>>
>>> That's not simple-mfd. You have driver for this. Drop.
>>>
>>>> + - const: syscon
>>> That's not syscon. Why do you have ranges then? Where is any explanation
>>> of hardware which would justify such combination?
>>>
>>>> +
>>>> + reg:
>>>> + maxItems: 1
>>>> +
>>>> + "#address-cells":
>>>> + const: 1
>>>> +
>>>> + "#size-cells":
>>>> + const: 1
>>>> +
>>>> + ranges: true
>>>> +
>>>> +patternProperties:
>>>> + "^espi-ctrl@[0-9a-f]+$":
>>>> + type: object
>>>> +
>>>> + description: Controls the flash channel of eSPI hardware
>>> That explains nothing. Unless you wanted to use here MTD bindings.
>>>
>>> This binding did not improve much. I don't understand why this is not
>>> SPI (nothing in commit msg, nothing in description), what is eSPI,
>>
>> eSPI uses Peripheral, Virtual Wire, Out of Band, and Flash Access
>> channels to communicate different sets of data.
>
> And what are these channels? What does it mean a "channel"? Is it just
> how you organize transfers and classes of devices? Or some sort of
> addressable instance on the bus?
>
Yes, an espi channel provides a means to allow multiple independent
flows of traffic to share the same physical bus. Each of the channels
has its own dedicated resources such as queue and flow control.
> The channels feel like some sort of software or logical concept, not
> physical. Physical would be endpoint with peripheral. Or flash memory.
A channel is a logical communication pathway or interface between the
chipset and peripheral devices. The concept of channels in the ESPI
protocol helps organize and manage different types of communication
between the chipset and peripherals. Each channel may have its own set
of protocols, data transfer rates, and supported features, tailored to
the requirements of the devices it serves.
> How do they fit here?
I am not sure I understand, can you please elaborate ?
>>
>> * The *Peripheral* Channel is used for communication between eSPI host
>> bridge located on the master side and eSPI endpoints located on the
>> slave side. LPC Host and LPC Peripherals are an example of eSPI host
>> bridge and eSPI endpoints respectively.
>> * *Virtual Wire* Channel: The Virtual Wire channel is used to
>> communicate the state of sideband pins or GPIO tunneled through eSPI
>> as in-band messages. Serial IRQ interrupts are communicated through
>> this channel as in-band messages.
>> * *OOB* Channel: The SMBus packets are tunneled through eSPI as
>> Out-Of-Band (OOB) messages. The whole SMBus packet is embedded
>> inside the eSPI OOB message as data.
>> * *Flash Access* Channel: The Flash Access channel provides a path
>> allowing the flash components to be shared run-time between chipset
>> and the eSPI slaves that require flash accesses such as EC (Embedded
>> Controller) and BMC.
>
> Please make binding complete, so define all of the channels.
I would like to inquire about the rationale behind this request. Based
on previous feedback received from the upstream efforts
[https://lore.kernel.org/openbmc/HK0PR06MB37798462D17443C697433D7191D09@HK0PR06MB3779.apcprd06.prod.outlook.com/],
suggestions were made to model the flash channel by utilizing the mtd
subsystem, the virtual wire channel by utilizing the GPIO subsystem, and
to consider the OOB channel as a type of i2c device, thereby allowing it
to be utilized by the existing in-kernel MCTP subsystem, among others.
My intention was to prioritize upstreaming the flash channel binding,
along with its driver code, before proceeding to address other channels.
I am curious to understand if it is a strict requirement to have the
complete binding upstreamed before addressing the device drivers code.
>
>>
>> Although , eSPI reuses the timing and electrical specification of Serial
>> Peripheral Interface (SPI) but it runs an entirely different protocol to
>> meet a set of different requirements. Which is why i felt probably
>> placing this in soc was a better choice rather than spi. Do you think
>> otherwise ?
>
> soc is dumping ground for things do not fit other places. Are there any
> other buses / IP blocks similar to this one?
>
>
> Best regards,
> Krzysztof
>
Thanks,
Manoj
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 3/3] clk: samsung: gs101: propagate PERIC0 USI SPI clock rate
From: André Draszik @ 2024-03-28 11:25 UTC (permalink / raw)
To: Tudor Ambarus, peter.griffin, krzysztof.kozlowski
Cc: alim.akhtar, linux-arm-kernel, linux-samsung-soc, linux-kernel,
willmcvicker, kernel-team, s.nawrocki, cw00.choi, mturquette,
sboyd, semen.protsenko, linux-clk, jaewon02.kim
In-Reply-To: <20240326172813.801470-4-tudor.ambarus@linaro.org>
On Tue, 2024-03-26 at 17:28 +0000, Tudor Ambarus wrote:
> When SPI transfer is being prepared, the spi-s3c64xx driver will call
> clk_set_rate() to change the rate of SPI source clock (IPCLK). But IPCLK
> is a gate (leaf) clock, so it must propagate the rate change up the
> clock tree, so that corresponding MUX/DIV clocks can actually change
> their values. Add CLK_SET_RATE_PARENT flag to corresponding clocks for
> all USI instances in GS101 PERIC0: USI{1-8, 14}. This change involves the
> following clocks:
>
> PERIC0 USI*:
>
> Clock Div range MUX Selection
> -------------------------------------------------------------------
> gout_peric0_peric0_top0_ipclk_* - -
> dout_peric0_usi*_usi /1..16 -
> mout_peric0_usi*_usi_user - {24.5 MHz, 400 MHz}
>
> With input clock of 400 MHz this scheme provides the following IPCLK
> rate range, for each USI block:
>
> PERIC0 USI*: 1.5 MHz ... 400 MHz
>
> Accounting for internal /4 divider in SPI blocks, and because the max
> SPI frequency is limited at 50 MHz, it gives us next SPI SCK rates:
>
> PERIC0 USI_SPI*: 384 KHz ... 49.9 MHz
>
> Which shall be fine for the applications of the SPI bus.
>
> Note that with this we allow the reparenting of the MUX_USIx clocks to
> OSCCLK. Each instance of the USI IP has its own MUX_USI clock, thus the
> reparenting of a MUX_USI clock corresponds to a single instance of the
> USI IP. The datasheet mentions OSCCLK just in the low-power mode
> context, but the downstream driver reparents too the MUX_USI clocks to
> OSCCLK. Follow the downstream driver and do the same.
>
> Fixes: 893f133a040b ("clk: samsung: gs101: add support for cmu_peric0")
> Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
Acked-by: André Draszik <andre.draszik@linaro.org>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 2/3] clk: samsung: gs101: propagate PERIC1 USI SPI clock rate
From: André Draszik @ 2024-03-28 11:25 UTC (permalink / raw)
To: Tudor Ambarus, peter.griffin, krzysztof.kozlowski
Cc: alim.akhtar, linux-arm-kernel, linux-samsung-soc, linux-kernel,
willmcvicker, kernel-team, s.nawrocki, cw00.choi, mturquette,
sboyd, semen.protsenko, linux-clk, jaewon02.kim
In-Reply-To: <20240326172813.801470-3-tudor.ambarus@linaro.org>
On Tue, 2024-03-26 at 17:28 +0000, Tudor Ambarus wrote:
> When SPI transfer is being prepared, the spi-s3c64xx driver will call
> clk_set_rate() to change the rate of SPI source clock (IPCLK). But IPCLK
> is a gate (leaf) clock, so it must propagate the rate change up the
> clock tree, so that corresponding MUX/DIV clocks can actually change
> their values. Add CLK_SET_RATE_PARENT flag to corresponding clocks for
> all USI instances in GS101 PERIC1: USI{0, 9, 10, 11, 12, 13}. This change
> involves the following clocks:
>
> PERIC1 USI*:
>
> Clock Div range MUX Selection
> -------------------------------------------------------------------
> gout_peric1_peric1_top0_ipclk_* - -
> dout_peric1_usi*_usi /1..16 -
> mout_peric1_usi*_usi_user - {24.5 MHz, 400 MHz}
>
> With input clock of 400 MHz this scheme provides the following IPCLK
> rate range, for each USI block:
>
> PERIC1 USI*: 1.5 MHz ... 400 MHz
>
> Accounting for internal /4 divider in SPI blocks, and because the max
> SPI frequency is limited at 50 MHz, it gives us next SPI SCK rates:
>
> PERIC1 USI_SPI*: 384 KHz ... 49.9 MHz
>
> Which shall be fine for the applications of the SPI bus.
>
> Note that with this we allow the reparenting of the MUX_USIx clocks to
> OSCCLK. Each instance of the USI IP has its own MUX_USI clock, thus the
> reparenting of a MUX_USI clock corresponds to a single instance of the
> USI IP. The datasheet mentions OSCCLK just in the low-power mode
> context, but the downstream driver reparents too the MUX_USI clocks to
> OSCCLK. Follow the downstream driver and do the same.
>
> Fixes: 63b4bd1259d9 ("clk: samsung: gs101: add support for cmu_peric1")
> Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
Acked-by: André Draszik <andre.draszik@linaro.org>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 1/3] clk: samsung: introduce nMUX for MUX clks that can reparented
From: Tudor Ambarus @ 2024-03-28 11:14 UTC (permalink / raw)
To: Krzysztof Kozlowski, peter.griffin
Cc: alim.akhtar, linux-arm-kernel, linux-samsung-soc, linux-kernel,
andre.draszik, willmcvicker, kernel-team, s.nawrocki, cw00.choi,
mturquette, sboyd, semen.protsenko, linux-clk, jaewon02.kim
In-Reply-To: <5af43398-70fc-4598-9453-6a52d758975e@linaro.org>
On 3/28/24 09:56, Krzysztof Kozlowski wrote:
> On 26/03/2024 18:28, Tudor Ambarus wrote:
>> All samsung MUX clocks that are defined with MUX() set the
>> CLK_SET_RATE_NO_REPARENT flag in __MUX(), which prevents MUXes to be
>> reparented during clk_set_rate().
>>
>> Introduce nMUX() for MUX clocks that can be reparented. One user of
>> nMUX() will be GS101. GS101 defines MUX clocks that are dedicated for
>> each instance of an IP (see MUX USI). The reparenting of these MUX clocks
>> will not affect other instances of the same IP or different IPs
>> altogether.
>>
>> Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
>> ---
>> drivers/clk/samsung/clk.h | 20 ++++++++++++++++++++
>> 1 file changed, 20 insertions(+)
>>
>> diff --git a/drivers/clk/samsung/clk.h b/drivers/clk/samsung/clk.h
>> index a70bd7cce39f..01f58b7686db 100644
>> --- a/drivers/clk/samsung/clk.h
>> +++ b/drivers/clk/samsung/clk.h
>> @@ -146,6 +146,26 @@ struct samsung_mux_clock {
>> #define MUX_F(_id, cname, pnames, o, s, w, f, mf) \
>> __MUX(_id, cname, pnames, o, s, w, f, mf)
>>
>> +/* Used by MUX clocks where reparenting is allowed. */
>
> ...where reparenting on clock rate change is allowed
>
> Because otherwise this suggest muxes cannot change :)
Ok.
>
> No need to resend just for this, I can fix it while applying. Still
> waiting for some review, till EOD.
>
Andre' suggested I can avoid defining __nMUX() by removing the
CLK_SET_RATE_NO_REPARENT flag from __MUX() and instead add the flag in
the MUX() and MUX_F() definitions. Something like this:
diff --git a/drivers/clk/samsung/clk.h b/drivers/clk/samsung/clk.h
index a70bd7cce39f..fb06caa71f0a 100644
--- a/drivers/clk/samsung/clk.h
+++ b/drivers/clk/samsung/clk.h
@@ -133,7 +133,7 @@ struct samsung_mux_clock {
.name = cname, \
.parent_names = pnames, \
.num_parents = ARRAY_SIZE(pnames), \
- .flags = (f) | CLK_SET_RATE_NO_REPARENT, \
+ .flags = f, \
.offset = o, \
.shift = s, \
.width = w, \
@@ -141,9 +141,16 @@ struct samsung_mux_clock {
}
#define MUX(_id, cname, pnames, o, s, w) \
- __MUX(_id, cname, pnames, o, s, w, 0, 0)
+ __MUX(_id, cname, pnames, o, s, w, CLK_SET_RATE_NO_REPARENT, 0)
#define MUX_F(_id, cname, pnames, o, s, w, f, mf) \
+ __MUX(_id, cname, pnames, o, s, w, (f) |
CLK_SET_RATE_NO_REPARENT, mf)
+
+/* Used by MUX clocks where reparenting on clock rate change is allowed. */
+#define nMUX(_id, cname, pnames, o, s, w) \
+ __MUX(_id, cname, pnames, o, s, w, 0, 0)
+
+#define nMUX_F(_id, cname, pnames, o, s, w, f, mf) \
__MUX(_id, cname, pnames, o, s, w, f, mf)
I find the suggestion fine. Will submit v3 in a min, addressing all the
comments.
Thanks,
ta
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH net-next v2] net: axienet: Fix kernel doc warnings
From: Suraj Gupta @ 2024-03-28 11:07 UTC (permalink / raw)
To: radhey.shyam.pandey, davem, edumazet, kuba, pabeni, michal.simek,
netdev, linux-arm-kernel
Cc: linux-kernel, git, harini.katakam, suraj.gupta2
Add description of mdio enable, mdio disable and mdio wait functions.
Add description of skb pointer in axidma_bd data structure.
Remove 'phy_node' description in axienet local data structure since
it is not a valid struct member.
Correct description of struct axienet_option.
Fix below kernel-doc warnings in drivers/net/ethernet/xilinx/:
1) xilinx_axienet_mdio.c:1: warning: no structured comments found
2) xilinx_axienet.h:379: warning: Function parameter or struct member
'skb' not described in 'axidma_bd'
3) xilinx_axienet.h:538: warning: Excess struct member 'phy_node'
description in 'axienet_local'
4) xilinx_axienet.h:1002: warning: expecting prototype for struct
axiethernet_option. Prototype was for struct axienet_option instead
Signed-off-by: Suraj Gupta <suraj.gupta2@amd.com>
Reviewed-by: Radhey Shyam Pandey <radhey.shyam.pandey@amd.com>
---
Changes in V2:
Correct alignment of skb struct description in struct axidma_bd.
drivers/net/ethernet/xilinx/xilinx_axienet.h | 4 ++--
.../net/ethernet/xilinx/xilinx_axienet_mdio.c | 23 ++++++++++++++++---
2 files changed, 22 insertions(+), 5 deletions(-)
diff --git a/drivers/net/ethernet/xilinx/xilinx_axienet.h b/drivers/net/ethernet/xilinx/xilinx_axienet.h
index 807ead678551..fa5500decc96 100644
--- a/drivers/net/ethernet/xilinx/xilinx_axienet.h
+++ b/drivers/net/ethernet/xilinx/xilinx_axienet.h
@@ -359,6 +359,7 @@
* @app2: MM2S/S2MM User Application Field 2.
* @app3: MM2S/S2MM User Application Field 3.
* @app4: MM2S/S2MM User Application Field 4.
+ * @skb: Pointer to SKB transferred using DMA
*/
struct axidma_bd {
u32 next; /* Physical address of next buffer descriptor */
@@ -399,7 +400,6 @@ struct skbuf_dma_descriptor {
* struct axienet_local - axienet private per device data
* @ndev: Pointer for net_device to which it will be attached.
* @dev: Pointer to device structure
- * @phy_node: Pointer to device node structure
* @phylink: Pointer to phylink instance
* @phylink_config: phylink configuration settings
* @pcs_phy: Reference to PCS/PMA PHY if used
@@ -537,7 +537,7 @@ struct axienet_local {
};
/**
- * struct axiethernet_option - Used to set axi ethernet hardware options
+ * struct axienet_option - Used to set axi ethernet hardware options
* @opt: Option to be set.
* @reg: Register offset to be written for setting the option
* @m_or: Mask to be ORed for setting the option in the register
diff --git a/drivers/net/ethernet/xilinx/xilinx_axienet_mdio.c b/drivers/net/ethernet/xilinx/xilinx_axienet_mdio.c
index 2f07fde361aa..9ca2643c921e 100644
--- a/drivers/net/ethernet/xilinx/xilinx_axienet_mdio.c
+++ b/drivers/net/ethernet/xilinx/xilinx_axienet_mdio.c
@@ -20,7 +20,14 @@
#define DEFAULT_MDIO_FREQ 2500000 /* 2.5 MHz */
#define DEFAULT_HOST_CLOCK 150000000 /* 150 MHz */
-/* Wait till MDIO interface is ready to accept a new transaction.*/
+/**
+ * axienet_mdio_wait_until_ready - MDIO wait function
+ * @lp: Pointer to axienet local data structure.
+ *
+ * Return : 0 on success, Negative value on errors
+ *
+ * Wait till MDIO interface is ready to accept a new transaction.
+ */
static int axienet_mdio_wait_until_ready(struct axienet_local *lp)
{
u32 val;
@@ -30,14 +37,24 @@ static int axienet_mdio_wait_until_ready(struct axienet_local *lp)
1, 20000);
}
-/* Enable the MDIO MDC. Called prior to a read/write operation */
+/**
+ * axienet_mdio_mdc_enable - MDIO MDC enable function
+ * @lp: Pointer to axienet local data structure.
+ *
+ * Enable the MDIO MDC. Called prior to a read/write operation
+ */
static void axienet_mdio_mdc_enable(struct axienet_local *lp)
{
axienet_iow(lp, XAE_MDIO_MC_OFFSET,
((u32)lp->mii_clk_div | XAE_MDIO_MC_MDIOEN_MASK));
}
-/* Disable the MDIO MDC. Called after a read/write operation*/
+/**
+ * axienet_mdio_mdc_disable - MDIO MDC disable function
+ * @lp: Pointer to axienet local data structure.
+ *
+ * Disable the MDIO MDC. Called after a read/write operation
+ */
static void axienet_mdio_mdc_disable(struct axienet_local *lp)
{
u32 mc_reg;
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH v2 2/3] arch: Remove struct fb_info from video helpers
From: Helge Deller @ 2024-03-28 11:04 UTC (permalink / raw)
To: Thomas Zimmermann, arnd, javierm, sui.jingfeng
Cc: linux-arch, dri-devel, linux-fbdev, sparclinux, linux-sh,
linuxppc-dev, linux-parisc, linux-mips, linux-m68k, loongarch,
linux-arm-kernel, linux-snps-arc, linux-kernel,
James E.J. Bottomley, David S. Miller, Andreas Larsson,
Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen, x86,
H. Peter Anvin
In-Reply-To: <20240327204450.14914-3-tzimmermann@suse.de>
On 3/27/24 21:41, Thomas Zimmermann wrote:
> The per-architecture video helpers do not depend on struct fb_info
> or anything else from fbdev. Remove it from the interface and replace
> fb_is_primary_device() with video_is_primary_device(). The new helper
Since you rename this function, wouldn't something similar to
device_is_primary_display()
or
device_is_primary_console()
or
is_primary_graphics_device()
or
is_primary_display_device()
be a better name?
Helge
> is similar in functionality, but can operate on non-fbdev devices.
>
> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
> Cc: "James E.J. Bottomley" <James.Bottomley@HansenPartnership.com>
> Cc: Helge Deller <deller@gmx.de>
> Cc: "David S. Miller" <davem@davemloft.net>
> Cc: Andreas Larsson <andreas@gaisler.com>
> Cc: Thomas Gleixner <tglx@linutronix.de>
> Cc: Ingo Molnar <mingo@redhat.com>
> Cc: Borislav Petkov <bp@alien8.de>
> Cc: Dave Hansen <dave.hansen@linux.intel.com>
> Cc: x86@kernel.org
> Cc: "H. Peter Anvin" <hpa@zytor.com>
> ---
> arch/parisc/include/asm/fb.h | 8 +++++---
> arch/parisc/video/fbdev.c | 9 +++++----
> arch/sparc/include/asm/fb.h | 7 ++++---
> arch/sparc/video/fbdev.c | 17 ++++++++---------
> arch/x86/include/asm/fb.h | 8 +++++---
> arch/x86/video/fbdev.c | 18 +++++++-----------
> drivers/video/fbdev/core/fbcon.c | 2 +-
> include/asm-generic/fb.h | 11 ++++++-----
> 8 files changed, 41 insertions(+), 39 deletions(-)
>
> diff --git a/arch/parisc/include/asm/fb.h b/arch/parisc/include/asm/fb.h
> index 658a8a7dc5312..ed2a195a3e762 100644
> --- a/arch/parisc/include/asm/fb.h
> +++ b/arch/parisc/include/asm/fb.h
> @@ -2,11 +2,13 @@
> #ifndef _ASM_FB_H_
> #define _ASM_FB_H_
>
> -struct fb_info;
> +#include <linux/types.h>
> +
> +struct device;
>
> #if defined(CONFIG_STI_CORE)
> -int fb_is_primary_device(struct fb_info *info);
> -#define fb_is_primary_device fb_is_primary_device
> +bool video_is_primary_device(struct device *dev);
> +#define video_is_primary_device video_is_primary_device
> #endif
>
> #include <asm-generic/fb.h>
> diff --git a/arch/parisc/video/fbdev.c b/arch/parisc/video/fbdev.c
> index e4f8ac99fc9e0..540fa0c919d59 100644
> --- a/arch/parisc/video/fbdev.c
> +++ b/arch/parisc/video/fbdev.c
> @@ -5,12 +5,13 @@
> * Copyright (C) 2001-2002 Thomas Bogendoerfer <tsbogend@alpha.franken.de>
> */
>
> -#include <linux/fb.h>
> #include <linux/module.h>
>
> #include <video/sticore.h>
>
> -int fb_is_primary_device(struct fb_info *info)
> +#include <asm/fb.h>
> +
> +bool video_is_primary_device(struct device *dev)
> {
> struct sti_struct *sti;
>
> @@ -21,6 +22,6 @@ int fb_is_primary_device(struct fb_info *info)
> return true;
>
> /* return true if it's the default built-in framebuffer driver */
> - return (sti->dev == info->device);
> + return (sti->dev == dev);
> }
> -EXPORT_SYMBOL(fb_is_primary_device);
> +EXPORT_SYMBOL(video_is_primary_device);
> diff --git a/arch/sparc/include/asm/fb.h b/arch/sparc/include/asm/fb.h
> index 24440c0fda490..07f0325d6921c 100644
> --- a/arch/sparc/include/asm/fb.h
> +++ b/arch/sparc/include/asm/fb.h
> @@ -3,10 +3,11 @@
> #define _SPARC_FB_H_
>
> #include <linux/io.h>
> +#include <linux/types.h>
>
> #include <asm/page.h>
>
> -struct fb_info;
> +struct device;
>
> #ifdef CONFIG_SPARC32
> static inline pgprot_t pgprot_framebuffer(pgprot_t prot,
> @@ -18,8 +19,8 @@ static inline pgprot_t pgprot_framebuffer(pgprot_t prot,
> #define pgprot_framebuffer pgprot_framebuffer
> #endif
>
> -int fb_is_primary_device(struct fb_info *info);
> -#define fb_is_primary_device fb_is_primary_device
> +bool video_is_primary_device(struct device *dev);
> +#define video_is_primary_device video_is_primary_device
>
> static inline void fb_memcpy_fromio(void *to, const volatile void __iomem *from, size_t n)
> {
> diff --git a/arch/sparc/video/fbdev.c b/arch/sparc/video/fbdev.c
> index bff66dd1909a4..e46f0499c2774 100644
> --- a/arch/sparc/video/fbdev.c
> +++ b/arch/sparc/video/fbdev.c
> @@ -1,26 +1,25 @@
> // SPDX-License-Identifier: GPL-2.0
>
> #include <linux/console.h>
> -#include <linux/fb.h>
> +#include <linux/device.h>
> #include <linux/module.h>
>
> +#include <asm/fb.h>
> #include <asm/prom.h>
>
> -int fb_is_primary_device(struct fb_info *info)
> +bool video_is_primary_device(struct device *dev)
> {
> - struct device *dev = info->device;
> - struct device_node *node;
> + struct device_node *node = dev->of_node;
>
> if (console_set_on_cmdline)
> - return 0;
> + return false;
>
> - node = dev->of_node;
> if (node && node == of_console_device)
> - return 1;
> + return true;
>
> - return 0;
> + return false;
> }
> -EXPORT_SYMBOL(fb_is_primary_device);
> +EXPORT_SYMBOL(video_is_primary_device);
>
> MODULE_DESCRIPTION("Sparc fbdev helpers");
> MODULE_LICENSE("GPL");
> diff --git a/arch/x86/include/asm/fb.h b/arch/x86/include/asm/fb.h
> index c3b9582de7efd..999db33792869 100644
> --- a/arch/x86/include/asm/fb.h
> +++ b/arch/x86/include/asm/fb.h
> @@ -2,17 +2,19 @@
> #ifndef _ASM_X86_FB_H
> #define _ASM_X86_FB_H
>
> +#include <linux/types.h>
> +
> #include <asm/page.h>
>
> -struct fb_info;
> +struct device;
>
> pgprot_t pgprot_framebuffer(pgprot_t prot,
> unsigned long vm_start, unsigned long vm_end,
> unsigned long offset);
> #define pgprot_framebuffer pgprot_framebuffer
>
> -int fb_is_primary_device(struct fb_info *info);
> -#define fb_is_primary_device fb_is_primary_device
> +bool video_is_primary_device(struct device *dev);
> +#define video_is_primary_device video_is_primary_device
>
> #include <asm-generic/fb.h>
>
> diff --git a/arch/x86/video/fbdev.c b/arch/x86/video/fbdev.c
> index 1dd6528cc947c..4d87ce8e257fe 100644
> --- a/arch/x86/video/fbdev.c
> +++ b/arch/x86/video/fbdev.c
> @@ -7,7 +7,6 @@
> *
> */
>
> -#include <linux/fb.h>
> #include <linux/module.h>
> #include <linux/pci.h>
> #include <linux/vgaarb.h>
> @@ -25,20 +24,17 @@ pgprot_t pgprot_framebuffer(pgprot_t prot,
> }
> EXPORT_SYMBOL(pgprot_framebuffer);
>
> -int fb_is_primary_device(struct fb_info *info)
> +bool video_is_primary_device(struct device *dev)
> {
> - struct device *device = info->device;
> - struct pci_dev *pci_dev;
> + struct pci_dev *pdev;
>
> - if (!device || !dev_is_pci(device))
> - return 0;
> + if (!dev_is_pci(dev))
> + return false;
>
> - pci_dev = to_pci_dev(device);
> + pdev = to_pci_dev(dev);
>
> - if (pci_dev == vga_default_device())
> - return 1;
> - return 0;
> + return (pdev == vga_default_device());
> }
> -EXPORT_SYMBOL(fb_is_primary_device);
> +EXPORT_SYMBOL(video_is_primary_device);
>
> MODULE_LICENSE("GPL");
> diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c
> index 46823c2e2ba12..85c5c8cbc680a 100644
> --- a/drivers/video/fbdev/core/fbcon.c
> +++ b/drivers/video/fbdev/core/fbcon.c
> @@ -2939,7 +2939,7 @@ void fbcon_remap_all(struct fb_info *info)
> static void fbcon_select_primary(struct fb_info *info)
> {
> if (!map_override && primary_device == -1 &&
> - fb_is_primary_device(info)) {
> + video_is_primary_device(info->device)) {
> int i;
>
> printk(KERN_INFO "fbcon: %s (fb%i) is primary device\n",
> diff --git a/include/asm-generic/fb.h b/include/asm-generic/fb.h
> index 6ccabb400aa66..4788c1e1c6bc0 100644
> --- a/include/asm-generic/fb.h
> +++ b/include/asm-generic/fb.h
> @@ -10,8 +10,9 @@
> #include <linux/io.h>
> #include <linux/mm_types.h>
> #include <linux/pgtable.h>
> +#include <linux/types.h>
>
> -struct fb_info;
> +struct device;
>
> #ifndef pgprot_framebuffer
> #define pgprot_framebuffer pgprot_framebuffer
> @@ -23,11 +24,11 @@ static inline pgprot_t pgprot_framebuffer(pgprot_t prot,
> }
> #endif
>
> -#ifndef fb_is_primary_device
> -#define fb_is_primary_device fb_is_primary_device
> -static inline int fb_is_primary_device(struct fb_info *info)
> +#ifndef video_is_primary_device
> +#define video_is_primary_device video_is_primary_device
> +static inline bool video_is_primary_device(struct device *dev)
> {
> - return 0;
> + return false;
> }
> #endif
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v4 10/11] pinctrl: pinctrl-tps6594: Add TPS65224 PMIC pinctrl and GPIO
From: Bhargav Raviprakash @ 2024-03-28 10:35 UTC (permalink / raw)
To: eblanc, jpanis
Cc: arnd, bhargav.r, broonie, conor+dt, devicetree, gregkh, kristo,
krzysztof.kozlowski+dt, lee, lgirdwood, linus.walleij,
linux-arm-kernel, linux-gpio, linux-kernel, m.nirmaladevi, nm,
robh+dt, vigneshr
In-Reply-To: <D00DSDGHFPLU.1MTQNFWP5DF0J@baylibre.com>
Hello,
On Fri, 22 Mar 2024 16:24:07 +0100, Esteban Blanc wrote:
> Hi Bhargav,
>
> LP8764 is not supported but the driver was wrongly instanciated on the
> MFD. For V5 could you:
> - Disable this driver for LD8764.
> - Make sure this driver correctly supports TPS6593
>
> Best Regards,
>
> --
> Esteban "Skallwar" Blanc
> BayLibre
Thanks!
We will make sure the driver properly supports TPS6593.
This issue will be fixed in v5.
Regards,
Bhargav
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: About upstreaming ArmChina NPU driver
From: Sudeep Holla @ 2024-03-28 10:32 UTC (permalink / raw)
To: Dejia Shang
Cc: ogabbay@kernel.org, Sudeep Holla, airlied@redhat.com,
daniel@ffwll.ch, linux-kernel@vger.kernel.org,
dri-devel@lists.freedesktop.org,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <SH0PR01MB063461EBC046437C88A6AE84983BA@SH0PR01MB0634.CHNPR01.prod.partner.outlook.cn>
On Thu, Mar 28, 2024 at 07:46:01AM +0000, Dejia Shang wrote:
> IMPORTANT NOTICE: The contents of this email and any attachments may be privileged and confidential. If you are not the intended recipient, please delete the email immediately. It is strictly prohibited to disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. ©Arm Technology (China) Co., Ltd copyright and reserve all rights. 重要提示：本邮件（包括任何附件）可能含有专供明确的个人或目的使用的机密信息，并受法律保护。如果您并非该收件人，请立即删除此邮件。严禁通过任何渠道，以任何目的，向任何人披露、储存或复制邮件信息或者据此采取任何行动。感谢您的配合。 ©安谋科技（中国）有限公司 版权所有并保留一切权利。
You need to get this fixed, otherwise people will delete this email
as you have suggested and/or refrain from responding to this email.
Please talk to your local IT and get a setup without this disclaimer for
all mailing list activities.
--
Regards,
Sudeep
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2] KVM: arm64: Add KVM_CAP to control WFx trapping
From: Quentin Perret @ 2024-03-28 10:30 UTC (permalink / raw)
To: Colton Lewis
Cc: kvm, maz, oliver.upton, james.morse, suzuki.poulose, yuzenghui,
catalin.marinas, will, pbonzini, mingo, peterz, juri.lelli,
vincent.guittot, dietmar.eggemann, rostedt, bsegall, mgorman,
bristot, vschneid, linux-arm-kernel, kvmarm, linux-kernel
In-Reply-To: <gsntjzlqax63.fsf@coltonlewis-kvm.c.googlers.com>
Hi Colton,
On Monday 25 Mar 2024 at 20:12:04 (+0000), Colton Lewis wrote:
> Thanks for the feedback.
>
> Quentin Perret <qperret@google.com> writes:
>
> > On Friday 22 Mar 2024 at 14:24:35 (+0000), Quentin Perret wrote:
> > > On Tuesday 19 Mar 2024 at 16:43:41 (+0000), Colton Lewis wrote:
> > > > Add a KVM_CAP to control WFx (WFI or WFE) trapping based on scheduler
> > > > runqueue depth. This is so they can be passed through if the runqueue
> > > > is shallow or the CPU has support for direct interrupt injection. They
> > > > may be always trapped by setting this value to 0. Technically this
> > > > means traps will be cleared when the runqueue depth is 0, but that
> > > > implies nothing is running anyway so there is no reason to care. The
> > > > default value is 1 to preserve previous behavior before adding this
> > > > option.
>
> > > I recently discovered that this was enabled by default, but it's not
> > > obvious to me everyone will want this enabled, so I'm in favour of
> > > figuring out a way to turn it off (in fact we might want to make this
> > > feature opt in as the status quo used to be to always trap).
>
> Setting the introduced threshold to zero will cause it to trap whenever
> something is running. Is there a problem with doing it that way?
No problem per se, I was simply hoping we could set the default to zero
to revert to the old behaviour. I don't think removing WFx traps was a
universally desirable behaviour, so it prob should have been opt-in from
the start.
> I'd also be interested to get more input before changing the current
> default behavior.
Ack, that is my personal opinion.
> > > There are a few potential issues I see with having this enabled:
>
> > > - a lone vcpu thread on a CPU will completely screw up the host
> > > scheduler's load tracking metrics if the vCPU actually spends a
> > > significant amount of time in WFI (the PELT signal will no longer
> > > be a good proxy for "how much CPU time does this task need");
>
> > > - the scheduler's decision will impact massively the behaviour of the
> > > vcpu task itself. Co-scheduling a task with a vcpu task (or not) will
> > > impact massively the perceived behaviour of the vcpu task in a way
> > > that is entirely unpredictable to the scheduler;
>
> > > - while the above problems might be OK for some users, I don't think
> > > this will always be true, e.g. when running on big.LITTLE systems the
> > > above sounds nightmare-ish;
>
> > > - the guest spending long periods of time in WFI prevents the host from
> > > being able to enter deeper idle states, which will impact power very
> > > negatively;
>
> > > And probably a whole bunch of other things.
>
> > > > Think about his option as a threshold. The instruction will be trapped
> > > > if the runqueue depth is higher than the threshold.
>
> > > So talking about the exact interface, I'm not sure exposing this to
> > > userspace is really appropriate. The current rq depth is next to
> > > impossible for userspace to control well.
>
> Using runqueue depth is going off of a suggestion from Oliver [1], who I've
> also talked to internally at Google a few times about this.
>
> But hearing your comment makes me lean more towards having some
> enumeration of behaviors like TRAP_ALWAYS, TRAP_NEVER,
> TRAP_IF_MULTIPLE_TASKS.
Do you guys really expect to set this TRAP_IF_MULTIPLE_TASKS? Again, the
rq depth is quite hard to reason about from userspace, so not sure
anybody will really want that? A simpler on/off thing might be simpler.
> > > My gut feeling tells me we might want to gate all of this on
> > > PREEMPT_FULL instead, since PREEMPT_FULL is pretty much a way to say
> > > "I'm willing to give up scheduler tracking accuracy to gain throughput
> > > when I've got a task running alone on a CPU". Thoughts?
>
> > And obviously I meant s/PREEMPT_FULL/NOHZ_FULL, but hopefully that was
> > clear :-)
>
> Sounds good to me but I've not touched anything scheduling related before.
Do you guys use NOHZ_FULL in prod? If not that idea might very well be a
non-starter, because switching to NOHZ_FULL would be a big ask. So,
yeah, I'm curious :)
Thanks,
Quentin
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v4 10/11] pinctrl: pinctrl-tps6594: Add TPS65224 PMIC pinctrl and GPIO
From: Bhargav Raviprakash @ 2024-03-28 10:27 UTC (permalink / raw)
To: eblanc
Cc: arnd, bhargav.r, broonie, conor+dt, devicetree, gregkh, jpanis,
kristo, krzysztof.kozlowski+dt, lee, lgirdwood, linus.walleij,
linux-arm-kernel, linux-gpio, linux-kernel, m.nirmaladevi, nm,
robh+dt, vigneshr
In-Reply-To: <D00EM8TTYGXL.3MMIBWJT03M5R@baylibre.com>
Hi,
On Fri, 22 Mar 2024 17:03:08 +0100, Esteban Blanc wrote:
> On Wed Mar 20, 2024 at 11:25 AM CET, Bhargav Raviprakash wrote:
> > From: Nirmala Devi Mal Nadar <m.nirmaladevi@ltts.com>
> >
> > Add support for TPS65224 pinctrl and GPIOs to TPS6594 driver as they have
> > significant functional overlap.
> > TPS65224 PMIC has 6 GPIOS which can be configured as GPIO or other
> > dedicated device functions.
> >
> > Signed-off-by: Nirmala Devi Mal Nadar <m.nirmaladevi@ltts.com>
> > Signed-off-by: Bhargav Raviprakash <bhargav.r@ltts.com>
> > Acked-by: Linus Walleij <linus.walleij@linaro.org>
> > ---
> > drivers/pinctrl/pinctrl-tps6594.c | 258 +++++++++++++++++++++++++-----
> > 1 file changed, 215 insertions(+), 43 deletions(-)
> >
> > diff --git a/drivers/pinctrl/pinctrl-tps6594.c b/drivers/pinctrl/pinctrl-tps6594.c
> > index 66985e54b..db0f5d2a8 100644
> > --- a/drivers/pinctrl/pinctrl-tps6594.c
> > +++ b/drivers/pinctrl/pinctrl-tps6594.c
> > @@ -320,8 +451,18 @@ static int tps6594_pinctrl_probe(struct platform_device *pdev)
> > return -ENOMEM;
> > pctrl_desc->name = dev_name(dev);
> > pctrl_desc->owner = THIS_MODULE;
> > - pctrl_desc->pins = tps6594_pins;
> > - pctrl_desc->npins = ARRAY_SIZE(tps6594_pins);
> > + switch (tps->chip_id) {
> > + case TPS65224:
> > + pctrl_desc->pins = tps65224_pins;
> > + pctrl_desc->npins = ARRAY_SIZE(tps65224_pins);
> > + break;
> > + case TPS6594:
> > + pctrl_desc->pins = tps6594_pins;
> > + pctrl_desc->npins = ARRAY_SIZE(tps6594_pins);
> > + break;
> > + default:
> > + break;
> > + }
> > pctrl_desc->pctlops = &tps6594_pctrl_ops;
> > pctrl_desc->pmxops = &tps6594_pmx_ops;
>
> See below.
>
> > @@ -329,8 +470,28 @@ static int tps6594_pinctrl_probe(struct platform_device *pdev)
> > if (!pinctrl)
> > return -ENOMEM;
> > pinctrl->tps = dev_get_drvdata(dev->parent);
> > - pinctrl->funcs = pinctrl_functions;
> > - pinctrl->pins = tps6594_pins;
> > + switch (pinctrl->tps->chip_id) {
>
> You could use tps->chip_id like in the previous switch.
>
> > + case TPS65224:
> > + pinctrl->funcs = tps65224_pinctrl_functions;
> > + pinctrl->func_cnt = ARRAY_SIZE(tps65224_pinctrl_functions);
> > + pinctrl->pins = tps65224_pins;
> > + pinctrl->num_pins = ARRAY_SIZE(tps65224_pins);
> > + pinctrl->mux_sel_mask = TPS65224_MASK_GPIO_SEL;
> > + pinctrl->remap = tps65224_muxval_remap;
> > + pinctrl->remap_cnt = ARRAY_SIZE(tps65224_muxval_remap);
> > + break;
> > + case TPS6594:
> > + pinctrl->funcs = pinctrl_functions;
>
> This should be tps6594_pinctrl_functions
>
> > + pinctrl->func_cnt = ARRAY_SIZE(pinctrl_functions);
> > + pinctrl->pins = tps6594_pins;
> > + pinctrl->num_pins = ARRAY_SIZE(tps6594_pins);
> > + pinctrl->mux_sel_mask = TPS6594_MASK_GPIO_SEL;
> > + pinctrl->remap = tps6594_muxval_remap;
> > + pinctrl->remap_cnt = ARRAY_SIZE(tps6594_muxval_remap);
> > + break;
> > + default:
> > + break;
> > + }
>
> See blow.
>
> > pinctrl->pctl_dev = devm_pinctrl_register(dev, pctrl_desc, pinctrl);
> > if (IS_ERR(pinctrl->pctl_dev))
> > return dev_err_probe(dev, PTR_ERR(pinctrl->pctl_dev),
> > @@ -338,8 +499,18 @@ static int tps6594_pinctrl_probe(struct platform_device *pdev)
> >
> > config.parent = tps->dev;
> > config.regmap = tps->regmap;
> > - config.ngpio = TPS6594_PINCTRL_PINS_NB;
> > - config.ngpio_per_reg = 8;
> > + switch (pinctrl->tps->chip_id) {
>
> Same here, use tps->chip_id
>
Sure, will do!
> > + case TPS65224:
> > + config.ngpio = ARRAY_SIZE(tps65224_gpio_func_group_names);
> > + config.ngpio_per_reg = TPS65224_NGPIO_PER_REG;
> > + break;
> > + case TPS6594:
> > + config.ngpio = ARRAY_SIZE(tps6594_gpio_func_group_names);
> > + config.ngpio_per_reg = TPS6594_NGPIO_PER_REG;
> > + break;
> > + default:
> > + break;
> > + }
> > config.reg_dat_base = TPS6594_REG_GPIO_IN_1;
> > config.reg_set_base = TPS6594_REG_GPIO_OUT_1;
> > config.reg_dir_out_base = TPS6594_REG_GPIOX_CONF(0);
>
> Regarding all the switch case, they should be use to set all the struct
> fields that are known at runtime only. For example, pinctrl->funcs, and
> pinctrl->func_cnt are known at compile time. You should create template
> structs, one for TPS6594 the other TPS65224, initialise the allocated
> struct with the template and then fill the remaining fields with the
> runtime values. Something like this:
>
> ```c
> struct test {
> int a;
> int *b;
> };
>
> static struct test template = {
> .a = 42,
> };
>
> int main(void) {
> struct test *test = malloc(sizeof(*test));
> *test = sample;
> test->b = NULL;
>
> return 0;
> }
> ```
>
> You could also try to reduce the number of switch case, there is no good
> reason to have 2 switch instead of one for pctrl_desc and pinctrl
> structs.
>
> Best regards,
>
> --
> Esteban "Skallwar" Blanc
> BayLibre
Thank you for bringing these issues to our attention.
We will follow the template struct way as suggested and also try to reduce the number of switch
cases. These changes will be available in the next version.
Regards,
Bhargav
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v4 09/11] regulator: tps6594-regulator: Add TI TPS65224 PMIC regulators
From: Bhargav Raviprakash @ 2024-03-28 10:16 UTC (permalink / raw)
To: broonie
Cc: arnd, bhargav.r, conor+dt, devicetree, eblanc, gregkh, jpanis,
kristo, krzysztof.kozlowski+dt, lee, lgirdwood, linus.walleij,
linux-arm-kernel, linux-gpio, linux-kernel, m.nirmaladevi, nm,
robh+dt, vigneshr
In-Reply-To: <a3ec3c14-eed3-429d-b3f6-0764bcfb8dc4@sirena.org.uk>
Hi,
On Wed, 20 Mar 2024 16:38:20 +0000, Mark Brown wrote:
> On Wed, Mar 20, 2024 at 03:55:57PM +0530, Bhargav Raviprakash wrote:
>
> > +static struct tps6594_regulator_irq_type tps65224_buck1_irq_types[] = {
> > + { TPS65224_IRQ_NAME_BUCK1_UVOV, "BUCK1", "voltage out of range",
> > + REGULATOR_EVENT_OVER_VOLTAGE_WARN },
> > +};
>
> These all look like they should be _REGULATION_OUT given that the
> interrupt names are _UVOV which look like they could be either under or
> over voltage.
>
> Otherwise this all looks good.
Thanks for the feedback! We will fix it in the next version.
Regards,
Bhargav
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 17/23] dt-bindings: media: imx258: Rename to include vendor prefix
From: Conor Dooley @ 2024-03-28 10:15 UTC (permalink / raw)
To: Kieran Bingham
Cc: Conor Dooley, git, linux-media, dave.stevenson, jacopo.mondi,
mchehab, robh, krzysztof.kozlowski+dt, conor+dt, shawnguo,
s.hauer, kernel, festevam, sakari.ailus, devicetree, imx,
linux-arm-kernel, linux-kernel
In-Reply-To: <171161592126.3072637.14564447281929105708@ping.linuxembedded.co.uk>
[-- Attachment #1.1: Type: text/plain, Size: 1939 bytes --]
On Thu, Mar 28, 2024 at 08:52:01AM +0000, Kieran Bingham wrote:
> Quoting git@luigi311.com (2024-03-28 00:57:34)
> > On 3/27/24 17:47, Conor Dooley wrote:
> > > On Wed, Mar 27, 2024 at 05:17:03PM -0600, git@luigi311.com wrote:
> > >> From: Dave Stevenson <dave.stevenson@raspberrypi.com>
> > >>
> > >> imx258.yaml doesn't include the vendor prefix of sony, so
> > >> rename to add it.
> > >> Update the id entry and MAINTAINERS to match.
> > >>
> > >> Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
> > >> Acked-by: Conor Dooley <conor.dooley@microchip.com>
> > >
> > > This is a v1 with my ack, something has gone awry here. It's also
> > > missing your signoff. Did you pick up someone else's series?
> >
> > Yes, this is a continuation of Dave's work. I contacted him directly,
> > and he mentioned that he is unable to submit a v2 any time soon and
> > was open to someone else continuing it in his stead.
Ah okay. Unfortunately I see so many binding patches pass by that I
sometimes forget about what I already reviewed, and I did not
remember this one at all.
> > This is my first
> > time submitting a patch via a mailing list, so I'm not sure if I'm
> > missing something, but I only added my sign off for anything that
> > actually included work from my side and not just bringing his patch
> > forward to this patch series.
Right. The rules are that you need to add it when you send someone's
work, like chain of custody type of thing.
> Your cover letter states v2, but the individual patches do not.
>
> Add the '-v2' (or, rather, next it will be '-v3') to git format-patch
> when you save your series and it will add the version to each patch. You
> can also add '-s' to that command I believe to add your SoB to each
> patch.
or a rebase will do it with --signoff:
https://git-scm.com/docs/git-rebase#Documentation/git-rebase.txt---signoff
Cheers,
Conor.
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v6 3/5] crypto: tegra: Add Tegra Security Engine driver
From: Herbert Xu @ 2024-03-28 10:13 UTC (permalink / raw)
To: Akhil R
Cc: davem, robh, krzysztof.kozlowski+dt, conor+dt, thierry.reding,
jonathanh, catalin.marinas, will, mperttunen, airlied, daniel,
linux-crypto, devicetree, linux-tegra, linux-kernel,
linux-arm-kernel, dri-devel
In-Reply-To: <20240319082306.34716-4-akhilrajeev@nvidia.com>
On Tue, Mar 19, 2024 at 01:53:04PM +0530, Akhil R wrote:
>
> +struct tegra_sha_reqctx {
> + struct ahash_request fallback_req;
This doesn't work because ahash_request is dynamically sized.
So you'll end up clobbering the rest of the struct if a fallback
ends up being used.
You should place the fallback_req at the end of the reqctx and set
the reqsize based on the fallback reqsize.
Cheers,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v4 06/13] mm/gup: Drop folio_fast_pin_allowed() in hugepd processing
From: David Hildenbrand @ 2024-03-28 10:10 UTC (permalink / raw)
To: peterx, linux-mm, linux-kernel
Cc: Yang Shi, Kirill A . Shutemov, Mike Kravetz, John Hubbard,
Michael Ellerman, Andrew Jones, Muchun Song, linux-riscv,
linuxppc-dev, Christophe Leroy, Andrew Morton, Christoph Hellwig,
Lorenzo Stoakes, Matthew Wilcox, Rik van Riel, linux-arm-kernel,
Andrea Arcangeli, Aneesh Kumar K . V, Vlastimil Babka,
James Houghton, Jason Gunthorpe, Mike Rapoport, Axel Rasmussen
In-Reply-To: <20240327152332.950956-7-peterx@redhat.com>
On 27.03.24 16:23, peterx@redhat.com wrote:
> From: Peter Xu <peterx@redhat.com>
>
> Hugepd format for GUP is only used in PowerPC with hugetlbfs. There are
> some kernel usage of hugepd (can refer to hugepd_populate_kernel() for
> PPC_8XX), however those pages are not candidates for GUP.
>
> Commit a6e79df92e4a ("mm/gup: disallow FOLL_LONGTERM GUP-fast writing to
> file-backed mappings") added a check to fail gup-fast if there's potential
> risk of violating GUP over writeback file systems. That should never apply
> to hugepd. Considering that hugepd is an old format (and even
> software-only), there's no plan to extend hugepd into other file typed
> memories that is prone to the same issue.
>
> Drop that check, not only because it'll never be true for hugepd per any
> known plan, but also it paves way for reusing the function outside
> fast-gup.
>
> To make sure we'll still remember this issue just in case hugepd will be
> extended to support non-hugetlbfs memories, add a rich comment above
> gup_huge_pd(), explaining the issue with proper references.
>
> Cc: Christoph Hellwig <hch@infradead.org>
> Cc: Lorenzo Stoakes <lstoakes@gmail.com>
> Cc: Michael Ellerman <mpe@ellerman.id.au>
> Cc: linuxppc-dev@lists.ozlabs.org
> Signed-off-by: Peter Xu <peterx@redhat.com>
> ---
@Andrew, you properly adjusted the code to remove the
gup_fast_folio_allowed() call instead of the folio_fast_pin_allowed()
call, but
(1) the commit subject
(2) comment for gup_huge_pd()
Still mention folio_fast_pin_allowed().
The patch "mm/gup: handle hugepd for follow_page()" then moves that
(outdated) comment.
--
Cheers,
David / dhildenb
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 00/18] Add audio support for the MediaTek Genio 350-evk board
From: Alexandre Mergnat @ 2024-03-28 10:09 UTC (permalink / raw)
To: AngeloGioacchino Del Regno
Cc: linux-sound, devicetree, Lee Jones, Mark Brown, Liam Girdwood,
Matthias Brugger, Conor Dooley, Krzysztof Kozlowski, Rob Herring,
linux-kernel, Catalin Marinas, Christian König,
linux-arm-kernel, Takashi Iwai, Jaroslav Kysela, Flora Fu,
linux-mediatek, linux-media, dri-devel, linaro-mm-sig,
Nicolas Belin, Fabien Parent, Sumit Semwal, Will Deacon
In-Reply-To: <53671deb-9c11-43c1-8deb-93fe4708651a@collabora.com>
Hi Angelo
On 26/02/2024 15:54, AngeloGioacchino Del Regno wrote:
> Il 26/02/24 15:01, Alexandre Mergnat ha scritto:
>> This serie aim to add the following audio support for the Genio 350-evk:
>> - Playback
>> - 2ch Headset Jack (Earphone)
>> - 1ch Line-out Jack (Speaker)
>> - 8ch HDMI Tx
>> - Capture
>> - 1ch DMIC (On-board Digital Microphone)
>> - 1ch AMIC (On-board Analogic Microphone)
>> - 1ch Headset Jack (External Analogic Microphone)
>>
>> Of course, HDMI playback need the MT8365 display patches [1] and a DTS
>> change documented in "mediatek,mt8365-mt6357.yaml".
>>
>> [1]:
>> https://lore.kernel.org/all/20231023-display-support-v1-0-5c860ed5c33b@baylibre.com/
>>
>> Signed-off-by: Alexandre Mergnat <amergnat@baylibre.com>
>
> Actually, I am cooking a series (I'm finishing the testing....) that
> brings quite
> a bit of cleanups in MTK ASoC, including the commonization of the
> machine driver
> probe, with the dai-link DT nodes, and which also modernizes most of the
> existing
> drivers to use that instead.
>
> If you wait for a day or two, your mt8365-mt6357.c driver's probe
> function can be
> shrunk to ~3 lines or something like that.. very easily :-)
Just to inform you. I'm aware of your serie. Currently, I've fixed my
patches according to the comments. The next step will be to rebase my
serie over yours and do the changes to be aligned with your new
implementation.
I've planned to review your serie during my last task, but it seems
already approved and already (partially) merged into linux-next, sorry.
--
Regards,
Alexandre
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [report] WARN_ON_ONCE triggered in for_each_sibling_event()
From: Zenghui Yu @ 2024-03-28 10:06 UTC (permalink / raw)
To: linux-perf-users, linux-kernel
Cc: peterz, mingo, acme, namhyung, mark.rutland, will,
alexander.shishkin, jolsa, irogers, adrian.hunter,
wanghaibin.wang, linux-arm-kernel
Hi folks,
The following splat is triggered when I execute `perf stat -e
smmuv3_pmcg_100020/config_cache_miss/` on mainline kernel (built with
arm64-defconfig + PROVE_LOCKING).
| ------------[ cut here ]------------
| WARNING: CPU: 36 PID: 72452 at drivers/perf/arm_smmuv3_pmu.c:434
smmu_pmu_event_init+0x298/0x2b0 [arm_smmuv3_pmu]
| Modules linked in: xt_MASQUERADE iptable_nat xt_addrtype xt_conntrack
nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 libcrc32c overlay
ip6table_filter ip6_tables xt_tcpudp iptable_filter ip_tables x_tables
md_mod arm_smmuv3_pmu hibmc_drm drm_vram_helper drm_ttm_helper ttm
drm_kms_helper spi_dw_mmio spi_dw fuse drm backlight crct10dif_ce
onboard_usb_hub xhci_pci xhci_pci_renesas hisi_sec2 hisi_qm uacce
authenc ipmi_si ipmi_devintf ipmi_msghandler dm_mod br_netfilter bridge
stp llc nvme nvme_core nbd ipv6
| CPU: 36 PID: 72452 Comm: perf Kdump: loaded Not tainted
6.9.0-rc1-00061-g8d025e2092e2-dirty #1700
| Hardware name: Huawei TaiShan 2280 V2/BC82AMDDA, BIOS 1.05 09/18/2019
| pstate: 80400009 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
| pc : smmu_pmu_event_init+0x298/0x2b0 [arm_smmuv3_pmu]
| lr : smmu_pmu_event_init+0x290/0x2b0 [arm_smmuv3_pmu]
| sp : ffff8000c8ce3be0
| x29: ffff8000c8ce3be0 x28: 0000000000000000 x27: ffff8000802a2c1c
| x26: ffff8000c8ce3d70 x25: ffff8000802a2bc8 x24: 0000000000000000
| x23: 0000000000000001 x22: ffff0028045d52b0 x21: ffff002807228168
| x20: 0000000000000002 x19: ffff002807228000 x18: 0000000000000000
| x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000
| x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000040
| x11: ffff0020804016d0 x10: ffff0020804016d2 x9 : ffff800083b29b18
| x8 : ffff0020804016f8 x7 : 0000000000000000 x6 : ffff0020804018c0
| x5 : ffff0020804016d0 x4 : ffff80007bf07a58 x3 : 0000000000000002
| x2 : ffff802f5db37000 x1 : 0000000000000000 x0 : 0000000000000000
| Call trace:
| smmu_pmu_event_init+0x298/0x2b0 [arm_smmuv3_pmu]
| perf_try_init_event+0x54/0x140| perf_event_alloc+0x3e4/0x1080
| __do_sys_perf_event_open+0x178/0xfa8
| __arm64_sys_perf_event_open+0x28/0x34
| invoke_syscall+0x48/0x114
| el0_svc_common.constprop.0+0x40/0xe0
| do_el0_svc+0x1c/0x28
| el0_svc+0x4c/0x11c
| el0t_64_sync_handler+0xc0/0xc4
| el0t_64_sync+0x190/0x194
| irq event stamp: 174338
| hardirqs last enabled at (174337): [<ffff800080357774>]
___slab_alloc+0x3bc/0xf38
| hardirqs last disabled at (174338): [<ffff8000812a7ee0>] el1_dbg+0x24/0x8c
| softirqs last enabled at (174292): [<ffff8000800185bc>]
fpsimd_restore_current_state+0x34/0xc4
| softirqs last disabled at (174290): [<ffff80008001858c>]
fpsimd_restore_current_state+0x4/0xc4
| ---[ end trace 0000000000000000 ]---
Note that this is not specific to the arm_smmuv3_pmu driver as I can
also reproduce it with some HiSilicon uncore PMU events (e.g., executing
`perf stat -e hisi_sccl1_ddrc0/flux_rd/`).
For your convenience, the assertion was added by commit f3c0eba28704
("perf: Add a few assertions").
Post it out for visibility, not sure if there are already similar
reports on the list though. Please have a look.
Thanks,
Zenghui
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v6 3/5] crypto: tegra: Add Tegra Security Engine driver
From: Herbert Xu @ 2024-03-28 10:05 UTC (permalink / raw)
To: Akhil R
Cc: davem, robh, krzysztof.kozlowski+dt, conor+dt, thierry.reding,
jonathanh, catalin.marinas, will, mperttunen, airlied, daniel,
linux-crypto, devicetree, linux-tegra, linux-kernel,
linux-arm-kernel, dri-devel
In-Reply-To: <20240319082306.34716-4-akhilrajeev@nvidia.com>
On Tue, Mar 19, 2024 at 01:53:04PM +0530, Akhil R wrote:
>
> + .alg.skcipher.op.do_one_request = tegra_aes_do_one_req,
> + .alg.skcipher.base = {
> + .init = tegra_aes_cra_init,
> + .exit = tegra_aes_cra_exit,
> + .setkey = tegra_aes_setkey,
> + .encrypt = tegra_aes_encrypt,
> + .decrypt = tegra_aes_decrypt,
> + .min_keysize = AES_MIN_KEY_SIZE,
> + .max_keysize = AES_MAX_KEY_SIZE,
> + .ivsize = AES_BLOCK_SIZE,
> + .base = {
> + .cra_name = "ofb(aes)",
> + .cra_driver_name = "ofb-aes-tegra",
> + .cra_priority = 500,
> + .cra_flags = CRYPTO_ALG_TYPE_SKCIPHER | CRYPTO_ALG_ASYNC,
> + .cra_blocksize = AES_BLOCK_SIZE,
> + .cra_ctxsize = sizeof(struct tegra_aes_ctx),
> + .cra_alignmask = 0xf,
> + .cra_module = THIS_MODULE,
> + },
> + }
> + }, {
OFB no longer exists in the kernel. Please remove all traces of it
from your driver.
Also please ensure that yuor driver passes the extra fuzz tests.
Thanks,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v3 0/5] arm64: dts: exynos: gs101: define all PERIC USI nodes
From: Krzysztof Kozlowski @ 2024-03-28 9:58 UTC (permalink / raw)
To: peter.griffin, robh+dt, krzysztof.kozlowski+dt, conor+dt,
Tudor Ambarus
Cc: alim.akhtar, linux-arm-kernel, linux-samsung-soc, devicetree,
linux-kernel, andre.draszik, willmcvicker, kernel-team
In-Reply-To: <20240326151301.348932-1-tudor.ambarus@linaro.org>
On Tue, 26 Mar 2024 15:12:56 +0000, Tudor Ambarus wrote:
> The series starts with some trivial cosmetics patches, then defines all
> the PERIC USI nodes.
>
> v3:
> - seems that Andre' already reordered the pinctrl properties, take his
> patch (first in the series) and rebase my series on top.
> - small updates on commit messages
> - collect R-b tags
>
> [...]
Applied, thanks!
[1/5] arm64: dts: exynos: gs101: reorder pinctrl-* properties
https://git.kernel.org/krzk/linux/c/7d7df014617ba8df7fbdacac54cafe0d13573dcb
[2/5] arm64: dts: exynos: gs101: move serial_0 pinctrl-0/names to dtsi
https://git.kernel.org/krzk/linux/c/73618dfa705dc8f993a6829c895eaf5af8402ceb
[3/5] arm64: dts: exynos: gs101: move pinctrl-* properties after clocks
https://git.kernel.org/krzk/linux/c/d978c70e8d4775c62db21f85947d12b4f874104a
[4/5] arm64: dts: exynos: gs101: join lines close to 80 chars
https://git.kernel.org/krzk/linux/c/028a87e91fcd8c485afcf8bd0d26ae34a0872438
[5/5] arm64: dts: exynos: gs101: define all PERIC USI nodes
https://git.kernel.org/krzk/linux/c/a45c3a9b1ef9571741d40bf10f22ce3c60bc5111
Best regards,
--
Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox