* [PATCH 10/13] ia64: Remove dev->archdata.iommu pointer
From: Joerg Roedel @ 2020-06-25 13:08 UTC (permalink / raw)
To: iommu
Cc: linux-ia64, Heiko Stuebner, David Airlie, Joonas Lahtinen,
Thierry Reding, Paul Mackerras, Will Deacon, Marek Szyprowski,
Joerg Roedel, x86, Russell King, Catalin Marinas, Fenghua Yu,
Joerg Roedel, intel-gfx, Jani Nikula, Rodrigo Vivi,
Matthias Brugger, linux-arm-kernel, Tony Luck, linuxppc-dev,
linux-kernel, Daniel Vetter, David Woodhouse, Lu Baolu
In-Reply-To: <20200625130836.1916-1-joro@8bytes.org>
From: Joerg Roedel <jroedel@suse.de>
There are no users left, all drivers have been converted to use the
per-device private pointer offered by IOMMU core.
Signed-off-by: Joerg Roedel <jroedel@suse.de>
---
arch/ia64/include/asm/device.h | 3 ---
1 file changed, 3 deletions(-)
diff --git a/arch/ia64/include/asm/device.h b/arch/ia64/include/asm/device.h
index 3eb397415381..918b198cd5bb 100644
--- a/arch/ia64/include/asm/device.h
+++ b/arch/ia64/include/asm/device.h
@@ -6,9 +6,6 @@
#define _ASM_IA64_DEVICE_H
struct dev_archdata {
-#ifdef CONFIG_IOMMU_API
- void *iommu; /* hook for IOMMU specific extension */
-#endif
};
struct pdev_archdata {
--
2.27.0
^ permalink raw reply related
* [PATCH 12/13] arm64: Remove dev->archdata.iommu pointer
From: Joerg Roedel @ 2020-06-25 13:08 UTC (permalink / raw)
To: iommu
Cc: linux-ia64, Heiko Stuebner, David Airlie, Joonas Lahtinen,
Thierry Reding, Paul Mackerras, Will Deacon, Marek Szyprowski,
Joerg Roedel, x86, Russell King, Catalin Marinas, Fenghua Yu,
Joerg Roedel, intel-gfx, Jani Nikula, Rodrigo Vivi,
Matthias Brugger, linux-arm-kernel, Tony Luck, linuxppc-dev,
linux-kernel, Daniel Vetter, David Woodhouse, Lu Baolu
In-Reply-To: <20200625130836.1916-1-joro@8bytes.org>
From: Joerg Roedel <jroedel@suse.de>
There are no users left, all drivers have been converted to use the
per-device private pointer offered by IOMMU core.
Signed-off-by: Joerg Roedel <jroedel@suse.de>
---
arch/arm64/include/asm/device.h | 3 ---
1 file changed, 3 deletions(-)
diff --git a/arch/arm64/include/asm/device.h b/arch/arm64/include/asm/device.h
index 12b778d55342..996498751318 100644
--- a/arch/arm64/include/asm/device.h
+++ b/arch/arm64/include/asm/device.h
@@ -6,9 +6,6 @@
#define __ASM_DEVICE_H
struct dev_archdata {
-#ifdef CONFIG_IOMMU_API
- void *iommu; /* private IOMMU data */
-#endif
};
struct pdev_archdata {
--
2.27.0
^ permalink raw reply related
* Re: [PATCH 12/13] arm64: Remove dev->archdata.iommu pointer
From: Will Deacon @ 2020-06-25 13:16 UTC (permalink / raw)
To: Joerg Roedel
Cc: linux-ia64, Heiko Stuebner, David Airlie, Joonas Lahtinen,
Thierry Reding, Paul Mackerras, Marek Szyprowski, x86,
Russell King, Catalin Marinas, Fenghua Yu, Joerg Roedel,
intel-gfx, Jani Nikula, Rodrigo Vivi, Matthias Brugger,
linux-arm-kernel, Tony Luck, linuxppc-dev, linux-kernel, iommu,
Daniel Vetter, David Woodhouse, Lu Baolu
In-Reply-To: <20200625130836.1916-13-joro@8bytes.org>
On Thu, Jun 25, 2020 at 03:08:35PM +0200, Joerg Roedel wrote:
> From: Joerg Roedel <jroedel@suse.de>
>
> There are no users left, all drivers have been converted to use the
> per-device private pointer offered by IOMMU core.
>
> Signed-off-by: Joerg Roedel <jroedel@suse.de>
> ---
> arch/arm64/include/asm/device.h | 3 ---
> 1 file changed, 3 deletions(-)
>
> diff --git a/arch/arm64/include/asm/device.h b/arch/arm64/include/asm/device.h
> index 12b778d55342..996498751318 100644
> --- a/arch/arm64/include/asm/device.h
> +++ b/arch/arm64/include/asm/device.h
> @@ -6,9 +6,6 @@
> #define __ASM_DEVICE_H
>
> struct dev_archdata {
> -#ifdef CONFIG_IOMMU_API
> - void *iommu; /* private IOMMU data */
> -#endif
> };
Acked-by: Will Deacon <will@kernel.org>
Thanks, Joerg.
Will
^ permalink raw reply
* Re: [PATCH 02/13] iommu/vt-d: Use dev_iommu_priv_get/set()
From: Lu Baolu @ 2020-06-25 13:24 UTC (permalink / raw)
To: Joerg Roedel, iommu
Cc: linux-ia64, Heiko Stuebner, David Airlie, Joonas Lahtinen,
Thierry Reding, Paul Mackerras, Will Deacon, Marek Szyprowski,
x86, Russell King, Catalin Marinas, Fenghua Yu, Joerg Roedel,
intel-gfx, Jani Nikula, Rodrigo Vivi, Matthias Brugger,
linux-arm-kernel, Tony Luck, linuxppc-dev, linux-kernel,
Daniel Vetter, David Woodhouse, baolu.lu
In-Reply-To: <20200625130836.1916-3-joro@8bytes.org>
Hi Joerg,
On 2020/6/25 21:08, Joerg Roedel wrote:
> From: Joerg Roedel <jroedel@suse.de>
>
> Remove the use of dev->archdata.iommu and use the private per-device
> pointer provided by IOMMU core code instead.
>
> Signed-off-by: Joerg Roedel <jroedel@suse.de>
> ---
> .../gpu/drm/i915/selftests/mock_gem_device.c | 10 ++++++++--
> drivers/iommu/intel/iommu.c | 18 +++++++++---------
For changes in VT-d driver,
Reviewed-by: Lu Baolu <baolu.lu@linux.intel.com>
Best regards,
baolu
> 2 files changed, 17 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/selftests/mock_gem_device.c b/drivers/gpu/drm/i915/selftests/mock_gem_device.c
> index 9b105b811f1f..e08601905a64 100644
> --- a/drivers/gpu/drm/i915/selftests/mock_gem_device.c
> +++ b/drivers/gpu/drm/i915/selftests/mock_gem_device.c
> @@ -24,6 +24,7 @@
>
> #include <linux/pm_domain.h>
> #include <linux/pm_runtime.h>
> +#include <linux/iommu.h>
>
> #include <drm/drm_managed.h>
>
> @@ -118,6 +119,9 @@ struct drm_i915_private *mock_gem_device(void)
> {
> struct drm_i915_private *i915;
> struct pci_dev *pdev;
> +#if IS_ENABLED(CONFIG_IOMMU_API) && defined(CONFIG_INTEL_IOMMU)
> + struct dev_iommu iommu;
> +#endif
> int err;
>
> pdev = kzalloc(sizeof(*pdev), GFP_KERNEL);
> @@ -136,8 +140,10 @@ struct drm_i915_private *mock_gem_device(void)
> dma_coerce_mask_and_coherent(&pdev->dev, DMA_BIT_MASK(64));
>
> #if IS_ENABLED(CONFIG_IOMMU_API) && defined(CONFIG_INTEL_IOMMU)
> - /* hack to disable iommu for the fake device; force identity mapping */
> - pdev->dev.archdata.iommu = (void *)-1;
> + /* HACK HACK HACK to disable iommu for the fake device; force identity mapping */
> + memset(&iommu, 0, sizeof(iommu));
> + iommu.priv = (void *)-1;
> + pdev->dev.iommu = &iommu;
> #endif
>
> pci_set_drvdata(pdev, i915);
> diff --git a/drivers/iommu/intel/iommu.c b/drivers/iommu/intel/iommu.c
> index d759e7234e98..2ce490c2eab8 100644
> --- a/drivers/iommu/intel/iommu.c
> +++ b/drivers/iommu/intel/iommu.c
> @@ -372,7 +372,7 @@ struct device_domain_info *get_domain_info(struct device *dev)
> if (!dev)
> return NULL;
>
> - info = dev->archdata.iommu;
> + info = dev_iommu_priv_get(dev);
> if (unlikely(info == DUMMY_DEVICE_DOMAIN_INFO ||
> info == DEFER_DEVICE_DOMAIN_INFO))
> return NULL;
> @@ -743,12 +743,12 @@ struct context_entry *iommu_context_addr(struct intel_iommu *iommu, u8 bus,
>
> static int iommu_dummy(struct device *dev)
> {
> - return dev->archdata.iommu == DUMMY_DEVICE_DOMAIN_INFO;
> + return dev_iommu_priv_get(dev) == DUMMY_DEVICE_DOMAIN_INFO;
> }
>
> static bool attach_deferred(struct device *dev)
> {
> - return dev->archdata.iommu == DEFER_DEVICE_DOMAIN_INFO;
> + return dev_iommu_priv_get(dev) == DEFER_DEVICE_DOMAIN_INFO;
> }
>
> /**
> @@ -2420,7 +2420,7 @@ static inline void unlink_domain_info(struct device_domain_info *info)
> list_del(&info->link);
> list_del(&info->global);
> if (info->dev)
> - info->dev->archdata.iommu = NULL;
> + dev_iommu_priv_set(info->dev, NULL);
> }
>
> static void domain_remove_dev_info(struct dmar_domain *domain)
> @@ -2453,7 +2453,7 @@ static void do_deferred_attach(struct device *dev)
> {
> struct iommu_domain *domain;
>
> - dev->archdata.iommu = NULL;
> + dev_iommu_priv_set(dev, NULL);
> domain = iommu_get_domain_for_dev(dev);
> if (domain)
> intel_iommu_attach_device(domain, dev);
> @@ -2599,7 +2599,7 @@ static struct dmar_domain *dmar_insert_one_dev_info(struct intel_iommu *iommu,
> list_add(&info->link, &domain->devices);
> list_add(&info->global, &device_domain_list);
> if (dev)
> - dev->archdata.iommu = info;
> + dev_iommu_priv_set(dev, info);
> spin_unlock_irqrestore(&device_domain_lock, flags);
>
> /* PASID table is mandatory for a PCI device in scalable mode. */
> @@ -4004,7 +4004,7 @@ static void quirk_ioat_snb_local_iommu(struct pci_dev *pdev)
> if (!drhd || drhd->reg_base_addr - vtbar != 0xa000) {
> pr_warn_once(FW_BUG "BIOS assigned incorrect VT-d unit for Intel(R) QuickData Technology device\n");
> add_taint(TAINT_FIRMWARE_WORKAROUND, LOCKDEP_STILL_OK);
> - pdev->dev.archdata.iommu = DUMMY_DEVICE_DOMAIN_INFO;
> + dev_iommu_priv_set(&pdev->dev, DUMMY_DEVICE_DOMAIN_INFO);
> }
> }
> DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_IOAT_SNB, quirk_ioat_snb_local_iommu);
> @@ -4043,7 +4043,7 @@ static void __init init_no_remapping_devices(void)
> drhd->ignored = 1;
> for_each_active_dev_scope(drhd->devices,
> drhd->devices_cnt, i, dev)
> - dev->archdata.iommu = DUMMY_DEVICE_DOMAIN_INFO;
> + dev_iommu_priv_set(dev, DUMMY_DEVICE_DOMAIN_INFO);
> }
> }
> }
> @@ -5665,7 +5665,7 @@ static struct iommu_device *intel_iommu_probe_device(struct device *dev)
> return ERR_PTR(-ENODEV);
>
> if (translation_pre_enabled(iommu))
> - dev->archdata.iommu = DEFER_DEVICE_DOMAIN_INFO;
> + dev_iommu_priv_set(dev, DEFER_DEVICE_DOMAIN_INFO);
>
> return &iommu->iommu;
> }
>
^ permalink raw reply
* Re: [PATCH v2 2/2] cpufreq: Specify default governor on command line
From: Rafael J. Wysocki @ 2020-06-25 13:28 UTC (permalink / raw)
To: Quentin Perret
Cc: Juri Lelli, Cc: Android Kernel, Vincent Guittot, Arnd Bergmann,
Rafael J. Wysocki, Peter Zijlstra, Viresh Kumar, adharmap,
Linux PM, Rafael J. Wysocki, Linux Kernel Mailing List,
Ingo Molnar, Paul Mackerras, linuxppc-dev, Todd Kjos
In-Reply-To: <20200625115318.GA219598@google.com>
On Thu, Jun 25, 2020 at 1:53 PM Quentin Perret <qperret@google.com> wrote:
>
> On Thursday 25 Jun 2020 at 13:44:34 (+0200), Rafael J. Wysocki wrote:
> > On Thu, Jun 25, 2020 at 1:36 PM Viresh Kumar <viresh.kumar@linaro.org> wrote:
> > > This change is not right IMO. This part handles the set-policy case,
> > > where there are no governors. Right now this code, for some reasons
> > > unknown to me, forcefully uses the default governor set to indicate
> > > the policy, which is not a great idea in my opinion TBH. This doesn't
> > > and shouldn't care about governor modules and should only be looking
> > > at strings instead of governor pointer.
> >
> > Sounds right.
> >
> > > Rafael, I even think we should remove this code completely and just
> > > rely on what the driver has sent to us. Using the selected governor
> > > for set policy drivers is very confusing and also we shouldn't be
> > > forced to compiling any governor for the set-policy case.
> >
> > Well, AFAICS the idea was to use the default governor as a kind of
> > default policy proxy, but I agree that strings should be sufficient
> > for that.
>
> I agree with all the above. I'd much rather not rely on the default
> governor name to populate the default policy, too, so +1 from me.
So before this series the default governor was selected at the kernel
configuration time (pre-build) and was always built-in. Because it
could not go away, its name could be used to indicate the default
policy for the "setpolicy" drivers.
After this series, however, it cannot be used this way reliably, but
you can still pass cpufreq_param_governor to cpufreq_parse_policy()
instead of def_gov->name in cpufreq_init_policy(), can't you?
^ permalink raw reply
* Re: [PATCH v2 2/2] cpufreq: Specify default governor on command line
From: Quentin Perret @ 2020-06-25 13:49 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Juri Lelli, Cc: Android Kernel, Vincent Guittot, Arnd Bergmann,
Linux PM, Peter Zijlstra, Viresh Kumar, adharmap,
Rafael J. Wysocki, Linux Kernel Mailing List, Ingo Molnar,
Paul Mackerras, linuxppc-dev, Todd Kjos
In-Reply-To: <CAJZ5v0jQkeu5dJXxXN2eQ+cAwv8oSK_wZZgTW3cvMZX0ks9jHQ@mail.gmail.com>
On Thursday 25 Jun 2020 at 15:28:43 (+0200), Rafael J. Wysocki wrote:
> On Thu, Jun 25, 2020 at 1:53 PM Quentin Perret <qperret@google.com> wrote:
> >
> > On Thursday 25 Jun 2020 at 13:44:34 (+0200), Rafael J. Wysocki wrote:
> > > On Thu, Jun 25, 2020 at 1:36 PM Viresh Kumar <viresh.kumar@linaro.org> wrote:
> > > > This change is not right IMO. This part handles the set-policy case,
> > > > where there are no governors. Right now this code, for some reasons
> > > > unknown to me, forcefully uses the default governor set to indicate
> > > > the policy, which is not a great idea in my opinion TBH. This doesn't
> > > > and shouldn't care about governor modules and should only be looking
> > > > at strings instead of governor pointer.
> > >
> > > Sounds right.
> > >
> > > > Rafael, I even think we should remove this code completely and just
> > > > rely on what the driver has sent to us. Using the selected governor
> > > > for set policy drivers is very confusing and also we shouldn't be
> > > > forced to compiling any governor for the set-policy case.
> > >
> > > Well, AFAICS the idea was to use the default governor as a kind of
> > > default policy proxy, but I agree that strings should be sufficient
> > > for that.
> >
> > I agree with all the above. I'd much rather not rely on the default
> > governor name to populate the default policy, too, so +1 from me.
>
> So before this series the default governor was selected at the kernel
> configuration time (pre-build) and was always built-in. Because it
> could not go away, its name could be used to indicate the default
> policy for the "setpolicy" drivers.
>
> After this series, however, it cannot be used this way reliably, but
> you can still pass cpufreq_param_governor to cpufreq_parse_policy()
> instead of def_gov->name in cpufreq_init_policy(), can't you?
Good point. I also need to fallback to the default builtin governor if
the command line parameter isn't valid (or non-existent), so perhaps
something like so?
iff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
index dad6b85f4c89..20a2020abf88 100644
--- a/drivers/cpufreq/cpufreq.c
+++ b/drivers/cpufreq/cpufreq.c
@@ -653,6 +653,23 @@ static unsigned int cpufreq_parse_policy(char *str_governor)
return CPUFREQ_POLICY_UNKNOWN;
}
+static unsigned int cpufreq_default_policy(void)
+{
+ unsigned int pol;
+
+ pol = cpufreq_parse_policy(cpufreq_param_governor);
+ if (pol != CPUFREQ_POLICY_UNKNOWN)
+ return pol;
+
+ if (IS_BUILTIN(CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE))
+ return CPUFREQ_POLICY_PERFORMANCE;
+
+ if (IS_BUILTIN(CONFIG_CPU_FREQ_DEFAULT_GOV_POWERSAVE))
+ return CPUFREQ_POLICY_POWERSAVE;
+
+ return CPUFREQ_POLICY_UNKNOWN;
+}
+
/**
* cpufreq_parse_governor - parse a governor string only for has_target()
* @str_governor: Governor name.
@@ -1085,8 +1102,8 @@ static int cpufreq_init_policy(struct cpufreq_policy *policy)
/* Use the default policy if there is no last_policy. */
if (policy->last_policy) {
pol = policy->last_policy;
- } else if (default_governor) {
- pol = cpufreq_parse_policy(default_governor->name);
+ } else {
+ pol = cpufreq_default_policy();
/*
* In case the default governor is neiter "performance"
* nor "powersave", fall back to the initial policy
^ permalink raw reply related
* Re: [PATCH] hvc: unify console setup naming
From: Petr Mladek @ 2020-06-25 13:42 UTC (permalink / raw)
To: Sergey Senozhatsky
Cc: Greg Kroah-Hartman, linux-kernel, Steven Rostedt, Jiri Slaby,
Andy Shevchenko, linuxppc-dev
In-Reply-To: <20200619172240.754910-1-sergey.senozhatsky@gmail.com>
On Sat 2020-06-20 02:22:40, Sergey Senozhatsky wrote:
> Use the 'common' foo_console_setup() naming scheme. There are 71
> foo_console_setup() callbacks and only one foo_setup_console().
>
> Signed-off-by: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
This patch is commited in printk/linux.git, branch
for-5.9-console-return-codes.
Best Regards,
Petr
^ permalink raw reply
* Re: [PATCH v2 2/2] cpufreq: Specify default governor on command line
From: Rafael J. Wysocki @ 2020-06-25 14:08 UTC (permalink / raw)
To: Quentin Perret
Cc: Juri Lelli, Cc: Android Kernel, Vincent Guittot, Arnd Bergmann,
Rafael J. Wysocki, Peter Zijlstra, Viresh Kumar, adharmap,
Linux PM, Rafael J. Wysocki, Linux Kernel Mailing List,
Ingo Molnar, Paul Mackerras, linuxppc-dev, Todd Kjos
In-Reply-To: <20200625134953.GA242742@google.com>
On Thu, Jun 25, 2020 at 3:50 PM Quentin Perret <qperret@google.com> wrote:
>
> On Thursday 25 Jun 2020 at 15:28:43 (+0200), Rafael J. Wysocki wrote:
> > On Thu, Jun 25, 2020 at 1:53 PM Quentin Perret <qperret@google.com> wrote:
> > >
> > > On Thursday 25 Jun 2020 at 13:44:34 (+0200), Rafael J. Wysocki wrote:
> > > > On Thu, Jun 25, 2020 at 1:36 PM Viresh Kumar <viresh.kumar@linaro.org> wrote:
> > > > > This change is not right IMO. This part handles the set-policy case,
> > > > > where there are no governors. Right now this code, for some reasons
> > > > > unknown to me, forcefully uses the default governor set to indicate
> > > > > the policy, which is not a great idea in my opinion TBH. This doesn't
> > > > > and shouldn't care about governor modules and should only be looking
> > > > > at strings instead of governor pointer.
> > > >
> > > > Sounds right.
> > > >
> > > > > Rafael, I even think we should remove this code completely and just
> > > > > rely on what the driver has sent to us. Using the selected governor
> > > > > for set policy drivers is very confusing and also we shouldn't be
> > > > > forced to compiling any governor for the set-policy case.
> > > >
> > > > Well, AFAICS the idea was to use the default governor as a kind of
> > > > default policy proxy, but I agree that strings should be sufficient
> > > > for that.
> > >
> > > I agree with all the above. I'd much rather not rely on the default
> > > governor name to populate the default policy, too, so +1 from me.
> >
> > So before this series the default governor was selected at the kernel
> > configuration time (pre-build) and was always built-in. Because it
> > could not go away, its name could be used to indicate the default
> > policy for the "setpolicy" drivers.
> >
> > After this series, however, it cannot be used this way reliably, but
> > you can still pass cpufreq_param_governor to cpufreq_parse_policy()
> > instead of def_gov->name in cpufreq_init_policy(), can't you?
>
> Good point. I also need to fallback to the default builtin governor if
> the command line parameter isn't valid (or non-existent), so perhaps
> something like so?
Yes, that should work if I haven't missed anything.
> iff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
> index dad6b85f4c89..20a2020abf88 100644
> --- a/drivers/cpufreq/cpufreq.c
> +++ b/drivers/cpufreq/cpufreq.c
> @@ -653,6 +653,23 @@ static unsigned int cpufreq_parse_policy(char *str_governor)
> return CPUFREQ_POLICY_UNKNOWN;
> }
>
> +static unsigned int cpufreq_default_policy(void)
> +{
> + unsigned int pol;
> +
> + pol = cpufreq_parse_policy(cpufreq_param_governor);
> + if (pol != CPUFREQ_POLICY_UNKNOWN)
> + return pol;
> +
> + if (IS_BUILTIN(CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE))
> + return CPUFREQ_POLICY_PERFORMANCE;
> +
> + if (IS_BUILTIN(CONFIG_CPU_FREQ_DEFAULT_GOV_POWERSAVE))
> + return CPUFREQ_POLICY_POWERSAVE;
> +
> + return CPUFREQ_POLICY_UNKNOWN;
> +}
> +
> /**
> * cpufreq_parse_governor - parse a governor string only for has_target()
> * @str_governor: Governor name.
> @@ -1085,8 +1102,8 @@ static int cpufreq_init_policy(struct cpufreq_policy *policy)
> /* Use the default policy if there is no last_policy. */
> if (policy->last_policy) {
> pol = policy->last_policy;
> - } else if (default_governor) {
> - pol = cpufreq_parse_policy(default_governor->name);
> + } else {
> + pol = cpufreq_default_policy();
> /*
> * In case the default governor is neiter "performance"
> * nor "powersave", fall back to the initial policy
^ permalink raw reply
* Re: [PATCH] powerpc/boot: Use address-of operator on section symbols
From: Nick Desaulniers @ 2020-06-25 16:32 UTC (permalink / raw)
To: Geoff Levand
Cc: LKML, clang-built-linux, Paul Mackerras, Joel Stanley,
Nathan Chancellor, linuxppc-dev
In-Reply-To: <1bbb6956-d9de-e0c8-5b45-20b6fecc2189@infradead.org>
On Wed, Jun 24, 2020 at 6:19 PM Geoff Levand <geoff@infradead.org> wrote:
>
> Hi Nathan,
>
> On 6/23/20 8:59 PM, Nathan Chancellor wrote:
> > These are not true arrays, they are linker defined symbols, which are
> > just addresses. Using the address of operator silences the warning
> > and does not change the resulting assembly with either clang/ld.lld
> > or gcc/ld (tested with diff + objdump -Dr).
>
> Thanks for your patch. I tested this patch applied to v5.8-rc2 on a
> PS3 and it seems OK.
PS3? Folks still have ones that can boot Linux? Those ****ers took
my Yellow Dog Linux away from me; I enjoyed depositing that settlement
check! Hopefully by now, folks have figured out how to roll back the
system firmware?
>
> Tested-by: Geoff Levand <geoff@infradead.org>
>
>
> --
--
Thanks,
~Nick Desaulniers
^ permalink raw reply
* [PATCH] selftests/powerpc: Fix build issue with output directory
From: Harish @ 2020-06-25 16:57 UTC (permalink / raw)
To: mpe; +Cc: Harish, linuxppc-dev
We use OUTPUT directory as TMPOUT for checking no-pie option. When
building powerpc/ from selftests directory, the OUTPUT directory
eventually points to powerpc/pmu/ebb/ and gets removed when
checking for -no-pie option in try-run routine, subsequently build
fails with the following
$ make -C powerpc
...
...
TARGET=ebb; BUILD_TARGET=$OUTPUT/$TARGET; mkdir -p $BUILD_TARGET; make OUTPUT=$BUILD_TARGET -k -C $TARGET all
make[2]: Entering directory '/home/linux-master/tools/testing/selftests/powerpc/pmu/ebb'
make[2]: *** No rule to make target 'Makefile'.
make[2]: Failed to remake makefile 'Makefile'.
make[2]: *** No rule to make target 'ebb.c', needed by '/home/linux-master/tools/testing/selftests/powerpc/pmu/ebb/reg_access_test'.
make[2]: *** No rule to make target 'ebb_handler.S', needed by '/home/linux-master/tools/testing/selftests/powerpc/pmu/ebb/reg_access_test'.
make[2]: *** No rule to make target 'trace.c', needed by '/home/linux-master/tools/testing/selftests/powerpc/pmu/ebb/reg_access_test'.
make[2]: *** No rule to make target 'busy_loop.S', needed by '/home/linux-master/tools/testing/selftests/powerpc/pmu/ebb/reg_access_test'.
make[2]: Target 'all' not remade because of errors.
Fix this by adding a suffix to the OUTPUT directory so that the
failure is avoided
Fixes: 9686813f6e9d ("selftests/powerpc: Fix try-run when source tree is not writable")
Signed-off-by: Harish <harish@linux.ibm.com>
---
tools/testing/selftests/powerpc/pmu/ebb/Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/testing/selftests/powerpc/pmu/ebb/Makefile b/tools/testing/selftests/powerpc/pmu/ebb/Makefile
index ca35dd8848b0..af3df79d8163 100644
--- a/tools/testing/selftests/powerpc/pmu/ebb/Makefile
+++ b/tools/testing/selftests/powerpc/pmu/ebb/Makefile
@@ -7,7 +7,7 @@ noarg:
# The EBB handler is 64-bit code and everything links against it
CFLAGS += -m64
-TMPOUT = $(OUTPUT)/
+TMPOUT = $(OUTPUT)/TMPDIR/
# Toolchains may build PIE by default which breaks the assembly
no-pie-option := $(call try-run, echo 'int main() { return 0; }' | \
$(CC) -Werror $(KBUILD_CPPFLAGS) $(CC_OPTION_CFLAGS) -no-pie -x c - -o "$$TMP", -no-pie)
--
2.24.1
^ permalink raw reply related
* Re: [PATCH] powerpc: Warn about use of smt_snooze_delay
From: Tyrel Datwyler @ 2020-06-25 20:38 UTC (permalink / raw)
To: Christophe Leroy, Joel Stanley, linuxppc-dev; +Cc: ego
In-Reply-To: <189c0339-da57-9df7-4774-4fe97db7ce52@csgroup.eu>
On 6/25/20 3:29 AM, Christophe Leroy wrote:
>
>
> Le 25/06/2020 à 12:03, Joel Stanley a écrit :
>> It's not done anything for a long time. Save the percpu variable, and
>> emit a warning to remind users to not expect it to do anything.
>
> Why not just drop the file entirely if it is useless ?
Userspace tooling that hasn't learned its useless yet. Joel has also submitted a
pull request for the ppc64_util tool in question to drop using this interface.
-Tyrel
>
> Christophe
>
>>
>> Signed-off-by: Joel Stanley <joel@jms.id.au>
>> ---
>> arch/powerpc/kernel/sysfs.c | 41 +++++++++++++------------------------
>> 1 file changed, 14 insertions(+), 27 deletions(-)
>>
>> diff --git a/arch/powerpc/kernel/sysfs.c b/arch/powerpc/kernel/sysfs.c
>> index 571b3259697e..530ae92bc46d 100644
>> --- a/arch/powerpc/kernel/sysfs.c
>> +++ b/arch/powerpc/kernel/sysfs.c
>> @@ -32,29 +32,25 @@
>> static DEFINE_PER_CPU(struct cpu, cpu_devices);
>> -/*
>> - * SMT snooze delay stuff, 64-bit only for now
>> - */
>> -
>> #ifdef CONFIG_PPC64
>> -/* Time in microseconds we delay before sleeping in the idle loop */
>> -static DEFINE_PER_CPU(long, smt_snooze_delay) = { 100 };
>> +/*
>> + * Snooze delay has not been hooked up since 3fa8cad82b94
>> ("powerpc/pseries/cpuidle:
>> + * smt-snooze-delay cleanup.") and has been broken even longer. As was
>> foretold in
>> + * 2014:
>> + *
>> + * "ppc64_util currently utilises it. Once we fix ppc64_util, propose to clean
>> + * up the kernel code."
>> + *
>> + * At some point in the future this code should be removed.
>> + */
>> static ssize_t store_smt_snooze_delay(struct device *dev,
>> struct device_attribute *attr,
>> const char *buf,
>> size_t count)
>> {
>> - struct cpu *cpu = container_of(dev, struct cpu, dev);
>> - ssize_t ret;
>> - long snooze;
>> -
>> - ret = sscanf(buf, "%ld", &snooze);
>> - if (ret != 1)
>> - return -EINVAL;
>> -
>> - per_cpu(smt_snooze_delay, cpu->dev.id) = snooze;
>> + WARN_ON_ONCE("smt_snooze_delay sysfs file has no effect\n");
>> return count;
>> }
>> @@ -62,9 +58,9 @@ static ssize_t show_smt_snooze_delay(struct device *dev,
>> struct device_attribute *attr,
>> char *buf)
>> {
>> - struct cpu *cpu = container_of(dev, struct cpu, dev);
>> + WARN_ON_ONCE("smt_snooze_delay sysfs file has no effect\n");
>> - return sprintf(buf, "%ld\n", per_cpu(smt_snooze_delay, cpu->dev.id));
>> + return sprintf(buf, "100\n");
>> }
>> static DEVICE_ATTR(smt_snooze_delay, 0644, show_smt_snooze_delay,
>> @@ -72,16 +68,7 @@ static DEVICE_ATTR(smt_snooze_delay, 0644,
>> show_smt_snooze_delay,
>> static int __init setup_smt_snooze_delay(char *str)
>> {
>> - unsigned int cpu;
>> - long snooze;
>> -
>> - if (!cpu_has_feature(CPU_FTR_SMT))
>> - return 1;
>> -
>> - snooze = simple_strtol(str, NULL, 10);
>> - for_each_possible_cpu(cpu)
>> - per_cpu(smt_snooze_delay, cpu) = snooze;
>> -
>> + WARN_ON_ONCE("smt-snooze-delay command line option has no effect\n");
>> return 1;
>> }
>> __setup("smt-snooze-delay=", setup_smt_snooze_delay);
>>
^ permalink raw reply
* Re: [PATCH v2] SUNRPC: Add missing definition of ARCH_IMPLEMENTS_FLUSH_DCACHE_PAGE
From: Bruce Fields @ 2020-06-25 20:40 UTC (permalink / raw)
To: Chuck Lever
Cc: Linux NFS Mailing List, netdev, Linux Kernel Mailing List,
Trond Myklebust, Anna Schumaker, Jakub Kicinski, linuxppc-dev,
David S. Miller
In-Reply-To: <733E4CAF-A9E5-491F-B0C7-69CA84E5DFA5@oracle.com>
On Mon, Jun 15, 2020 at 08:33:40AM -0400, Chuck Lever wrote:
>
>
> > On Jun 15, 2020, at 2:25 AM, Christophe Leroy <christophe.leroy@csgroup.eu> wrote:
> >
> > Even if that's only a warning, not including asm/cacheflush.h
> > leads to svc_flush_bvec() being empty allthough powerpc defines
> > ARCH_IMPLEMENTS_FLUSH_DCACHE_PAGE.
> >
> > CC net/sunrpc/svcsock.o
> > net/sunrpc/svcsock.c:227:5: warning: "ARCH_IMPLEMENTS_FLUSH_DCACHE_PAGE" is not defined [-Wundef]
> > #if ARCH_IMPLEMENTS_FLUSH_DCACHE_PAGE
> > ^
> >
> > Include linux/highmem.h so that asm/cacheflush.h will be included.
> >
> > Reported-by: Christophe Leroy <christophe.leroy@csgroup.eu>
> > Reported-by: kernel test robot <lkp@intel.com>
> > Cc: Chuck Lever <chuck.lever@oracle.com>
> > Fixes: ca07eda33e01 ("SUNRPC: Refactor svc_recvfrom()")
> > Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
>
> LGTM.
>
> Acked-by: Chuck Lever <chuck.lever@oracle.com>
Thanks, applying for 5.8.--b.
^ permalink raw reply
* Re: [PATCH 17/17] arch: rename copy_thread_tls() back to copy_thread()
From: Stafford Horne @ 2020-06-25 21:17 UTC (permalink / raw)
To: Christian Brauner
Cc: Rich Felker, linux-sh, Peter Zijlstra (Intel), Catalin Marinas,
linux-mips, James E.J. Bottomley, Max Filippov, Guo Ren,
Matthew Wilcox (Oracle), H. Peter Anvin, sparclinux,
linux-hexagon, linux-riscv, Vincent Chen, Will Deacon,
Anton Ivanov, Jonas Bonn, linux-s390, linux-ia64, linux-c6x-dev,
Brian Cain, linux-xtensa, Helge Deller, x86, Russell King,
Ley Foon Tan, Christian Borntraeger, Ingo Molnar,
Geert Uytterhoeven, linux-parisc, Mark Salter, linux-csky,
Matt Turner, linux-snps-arc, uclinux-h8-devel, Fenghua Yu,
Albert Ou, Kees Cook, Jeff Dike, linux-alpha, linux-um,
linuxppc-dev, Aurelien Jacquiot, linux-m68k, Thomas Bogendoerfer,
Ivan Kokshaysky, Greentime Hu, Paul Walmsley, Thomas Gleixner,
Stefan Kristiansson, Guan Xuetao, linux-arm-kernel,
Richard Henderson, Chris Zankel, Michal Simek, Tony Luck,
Yoshinori Sato, Nick Hu, Vineet Gupta, linux-kernel, openrisc,
Palmer Dabbelt, Richard Weinberger, Paul Mackerras,
Linus Torvalds, David S. Miller, Al Viro
In-Reply-To: <20200622234326.906346-18-christian.brauner@ubuntu.com>
On Tue, Jun 23, 2020 at 01:43:26AM +0200, Christian Brauner wrote:
> diff --git a/arch/openrisc/kernel/process.c b/arch/openrisc/kernel/process.c
> index d7010e72450c..19045a3efb8a 100644
> --- a/arch/openrisc/kernel/process.c
> +++ b/arch/openrisc/kernel/process.c
> @@ -116,7 +116,7 @@ void release_thread(struct task_struct *dead_task)
> extern asmlinkage void ret_from_fork(void);
>
> /*
> - * copy_thread_tls
> + * copy_thread
> * @clone_flags: flags
> * @usp: user stack pointer or fn for kernel thread
> * @arg: arg to fn for kernel thread; always NULL for userspace thread
> @@ -147,7 +147,7 @@ extern asmlinkage void ret_from_fork(void);
> */
>
> int
> -copy_thread_tls(unsigned long clone_flags, unsigned long usp,
> +copy_thread(unsigned long clone_flags, unsigned long usp,
> unsigned long arg, struct task_struct *p, unsigned long tls)
> {
For the OpenRISC bit.
Acked-by: Stafford Horne <shorne@gmail.com>
Also, I would agree with what Kees mentioned about aligning the parameters.
Sure that would be more work but it would be appreciated.
-Stafford
^ permalink raw reply
* Re: [PATCH 00/13] iommu: Remove usage of dev->archdata.iommu
From: Jerry Snitselaar @ 2020-06-26 1:41 UTC (permalink / raw)
To: Joerg Roedel
Cc: linux-ia64, Heiko Stuebner, David Airlie, Joonas Lahtinen,
Thierry Reding, Paul Mackerras, Will Deacon, Marek Szyprowski,
x86, Russell King, Catalin Marinas, Fenghua Yu, Joerg Roedel,
intel-gfx, Jani Nikula, Rodrigo Vivi, Matthias Brugger,
linux-arm-kernel, Tony Luck, linuxppc-dev, linux-kernel, iommu,
Daniel Vetter, David Woodhouse, Lu Baolu
In-Reply-To: <20200625130836.1916-1-joro@8bytes.org>
On Thu Jun 25 20, Joerg Roedel wrote:
>From: Joerg Roedel <jroedel@suse.de>
>
>Hi,
>
>here is a patch-set to remove the usage of dev->archdata.iommu from
>the IOMMU code in the kernel and replace its uses by the iommu per-device
>private data field. The changes also remove the field entirely from
>the architectures which no longer need it.
>
>On PowerPC the field is called dev->archdata.iommu_domain and was only
>used by the PAMU IOMMU driver. It gets removed as well.
>
>The patches have been runtime tested on Intel VT-d and compile tested
>with allyesconfig for:
>
> * x86 (32 and 64 bit)
> * arm and arm64
> * ia64 (only drivers/ because build failed for me in
> arch/ia64)
> * PPC64
>
>Besides that the changes also survived my IOMMU tree compile tests.
>
>Please review.
>
>Regards,
>
> Joerg
>
>Joerg Roedel (13):
> iommu/exynos: Use dev_iommu_priv_get/set()
> iommu/vt-d: Use dev_iommu_priv_get/set()
> iommu/msm: Use dev_iommu_priv_get/set()
> iommu/omap: Use dev_iommu_priv_get/set()
> iommu/rockchip: Use dev_iommu_priv_get/set()
> iommu/tegra: Use dev_iommu_priv_get/set()
> iommu/pamu: Use dev_iommu_priv_get/set()
> iommu/mediatek: Do no use dev->archdata.iommu
> x86: Remove dev->archdata.iommu pointer
> ia64: Remove dev->archdata.iommu pointer
> arm: Remove dev->archdata.iommu pointer
> arm64: Remove dev->archdata.iommu pointer
> powerpc/dma: Remove dev->archdata.iommu_domain
>
> arch/arm/include/asm/device.h | 3 ---
> arch/arm64/include/asm/device.h | 3 ---
> arch/ia64/include/asm/device.h | 3 ---
> arch/powerpc/include/asm/device.h | 3 ---
> arch/x86/include/asm/device.h | 3 ---
> .../gpu/drm/i915/selftests/mock_gem_device.c | 10 ++++++++--
> drivers/iommu/exynos-iommu.c | 20 +++++++++----------
> drivers/iommu/fsl_pamu_domain.c | 8 ++++----
> drivers/iommu/intel/iommu.c | 18 ++++++++---------
> drivers/iommu/msm_iommu.c | 4 ++--
> drivers/iommu/mtk_iommu.h | 2 ++
> drivers/iommu/mtk_iommu_v1.c | 10 ++++------
> drivers/iommu/omap-iommu.c | 20 +++++++++----------
> drivers/iommu/rockchip-iommu.c | 8 ++++----
> drivers/iommu/tegra-gart.c | 8 ++++----
> drivers/iommu/tegra-smmu.c | 8 ++++----
> .../media/platform/s5p-mfc/s5p_mfc_iommu.h | 4 +++-
> 17 files changed, 64 insertions(+), 71 deletions(-)
>
>--
>2.27.0
>
Reviewed-by: Jerry Snitselaar <jsnitsel@redhat.com>
^ permalink raw reply
* Re: [PATCH v2 2/2] cpufreq: Specify default governor on command line
From: Viresh Kumar @ 2020-06-26 2:53 UTC (permalink / raw)
To: Quentin Perret
Cc: juri.lelli, kernel-team, vincent.guittot, arnd, rafael, peterz,
adharmap, linux-pm, rjw, linux-kernel, mingo, paulus,
linuxppc-dev, tkjos
In-Reply-To: <20200623142138.209513-3-qperret@google.com>
On 23-06-20, 15:21, Quentin Perret wrote:
> @@ -2789,7 +2796,13 @@ static int __init cpufreq_core_init(void)
> cpufreq_global_kobject = kobject_create_and_add("cpufreq", &cpu_subsys.dev_root->kobj);
> BUG_ON(!cpufreq_global_kobject);
>
> + mutex_lock(&cpufreq_governor_mutex);
> + if (!default_governor)
Also is this check really required ? The pointer will always be NULL
at this point, isn't it ?
> + default_governor = cpufreq_default_governor();
> + mutex_unlock(&cpufreq_governor_mutex);
> +
> return 0;
> }
> module_param(off, int, 0444);
> +module_param_string(default_governor, cpufreq_param_governor, CPUFREQ_NAME_LEN, 0444);
> core_initcall(cpufreq_core_init);
> --
> 2.27.0.111.gc72c7da667-goog
--
viresh
^ permalink raw reply
* Re: [PATCH] selftests/powerpc: Fix build issue with output directory
From: Michael Ellerman @ 2020-06-26 2:54 UTC (permalink / raw)
To: Harish; +Cc: Harish, linuxppc-dev
In-Reply-To: <20200625165721.264904-1-harish@linux.ibm.com>
Harish <harish@linux.ibm.com> writes:
> We use OUTPUT directory as TMPOUT for checking no-pie option. When
> building powerpc/ from selftests directory, the OUTPUT directory
> eventually points to powerpc/pmu/ebb/ and gets removed when
> checking for -no-pie option in try-run routine, subsequently build
> fails with the following
It worked fine until:
f2f02ebd8f38 ("kbuild: improve cc-option to clean up all temporary files") when building powerpc/ from selftests directory, the
I updated the change log to mention that.
cheers
> $ make -C powerpc
> ...
> ...
> TARGET=ebb; BUILD_TARGET=$OUTPUT/$TARGET; mkdir -p $BUILD_TARGET; make OUTPUT=$BUILD_TARGET -k -C $TARGET all
> make[2]: Entering directory '/home/linux-master/tools/testing/selftests/powerpc/pmu/ebb'
> make[2]: *** No rule to make target 'Makefile'.
> make[2]: Failed to remake makefile 'Makefile'.
> make[2]: *** No rule to make target 'ebb.c', needed by '/home/linux-master/tools/testing/selftests/powerpc/pmu/ebb/reg_access_test'.
> make[2]: *** No rule to make target 'ebb_handler.S', needed by '/home/linux-master/tools/testing/selftests/powerpc/pmu/ebb/reg_access_test'.
> make[2]: *** No rule to make target 'trace.c', needed by '/home/linux-master/tools/testing/selftests/powerpc/pmu/ebb/reg_access_test'.
> make[2]: *** No rule to make target 'busy_loop.S', needed by '/home/linux-master/tools/testing/selftests/powerpc/pmu/ebb/reg_access_test'.
> make[2]: Target 'all' not remade because of errors.
>
> Fix this by adding a suffix to the OUTPUT directory so that the
> failure is avoided
>
> Fixes: 9686813f6e9d ("selftests/powerpc: Fix try-run when source tree is not writable")
> Signed-off-by: Harish <harish@linux.ibm.com>
^ permalink raw reply
* [PATCH v3 0/3] cpufreq: Allow default governor on cmdline and fix locking issues
From: Viresh Kumar @ 2020-06-26 3:51 UTC (permalink / raw)
To: Rafael Wysocki, Arnd Bergmann, Ben Segall, Dietmar Eggemann,
Ingo Molnar, Jonathan Corbet, Juri Lelli, Mel Gorman,
Peter Zijlstra, Steven Rostedt, Vincent Guittot, Viresh Kumar
Cc: linux-doc, linuxppc-dev, adharmap, linux-pm, linux-kernel,
Quentin Perret, kernel-team, tkjos
Hi,
I have picked Quentin's series over my patch, modified both and tested.
V2->V3:
- default_governor is a string now and we don't set it on governor
registration or unregistration anymore.
- Fixed locking issues in cpufreq_init_policy().
--
Viresh
Original cover letter fro Quentin:
This series enables users of prebuilt kernels (e.g. distro kernels) to
specify their CPUfreq governor of choice using the kernel command line,
instead of having to wait for the system to fully boot to userspace to
switch using the sysfs interface. This is helpful for 2 reasons:
1. users get to choose the governor that runs during the actual boot;
2. it simplifies the userspace boot procedure a bit (one less thing to
worry about).
To enable this, the first patch moves all governor init calls to
core_initcall, to make sure they are registered by the time the drivers
probe. This should be relatively low impact as registering a governor
is a simple procedure (it gets added to a llist), and all governors
already load at core_initcall anyway when they're set as the default
in Kconfig. This also allows to clean-up the governors' init/exit code,
and reduces boilerplate.
The second patch introduces the new command line parameter, inspired by
its cpuidle counterpart. More details can be found in the respective
patch headers.
Changes in v2:
- added Viresh's ack to patch 01
- moved the assignment of 'default_governor' in patch 02 to the governor
registration path instead of the driver registration (Viresh)
Quentin Perret (2):
cpufreq: Register governors at core_initcall
cpufreq: Specify default governor on command line
Viresh Kumar (1):
cpufreq: Fix locking issues with governors
.../admin-guide/kernel-parameters.txt | 5 +
Documentation/admin-guide/pm/cpufreq.rst | 6 +-
.../platforms/cell/cpufreq_spudemand.c | 26 +-----
drivers/cpufreq/cpufreq.c | 93 ++++++++++++-------
drivers/cpufreq/cpufreq_conservative.c | 22 +----
drivers/cpufreq/cpufreq_ondemand.c | 24 ++---
drivers/cpufreq/cpufreq_performance.c | 14 +--
drivers/cpufreq/cpufreq_powersave.c | 18 +---
drivers/cpufreq/cpufreq_userspace.c | 18 +---
include/linux/cpufreq.h | 14 +++
kernel/sched/cpufreq_schedutil.c | 6 +-
11 files changed, 106 insertions(+), 140 deletions(-)
--
2.25.0.rc1.19.g042ed3e048af
^ permalink raw reply
* [PATCH V3 2/3] cpufreq: Register governors at core_initcall
From: Viresh Kumar @ 2020-06-26 3:51 UTC (permalink / raw)
To: Rafael Wysocki, Arnd Bergmann, Viresh Kumar, Ingo Molnar,
Peter Zijlstra, Juri Lelli, Vincent Guittot, Dietmar Eggemann,
Steven Rostedt, Ben Segall, Mel Gorman
Cc: Quentin Perret, kernel-team, adharmap, linux-pm, linux-kernel,
linuxppc-dev, tkjos
In-Reply-To: <cover.1593143118.git.viresh.kumar@linaro.org>
From: Quentin Perret <qperret@google.com>
Currently, most CPUFreq governors are registered at core_initcall time
when used as default, and module_init otherwise. In preparation for
letting users specify the default governor on the kernel command line,
change all of them to use core_initcall unconditionally, as is already
the case for schedutil and performance. This will enable us to assume
builtin governors have been registered before the builtin CPUFreq
drivers probe.
And since all governors now have similar init/exit patterns, introduce
two new macros cpufreq_governor_{init,exit}() to factorize the code.
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Quentin Perret <qperret@google.com>
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
---
.../platforms/cell/cpufreq_spudemand.c | 26 ++-----------------
drivers/cpufreq/cpufreq_conservative.c | 22 ++++------------
drivers/cpufreq/cpufreq_ondemand.c | 24 +++++------------
drivers/cpufreq/cpufreq_performance.c | 14 ++--------
drivers/cpufreq/cpufreq_powersave.c | 18 +++----------
drivers/cpufreq/cpufreq_userspace.c | 18 +++----------
include/linux/cpufreq.h | 14 ++++++++++
kernel/sched/cpufreq_schedutil.c | 6 +----
8 files changed, 36 insertions(+), 106 deletions(-)
diff --git a/arch/powerpc/platforms/cell/cpufreq_spudemand.c b/arch/powerpc/platforms/cell/cpufreq_spudemand.c
index 55b31eadb3c8..ca7849e113d7 100644
--- a/arch/powerpc/platforms/cell/cpufreq_spudemand.c
+++ b/arch/powerpc/platforms/cell/cpufreq_spudemand.c
@@ -126,30 +126,8 @@ static struct cpufreq_governor spu_governor = {
.stop = spu_gov_stop,
.owner = THIS_MODULE,
};
-
-/*
- * module init and destoy
- */
-
-static int __init spu_gov_init(void)
-{
- int ret;
-
- ret = cpufreq_register_governor(&spu_governor);
- if (ret)
- printk(KERN_ERR "registration of governor failed\n");
- return ret;
-}
-
-static void __exit spu_gov_exit(void)
-{
- cpufreq_unregister_governor(&spu_governor);
-}
-
-
-module_init(spu_gov_init);
-module_exit(spu_gov_exit);
+cpufreq_governor_init(spu_governor);
+cpufreq_governor_exit(spu_governor);
MODULE_LICENSE("GPL");
MODULE_AUTHOR("Christian Krafft <krafft@de.ibm.com>");
-
diff --git a/drivers/cpufreq/cpufreq_conservative.c b/drivers/cpufreq/cpufreq_conservative.c
index 737ff3b9c2c0..aa39ff31ec9f 100644
--- a/drivers/cpufreq/cpufreq_conservative.c
+++ b/drivers/cpufreq/cpufreq_conservative.c
@@ -322,17 +322,7 @@ static struct dbs_governor cs_governor = {
.start = cs_start,
};
-#define CPU_FREQ_GOV_CONSERVATIVE (&cs_governor.gov)
-
-static int __init cpufreq_gov_dbs_init(void)
-{
- return cpufreq_register_governor(CPU_FREQ_GOV_CONSERVATIVE);
-}
-
-static void __exit cpufreq_gov_dbs_exit(void)
-{
- cpufreq_unregister_governor(CPU_FREQ_GOV_CONSERVATIVE);
-}
+#define CPU_FREQ_GOV_CONSERVATIVE (cs_governor.gov)
MODULE_AUTHOR("Alexander Clouter <alex@digriz.org.uk>");
MODULE_DESCRIPTION("'cpufreq_conservative' - A dynamic cpufreq governor for "
@@ -343,11 +333,9 @@ MODULE_LICENSE("GPL");
#ifdef CONFIG_CPU_FREQ_DEFAULT_GOV_CONSERVATIVE
struct cpufreq_governor *cpufreq_default_governor(void)
{
- return CPU_FREQ_GOV_CONSERVATIVE;
+ return &CPU_FREQ_GOV_CONSERVATIVE;
}
-
-core_initcall(cpufreq_gov_dbs_init);
-#else
-module_init(cpufreq_gov_dbs_init);
#endif
-module_exit(cpufreq_gov_dbs_exit);
+
+cpufreq_governor_init(CPU_FREQ_GOV_CONSERVATIVE);
+cpufreq_governor_exit(CPU_FREQ_GOV_CONSERVATIVE);
diff --git a/drivers/cpufreq/cpufreq_ondemand.c b/drivers/cpufreq/cpufreq_ondemand.c
index 82a4d37ddecb..ac361a8b1d3b 100644
--- a/drivers/cpufreq/cpufreq_ondemand.c
+++ b/drivers/cpufreq/cpufreq_ondemand.c
@@ -408,7 +408,7 @@ static struct dbs_governor od_dbs_gov = {
.start = od_start,
};
-#define CPU_FREQ_GOV_ONDEMAND (&od_dbs_gov.gov)
+#define CPU_FREQ_GOV_ONDEMAND (od_dbs_gov.gov)
static void od_set_powersave_bias(unsigned int powersave_bias)
{
@@ -429,7 +429,7 @@ static void od_set_powersave_bias(unsigned int powersave_bias)
continue;
policy = cpufreq_cpu_get_raw(cpu);
- if (!policy || policy->governor != CPU_FREQ_GOV_ONDEMAND)
+ if (!policy || policy->governor != &CPU_FREQ_GOV_ONDEMAND)
continue;
policy_dbs = policy->governor_data;
@@ -461,16 +461,6 @@ void od_unregister_powersave_bias_handler(void)
}
EXPORT_SYMBOL_GPL(od_unregister_powersave_bias_handler);
-static int __init cpufreq_gov_dbs_init(void)
-{
- return cpufreq_register_governor(CPU_FREQ_GOV_ONDEMAND);
-}
-
-static void __exit cpufreq_gov_dbs_exit(void)
-{
- cpufreq_unregister_governor(CPU_FREQ_GOV_ONDEMAND);
-}
-
MODULE_AUTHOR("Venkatesh Pallipadi <venkatesh.pallipadi@intel.com>");
MODULE_AUTHOR("Alexey Starikovskiy <alexey.y.starikovskiy@intel.com>");
MODULE_DESCRIPTION("'cpufreq_ondemand' - A dynamic cpufreq governor for "
@@ -480,11 +470,9 @@ MODULE_LICENSE("GPL");
#ifdef CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND
struct cpufreq_governor *cpufreq_default_governor(void)
{
- return CPU_FREQ_GOV_ONDEMAND;
+ return &CPU_FREQ_GOV_ONDEMAND;
}
-
-core_initcall(cpufreq_gov_dbs_init);
-#else
-module_init(cpufreq_gov_dbs_init);
#endif
-module_exit(cpufreq_gov_dbs_exit);
+
+cpufreq_governor_init(CPU_FREQ_GOV_ONDEMAND);
+cpufreq_governor_exit(CPU_FREQ_GOV_ONDEMAND);
diff --git a/drivers/cpufreq/cpufreq_performance.c b/drivers/cpufreq/cpufreq_performance.c
index def9afe0f5b8..71c1d9aba772 100644
--- a/drivers/cpufreq/cpufreq_performance.c
+++ b/drivers/cpufreq/cpufreq_performance.c
@@ -23,16 +23,6 @@ static struct cpufreq_governor cpufreq_gov_performance = {
.limits = cpufreq_gov_performance_limits,
};
-static int __init cpufreq_gov_performance_init(void)
-{
- return cpufreq_register_governor(&cpufreq_gov_performance);
-}
-
-static void __exit cpufreq_gov_performance_exit(void)
-{
- cpufreq_unregister_governor(&cpufreq_gov_performance);
-}
-
#ifdef CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE
struct cpufreq_governor *cpufreq_default_governor(void)
{
@@ -50,5 +40,5 @@ MODULE_AUTHOR("Dominik Brodowski <linux@brodo.de>");
MODULE_DESCRIPTION("CPUfreq policy governor 'performance'");
MODULE_LICENSE("GPL");
-core_initcall(cpufreq_gov_performance_init);
-module_exit(cpufreq_gov_performance_exit);
+cpufreq_governor_init(cpufreq_gov_performance);
+cpufreq_governor_exit(cpufreq_gov_performance);
diff --git a/drivers/cpufreq/cpufreq_powersave.c b/drivers/cpufreq/cpufreq_powersave.c
index 1ae66019eb83..7749522355b5 100644
--- a/drivers/cpufreq/cpufreq_powersave.c
+++ b/drivers/cpufreq/cpufreq_powersave.c
@@ -23,16 +23,6 @@ static struct cpufreq_governor cpufreq_gov_powersave = {
.owner = THIS_MODULE,
};
-static int __init cpufreq_gov_powersave_init(void)
-{
- return cpufreq_register_governor(&cpufreq_gov_powersave);
-}
-
-static void __exit cpufreq_gov_powersave_exit(void)
-{
- cpufreq_unregister_governor(&cpufreq_gov_powersave);
-}
-
MODULE_AUTHOR("Dominik Brodowski <linux@brodo.de>");
MODULE_DESCRIPTION("CPUfreq policy governor 'powersave'");
MODULE_LICENSE("GPL");
@@ -42,9 +32,7 @@ struct cpufreq_governor *cpufreq_default_governor(void)
{
return &cpufreq_gov_powersave;
}
-
-core_initcall(cpufreq_gov_powersave_init);
-#else
-module_init(cpufreq_gov_powersave_init);
#endif
-module_exit(cpufreq_gov_powersave_exit);
+
+cpufreq_governor_init(cpufreq_gov_powersave);
+cpufreq_governor_exit(cpufreq_gov_powersave);
diff --git a/drivers/cpufreq/cpufreq_userspace.c b/drivers/cpufreq/cpufreq_userspace.c
index b43e7cd502c5..50a4d7846580 100644
--- a/drivers/cpufreq/cpufreq_userspace.c
+++ b/drivers/cpufreq/cpufreq_userspace.c
@@ -126,16 +126,6 @@ static struct cpufreq_governor cpufreq_gov_userspace = {
.owner = THIS_MODULE,
};
-static int __init cpufreq_gov_userspace_init(void)
-{
- return cpufreq_register_governor(&cpufreq_gov_userspace);
-}
-
-static void __exit cpufreq_gov_userspace_exit(void)
-{
- cpufreq_unregister_governor(&cpufreq_gov_userspace);
-}
-
MODULE_AUTHOR("Dominik Brodowski <linux@brodo.de>, "
"Russell King <rmk@arm.linux.org.uk>");
MODULE_DESCRIPTION("CPUfreq policy governor 'userspace'");
@@ -146,9 +136,7 @@ struct cpufreq_governor *cpufreq_default_governor(void)
{
return &cpufreq_gov_userspace;
}
-
-core_initcall(cpufreq_gov_userspace_init);
-#else
-module_init(cpufreq_gov_userspace_init);
#endif
-module_exit(cpufreq_gov_userspace_exit);
+
+cpufreq_governor_init(cpufreq_gov_userspace);
+cpufreq_governor_exit(cpufreq_gov_userspace);
diff --git a/include/linux/cpufreq.h b/include/linux/cpufreq.h
index 3494f6763597..e62b022cb07e 100644
--- a/include/linux/cpufreq.h
+++ b/include/linux/cpufreq.h
@@ -577,6 +577,20 @@ unsigned int cpufreq_policy_transition_delay_us(struct cpufreq_policy *policy);
int cpufreq_register_governor(struct cpufreq_governor *governor);
void cpufreq_unregister_governor(struct cpufreq_governor *governor);
+#define cpufreq_governor_init(__governor) \
+static int __init __governor##_init(void) \
+{ \
+ return cpufreq_register_governor(&__governor); \
+} \
+core_initcall(__governor##_init)
+
+#define cpufreq_governor_exit(__governor) \
+static void __exit __governor##_exit(void) \
+{ \
+ return cpufreq_unregister_governor(&__governor); \
+} \
+module_exit(__governor##_exit)
+
struct cpufreq_governor *cpufreq_default_governor(void);
struct cpufreq_governor *cpufreq_fallback_governor(void);
diff --git a/kernel/sched/cpufreq_schedutil.c b/kernel/sched/cpufreq_schedutil.c
index 7fbaee24c824..402a09af9f43 100644
--- a/kernel/sched/cpufreq_schedutil.c
+++ b/kernel/sched/cpufreq_schedutil.c
@@ -909,11 +909,7 @@ struct cpufreq_governor *cpufreq_default_governor(void)
}
#endif
-static int __init sugov_register(void)
-{
- return cpufreq_register_governor(&schedutil_gov);
-}
-core_initcall(sugov_register);
+cpufreq_governor_init(schedutil_gov);
#ifdef CONFIG_ENERGY_MODEL
extern bool sched_energy_update;
--
2.25.0.rc1.19.g042ed3e048af
^ permalink raw reply related
* Re: [PATCH] powerpc/kvm/book3s64/nested: Fix kernel crash with nested kvm
From: Michael Ellerman @ 2020-06-26 4:44 UTC (permalink / raw)
To: Aneesh Kumar K.V, kvm-ppc, paulus; +Cc: linuxppc-dev
In-Reply-To: <20200611120159.680284-1-aneesh.kumar@linux.ibm.com>
On Thu, 11 Jun 2020 17:31:59 +0530, Aneesh Kumar K.V wrote:
> __pa() do check for addr value passed and if < PAGE_OFFSET
> results in BUG.
>
> #define __pa(x) \
> ({ \
> VIRTUAL_BUG_ON((unsigned long)(x) < PAGE_OFFSET); \
> (unsigned long)(x) & 0x0fffffffffffffffUL; \
> })
>
> [...]
Applied to powerpc/fixes.
[1/1] powerpc/kvm/book3s64: Fix kernel crash with nested kvm & DEBUG_VIRTUAL
https://git.kernel.org/powerpc/c/c1ed1754f271f6b7acb1bfdc8cfb62220fbed423
cheers
^ permalink raw reply
* Re: [PATCH] powerpc/fsl_booke/32: fix build with CONFIG_RANDOMIZE_BASE
From: Michael Ellerman @ 2020-06-26 4:44 UTC (permalink / raw)
To: Arseny Solokha, Jason Yan, Michael Ellerman, linuxppc-dev
Cc: Scott Wood, Christophe Leroy, linux-kernel, stable
In-Reply-To: <20200613162801.1946619-1-asolokha@kb.kras.ru>
On Sat, 13 Jun 2020 23:28:01 +0700, Arseny Solokha wrote:
> Building the current 5.8 kernel for a e500 machine with
> CONFIG_RANDOMIZE_BASE set yields the following failure:
>
> arch/powerpc/mm/nohash/kaslr_booke.c: In function 'kaslr_early_init':
> arch/powerpc/mm/nohash/kaslr_booke.c:387:2: error: implicit declaration
> of function 'flush_icache_range'; did you mean 'flush_tlb_range'?
> [-Werror=implicit-function-declaration]
>
> [...]
Applied to powerpc/fixes.
[1/1] powerpc/fsl_booke/32: Fix build with CONFIG_RANDOMIZE_BASE
https://git.kernel.org/powerpc/c/7e4773f73dcfb92e7e33532162f722ec291e75a4
cheers
^ permalink raw reply
* Re: [PATCH kernel] powerpc/xive: Ignore kmemleak false positives
From: Michael Ellerman @ 2020-06-26 4:45 UTC (permalink / raw)
To: linuxppc-dev, Alexey Kardashevskiy; +Cc: Paul Mackerras
In-Reply-To: <20200612043303.84894-1-aik@ozlabs.ru>
On Fri, 12 Jun 2020 14:33:03 +1000, Alexey Kardashevskiy wrote:
> xive_native_provision_pages() allocates memory and passes the pointer to
> OPAL so kmemleak cannot find the pointer usage in the kernel memory and
> produces a false positive report (below) (even if the kernel did scan
> OPAL memory, it is unable to deal with __pa() addresses anyway).
>
> This silences the warning.
>
> [...]
Applied to powerpc/next.
[1/1] powerpc/xive: Ignore kmemleak false positives
https://git.kernel.org/powerpc/c/f0993c839e95dd6c7f054a1015e693c87e33e4fb
cheers
^ permalink raw reply
* Re: [PATCH kernel v2] powerpc/powernv/ioda: Return correct error if TCE level allocation failed
From: Michael Ellerman @ 2020-06-26 4:45 UTC (permalink / raw)
To: linuxppc-dev, Alexey Kardashevskiy
In-Reply-To: <20200617003835.48831-1-aik@ozlabs.ru>
On Wed, 17 Jun 2020 10:38:35 +1000, Alexey Kardashevskiy wrote:
> The iommu_table_ops::xchg_no_kill() callback updates TCE. It is quite
> possible that not entire table is allocated if it is huge and multilevel
> so xchg may also allocate subtables. If failed, it returns H_HARDWARE
> for failed allocation and H_TOO_HARD if it needs it but cannot do because
> the alloc parameter is "false" (set when called with MMU=off to force
> retry with MMU=on).
>
> [...]
Applied to powerpc/next.
[1/1] powerpc/powernv/ioda: Return correct error if TCE level allocation failed
https://git.kernel.org/powerpc/c/5f202c1a1d429bee3ddab647711f181c72d157da
cheers
^ permalink raw reply
* Re: [PATCH] powerpc/mm/book3s64: Skip 16G page reservation with radix
From: Michael Ellerman @ 2020-06-26 4:45 UTC (permalink / raw)
To: linuxppc-dev, Aneesh Kumar K.V, mpe
In-Reply-To: <20200622064019.16682-1-aneesh.kumar@linux.ibm.com>
On Mon, 22 Jun 2020 12:10:19 +0530, Aneesh Kumar K.V wrote:
> With hash translation, the hypervisor can hint the LPAR about 16GB contiguous range
> via ibm,expected#pages. The kernel marks the range specified in the device tree
> as reserved. Avoid doing this when using radix translation. Radix translation
> only supports 1G gigantic hugepage and kernel can do the 1G gigantic hugepage
> allocation via early memblock reservation. This can be done because with radix
> translation pages are not required to be contiguous on the host.
Applied to powerpc/next.
[1/1] powerpc/mm/book3s64: Skip 16G page reservation with radix
https://git.kernel.org/powerpc/c/86590e524ee834b629afc55d8e5786091fbf84cc
cheers
^ permalink raw reply
* Re: [PATCH v3 0/2] powerpc: CMDLINE config cleanup
From: Michael Ellerman @ 2020-06-26 4:45 UTC (permalink / raw)
To: benh, paulus, Chris Packham, christophe.leroy, mpe
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <20200611224220.25066-1-chris.packham@alliedtelesis.co.nz>
On Fri, 12 Jun 2020 10:42:18 +1200, Chris Packham wrote:
> This series cleans up the config options related to the boot command line.
>
> Chris Packham (2):
> powerpc: Remove inaccessible CMDLINE default
> powerpc: configs: remove CMDLINE_BOOL
>
> arch/powerpc/Kconfig | 6 +-----
> arch/powerpc/configs/44x/akebono_defconfig | 2 --
> arch/powerpc/configs/44x/arches_defconfig | 2 --
> arch/powerpc/configs/44x/bamboo_defconfig | 2 --
> arch/powerpc/configs/44x/bluestone_defconfig | 2 --
> arch/powerpc/configs/44x/canyonlands_defconfig | 2 --
> arch/powerpc/configs/44x/currituck_defconfig | 2 --
> arch/powerpc/configs/44x/eiger_defconfig | 2 --
> arch/powerpc/configs/44x/fsp2_defconfig | 1 -
> arch/powerpc/configs/44x/icon_defconfig | 2 --
> arch/powerpc/configs/44x/iss476-smp_defconfig | 1 -
> arch/powerpc/configs/44x/katmai_defconfig | 2 --
> arch/powerpc/configs/44x/rainier_defconfig | 2 --
> arch/powerpc/configs/44x/redwood_defconfig | 2 --
> arch/powerpc/configs/44x/sam440ep_defconfig | 2 --
> arch/powerpc/configs/44x/sequoia_defconfig | 2 --
> arch/powerpc/configs/44x/taishan_defconfig | 2 --
> arch/powerpc/configs/44x/warp_defconfig | 1 -
> arch/powerpc/configs/holly_defconfig | 1 -
> arch/powerpc/configs/mvme5100_defconfig | 3 +--
> arch/powerpc/configs/ps3_defconfig | 2 --
> arch/powerpc/configs/skiroot_defconfig | 1 -
> arch/powerpc/configs/storcenter_defconfig | 1 -
> 23 files changed, 2 insertions(+), 43 deletions(-)
Applied to powerpc/next.
[1/2] powerpc: Remove inaccessible CMDLINE default
https://git.kernel.org/powerpc/c/f134a7cef1d7de45fab028a945b7f34c615718e1
[2/2] powerpc/configs: Remove CMDLINE_BOOL
https://git.kernel.org/powerpc/c/0488d32530ecff973c40f2592a6eab2907d0a5cc
cheers
^ permalink raw reply
* Re: [PATCH] powerpc/8xx: Modify ptep_get()
From: Michael Ellerman @ 2020-06-26 4:45 UTC (permalink / raw)
To: Paul Mackerras, Will Deacon, Andrew Morton, Christophe Leroy,
Peter Zijlstra (Intel), Benjamin Herrenschmidt, Michael Ellerman
Cc: linux-mm, linuxppc-dev, linux-kernel
In-Reply-To: <9f2df6621fcaf9eba15fadc61c169d0c8e2fb849.1592481938.git.christophe.leroy@csgroup.eu>
On Thu, 18 Jun 2020 12:07:46 +0000 (UTC), Christophe Leroy wrote:
> Move ptep_get() close to pte_update(), in an ifdef section already
> dedicated to powerpc 8xx. This section contains explanation about
> the layout of page table entries.
>
> Also modify it to return 4 times the pte value instead of padding
> with zeroes.
Applied to powerpc/next.
[1/1] powerpc/8xx: Modify ptep_get()
https://git.kernel.org/powerpc/c/105fb38124a490f38e9c1e23bb4c4a0b6ba12fdb
cheers
^ 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