* Re: [PATCH] arm64: Fix double TCR_T0SZ_OFFSET shift
From: Will Deacon @ 2024-04-02 11:58 UTC (permalink / raw)
To: Seongsu Park
Cc: catalin.marinas, ardb, mark.rutland, linux-arm-kernel,
linux-kernel, Leem ChaeHoon, Gyeonggeon Choi, Soomin Cho,
DaeRo Lee, kmasta
In-Reply-To: <20240402104950.170632-1-sgsu.park@samsung.com>
On Tue, Apr 02, 2024 at 07:49:50PM +0900, Seongsu Park wrote:
> We have already shifted the value of t0sz in TCR_T0SZ by TCR_T0SZ_OFFSET.
> So, the TCR_T0SZ_OFFSET shift here should be removed.
>
> Co-developed-by: Leem ChaeHoon <infinite.run@gmail.com>
> Signed-off-by: Leem ChaeHoon <infinite.run@gmail.com>
> Co-developed-by: Gyeonggeon Choi <gychoi@student.42seoul.kr>
> Signed-off-by: Gyeonggeon Choi <gychoi@student.42seoul.kr>
> Co-developed-by: Soomin Cho <to.soomin@gmail.com>
> Signed-off-by: Soomin Cho <to.soomin@gmail.com>
> Co-developed-by: DaeRo Lee <skseofh@gmail.com>
> Signed-off-by: DaeRo Lee <skseofh@gmail.com>
> Co-developed-by: kmasta <kmasta.study@gmail.com>
> Signed-off-by: kmasta <kmasta.study@gmail.com>
> Signed-off-by: Seongsu Park <sgsu.park@samsung.com>
heh, that's quite a lot of people. Did you remove three chars each? :p
> ---
> arch/arm64/include/asm/mmu_context.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm64/include/asm/mmu_context.h b/arch/arm64/include/asm/mmu_context.h
> index c768d16b81a4..58de99836d2e 100644
> --- a/arch/arm64/include/asm/mmu_context.h
> +++ b/arch/arm64/include/asm/mmu_context.h
> @@ -76,7 +76,7 @@ static inline void __cpu_set_tcr_t0sz(unsigned long t0sz)
> return;
>
> tcr &= ~TCR_T0SZ_MASK;
> - tcr |= t0sz << TCR_T0SZ_OFFSET;
> + tcr |= t0sz;
Thankfully, TCR_T0SZ_OFFSET is 0 so this isn't as alarming as it looks.
Even so, if we're going to make the code consistent, then shouldn't the
earlier conditional be updated too?
if ((tcr & TCR_T0SZ_MASK) >> TCR_T0SZ_OFFSET == t0sz)
return;
seems to assume that t0sz is unshifted.
Will
_______________________________________________
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 v1 6/6] clk: meson: a1: add Amlogic A1 CPU clock controller driver
From: Dmitry Rokosov @ 2024-04-02 11:43 UTC (permalink / raw)
To: Jerome Brunet
Cc: Martin Blumenstingl, neil.armstrong, mturquette, sboyd, robh+dt,
krzysztof.kozlowski+dt, khilman, kernel, rockosov, linux-amlogic,
linux-clk, devicetree, linux-kernel, linux-arm-kernel
In-Reply-To: <1jzfuchztl.fsf@starbuckisacylon.baylibre.com>
On Tue, Apr 02, 2024 at 11:27:24AM +0200, Jerome Brunet wrote:
>
> On Mon 01 Apr 2024 at 20:12, Dmitry Rokosov <ddrokosov@salutedevices.com> wrote:
>
> > Hello Martin,
> >
> > Thank you for quick response. Please find my thoughts below.
> >
> > On Sun, Mar 31, 2024 at 11:40:13PM +0200, Martin Blumenstingl wrote:
> >> Hi Dmitry,
> >>
> >> On Fri, Mar 29, 2024 at 9:59 PM Dmitry Rokosov
> >> <ddrokosov@salutedevices.com> wrote:
> >> [...]
> >> > +static struct clk_regmap cpu_fclk = {
> >> > + .data = &(struct clk_regmap_mux_data) {
> >> > + .offset = CPUCTRL_CLK_CTRL0,
> >> > + .mask = 0x1,
> >> > + .shift = 10,
> >> > + },
> >> > + .hw.init = &(struct clk_init_data) {
> >> > + .name = "cpu_fclk",
> >> > + .ops = &clk_regmap_mux_ops,
> >> > + .parent_hws = (const struct clk_hw *[]) {
> >> > + &cpu_fsel0.hw,
> >> > + &cpu_fsel1.hw,
> >> Have you considered the CLK_SET_RATE_GATE flag for &cpu_fsel0.hw and
> >> &cpu_fsel1.hw and then dropping the clock notifier below?
> >> We use that approach with the Mali GPU clock on other SoCs, see for
> >> example commit 8daeaea99caa ("clk: meson: meson8b: make the CCF use
> >> the glitch-free mali mux").
> >> It may differ from what Amlogic does in their BSP,
> >
> > Amlogic in their BSP takes a different approach, which is slightly
> > different from mine. They cleverly change the parent of cpu_clk directly
> > by forking the cpufreq driver to a custom version. I must admit, it's
> > quite an "interesting and amazing" idea :) but it's not architecturally
> > correct totally.
>
> I disagree. Martin's suggestion is correct for the fsel part which is
> symetric.
>
It seems that I didn't fully understand Martin's suggestion. I was
confused by the advice to remove the notifier block and tried to explain
why it's not possible. However, I believe it is reasonable to protect
the cpu_fselX from rate propagation, because it is symmetric, as you
mentioned.
> >
> >> but I don't think
> >> that there's any harm (if it works in general) because CCF (common
> >> clock framework) will set all clocks in the "inactive" tree and then
> >> as a last step just change the mux (&cpu_fclk.hw). So at no point in
> >> time will we get any other rate than a) the original CPU clock rate
> >> before the rate change b) the new desired CPU clock rate. This is
> >> because we have two symmetric clock trees.
> >
> > Now, let's dive into the specifics of the issue we're facing. I've
> > examined the CLK_SET_RATE_GATE flag, which, to my understanding, blocks
> > rate changes for the entire clock chain. However, in this particular
> > situation, it doesn't provide the solution we need.
> >
> > Here's the problem we're dealing with:
> >
> > 1) The CPU clock can have the following frequency points:
> >
> > available frequency steps: 128 MHz, 256 MHz, 512 MHz, 768 MHz, 1.01 GHz, 1.20 GHz
> >
> > When we run the cpupower, we get the following information:
> > # cpupower -c 0,1 frequency-info
> > analyzing CPU 0:
> > driver: cpufreq-dt
> > CPUs which run at the same hardware frequency: 0 1
> > CPUs which need to have their frequency coordinated by software: 0 1
> > maximum transition latency: 50.0 us
> > hardware limits: 128 MHz - 1.20 GHz
> > available frequency steps: 128 MHz, 256 MHz, 512 MHz, 768 MHz, 1.01 GHz, 1.20 GHz
> > available cpufreq governors: conservative ondemand userspace performance schedutil
> > current policy: frequency should be within 128 MHz and 128 MHz.
> > The governor "schedutil" may decide which speed to use
> > within this range.
> > current CPU frequency: 128 MHz (asserted by call to hardware)
> > analyzing CPU 1:
> > driver: cpufreq-dt
> > CPUs which run at the same hardware frequency: 0 1
> > CPUs which need to have their frequency coordinated by software: 0 1
> > maximum transition latency: 50.0 us
> > hardware limits: 128 MHz - 1.20 GHz
> > available frequency steps: 128 MHz, 256 MHz, 512 MHz, 768 MHz, 1.01 GHz, 1.20 GHz
> > available cpufreq governors: conservative ondemand userspace performance schedutil
> > current policy: frequency should be within 128 MHz and 128 MHz.
> > The governor "schedutil" may decide which speed to use
> > within this range.
> > current CPU frequency: 128 MHz (asserted by call to hardware)
> >
> > 2) For the frequency points 128 MHz, 256 MHz, and 512 MHz, the CPU fixed
> > clock should be used.
>
> Apparently, you are relying on the SYS PLL lowest possible rate to
> enfore this contraint, which I suppose is 24 * 32 = 768MHz. It would be
> nice to clearly say so.
>
Based on my understanding, the minimum frequency that sys_pll can
provide is not relevant. The CPU fixed clock is considered a "safety"
clock, and I can confidently connect the cpu_clk parent to that stable
clock without any issues. CCF will decide which parent will be used in
the end of rate changing process.
> > Fortunately, we don't encounter any freeze
> > problems when we attempt to change its rate at these frequencies.
>
> That does not sound very solid ...
>
Why? Per my understanding, CPU fixed clock guarantees this behaviour.
> >
> > 3) However, for the frequency points 768 MHz, 1.01 GHz, and 1.20 GHz,
> > the sys_pll is used as the clock source because it's a faster option.
> > Now, let's imagine that we want to change the CPU clock from 768 MHz to
> > 1.01 GHz. Unfortunately, it's not possible due to the broken sys_pll,
> > and any execution attempts will result in a hang.
>
> ... Because PLL needs to relock, it is going to be off for a while. That
> is not "broken", unless there is something else ?
>
Sorry for wrong terminology. I meant that sys_pll cannot be used as a
clock source (clock parent) while we are changing its rate.
> >
> > 4) As you can observe, in this case, we actually don't need to lock the
> > rate for the sys_pll chain.
>
> In which case ? I'm lost.
>
In the case for which notifier block was applied - cpu_clk and sys_pll
rate propagation.
> > We want to change the rate instead.
>
> ... How are you going to do that without relocking the PLL ?
>
I'm afraid, this is terminology miss from my side again. By 'sys_pll
lock' I mean rate lock using CLK_SET_RATE_GATE. I want to say that we
can't prohibit rate propagation of sys_pll chain, because we want to
change the rate, this is our main goal.
> > Hence,
> > I'm not aware of any other method to achieve this except by switching
> > the cpu_clk parent to a stable clock using clock notifier block.
> > Interestingly, I've noticed a similar approach in the CPU clock drivers
> > of Rockchip, Qualcomm, and Mediatek.
>
> There is an example of syspll notifier in the g12 clock controller.
> You should have a look at it
Okay. As I mentioned in another email reply, in order to make it happen,
it is required to move the sys_pll clock to the a1-cpu driver. However,
I thought that this approach may not be correct from a logical
perspective. I will try.
--
Thank you,
Dmitry
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH] irqchip/gic-v3-its: Don't need VSYNC if VMAPP with {V, Alloc}=={0, x}
From: t00849498 @ 2024-04-02 11:41 UTC (permalink / raw)
To: maz, tglx, linux-arm-kernel, linux-kernel; +Cc: guoyang2, wangwudi, tangnianyao
From GIC spec, a VMAPP with {V, Alloc}=={0, x} is self-synchronizing,
This means the ITS command queue does not show the command as
consumed until all of its effects are completed. A VSYNC with unmapped
vpeid is not needed.
Signed-off-by: t00849498 <tangnianyao@huawei.com>
---
drivers/irqchip/irq-gic-v3-its.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/irqchip/irq-gic-v3-its.c b/drivers/irqchip/irq-gic-v3-its.c
index fca888b36680..a0ca5dcbb245 100644
--- a/drivers/irqchip/irq-gic-v3-its.c
+++ b/drivers/irqchip/irq-gic-v3-its.c
@@ -789,6 +789,7 @@ static struct its_vpe *its_build_vmapp_cmd(struct its_node *its,
unsigned long vpt_addr, vconf_addr;
u64 target;
bool alloc;
+ bool unmap_v4_1 = !desc->its_vmapp_cmd.valid && is_v4_1(its);
its_encode_cmd(cmd, GITS_CMD_VMAPP);
its_encode_vpeid(cmd, desc->its_vmapp_cmd.vpe->vpe_id);
@@ -832,6 +833,9 @@ static struct its_vpe *its_build_vmapp_cmd(struct its_node *its,
out:
its_fixup_cmd(cmd);
+ if (unmap_v4_1)
+ return NULL;
+
return valid_vpe(its, desc->its_vmapp_cmd.vpe);
}
--
2.30.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] ARM: shmobile: defconfig: Refresh for v6.9-rc1
From: Geert Uytterhoeven @ 2024-04-02 10:21 UTC (permalink / raw)
To: Magnus Damm; +Cc: linux-renesas-soc, linux-arm-kernel, Geert Uytterhoeven
Refresh the defconfig for Renesas ARM systems:
- Move CONFIG_DRM_PANEL_SIMPLE (moved in commit aaf7f80996834ae5
("drm/panel: re-alphabetize the menu list")),
- Enable warn on W+X mappings at boot (recommended, renamed in commit
a90f0a02f139a13d ("arm: ptdump: rename CONFIG_DEBUG_WX to
CONFIG_ARM_DEBUG_WX")).
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
To be queued in renesas-devel for v6.10.
arch/arm/configs/shmobile_defconfig | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/arm/configs/shmobile_defconfig b/arch/arm/configs/shmobile_defconfig
index 091e1840933cf2c6..56925adfe8422921 100644
--- a/arch/arm/configs/shmobile_defconfig
+++ b/arch/arm/configs/shmobile_defconfig
@@ -139,8 +139,8 @@ CONFIG_DRM_FBDEV_EMULATION=y
CONFIG_DRM_RCAR_DU=y
# CONFIG_DRM_RCAR_USE_MIPI_DSI is not set
CONFIG_DRM_SHMOBILE=y
-CONFIG_DRM_PANEL_SIMPLE=y
CONFIG_DRM_PANEL_EDP=y
+CONFIG_DRM_PANEL_SIMPLE=y
CONFIG_DRM_DISPLAY_CONNECTOR=y
CONFIG_DRM_LVDS_CODEC=y
CONFIG_DRM_SII902X=y
@@ -235,3 +235,4 @@ CONFIG_CMA_SIZE_MBYTES=64
CONFIG_PRINTK_TIME=y
CONFIG_DEBUG_KERNEL=y
CONFIG_DEBUG_FS=y
+CONFIG_ARM_DEBUG_WX=y
--
2.34.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 1/2] ARM: boot: dts: microchip: at91-sama7g5ek: Replace regulator-suspend-voltage with the valid property
From: Andrei.Simion @ 2024-04-02 11:27 UTC (permalink / raw)
To: krzysztof.kozlowski, robh, krzysztof.kozlowski+dt, conor+dt,
Nicolas.Ferre, alexandre.belloni, claudiu.beznea, Mihai.Sain
Cc: linux-arm-kernel, linux-kernel, devicetree
In-Reply-To: <34543ae2-4e78-45a4-9cff-389f7495fd4a@linaro.org>
On 02.04.2024 13:39, Krzysztof Kozlowski wrote:
> [You don't often get email from krzysztof.kozlowski@linaro.org. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]
>
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
>
> On 02/04/2024 11:12, Andrei Simion wrote:
>> Replace regulator-suspend-voltage with regulator-suspend-microvolt.
>
> Why?
>
at91-sama7g5ek.dtb: mcp16502@5b: regulators:VDD_(CORE|OTHER)|LDO[1-2]:
regulator-state-standby 'regulator-suspend-voltage' does not match any of
the regexes 'pinctrl-[0-9]+' from schema
$id: http://devicetree.org/schemas/regulator/microchip,mcp16502.yaml#
no property named regulator-suspend-voltage in
https://github.com/torvalds/linux/blob/master/Documentation/devicetree/bindings/regulator/regulator.yaml
so if it is using this property there will be no effect as it was expected in
https://github.com/torvalds/linux/commit/85b1304b9daa06367139b471789c7ddb76250b9f
> Please explain what is the bug and how it manifests itself. Is one
> property incorrect and other correct?
>
The main reason is explained in the cover-letter but if you ask me to explain in each commit I will do it in next version.
> Please use subject prefixes matching the subsystem. You can get them for
> example with `git log --oneline -- DIRECTORY_OR_FILE` on the directory
> your patch is touching.
> Hint: there is no "boot"
>
Yes, in hurry I slipped that "boot" in subject.
>>
>
> Best regards,
> Krzysztof
>
--
Andrei Simion
_______________________________________________
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] pmdomain: mediatek: scpsys: drop driver owner assignment
From: AngeloGioacchino Del Regno @ 2024-04-02 10:07 UTC (permalink / raw)
To: Krzysztof Kozlowski, Ulf Hansson, Matthias Brugger, linux-pm,
linux-kernel, linux-arm-kernel, linux-mediatek
In-Reply-To: <20240330211036.100956-1-krzysztof.kozlowski@linaro.org>
Il 30/03/24 22:10, Krzysztof Kozlowski ha scritto:
> Core in platform_driver_register() already sets the .owner, so driver
> does not need to.
>
> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
_______________________________________________
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 0/9] perf: Avoid explicit cpumask var allocation from stack
From: Mark Rutland @ 2024-04-02 11:12 UTC (permalink / raw)
To: Dawei Li
Cc: will, xueshuai, renyu.zj, yangyicong, jonathan.cameron, andersson,
konrad.dybcio, linux-arm-kernel, linux-kernel, linux-arm-msm
In-Reply-To: <20240402105610.1695644-1-dawei.li@shingroup.cn>
On Tue, Apr 02, 2024 at 06:56:01PM +0800, Dawei Li wrote:
> Hi,
>
> This series try to eliminate direct cpumask var allocation from stack
> for perf subsystem.
>
> Direct/explicit allocation of cpumask on stack could be dangerous since
> it can lead to stack overflow for systems with big NR_CPUS or
> CONFIG_CPUMASK_OFFSTACK=y.
>
> For arm64, it's more urgent since commit 3fbd56f0e7c1 ("ARM64: Dynamically
> allocate cpumasks and increase supported CPUs to 512").
>
> It's sort of a pattern that almost every cpumask var in perf subystem
> occurs in teardown callback of cpuhp. In which case, if dynamic
> allocation failed(which is unlikely), we choose return 0 rather than
> -ENOMEM to caller cuz:
> @teardown is not supposed to fail and if it does, system crashes:
... but we've left the system in an incorrect state, so that makes no sense.
As I commented on the first patch, NAK to dynamically allocating cpumasks in
the CPUHP callbacks. Please allocate the necessry cpumasks up-front when we
probe the PMU. At that time we can handle an allocation failure by cleaning up
and failing to probe the PMU, and then the CPUHP callbacks don't need to
allocate memory to offline a CPU...
Also, for the titles it'd be better to say something like "avoid placing
cpumasks on the stack", because "explicit cpumask var allocation" sounds like
the use of alloc_cpumask_var().
Mark.
>
> static int cpuhp_issue_call(int cpu, enum cpuhp_state state, bool bringup,
> struct hlist_node *node)
> {
> struct cpuhp_step *sp = cpuhp_get_step(state);
> int ret;
>
> /*
> * If there's nothing to do, we done.
> * Relies on the union for multi_instance.
> */
> if (cpuhp_step_empty(bringup, sp))
> return 0;
> /*
> * The non AP bound callbacks can fail on bringup. On teardown
> * e.g. module removal we crash for now.
> */
> #ifdef CONFIG_SMP
> if (cpuhp_is_ap_state(state))
> ret = cpuhp_invoke_ap_callback(cpu, state, bringup, node);
> else
> ret = cpuhp_invoke_callback(cpu, state, bringup, node,
> NULL);
> #else
> ret = cpuhp_invoke_callback(cpu, state, bringup, node, NULL);
> #endif
> BUG_ON(ret && !bringup);
> return ret;
> }
>
> Dawei Li (9):
> perf/alibaba_uncore_drw: Avoid explicit cpumask var allocation from
> stack
> perf/arm-cmn: Avoid explicit cpumask var allocation from stack
> perf/arm_cspmu: Avoid explicit cpumask var allocation from stack
> perf/arm_dsu: Avoid explicit cpumask var allocation from stack
> perf/dwc_pcie: Avoid explicit cpumask var allocation from stack
> perf/hisi_pcie: Avoid explicit cpumask var allocation from stack
> perf/hisi_uncore: Avoid explicit cpumask var allocation from stack
> perf/qcom_l2: Avoid explicit cpumask var allocation from stack
> perf/thunder_x2: Avoid explicit cpumask var allocation from stack
>
> drivers/perf/alibaba_uncore_drw_pmu.c | 13 +++++++++----
> drivers/perf/arm-cmn.c | 13 +++++++++----
> drivers/perf/arm_cspmu/arm_cspmu.c | 13 +++++++++----
> drivers/perf/arm_dsu_pmu.c | 18 +++++++++++++-----
> drivers/perf/dwc_pcie_pmu.c | 17 +++++++++++------
> drivers/perf/hisilicon/hisi_pcie_pmu.c | 15 ++++++++++-----
> drivers/perf/hisilicon/hisi_uncore_pmu.c | 13 +++++++++----
> drivers/perf/qcom_l2_pmu.c | 15 ++++++++++-----
> drivers/perf/thunderx2_pmu.c | 20 ++++++++++++--------
> 9 files changed, 92 insertions(+), 45 deletions(-)
>
>
> Thanks,
>
> Dawei
>
> --
> 2.27.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] ARM: dts: imx7s-warp: Fix OV2680 supply names
From: Fabio Estevam @ 2024-04-02 11:11 UTC (permalink / raw)
To: Shawn Guo; +Cc: shawnguo, linux-arm-kernel, rmfrfs, Fabio Estevam
In-Reply-To: <Zgvk2ao9wwT2s/36@dragon>
Hi Shawn,
On Tue, Apr 2, 2024 at 7:58 AM Shawn Guo <shawnguo2@yeah.net> wrote:
>
> On Sat, Mar 23, 2024 at 09:53:27AM -0300, Fabio Estevam wrote:
> > From: Fabio Estevam <festevam@denx.de>
> >
> > Fix the OV2680 supply names according to ovti,ov2680.yaml.
> >
> > Signed-off-by: Fabio Estevam <festevam@denx.de>
>
> Do we want to have a Fixes tag for it?
Please discard this patch.
I noticed that the driver uses DOVDD, DVDD, and AVDD as supply names.
The regulators uses on imx7s-warp are marked as 'regulator-always-on'
so we don't see the issue in practice.
I will update the bindings instead.
Thanks.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* RE: [EXT] Re: [PATCH v10 09/11] arm64: dts: imx93-11x11-evk: enable usb and typec nodes
From: Xu Yang @ 2024-04-02 11:10 UTC (permalink / raw)
To: Shawn Guo
Cc: gregkh@linuxfoundation.org, robh+dt@kernel.org,
krzysztof.kozlowski+dt@linaro.org, shawnguo@kernel.org,
conor+dt@kernel.org, s.hauer@pengutronix.de,
kernel@pengutronix.de, festevam@gmail.com, dl-linux-imx,
peter.chen@kernel.org, Jun Li, linux-usb@vger.kernel.org,
devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
imx@lists.linux.dev, linux-kernel@vger.kernel.org
In-Reply-To: <ZgvKteCEZJxShA/j@dragon>
>
> On Thu, Mar 21, 2024 at 04:14:37PM +0800, Xu Yang wrote:
> > There are 2 Type-C ports and 2 USB controllers on i.MX93. Enable them.
> >
> > Signed-off-by: Xu Yang <xu.yang_2@nxp.com>
> >
> > ---
> > Changes in v2:
> > - remove status property in ptn5110 nodes
> > - fix dt-schema warnings
> > Changes in v3:
> > - no changes
> > Changes in v4:
> > - no changes
> > Changes in v5:
> > - no changes
> > Changes in v6:
> > - no changes
> > Changes in v7:
> > - no changes
> > Changes in v8:
> > - no changes
> > Changes in v9:
> > - use compatible "nxp,ptn5110", "tcpci"
> > Changes in v10:
> > - no changes
> > ---
> > .../boot/dts/freescale/imx93-11x11-evk.dts | 118 ++++++++++++++++++
> > 1 file changed, 118 insertions(+)
> >
> > diff --git a/arch/arm64/boot/dts/freescale/imx93-11x11-evk.dts b/arch/arm64/boot/dts/freescale/imx93-11x11-evk.dts
> > index 9921ea13ab48..ecc01d872e95 100644
> > --- a/arch/arm64/boot/dts/freescale/imx93-11x11-evk.dts
> > +++ b/arch/arm64/boot/dts/freescale/imx93-11x11-evk.dts
> > @@ -5,6 +5,7 @@
> >
> > /dts-v1/;
> >
> > +#include <dt-bindings/usb/pd.h>
> > #include "imx93.dtsi"
> >
> > / {
> > @@ -104,6 +105,80 @@ &mu2 {
> > status = "okay";
> > };
> >
> > +&lpi2c3 {
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > + clock-frequency = <400000>;
> > + pinctrl-names = "default", "sleep";
> > + pinctrl-0 = <&pinctrl_lpi2c3>;
> > + pinctrl-1 = <&pinctrl_lpi2c3>;
>
> Do you really need "sleep" pinctrl state?
"sleep" pinctrl state can be removed.
>
> > + status = "okay";
> > +
> > + ptn5110: tcpc@50 {
> > + compatible = "nxp,ptn5110", "tcpci";
> > + reg = <0x50>;
> > + interrupt-parent = <&gpio3>;
> > + interrupts = <27 IRQ_TYPE_LEVEL_LOW>;
> > +
> > + typec1_con: connector {
> > + compatible = "usb-c-connector";
> > + label = "USB-C";
> > + power-role = "dual";
> > + data-role = "dual";
> > + try-power-role = "sink";
> > + source-pdos = <PDO_FIXED(5000, 3000, PDO_FIXED_USB_COMM)>;
> > + sink-pdos = <PDO_FIXED(5000, 3000, PDO_FIXED_USB_COMM)
> > + PDO_VAR(5000, 20000, 3000)>;
> > + op-sink-microwatt = <15000000>;
> > + self-powered;
> > +
> > + ports {
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > +
> > + port@0 {
> > + reg = <0>;
>
> Have a newline between properties and child node.
Okay.
Thanks,
Xu Yang
>
> Shawn
>
> > + typec1_dr_sw: endpoint {
> > + remote-endpoint = <&usb1_drd_sw>;
> > + };
> > + };
> > + };
> > + };
> > + };
> > +
> > + ptn5110_2: tcpc@51 {
> > + compatible = "nxp,ptn5110", "tcpci";
> > + reg = <0x51>;
> > + interrupt-parent = <&gpio3>;
> > + interrupts = <27 IRQ_TYPE_LEVEL_LOW>;
> > +
> > + typec2_con: connector {
> > + compatible = "usb-c-connector";
> > + label = "USB-C";
> > + power-role = "dual";
> > + data-role = "dual";
> > + try-power-role = "sink";
> > + source-pdos = <PDO_FIXED(5000, 3000, PDO_FIXED_USB_COMM)>;
> > + sink-pdos = <PDO_FIXED(5000, 3000, PDO_FIXED_USB_COMM)
> > + PDO_VAR(5000, 20000, 3000)>;
> > + op-sink-microwatt = <15000000>;
> > + self-powered;
> > +
> > + ports {
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > +
> > + port@0 {
> > + reg = <0>;
> > + typec2_dr_sw: endpoint {
> > + remote-endpoint = <&usb2_drd_sw>;
> > + };
> > + };
> > + };
> > + };
> > + };
> > +};
> > +
> > &eqos {
> > pinctrl-names = "default";
> > pinctrl-0 = <&pinctrl_eqos>;
> > @@ -156,6 +231,42 @@ &lpuart5 {
> > status = "okay";
> > };
> >
> > +&usbotg1 {
> > + dr_mode = "otg";
> > + hnp-disable;
> > + srp-disable;
> > + adp-disable;
> > + usb-role-switch;
> > + disable-over-current;
> > + samsung,picophy-pre-emp-curr-control = <3>;
> > + samsung,picophy-dc-vol-level-adjust = <7>;
> > + status = "okay";
> > +
> > + port {
> > + usb1_drd_sw: endpoint {
> > + remote-endpoint = <&typec1_dr_sw>;
> > + };
> > + };
> > +};
> > +
> > +&usbotg2 {
> > + dr_mode = "otg";
> > + hnp-disable;
> > + srp-disable;
> > + adp-disable;
> > + usb-role-switch;
> > + disable-over-current;
> > + samsung,picophy-pre-emp-curr-control = <3>;
> > + samsung,picophy-dc-vol-level-adjust = <7>;
> > + status = "okay";
> > +
> > + port {
> > + usb2_drd_sw: endpoint {
> > + remote-endpoint = <&typec2_dr_sw>;
> > + };
> > + };
> > +};
> > +
> > &usdhc1 {
> > pinctrl-names = "default", "state_100mhz", "state_200mhz";
> > pinctrl-0 = <&pinctrl_usdhc1>;
> > @@ -222,6 +333,13 @@ MX93_PAD_ENET2_TX_CTL__ENET1_RGMII_TX_CTL 0x57e
> > >;
> > };
> >
> > + pinctrl_lpi2c3: lpi2c3grp {
> > + fsl,pins = <
> > + MX93_PAD_GPIO_IO28__LPI2C3_SDA 0x40000b9e
> > + MX93_PAD_GPIO_IO29__LPI2C3_SCL 0x40000b9e
> > + >;
> > + };
> > +
> > pinctrl_uart1: uart1grp {
> > fsl,pins = <
> > MX93_PAD_UART1_RXD__LPUART1_RX 0x31e
> > --
> > 2.34.1
> >
_______________________________________________
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 1/9] perf/alibaba_uncore_drw: Avoid explicit cpumask var allocation from stack
From: Mark Rutland @ 2024-04-02 11:06 UTC (permalink / raw)
To: Dawei Li
Cc: will, xueshuai, renyu.zj, yangyicong, jonathan.cameron, andersson,
konrad.dybcio, linux-arm-kernel, linux-kernel, linux-arm-msm
In-Reply-To: <20240402105610.1695644-2-dawei.li@shingroup.cn>
On Tue, Apr 02, 2024 at 06:56:02PM +0800, Dawei Li wrote:
> For CONFIG_CPUMASK_OFFSTACK=y kernel, explicit allocation of cpumask
> variable on stack is not recommended since it can cause potential stack
> overflow.
>
> Instead, kernel code should always use *cpumask_var API(s) to allocate
> cpumask var in config- neutral way, leaving allocation strategy to
> CONFIG_CPUMASK_OFFSTACK.
>
> Use *cpumask_var API(s) to address it.
>
> Signed-off-by: Dawei Li <dawei.li@shingroup.cn>
> ---
> drivers/perf/alibaba_uncore_drw_pmu.c | 13 +++++++++----
> 1 file changed, 9 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/perf/alibaba_uncore_drw_pmu.c b/drivers/perf/alibaba_uncore_drw_pmu.c
> index a9277dcf90ce..251f0a2dee84 100644
> --- a/drivers/perf/alibaba_uncore_drw_pmu.c
> +++ b/drivers/perf/alibaba_uncore_drw_pmu.c
> @@ -743,25 +743,28 @@ static void ali_drw_pmu_remove(struct platform_device *pdev)
>
> static int ali_drw_pmu_offline_cpu(unsigned int cpu, struct hlist_node *node)
> {
> + cpumask_var_t node_online_cpus;
> struct ali_drw_pmu_irq *irq;
> struct ali_drw_pmu *drw_pmu;
> unsigned int target;
> int ret;
> - cpumask_t node_online_cpus;
>
> irq = hlist_entry_safe(node, struct ali_drw_pmu_irq, node);
> if (cpu != irq->cpu)
> return 0;
>
> - ret = cpumask_and(&node_online_cpus,
> + if (!alloc_cpumask_var(&node_online_cpus, GFP_KERNEL))
> + return 0;
NAK. This error path leaves things in an incorrect state and this approach does
not make sense.
Please allocate the cpumasks when we allocate the PMU. Then we can reasonably
fail to probe the PMU if we don't have enough memory, and the masks will
definitely be accessible in gotplug paths.
The same comment applies to the whole series.
Mark.
> +
> + ret = cpumask_and(node_online_cpus,
> cpumask_of_node(cpu_to_node(cpu)), cpu_online_mask);
> if (ret)
> - target = cpumask_any_but(&node_online_cpus, cpu);
> + target = cpumask_any_but(node_online_cpus, cpu);
> else
> target = cpumask_any_but(cpu_online_mask, cpu);
>
> if (target >= nr_cpu_ids)
> - return 0;
> + goto __free_cpumask;
>
> /* We're only reading, but this isn't the place to be involving RCU */
> mutex_lock(&ali_drw_pmu_irqs_lock);
> @@ -772,6 +775,8 @@ static int ali_drw_pmu_offline_cpu(unsigned int cpu, struct hlist_node *node)
> WARN_ON(irq_set_affinity_hint(irq->irq_num, cpumask_of(target)));
> irq->cpu = target;
>
> +__free_cpumask:
> + free_cpumask_var(node_online_cpus);
> return 0;
> }
>
> --
> 2.27.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: [EXT] Re: [PATCH v10 03/11] arm64: dts: imx8ulp-evk: enable usb nodes and add ptn5150 nodes
From: Xu Yang @ 2024-04-02 11:06 UTC (permalink / raw)
To: Shawn Guo
Cc: gregkh@linuxfoundation.org, robh+dt@kernel.org,
krzysztof.kozlowski+dt@linaro.org, shawnguo@kernel.org,
conor+dt@kernel.org, s.hauer@pengutronix.de,
kernel@pengutronix.de, festevam@gmail.com, dl-linux-imx,
peter.chen@kernel.org, Jun Li, linux-usb@vger.kernel.org,
devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
imx@lists.linux.dev, linux-kernel@vger.kernel.org
In-Reply-To: <ZgvDTPiBM65l3F+U@dragon>
>
> On Thu, Mar 21, 2024 at 04:14:31PM +0800, Xu Yang wrote:
> > Enable 2 USB nodes and add 2 PTN5150 nodes on i.MX8ULP evk board.
> >
> > Signed-off-by: Xu Yang <xu.yang_2@nxp.com>
> >
> > ---
> > Changes in v2:
> > - fix format as suggusted by Fabio
> > - add PTN5150 nodes
> > Changes in v3:
> > - no changes
> > Changes in v4:
> > - no changes
> > Changes in v5:
> > - no changes
> > Changes in v6:
> > - no changes
> > Changes in v7:
> > - no changes
> > Changes in v8:
> > - no changes
> > Changes in v9:
> > - no changes
> > Changes in v10:
> > - no changes
> > ---
> > arch/arm64/boot/dts/freescale/imx8ulp-evk.dts | 84 +++++++++++++++++++
> > 1 file changed, 84 insertions(+)
> >
> > diff --git a/arch/arm64/boot/dts/freescale/imx8ulp-evk.dts b/arch/arm64/boot/dts/freescale/imx8ulp-evk.dts
> > index 69dd8e31027c..bf418af31039 100644
> > --- a/arch/arm64/boot/dts/freescale/imx8ulp-evk.dts
> > +++ b/arch/arm64/boot/dts/freescale/imx8ulp-evk.dts
> > @@ -133,6 +133,64 @@ pcal6408: gpio@21 {
> > gpio-controller;
> > #gpio-cells = <2>;
> > };
> > +
> > + ptn5150_1: typec@1d {
>
> Could you sort devices in unit-address?
Okay.
>
> > + compatible = "nxp,ptn5150";
> > + reg = <0x1d>;
> > + int-gpios = <&gpiof 3 IRQ_TYPE_EDGE_FALLING>;
> > + pinctrl-names = "default";
> > + pinctrl-0 = <&pinctrl_typec1>;
> > + status = "disabled";
> > + };
> > +
> > + ptn5150_2: typec@3d {
> > + compatible = "nxp,ptn5150";
> > + reg = <0x3d>;
> > + int-gpios = <&gpiof 5 IRQ_TYPE_EDGE_FALLING>;
> > + pinctrl-names = "default";
>
> Broken indent?
Yes, will fix it.
Thanks,
Xu Yang
>
> Shawn
>
> > + pinctrl-0 = <&pinctrl_typec2>;
> > + status = "disabled";
> > + };
> > +};
> > +
> > +&usbotg1 {
> > + pinctrl-names = "default";
> > + pinctrl-0 = <&pinctrl_usb1>;
> > + dr_mode = "otg";
> > + hnp-disable;
> > + srp-disable;
> > + adp-disable;
> > + over-current-active-low;
> > + status = "okay";
> > +};
> > +
> > +&usbphy1 {
> > + fsl,tx-d-cal = <110>;
> > + status = "okay";
> > +};
> > +
> > +&usbmisc1 {
> > + status = "okay";
> > +};
> > +
> > +&usbotg2 {
> > + pinctrl-names = "default";
> > + pinctrl-0 = <&pinctrl_usb2>;
> > + dr_mode = "otg";
> > + hnp-disable;
> > + srp-disable;
> > + adp-disable;
> > + over-current-active-low;
> > + status = "okay";
> > +};
> > +
> > +&usbphy2 {
> > + fsl,tx-d-cal = <110>;
> > + status = "okay";
> > +};
> > +
> > +&usbmisc2 {
> > + status = "okay";
> > };
> >
> > &usdhc0 {
> > @@ -224,6 +282,32 @@ MX8ULP_PAD_PTE13__LPI2C7_SDA 0x20
> > >;
> > };
> >
> > + pinctrl_typec1: typec1grp {
> > + fsl,pins = <
> > + MX8ULP_PAD_PTF3__PTF3 0x3
> > + >;
> > + };
> > +
> > + pinctrl_typec2: typec2grp {
> > + fsl,pins = <
> > + MX8ULP_PAD_PTF5__PTF5 0x3
> > + >;
> > + };
> > +
> > + pinctrl_usb1: usb1grp {
> > + fsl,pins = <
> > + MX8ULP_PAD_PTF2__USB0_ID 0x10003
> > + MX8ULP_PAD_PTF4__USB0_OC 0x10003
> > + >;
> > + };
> > +
> > + pinctrl_usb2: usb2grp {
> > + fsl,pins = <
> > + MX8ULP_PAD_PTD23__USB1_ID 0x10003
> > + MX8ULP_PAD_PTF6__USB1_OC 0x10003
> > + >;
> > + };
> > +
> > pinctrl_usdhc0: usdhc0grp {
> > fsl,pins = <
> > MX8ULP_PAD_PTD1__SDHC0_CMD 0x3
> > --
> > 2.34.1
> >
_______________________________________________
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 v1 6/6] clk: meson: a1: add Amlogic A1 CPU clock controller driver
From: Dmitry Rokosov @ 2024-04-02 11:05 UTC (permalink / raw)
To: Jerome Brunet
Cc: neil.armstrong, mturquette, sboyd, robh+dt,
krzysztof.kozlowski+dt, khilman, martin.blumenstingl, kernel,
rockosov, linux-amlogic, linux-clk, devicetree, linux-kernel,
linux-arm-kernel
In-Reply-To: <1jv850hyvm.fsf@starbuckisacylon.baylibre.com>
Hello Jerome,
On Tue, Apr 02, 2024 at 11:35:49AM +0200, Jerome Brunet wrote:
>
> On Fri 29 Mar 2024 at 23:58, Dmitry Rokosov <ddrokosov@salutedevices.com> wrote:
>
> > The CPU clock controller plays a general role in the Amlogic A1 SoC
> > family by generating CPU clocks. As an APB slave module, it offers the
> > capability to inherit the CPU clock from two sources: the internal fixed
> > clock known as 'cpu fixed clock' and the external input provided by the
> > A1 PLL clock controller, referred to as 'syspll'.
> >
> > It is important for the driver to handle cpu_clk rate switching
> > effectively by transitioning to the CPU fixed clock to avoid any
> > potential execution freezes.
> >
> > Signed-off-by: Dmitry Rokosov <ddrokosov@salutedevices.com>
> > ---
> > drivers/clk/meson/Kconfig | 10 ++
> > drivers/clk/meson/Makefile | 1 +
> > drivers/clk/meson/a1-cpu.c | 324 +++++++++++++++++++++++++++++++++++++
> > drivers/clk/meson/a1-cpu.h | 16 ++
> > 4 files changed, 351 insertions(+)
> > create mode 100644 drivers/clk/meson/a1-cpu.c
> > create mode 100644 drivers/clk/meson/a1-cpu.h
> >
> > diff --git a/drivers/clk/meson/Kconfig b/drivers/clk/meson/Kconfig
> > index 80c4a18c83d2..148d4495eee3 100644
> > --- a/drivers/clk/meson/Kconfig
> > +++ b/drivers/clk/meson/Kconfig
> > @@ -111,6 +111,16 @@ config COMMON_CLK_AXG_AUDIO
> > Support for the audio clock controller on AmLogic A113D devices,
> > aka axg, Say Y if you want audio subsystem to work.
> >
> > +config COMMON_CLK_A1_CPU
> > + tristate "Amlogic A1 SoC CPU controller support"
> > + depends on ARM64
> > + select COMMON_CLK_MESON_REGMAP
> > + select COMMON_CLK_MESON_CLKC_UTILS
> > + help
> > + Support for the CPU clock controller on Amlogic A113L based
> > + device, A1 SoC Family. Say Y if you want A1 CPU clock controller
> > + to work.
> > +
> > config COMMON_CLK_A1_PLL
> > tristate "Amlogic A1 SoC PLL controller support"
> > depends on ARM64
> > diff --git a/drivers/clk/meson/Makefile b/drivers/clk/meson/Makefile
> > index 4968fc7ad555..2a06eb0303d6 100644
> > --- a/drivers/clk/meson/Makefile
> > +++ b/drivers/clk/meson/Makefile
> > @@ -18,6 +18,7 @@ obj-$(CONFIG_COMMON_CLK_MESON_AUDIO_RSTC) += meson-audio-rstc.o
> >
> > obj-$(CONFIG_COMMON_CLK_AXG) += axg.o axg-aoclk.o
> > obj-$(CONFIG_COMMON_CLK_AXG_AUDIO) += axg-audio.o
> > +obj-$(CONFIG_COMMON_CLK_A1_CPU) += a1-cpu.o
> > obj-$(CONFIG_COMMON_CLK_A1_PLL) += a1-pll.o
> > obj-$(CONFIG_COMMON_CLK_A1_PERIPHERALS) += a1-peripherals.o
> > obj-$(CONFIG_COMMON_CLK_A1_AUDIO) += a1-audio.o
> > diff --git a/drivers/clk/meson/a1-cpu.c b/drivers/clk/meson/a1-cpu.c
> > new file mode 100644
> > index 000000000000..5f5d8ae112e5
> > --- /dev/null
> > +++ b/drivers/clk/meson/a1-cpu.c
> > @@ -0,0 +1,324 @@
> > +// SPDX-License-Identifier: GPL-2.0+
> > +/*
> > + * Amlogic A1 SoC family CPU Clock Controller driver.
> > + *
> > + * Copyright (c) 2024, SaluteDevices. All Rights Reserved.
> > + * Author: Dmitry Rokosov <ddrokosov@salutedevices.com>
> > + */
> > +
> > +#include <linux/clk.h>
> > +#include <linux/clk-provider.h>
> > +#include <linux/mod_devicetable.h>
> > +#include <linux/platform_device.h>
> > +#include "a1-cpu.h"
> > +#include "clk-regmap.h"
> > +#include "meson-clkc-utils.h"
> > +
> > +#include <dt-bindings/clock/amlogic,a1-cpu-clkc.h>
> > +
> > +static u32 cpu_fsource_sel_table[] = { 0, 1, 2 };
> > +static const struct clk_parent_data cpu_fsource_sel_parents[] = {
> > + { .fw_name = "xtal" },
> > + { .fw_name = "fclk_div2" },
> > + { .fw_name = "fclk_div3" },
> > +};
> > +
> > +static struct clk_regmap cpu_fsource_sel0 = {
> > + .data = &(struct clk_regmap_mux_data) {
> > + .offset = CPUCTRL_CLK_CTRL0,
> > + .mask = 0x3,
> > + .shift = 0,
> > + .table = cpu_fsource_sel_table,
> > + },
> > + .hw.init = &(struct clk_init_data) {
> > + .name = "cpu_fsource_sel0",
> > + .ops = &clk_regmap_mux_ops,
> > + .parent_data = cpu_fsource_sel_parents,
> > + .num_parents = ARRAY_SIZE(cpu_fsource_sel_parents),
> > + .flags = CLK_SET_RATE_PARENT,
> > + },
> > +};
> > +
> > +static struct clk_regmap cpu_fsource_div0 = {
> > + .data = &(struct clk_regmap_div_data) {
> > + .offset = CPUCTRL_CLK_CTRL0,
> > + .shift = 4,
> > + .width = 6,
> > + },
> > + .hw.init = &(struct clk_init_data) {
> > + .name = "cpu_fsource_div0",
> > + .ops = &clk_regmap_divider_ops,
> > + .parent_hws = (const struct clk_hw *[]) {
> > + &cpu_fsource_sel0.hw
> > + },
> > + .num_parents = 1,
> > + .flags = CLK_SET_RATE_PARENT,
> > + },
> > +};
> > +
> > +static struct clk_regmap cpu_fsel0 = {
> > + .data = &(struct clk_regmap_mux_data) {
> > + .offset = CPUCTRL_CLK_CTRL0,
> > + .mask = 0x1,
> > + .shift = 2,
> > + },
> > + .hw.init = &(struct clk_init_data) {
> > + .name = "cpu_fsel0",
> > + .ops = &clk_regmap_mux_ops,
> > + .parent_hws = (const struct clk_hw *[]) {
> > + &cpu_fsource_sel0.hw,
> > + &cpu_fsource_div0.hw,
> > + },
> > + .num_parents = 2,
> > + .flags = CLK_SET_RATE_PARENT,
> > + },
> > +};
> > +
> > +static struct clk_regmap cpu_fsource_sel1 = {
> > + .data = &(struct clk_regmap_mux_data) {
> > + .offset = CPUCTRL_CLK_CTRL0,
> > + .mask = 0x3,
> > + .shift = 16,
> > + .table = cpu_fsource_sel_table,
> > + },
> > + .hw.init = &(struct clk_init_data) {
> > + .name = "cpu_fsource_sel1",
> > + .ops = &clk_regmap_mux_ops,
> > + .parent_data = cpu_fsource_sel_parents,
> > + .num_parents = ARRAY_SIZE(cpu_fsource_sel_parents),
> > + .flags = CLK_SET_RATE_PARENT,
> > + },
> > +};
> > +
> > +static struct clk_regmap cpu_fsource_div1 = {
> > + .data = &(struct clk_regmap_div_data) {
> > + .offset = CPUCTRL_CLK_CTRL0,
> > + .shift = 20,
> > + .width = 6,
> > + },
> > + .hw.init = &(struct clk_init_data) {
> > + .name = "cpu_fsource_div1",
> > + .ops = &clk_regmap_divider_ops,
> > + .parent_hws = (const struct clk_hw *[]) {
> > + &cpu_fsource_sel1.hw
> > + },
> > + .num_parents = 1,
> > + .flags = CLK_SET_RATE_PARENT,
> > + },
> > +};
> > +
> > +static struct clk_regmap cpu_fsel1 = {
> > + .data = &(struct clk_regmap_mux_data) {
> > + .offset = CPUCTRL_CLK_CTRL0,
> > + .mask = 0x1,
> > + .shift = 18,
> > + },
> > + .hw.init = &(struct clk_init_data) {
> > + .name = "cpu_fsel1",
> > + .ops = &clk_regmap_mux_ops,
> > + .parent_hws = (const struct clk_hw *[]) {
> > + &cpu_fsource_sel1.hw,
> > + &cpu_fsource_div1.hw,
> > + },
> > + .num_parents = 2,
> > + .flags = CLK_SET_RATE_PARENT,
> > + },
> > +};
> > +
> > +static struct clk_regmap cpu_fclk = {
> > + .data = &(struct clk_regmap_mux_data) {
> > + .offset = CPUCTRL_CLK_CTRL0,
> > + .mask = 0x1,
> > + .shift = 10,
> > + },
> > + .hw.init = &(struct clk_init_data) {
> > + .name = "cpu_fclk",
> > + .ops = &clk_regmap_mux_ops,
> > + .parent_hws = (const struct clk_hw *[]) {
> > + &cpu_fsel0.hw,
> > + &cpu_fsel1.hw,
> > + },
> > + .num_parents = 2,
> > + .flags = CLK_SET_RATE_PARENT,
> > + },
> > +};
> > +
> > +static struct clk_regmap cpu_clk = {
> > + .data = &(struct clk_regmap_mux_data) {
> > + .offset = CPUCTRL_CLK_CTRL0,
> > + .mask = 0x1,
> > + .shift = 11,
> > + },
> > + .hw.init = &(struct clk_init_data) {
> > + .name = "cpu_clk",
> > + .ops = &clk_regmap_mux_ops,
> > + .parent_data = (const struct clk_parent_data []) {
> > + { .hw = &cpu_fclk.hw },
> > + { .fw_name = "sys_pll", },
> > + },
> > + .num_parents = 2,
> > + .flags = CLK_SET_RATE_PARENT | CLK_IS_CRITICAL,
> > + },
> > +};
> > +
> > +/* Array of all clocks registered by this provider */
> > +static struct clk_hw *a1_cpu_hw_clks[] = {
> > + [CLKID_CPU_FSOURCE_SEL0] = &cpu_fsource_sel0.hw,
> > + [CLKID_CPU_FSOURCE_DIV0] = &cpu_fsource_div0.hw,
> > + [CLKID_CPU_FSEL0] = &cpu_fsel0.hw,
> > + [CLKID_CPU_FSOURCE_SEL1] = &cpu_fsource_sel1.hw,
> > + [CLKID_CPU_FSOURCE_DIV1] = &cpu_fsource_div1.hw,
> > + [CLKID_CPU_FSEL1] = &cpu_fsel1.hw,
> > + [CLKID_CPU_FCLK] = &cpu_fclk.hw,
> > + [CLKID_CPU_CLK] = &cpu_clk.hw,
> > +};
> > +
> > +static struct clk_regmap *const a1_cpu_regmaps[] = {
> > + &cpu_fsource_sel0,
> > + &cpu_fsource_div0,
> > + &cpu_fsel0,
> > + &cpu_fsource_sel1,
> > + &cpu_fsource_div1,
> > + &cpu_fsel1,
> > + &cpu_fclk,
> > + &cpu_clk,
> > +};
> > +
> > +static struct regmap_config a1_cpu_regmap_cfg = {
> > + .reg_bits = 32,
> > + .val_bits = 32,
> > + .reg_stride = 4,
> > + .max_register = CPUCTRL_CLK_CTRL1,
> > +};
> > +
> > +static struct meson_clk_hw_data a1_cpu_clks = {
> > + .hws = a1_cpu_hw_clks,
> > + .num = ARRAY_SIZE(a1_cpu_hw_clks),
> > +};
> > +
> > +struct a1_cpu_clk_nb_data {
> > + const struct clk_ops *mux_ops;
>
> That's fishy ...
>
> > + struct clk_hw *cpu_clk;
> > + struct notifier_block nb;
> > + u8 parent;
> > +};
> > +
> > +#define MESON_A1_CPU_CLK_GET_PARENT(nbd) \
> > + ((nbd)->mux_ops->get_parent((nbd)->cpu_clk))
> > +#define MESON_A1_CPU_CLK_SET_PARENT(nbd, index) \
> > + ((nbd)->mux_ops->set_parent((nbd)->cpu_clk, index))
>
> ... Directly going for the mux ops ??!?? No way !
>
> We have a framework to handle the clocks, the whole point is to use it,
> not bypass it !
>
I suppose you understand my approach, which is quite similar to what is
happening in the Mediatek driver:
https://elixir.bootlin.com/linux/latest/source/drivers/clk/mediatek/clk-mux.c#L295
Initially, I attempted to set the parent using the clk_set_parent() API.
However, I encountered a problem with recursive calling of the
notifier_block. This issue arises because the parent triggers
notifications for its children, leading to repeated calls to the
notifier_block.
I find it puzzling why I cannot call an internal function or callback
within the internal driver context. After all, the notifier block is
just a part of the set_rate() flow. From a global Clock Control
Framework perspective, the context should not change.
> > +
> > +static int meson_a1_cpu_clk_notifier_cb(struct notifier_block *nb,
> > + unsigned long event, void *data)
> > +{
> > + struct a1_cpu_clk_nb_data *nbd;
> > + int ret = 0;
> > +
> > + nbd = container_of(nb, struct a1_cpu_clk_nb_data, nb);
> > +
> > + switch (event) {
> > + case PRE_RATE_CHANGE:
> > + nbd->parent = MESON_A1_CPU_CLK_GET_PARENT(nbd);
> > + /* Fallback to the CPU fixed clock */
> > + ret = MESON_A1_CPU_CLK_SET_PARENT(nbd, 0);
> > + /* Wait for clock propagation */
> > + udelay(100);
> > + break;
> > +
> > + case POST_RATE_CHANGE:
> > + case ABORT_RATE_CHANGE:
> > + /* Back to the original parent clock */
> > + ret = MESON_A1_CPU_CLK_SET_PARENT(nbd, nbd->parent);
> > + /* Wait for clock propagation */
> > + udelay(100);
> > + break;
> > +
> > + default:
> > + pr_warn("Unknown event %lu for %s notifier block\n",
> > + event, clk_hw_get_name(nbd->cpu_clk));
> > + break;
> > + }
> > +
> > + return notifier_from_errno(ret);
> > +}
> > +
> > +static struct a1_cpu_clk_nb_data a1_cpu_clk_nb_data = {
> > + .mux_ops = &clk_regmap_mux_ops,
> > + .cpu_clk = &cpu_clk.hw,
> > + .nb.notifier_call = meson_a1_cpu_clk_notifier_cb,
> > +};
> > +
> > +static int meson_a1_dvfs_setup(struct platform_device *pdev)
> > +{
> > + struct device *dev = &pdev->dev;
> > + struct clk *notifier_clk;
> > + int ret;
> > +
> > + /* Setup clock notifier for cpu_clk */
> > + notifier_clk = devm_clk_hw_get_clk(dev, &cpu_clk.hw, "dvfs");
> > + if (IS_ERR(notifier_clk))
> > + return dev_err_probe(dev, PTR_ERR(notifier_clk),
> > + "can't get cpu_clk as notifier clock\n");
> > +
> > + ret = devm_clk_notifier_register(dev, notifier_clk,
> > + &a1_cpu_clk_nb_data.nb);
> > + if (ret)
> > + return dev_err_probe(dev, ret,
> > + "can't register cpu_clk notifier\n");
> > +
> > + return ret;
> > +}
> > +
> > +static int meson_a1_cpu_probe(struct platform_device *pdev)
> > +{
> > + struct device *dev = &pdev->dev;
> > + void __iomem *base;
> > + struct regmap *map;
> > + int clkid, i, err;
> > +
> > + base = devm_platform_ioremap_resource(pdev, 0);
> > + if (IS_ERR(base))
> > + return dev_err_probe(dev, PTR_ERR(base),
> > + "can't ioremap resource\n");
> > +
> > + map = devm_regmap_init_mmio(dev, base, &a1_cpu_regmap_cfg);
> > + if (IS_ERR(map))
> > + return dev_err_probe(dev, PTR_ERR(map),
> > + "can't init regmap mmio region\n");
> > +
> > + /* Populate regmap for the regmap backed clocks */
> > + for (i = 0; i < ARRAY_SIZE(a1_cpu_regmaps); i++)
> > + a1_cpu_regmaps[i]->map = map;
> > +
> > + for (clkid = 0; clkid < a1_cpu_clks.num; clkid++) {
> > + err = devm_clk_hw_register(dev, a1_cpu_clks.hws[clkid]);
> > + if (err)
> > + return dev_err_probe(dev, err,
> > + "clock[%d] registration failed\n",
> > + clkid);
> > + }
> > +
> > + err = devm_of_clk_add_hw_provider(dev, meson_clk_hw_get, &a1_cpu_clks);
> > + if (err)
> > + return dev_err_probe(dev, err, "can't add clk hw provider\n");
>
> I wonder if there is a window of opportunity to poke the syspll without
> your notifier here. That being said, the situation would be similar on g12.
>
Yes, I have taken into account what you did in the G12A CPU clock
relations. My thoughts were that it might not be applicable for the A1
case. This is because the sys_pll should be located in a different
driver from a logical perspective. Consequently, we cannot configure the
sys_pll notifier block to manage the cpu_clk from a different driver.
However, if I were to move the sys_pll clock object to the A1 CPU clock
controller, I believe the g12a sys_pll notifier approach would work.
> > +
> > + return meson_a1_dvfs_setup(pdev);
>
>
>
> > +}
> > +
> > +static const struct of_device_id a1_cpu_clkc_match_table[] = {
> > + { .compatible = "amlogic,a1-cpu-clkc", },
> > + {}
> > +};
> > +MODULE_DEVICE_TABLE(of, a1_cpu_clkc_match_table);
> > +
> > +static struct platform_driver a1_cpu_clkc_driver = {
> > + .probe = meson_a1_cpu_probe,
> > + .driver = {
> > + .name = "a1-cpu-clkc",
> > + .of_match_table = a1_cpu_clkc_match_table,
> > + },
> > +};
> > +
> > +module_platform_driver(a1_cpu_clkc_driver);
> > +MODULE_AUTHOR("Dmitry Rokosov <ddrokosov@salutedevices.com>");
> > +MODULE_LICENSE("GPL");
> > diff --git a/drivers/clk/meson/a1-cpu.h b/drivers/clk/meson/a1-cpu.h
> > new file mode 100644
> > index 000000000000..e9af4117e26f
> > --- /dev/null
> > +++ b/drivers/clk/meson/a1-cpu.h
>
> There is not point putting the definition here in a header
> These are clearly not going to be shared with another driver.
>
> Please drop this file
>
The same approach was applied to the Peripherals and PLL A1 drivers.
Honestly, I am not a fan of having different file organization within a
single logical code folder.
Please refer to:
drivers/clk/meson/a1-peripherals.h
drivers/clk/meson/a1-pll.h
> > @@ -0,0 +1,16 @@
> > +/* SPDX-License-Identifier: GPL-2.0+ */
> > +/*
> > + * Amlogic A1 CPU Clock Controller internals
> > + *
> > + * Copyright (c) 2024, SaluteDevices. All Rights Reserved.
> > + * Author: Dmitry Rokosov <ddrokosov@salutedevices.com>
> > + */
> > +
> > +#ifndef __A1_CPU_H
> > +#define __A1_CPU_H
> > +
> > +/* cpu clock controller register offset */
> > +#define CPUCTRL_CLK_CTRL0 0x80
> > +#define CPUCTRL_CLK_CTRL1 0x84
>
> You are claiming the registers from 0x00 to 0x84 (included), but only
> using these 2 registers ? What is the rest ? Are you sure there is only
> clocks in there ?
>
Yes, unfortunately, the register map for this IP is not described in the
A1 Datasheet. The only available information about it can be found in
the vendor clock driver, which provides details for only two registers
used to configure the CPU clock.
From vendor kernel dtsi:
clkc: clock-controller {
compatible = "amlogic,a1-clkc";
#clock-cells = <1>;
reg = <0x0 0xfe000800 0x0 0x100>,
<0x0 0xfe007c00 0x0 0x21c>,
<0x0 0xfd000000 0x0 0x88>; <==== CPU clock regmap
reg-names = "basic", "pll",
"cpu_clk";
clocks = <&xtal>;
clock-names = "core";
status = "okay";
};
From vendor clkc driver:
/*
* CPU clok register offset
* APB_BASE: APB1_BASE_ADDR = 0xfd000000
*/
#define CPUCTRL_CLK_CTRL0 0x80
#define CPUCTRL_CLK_CTRL1 0x84
[...]
--
Thank you,
Dmitry
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH 9/9] perf/thunder_x2: Avoid explicit cpumask var allocation from stack
From: Dawei Li @ 2024-04-02 10:56 UTC (permalink / raw)
To: will, mark.rutland
Cc: xueshuai, renyu.zj, yangyicong, jonathan.cameron, andersson,
konrad.dybcio, linux-arm-kernel, linux-kernel, linux-arm-msm,
Dawei Li
In-Reply-To: <20240402105610.1695644-1-dawei.li@shingroup.cn>
For CONFIG_CPUMASK_OFFSTACK=y kernel, explicit allocation of cpumask
variable on stack is not recommended since it can cause potential stack
overflow.
Instead, kernel code should always use *cpumask_var API(s) to allocate
cpumask var in config- neutral way, leaving allocation strategy to
CONFIG_CPUMASK_OFFSTACK.
Use *cpumask_var API(s) to address it.
Signed-off-by: Dawei Li <dawei.li@shingroup.cn>
---
drivers/perf/thunderx2_pmu.c | 20 ++++++++++++--------
1 file changed, 12 insertions(+), 8 deletions(-)
diff --git a/drivers/perf/thunderx2_pmu.c b/drivers/perf/thunderx2_pmu.c
index e16d10c763de..8a02a4533b32 100644
--- a/drivers/perf/thunderx2_pmu.c
+++ b/drivers/perf/thunderx2_pmu.c
@@ -932,9 +932,9 @@ static int tx2_uncore_pmu_online_cpu(unsigned int cpu,
static int tx2_uncore_pmu_offline_cpu(unsigned int cpu,
struct hlist_node *hpnode)
{
- int new_cpu;
+ cpumask_var_t cpu_online_mask_temp;
struct tx2_uncore_pmu *tx2_pmu;
- struct cpumask cpu_online_mask_temp;
+ int new_cpu;
tx2_pmu = hlist_entry_safe(hpnode,
struct tx2_uncore_pmu, hpnode);
@@ -945,17 +945,21 @@ static int tx2_uncore_pmu_offline_cpu(unsigned int cpu,
if (tx2_pmu->hrtimer_callback)
hrtimer_cancel(&tx2_pmu->hrtimer);
- cpumask_copy(&cpu_online_mask_temp, cpu_online_mask);
- cpumask_clear_cpu(cpu, &cpu_online_mask_temp);
- new_cpu = cpumask_any_and(
- cpumask_of_node(tx2_pmu->node),
- &cpu_online_mask_temp);
+ if (!alloc_cpumask_var(&cpu_online_mask_temp, GFP_KERNEL))
+ return 0;
+
+ cpumask_copy(cpu_online_mask_temp, cpu_online_mask);
+ cpumask_clear_cpu(cpu, cpu_online_mask_temp);
+ new_cpu = cpumask_any_and(cpumask_of_node(tx2_pmu->node),
+ cpu_online_mask_temp);
tx2_pmu->cpu = new_cpu;
if (new_cpu >= nr_cpu_ids)
- return 0;
+ goto __free_cpumask;
perf_pmu_migrate_context(&tx2_pmu->pmu, cpu, new_cpu);
+__free_cpumask:
+ free_cpumask_var(cpu_online_mask_temp);
return 0;
}
--
2.27.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 8/9] perf/qcom_l2: Avoid explicit cpumask var allocation from stack
From: Dawei Li @ 2024-04-02 10:56 UTC (permalink / raw)
To: will, mark.rutland
Cc: xueshuai, renyu.zj, yangyicong, jonathan.cameron, andersson,
konrad.dybcio, linux-arm-kernel, linux-kernel, linux-arm-msm,
Dawei Li
In-Reply-To: <20240402105610.1695644-1-dawei.li@shingroup.cn>
For CONFIG_CPUMASK_OFFSTACK=y kernel, explicit allocation of cpumask
variable on stack is not recommended since it can cause potential stack
overflow.
Instead, kernel code should always use *cpumask_var API(s) to allocate
cpumask var in config- neutral way, leaving allocation strategy to
CONFIG_CPUMASK_OFFSTACK.
Use *cpumask_var API(s) to address it.
Signed-off-by: Dawei Li <dawei.li@shingroup.cn>
---
drivers/perf/qcom_l2_pmu.c | 15 ++++++++++-----
1 file changed, 10 insertions(+), 5 deletions(-)
diff --git a/drivers/perf/qcom_l2_pmu.c b/drivers/perf/qcom_l2_pmu.c
index 148df5ae8ef8..8fe0c7557521 100644
--- a/drivers/perf/qcom_l2_pmu.c
+++ b/drivers/perf/qcom_l2_pmu.c
@@ -801,9 +801,9 @@ static int l2cache_pmu_online_cpu(unsigned int cpu, struct hlist_node *node)
static int l2cache_pmu_offline_cpu(unsigned int cpu, struct hlist_node *node)
{
- struct cluster_pmu *cluster;
+ cpumask_var_t cluster_online_cpus;
struct l2cache_pmu *l2cache_pmu;
- cpumask_t cluster_online_cpus;
+ struct cluster_pmu *cluster;
unsigned int target;
l2cache_pmu = hlist_entry_safe(node, struct l2cache_pmu, node);
@@ -815,17 +815,20 @@ static int l2cache_pmu_offline_cpu(unsigned int cpu, struct hlist_node *node)
if (cluster->on_cpu != cpu)
return 0;
+ if (!alloc_cpumask_var(&cluster_online_cpus, GFP_KERNEL))
+ return 0;
+
/* Give up ownership of cluster */
cpumask_clear_cpu(cpu, &l2cache_pmu->cpumask);
cluster->on_cpu = -1;
/* Any other CPU for this cluster which is still online */
- cpumask_and(&cluster_online_cpus, &cluster->cluster_cpus,
+ cpumask_and(cluster_online_cpus, &cluster->cluster_cpus,
cpu_online_mask);
- target = cpumask_any_but(&cluster_online_cpus, cpu);
+ target = cpumask_any_but(cluster_online_cpus, cpu);
if (target >= nr_cpu_ids) {
disable_irq(cluster->irq);
- return 0;
+ goto __free_cpumask;
}
perf_pmu_migrate_context(&l2cache_pmu->pmu, cpu, target);
@@ -833,6 +836,8 @@ static int l2cache_pmu_offline_cpu(unsigned int cpu, struct hlist_node *node)
cpumask_set_cpu(target, &l2cache_pmu->cpumask);
WARN_ON(irq_set_affinity(cluster->irq, cpumask_of(target)));
+__free_cpumask:
+ free_cpumask_var(cluster_online_cpus);
return 0;
}
--
2.27.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
* Re: [PATCH 0/7] mmc/wifi/bluetooth: store owner from modules with sdio_register_driver()
From: Ulf Hansson @ 2024-04-02 10:57 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Marcel Holtmann, Luiz Augusto von Dentz, Matthias Brugger,
AngeloGioacchino Del Regno, Kalle Valo, Jeff Johnson,
Arend van Spriel, Brian Norris, Jérôme Pouiller,
linux-mmc, linux-kernel, linux-bluetooth, linux-arm-kernel,
linux-mediatek, linux-wireless, ath10k, brcm80211,
brcm80211-dev-list.pdl
In-Reply-To: <20240329-module-owner-sdio-v1-0-e4010b11ccaa@linaro.org>
On Fri, 29 Mar 2024 at 18:24, Krzysztof Kozlowski
<krzysztof.kozlowski@linaro.org> wrote:
>
> Merging
> =======
> All further patches depend on the first patch. Everything could go via
> one tree, e.g. MMC, or the cleanup patches removing owner would wait a
> cycle.
Patch 1 applied for next, thanks!
I can certainly pick the remaining in the series through my mmc tree,
but waiting a bit to queue them up to allow some more acks to be
received.
Kind regards
Uffe
>
> Description
> ===========
> Modules registering driver with sdio_register_driver() might
> forget to set .owner field.
>
> Solve the problem by moving this task away from the drivers to the core
> code, just like we did for platform_driver in commit 9447057eaff8
> ("platform_device: use a macro instead of platform_driver_register").
>
> Best regards,
> Krzysztof
>
> ---
> Krzysztof Kozlowski (7):
> mmc: sdio: store owner from modules with sdio_register_driver()
> bluetooth: btmrvl_sdio: drop driver owner initialization
> bluetooth: btmtksdio: drop driver owner initialization
> wifi: ath10k: sdio: drop driver owner initialization
> wifi: brcm80211: drop driver owner initialization
> wifi: marvell: mwifiex: drop driver owner initialization
> wifi: silabs: wfx: drop driver owner initialization
>
> drivers/bluetooth/btmrvl_sdio.c | 1 -
> drivers/bluetooth/btmtksdio.c | 1 -
> drivers/mmc/core/sdio_bus.c | 9 ++++++---
> drivers/net/wireless/ath/ath10k/sdio.c | 1 -
> drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c | 1 -
> drivers/net/wireless/marvell/mwifiex/sdio.c | 1 -
> drivers/net/wireless/silabs/wfx/bus_sdio.c | 1 -
> include/linux/mmc/sdio_func.h | 5 ++++-
> 8 files changed, 10 insertions(+), 10 deletions(-)
> ---
> base-commit: 087c142b2b04898c897aa77938d05a93907150e5
> change-id: 20240329-module-owner-sdio-abd5de3f1d74
>
> 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
* [PATCH 3/9] perf/arm_cspmu: Avoid explicit cpumask var allocation from stack
From: Dawei Li @ 2024-04-02 10:56 UTC (permalink / raw)
To: will, mark.rutland
Cc: xueshuai, renyu.zj, yangyicong, jonathan.cameron, andersson,
konrad.dybcio, linux-arm-kernel, linux-kernel, linux-arm-msm,
Dawei Li
In-Reply-To: <20240402105610.1695644-1-dawei.li@shingroup.cn>
For CONFIG_CPUMASK_OFFSTACK=y kernel, explicit allocation of cpumask
variable on stack is not recommended since it can cause potential stack
overflow.
Instead, kernel code should always use *cpumask_var API(s) to allocate
cpumask var in config- neutral way, leaving allocation strategy to
CONFIG_CPUMASK_OFFSTACK.
Use *cpumask_var API(s) to address it.
Signed-off-by: Dawei Li <dawei.li@shingroup.cn>
---
drivers/perf/arm_cspmu/arm_cspmu.c | 13 +++++++++----
1 file changed, 9 insertions(+), 4 deletions(-)
diff --git a/drivers/perf/arm_cspmu/arm_cspmu.c b/drivers/perf/arm_cspmu/arm_cspmu.c
index b9a252272f1e..8fa7c26aec28 100644
--- a/drivers/perf/arm_cspmu/arm_cspmu.c
+++ b/drivers/perf/arm_cspmu/arm_cspmu.c
@@ -1322,8 +1322,8 @@ static int arm_cspmu_cpu_online(unsigned int cpu, struct hlist_node *node)
static int arm_cspmu_cpu_teardown(unsigned int cpu, struct hlist_node *node)
{
+ cpumask_var_t online_supported;
int dst;
- struct cpumask online_supported;
struct arm_cspmu *cspmu =
hlist_entry_safe(node, struct arm_cspmu, cpuhp_node);
@@ -1332,17 +1332,22 @@ static int arm_cspmu_cpu_teardown(unsigned int cpu, struct hlist_node *node)
if (!cpumask_test_and_clear_cpu(cpu, &cspmu->active_cpu))
return 0;
+ if (!alloc_cpumask_var(&online_supported, GFP_KERNEL))
+ return 0;
+
/* Choose a new CPU to migrate ownership of the PMU to */
- cpumask_and(&online_supported, &cspmu->associated_cpus,
+ cpumask_and(online_supported, &cspmu->associated_cpus,
cpu_online_mask);
- dst = cpumask_any_but(&online_supported, cpu);
+ dst = cpumask_any_but(online_supported, cpu);
if (dst >= nr_cpu_ids)
- return 0;
+ goto __free_cpumask;
/* Use this CPU for event counting */
perf_pmu_migrate_context(&cspmu->pmu, cpu, dst);
arm_cspmu_set_active_cpu(dst, cspmu);
+__free_cpumask:
+ free_cpumask_var(online_supported);
return 0;
}
--
2.27.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 5/9] perf/dwc_pcie: Avoid explicit cpumask var allocation from stack
From: Dawei Li @ 2024-04-02 10:56 UTC (permalink / raw)
To: will, mark.rutland
Cc: xueshuai, renyu.zj, yangyicong, jonathan.cameron, andersson,
konrad.dybcio, linux-arm-kernel, linux-kernel, linux-arm-msm,
Dawei Li
In-Reply-To: <20240402105610.1695644-1-dawei.li@shingroup.cn>
For CONFIG_CPUMASK_OFFSTACK=y kernel, explicit allocation of cpumask
variable on stack is not recommended since it can cause potential stack
overflow.
Instead, kernel code should always use *cpumask_var API(s) to allocate
cpumask var in config- neutral way, leaving allocation strategy to
CONFIG_CPUMASK_OFFSTACK.
Use *cpumask_var API(s) to address it.
Signed-off-by: Dawei Li <dawei.li@shingroup.cn>
---
drivers/perf/dwc_pcie_pmu.c | 17 +++++++++++------
1 file changed, 11 insertions(+), 6 deletions(-)
diff --git a/drivers/perf/dwc_pcie_pmu.c b/drivers/perf/dwc_pcie_pmu.c
index 957058ad0099..97037b6aaa97 100644
--- a/drivers/perf/dwc_pcie_pmu.c
+++ b/drivers/perf/dwc_pcie_pmu.c
@@ -690,33 +690,38 @@ static int dwc_pcie_pmu_offline_cpu(unsigned int cpu, struct hlist_node *cpuhp_n
{
struct dwc_pcie_pmu *pcie_pmu;
struct pci_dev *pdev;
- int node;
- cpumask_t mask;
unsigned int target;
+ cpumask_var_t mask;
+ int node;
pcie_pmu = hlist_entry_safe(cpuhp_node, struct dwc_pcie_pmu, cpuhp_node);
/* Nothing to do if this CPU doesn't own the PMU */
if (cpu != pcie_pmu->on_cpu)
return 0;
+ if (!alloc_cpumask_var(&mask, GFP_KERNEL))
+ return 0;
+
pcie_pmu->on_cpu = -1;
pdev = pcie_pmu->pdev;
node = dev_to_node(&pdev->dev);
- if (cpumask_and(&mask, cpumask_of_node(node), cpu_online_mask) &&
- cpumask_andnot(&mask, &mask, cpumask_of(cpu)))
- target = cpumask_any(&mask);
+ if (cpumask_and(mask, cpumask_of_node(node), cpu_online_mask) &&
+ cpumask_andnot(mask, mask, cpumask_of(cpu)))
+ target = cpumask_any(mask);
else
target = cpumask_any_but(cpu_online_mask, cpu);
if (target >= nr_cpu_ids) {
pci_err(pdev, "There is no CPU to set\n");
- return 0;
+ goto __free_cpumask;
}
/* This PMU does NOT support interrupt, just migrate context. */
perf_pmu_migrate_context(&pcie_pmu->pmu, cpu, target);
pcie_pmu->on_cpu = target;
+__free_cpumask:
+ free_cpumask_var(mask);
return 0;
}
--
2.27.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
* RE: [EXT] Re: [PATCH v10 08/11] arm64: dts: imx93: add usb nodes
From: Xu Yang @ 2024-04-02 10:57 UTC (permalink / raw)
To: Shawn Guo
Cc: gregkh@linuxfoundation.org, robh+dt@kernel.org,
krzysztof.kozlowski+dt@linaro.org, shawnguo@kernel.org,
conor+dt@kernel.org, s.hauer@pengutronix.de,
kernel@pengutronix.de, festevam@gmail.com, dl-linux-imx,
peter.chen@kernel.org, Jun Li, linux-usb@vger.kernel.org,
devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
imx@lists.linux.dev, linux-kernel@vger.kernel.org
In-Reply-To: <ZgvEXZTOHUv+GGeH@dragon>
Hi Shawn,
>
> On Thu, Mar 21, 2024 at 04:14:36PM +0800, Xu Yang wrote:
> > There are 2 USB controllers on i.MX93. Add them.
> >
> > Acked-by: Alexander Stein <alexander.stein@ew.tq-group.com>
> > Tested-by: Alexander Stein <alexander.stein@ew.tq-group.com> # TQMa9352LA/CA
> > Signed-off-by: Xu Yang <xu.yang_2@nxp.com>
> >
> > ---
> > Changes in v2:
> > - fix format as suggested by Alexander
> > - change compatible from fsl,imx8mm-usb to fsl,imx93-usb
> > Changes in v3:
> > - replace deprecated fsl,usbphy with phys as suggested by Alexander
> > - reorder nodes
> > Changes in v4:
> > - fix the alignment
> > Changes in v5:
> > - rename usb_wakeup_clk to usb_wakeup
> > Changes in v6:
> > - rename usb_ctrl_root_clk to usb_ctrl_root
> > Changes in v7:
> > - no changes
> > Changes in v8:
> > - no changes
> > Changes in v9:
> > - no changes
> > Changes in v10:
> > - no changes
> > ---
> > arch/arm64/boot/dts/freescale/imx93.dtsi | 58 ++++++++++++++++++++++++
> > 1 file changed, 58 insertions(+)
> >
> > diff --git a/arch/arm64/boot/dts/freescale/imx93.dtsi b/arch/arm64/boot/dts/freescale/imx93.dtsi
> > index 8f2e7c42ad6e..4a7efccb4f67 100644
> > --- a/arch/arm64/boot/dts/freescale/imx93.dtsi
> > +++ b/arch/arm64/boot/dts/freescale/imx93.dtsi
> > @@ -183,6 +183,20 @@ mqs2: mqs2 {
> > status = "disabled";
> > };
> >
> > + usbphynop1: usbphynop1 {
> > + compatible = "usb-nop-xceiv";
> > + #phy-cells = <0>;
> > + clocks = <&clk IMX93_CLK_USB_PHY_BURUNIN>;
> > + clock-names = "main_clk";
> > + };
> > +
> > + usbphynop2: usbphynop2 {
> > + compatible = "usb-nop-xceiv";
> > + #phy-cells = <0>;
> > + clocks = <&clk IMX93_CLK_USB_PHY_BURUNIN>;
> > + clock-names = "main_clk";
> > + };
> > +
> > soc@0 {
> > compatible = "simple-bus";
> > #address-cells = <1>;
> > @@ -1167,6 +1181,50 @@ media_blk_ctrl: system-controller@4ac10000 {
> > status = "disabled";
> > };
> >
> > + usbotg1: usb@4c100000 {
> > + compatible = "fsl,imx93-usb", "fsl,imx7d-usb", "fsl,imx27-usb";
> > + reg = <0x4c100000 0x200>;
> > + interrupts = <GIC_SPI 187 IRQ_TYPE_LEVEL_HIGH>;
> > + clocks = <&clk IMX93_CLK_USB_CONTROLLER_GATE>,
> > + <&clk IMX93_CLK_HSIO_32K_GATE>;
> > + clock-names = "usb_ctrl_root", "usb_wakeup";
> > + assigned-clocks = <&clk IMX93_CLK_HSIO>;
> > + assigned-clock-parents = <&clk IMX93_CLK_SYS_PLL_PFD1_DIV2>;
> > + assigned-clock-rates = <133000000>;
> > + phys = <&usbphynop1>;
> > + fsl,usbmisc = <&usbmisc1 0>;
> > + status = "disabled";
> > + };
> > +
> > + usbmisc1: usbmisc@4c100200 {
> > + compatible = "fsl,imx8mm-usbmisc", "fsl,imx7d-usbmisc",
> > + "fsl,imx6q-usbmisc";
> > + reg = <0x4c100200 0x200>;
> > + #index-cells = <1>;
>
> Do we still need this '#index-cells' property? I see it's being marked
> as deprecated in bindings doc.
Sorry, the driver still needs fetch the value of this property so far. Otherwise,
the driver will probe failed. We still need some time to totally retire this property.
Thanks,
Xu Yang
>
> Shawn
>
> > + };
> > +
> > + usbotg2: usb@4c200000 {
> > + compatible = "fsl,imx93-usb", "fsl,imx7d-usb", "fsl,imx27-usb";
> > + reg = <0x4c200000 0x200>;
> > + interrupts = <GIC_SPI 188 IRQ_TYPE_LEVEL_HIGH>;
> > + clocks = <&clk IMX93_CLK_USB_CONTROLLER_GATE>,
> > + <&clk IMX93_CLK_HSIO_32K_GATE>;
> > + clock-names = "usb_ctrl_root", "usb_wakeup";
> > + assigned-clocks = <&clk IMX93_CLK_HSIO>;
> > + assigned-clock-parents = <&clk IMX93_CLK_SYS_PLL_PFD1_DIV2>;
> > + assigned-clock-rates = <133000000>;
> > + phys = <&usbphynop2>;
> > + fsl,usbmisc = <&usbmisc2 0>;
> > + status = "disabled";
> > + };
> > +
> > + usbmisc2: usbmisc@4c200200 {
> > + compatible = "fsl,imx8mm-usbmisc", "fsl,imx7d-usbmisc",
> > + "fsl,imx6q-usbmisc";
> > + reg = <0x4c200200 0x200>;
> > + #index-cells = <1>;
> > + };
> > +
> > ddr-pmu@4e300dc0 {
> > compatible = "fsl,imx93-ddr-pmu";
> > reg = <0x4e300dc0 0x200>;
> > --
> > 2.34.1
> >
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH 4/9] perf/arm_dsu: Avoid explicit cpumask var allocation from stack
From: Dawei Li @ 2024-04-02 10:56 UTC (permalink / raw)
To: will, mark.rutland
Cc: xueshuai, renyu.zj, yangyicong, jonathan.cameron, andersson,
konrad.dybcio, linux-arm-kernel, linux-kernel, linux-arm-msm,
Dawei Li
In-Reply-To: <20240402105610.1695644-1-dawei.li@shingroup.cn>
For CONFIG_CPUMASK_OFFSTACK=y kernel, explicit allocation of cpumask
variable on stack is not recommended since it can cause potential stack
overflow.
Instead, kernel code should always use *cpumask_var API(s) to allocate
cpumask var in config- neutral way, leaving allocation strategy to
CONFIG_CPUMASK_OFFSTACK.
Use *cpumask_var API(s) to address it.
Signed-off-by: Dawei Li <dawei.li@shingroup.cn>
---
drivers/perf/arm_dsu_pmu.c | 18 +++++++++++++-----
1 file changed, 13 insertions(+), 5 deletions(-)
diff --git a/drivers/perf/arm_dsu_pmu.c b/drivers/perf/arm_dsu_pmu.c
index bae3ca37f846..87efdca05807 100644
--- a/drivers/perf/arm_dsu_pmu.c
+++ b/drivers/perf/arm_dsu_pmu.c
@@ -230,13 +230,21 @@ static const struct attribute_group *dsu_pmu_attr_groups[] = {
NULL,
};
-static int dsu_pmu_get_online_cpu_any_but(struct dsu_pmu *dsu_pmu, int cpu)
+static unsigned int dsu_pmu_get_online_cpu_any_but(struct dsu_pmu *dsu_pmu, int cpu)
{
- struct cpumask online_supported;
+ cpumask_var_t online_supported;
+ unsigned int ret;
- cpumask_and(&online_supported,
- &dsu_pmu->associated_cpus, cpu_online_mask);
- return cpumask_any_but(&online_supported, cpu);
+ if (!alloc_cpumask_var(&online_supported, GFP_KERNEL))
+ return -ENOMEM;
+
+ cpumask_and(online_supported,
+ &dsu_pmu->associated_cpus, cpu_online_mask);
+ ret = cpumask_any_but(&online_supported, cpu);
+
+ free_cpumask_var(online_supported);
+
+ return ret;
}
static inline bool dsu_pmu_counter_valid(struct dsu_pmu *dsu_pmu, u32 idx)
--
2.27.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 6/9] perf/hisi_pcie: Avoid explicit cpumask var allocation from stack
From: Dawei Li @ 2024-04-02 10:56 UTC (permalink / raw)
To: will, mark.rutland
Cc: xueshuai, renyu.zj, yangyicong, jonathan.cameron, andersson,
konrad.dybcio, linux-arm-kernel, linux-kernel, linux-arm-msm,
Dawei Li
In-Reply-To: <20240402105610.1695644-1-dawei.li@shingroup.cn>
For CONFIG_CPUMASK_OFFSTACK=y kernel, explicit allocation of cpumask
variable on stack is not recommended since it can cause potential stack
overflow.
Instead, kernel code should always use *cpumask_var API(s) to allocate
cpumask var in config- neutral way, leaving allocation strategy to
CONFIG_CPUMASK_OFFSTACK.
Use *cpumask_var API(s) to address it.
Signed-off-by: Dawei Li <dawei.li@shingroup.cn>
---
drivers/perf/hisilicon/hisi_pcie_pmu.c | 15 ++++++++++-----
1 file changed, 10 insertions(+), 5 deletions(-)
diff --git a/drivers/perf/hisilicon/hisi_pcie_pmu.c b/drivers/perf/hisilicon/hisi_pcie_pmu.c
index 5d1f0e9fdb08..0183640db2de 100644
--- a/drivers/perf/hisilicon/hisi_pcie_pmu.c
+++ b/drivers/perf/hisilicon/hisi_pcie_pmu.c
@@ -673,26 +673,29 @@ static int hisi_pcie_pmu_offline_cpu(unsigned int cpu, struct hlist_node *node)
{
struct hisi_pcie_pmu *pcie_pmu = hlist_entry_safe(node, struct hisi_pcie_pmu, node);
unsigned int target;
- cpumask_t mask;
+ cpumask_var_t mask;
int numa_node;
/* Nothing to do if this CPU doesn't own the PMU */
if (pcie_pmu->on_cpu != cpu)
return 0;
+ if (!alloc_cpumask_var(&mask, GFP_KERNEL))
+ return 0;
+
pcie_pmu->on_cpu = -1;
/* Choose a local CPU from all online cpus. */
numa_node = dev_to_node(&pcie_pmu->pdev->dev);
- if (cpumask_and(&mask, cpumask_of_node(numa_node), cpu_online_mask) &&
- cpumask_andnot(&mask, &mask, cpumask_of(cpu)))
- target = cpumask_any(&mask);
+ if (cpumask_and(mask, cpumask_of_node(numa_node), cpu_online_mask) &&
+ cpumask_andnot(mask, mask, cpumask_of(cpu)))
+ target = cpumask_any(mask);
else
target = cpumask_any_but(cpu_online_mask, cpu);
if (target >= nr_cpu_ids) {
pci_err(pcie_pmu->pdev, "There is no CPU to set\n");
- return 0;
+ goto __free_cpumask;
}
perf_pmu_migrate_context(&pcie_pmu->pmu, cpu, target);
@@ -700,6 +703,8 @@ static int hisi_pcie_pmu_offline_cpu(unsigned int cpu, struct hlist_node *node)
pcie_pmu->on_cpu = target;
WARN_ON(irq_set_affinity(pcie_pmu->irq, cpumask_of(target)));
+__free_cpumask:
+ free_cpumask_var(mask);
return 0;
}
--
2.27.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 1/9] perf/alibaba_uncore_drw: Avoid explicit cpumask var allocation from stack
From: Dawei Li @ 2024-04-02 10:56 UTC (permalink / raw)
To: will, mark.rutland
Cc: xueshuai, renyu.zj, yangyicong, jonathan.cameron, andersson,
konrad.dybcio, linux-arm-kernel, linux-kernel, linux-arm-msm,
Dawei Li
In-Reply-To: <20240402105610.1695644-1-dawei.li@shingroup.cn>
For CONFIG_CPUMASK_OFFSTACK=y kernel, explicit allocation of cpumask
variable on stack is not recommended since it can cause potential stack
overflow.
Instead, kernel code should always use *cpumask_var API(s) to allocate
cpumask var in config- neutral way, leaving allocation strategy to
CONFIG_CPUMASK_OFFSTACK.
Use *cpumask_var API(s) to address it.
Signed-off-by: Dawei Li <dawei.li@shingroup.cn>
---
drivers/perf/alibaba_uncore_drw_pmu.c | 13 +++++++++----
1 file changed, 9 insertions(+), 4 deletions(-)
diff --git a/drivers/perf/alibaba_uncore_drw_pmu.c b/drivers/perf/alibaba_uncore_drw_pmu.c
index a9277dcf90ce..251f0a2dee84 100644
--- a/drivers/perf/alibaba_uncore_drw_pmu.c
+++ b/drivers/perf/alibaba_uncore_drw_pmu.c
@@ -743,25 +743,28 @@ static void ali_drw_pmu_remove(struct platform_device *pdev)
static int ali_drw_pmu_offline_cpu(unsigned int cpu, struct hlist_node *node)
{
+ cpumask_var_t node_online_cpus;
struct ali_drw_pmu_irq *irq;
struct ali_drw_pmu *drw_pmu;
unsigned int target;
int ret;
- cpumask_t node_online_cpus;
irq = hlist_entry_safe(node, struct ali_drw_pmu_irq, node);
if (cpu != irq->cpu)
return 0;
- ret = cpumask_and(&node_online_cpus,
+ if (!alloc_cpumask_var(&node_online_cpus, GFP_KERNEL))
+ return 0;
+
+ ret = cpumask_and(node_online_cpus,
cpumask_of_node(cpu_to_node(cpu)), cpu_online_mask);
if (ret)
- target = cpumask_any_but(&node_online_cpus, cpu);
+ target = cpumask_any_but(node_online_cpus, cpu);
else
target = cpumask_any_but(cpu_online_mask, cpu);
if (target >= nr_cpu_ids)
- return 0;
+ goto __free_cpumask;
/* We're only reading, but this isn't the place to be involving RCU */
mutex_lock(&ali_drw_pmu_irqs_lock);
@@ -772,6 +775,8 @@ static int ali_drw_pmu_offline_cpu(unsigned int cpu, struct hlist_node *node)
WARN_ON(irq_set_affinity_hint(irq->irq_num, cpumask_of(target)));
irq->cpu = target;
+__free_cpumask:
+ free_cpumask_var(node_online_cpus);
return 0;
}
--
2.27.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/9] perf: Avoid explicit cpumask var allocation from stack
From: Dawei Li @ 2024-04-02 10:56 UTC (permalink / raw)
To: will, mark.rutland
Cc: xueshuai, renyu.zj, yangyicong, jonathan.cameron, andersson,
konrad.dybcio, linux-arm-kernel, linux-kernel, linux-arm-msm,
Dawei Li
Hi,
This series try to eliminate direct cpumask var allocation from stack
for perf subsystem.
Direct/explicit allocation of cpumask on stack could be dangerous since
it can lead to stack overflow for systems with big NR_CPUS or
CONFIG_CPUMASK_OFFSTACK=y.
For arm64, it's more urgent since commit 3fbd56f0e7c1 ("ARM64: Dynamically
allocate cpumasks and increase supported CPUs to 512").
It's sort of a pattern that almost every cpumask var in perf subystem
occurs in teardown callback of cpuhp. In which case, if dynamic
allocation failed(which is unlikely), we choose return 0 rather than
-ENOMEM to caller cuz:
@teardown is not supposed to fail and if it does, system crashes:
static int cpuhp_issue_call(int cpu, enum cpuhp_state state, bool bringup,
struct hlist_node *node)
{
struct cpuhp_step *sp = cpuhp_get_step(state);
int ret;
/*
* If there's nothing to do, we done.
* Relies on the union for multi_instance.
*/
if (cpuhp_step_empty(bringup, sp))
return 0;
/*
* The non AP bound callbacks can fail on bringup. On teardown
* e.g. module removal we crash for now.
*/
#ifdef CONFIG_SMP
if (cpuhp_is_ap_state(state))
ret = cpuhp_invoke_ap_callback(cpu, state, bringup, node);
else
ret = cpuhp_invoke_callback(cpu, state, bringup, node,
NULL);
#else
ret = cpuhp_invoke_callback(cpu, state, bringup, node, NULL);
#endif
BUG_ON(ret && !bringup);
return ret;
}
Dawei Li (9):
perf/alibaba_uncore_drw: Avoid explicit cpumask var allocation from
stack
perf/arm-cmn: Avoid explicit cpumask var allocation from stack
perf/arm_cspmu: Avoid explicit cpumask var allocation from stack
perf/arm_dsu: Avoid explicit cpumask var allocation from stack
perf/dwc_pcie: Avoid explicit cpumask var allocation from stack
perf/hisi_pcie: Avoid explicit cpumask var allocation from stack
perf/hisi_uncore: Avoid explicit cpumask var allocation from stack
perf/qcom_l2: Avoid explicit cpumask var allocation from stack
perf/thunder_x2: Avoid explicit cpumask var allocation from stack
drivers/perf/alibaba_uncore_drw_pmu.c | 13 +++++++++----
drivers/perf/arm-cmn.c | 13 +++++++++----
drivers/perf/arm_cspmu/arm_cspmu.c | 13 +++++++++----
drivers/perf/arm_dsu_pmu.c | 18 +++++++++++++-----
drivers/perf/dwc_pcie_pmu.c | 17 +++++++++++------
drivers/perf/hisilicon/hisi_pcie_pmu.c | 15 ++++++++++-----
drivers/perf/hisilicon/hisi_uncore_pmu.c | 13 +++++++++----
drivers/perf/qcom_l2_pmu.c | 15 ++++++++++-----
drivers/perf/thunderx2_pmu.c | 20 ++++++++++++--------
9 files changed, 92 insertions(+), 45 deletions(-)
Thanks,
Dawei
--
2.27.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH] dt-bindings: mfd: syscon: Add ti,am62p-cpsw-mac-efuse compatible
From: Siddharth Vadapalli @ 2024-04-02 10:57 UTC (permalink / raw)
To: lee, robh, krzk+dt, conor+dt
Cc: devicetree, linux-kernel, linux-arm-kernel, srk, s-vadapalli
The CTRLMMR_MAC_IDx registers within the CTRL_MMR space of TI's AM62p SoC
contain the MAC Address programmed in the eFuse. Add compatible for
allowing the CPSW driver to obtain a regmap for the CTRLMMR_MAC_IDx
registers within the System Controller device-tree node. The default MAC
Address for the interface corresponding to the first MAC port will be set
to the value programmed in the eFuse.
Signed-off-by: Siddharth Vadapalli <s-vadapalli@ti.com>
---
This patch is based on linux-next tagged next-20240402.
Regards,
Siddharth.
Documentation/devicetree/bindings/mfd/syscon.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/mfd/syscon.yaml b/Documentation/devicetree/bindings/mfd/syscon.yaml
index 9d55bee155ce..4936ac0b5936 100644
--- a/Documentation/devicetree/bindings/mfd/syscon.yaml
+++ b/Documentation/devicetree/bindings/mfd/syscon.yaml
@@ -73,6 +73,7 @@ properties:
- rockchip,rv1126-qos
- starfive,jh7100-sysmain
- ti,am62-usb-phy-ctrl
+ - ti,am62p-cpsw-mac-efuse
- ti,am654-dss-oldi-io-ctrl
- ti,am654-serdes-ctrl
- ti,j784s4-pcie-ctrl
--
2.40.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 1/1] arm64: dts: imx8-ss-conn: fix usdhc wrong lpcg clock order
From: Shawn Guo @ 2024-04-02 10:56 UTC (permalink / raw)
To: Frank Li
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Shawn Guo,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Dong Aisheng,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
open list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
open list
In-Reply-To: <20240322164706.2626088-1-Frank.Li@nxp.com>
On Fri, Mar 22, 2024 at 12:47:05PM -0400, Frank Li wrote:
> The actual clock show wrong frequency:
>
> echo on >/sys/devices/platform/bus\@5b000000/5b010000.mmc/power/control
> cat /sys/kernel/debug/mmc0/ios
>
> clock: 200000000 Hz
> actual clock: 166000000 Hz
> ^^^^^^^^^
> .....
>
> According to
>
> sdhc0_lpcg: clock-controller@5b200000 {
> compatible = "fsl,imx8qxp-lpcg";
> reg = <0x5b200000 0x10000>;
> #clock-cells = <1>;
> clocks = <&clk IMX_SC_R_SDHC_0 IMX_SC_PM_CLK_PER>,
> <&conn_ipg_clk>, <&conn_axi_clk>;
> clock-indices = <IMX_LPCG_CLK_0>, <IMX_LPCG_CLK_4>,
> <IMX_LPCG_CLK_5>;
> clock-output-names = "sdhc0_lpcg_per_clk",
> "sdhc0_lpcg_ipg_clk",
> "sdhc0_lpcg_ahb_clk";
> power-domains = <&pd IMX_SC_R_SDHC_0>;
> }
>
> "per_clk" should be IMX_LPCG_CLK_0 instead of IMX_LPCG_CLK_5.
>
> After correct clocks order:
>
> echo on >/sys/devices/platform/bus\@5b000000/5b010000.mmc/power/control
> cat /sys/kernel/debug/mmc0/ios
>
> clock: 200000000 Hz
> actual clock: 198000000 Hz
> ^^^^^^^^
> ...
>
> Fixes: 16c4ea7501b1 ("arm64: dts: imx8: switch to new lpcg clock binding")
> Signed-off-by: Frank Li <Frank.Li@nxp.com>
Applied, thanks!
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH] arm64: Fix double TCR_T0SZ_OFFSET shift
From: Seongsu Park @ 2024-04-02 10:49 UTC (permalink / raw)
To: catalin.marinas, will, ardb, mark.rutland
Cc: linux-arm-kernel, linux-kernel, sgsu.park, Leem ChaeHoon,
Gyeonggeon Choi, Soomin Cho, DaeRo Lee, kmasta
In-Reply-To: <CGME20240402104955epcas1p3dd15334a1305b99f3e1b82000e3c7c42@epcas1p3.samsung.com>
We have already shifted the value of t0sz in TCR_T0SZ by TCR_T0SZ_OFFSET.
So, the TCR_T0SZ_OFFSET shift here should be removed.
Co-developed-by: Leem ChaeHoon <infinite.run@gmail.com>
Signed-off-by: Leem ChaeHoon <infinite.run@gmail.com>
Co-developed-by: Gyeonggeon Choi <gychoi@student.42seoul.kr>
Signed-off-by: Gyeonggeon Choi <gychoi@student.42seoul.kr>
Co-developed-by: Soomin Cho <to.soomin@gmail.com>
Signed-off-by: Soomin Cho <to.soomin@gmail.com>
Co-developed-by: DaeRo Lee <skseofh@gmail.com>
Signed-off-by: DaeRo Lee <skseofh@gmail.com>
Co-developed-by: kmasta <kmasta.study@gmail.com>
Signed-off-by: kmasta <kmasta.study@gmail.com>
Signed-off-by: Seongsu Park <sgsu.park@samsung.com>
---
arch/arm64/include/asm/mmu_context.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/include/asm/mmu_context.h b/arch/arm64/include/asm/mmu_context.h
index c768d16b81a4..58de99836d2e 100644
--- a/arch/arm64/include/asm/mmu_context.h
+++ b/arch/arm64/include/asm/mmu_context.h
@@ -76,7 +76,7 @@ static inline void __cpu_set_tcr_t0sz(unsigned long t0sz)
return;
tcr &= ~TCR_T0SZ_MASK;
- tcr |= t0sz << TCR_T0SZ_OFFSET;
+ tcr |= t0sz;
write_sysreg(tcr, tcr_el1);
isb();
}
--
2.34.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
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