* Re: [PATCH 1/2] arm64: dts: rockchip: Add enable-strobe-pulldown to emmc phy on ROCK Pi 4
From: Chen-Yu Tsai @ 2024-03-28 7:44 UTC (permalink / raw)
To: Folker Schwesinger
Cc: Vinod Koul, Yogesh Hegde, Heiko Stuebner, Chris Ruehl,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Dragan Simic,
Christopher Obbard, linux-arm-kernel, linux-rockchip,
linux-kernel, devicetree
In-Reply-To: <D05701GE187C.3VLOERXP8B3NR@folker-schwesinger.de>
On Thu, Mar 28, 2024 at 3:09 PM Folker Schwesinger
<dev@folker-schwesinger.de> wrote:
>
> On Thu Mar 28, 2024 at 6:39 AM CET, Chen-Yu Tsai wrote:
> > > @@ -648,7 +649,8 @@ &saradc {
> > > &sdhci {
> > > max-frequency <150000000>;
> > > bus-width <8>;
> > > - mmc-hs200-1_8v;
> >
> > Shouldn't this be kept around? The node should list all supported modes,
> > not just the highest one. Same for the other patch.
> >
>
> This is not necessary, mmc-hs400-1_8v implicitly activates the
> corresponding HS200 capability, see drivers/mmc/core/host.c:
>
> if (device_property_read_bool(dev, "mmc-hs200-1_8v"))
> host->caps2 | MMC_CAP2_HS200_1_8V_SDR;
> /* ... */
> if (device_property_read_bool(dev, "mmc-hs400-1_8v"))
> host->caps2 | MMC_CAP2_HS400_1_8V | MMC_CAP2_HS200_1_8V_SDR;
Looking at the initial commit for adding the hs400 properties,
it was also mentioned that hs400 support implies hs200 support.
It just wasn't explicitly spelled out in the bindings.
In that case, I think we're good here for this particular case.
> Kind regards
>
> Folker
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
_______________________________________________
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/23] v2: imx258 improvement series
From: Krzysztof Kozlowski @ 2024-03-28 7:43 UTC (permalink / raw)
To: git, linux-media
Cc: 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: <20240327231710.53188-1-git@luigi311.com>
On 28/03/2024 00:16, git@luigi311.com wrote:
> From: Luigi311 <git@luigi311.com>
>
> Resend due to email message limits being exceeded.
>
> v2 changes:
Please mark your patches correctly. Use b4 or -v2 for format-patch.
Best regards,
Krzysztof
_______________________________________________
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 01/23] media: i2c: imx258: Remove unused defines
From: Krzysztof Kozlowski @ 2024-03-28 7:42 UTC (permalink / raw)
To: git, linux-media
Cc: 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: <20240327231710.53188-2-git@luigi311.com>
On 28/03/2024 00:16, git@luigi311.com wrote:
> From: Dave Stevenson <dave.stevenson@raspberrypi.com>
>
> The IMX258_FLL_* defines are unused. Remove them.
>
> Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
> Reviewed-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com>
Your SoB is missing.
Best regards,
Krzysztof
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH V4 2/2] cpufreq: scmi: Register for limit change notifications
From: Sibi Sankar @ 2024-03-28 7:41 UTC (permalink / raw)
To: sudeep.holla, cristian.marussi, rafael, viresh.kumar,
morten.rasmussen, dietmar.eggemann, lukasz.luba, pierre.gondois
Cc: linux-arm-kernel, linux-pm, linux-kernel, quic_mdtipton,
linux-arm-msm, Sibi Sankar
In-Reply-To: <20240328074131.2839871-1-quic_sibis@quicinc.com>
Register for limit change notifications if supported and use the throttled
frequency from the notification to apply HW pressure.
Signed-off-by: Sibi Sankar <quic_sibis@quicinc.com>
---
v4:
* Use a interim variable to show the khz calc. [Lukasz]
* Use driver_data to pass on the handle and scmi_dev instead of using
global variables. Dropped Lukasz's Rb due to adding these minor
changes.
drivers/cpufreq/scmi-cpufreq.c | 44 ++++++++++++++++++++++++++++++++++
1 file changed, 44 insertions(+)
diff --git a/drivers/cpufreq/scmi-cpufreq.c b/drivers/cpufreq/scmi-cpufreq.c
index 3b4f6bfb2f4c..d946b7a08258 100644
--- a/drivers/cpufreq/scmi-cpufreq.c
+++ b/drivers/cpufreq/scmi-cpufreq.c
@@ -21,11 +21,18 @@
#include <linux/types.h>
#include <linux/units.h>
+struct scmi_cpufreq_driver_data {
+ struct scmi_device *sdev;
+ const struct scmi_handle *handle;
+};
+
struct scmi_data {
int domain_id;
int nr_opp;
struct device *cpu_dev;
+ struct cpufreq_policy *policy;
cpumask_var_t opp_shared_cpus;
+ struct notifier_block limit_notify_nb;
};
static struct scmi_protocol_handle *ph;
@@ -174,6 +181,22 @@ static struct freq_attr *scmi_cpufreq_hw_attr[] = {
NULL,
};
+static int scmi_limit_notify_cb(struct notifier_block *nb, unsigned long event, void *data)
+{
+ struct scmi_data *priv = container_of(nb, struct scmi_data, limit_notify_nb);
+ struct scmi_perf_limits_report *limit_notify = data;
+ struct cpufreq_policy *policy = priv->policy;
+ unsigned int limit_freq_khz;
+
+ limit_freq_khz = limit_notify->range_max_freq / HZ_PER_KHZ;
+
+ policy->max = clamp(limit_freq_khz, policy->cpuinfo.min_freq, policy->cpuinfo.max_freq);
+
+ cpufreq_update_pressure(policy);
+
+ return NOTIFY_OK;
+}
+
static int scmi_cpufreq_init(struct cpufreq_policy *policy)
{
int ret, nr_opp, domain;
@@ -181,6 +204,7 @@ static int scmi_cpufreq_init(struct cpufreq_policy *policy)
struct device *cpu_dev;
struct scmi_data *priv;
struct cpufreq_frequency_table *freq_table;
+ struct scmi_cpufreq_driver_data *data = cpufreq_get_driver_data();
cpu_dev = get_cpu_device(policy->cpu);
if (!cpu_dev) {
@@ -294,6 +318,17 @@ static int scmi_cpufreq_init(struct cpufreq_policy *policy)
}
}
+ priv->limit_notify_nb.notifier_call = scmi_limit_notify_cb;
+ ret = data->handle->notify_ops->devm_event_notifier_register(data->sdev, SCMI_PROTOCOL_PERF,
+ SCMI_EVENT_PERFORMANCE_LIMITS_CHANGED,
+ &domain,
+ &priv->limit_notify_nb);
+ if (ret)
+ dev_warn(cpu_dev,
+ "failed to register for limits change notifier for domain %d\n", domain);
+
+ priv->policy = policy;
+
return 0;
out_free_opp:
@@ -366,12 +401,21 @@ static int scmi_cpufreq_probe(struct scmi_device *sdev)
int ret;
struct device *dev = &sdev->dev;
const struct scmi_handle *handle;
+ struct scmi_cpufreq_driver_data *data;
handle = sdev->handle;
if (!handle)
return -ENODEV;
+ data = devm_kzalloc(dev, sizeof(*data), GFP_KERNEL);
+ if (!data)
+ return -ENOMEM;
+
+ data->sdev = sdev;
+ data->handle = handle;
+ scmi_cpufreq_driver.driver_data = data;
+
perf_ops = handle->devm_protocol_get(sdev, SCMI_PROTOCOL_PERF, &ph);
if (IS_ERR(perf_ops))
return PTR_ERR(perf_ops);
--
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
* [PATCH V4 0/2] firmware: arm_scmi: Register and handle limits change notification
From: Sibi Sankar @ 2024-03-28 7:41 UTC (permalink / raw)
To: sudeep.holla, cristian.marussi, rafael, viresh.kumar,
morten.rasmussen, dietmar.eggemann, lukasz.luba, pierre.gondois
Cc: linux-arm-kernel, linux-pm, linux-kernel, quic_mdtipton,
linux-arm-msm, Sibi Sankar
This series registers for scmi limits change notifications to determine
the throttled frequency and apply HW pressure.
V4:
* Use EXPORT_SYMBOL_GPL instead. [Trilok]
* Use a interim variable to show the khz calc. [Lukasz]
* Use driver_data to pass on the handle and scmi_dev instead of using
global variables. Dropped Lukasz's Rb due to adding these minor
changes.
V3:
* Sanitize range_max received from the notifier. [Pierre]
* Drop patches 1/2 from v2. [Cristian]
* Update commit message in patch 2.
V2:
* Rename opp_xlate -> freq_xlate [Viresh]
* Export cpufreq_update_pressure and use it directly [Lukasz]
Depends on:
HW pressure v6: https://patchwork.kernel.org/project/linux-arm-msm/cover/20240326091616.3696851-1-vincent.guittot@linaro.org/
Sibi Sankar (2):
cpufreq: Export cpufreq_update_pressure
cpufreq: scmi: Register for limit change notifications
drivers/cpufreq/cpufreq.c | 3 ++-
drivers/cpufreq/scmi-cpufreq.c | 44 ++++++++++++++++++++++++++++++++++
include/linux/cpufreq.h | 2 ++
3 files changed, 48 insertions(+), 1 deletion(-)
--
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] dmaengine: owl: fix register access functions
From: Vinod Koul @ 2024-03-28 7:39 UTC (permalink / raw)
To: Andreas Färber, Manivannan Sadhasivam, Nathan Chancellor,
Arnd Bergmann
Cc: Arnd Bergmann, Nick Desaulniers, Bill Wendling, Justin Stitt,
Uwe Kleine-König, Randy Dunlap, Rob Herring, Zhang Jianhua,
dmaengine, linux-arm-kernel, linux-actions, linux-kernel, llvm
In-Reply-To: <20240322132116.906475-1-arnd@kernel.org>
On Fri, 22 Mar 2024 14:21:07 +0100, Arnd Bergmann wrote:
> When building with 'make W=1', clang notices that the computed register
> values are never actually written back but instead the wrong variable
> is set:
>
> drivers/dma/owl-dma.c:244:6: error: variable 'regval' set but not used [-Werror,-Wunused-but-set-variable]
> 244 | u32 regval;
> | ^
> drivers/dma/owl-dma.c:268:6: error: variable 'regval' set but not used [-Werror,-Wunused-but-set-variable]
> 268 | u32 regval;
> | ^
>
> [...]
Applied, thanks!
[1/1] dmaengine: owl: fix register access functions
commit: 43c633ef93a5d293c96ebcedb40130df13128428
Best regards,
--
~Vinod
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [RESEND][PATCH v2 3/4] PM: EM: Add em_dev_update_chip_binning()
From: Lukasz Luba @ 2024-03-28 7:30 UTC (permalink / raw)
To: Dietmar Eggemann
Cc: linux-arm-kernel, sboyd, nm, linux-samsung-soc, daniel.lezcano,
rafael, viresh.kumar, krzysztof.kozlowski, alim.akhtar,
m.szyprowski, mhiramat, linux-kernel, linux-pm
In-Reply-To: <9f2f5c94-cc9f-4a16-9b70-f00598af8cab@arm.com>
On 3/28/24 07:21, Dietmar Eggemann wrote:
> On 27/03/2024 13:55, Dietmar Eggemann wrote:
>> On 26/03/2024 21:32, Lukasz Luba wrote:
>>>
>>>
>>> On 3/26/24 10:09, Dietmar Eggemann wrote:
>>>> On 22/03/2024 12:08, Lukasz Luba wrote:
>>
>> [...]
>>
>>>>> + return em_recalc_and_update(dev, pd, em_table);
>>>>> +}
>>>>> +EXPORT_SYMBOL_GPL(em_dev_update_chip_binning);
>>>>
>>>> In the previous version of 'chip-binning' you were using the new EM
>>>> interface em_dev_compute_costs() (1) which is now replaced by
>>>> em_recalc_and_update() -> em_compute_costs().
>>>>
>>>> https://lkml.kernel.org/r/20231220110339.1065505-2-lukasz.luba@arm.com
>>>>
>>>> Which leaves (1) still unused.
>>>>
>>>> That was why my concern back then that we shouldn't introduce EM
>>>> interfaces without a user:
>>>>
>>>> https://lkml.kernel.org/r/8fc499cf-fca1-4465-bff7-a93dfd36f3c8@arm.com
>>>>
>>>> What happens now with em_dev_compute_costs()?
>>>>
>>>
>>> For now it's not used, but modules which will create new EMs
>>> with custom power values will use it. When such a module have
>>> e.g. 5 EMs for one PD and only switches on one of them, then
>>> this em_dev_compute_costs() will be used at setup for those
>>> 5 EMs. Later it won't be used.
>>> I don't wanted to combine the registration of new EM with
>>> the compute cost, because that will create overhead in the
>>> switching to new EM code path. Now we have only ~3us, which
>>> was the main goal.
>>>
>>> When our scmi-cpufreq get the support for EM update this
>>> compute cost will be used there.
>>
>> OK, I see. I checked the reloadable EM test module and
>> em_dev_compute_costs() is used there like you described it.
>
> I had a second look and IMHO the layout is like this:
>
> Internal (1) and external (2,3) 'reloadable EM' use cases:
> (EM alloc and free not depicted)
>
> 1. Late CPUs booting (CPU capacity adjustment)
>
> e3f1164fc9ee PM: EM: Support late CPUs booting and capacity adjustment
>
> schedule_delayed_work(&em_update_work, ...)
>
> em_update_workfn()
> em_check_capacity_update()
> em_adjust_new_capacity()
> em_recalc_and_update() <-- (i)
> em_compute_costs() <-- (ii)
> em_dev_update_perf_domain() <-- external
>
> 2. Reload EM from driver
>
> 22ea02848c07 PM: EM: Add em_dev_compute_costs()
> 977230d5d503 PM: EM: Introduce em_dev_update_perf_domain() for EM
> updates
>
> em_dev_compute_costs() <-- external
> em_compute_costs() <-- (ii)
> em_dev_update_perf_domain() <-- external
>
> 3. Chip binning
>
> this patchset PM: EM: Add em_dev_update_chip_binning()
>
> em_dev_update_chip_binning() <-- external
> em_recalc_and_update() <-- (i)
> em_compute_costs() <-- (ii)
> em_dev_update_perf_domain() <-- external
>
>
>
>
Yes, that's correct.
_______________________________________________
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] arch: Remove struct fb_info from video helpers
From: Sam Ravnborg @ 2024-03-28 7:25 UTC (permalink / raw)
To: Thomas Zimmermann
Cc: arnd, javierm, deller, sui.jingfeng, 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>
Hi Thomas,
On Wed, Mar 27, 2024 at 09:41:30PM +0100, 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
> 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>
Reviewed-by: Sam Ravnborg <sam@ravnborg.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] arch: Select fbdev helpers with CONFIG_VIDEO
From: Sam Ravnborg @ 2024-03-28 7:24 UTC (permalink / raw)
To: Thomas Zimmermann
Cc: arnd, javierm, deller, sui.jingfeng, 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-2-tzimmermann@suse.de>
On Wed, Mar 27, 2024 at 09:41:29PM +0100, Thomas Zimmermann wrote:
> Various Kconfig options selected the per-architecture helpers for
> fbdev. But none of the contained code depends on fbdev. Standardize
> on CONFIG_VIDEO, which will allow to add more general helpers for
> video functionality.
>
> CONFIG_VIDEO protects each architecture's video/ directory. This
> allows for the use of more fine-grained control for each directory's
> files, such as the use of CONFIG_STI_CORE on parisc.
>
> v2:
> - sparc: rebased onto Makefile changes
>
> 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>
Reviewed-by: Sam Ravnborg <sam@ravnborg.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 3/3] arch: Rename fbdev header and source files
From: Sam Ravnborg @ 2024-03-28 7:23 UTC (permalink / raw)
To: Thomas Zimmermann
Cc: arnd, javierm, deller, sui.jingfeng, 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, Vineet Gupta, Catalin Marinas,
Will Deacon, Huacai Chen, WANG Xuerui, Geert Uytterhoeven,
Thomas Bogendoerfer, James E.J. Bottomley, Michael Ellerman,
Nicholas Piggin, Yoshinori Sato, Rich Felker,
John Paul Adrian Glaubitz, David S. Miller, Andreas Larsson,
Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen, x86,
H. Peter Anvin
In-Reply-To: <20240327204450.14914-4-tzimmermann@suse.de>
Hi Thomas,
On Wed, Mar 27, 2024 at 09:41:31PM +0100, Thomas Zimmermann wrote:
> The per-architecture fbdev code has no dependencies on fbdev and can
> be used for any video-related subsystem. Rename the files to 'video'.
> Use video-sti.c on parisc as the source file depends on CONFIG_STI_CORE.
>
> Further update all includes statements, includ guards, and Makefiles.
^ missing 'e'
> Also update a few strings and comments to refer to video instead of
> fbdev.
>
> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
> Cc: Vineet Gupta <vgupta@kernel.org>
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> Cc: Will Deacon <will@kernel.org>
> Cc: Huacai Chen <chenhuacai@kernel.org>
> Cc: WANG Xuerui <kernel@xen0n.name>
> Cc: Geert Uytterhoeven <geert@linux-m68k.org>
> Cc: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
> Cc: "James E.J. Bottomley" <James.Bottomley@HansenPartnership.com>
> Cc: Helge Deller <deller@gmx.de>
> Cc: Michael Ellerman <mpe@ellerman.id.au>
> Cc: Nicholas Piggin <npiggin@gmail.com>
> Cc: Yoshinori Sato <ysato@users.sourceforge.jp>
> Cc: Rich Felker <dalias@libc.org>
> Cc: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.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>
If the patch is changed to use the Kbuild file to pick the generic
variant of video.h then it is:
Reviewed-by: Sam Ravnborg <sam@ravnborg.org>
I also added an unrelated sparc comment, that can be addressed another
time.
Sam
> ---
> arch/arc/include/asm/fb.h | 8 --------
> arch/arc/include/asm/video.h | 8 ++++++++
> arch/arm/include/asm/fb.h | 6 ------
> arch/arm/include/asm/video.h | 6 ++++++
> arch/arm64/include/asm/fb.h | 10 ----------
> arch/arm64/include/asm/video.h | 10 ++++++++++
> arch/loongarch/include/asm/{fb.h => video.h} | 8 ++++----
> arch/m68k/include/asm/{fb.h => video.h} | 8 ++++----
> arch/mips/include/asm/{fb.h => video.h} | 12 ++++++------
> arch/parisc/include/asm/{fb.h => video.h} | 8 ++++----
> arch/parisc/video/Makefile | 2 +-
> arch/parisc/video/{fbdev.c => video-sti.c} | 2 +-
> arch/powerpc/include/asm/{fb.h => video.h} | 8 ++++----
> arch/powerpc/kernel/pci-common.c | 2 +-
> arch/sh/include/asm/fb.h | 7 -------
> arch/sh/include/asm/video.h | 7 +++++++
> arch/sparc/include/asm/{fb.h => video.h} | 8 ++++----
> arch/sparc/video/Makefile | 2 +-
> arch/sparc/video/{fbdev.c => video.c} | 4 ++--
> arch/x86/include/asm/{fb.h => video.h} | 8 ++++----
> arch/x86/video/Makefile | 2 +-
> arch/x86/video/{fbdev.c => video.c} | 3 ++-
> include/asm-generic/Kbuild | 2 +-
> include/asm-generic/{fb.h => video.h} | 6 +++---
> include/linux/fb.h | 2 +-
> 25 files changed, 75 insertions(+), 74 deletions(-)
> delete mode 100644 arch/arc/include/asm/fb.h
> create mode 100644 arch/arc/include/asm/video.h
> delete mode 100644 arch/arm/include/asm/fb.h
> create mode 100644 arch/arm/include/asm/video.h
> delete mode 100644 arch/arm64/include/asm/fb.h
> create mode 100644 arch/arm64/include/asm/video.h
> rename arch/loongarch/include/asm/{fb.h => video.h} (86%)
> rename arch/m68k/include/asm/{fb.h => video.h} (86%)
> rename arch/mips/include/asm/{fb.h => video.h} (76%)
> rename arch/parisc/include/asm/{fb.h => video.h} (68%)
> rename arch/parisc/video/{fbdev.c => video-sti.c} (96%)
> rename arch/powerpc/include/asm/{fb.h => video.h} (76%)
> delete mode 100644 arch/sh/include/asm/fb.h
> create mode 100644 arch/sh/include/asm/video.h
> rename arch/sparc/include/asm/{fb.h => video.h} (89%)
> rename arch/sparc/video/{fbdev.c => video.c} (86%)
> rename arch/x86/include/asm/{fb.h => video.h} (77%)
> rename arch/x86/video/{fbdev.c => video.c} (97%)
> rename include/asm-generic/{fb.h => video.h} (96%)
>
> diff --git a/arch/arc/include/asm/fb.h b/arch/arc/include/asm/fb.h
> deleted file mode 100644
> index 9c2383d29cbb9..0000000000000
> --- a/arch/arc/include/asm/fb.h
> +++ /dev/null
> @@ -1,8 +0,0 @@
> -/* SPDX-License-Identifier: GPL-2.0 */
> -
> -#ifndef _ASM_FB_H_
> -#define _ASM_FB_H_
> -
> -#include <asm-generic/fb.h>
> -
> -#endif /* _ASM_FB_H_ */
> diff --git a/arch/arc/include/asm/video.h b/arch/arc/include/asm/video.h
> new file mode 100644
> index 0000000000000..8ff7263727fe7
> --- /dev/null
> +++ b/arch/arc/include/asm/video.h
> @@ -0,0 +1,8 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +
> +#ifndef _ASM_VIDEO_H_
> +#define _ASM_VIDEO_H_
> +
> +#include <asm-generic/video.h>
> +
> +#endif /* _ASM_VIDEO_H_ */
arch/arc/include/asm/video.h only exists to pick
include/asm-generic/video.h.
The simpler way to do this is to add a line to:
arch/arc/include/asm/Kbuild:
+ generic-y += video.h
While touching the file I suggest to move to the simpler way using the
Kbuild file.
The same goes for all the other video.h files that only picks the
asm-generic variant.
> diff --git a/arch/arm/include/asm/fb.h b/arch/arm/include/asm/fb.h
> deleted file mode 100644
> index ce20a43c30339..0000000000000
> --- a/arch/arm/include/asm/fb.h
> +++ /dev/null
> @@ -1,6 +0,0 @@
> -#ifndef _ASM_FB_H_
> -#define _ASM_FB_H_
> -
> -#include <asm-generic/fb.h>
> -
> -#endif /* _ASM_FB_H_ */
> diff --git a/arch/arm/include/asm/video.h b/arch/arm/include/asm/video.h
> new file mode 100644
> index 0000000000000..f570565366e67
> --- /dev/null
> +++ b/arch/arm/include/asm/video.h
> @@ -0,0 +1,6 @@
> +#ifndef _ASM_VIDEO_H_
> +#define _ASM_VIDEO_H_
> +
> +#include <asm-generic/video.h>
> +
> +#endif /* _ASM_VIDEO_H_ */
> diff --git a/arch/arm64/include/asm/fb.h b/arch/arm64/include/asm/fb.h
> deleted file mode 100644
> index 1a495d8fb2ce0..0000000000000
> --- a/arch/arm64/include/asm/fb.h
> +++ /dev/null
> @@ -1,10 +0,0 @@
> -/* SPDX-License-Identifier: GPL-2.0-only */
> -/*
> - * Copyright (C) 2012 ARM Ltd.
> - */
> -#ifndef __ASM_FB_H_
> -#define __ASM_FB_H_
> -
> -#include <asm-generic/fb.h>
> -
> -#endif /* __ASM_FB_H_ */
> diff --git a/arch/arm64/include/asm/video.h b/arch/arm64/include/asm/video.h
> new file mode 100644
> index 0000000000000..fe0e74983f4d9
> --- /dev/null
> +++ b/arch/arm64/include/asm/video.h
> @@ -0,0 +1,10 @@
> +/* SPDX-License-Identifier: GPL-2.0-only */
> +/*
> + * Copyright (C) 2012 ARM Ltd.
> + */
> +#ifndef __ASM_VIDEO_H_
> +#define __ASM_VIDEO_H_
> +
> +#include <asm-generic/video.h>
> +
> +#endif /* __ASM_VIDEO_H_ */
> diff --git a/arch/loongarch/include/asm/fb.h b/arch/loongarch/include/asm/video.h
> similarity index 86%
> rename from arch/loongarch/include/asm/fb.h
> rename to arch/loongarch/include/asm/video.h
> index 0b218b10a9ec3..9f76845f2d4fd 100644
> --- a/arch/loongarch/include/asm/fb.h
> +++ b/arch/loongarch/include/asm/video.h
> @@ -2,8 +2,8 @@
> /*
> * Copyright (C) 2020-2022 Loongson Technology Corporation Limited
> */
> -#ifndef _ASM_FB_H_
> -#define _ASM_FB_H_
> +#ifndef _ASM_VIDEO_H_
> +#define _ASM_VIDEO_H_
>
> #include <linux/compiler.h>
> #include <linux/string.h>
> @@ -26,6 +26,6 @@ static inline void fb_memset_io(volatile void __iomem *addr, int c, size_t n)
> }
> #define fb_memset fb_memset_io
>
> -#include <asm-generic/fb.h>
> +#include <asm-generic/video.h>
>
> -#endif /* _ASM_FB_H_ */
> +#endif /* _ASM_VIDEO_H_ */
> diff --git a/arch/m68k/include/asm/fb.h b/arch/m68k/include/asm/video.h
> similarity index 86%
> rename from arch/m68k/include/asm/fb.h
> rename to arch/m68k/include/asm/video.h
> index 9941b7434b696..6cf2194c413d8 100644
> --- a/arch/m68k/include/asm/fb.h
> +++ b/arch/m68k/include/asm/video.h
> @@ -1,6 +1,6 @@
> /* SPDX-License-Identifier: GPL-2.0 */
> -#ifndef _ASM_FB_H_
> -#define _ASM_FB_H_
> +#ifndef _ASM_VIDEO_H_
> +#define _ASM_VIDEO_H_
>
> #include <asm/page.h>
> #include <asm/setup.h>
> @@ -27,6 +27,6 @@ static inline pgprot_t pgprot_framebuffer(pgprot_t prot,
> }
> #define pgprot_framebuffer pgprot_framebuffer
>
> -#include <asm-generic/fb.h>
> +#include <asm-generic/video.h>
>
> -#endif /* _ASM_FB_H_ */
> +#endif /* _ASM_VIDEO_H_ */
> diff --git a/arch/mips/include/asm/fb.h b/arch/mips/include/asm/video.h
> similarity index 76%
> rename from arch/mips/include/asm/fb.h
> rename to arch/mips/include/asm/video.h
> index d98d6681d64ec..007c106d980fd 100644
> --- a/arch/mips/include/asm/fb.h
> +++ b/arch/mips/include/asm/video.h
> @@ -1,5 +1,5 @@
> -#ifndef _ASM_FB_H_
> -#define _ASM_FB_H_
> +#ifndef _ASM_VIDEO_H_
> +#define _ASM_VIDEO_H_
>
> #include <asm/page.h>
>
> @@ -13,8 +13,8 @@ static inline pgprot_t pgprot_framebuffer(pgprot_t prot,
>
> /*
> * MIPS doesn't define __raw_ I/O macros, so the helpers
> - * in <asm-generic/fb.h> don't generate fb_readq() and
> - * fb_write(). We have to provide them here.
> + * in <asm-generic/video.h> don't generate fb_readq() and
> + * fb_writeq(). We have to provide them here.
> *
> * TODO: Convert MIPS to generic I/O. The helpers below can
> * then be removed.
> @@ -33,6 +33,6 @@ static inline void fb_writeq(u64 b, volatile void __iomem *addr)
> #define fb_writeq fb_writeq
> #endif
>
> -#include <asm-generic/fb.h>
> +#include <asm-generic/video.h>
>
> -#endif /* _ASM_FB_H_ */
> +#endif /* _ASM_VIDEO_H_ */
> diff --git a/arch/parisc/include/asm/fb.h b/arch/parisc/include/asm/video.h
> similarity index 68%
> rename from arch/parisc/include/asm/fb.h
> rename to arch/parisc/include/asm/video.h
> index ed2a195a3e762..c5dff3223194a 100644
> --- a/arch/parisc/include/asm/fb.h
> +++ b/arch/parisc/include/asm/video.h
> @@ -1,6 +1,6 @@
> /* SPDX-License-Identifier: GPL-2.0 */
> -#ifndef _ASM_FB_H_
> -#define _ASM_FB_H_
> +#ifndef _ASM_VIDEO_H_
> +#define _ASM_VIDEO_H_
>
> #include <linux/types.h>
>
> @@ -11,6 +11,6 @@ bool video_is_primary_device(struct device *dev);
> #define video_is_primary_device video_is_primary_device
> #endif
>
> -#include <asm-generic/fb.h>
> +#include <asm-generic/video.h>
>
> -#endif /* _ASM_FB_H_ */
> +#endif /* _ASM_VIDEO_H_ */
> diff --git a/arch/parisc/video/Makefile b/arch/parisc/video/Makefile
> index 16a73cce46612..b5db5b42880f8 100644
> --- a/arch/parisc/video/Makefile
> +++ b/arch/parisc/video/Makefile
> @@ -1,3 +1,3 @@
> # SPDX-License-Identifier: GPL-2.0-only
>
> -obj-$(CONFIG_STI_CORE) += fbdev.o
> +obj-$(CONFIG_STI_CORE) += video-sti.o
> diff --git a/arch/parisc/video/fbdev.c b/arch/parisc/video/video-sti.c
> similarity index 96%
> rename from arch/parisc/video/fbdev.c
> rename to arch/parisc/video/video-sti.c
> index 540fa0c919d59..564661e87093c 100644
> --- a/arch/parisc/video/fbdev.c
> +++ b/arch/parisc/video/video-sti.c
> @@ -9,7 +9,7 @@
>
> #include <video/sticore.h>
>
> -#include <asm/fb.h>
> +#include <asm/video.h>
>
> bool video_is_primary_device(struct device *dev)
> {
> diff --git a/arch/powerpc/include/asm/fb.h b/arch/powerpc/include/asm/video.h
> similarity index 76%
> rename from arch/powerpc/include/asm/fb.h
> rename to arch/powerpc/include/asm/video.h
> index c0c5d1df7ad1e..e1770114ffc36 100644
> --- a/arch/powerpc/include/asm/fb.h
> +++ b/arch/powerpc/include/asm/video.h
> @@ -1,6 +1,6 @@
> /* SPDX-License-Identifier: GPL-2.0 */
> -#ifndef _ASM_FB_H_
> -#define _ASM_FB_H_
> +#ifndef _ASM_VIDEO_H_
> +#define _ASM_VIDEO_H_
>
> #include <asm/page.h>
>
> @@ -12,6 +12,6 @@ static inline pgprot_t pgprot_framebuffer(pgprot_t prot,
> }
> #define pgprot_framebuffer pgprot_framebuffer
>
> -#include <asm-generic/fb.h>
> +#include <asm-generic/video.h>
>
> -#endif /* _ASM_FB_H_ */
> +#endif /* _ASM_VIDEO_H_ */
> diff --git a/arch/powerpc/kernel/pci-common.c b/arch/powerpc/kernel/pci-common.c
> index d95a48eff412e..eac84d687b53f 100644
> --- a/arch/powerpc/kernel/pci-common.c
> +++ b/arch/powerpc/kernel/pci-common.c
> @@ -517,7 +517,7 @@ int pci_iobar_pfn(struct pci_dev *pdev, int bar, struct vm_area_struct *vma)
> }
>
> /*
> - * This one is used by /dev/mem and fbdev who have no clue about the
> + * This one is used by /dev/mem and video who have no clue about the
> * PCI device, it tries to find the PCI device first and calls the
> * above routine
> */
> diff --git a/arch/sh/include/asm/fb.h b/arch/sh/include/asm/fb.h
> deleted file mode 100644
> index 19df13ee9ca73..0000000000000
> --- a/arch/sh/include/asm/fb.h
> +++ /dev/null
> @@ -1,7 +0,0 @@
> -/* SPDX-License-Identifier: GPL-2.0 */
> -#ifndef _ASM_FB_H_
> -#define _ASM_FB_H_
> -
> -#include <asm-generic/fb.h>
> -
> -#endif /* _ASM_FB_H_ */
> diff --git a/arch/sh/include/asm/video.h b/arch/sh/include/asm/video.h
> new file mode 100644
> index 0000000000000..14f49934a247a
> --- /dev/null
> +++ b/arch/sh/include/asm/video.h
> @@ -0,0 +1,7 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +#ifndef _ASM_VIDEO_H_
> +#define _ASM_VIDEO_H_
> +
> +#include <asm-generic/video.h>
> +
> +#endif /* _ASM_VIDEO_H_ */
> diff --git a/arch/sparc/include/asm/fb.h b/arch/sparc/include/asm/video.h
> similarity index 89%
> rename from arch/sparc/include/asm/fb.h
> rename to arch/sparc/include/asm/video.h
> index 07f0325d6921c..a6f48f52db584 100644
> --- a/arch/sparc/include/asm/fb.h
> +++ b/arch/sparc/include/asm/video.h
> @@ -1,6 +1,6 @@
> /* SPDX-License-Identifier: GPL-2.0 */
> -#ifndef _SPARC_FB_H_
> -#define _SPARC_FB_H_
> +#ifndef _SPARC_VIDEO_H_
> +#define _SPARC_VIDEO_H_
>
> #include <linux/io.h>
> #include <linux/types.h>
> @@ -40,6 +40,6 @@ static inline void fb_memset_io(volatile void __iomem *addr, int c, size_t n)
> }
> #define fb_memset fb_memset_io
>
> -#include <asm-generic/fb.h>
> +#include <asm-generic/video.h>
>
> -#endif /* _SPARC_FB_H_ */
> +#endif /* _SPARC_VIDEO_H_ */
> diff --git a/arch/sparc/video/Makefile b/arch/sparc/video/Makefile
> index 9dd82880a027a..fdf83a408d750 100644
> --- a/arch/sparc/video/Makefile
> +++ b/arch/sparc/video/Makefile
> @@ -1,3 +1,3 @@
> # SPDX-License-Identifier: GPL-2.0-only
>
> -obj-y += fbdev.o
> +obj-y += video.o
> diff --git a/arch/sparc/video/fbdev.c b/arch/sparc/video/video.c
> similarity index 86%
> rename from arch/sparc/video/fbdev.c
> rename to arch/sparc/video/video.c
> index e46f0499c2774..2414380caadc9 100644
> --- a/arch/sparc/video/fbdev.c
> +++ b/arch/sparc/video/video.c
> @@ -4,8 +4,8 @@
> #include <linux/device.h>
> #include <linux/module.h>
>
> -#include <asm/fb.h>
> #include <asm/prom.h>
> +#include <asm/video.h>
>
> bool video_is_primary_device(struct device *dev)
> {
> @@ -21,5 +21,5 @@ bool video_is_primary_device(struct device *dev)
> }
> EXPORT_SYMBOL(video_is_primary_device);
>
> -MODULE_DESCRIPTION("Sparc fbdev helpers");
> +MODULE_DESCRIPTION("Sparc video helpers");
> MODULE_LICENSE("GPL");
video.c is always built-in, so the MODULE_ things can be dropped.
That is an unrelated clean-up so should not be part of this patch.
> diff --git a/arch/x86/include/asm/fb.h b/arch/x86/include/asm/video.h
> similarity index 77%
> rename from arch/x86/include/asm/fb.h
> rename to arch/x86/include/asm/video.h
> index 999db33792869..0950c9535fae9 100644
> --- a/arch/x86/include/asm/fb.h
> +++ b/arch/x86/include/asm/video.h
> @@ -1,6 +1,6 @@
> /* SPDX-License-Identifier: GPL-2.0 */
> -#ifndef _ASM_X86_FB_H
> -#define _ASM_X86_FB_H
> +#ifndef _ASM_X86_VIDEO_H
> +#define _ASM_X86_VIDEO_H
>
> #include <linux/types.h>
>
> @@ -16,6 +16,6 @@ pgprot_t pgprot_framebuffer(pgprot_t prot,
> bool video_is_primary_device(struct device *dev);
> #define video_is_primary_device video_is_primary_device
>
> -#include <asm-generic/fb.h>
> +#include <asm-generic/video.h>
>
> -#endif /* _ASM_X86_FB_H */
> +#endif /* _ASM_X86_VIDEO_H */
> diff --git a/arch/x86/video/Makefile b/arch/x86/video/Makefile
> index 9dd82880a027a..fdf83a408d750 100644
> --- a/arch/x86/video/Makefile
> +++ b/arch/x86/video/Makefile
> @@ -1,3 +1,3 @@
> # SPDX-License-Identifier: GPL-2.0-only
>
> -obj-y += fbdev.o
> +obj-y += video.o
> diff --git a/arch/x86/video/fbdev.c b/arch/x86/video/video.c
> similarity index 97%
> rename from arch/x86/video/fbdev.c
> rename to arch/x86/video/video.c
> index 4d87ce8e257fe..81fc97a2a837a 100644
> --- a/arch/x86/video/fbdev.c
> +++ b/arch/x86/video/video.c
> @@ -10,7 +10,8 @@
> #include <linux/module.h>
> #include <linux/pci.h>
> #include <linux/vgaarb.h>
> -#include <asm/fb.h>
> +
> +#include <asm/video.h>
>
> pgprot_t pgprot_framebuffer(pgprot_t prot,
> unsigned long vm_start, unsigned long vm_end,
> diff --git a/include/asm-generic/Kbuild b/include/asm-generic/Kbuild
> index d436bee4d129d..b20fa25a7e8d8 100644
> --- a/include/asm-generic/Kbuild
> +++ b/include/asm-generic/Kbuild
> @@ -22,7 +22,6 @@ mandatory-y += dma-mapping.h
> mandatory-y += dma.h
> mandatory-y += emergency-restart.h
> mandatory-y += exec.h
> -mandatory-y += fb.h
> mandatory-y += ftrace.h
> mandatory-y += futex.h
> mandatory-y += hardirq.h
> @@ -62,5 +61,6 @@ mandatory-y += uaccess.h
> mandatory-y += unaligned.h
> mandatory-y += vermagic.h
> mandatory-y += vga.h
> +mandatory-y += video.h
> mandatory-y += word-at-a-time.h
> mandatory-y += xor.h
> diff --git a/include/asm-generic/fb.h b/include/asm-generic/video.h
> similarity index 96%
> rename from include/asm-generic/fb.h
> rename to include/asm-generic/video.h
> index 4788c1e1c6bc0..b1da2309d9434 100644
> --- a/include/asm-generic/fb.h
> +++ b/include/asm-generic/video.h
> @@ -1,7 +1,7 @@
> /* SPDX-License-Identifier: GPL-2.0 */
>
> -#ifndef __ASM_GENERIC_FB_H_
> -#define __ASM_GENERIC_FB_H_
> +#ifndef __ASM_GENERIC_VIDEO_H_
> +#define __ASM_GENERIC_VIDEO_H_
>
> /*
> * Only include this header file from your architecture's <asm/fb.h>.
> @@ -133,4 +133,4 @@ static inline void fb_memset_io(volatile void __iomem *addr, int c, size_t n)
> #define fb_memset fb_memset_io
> #endif
>
> -#endif /* __ASM_GENERIC_FB_H_ */
> +#endif /* __ASM_GENERIC_VIDEO_H_ */
> diff --git a/include/linux/fb.h b/include/linux/fb.h
> index 708e6a177b1be..1f23e0c505424 100644
> --- a/include/linux/fb.h
> +++ b/include/linux/fb.h
> @@ -12,7 +12,7 @@
> #include <linux/types.h>
> #include <linux/workqueue.h>
>
> -#include <asm/fb.h>
> +#include <asm/video.h>
>
> struct backlight_device;
> struct device;
> --
> 2.44.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 v2 2/3] dt-bindings: power: Add mediatek larb definition
From: Yu-chang Lee (李禹璋) @ 2024-03-28 7:03 UTC (permalink / raw)
To: krzysztof.kozlowski@linaro.org,
MandyJH Liu (劉人僖), conor+dt@kernel.org,
robh@kernel.org, krzysztof.kozlowski+dt@linaro.org,
matthias.bgg@gmail.com, ulf.hansson@linaro.org,
angelogioacchino.delregno@collabora.com
Cc: linux-kernel@vger.kernel.org, linux-mediatek@lists.infradead.org,
devicetree@vger.kernel.org, linux-pm@vger.kernel.org,
Project_Global_Chrome_Upstream_Group,
Xiufeng Li (李秀峰),
linux-arm-kernel@lists.infradead.org, Fan Chen (陳凡)
In-Reply-To: <c59f2f33-ad6b-469d-96be-9345920370b4@linaro.org>
On Wed, 2024-03-27 at 12:04 +0100, Krzysztof Kozlowski wrote:
>
> External email : Please do not click links or open attachments until
> you have verified the sender or the content.
> On 27/03/2024 11:56, Yu-chang Lee (李禹璋) wrote:
> > On Wed, 2024-03-27 at 11:43 +0100, Krzysztof Kozlowski wrote:
> >>
> >> External email : Please do not click links or open attachments
> until
> >> you have verified the sender or the content.
> >> On 27/03/2024 11:39, Yu-chang Lee (李禹璋) wrote:
> >>>>>>
> >>>>> Hi,
> >>>>>
> >>>>> I will double check the format of yaml for the next version,
> >> sorry
> >>>> for
> >>>>> inconvenience. But I did test it on mt8188 chromebook, the
> reason
> >>>> why
> >>>>
> >>>> How do you test a binding on chromebook?
> >>>>
> >>>>> power domain need larb node is that when mtcmos power on,
> signal
> >>>> glitch
> >>>>> may produce. Power domain driver must reset larb when this
> happen
> >>>> to
> >>>>> prevent dummy transaction on bus. That why I need larb node in
> >> dts.
> >>>>
> >>>> No one talks here about larb node...
> >>>
> >>> Sorry, May you elaborate on what information I need to provide to
> >> you
> >>> or it is just a syntax problem I need to fix?
> >>
> >> Please explain the purpose of this property (how is it going to be
> >> used by drivers)and what does it represent.
> >>
> >
> > It represent SMI LARB(Local ARBitration). In power domain driver
> when
> > power on power domain, It need to reset LARB to prevent potential
> power
> > glitch which may cause dummy transaction on bus. Without taking
> care of
> > this issue it often leads to camera hang in stress test.
>
> That sounds rather like missing resets... or something else
> connecting
> these devices. Maybe the explanation is just imprecise...
>
Maybe the term "reset" is misleading here. What power domain driver
trying to do is "set and then clr" the smi larb to clear potential
glitch signal that is already in there. And this step is strongly
related to power domain onf that why I want to add it in to power
domain node without depending larb driver to do the work to prevent
this setting missing.
> Best regards,
> Krzysztof
Best Regards,
yu-chang
>
_______________________________________________
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] arm64: mm: Batch dsb and isb when populating pgtables
From: Ard Biesheuvel @ 2024-03-28 7:23 UTC (permalink / raw)
To: Ryan Roberts
Cc: Catalin Marinas, Will Deacon, Mark Rutland, David Hildenbrand,
Donald Dutile, Eric Chanudet, linux-arm-kernel, linux-kernel
In-Reply-To: <20240327190723.185232-1-ryan.roberts@arm.com>
On Wed, 27 Mar 2024 at 21:07, Ryan Roberts <ryan.roberts@arm.com> wrote:
>
> After removing uneccessary TLBIs, the next bottleneck when creating the
> page tables for the linear map is DSB and ISB, which were previously
> issued per-pte in __set_pte(). Since we are writing multiple ptes in a
> given pte table, we can elide these barriers and insert them once we
> have finished writing to the table.
>
Nice!
> Signed-off-by: Ryan Roberts <ryan.roberts@arm.com>
> ---
> arch/arm64/include/asm/pgtable.h | 7 ++++++-
> arch/arm64/mm/mmu.c | 13 ++++++++++++-
> 2 files changed, 18 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm64/include/asm/pgtable.h b/arch/arm64/include/asm/pgtable.h
> index bd5d02f3f0a3..81e427b23b3f 100644
> --- a/arch/arm64/include/asm/pgtable.h
> +++ b/arch/arm64/include/asm/pgtable.h
> @@ -271,9 +271,14 @@ static inline pte_t pte_mkdevmap(pte_t pte)
> return set_pte_bit(pte, __pgprot(PTE_DEVMAP | PTE_SPECIAL));
> }
>
> -static inline void __set_pte(pte_t *ptep, pte_t pte)
> +static inline void ___set_pte(pte_t *ptep, pte_t pte)
IMHO, we should either use WRITE_ONCE() directly in the caller, or
find a better name.
> {
> WRITE_ONCE(*ptep, pte);
> +}
> +
> +static inline void __set_pte(pte_t *ptep, pte_t pte)
> +{
> + ___set_pte(ptep, pte);
>
> /*
> * Only if the new pte is valid and kernel, otherwise TLB maintenance
> diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
> index 1b2a2a2d09b7..c6d5a76732d4 100644
> --- a/arch/arm64/mm/mmu.c
> +++ b/arch/arm64/mm/mmu.c
> @@ -301,7 +301,11 @@ static pte_t *init_pte(pte_t *ptep, unsigned long addr, unsigned long end,
> do {
> pte_t old_pte = __ptep_get(ptep);
>
> - __set_pte(ptep, pfn_pte(__phys_to_pfn(phys), prot));
> + /*
> + * Required barriers to make this visible to the table walker
> + * are deferred to the end of alloc_init_cont_pte().
> + */
> + ___set_pte(ptep, pfn_pte(__phys_to_pfn(phys), prot));
>
> /*
> * After the PTE entry has been populated once, we
> @@ -358,6 +362,13 @@ static void alloc_init_cont_pte(pmd_t *pmdp, unsigned long addr,
> } while (addr = next, addr != end);
>
> ops->unmap(TYPE_PTE);
> +
> + /*
> + * Ensure all previous pgtable writes are visible to the table walker.
> + * See init_pte().
> + */
> + dsb(ishst);
> + isb();
> }
>
> static pmd_t *init_pmd(pmd_t *pmdp, unsigned long addr, unsigned long end,
> --
> 2.25.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: [RESEND][PATCH v2 3/4] PM: EM: Add em_dev_update_chip_binning()
From: Dietmar Eggemann @ 2024-03-28 7:21 UTC (permalink / raw)
To: Lukasz Luba
Cc: linux-arm-kernel, sboyd, nm, linux-samsung-soc, daniel.lezcano,
rafael, viresh.kumar, krzysztof.kozlowski, alim.akhtar,
m.szyprowski, mhiramat, linux-kernel, linux-pm
In-Reply-To: <410c5da7-c79c-4607-9aa3-2e78d991d2d7@arm.com>
On 27/03/2024 13:55, Dietmar Eggemann wrote:
> On 26/03/2024 21:32, Lukasz Luba wrote:
>>
>>
>> On 3/26/24 10:09, Dietmar Eggemann wrote:
>>> On 22/03/2024 12:08, Lukasz Luba wrote:
>
> [...]
>
>>>> + return em_recalc_and_update(dev, pd, em_table);
>>>> +}
>>>> +EXPORT_SYMBOL_GPL(em_dev_update_chip_binning);
>>>
>>> In the previous version of 'chip-binning' you were using the new EM
>>> interface em_dev_compute_costs() (1) which is now replaced by
>>> em_recalc_and_update() -> em_compute_costs().
>>>
>>> https://lkml.kernel.org/r/20231220110339.1065505-2-lukasz.luba@arm.com
>>>
>>> Which leaves (1) still unused.
>>>
>>> That was why my concern back then that we shouldn't introduce EM
>>> interfaces without a user:
>>>
>>> https://lkml.kernel.org/r/8fc499cf-fca1-4465-bff7-a93dfd36f3c8@arm.com
>>>
>>> What happens now with em_dev_compute_costs()?
>>>
>>
>> For now it's not used, but modules which will create new EMs
>> with custom power values will use it. When such a module have
>> e.g. 5 EMs for one PD and only switches on one of them, then
>> this em_dev_compute_costs() will be used at setup for those
>> 5 EMs. Later it won't be used.
>> I don't wanted to combine the registration of new EM with
>> the compute cost, because that will create overhead in the
>> switching to new EM code path. Now we have only ~3us, which
>> was the main goal.
>>
>> When our scmi-cpufreq get the support for EM update this
>> compute cost will be used there.
>
> OK, I see. I checked the reloadable EM test module and
> em_dev_compute_costs() is used there like you described it.
I had a second look and IMHO the layout is like this:
Internal (1) and external (2,3) 'reloadable EM' use cases:
(EM alloc and free not depicted)
1. Late CPUs booting (CPU capacity adjustment)
e3f1164fc9ee PM: EM: Support late CPUs booting and capacity adjustment
schedule_delayed_work(&em_update_work, ...)
em_update_workfn()
em_check_capacity_update()
em_adjust_new_capacity()
em_recalc_and_update() <-- (i)
em_compute_costs() <-- (ii)
em_dev_update_perf_domain() <-- external
2. Reload EM from driver
22ea02848c07 PM: EM: Add em_dev_compute_costs()
977230d5d503 PM: EM: Introduce em_dev_update_perf_domain() for EM
updates
em_dev_compute_costs() <-- external
em_compute_costs() <-- (ii)
em_dev_update_perf_domain() <-- external
3. Chip binning
this patchset PM: EM: Add em_dev_update_chip_binning()
em_dev_update_chip_binning() <-- external
em_recalc_and_update() <-- (i)
em_compute_costs() <-- (ii)
em_dev_update_perf_domain() <-- external
_______________________________________________
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/6] arm64: dts: qcom: qcs6490-rb3gen2: Add DP output
From: Dmitry Baryshkov @ 2024-03-28 7:17 UTC (permalink / raw)
To: Bjorn Andersson
Cc: Bjorn Andersson, cros-qcom-dts-watchers, Konrad Dybcio,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Catalin Marinas,
Will Deacon, linux-arm-msm, devicetree, linux-kernel,
linux-arm-kernel
In-Reply-To: <zsjzysb7h3wi3cfpaozl46l4jnsd7e3lxttzm5vptozjx24cqo@vqmyhl65q7ay>
On Thu, 28 Mar 2024 at 05:07, Bjorn Andersson <andersson@kernel.org> wrote:
>
> On Thu, Mar 28, 2024 at 03:51:54AM +0200, Dmitry Baryshkov wrote:
> > On Wed, 27 Mar 2024 at 04:04, Bjorn Andersson <quic_bjorande@quicinc.com> wrote:
> > >
> > > The RB3Gen2 board comes with a mini DP connector, describe this, enable
> > > MDSS, DP controller and the PHY that drives this.
> > >
> > > Signed-off-by: Bjorn Andersson <quic_bjorande@quicinc.com>
> > > ---
> > > arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts | 40 ++++++++++++++++++++++++++++
> > > 1 file changed, 40 insertions(+)
> > >
> > > diff --git a/arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts b/arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts
> > > index 63ebe0774f1d..f90bf3518e98 100644
> > > --- a/arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts
> > > +++ b/arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts
> > > @@ -39,6 +39,20 @@ chosen {
> > > stdout-path = "serial0:115200n8";
> > > };
> > >
> > > + dp-connector {
> > > + compatible = "dp-connector";
> > > + label = "DP";
> > > + type = "mini";
> > > +
> > > + hpd-gpios = <&tlmm 60 GPIO_ACTIVE_HIGH>;
> >
> > Is it the standard hpd gpio? If so, is there any reason for using it
> > through dp-connector rather than as a native HPD signal?
> >
>
> I added it because you asked for it. That said, I do like having it
> clearly defined in the devicetree.
I asked for the dp-connector device, not for the HPD function change.
--
With best wishes
Dmitry
_______________________________________________
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 RFC 0/3] mm/gup: consistently call it GUP-fast
From: Mike Rapoport @ 2024-03-28 7:15 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Vineet Gupta, David Hildenbrand, peterx, linux-kernel,
Andrew Morton, Jason Gunthorpe, John Hubbard, linux-arm-kernel,
loongarch, linux-mips, linuxppc-dev, linux-s390, linux-sh,
linux-mm, linux-perf-users, linux-fsdevel, x86, Ryan Roberts,
Alexander Viro, Matt Turner, Alexey Brodkin
In-Reply-To: <10da3ced-9a79-4ebb-a77d-1aa49cc61952@app.fastmail.com>
On Thu, Mar 28, 2024 at 07:09:13AM +0100, Arnd Bergmann wrote:
> On Thu, Mar 28, 2024, at 06:51, Vineet Gupta wrote:
> > On 3/27/24 09:22, Arnd Bergmann wrote:
> >> On Wed, Mar 27, 2024, at 16:39, David Hildenbrand wrote:
> >>> On 27.03.24 16:21, Peter Xu wrote:
> >>>> On Wed, Mar 27, 2024 at 02:05:35PM +0100, David Hildenbrand wrote:
> >>>>
> >>>> I'm not sure what config you tried there; as I am doing some build tests
> >>>> recently, I found turning off CONFIG_SAMPLES + CONFIG_GCC_PLUGINS could
> >>>> avoid a lot of issues, I think it's due to libc missing. But maybe not the
> >>>> case there.
> >>> CCin Arnd; I use some of his compiler chains, others from Fedora directly. For
> >>> example for alpha and arc, the Fedora gcc is "13.2.1".
> >>> But there is other stuff like (arc):
> >>>
> >>> ./arch/arc/include/asm/mmu-arcv2.h: In function 'mmu_setup_asid':
> >>> ./arch/arc/include/asm/mmu-arcv2.h:82:9: error: implicit declaration of
> >>> function 'write_aux_reg' [-Werro
> >>> r=implicit-function-declaration]
> >>> 82 | write_aux_reg(ARC_REG_PID, asid | MMU_ENABLE);
> >>> | ^~~~~~~~~~~~~
> >> Seems to be missing an #include of soc/arc/aux.h, but I can't
> >> tell when this first broke without bisecting.
> >
> > Weird I don't see this one but I only have gcc 12 handy ATM.
> >
> > gcc version 12.2.1 20230306 (ARC HS GNU/Linux glibc toolchain -
> > build 1360)
> >
> > I even tried W=1 (which according to scripts/Makefile.extrawarn) should
> > include -Werror=implicit-function-declaration but don't see this still.
> >
> > Tomorrow I'll try building a gcc 13.2.1 for ARC.
>
> David reported them with the toolchains I built at
> https://mirrors.edge.kernel.org/pub/tools/crosstool/
> I'm fairly sure the problem is specific to the .config
> and tree, not the toolchain though.
This happens with defconfig and both gcc 12.2.0 and gcc 13.2.0 from your
crosstools. I also see these on the current Linus' tree:
arc/kernel/ptrace.c:342:16: warning: no previous prototype for 'syscall_trace_enter' [-Wmissing-prototypes]
arch/arc/kernel/kprobes.c:193:15: warning: no previous prototype for 'arc_kprobe_handler' [-Wmissing-prototypes]
This fixed the warning about write_aux_reg for me, probably Vineet would
want this include somewhere else...
diff --git a/arch/arc/include/asm/mmu-arcv2.h b/arch/arc/include/asm/mmu-arcv2.h
index ed9036d4ede3..0fca342d7b79 100644
--- a/arch/arc/include/asm/mmu-arcv2.h
+++ b/arch/arc/include/asm/mmu-arcv2.h
@@ -69,6 +69,8 @@
#ifndef __ASSEMBLY__
+#include <asm/arcregs.h>
+
struct mm_struct;
extern int pae40_exist_but_not_enab(void);
> >>> or (alpha)
> >>>
> >>> WARNING: modpost: "saved_config" [vmlinux] is COMMON symbol
> >>> ERROR: modpost: "memcpy" [fs/reiserfs/reiserfs.ko] undefined!
> >>> ERROR: modpost: "memcpy" [fs/nfs/nfs.ko] undefined!
> >>> ERROR: modpost: "memcpy" [fs/nfs/nfsv3.ko] undefined!
> >>> ERROR: modpost: "memcpy" [fs/nfsd/nfsd.ko] undefined!
> >>> ERROR: modpost: "memcpy" [fs/lockd/lockd.ko] undefined!
> >>> ERROR: modpost: "memcpy" [crypto/crypto.ko] undefined!
> >>> ERROR: modpost: "memcpy" [crypto/crypto_algapi.ko] undefined!
> >>> ERROR: modpost: "memcpy" [crypto/aead.ko] undefined!
> >>> ERROR: modpost: "memcpy" [crypto/crypto_skcipher.ko] undefined!
> >>> ERROR: modpost: "memcpy" [crypto/seqiv.ko] undefined!
> >
> > Are these from ARC build or otherwise ?
>
> This was arch/alpha.
>
> Arnd
--
Sincerely yours,
Mike.
_______________________________________________
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] arm64: dts: rockchip: Add enable-strobe-pulldown to emmc phy on ROCK Pi 4
From: Folker Schwesinger @ 2024-03-28 7:08 UTC (permalink / raw)
To: wens
Cc: Vinod Koul, Yogesh Hegde, Heiko Stuebner, Chris Ruehl,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Dragan Simic,
Christopher Obbard, linux-arm-kernel, linux-rockchip,
linux-kernel, devicetree
In-Reply-To: <CAGb2v64cF2fuW7vKq_=AhY+ciAp8t=fxT23AFJWB1qOv1xWuNw@mail.gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 730 bytes --]
On Thu Mar 28, 2024 at 6:39 AM CET, Chen-Yu Tsai wrote:
> > @@ -648,7 +649,8 @@ &saradc {
> > &sdhci {
> > max-frequency = <150000000>;
> > bus-width = <8>;
> > - mmc-hs200-1_8v;
>
> Shouldn't this be kept around? The node should list all supported modes,
> not just the highest one. Same for the other patch.
>
This is not necessary, mmc-hs400-1_8v implicitly activates the
corresponding HS200 capability, see drivers/mmc/core/host.c:
if (device_property_read_bool(dev, "mmc-hs200-1_8v"))
host->caps2 |= MMC_CAP2_HS200_1_8V_SDR;
/* ... */
if (device_property_read_bool(dev, "mmc-hs400-1_8v"))
host->caps2 |= MMC_CAP2_HS400_1_8V | MMC_CAP2_HS200_1_8V_SDR;
Kind regards
Folker
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 265 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 v11 00/11] Support page table check PowerPC
From: Christophe Leroy @ 2024-03-28 6:52 UTC (permalink / raw)
To: Rohan McLure, linuxppc-dev@lists.ozlabs.org
Cc: mpe@ellerman.id.au, linux-mm@kvack.org,
linux-riscv@lists.infradead.org,
linux-arm-kernel@lists.infradead.org, x86@kernel.org
In-Reply-To: <20240328045535.194800-3-rmclure@linux.ibm.com>
Le 28/03/2024 à 05:55, Rohan McLure a écrit :
> Support page table check on all PowerPC platforms. This works by
> serialising assignments, reassignments and clears of page table
> entries at each level in order to ensure that anonymous mappings
> have at most one writable consumer, and likewise that file-backed
> mappings are not simultaneously also anonymous mappings.
>
> In order to support this infrastructure, a number of stubs must be
> defined for all powerpc platforms. Additionally, seperate set_pte_at()
> and set_pte_at_unchecked(), to allow for internal, uninstrumented mappings.
I gave it a try on QEMU e500 (64 bits), and get the following Oops. What
do I have to look for ?
Freeing unused kernel image (initmem) memory: 2588K
This architecture does not have kernel memory protection.
Run /init as init process
------------[ cut here ]------------
kernel BUG at mm/page_table_check.c:119!
Oops: Exception in kernel mode, sig: 5 [#1]
BE PAGE_SIZE=4K SMP NR_CPUS=32 QEMU e500
Modules linked in:
CPU: 0 PID: 1 Comm: init Not tainted 6.8.0-13732-gc5347beead0b-dirty #784
Hardware name: QEMU ppce500 e5500 0x80240020 QEMU e500
NIP: c0000000002951a0 LR: c0000000002951bc CTR: 0000000000000000
REGS: c0000000032e7440 TRAP: 0700 Not tainted
(6.8.0-13732-gc5347beead0b-dirty)
MSR: 0000000080029002 <CE,EE,ME> CR: 24044248 XER: 00000000
IRQMASK: 0
GPR00: c000000000029d90 c0000000032e76e0 c000000000d44000 c000000003017e18
GPR04: 00000000ffb11000 c000000007f16888 0000000fc324123d 0000000000000000
GPR08: 0000000000000000 0000000000000001 c000000001184000 0000000084004248
GPR12: 00000000000000c0 c0000000011b9000 c000000007f16888 c000000007f19000
GPR16: 0000000000001000 00003ffffffff000 0000000000000000 0000000000000000
GPR20: 0000400000000000 0000000000000000 0000000000000001 ffffc000ffb12000
GPR24: c000000007f19000 c000000006008000 c000000006008000 0000000000000030
GPR28: 0000000000000001 c00000000118afe8 c000000003017e18 0000000000000001
NIP [c0000000002951a0] __page_table_check_ptes_set+0x210/0x2ac
LR [c0000000002951bc] __page_table_check_ptes_set+0x22c/0x2ac
Call Trace:
[c0000000032e76e0] [c0000000032e7790] 0xc0000000032e7790 (unreliable)
[c0000000032e7730] [c000000000029d90] set_ptes+0x178/0x210
[c0000000032e7790] [c00000000024c72c] move_page_tables+0x298/0x750
[c0000000032e7870] [c0000000002a944c] shift_arg_pages+0x120/0x254
[c0000000032e79a0] [c0000000002a9f94] setup_arg_pages+0x244/0x418
[c0000000032e7b30] [c000000000331610] load_elf_binary+0x584/0x17d4
[c0000000032e7c30] [c0000000002aa3e8] bprm_execve+0x280/0x704
[c0000000032e7d00] [c0000000002ac158] kernel_execve+0x16c/0x214
[c0000000032e7d50] [c0000000000011c8] run_init_process+0x100/0x168
[c0000000032e7de0] [c00000000000214c] kernel_init+0x84/0x1f8
[c0000000032e7e50] [c000000000000594] ret_from_kernel_user_thread+0x14/0x1c
--- interrupt: 0 at 0x0
Code: 81230004 7d2907b4 0b090000 7c0004ac 7d201828 31290001 7d20192d
40c2fff4 7c0004ac 2c090002 39200000 7d29e01e <0b090000> e93d0000
37ffffff 7fde4a14
---[ end trace 0000000000000000 ]---
note: init[1] exited with irqs disabled
Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000005
Rebooting in 180 seconds..
_______________________________________________
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: imx6sl: tolino-shine2hd: fix IRQ config of touchscreen
From: Shawn Guo @ 2024-03-28 6:50 UTC (permalink / raw)
To: Andreas Kemnade
Cc: robh+dt, krzysztof.kozlowski+dt, conor+dt, shawnguo, s.hauer,
kernel, festevam, linux-imx, devicetree, linux-arm-kernel,
linux-kernel, Dmitry Torokhov
In-Reply-To: <20240225225622.3419104-1-andreas@kemnade.info>
On Sun, Feb 25, 2024 at 11:56:22PM +0100, Andreas Kemnade wrote:
> Correctly describe the interrupt as level low. Driver enforces that
> anyways, but do not rely on that in the devicetree.
>
> Suggested-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
> Signed-off-by: Andreas Kemnade <andreas@kemnade.info>
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
* Re: [PATCH v2 0/2] add uSDHC and SCMI nodes to the S32G2 SoC
From: Shawn Guo @ 2024-03-28 6:37 UTC (permalink / raw)
To: Ghennadi Procopciuc
Cc: Chester Lin, Andreas Farber, Matthias Brugger, Shawn Guo,
Sascha Hauer, Fabio Estevam, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Michael Turquette, Stephen Boyd, NXP S32 Linux Team,
Pengutronix Kernel Team, NXP Linux Team, linux-arm-kernel,
devicetree, linux-kernel, linux-clk, Ghennadi Procopciuc
In-Reply-To: <20240122140602.1006813-1-ghennadi.procopciuc@oss.nxp.com>
On Mon, Jan 22, 2024 at 04:05:59PM +0200, Ghennadi Procopciuc wrote:
> From: Ghennadi Procopciuc <ghennadi.procopciuc@nxp.com>
>
> This patchset adds device tree support for S32G2 SCMI firmware and uSDHC
> node. The SCMI clock IDs are based on a downstream version of the TF-A
> stored on GitHub [0].
>
> I can send the patches individually if you prefer that instead of
> submitting them all at once.??
>
> [0] https://github.com/nxp-auto-linux/arm-trusted-firmware
>
> Changes in v2:
> - The SCMI clock bindings header has been removed.
>
> Ghennadi Procopciuc (2):
> arm64: dts: s32g: add SCMI firmware node
> arm64: dts: s32g: add uSDHC node
Applied both, 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: [PATCH net-next v3 3/3] net: ti: icssg-prueth: Add support for ICSSG switch firmware
From: MD Danish Anwar @ 2024-03-28 6:09 UTC (permalink / raw)
To: Andrew Lunn
Cc: Diogo Ivo, Rob Herring, Dan Carpenter, Jan Kiszka, Simon Horman,
Wolfram Sang, Arnd Bergmann, Vignesh Raghavendra, Vladimir Oltean,
Roger Quadros, Paolo Abeni, Jakub Kicinski, Eric Dumazet,
David S. Miller, linux-arm-kernel, netdev, linux-kernel, srk,
r-gunasekaran
In-Reply-To: <27d960ed-8e67-431b-a910-e6b2fc12e292@lunn.ch>
Hi Andrew,
On 27/03/24 6:05 pm, Andrew Lunn wrote:
> On Wed, Mar 27, 2024 at 05:10:54PM +0530, MD Danish Anwar wrote:
>> Add support for ICSSG switch firmware using existing Dual EMAC driver
>> with switchdev.
>>
>> Limitations:
>> VLAN offloading is limited to 0-256 IDs.
>> MDB/FDB static entries are limited to 511 entries and different FDBs can
>> hash to same bucket and thus may not completely offloaded
>>
>> Switch mode requires loading of new firmware into ICSSG cores. This
>> means interfaces have to taken down and then reconfigured to switch
>> mode.
>
> Patch 0/3 does not say this. It just shows the interfaces being added
I will modify the cover letter to state that.
> to the bridge. There should not be any need to down the interfaces.
>
The interfaces needs to be turned down for switching between dual emac
and switch mode.
Dual Emac mode runs with ICSSG Dual Emac firmware where as Switch mode
works with ICSSG Switch firmware. These firmware are running on the
dedicated PRU RPROC cores (pru0, rtu0, txpru0). When switch mode is
enabled, these pru cores need to be stopped and then Switch firmware is
loaded on these cores and then the cores are started again.
We stop the cores when interfaces are down and start the cores when
interfaces are up.
In short, Dual EMAC firmware runs on pru cores, we put down the
interface, stop pru cores, load switch firmware on the cores, bring the
interface up and start the pru cores and now Switch mode is enabled.
>> Example assuming ETH1 and ETH2 as ICSSG2 interfaces:
>>
>> Switch to ICSSG Switch mode:
>> ip link set dev eth1 down
>> ip link set dev eth2 down
>> ip link add name br0 type bridge
>> ip link set dev eth1 master br0
>> ip link set dev eth2 master br0
>> ip link set dev br0 up
>> ip link set dev eth1 up
>> ip link set dev eth2 up
>> bridge vlan add dev br0 vid 1 pvid untagged self
>>
>> Going back to Dual EMAC mode:
>>
>> ip link set dev br0 down
>> ip link set dev eth1 nomaster
>> ip link set dev eth2 nomaster
>> ip link set dev eth1 down
>> ip link set dev eth2 down
>> ip link del name br0 type bridge
>> ip link set dev eth1 up
>> ip link set dev eth2 up
>>
>> By default, Dual EMAC firmware is loaded, and can be changed to switch
>> mode by above steps
>
> I keep asking this, so it would be good to explain it in the commit
> message. What configuration is preserved over a firmware reload, and
> what is lost?
>
> Can i add VLAN in duel MAC mode and then swap into the switch firmware
> and all the VLANs are preserved? Can i add fdb entries to a port in
> dual MAC mode, and then swap into the swtich firmware and the FDB
> table is preserved? What about STP port state? What about ... ?
>
When ports are brought up (firmware reload) we do a full cleaning of all
the shared memories i.e. SMEM (shared RAM). [1]
Vlan table and FDB table are stored in SMEM so all the configuration
done to VLAN / FDB tables will be lost.
We don't clear DRAM. DRAM is used for sending r30 commands [see
emac_r30_cmd_init()], configure half duplex [see
icssg_config_half_duplex()] and configure link speed [see
icssg_config_set_speed()]. r30 commands are used to set port state (stp).
Now when the interfaces are brought up (firmware reload) r30 command is
reconfigured as a result any changes done to port state (stp) will be
lost. But the duplex and speed settings will be preserved.
To summarize,
VLAN table / FDB table and port states are lost during a firmware reload.
[1]
https://elixir.bootlin.com/linux/latest/source/drivers/net/ethernet/ti/icssg/icssg_prueth.c#L1321
>
>> +bool prueth_dev_check(const struct net_device *ndev)
>> +{
>> + if (ndev->netdev_ops == &emac_netdev_ops && netif_running(ndev)) {
>> + struct prueth_emac *emac = netdev_priv(ndev);
>> +
>> + return emac->prueth->is_switch_mode;
>> + }
>> +
>> + return false;
>> +}
>
> This does not appear to be used anywhere?
>
> Andrew
--
Thanks and Regards,
Danish
_______________________________________________
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 RFC 0/3] mm/gup: consistently call it GUP-fast
From: Arnd Bergmann @ 2024-03-28 6:09 UTC (permalink / raw)
To: Vineet Gupta, David Hildenbrand, peterx
Cc: linux-kernel, Andrew Morton, Mike Rapoport, Jason Gunthorpe,
John Hubbard, linux-arm-kernel, loongarch, linux-mips,
linuxppc-dev, linux-s390, linux-sh, linux-mm, linux-perf-users,
linux-fsdevel, x86, Ryan Roberts, Alexander Viro, Matt Turner,
Alexey Brodkin
In-Reply-To: <3360dba8-0fac-4126-b72b-abc036957d6a@kernel.org>
On Thu, Mar 28, 2024, at 06:51, Vineet Gupta wrote:
> On 3/27/24 09:22, Arnd Bergmann wrote:
>> On Wed, Mar 27, 2024, at 16:39, David Hildenbrand wrote:
>>> On 27.03.24 16:21, Peter Xu wrote:
>>>> On Wed, Mar 27, 2024 at 02:05:35PM +0100, David Hildenbrand wrote:
>>>>
>>>> I'm not sure what config you tried there; as I am doing some build tests
>>>> recently, I found turning off CONFIG_SAMPLES + CONFIG_GCC_PLUGINS could
>>>> avoid a lot of issues, I think it's due to libc missing. But maybe not the
>>>> case there.
>>> CCin Arnd; I use some of his compiler chains, others from Fedora directly. For
>>> example for alpha and arc, the Fedora gcc is "13.2.1".
>>> But there is other stuff like (arc):
>>>
>>> ./arch/arc/include/asm/mmu-arcv2.h: In function 'mmu_setup_asid':
>>> ./arch/arc/include/asm/mmu-arcv2.h:82:9: error: implicit declaration of
>>> function 'write_aux_reg' [-Werro
>>> r=implicit-function-declaration]
>>> 82 | write_aux_reg(ARC_REG_PID, asid | MMU_ENABLE);
>>> | ^~~~~~~~~~~~~
>> Seems to be missing an #include of soc/arc/aux.h, but I can't
>> tell when this first broke without bisecting.
>
> Weird I don't see this one but I only have gcc 12 handy ATM.
>
> gcc version 12.2.1 20230306 (ARC HS GNU/Linux glibc toolchain -
> build 1360)
>
> I even tried W=1 (which according to scripts/Makefile.extrawarn) should
> include -Werror=implicit-function-declaration but don't see this still.
>
> Tomorrow I'll try building a gcc 13.2.1 for ARC.
David reported them with the toolchains I built at
https://mirrors.edge.kernel.org/pub/tools/crosstool/
I'm fairly sure the problem is specific to the .config
and tree, not the toolchain though.
>>> or (alpha)
>>>
>>> WARNING: modpost: "saved_config" [vmlinux] is COMMON symbol
>>> ERROR: modpost: "memcpy" [fs/reiserfs/reiserfs.ko] undefined!
>>> ERROR: modpost: "memcpy" [fs/nfs/nfs.ko] undefined!
>>> ERROR: modpost: "memcpy" [fs/nfs/nfsv3.ko] undefined!
>>> ERROR: modpost: "memcpy" [fs/nfsd/nfsd.ko] undefined!
>>> ERROR: modpost: "memcpy" [fs/lockd/lockd.ko] undefined!
>>> ERROR: modpost: "memcpy" [crypto/crypto.ko] undefined!
>>> ERROR: modpost: "memcpy" [crypto/crypto_algapi.ko] undefined!
>>> ERROR: modpost: "memcpy" [crypto/aead.ko] undefined!
>>> ERROR: modpost: "memcpy" [crypto/crypto_skcipher.ko] undefined!
>>> ERROR: modpost: "memcpy" [crypto/seqiv.ko] undefined!
>
> Are these from ARC build or otherwise ?
This was arch/alpha.
Arnd
_______________________________________________
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: dts: lx2160a: add pinmux and i2c gpio to support bus recovery
From: carlos.song @ 2024-03-28 6:14 UTC (permalink / raw)
To: shawnguo, robh, krzysztof.kozlowski+dt, conor+dt
Cc: frank.li, linux-arm-kernel, devicetree, linux-kernel
From: Carlos Song <carlos.song@nxp.com>
I2C bus recovery need a pinmux and gpio. So i2c driver can switch
gpio mode to toggle scl to recovery bus.
Add pinctrl-single node to every i2c bus on fsl-ls2160 layerscape
platform.
Signed-off-by: Carlos Song <carlos.song@nxp.com>
Reviewed-by: Frank Li <frank.li@nxp.com>
diff --git a/arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi b/arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi
index e665c629e1a1..96055593204a 100644
--- a/arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi
@@ -748,7 +748,10 @@ i2c0: i2c@2000000 {
clock-names = "i2c";
clocks = <&clockgen QORIQ_CLK_PLATFORM_PLL
QORIQ_CLK_PLL_DIV(16)>;
- scl-gpios = <&gpio2 15 GPIO_ACTIVE_HIGH>;
+ pinctrl-names = "default", "gpio";
+ pinctrl-0 = <&i2c0_scl>;
+ pinctrl-1 = <&i2c0_scl_gpio>;
+ scl-gpios = <&gpio0 3 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
status = "disabled";
};
@@ -761,6 +764,10 @@ i2c1: i2c@2010000 {
clock-names = "i2c";
clocks = <&clockgen QORIQ_CLK_PLATFORM_PLL
QORIQ_CLK_PLL_DIV(16)>;
+ pinctrl-names = "default", "gpio";
+ pinctrl-0 = <&i2c1_scl>;
+ pinctrl-1 = <&i2c1_scl_gpio>;
+ scl-gpios = <&gpio0 31 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
status = "disabled";
};
@@ -773,6 +780,10 @@ i2c2: i2c@2020000 {
clock-names = "i2c";
clocks = <&clockgen QORIQ_CLK_PLATFORM_PLL
QORIQ_CLK_PLL_DIV(16)>;
+ pinctrl-names = "default", "gpio";
+ pinctrl-0 = <&i2c2_scl>;
+ pinctrl-1 = <&i2c2_scl_gpio>;
+ scl-gpios = <&gpio0 29 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
status = "disabled";
};
@@ -785,6 +796,10 @@ i2c3: i2c@2030000 {
clock-names = "i2c";
clocks = <&clockgen QORIQ_CLK_PLATFORM_PLL
QORIQ_CLK_PLL_DIV(16)>;
+ pinctrl-names = "default", "gpio";
+ pinctrl-0 = <&i2c3_scl>;
+ pinctrl-1 = <&i2c3_scl_gpio>;
+ scl-gpios = <&gpio0 27 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
status = "disabled";
};
@@ -797,7 +812,10 @@ i2c4: i2c@2040000 {
clock-names = "i2c";
clocks = <&clockgen QORIQ_CLK_PLATFORM_PLL
QORIQ_CLK_PLL_DIV(16)>;
- scl-gpios = <&gpio2 16 GPIO_ACTIVE_HIGH>;
+ pinctrl-names = "default", "gpio";
+ pinctrl-0 = <&i2c4_scl>;
+ pinctrl-1 = <&i2c4_scl_gpio>;
+ scl-gpios = <&gpio0 25 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
status = "disabled";
};
@@ -810,6 +828,10 @@ i2c5: i2c@2050000 {
clock-names = "i2c";
clocks = <&clockgen QORIQ_CLK_PLATFORM_PLL
QORIQ_CLK_PLL_DIV(16)>;
+ pinctrl-names = "default", "gpio";
+ pinctrl-0 = <&i2c5_scl>;
+ pinctrl-1 = <&i2c5_scl_gpio>;
+ scl-gpios = <&gpio0 23 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
status = "disabled";
};
@@ -822,6 +844,10 @@ i2c6: i2c@2060000 {
clock-names = "i2c";
clocks = <&clockgen QORIQ_CLK_PLATFORM_PLL
QORIQ_CLK_PLL_DIV(16)>;
+ pinctrl-names = "default", "gpio";
+ pinctrl-0 = <&i2c6_scl>;
+ pinctrl-1 = <&i2c6_scl_gpio>;
+ scl-gpios = <&gpio1 16 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
status = "disabled";
};
@@ -834,6 +860,10 @@ i2c7: i2c@2070000 {
clock-names = "i2c";
clocks = <&clockgen QORIQ_CLK_PLATFORM_PLL
QORIQ_CLK_PLL_DIV(16)>;
+ pinctrl-names = "default", "gpio";
+ pinctrl-0 = <&i2c7_scl>;
+ pinctrl-1 = <&i2c7_scl_gpio>;
+ scl-gpios = <&gpio1 18 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
status = "disabled";
};
@@ -1669,6 +1699,80 @@ pcs18: ethernet-phy@0 {
};
};
+ pinmux_i2crv: pinmux@70010012c {
+ compatible = "pinctrl-single";
+ reg = <0x00000007 0x0010012c 0x0 0xc>;
+ #address-cells = <2>;
+ #size-cells = <2>;
+ pinctrl-single,bit-per-mux;
+ pinctrl-single,register-width = <32>;
+ pinctrl-single,function-mask = <0x7>;
+
+ i2c1_scl: i2c1-scl-pins {
+ pinctrl-single,bits = <0x0 0 0x7>;
+ };
+
+ i2c1_scl_gpio: i2c1-scl-gpio-pins {
+ pinctrl-single,bits = <0x0 0x1 0x7>;
+ };
+
+ i2c2_scl: i2c2-scl-pins {
+ pinctrl-single,bits = <0x0 0 (0x7 << 3)>;
+ };
+
+ i2c2_scl_gpio: i2c2-scl-gpio-pins {
+ pinctrl-single,bits = <0x0 (0x1 << 3) (0x7 << 3)>;
+ };
+
+ i2c3_scl: i2c3-scl-pins {
+ pinctrl-single,bits = <0x0 0 (0x7 << 6)>;
+ };
+
+ i2c3_scl_gpio: i2c3-scl-gpio-pins {
+ pinctrl-single,bits = <0x0 (0x1 << 6) (0x7 << 6)>;
+ };
+
+ i2c4_scl: i2c4-scl-pins {
+ pinctrl-single,bits = <0x0 0 (0x7 << 9)>;
+ };
+
+ i2c4_scl_gpio: i2c4-scl-gpio-pins {
+ pinctrl-single,bits = <0x0 (0x1 << 9) (0x7 << 9)>;
+ };
+
+ i2c5_scl: i2c5-scl-pins {
+ pinctrl-single,bits = <0x0 0 (0x7 << 12)>;
+ };
+
+ i2c5_scl_gpio: i2c5-scl-gpio-pins {
+ pinctrl-single,bits = <0x0 (0x1 << 12) (0x7 << 12)>;
+ };
+
+ i2c6_scl: i2c6-scl-pins {
+ pinctrl-single,bits = <0x4 0x2 0x7>;
+ };
+
+ i2c6_scl_gpio: i2c6-scl-gpio-pins {
+ pinctrl-single,bits = <0x4 0x1 0x7>;
+ };
+
+ i2c7_scl: i2c7-scl-pins {
+ pinctrl-single,bits = <0x4 0x2 0x7>;
+ };
+
+ i2c7_scl_gpio: i2c7-scl-gpio-pins {
+ pinctrl-single,bits = <0x4 0x1 0x7>;
+ };
+
+ i2c0_scl: i2c0-scl-pins {
+ pinctrl-single,bits = <0x8 0 (0x7 << 10)>;
+ };
+
+ i2c0_scl_gpio: i2c0-scl-gpio-pins {
+ pinctrl-single,bits = <0x8 (0x1 << 10) (0x7 << 10)>;
+ };
+ };
+
fsl_mc: fsl-mc@80c000000 {
compatible = "fsl,qoriq-mc";
reg = <0x00000008 0x0c000000 0 0x40>,
--
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 v2 2/3] dt-bindings: power: Add mediatek larb definition
From: Yu-chang Lee (李禹璋) @ 2024-03-28 6:06 UTC (permalink / raw)
To: amergnat@baylibre.com, krzysztof.kozlowski@linaro.org
Cc: linux-mediatek@lists.infradead.org, linux-kernel@vger.kernel.org,
devicetree@vger.kernel.org, linux-pm@vger.kernel.org,
MandyJH Liu (劉人僖), conor+dt@kernel.org,
Project_Global_Chrome_Upstream_Group, robh@kernel.org,
Xiufeng Li (李秀峰),
linux-arm-kernel@lists.infradead.org,
krzysztof.kozlowski+dt@linaro.org, matthias.bgg@gmail.com,
ulf.hansson@linaro.org, Fan Chen (陳凡),
angelogioacchino.delregno@collabora.com
In-Reply-To: <CAFGrd9qZhObQXvm2_abqaX83xMLqxjQETB2=wXpobDWU1CnvkA@mail.gmail.com>
On Wed, 2024-03-27 at 12:55 +0100, Alexandre Mergnat wrote:
>
> External email : Please do not click links or open attachments until
> you have verified the sender or the content.
> Hello Yu-chang Lee,
>
> SMI LARB must have a power domain, according to "mediatek,smi-
> larb.yaml"
> Now you try to create a link from power domain to larb.
>
> Here is my understanding: when you enable/disable power domain, the
> larb linked to this power domain may have an issue. Then you want to
> retrieve de LARB linked to the power domain though the dts to manage
> the LARB.
Yes, this is what I am trying to do.
> IMHO, using the dts to have this information into the power
> driver isn't necessary and may introduce some bugs if the LARB node
> and power node in the DTS aren't aligned.
>
> It seems not implemented today but during the LARB probe, it should
> "subscribe" to the linked power domain. Then, when the power domain
> status is changing, it is able to "notify" (callback) the LARB, then
> implement the good stuff to handle this power domain status change
> into LARB driver.
>
The problem with this method and why "smi clamp" is in power domain
driver is that our HW designer gave us a programming guide strictly
states the sequence of what we need to do to power on/off power domain.
Using callback, this sequence is no longer guaranteed and the side
effect is unknown...
So I would like to stick with adding larbs just like smi into power
domain node.
> Regards,
> Alexandre
Best Regards,
Yu-chang
>
> On Wed, Mar 27, 2024 at 12:04 PM Krzysztof Kozlowski
> <krzysztof.kozlowski@linaro.org> wrote:
> >
> > On 27/03/2024 11:56, Yu-chang Lee (李禹璋) wrote:
> > > On Wed, 2024-03-27 at 11:43 +0100, Krzysztof Kozlowski wrote:
> > >>
> > >> External email : Please do not click links or open attachments
> until
> > >> you have verified the sender or the content.
> > >> On 27/03/2024 11:39, Yu-chang Lee (李禹璋) wrote:
> > >>>>>>
> > >>>>> Hi,
> > >>>>>
> > >>>>> I will double check the format of yaml for the next version,
> > >> sorry
> > >>>> for
> > >>>>> inconvenience. But I did test it on mt8188 chromebook, the
> reason
> > >>>> why
> > >>>>
> > >>>> How do you test a binding on chromebook?
> > >>>>
> > >>>>> power domain need larb node is that when mtcmos power on,
> signal
> > >>>> glitch
> > >>>>> may produce. Power domain driver must reset larb when this
> happen
> > >>>> to
> > >>>>> prevent dummy transaction on bus. That why I need larb node
> in
> > >> dts.
> > >>>>
> > >>>> No one talks here about larb node...
> > >>>
> > >>> Sorry, May you elaborate on what information I need to provide
> to
> > >> you
> > >>> or it is just a syntax problem I need to fix?
> > >>
> > >> Please explain the purpose of this property (how is it going to
> be
> > >> used by drivers)and what does it represent.
> > >>
> > >
> > > It represent SMI LARB(Local ARBitration). In power domain driver
> when
> > > power on power domain, It need to reset LARB to prevent potential
> power
> > > glitch which may cause dummy transaction on bus. Without taking
> care of
> > > this issue it often leads to camera hang in stress test.
> >
> > That sounds rather like missing resets... or something else
> connecting
> > these devices. Maybe the explanation is just imprecise...
> >
> > Best regards,
> > Krzysztof
> >
> >
_______________________________________________
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 RFC 0/3] mm/gup: consistently call it GUP-fast
From: Vineet Gupta @ 2024-03-28 5:51 UTC (permalink / raw)
To: Arnd Bergmann, David Hildenbrand, peterx
Cc: linux-kernel, Andrew Morton, Mike Rapoport, Jason Gunthorpe,
John Hubbard, linux-arm-kernel, loongarch, linux-mips,
linuxppc-dev, linux-s390, linux-sh, linux-mm, linux-perf-users,
linux-fsdevel, x86, Ryan Roberts, Alexander Viro, Matt Turner,
Vineet Gupta, Alexey Brodkin
In-Reply-To: <dc1433ea-4e59-4ab7-83fb-23b393020980@app.fastmail.com>
+CC Alexey
On 3/27/24 09:22, Arnd Bergmann wrote:
> On Wed, Mar 27, 2024, at 16:39, David Hildenbrand wrote:
>> On 27.03.24 16:21, Peter Xu wrote:
>>> On Wed, Mar 27, 2024 at 02:05:35PM +0100, David Hildenbrand wrote:
>>>
>>> I'm not sure what config you tried there; as I am doing some build tests
>>> recently, I found turning off CONFIG_SAMPLES + CONFIG_GCC_PLUGINS could
>>> avoid a lot of issues, I think it's due to libc missing. But maybe not the
>>> case there.
>> CCin Arnd; I use some of his compiler chains, others from Fedora directly. For
>> example for alpha and arc, the Fedora gcc is "13.2.1".
>> But there is other stuff like (arc):
>>
>> ./arch/arc/include/asm/mmu-arcv2.h: In function 'mmu_setup_asid':
>> ./arch/arc/include/asm/mmu-arcv2.h:82:9: error: implicit declaration of
>> function 'write_aux_reg' [-Werro
>> r=implicit-function-declaration]
>> 82 | write_aux_reg(ARC_REG_PID, asid | MMU_ENABLE);
>> | ^~~~~~~~~~~~~
> Seems to be missing an #include of soc/arc/aux.h, but I can't
> tell when this first broke without bisecting.
Weird I don't see this one but I only have gcc 12 handy ATM.
gcc version 12.2.1 20230306 (ARC HS GNU/Linux glibc toolchain -
build 1360)
I even tried W=1 (which according to scripts/Makefile.extrawarn) should
include -Werror=implicit-function-declaration but don't see this still.
Tomorrow I'll try building a gcc 13.2.1 for ARC.
>
>> or (alpha)
>>
>> WARNING: modpost: "saved_config" [vmlinux] is COMMON symbol
>> ERROR: modpost: "memcpy" [fs/reiserfs/reiserfs.ko] undefined!
>> ERROR: modpost: "memcpy" [fs/nfs/nfs.ko] undefined!
>> ERROR: modpost: "memcpy" [fs/nfs/nfsv3.ko] undefined!
>> ERROR: modpost: "memcpy" [fs/nfsd/nfsd.ko] undefined!
>> ERROR: modpost: "memcpy" [fs/lockd/lockd.ko] undefined!
>> ERROR: modpost: "memcpy" [crypto/crypto.ko] undefined!
>> ERROR: modpost: "memcpy" [crypto/crypto_algapi.ko] undefined!
>> ERROR: modpost: "memcpy" [crypto/aead.ko] undefined!
>> ERROR: modpost: "memcpy" [crypto/crypto_skcipher.ko] undefined!
>> ERROR: modpost: "memcpy" [crypto/seqiv.ko] undefined!
Are these from ARC build or otherwise ?
Thx,
-Vineet
_______________________________________________
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 v11 09/11] poweprc: mm: Implement *_user_accessible_page() for ptes
From: Rohan McLure @ 2024-03-28 5:44 UTC (permalink / raw)
To: Christophe Leroy, linuxppc-dev@lists.ozlabs.org
Cc: mpe@ellerman.id.au, linux-mm@kvack.org,
linux-riscv@lists.infradead.org,
linux-arm-kernel@lists.infradead.org, x86@kernel.org
In-Reply-To: <3fcc8331-28ed-458f-b7f6-ba1f161eb09e@csgroup.eu>
On Thu, 2024-03-28 at 05:40 +0000, Christophe Leroy wrote:
>
>
> Le 28/03/2024 à 05:55, Rohan McLure a écrit :
> > Page table checking depends on architectures providing an
> > implementation of p{te,md,ud}_user_accessible_page. With
> > refactorisations made on powerpc/mm, the pte_access_permitted() and
> > similar methods verify whether a userland page is accessible with
> > the
> > required permissions.
> >
> > Since page table checking is the only user of
> > p{te,md,ud}_user_accessible_page(), implement these for all
> > platforms,
> > using some of the same preliminary checks taken by
> > pte_access_permitted()
> > on that platform.
> >
> > Since Commit 8e9bd41e4ce1 ("powerpc/nohash: Replace pte_user() by
> > pte_read()")
> > pte_user() is no longer required to be present on all platforms as
> > it
> > may be equivalent to or implied by pte_read(). Hence
> > implementations of
> > pte_user_accessible_page() are specialised.
> >
> > Signed-off-by: Rohan McLure <rmclure@linux.ibm.com>
> > ---
> > v9: New implementation
> > v10: Let book3s/64 use pte_user(), but otherwise default other
> > platforms
> > to using the address provided with the call to infer whether it is
> > a
> > user page or not. pmd/pud variants will warn on all other
> > platforms, as
> > they should not be used for user page mappings
> > v11: Conditionally define p{m,u}d_user_accessible_page(), as not
> > all
> > platforms have p{m,u}d_leaf(), p{m,u}d_pte() stubs.
>
> See my comment to v10 patch 10.
>
> p{m,u}d_leaf() is defined for all platforms (There is a fallback
> definition in include/linux/pgtable.h) so
> p{m,u}d_user_accessible_page()
> can be defined for all platforms, no need for a conditionally define.
The issue I see is that the definition in include/linux/pgtable.h
occurs after this header is included. Prior to the removal of a local
definition of p{m,u}d_leaf() etc we didn't run into this issue, but we
still do now.
Not insistent on doing it this way with ifndef, so amenable to
suggestions if you have a preference.
>
> > ---
> > arch/powerpc/include/asm/book3s/32/pgtable.h | 5 +++++
> > arch/powerpc/include/asm/book3s/64/pgtable.h | 17
> > +++++++++++++++++
> > arch/powerpc/include/asm/nohash/pgtable.h | 5 +++++
> > arch/powerpc/include/asm/pgtable.h | 8 ++++++++
> > 4 files changed, 35 insertions(+)
> >
> > diff --git a/arch/powerpc/include/asm/book3s/32/pgtable.h
> > b/arch/powerpc/include/asm/book3s/32/pgtable.h
> > index 52971ee30717..83f7b98ef49f 100644
> > --- a/arch/powerpc/include/asm/book3s/32/pgtable.h
> > +++ b/arch/powerpc/include/asm/book3s/32/pgtable.h
> > @@ -436,6 +436,11 @@ static inline bool pte_access_permitted(pte_t
> > pte, bool write)
> > return true;
> > }
> >
> > +static inline bool pte_user_accessible_page(pte_t pte, unsigned
> > long addr)
> > +{
> > + return pte_present(pte) && !is_kernel_addr(addr);
> > +}
> > +
> > /* Conversion functions: convert a page and protection to a page
> > entry,
> > * and a page entry and page directory to the page they refer to.
> > *
> > diff --git a/arch/powerpc/include/asm/book3s/64/pgtable.h
> > b/arch/powerpc/include/asm/book3s/64/pgtable.h
> > index fac5615e6bc5..d8640ddbcad1 100644
> > --- a/arch/powerpc/include/asm/book3s/64/pgtable.h
> > +++ b/arch/powerpc/include/asm/book3s/64/pgtable.h
> > @@ -538,6 +538,11 @@ static inline bool pte_access_permitted(pte_t
> > pte, bool write)
> > return arch_pte_access_permitted(pte_val(pte), write, 0);
> > }
> >
> > +static inline bool pte_user_accessible_page(pte_t pte, unsigned
> > long addr)
> > +{
> > + return pte_present(pte) && pte_user(pte);
> > +}
> > +
> > /*
> > * Conversion functions: convert a page and protection to a page
> > entry,
> > * and a page entry and page directory to the page they refer to.
> > @@ -1441,5 +1446,17 @@ static inline bool pud_leaf(pud_t pud)
> > return !!(pud_raw(pud) & cpu_to_be64(_PAGE_PTE));
> > }
> >
> > +#define pmd_user_accessible_page pmd_user_accessible_page
> > +static inline bool pmd_user_accessible_page(pmd_t pmd, unsigned
> > long addr)
> > +{
> > + return pmd_leaf(pmd) &&
> > pte_user_accessible_page(pmd_pte(pmd), addr);
> > +}
> > +
> > +#define pud_user_accessible_page pud_user_accessible_page
> > +static inline bool pud_user_accessible_page(pud_t pud, unsigned
> > long addr)
> > +{
> > + return pud_leaf(pud) &&
> > pte_user_accessible_page(pud_pte(pud), addr);
> > +}
> > +
> > #endif /* __ASSEMBLY__ */
> > #endif /* _ASM_POWERPC_BOOK3S_64_PGTABLE_H_ */
> > diff --git a/arch/powerpc/include/asm/nohash/pgtable.h
> > b/arch/powerpc/include/asm/nohash/pgtable.h
> > index 427db14292c9..413d01a51e6f 100644
> > --- a/arch/powerpc/include/asm/nohash/pgtable.h
> > +++ b/arch/powerpc/include/asm/nohash/pgtable.h
> > @@ -213,6 +213,11 @@ static inline bool pte_access_permitted(pte_t
> > pte, bool write)
> > return true;
> > }
> >
> > +static inline bool pte_user_accessible_page(pte_t pte, unsigned
> > long addr)
> > +{
> > + return pte_present(pte) && !is_kernel_addr(addr);
> > +}
> > +
> > /* Conversion functions: convert a page and protection to a page
> > entry,
> > * and a page entry and page directory to the page they refer to.
> > *
> > diff --git a/arch/powerpc/include/asm/pgtable.h
> > b/arch/powerpc/include/asm/pgtable.h
> > index ee8c82c0528f..f1ceae778cb1 100644
> > --- a/arch/powerpc/include/asm/pgtable.h
> > +++ b/arch/powerpc/include/asm/pgtable.h
> > @@ -219,6 +219,14 @@ static inline int pud_pfn(pud_t pud)
> > }
> > #endif
> >
> > +#ifndef pmd_user_accessible_page
> > +#define pmd_user_accessible_page(pmd, addr) false
> > +#endif
> > +
> > +#ifndef pud_user_accessible_page
> > +#define pud_user_accessible_page(pud, addr) false
> > +#endif
> > +
> > #endif /* __ASSEMBLY__ */
> >
> > #endif /* _ASM_POWERPC_PGTABLE_H */
_______________________________________________
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