* [PATCH AUTOSEL 4.19 243/252] microblaze: Prevent the overflow of the start
From: Sasha Levin @ 2020-02-14 16:11 UTC (permalink / raw)
To: linux-kernel, stable; +Cc: Shubhrajyoti Datta, Michal Simek, Sasha Levin
In-Reply-To: <20200214161147.15842-1-sashal@kernel.org>
From: Shubhrajyoti Datta <shubhrajyoti.datta@xilinx.com>
[ Upstream commit 061d2c1d593076424c910cb1b64ecdb5c9a6923f ]
In case the start + cache size is more than the max int the
start overflows.
Prevent the same.
Signed-off-by: Shubhrajyoti Datta <shubhrajyoti.datta@xilinx.com>
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
arch/microblaze/kernel/cpu/cache.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/microblaze/kernel/cpu/cache.c b/arch/microblaze/kernel/cpu/cache.c
index 0bde47e4fa694..dcba53803fa5f 100644
--- a/arch/microblaze/kernel/cpu/cache.c
+++ b/arch/microblaze/kernel/cpu/cache.c
@@ -92,7 +92,8 @@ static inline void __disable_dcache_nomsr(void)
#define CACHE_LOOP_LIMITS(start, end, cache_line_length, cache_size) \
do { \
int align = ~(cache_line_length - 1); \
- end = min(start + cache_size, end); \
+ if (start < UINT_MAX - cache_size) \
+ end = min(start + cache_size, end); \
start &= align; \
} while (0)
--
2.20.1
^ permalink raw reply related
* Re: [PATCH 41/62] x86/sev-es: Handle MSR events
From: Dave Hansen @ 2020-02-14 16:59 UTC (permalink / raw)
To: Joerg Roedel
Cc: Juergen Gross, Tom Lendacky, Thomas Hellstrom, Dave Hansen,
Kees Cook, kvm, Peter Zijlstra, x86, linux-kernel, virtualization,
Joerg Roedel, Andy Lutomirski, hpa, Dan Williams, Jiri Slaby
In-Reply-To: <20200214072324.GE22063@8bytes.org>
On 2/13/20 11:23 PM, Joerg Roedel wrote:
> Yes, investigating this is on the list for future optimizations (besides
> caching CPUID results). My idea is to use alternatives patching for
> this. But the exception handling is needed anyway because #VC
> exceptions happen very early already, basically the first thing after
> setting up a stack is calling verify_cpu(), which uses CPUID.
Ahh, bummer. How does a guest know that it's running under SEV-ES?
What's the enumeration mechanism if CPUID doesn't "work"?
> The other reason is that things like MMIO and IOIO instructions can't be
> easily patched by alternatives. Those would work with the runtime
> checking you showed above, though.
Is there a reason we can't make a rule that you *must* do MMIO through
an accessor function so we *can* patch them? I know random drivers
might break the rule, but are SEV-ES guests going to be running random
drivers? I would think that they mostly if not all want to use virtio.
^ permalink raw reply
* Re: [PATCH 09/11] drm, cgroup: Introduce lgpu as DRM cgroup resource
From: Jason Ekstrand @ 2020-02-14 16:59 UTC (permalink / raw)
To: Kenny Ho
Cc: juan.zuniga-anaya, felix.kuehling, jsparks, amd-gfx mailing list,
lkaplan, alexander.deucher, nirmoy.das, y2kenny,
Maling list - DRI developers, joseph.greathouse, tj, cgroups,
Christian König, damon.mcdougall
In-Reply-To: <CAOFGe96N5gG+08rQCRC+diHKDAfxPFYEnVxDS8_udvjcBYgsPg@mail.gmail.com>
On Fri, Feb 14, 2020 at 10:44 AM Jason Ekstrand <jason@jlekstrand.net> wrote:
>
> Pardon my ignorance but I'm a bit confused by this. What is a "logical GPU"? What are we subdividing? Are we carving up memory? Compute power? Both?
>
> If it's carving up memory, why aren't we just measuring it in megabytes?
>
> If it's carving up compute power, what's actually being carved up? Time? Execution units/waves/threads? Even if that's the case, what advantage does it give to have it in terms of a fixed set of lgpus where each cgroup gets to pick a fixed set. Does affinity matter that much? Why not just say how many waves the GPU supports and that they have to be allocated in chunks of 16 waves (pulling a number out of thin air) and let the cgroup specify how many waves it wants.
One more question: If I'm a userspace driver, and there are 14 lgpus
allocated to my cgroup, does that mean I have 14 GPUs? Or does that
mean I have one GPU with 14 units of compute power?
> Don't get me wrong here. I'm all for the notion of being able to use cgroups to carve up GPU compute resources. However, this sounds to me like the most AMD-specific solution possible. We (Intel) could probably do some sort of carving up as well but we'd likely want to do it with preemption and time-slicing rather than handing out specific EUs.
Ok, so "most AMD-specific solution possible" probably wasn't fair.
However, it does seem like an unnecessarily rigid solution to me.
Maybe there's something I'm not getting?
--Jason
> --Jason
>
>
> On Fri, Feb 14, 2020 at 9:57 AM Kenny Ho <Kenny.Ho@amd.com> wrote:
>>
>> drm.lgpu
>> A read-write nested-keyed file which exists on all cgroups.
>> Each entry is keyed by the DRM device's major:minor.
>>
>> lgpu stands for logical GPU, it is an abstraction used to
>> subdivide a physical DRM device for the purpose of resource
>> management. This file stores user configuration while the
>> drm.lgpu.effective reflects the actual allocation after
>> considering the relationship between the cgroups and their
>> configurations.
>>
>> The lgpu is a discrete quantity that is device specific (i.e.
>> some DRM devices may have 64 lgpus while others may have 100
>> lgpus.) The lgpu is a single quantity that can be allocated
>> in three different ways denoted by the following nested keys.
>>
>> ===== ==============================================
>> weight Allocate by proportion in relationship with
>> active sibling cgroups
>> count Allocate by amount statically, treat lgpu as
>> anonymous resources
>> list Allocate statically, treat lgpu as named
>> resource
>> ===== ==============================================
>>
>> For example:
>> 226:0 weight=100 count=256 list=0-255
>> 226:1 weight=100 count=4 list=0,2,4,6
>> 226:2 weight=100 count=32 list=32-63
>> 226:3 weight=100 count=0 list=
>> 226:4 weight=500 count=0 list=
>>
>> lgpu is represented by a bitmap and uses the bitmap_parselist
>> kernel function so the list key input format is a
>> comma-separated list of decimal numbers and ranges.
>>
>> Consecutively set bits are shown as two hyphen-separated decimal
>> numbers, the smallest and largest bit numbers set in the range.
>> Optionally each range can be postfixed to denote that only parts
>> of it should be set. The range will divided to groups of
>> specific size.
>> Syntax: range:used_size/group_size
>> Example: 0-1023:2/256 ==> 0,1,256,257,512,513,768,769
>>
>> The count key is the hamming weight / hweight of the bitmap.
>>
>> Weight, count and list accept the max and default keywords.
>>
>> Some DRM devices may only support lgpu as anonymous resources.
>> In such case, the significance of the position of the set bits
>> in list will be ignored.
>>
>> The weight quantity is only in effect when static allocation
>> is not used (by setting count=0) for this cgroup. The weight
>> quantity distributes lgpus that are not statically allocated by
>> the siblings. For example, given siblings cgroupA, cgroupB and
>> cgroupC for a DRM device that has 64 lgpus, if cgroupA occupies
>> 0-63, no lgpu is available to be distributed by weight.
>> Similarly, if cgroupA has list=0-31 and cgroupB has list=16-63,
>> cgroupC will be starved if it tries to allocate by weight.
>>
>> On the other hand, if cgroupA has weight=100 count=0, cgroupB
>> has list=16-47, and cgroupC has weight=100 count=0, then 32
>> lgpus are available to be distributed evenly between cgroupA
>> and cgroupC. In drm.lgpu.effective, cgroupA will have
>> list=0-15 and cgroupC will have list=48-63.
>>
>> This lgpu resource supports the 'allocation' and 'weight'
>> resource distribution model.
>>
>> drm.lgpu.effective
>> A read-only nested-keyed file which exists on all cgroups.
>> Each entry is keyed by the DRM device's major:minor.
>>
>> lgpu stands for logical GPU, it is an abstraction used to
>> subdivide a physical DRM device for the purpose of resource
>> management. This file reflects the actual allocation after
>> considering the relationship between the cgroups and their
>> configurations in drm.lgpu.
>>
>> Change-Id: Idde0ef9a331fd67bb9c7eb8ef9978439e6452488
>> Signed-off-by: Kenny Ho <Kenny.Ho@amd.com>
>> ---
>> Documentation/admin-guide/cgroup-v2.rst | 80 ++++++
>> include/drm/drm_cgroup.h | 3 +
>> include/linux/cgroup_drm.h | 22 ++
>> kernel/cgroup/drm.c | 324 +++++++++++++++++++++++-
>> 4 files changed, 427 insertions(+), 2 deletions(-)
>>
>> diff --git a/Documentation/admin-guide/cgroup-v2.rst b/Documentation/admin-guide/cgroup-v2.rst
>> index ce5dc027366a..d8a41956e5c7 100644
>> --- a/Documentation/admin-guide/cgroup-v2.rst
>> +++ b/Documentation/admin-guide/cgroup-v2.rst
>> @@ -2120,6 +2120,86 @@ DRM Interface Files
>> Set largest allocation for /dev/dri/card1 to 4MB
>> echo "226:1 4m" > drm.buffer.peak.max
>>
>> + drm.lgpu
>> + A read-write nested-keyed file which exists on all cgroups.
>> + Each entry is keyed by the DRM device's major:minor.
>> +
>> + lgpu stands for logical GPU, it is an abstraction used to
>> + subdivide a physical DRM device for the purpose of resource
>> + management. This file stores user configuration while the
>> + drm.lgpu.effective reflects the actual allocation after
>> + considering the relationship between the cgroups and their
>> + configurations.
>> +
>> + The lgpu is a discrete quantity that is device specific (i.e.
>> + some DRM devices may have 64 lgpus while others may have 100
>> + lgpus.) The lgpu is a single quantity that can be allocated
>> + in three different ways denoted by the following nested keys.
>> +
>> + ===== ==============================================
>> + weight Allocate by proportion in relationship with
>> + active sibling cgroups
>> + count Allocate by amount statically, treat lgpu as
>> + anonymous resources
>> + list Allocate statically, treat lgpu as named
>> + resource
>> + ===== ==============================================
>> +
>> + For example:
>> + 226:0 weight=100 count=256 list=0-255
>> + 226:1 weight=100 count=4 list=0,2,4,6
>> + 226:2 weight=100 count=32 list=32-63
>> + 226:3 weight=100 count=0 list=
>> + 226:4 weight=500 count=0 list=
>> +
>> + lgpu is represented by a bitmap and uses the bitmap_parselist
>> + kernel function so the list key input format is a
>> + comma-separated list of decimal numbers and ranges.
>> +
>> + Consecutively set bits are shown as two hyphen-separated decimal
>> + numbers, the smallest and largest bit numbers set in the range.
>> + Optionally each range can be postfixed to denote that only parts
>> + of it should be set. The range will divided to groups of
>> + specific size.
>> + Syntax: range:used_size/group_size
>> + Example: 0-1023:2/256 ==> 0,1,256,257,512,513,768,769
>> +
>> + The count key is the hamming weight / hweight of the bitmap.
>> +
>> + Weight, count and list accept the max and default keywords.
>> +
>> + Some DRM devices may only support lgpu as anonymous resources.
>> + In such case, the significance of the position of the set bits
>> + in list will be ignored.
>> +
>> + The weight quantity is only in effect when static allocation
>> + is not used (by setting count=0) for this cgroup. The weight
>> + quantity distributes lgpus that are not statically allocated by
>> + the siblings. For example, given siblings cgroupA, cgroupB and
>> + cgroupC for a DRM device that has 64 lgpus, if cgroupA occupies
>> + 0-63, no lgpu is available to be distributed by weight.
>> + Similarly, if cgroupA has list=0-31 and cgroupB has list=16-63,
>> + cgroupC will be starved if it tries to allocate by weight.
>> +
>> + On the other hand, if cgroupA has weight=100 count=0, cgroupB
>> + has list=16-47, and cgroupC has weight=100 count=0, then 32
>> + lgpus are available to be distributed evenly between cgroupA
>> + and cgroupC. In drm.lgpu.effective, cgroupA will have
>> + list=0-15 and cgroupC will have list=48-63.
>> +
>> + This lgpu resource supports the 'allocation' and 'weight'
>> + resource distribution model.
>> +
>> + drm.lgpu.effective
>> + A read-only nested-keyed file which exists on all cgroups.
>> + Each entry is keyed by the DRM device's major:minor.
>> +
>> + lgpu stands for logical GPU, it is an abstraction used to
>> + subdivide a physical DRM device for the purpose of resource
>> + management. This file reflects the actual allocation after
>> + considering the relationship between the cgroups and their
>> + configurations in drm.lgpu.
>> +
>> GEM Buffer Ownership
>> ~~~~~~~~~~~~~~~~~~~~
>>
>> diff --git a/include/drm/drm_cgroup.h b/include/drm/drm_cgroup.h
>> index 2b41d4d22e33..619a110cc748 100644
>> --- a/include/drm/drm_cgroup.h
>> +++ b/include/drm/drm_cgroup.h
>> @@ -17,6 +17,9 @@ struct drmcg_props {
>>
>> s64 bo_limits_total_allocated_default;
>> s64 bo_limits_peak_allocated_default;
>> +
>> + int lgpu_capacity;
>> + DECLARE_BITMAP(lgpu_slots, MAX_DRMCG_LGPU_CAPACITY);
>> };
>>
>> void drmcg_bind(struct drm_minor (*(*acq_dm)(unsigned int minor_id)),
>> diff --git a/include/linux/cgroup_drm.h b/include/linux/cgroup_drm.h
>> index eae400f3d9b4..bb09704e7f71 100644
>> --- a/include/linux/cgroup_drm.h
>> +++ b/include/linux/cgroup_drm.h
>> @@ -11,10 +11,14 @@
>> /* limit defined per the way drm_minor_alloc operates */
>> #define MAX_DRM_DEV (64 * DRM_MINOR_RENDER)
>>
>> +#define MAX_DRMCG_LGPU_CAPACITY 256
>> +
>> enum drmcg_res_type {
>> DRMCG_TYPE_BO_TOTAL,
>> DRMCG_TYPE_BO_PEAK,
>> DRMCG_TYPE_BO_COUNT,
>> + DRMCG_TYPE_LGPU,
>> + DRMCG_TYPE_LGPU_EFF,
>> __DRMCG_TYPE_LAST,
>> };
>>
>> @@ -32,6 +36,24 @@ struct drmcg_device_resource {
>> s64 bo_limits_peak_allocated;
>>
>> s64 bo_stats_count_allocated;
>> +
>> + /**
>> + * Logical GPU
>> + *
>> + * *_cfg are properties configured by users
>> + * *_eff are the effective properties being applied to the hardware
>> + * *_stg is used to calculate _eff before applying to _eff
>> + * after considering the entire hierarchy
>> + */
>> + DECLARE_BITMAP(lgpu_stg, MAX_DRMCG_LGPU_CAPACITY);
>> + /* user configurations */
>> + s64 lgpu_weight_cfg;
>> + DECLARE_BITMAP(lgpu_cfg, MAX_DRMCG_LGPU_CAPACITY);
>> + /* effective lgpu for the cgroup after considering
>> + * relationship with other cgroup
>> + */
>> + s64 lgpu_count_eff;
>> + DECLARE_BITMAP(lgpu_eff, MAX_DRMCG_LGPU_CAPACITY);
>> };
>>
>> /**
>> diff --git a/kernel/cgroup/drm.c b/kernel/cgroup/drm.c
>> index 5fcbbc13fa1c..a4e88a3704bb 100644
>> --- a/kernel/cgroup/drm.c
>> +++ b/kernel/cgroup/drm.c
>> @@ -9,6 +9,7 @@
>> #include <linux/seq_file.h>
>> #include <linux/mutex.h>
>> #include <linux/kernel.h>
>> +#include <linux/bitmap.h>
>> #include <linux/cgroup_drm.h>
>> #include <drm/drm_file.h>
>> #include <drm/drm_drv.h>
>> @@ -41,6 +42,10 @@ enum drmcg_file_type {
>> DRMCG_FTYPE_DEFAULT,
>> };
>>
>> +#define LGPU_LIMITS_NAME_LIST "list"
>> +#define LGPU_LIMITS_NAME_COUNT "count"
>> +#define LGPU_LIMITS_NAME_WEIGHT "weight"
>> +
>> /**
>> * drmcg_bind - Bind DRM subsystem to cgroup subsystem
>> * @acq_dm: function pointer to the drm_minor_acquire function
>> @@ -98,6 +103,13 @@ static inline int init_drmcg_single(struct drmcg *drmcg, struct drm_device *dev)
>> ddr->bo_limits_peak_allocated =
>> dev->drmcg_props.bo_limits_peak_allocated_default;
>>
>> + bitmap_copy(ddr->lgpu_cfg, dev->drmcg_props.lgpu_slots,
>> + MAX_DRMCG_LGPU_CAPACITY);
>> + bitmap_copy(ddr->lgpu_stg, dev->drmcg_props.lgpu_slots,
>> + MAX_DRMCG_LGPU_CAPACITY);
>> +
>> + ddr->lgpu_weight_cfg = CGROUP_WEIGHT_DFL;
>> +
>> return 0;
>> }
>>
>> @@ -121,6 +133,120 @@ static inline void drmcg_update_cg_tree(struct drm_device *dev)
>> mutex_unlock(&cgroup_mutex);
>> }
>>
>> +static void drmcg_calculate_effective_lgpu(struct drm_device *dev,
>> + const unsigned long *free_static,
>> + const unsigned long *free_weighted,
>> + struct drmcg *parent_drmcg)
>> +{
>> + int capacity = dev->drmcg_props.lgpu_capacity;
>> + DECLARE_BITMAP(lgpu_unused, MAX_DRMCG_LGPU_CAPACITY);
>> + DECLARE_BITMAP(lgpu_by_weight, MAX_DRMCG_LGPU_CAPACITY);
>> + struct drmcg_device_resource *parent_ddr;
>> + struct drmcg_device_resource *ddr;
>> + int minor = dev->primary->index;
>> + struct cgroup_subsys_state *pos;
>> + struct drmcg *child;
>> + s64 weight_sum = 0;
>> + s64 unused;
>> +
>> + parent_ddr = parent_drmcg->dev_resources[minor];
>> +
>> + if (bitmap_empty(parent_ddr->lgpu_cfg, capacity))
>> + /* no static cfg, use weight for calculating the effective */
>> + bitmap_copy(parent_ddr->lgpu_stg, free_weighted, capacity);
>> + else
>> + /* lgpu statically configured, use the overlap as effective */
>> + bitmap_and(parent_ddr->lgpu_stg, free_static,
>> + parent_ddr->lgpu_cfg, capacity);
>> +
>> + /* calculate lgpu available for distribution by weight for children */
>> + bitmap_copy(lgpu_unused, parent_ddr->lgpu_stg, capacity);
>> + css_for_each_child(pos, &parent_drmcg->css) {
>> + child = css_to_drmcg(pos);
>> + ddr = child->dev_resources[minor];
>> +
>> + if (bitmap_empty(ddr->lgpu_cfg, capacity))
>> + /* no static allocation, participate in weight dist */
>> + weight_sum += ddr->lgpu_weight_cfg;
>> + else
>> + /* take out statically allocated lgpu by siblings */
>> + bitmap_andnot(lgpu_unused, lgpu_unused, ddr->lgpu_cfg,
>> + capacity);
>> + }
>> +
>> + unused = bitmap_weight(lgpu_unused, capacity);
>> +
>> + css_for_each_child(pos, &parent_drmcg->css) {
>> + child = css_to_drmcg(pos);
>> + ddr = child->dev_resources[minor];
>> +
>> + bitmap_zero(lgpu_by_weight, capacity);
>> + /* no static allocation, participate in weight distribution */
>> + if (bitmap_empty(ddr->lgpu_cfg, capacity)) {
>> + int c;
>> + int p = 0;
>> +
>> + for (c = ddr->lgpu_weight_cfg * unused / weight_sum;
>> + c > 0; c--) {
>> + p = find_next_bit(lgpu_unused, capacity, p);
>> + if (p < capacity) {
>> + clear_bit(p, lgpu_unused);
>> + set_bit(p, lgpu_by_weight);
>> + }
>> + }
>> +
>> + }
>> +
>> + drmcg_calculate_effective_lgpu(dev, parent_ddr->lgpu_stg,
>> + lgpu_by_weight, child);
>> + }
>> +}
>> +
>> +static void drmcg_apply_effective_lgpu(struct drm_device *dev)
>> +{
>> + int capacity = dev->drmcg_props.lgpu_capacity;
>> + int minor = dev->primary->index;
>> + struct drmcg_device_resource *ddr;
>> + struct cgroup_subsys_state *pos;
>> + struct drmcg *drmcg;
>> +
>> + if (root_drmcg == NULL) {
>> + WARN_ON(root_drmcg == NULL);
>> + return;
>> + }
>> +
>> + rcu_read_lock();
>> +
>> + /* process the entire cgroup tree from root to simplify the algorithm */
>> + drmcg_calculate_effective_lgpu(dev, dev->drmcg_props.lgpu_slots,
>> + dev->drmcg_props.lgpu_slots, root_drmcg);
>> +
>> + /* apply changes to effective only if there is a change */
>> + css_for_each_descendant_pre(pos, &root_drmcg->css) {
>> + drmcg = css_to_drmcg(pos);
>> + ddr = drmcg->dev_resources[minor];
>> +
>> + if (!bitmap_equal(ddr->lgpu_stg, ddr->lgpu_eff, capacity)) {
>> + bitmap_copy(ddr->lgpu_eff, ddr->lgpu_stg, capacity);
>> + ddr->lgpu_count_eff =
>> + bitmap_weight(ddr->lgpu_eff, capacity);
>> + }
>> + }
>> + rcu_read_unlock();
>> +}
>> +
>> +static void drmcg_apply_effective(enum drmcg_res_type type,
>> + struct drm_device *dev, struct drmcg *changed_drmcg)
>> +{
>> + switch (type) {
>> + case DRMCG_TYPE_LGPU:
>> + drmcg_apply_effective_lgpu(dev);
>> + break;
>> + default:
>> + break;
>> + }
>> +}
>> +
>> /**
>> * drmcg_register_dev - register a DRM device for usage in drm cgroup
>> * @dev: DRM device
>> @@ -143,7 +269,13 @@ void drmcg_register_dev(struct drm_device *dev)
>> {
>> dev->driver->drmcg_custom_init(dev, &dev->drmcg_props);
>>
>> + WARN_ON(dev->drmcg_props.lgpu_capacity !=
>> + bitmap_weight(dev->drmcg_props.lgpu_slots,
>> + MAX_DRMCG_LGPU_CAPACITY));
>> +
>> drmcg_update_cg_tree(dev);
>> +
>> + drmcg_apply_effective(DRMCG_TYPE_LGPU, dev, root_drmcg);
>> }
>> mutex_unlock(&drmcg_mutex);
>> }
>> @@ -297,7 +429,8 @@ static void drmcg_print_stats(struct drmcg_device_resource *ddr,
>> }
>>
>> static void drmcg_print_limits(struct drmcg_device_resource *ddr,
>> - struct seq_file *sf, enum drmcg_res_type type)
>> + struct seq_file *sf, enum drmcg_res_type type,
>> + struct drm_device *dev)
>> {
>> if (ddr == NULL) {
>> seq_puts(sf, "\n");
>> @@ -311,6 +444,25 @@ static void drmcg_print_limits(struct drmcg_device_resource *ddr,
>> case DRMCG_TYPE_BO_PEAK:
>> seq_printf(sf, "%lld\n", ddr->bo_limits_peak_allocated);
>> break;
>> + case DRMCG_TYPE_LGPU:
>> + seq_printf(sf, "%s=%lld %s=%d %s=%*pbl\n",
>> + LGPU_LIMITS_NAME_WEIGHT,
>> + ddr->lgpu_weight_cfg,
>> + LGPU_LIMITS_NAME_COUNT,
>> + bitmap_weight(ddr->lgpu_cfg,
>> + dev->drmcg_props.lgpu_capacity),
>> + LGPU_LIMITS_NAME_LIST,
>> + dev->drmcg_props.lgpu_capacity,
>> + ddr->lgpu_cfg);
>> + break;
>> + case DRMCG_TYPE_LGPU_EFF:
>> + seq_printf(sf, "%s=%lld %s=%*pbl\n",
>> + LGPU_LIMITS_NAME_COUNT,
>> + ddr->lgpu_count_eff,
>> + LGPU_LIMITS_NAME_LIST,
>> + dev->drmcg_props.lgpu_capacity,
>> + ddr->lgpu_eff);
>> + break;
>> default:
>> seq_puts(sf, "\n");
>> break;
>> @@ -329,6 +481,17 @@ static void drmcg_print_default(struct drmcg_props *props,
>> seq_printf(sf, "%lld\n",
>> props->bo_limits_peak_allocated_default);
>> break;
>> + case DRMCG_TYPE_LGPU:
>> + seq_printf(sf, "%s=%d %s=%d %s=%*pbl\n",
>> + LGPU_LIMITS_NAME_WEIGHT,
>> + CGROUP_WEIGHT_DFL,
>> + LGPU_LIMITS_NAME_COUNT,
>> + bitmap_weight(props->lgpu_slots,
>> + props->lgpu_capacity),
>> + LGPU_LIMITS_NAME_LIST,
>> + props->lgpu_capacity,
>> + props->lgpu_slots);
>> + break;
>> default:
>> seq_puts(sf, "\n");
>> break;
>> @@ -358,7 +521,7 @@ static int drmcg_seq_show_fn(int id, void *ptr, void *data)
>> drmcg_print_stats(ddr, sf, type);
>> break;
>> case DRMCG_FTYPE_LIMIT:
>> - drmcg_print_limits(ddr, sf, type);
>> + drmcg_print_limits(ddr, sf, type, minor->dev);
>> break;
>> case DRMCG_FTYPE_DEFAULT:
>> drmcg_print_default(&minor->dev->drmcg_props, sf, type);
>> @@ -415,6 +578,115 @@ static int drmcg_process_limit_s64_val(char *sval, bool is_mem,
>> return rc;
>> }
>>
>> +static void drmcg_nested_limit_parse(struct kernfs_open_file *of,
>> + struct drm_device *dev, char *attrs)
>> +{
>> + DECLARE_BITMAP(tmp_bitmap, MAX_DRMCG_LGPU_CAPACITY);
>> + DECLARE_BITMAP(chk_bitmap, MAX_DRMCG_LGPU_CAPACITY);
>> + enum drmcg_res_type type =
>> + DRMCG_CTF_PRIV2RESTYPE(of_cft(of)->private);
>> + struct drmcg *drmcg = css_to_drmcg(of_css(of));
>> + struct drmcg_props *props = &dev->drmcg_props;
>> + char *cft_name = of_cft(of)->name;
>> + int minor = dev->primary->index;
>> + char *nested = strstrip(attrs);
>> + struct drmcg_device_resource *ddr =
>> + drmcg->dev_resources[minor];
>> + char *attr;
>> + char sname[256];
>> + char sval[256];
>> + s64 val;
>> + int rc;
>> +
>> + while (nested != NULL) {
>> + attr = strsep(&nested, " ");
>> +
>> + if (sscanf(attr, "%255[^=]=%255[^=]", sname, sval) != 2)
>> + continue;
>> +
>> + switch (type) {
>> + case DRMCG_TYPE_LGPU:
>> + if (strncmp(sname, LGPU_LIMITS_NAME_LIST, 256) &&
>> + strncmp(sname, LGPU_LIMITS_NAME_COUNT, 256) &&
>> + strncmp(sname, LGPU_LIMITS_NAME_WEIGHT, 256))
>> + continue;
>> +
>> + if (strncmp(sname, LGPU_LIMITS_NAME_WEIGHT, 256) &&
>> + (!strcmp("max", sval) ||
>> + !strcmp("default", sval))) {
>> + bitmap_copy(ddr->lgpu_cfg, props->lgpu_slots,
>> + props->lgpu_capacity);
>> +
>> + continue;
>> + }
>> +
>> + if (strncmp(sname, LGPU_LIMITS_NAME_WEIGHT, 256) == 0) {
>> + rc = drmcg_process_limit_s64_val(sval,
>> + false, CGROUP_WEIGHT_DFL,
>> + CGROUP_WEIGHT_MAX, &val);
>> +
>> + if (rc || val < CGROUP_WEIGHT_MIN ||
>> + val > CGROUP_WEIGHT_MAX) {
>> + drmcg_pr_cft_err(drmcg, rc, cft_name,
>> + minor);
>> + continue;
>> + }
>> +
>> + ddr->lgpu_weight_cfg = val;
>> + continue;
>> + }
>> +
>> + if (strncmp(sname, LGPU_LIMITS_NAME_COUNT, 256) == 0) {
>> + rc = drmcg_process_limit_s64_val(sval,
>> + false, props->lgpu_capacity,
>> + props->lgpu_capacity, &val);
>> +
>> + if (rc || val < 0) {
>> + drmcg_pr_cft_err(drmcg, rc, cft_name,
>> + minor);
>> + continue;
>> + }
>> +
>> + bitmap_zero(tmp_bitmap,
>> + MAX_DRMCG_LGPU_CAPACITY);
>> + bitmap_set(tmp_bitmap, 0, val);
>> + }
>> +
>> + if (strncmp(sname, LGPU_LIMITS_NAME_LIST, 256) == 0) {
>> + rc = bitmap_parselist(sval, tmp_bitmap,
>> + MAX_DRMCG_LGPU_CAPACITY);
>> +
>> + if (rc) {
>> + drmcg_pr_cft_err(drmcg, rc, cft_name,
>> + minor);
>> + continue;
>> + }
>> +
>> + bitmap_andnot(chk_bitmap, tmp_bitmap,
>> + props->lgpu_slots,
>> + MAX_DRMCG_LGPU_CAPACITY);
>> +
>> + /* user setting does not intersect with
>> + * available lgpu */
>> + if (!bitmap_empty(chk_bitmap,
>> + MAX_DRMCG_LGPU_CAPACITY)) {
>> + drmcg_pr_cft_err(drmcg, 0, cft_name,
>> + minor);
>> + continue;
>> + }
>> + }
>> +
>> + bitmap_copy(ddr->lgpu_cfg, tmp_bitmap,
>> + props->lgpu_capacity);
>> +
>> + break; /* DRMCG_TYPE_LGPU */
>> + default:
>> + break;
>> + } /* switch (type) */
>> + }
>> +}
>> +
>> +
>> /**
>> * drmcg_limit_write - parse cgroup interface files to obtain user config
>> *
>> @@ -499,9 +771,15 @@ static ssize_t drmcg_limit_write(struct kernfs_open_file *of, char *buf,
>>
>> ddr->bo_limits_peak_allocated = val;
>> break;
>> + case DRMCG_TYPE_LGPU:
>> + drmcg_nested_limit_parse(of, dm->dev, sattr);
>> + break;
>> default:
>> break;
>> }
>> +
>> + drmcg_apply_effective(type, dm->dev, drmcg);
>> +
>> mutex_unlock(&dm->dev->drmcg_mutex);
>>
>> mutex_lock(&drmcg_mutex);
>> @@ -560,12 +838,51 @@ struct cftype files[] = {
>> .private = DRMCG_CTF_PRIV(DRMCG_TYPE_BO_COUNT,
>> DRMCG_FTYPE_STATS),
>> },
>> + {
>> + .name = "lgpu",
>> + .seq_show = drmcg_seq_show,
>> + .write = drmcg_limit_write,
>> + .private = DRMCG_CTF_PRIV(DRMCG_TYPE_LGPU,
>> + DRMCG_FTYPE_LIMIT),
>> + },
>> + {
>> + .name = "lgpu.default",
>> + .seq_show = drmcg_seq_show,
>> + .flags = CFTYPE_ONLY_ON_ROOT,
>> + .private = DRMCG_CTF_PRIV(DRMCG_TYPE_LGPU,
>> + DRMCG_FTYPE_DEFAULT),
>> + },
>> + {
>> + .name = "lgpu.effective",
>> + .seq_show = drmcg_seq_show,
>> + .private = DRMCG_CTF_PRIV(DRMCG_TYPE_LGPU_EFF,
>> + DRMCG_FTYPE_LIMIT),
>> + },
>> { } /* terminate */
>> };
>>
>> +static int drmcg_online_fn(int id, void *ptr, void *data)
>> +{
>> + struct drm_minor *minor = ptr;
>> + struct drmcg *drmcg = data;
>> +
>> + if (minor->type != DRM_MINOR_PRIMARY)
>> + return 0;
>> +
>> + drmcg_apply_effective(DRMCG_TYPE_LGPU, minor->dev, drmcg);
>> +
>> + return 0;
>> +}
>> +
>> +static int drmcg_css_online(struct cgroup_subsys_state *css)
>> +{
>> + return drm_minor_for_each(&drmcg_online_fn, css_to_drmcg(css));
>> +}
>> +
>> struct cgroup_subsys drm_cgrp_subsys = {
>> .css_alloc = drmcg_css_alloc,
>> .css_free = drmcg_css_free,
>> + .css_online = drmcg_css_online,
>> .early_init = false,
>> .legacy_cftypes = files,
>> .dfl_cftypes = files,
>> @@ -585,6 +902,9 @@ void drmcg_device_early_init(struct drm_device *dev)
>> dev->drmcg_props.bo_limits_total_allocated_default = S64_MAX;
>> dev->drmcg_props.bo_limits_peak_allocated_default = S64_MAX;
>>
>> + dev->drmcg_props.lgpu_capacity = MAX_DRMCG_LGPU_CAPACITY;
>> + bitmap_fill(dev->drmcg_props.lgpu_slots, MAX_DRMCG_LGPU_CAPACITY);
>> +
>> drmcg_update_cg_tree(dev);
>> }
>> EXPORT_SYMBOL(drmcg_device_early_init);
>> --
>> 2.25.0
>>
>> _______________________________________________
>> dri-devel mailing list
>> dri-devel@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/dri-devel
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: [PATCH v7 01/13] dt-bindings: arm: move mmsys description to display
From: CK Hu @ 2020-02-14 16:22 UTC (permalink / raw)
To: Enric Balletbo i Serra, Matthias Brugger
Cc: mark.rutland, airlied, mturquette, dri-devel, laurent.pinchart,
ulrich.hecht+renesas, linux-clk, drinkcat, Weiyi Lu, wens,
mtk01761, linux-media, devicetree, Daniel Vetter, frank-w,
sean.wang, robh+dt, linux-mediatek, hsinyi, linux-arm-kernel,
Matthias Brugger, sboyd, rdunlap, linux-kernel, p.zabel,
matthias.bgg
In-Reply-To: <022e8f64-b414-67a5-722e-bdd7c00230ff@collabora.com>
Hi, Matthias & Enric:
On Fri, 2020-02-14 at 13:19 +0100, Enric Balletbo i Serra wrote:
> Hi CK,
>
> On 14/2/20 11:01, Matthias Brugger wrote:
> >
> >
> > On 14/02/2020 07:42, CK Hu wrote:
> >> Hi, Matthias:
> >>
> >> On Thu, 2020-02-13 at 21:19 +0100, matthias.bgg@kernel.org wrote:
> >>> From: Matthias Brugger <mbrugger@suse.com>
> >>>
> >>> The mmsys block provides registers and clocks for the display
> >>> subsystem. The binding description should therefore live together with
> >>> the rest of the display descriptions. Move it to display/mediatek.
> >>>
> >>
> >> Yes, for the upstreamed driver, only display (DRM) use mmsys clock. For
> >> some MDP patches [1] in progress, MDP also use mmsys clock. So we just
> >> consider what's upstreamed now?
> >
>
> Let me jump into the discussion, and sorry if my question is silly because I'm
> just starting to look at this code.
>
> IMO we should consider all the cases to find a proper fix on all this, and if
> MDP uses also mmsys clocks this approach will not work. I think the main problem
> here and the big question is what exactly is the MMSYS block, is an independent
> clock controller that provides clocks to DRM and other blocks? or is hardly tied
> to the DRM block in some way?
>
> Could you give us a block schema on how the things are interconnected?
>
> If is an independent clock controller I think there was a mistake when the first
> drm driver was pushed by using the compatible = "mediatek,mt8173-mmsys" as id
> for that driver.
>
I correct my mistake first. In mt8173, mdp has already upstreamed [1].
There are many partitions in Mediatek SoC. mmsys is one of these
partition. There are many function blocks in mmsys such as OVL, RDMA,
RSZ, WROT, .... Some data routing between these blocks are fixed but
some are changeable. For application, we group them into display path
and mdp path. Clock gating register of these blocks are in the range of
0x14000000 ~ 0x14000fff. The routing control register of these blocks
are also in the range of 0x14000000 ~ 0x14000fff. So the control
function belong to mmsys partition but not belong to specific function
block would in the register range of 0x14000000 ~ 0x14000fff. I think
there could be two definition of mmsys device. One is that mmsys device
is the whole mmsys partiotion, so OVL, RDMA, ... would be sub device of
it. Another is that mmsys just control register of 0x14000000 ~
0x14000fff, so it's part of mmsys partition like OVL, RDMA, .....
Currently we define mmsys as the latter one. I've no idea how to map
mmsys into current Linux hardware category, but I think it is not just a
display device.
[1]
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm64/boot/dts/mediatek/mt8173.dtsi?h=v5.6-rc1
Regards,
CK
> Thanks,
> Enric
>
>
> > I'm not sure if I understand you correctly. Are you proposing to keep the
> > binding description in arm/mediatek?
> >
> > Regards,
> > Matthias
> >
> >>
> >> [1] https://patchwork.kernel.org/patch/11140747/
> >>
> >> Regards,
> >> CK
> >>
> >>> Signed-off-by: Matthias Brugger <mbrugger@suse.com>
> >>>
> >>> ---
> >>>
> >>> Changes in v7:
> >>> - move the binding description
> >>>
> >>> Changes in v6: None
> >>> Changes in v5: None
> >>> Changes in v4: None
> >>> Changes in v3: None
> >>> Changes in v2: None
> >>>
> >>> .../bindings/{arm => display}/mediatek/mediatek,mmsys.txt | 0
> >>> 1 file changed, 0 insertions(+), 0 deletions(-)
> >>> rename Documentation/devicetree/bindings/{arm => display}/mediatek/mediatek,mmsys.txt (100%)
> >>>
> >>> diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.txt b/Documentation/devicetree/bindings/display/mediatek/mediatek,mmsys.txt
> >>> similarity index 100%
> >>> rename from Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.txt
> >>> rename to Documentation/devicetree/bindings/display/mediatek/mediatek,mmsys.txt
> >>
> >> _______________________________________________
> >> linux-arm-kernel mailing list
> >> linux-arm-kernel@lists.infradead.org
> >> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> >>
>
> _______________________________________________
> Linux-mediatek mailing list
> Linux-mediatek@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-mediatek
_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek
^ permalink raw reply
* Re: [PATCH v7 01/13] dt-bindings: arm: move mmsys description to display
From: CK Hu @ 2020-02-14 16:22 UTC (permalink / raw)
To: Enric Balletbo i Serra, Matthias Brugger
Cc: mark.rutland, airlied, mturquette, dri-devel, laurent.pinchart,
ulrich.hecht+renesas, linux-clk, drinkcat, Weiyi Lu, wens,
mtk01761, linux-media, devicetree, Daniel Vetter, frank-w,
sean.wang, robh+dt, linux-mediatek, hsinyi, linux-arm-kernel,
Matthias Brugger, sboyd, rdunlap, linux-kernel, p.zabel,
matthias.bgg
In-Reply-To: <022e8f64-b414-67a5-722e-bdd7c00230ff@collabora.com>
Hi, Matthias & Enric:
On Fri, 2020-02-14 at 13:19 +0100, Enric Balletbo i Serra wrote:
> Hi CK,
>
> On 14/2/20 11:01, Matthias Brugger wrote:
> >
> >
> > On 14/02/2020 07:42, CK Hu wrote:
> >> Hi, Matthias:
> >>
> >> On Thu, 2020-02-13 at 21:19 +0100, matthias.bgg@kernel.org wrote:
> >>> From: Matthias Brugger <mbrugger@suse.com>
> >>>
> >>> The mmsys block provides registers and clocks for the display
> >>> subsystem. The binding description should therefore live together with
> >>> the rest of the display descriptions. Move it to display/mediatek.
> >>>
> >>
> >> Yes, for the upstreamed driver, only display (DRM) use mmsys clock. For
> >> some MDP patches [1] in progress, MDP also use mmsys clock. So we just
> >> consider what's upstreamed now?
> >
>
> Let me jump into the discussion, and sorry if my question is silly because I'm
> just starting to look at this code.
>
> IMO we should consider all the cases to find a proper fix on all this, and if
> MDP uses also mmsys clocks this approach will not work. I think the main problem
> here and the big question is what exactly is the MMSYS block, is an independent
> clock controller that provides clocks to DRM and other blocks? or is hardly tied
> to the DRM block in some way?
>
> Could you give us a block schema on how the things are interconnected?
>
> If is an independent clock controller I think there was a mistake when the first
> drm driver was pushed by using the compatible = "mediatek,mt8173-mmsys" as id
> for that driver.
>
I correct my mistake first. In mt8173, mdp has already upstreamed [1].
There are many partitions in Mediatek SoC. mmsys is one of these
partition. There are many function blocks in mmsys such as OVL, RDMA,
RSZ, WROT, .... Some data routing between these blocks are fixed but
some are changeable. For application, we group them into display path
and mdp path. Clock gating register of these blocks are in the range of
0x14000000 ~ 0x14000fff. The routing control register of these blocks
are also in the range of 0x14000000 ~ 0x14000fff. So the control
function belong to mmsys partition but not belong to specific function
block would in the register range of 0x14000000 ~ 0x14000fff. I think
there could be two definition of mmsys device. One is that mmsys device
is the whole mmsys partiotion, so OVL, RDMA, ... would be sub device of
it. Another is that mmsys just control register of 0x14000000 ~
0x14000fff, so it's part of mmsys partition like OVL, RDMA, .....
Currently we define mmsys as the latter one. I've no idea how to map
mmsys into current Linux hardware category, but I think it is not just a
display device.
[1]
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm64/boot/dts/mediatek/mt8173.dtsi?h=v5.6-rc1
Regards,
CK
> Thanks,
> Enric
>
>
> > I'm not sure if I understand you correctly. Are you proposing to keep the
> > binding description in arm/mediatek?
> >
> > Regards,
> > Matthias
> >
> >>
> >> [1] https://patchwork.kernel.org/patch/11140747/
> >>
> >> Regards,
> >> CK
> >>
> >>> Signed-off-by: Matthias Brugger <mbrugger@suse.com>
> >>>
> >>> ---
> >>>
> >>> Changes in v7:
> >>> - move the binding description
> >>>
> >>> Changes in v6: None
> >>> Changes in v5: None
> >>> Changes in v4: None
> >>> Changes in v3: None
> >>> Changes in v2: None
> >>>
> >>> .../bindings/{arm => display}/mediatek/mediatek,mmsys.txt | 0
> >>> 1 file changed, 0 insertions(+), 0 deletions(-)
> >>> rename Documentation/devicetree/bindings/{arm => display}/mediatek/mediatek,mmsys.txt (100%)
> >>>
> >>> diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.txt b/Documentation/devicetree/bindings/display/mediatek/mediatek,mmsys.txt
> >>> similarity index 100%
> >>> rename from Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.txt
> >>> rename to Documentation/devicetree/bindings/display/mediatek/mediatek,mmsys.txt
> >>
> >> _______________________________________________
> >> linux-arm-kernel mailing list
> >> linux-arm-kernel@lists.infradead.org
> >> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> >>
>
> _______________________________________________
> Linux-mediatek mailing list
> Linux-mediatek@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-mediatek
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH AUTOSEL 4.19 242/252] iwlwifi: mvm: Fix thermal zone registration
From: Sasha Levin @ 2020-02-14 16:11 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Andrei Otcheretianski, Luca Coelho, Kalle Valo, Sasha Levin,
linux-wireless, netdev
In-Reply-To: <20200214161147.15842-1-sashal@kernel.org>
From: Andrei Otcheretianski <andrei.otcheretianski@intel.com>
[ Upstream commit baa6cf8450b72dcab11f37c47efce7c5b9b8ad0f ]
Use a unique name when registering a thermal zone. Otherwise, with
multiple NICS, we hit the following warning during the unregistration.
WARNING: CPU: 2 PID: 3525 at fs/sysfs/group.c:255
RIP: 0010:sysfs_remove_group+0x80/0x90
Call Trace:
dpm_sysfs_remove+0x57/0x60
device_del+0x5a/0x350
? sscanf+0x4e/0x70
device_unregister+0x1a/0x60
hwmon_device_unregister+0x4a/0xa0
thermal_remove_hwmon_sysfs+0x175/0x1d0
thermal_zone_device_unregister+0x188/0x1e0
iwl_mvm_thermal_exit+0xe7/0x100 [iwlmvm]
iwl_op_mode_mvm_stop+0x27/0x180 [iwlmvm]
_iwl_op_mode_stop.isra.3+0x2b/0x50 [iwlwifi]
iwl_opmode_deregister+0x90/0xa0 [iwlwifi]
__exit_compat+0x10/0x2c7 [iwlmvm]
__x64_sys_delete_module+0x13f/0x270
do_syscall_64+0x5a/0x110
entry_SYSCALL_64_after_hwframe+0x44/0xa9
Signed-off-by: Andrei Otcheretianski <andrei.otcheretianski@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/net/wireless/intel/iwlwifi/mvm/tt.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/intel/iwlwifi/mvm/tt.c b/drivers/net/wireless/intel/iwlwifi/mvm/tt.c
index 1232f63278eb6..319103f4b432e 100644
--- a/drivers/net/wireless/intel/iwlwifi/mvm/tt.c
+++ b/drivers/net/wireless/intel/iwlwifi/mvm/tt.c
@@ -739,7 +739,8 @@ static struct thermal_zone_device_ops tzone_ops = {
static void iwl_mvm_thermal_zone_register(struct iwl_mvm *mvm)
{
int i;
- char name[] = "iwlwifi";
+ char name[16];
+ static atomic_t counter = ATOMIC_INIT(0);
if (!iwl_mvm_is_tt_in_fw(mvm)) {
mvm->tz_device.tzone = NULL;
@@ -749,6 +750,7 @@ static void iwl_mvm_thermal_zone_register(struct iwl_mvm *mvm)
BUILD_BUG_ON(ARRAY_SIZE(name) >= THERMAL_NAME_LENGTH);
+ sprintf(name, "iwlwifi_%u", atomic_inc_return(&counter) & 0xFF);
mvm->tz_device.tzone = thermal_zone_device_register(name,
IWL_MAX_DTS_TRIPS,
IWL_WRITABLE_TRIPS_MSK,
--
2.20.1
^ permalink raw reply related
* Re: [PATCH] kvm/emulate: fix a -Werror=cast-function-type
From: Sean Christopherson @ 2020-02-14 16:59 UTC (permalink / raw)
To: Qian Cai; +Cc: pbonzini, vkuznets, wanpengli, jmattson, joro, kvm, linux-kernel
In-Reply-To: <1581695768-6123-1-git-send-email-cai@lca.pw>
On Fri, Feb 14, 2020 at 10:56:08AM -0500, Qian Cai wrote:
> arch/x86/kvm/emulate.c: In function 'x86_emulate_insn':
> arch/x86/kvm/emulate.c:5686:22: error: cast between incompatible
> function types from 'int (*)(struct x86_emulate_ctxt *)' to 'void
> (*)(struct fastop *)' [-Werror=cast-function-type]
> rc = fastop(ctxt, (fastop_t)ctxt->execute);
>
> Fixes: 3009afc6e39e ("KVM: x86: Use a typedef for fastop functions")
> Signed-off-by: Qian Cai <cai@lca.pw>
> ---
> arch/x86/kvm/emulate.c | 8 +++++---
> 1 file changed, 5 insertions(+), 3 deletions(-)
>
> diff --git a/arch/x86/kvm/emulate.c b/arch/x86/kvm/emulate.c
> index ddbc61984227..17ae820cf59d 100644
> --- a/arch/x86/kvm/emulate.c
> +++ b/arch/x86/kvm/emulate.c
> @@ -5682,10 +5682,12 @@ int x86_emulate_insn(struct x86_emulate_ctxt *ctxt)
> ctxt->eflags &= ~X86_EFLAGS_RF;
>
> if (ctxt->execute) {
> - if (ctxt->d & Fastop)
> - rc = fastop(ctxt, (fastop_t)ctxt->execute);
Alternatively, can we do -Wno-cast-function-type? That's a silly warning
IMO.
If not, will either of these work?
rc = fastop(ctxt, (void *)ctxt->execute);
or
rc = fastop(ctxt, (fastop_t)(void *)ctxt->execute);
> - else
> + if (ctxt->d & Fastop) {
> + fastop_t fop = (void *)ctxt->execute;
> + rc = fastop(ctxt, fop);
> + } else {
> rc = ctxt->execute(ctxt);
> + }
> if (rc != X86EMUL_CONTINUE)
> goto done;
> goto writeback;
> --
> 1.8.3.1
>
^ permalink raw reply
* [PATCH AUTOSEL 4.19 198/252] remoteproc: Initialize rproc_class before use
From: Sasha Levin @ 2020-02-14 16:10 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Brandon Maier, Bjorn Andersson, Sasha Levin, linux-remoteproc
In-Reply-To: <20200214161147.15842-1-sashal@kernel.org>
From: Brandon Maier <brandon.maier@rockwellcollins.com>
[ Upstream commit a8f40111d184098cd2b3dc0c7170c42250a5fa09 ]
The remoteproc_core and remoteproc drivers all initialize with module_init().
However remoteproc drivers need the rproc_class during their probe. If one of
the remoteproc drivers runs init and gets through probe before
remoteproc_init() runs, a NULL pointer access of rproc_class's `glue_dirs`
spinlock occurs.
> Unable to handle kernel NULL pointer dereference at virtual address 000000dc
> pgd = c0004000
> [000000dc] *pgd=00000000
> Internal error: Oops: 5 [#1] PREEMPT ARM
> Modules linked in:
> CPU: 0 PID: 1 Comm: swapper Tainted: G W 4.14.106-rt56 #1
> Hardware name: Generic OMAP36xx (Flattened Device Tree)
> task: c6050000 task.stack: c604a000
> PC is at rt_spin_lock+0x40/0x6c
> LR is at rt_spin_lock+0x28/0x6c
> pc : [<c0523c90>] lr : [<c0523c78>] psr: 60000013
> sp : c604bdc0 ip : 00000000 fp : 00000000
> r10: 00000000 r9 : c61c7c10 r8 : c6269c20
> r7 : c0905888 r6 : c6269c20 r5 : 00000000 r4 : 000000d4
> r3 : 000000dc r2 : c6050000 r1 : 00000002 r0 : 000000d4
> Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none
...
> [<c0523c90>] (rt_spin_lock) from [<c03b65a4>] (get_device_parent+0x54/0x17c)
> [<c03b65a4>] (get_device_parent) from [<c03b6bec>] (device_add+0xe0/0x5b4)
> [<c03b6bec>] (device_add) from [<c042adf4>] (rproc_add+0x18/0xd8)
> [<c042adf4>] (rproc_add) from [<c01110e4>] (my_rproc_probe+0x158/0x204)
> [<c01110e4>] (my_rproc_probe) from [<c03bb6b8>] (platform_drv_probe+0x34/0x70)
> [<c03bb6b8>] (platform_drv_probe) from [<c03b9dd4>] (driver_probe_device+0x2c8/0x420)
> [<c03b9dd4>] (driver_probe_device) from [<c03ba02c>] (__driver_attach+0x100/0x11c)
> [<c03ba02c>] (__driver_attach) from [<c03b7d08>] (bus_for_each_dev+0x7c/0xc0)
> [<c03b7d08>] (bus_for_each_dev) from [<c03b910c>] (bus_add_driver+0x1cc/0x264)
> [<c03b910c>] (bus_add_driver) from [<c03ba714>] (driver_register+0x78/0xf8)
> [<c03ba714>] (driver_register) from [<c010181c>] (do_one_initcall+0x100/0x190)
> [<c010181c>] (do_one_initcall) from [<c0800de8>] (kernel_init_freeable+0x130/0x1d0)
> [<c0800de8>] (kernel_init_freeable) from [<c051eee8>] (kernel_init+0x8/0x114)
> [<c051eee8>] (kernel_init) from [<c01175b0>] (ret_from_fork+0x14/0x24)
> Code: e2843008 e3c2203f f5d3f000 e5922010 (e193cf9f)
> ---[ end trace 0000000000000002 ]---
Signed-off-by: Brandon Maier <brandon.maier@rockwellcollins.com>
Link: https://lore.kernel.org/r/20190530225223.136420-1-brandon.maier@rockwellcollins.com
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/remoteproc/remoteproc_core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/remoteproc/remoteproc_core.c b/drivers/remoteproc/remoteproc_core.c
index aa6206706fe33..abbef17c97ee2 100644
--- a/drivers/remoteproc/remoteproc_core.c
+++ b/drivers/remoteproc/remoteproc_core.c
@@ -1786,7 +1786,7 @@ static int __init remoteproc_init(void)
return 0;
}
-module_init(remoteproc_init);
+subsys_initcall(remoteproc_init);
static void __exit remoteproc_exit(void)
{
--
2.20.1
^ permalink raw reply related
* [PATCH AUTOSEL 4.19 244/252] brd: check and limit max_part par
From: Sasha Levin @ 2020-02-14 16:11 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Zhiqiang Liu, Bob Liu, Ming Lei, Jens Axboe, Sasha Levin,
linux-block
In-Reply-To: <20200214161147.15842-1-sashal@kernel.org>
From: Zhiqiang Liu <liuzhiqiang26@huawei.com>
[ Upstream commit c8ab422553c81a0eb070329c63725df1cd1425bc ]
In brd_init func, rd_nr num of brd_device are firstly allocated
and add in brd_devices, then brd_devices are traversed to add each
brd_device by calling add_disk func. When allocating brd_device,
the disk->first_minor is set to i * max_part, if rd_nr * max_part
is larger than MINORMASK, two different brd_device may have the same
devt, then only one of them can be successfully added.
when rmmod brd.ko, it will cause oops when calling brd_exit.
Follow those steps:
# modprobe brd rd_nr=3 rd_size=102400 max_part=1048576
# rmmod brd
then, the oops will appear.
Oops log:
[ 726.613722] Call trace:
[ 726.614175] kernfs_find_ns+0x24/0x130
[ 726.614852] kernfs_find_and_get_ns+0x44/0x68
[ 726.615749] sysfs_remove_group+0x38/0xb0
[ 726.616520] blk_trace_remove_sysfs+0x1c/0x28
[ 726.617320] blk_unregister_queue+0x98/0x100
[ 726.618105] del_gendisk+0x144/0x2b8
[ 726.618759] brd_exit+0x68/0x560 [brd]
[ 726.619501] __arm64_sys_delete_module+0x19c/0x2a0
[ 726.620384] el0_svc_common+0x78/0x130
[ 726.621057] el0_svc_handler+0x38/0x78
[ 726.621738] el0_svc+0x8/0xc
[ 726.622259] Code: aa0203f6 aa0103f7 aa1e03e0 d503201f (7940e260)
Here, we add brd_check_and_reset_par func to check and limit max_part par.
--
V5->V6:
- remove useless code
V4->V5:(suggested by Ming Lei)
- make sure max_part is not larger than DISK_MAX_PARTS
V3->V4:(suggested by Ming Lei)
- remove useless change
- add one limit of max_part
V2->V3: (suggested by Ming Lei)
- clear .minors when running out of consecutive minor space in brd_alloc
- remove limit of rd_nr
V1->V2:
- add more checks in brd_check_par_valid as suggested by Ming Lei.
Signed-off-by: Zhiqiang Liu <liuzhiqiang26@huawei.com>
Reviewed-by: Bob Liu <bob.liu@oracle.com>
Reviewed-by: Ming Lei <ming.lei@redhat.com>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/block/brd.c | 22 ++++++++++++++++++++--
1 file changed, 20 insertions(+), 2 deletions(-)
diff --git a/drivers/block/brd.c b/drivers/block/brd.c
index 17defbf4f332c..02e8fff3f8283 100644
--- a/drivers/block/brd.c
+++ b/drivers/block/brd.c
@@ -463,6 +463,25 @@ static struct kobject *brd_probe(dev_t dev, int *part, void *data)
return kobj;
}
+static inline void brd_check_and_reset_par(void)
+{
+ if (unlikely(!max_part))
+ max_part = 1;
+
+ /*
+ * make sure 'max_part' can be divided exactly by (1U << MINORBITS),
+ * otherwise, it is possiable to get same dev_t when adding partitions.
+ */
+ if ((1U << MINORBITS) % max_part != 0)
+ max_part = 1UL << fls(max_part);
+
+ if (max_part > DISK_MAX_PARTS) {
+ pr_info("brd: max_part can't be larger than %d, reset max_part = %d.\n",
+ DISK_MAX_PARTS, DISK_MAX_PARTS);
+ max_part = DISK_MAX_PARTS;
+ }
+}
+
static int __init brd_init(void)
{
struct brd_device *brd, *next;
@@ -486,8 +505,7 @@ static int __init brd_init(void)
if (register_blkdev(RAMDISK_MAJOR, "ramdisk"))
return -EIO;
- if (unlikely(!max_part))
- max_part = 1;
+ brd_check_and_reset_par();
for (i = 0; i < rd_nr; i++) {
brd = brd_alloc(i);
--
2.20.1
^ permalink raw reply related
* Re: [PATCH 09/11] drm, cgroup: Introduce lgpu as DRM cgroup resource
From: Jason Ekstrand @ 2020-02-14 16:59 UTC (permalink / raw)
To: Kenny Ho
Cc: juan.zuniga-anaya-5C7GfCeVMHo, Daniel Vetter,
felix.kuehling-5C7GfCeVMHo, jsparks-WVYJKLFxKCc,
amd-gfx mailing list, lkaplan-WVYJKLFxKCc,
alexander.deucher-5C7GfCeVMHo, nirmoy.das-5C7GfCeVMHo,
y2kenny-Re5JQEeQqe8AvxtiuMwx3w, Maling list - DRI developers,
joseph.greathouse-5C7GfCeVMHo, tj-DgEjT+Ai2ygdnm+yROfE0A,
cgroups-u79uwXL29TY76Z2rM5mHXA, Christian König,
damon.mcdougall-5C7GfCeVMHo
In-Reply-To: <CAOFGe96N5gG+08rQCRC+diHKDAfxPFYEnVxDS8_udvjcBYgsPg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Fri, Feb 14, 2020 at 10:44 AM Jason Ekstrand <jason-fQELhIk9awXprZlt/sZkLg@public.gmane.org> wrote:
>
> Pardon my ignorance but I'm a bit confused by this. What is a "logical GPU"? What are we subdividing? Are we carving up memory? Compute power? Both?
>
> If it's carving up memory, why aren't we just measuring it in megabytes?
>
> If it's carving up compute power, what's actually being carved up? Time? Execution units/waves/threads? Even if that's the case, what advantage does it give to have it in terms of a fixed set of lgpus where each cgroup gets to pick a fixed set. Does affinity matter that much? Why not just say how many waves the GPU supports and that they have to be allocated in chunks of 16 waves (pulling a number out of thin air) and let the cgroup specify how many waves it wants.
One more question: If I'm a userspace driver, and there are 14 lgpus
allocated to my cgroup, does that mean I have 14 GPUs? Or does that
mean I have one GPU with 14 units of compute power?
> Don't get me wrong here. I'm all for the notion of being able to use cgroups to carve up GPU compute resources. However, this sounds to me like the most AMD-specific solution possible. We (Intel) could probably do some sort of carving up as well but we'd likely want to do it with preemption and time-slicing rather than handing out specific EUs.
Ok, so "most AMD-specific solution possible" probably wasn't fair.
However, it does seem like an unnecessarily rigid solution to me.
Maybe there's something I'm not getting?
--Jason
> --Jason
>
>
> On Fri, Feb 14, 2020 at 9:57 AM Kenny Ho <Kenny.Ho-5C7GfCeVMHo@public.gmane.org> wrote:
>>
>> drm.lgpu
>> A read-write nested-keyed file which exists on all cgroups.
>> Each entry is keyed by the DRM device's major:minor.
>>
>> lgpu stands for logical GPU, it is an abstraction used to
>> subdivide a physical DRM device for the purpose of resource
>> management. This file stores user configuration while the
>> drm.lgpu.effective reflects the actual allocation after
>> considering the relationship between the cgroups and their
>> configurations.
>>
>> The lgpu is a discrete quantity that is device specific (i.e.
>> some DRM devices may have 64 lgpus while others may have 100
>> lgpus.) The lgpu is a single quantity that can be allocated
>> in three different ways denoted by the following nested keys.
>>
>> ===== ==============================================
>> weight Allocate by proportion in relationship with
>> active sibling cgroups
>> count Allocate by amount statically, treat lgpu as
>> anonymous resources
>> list Allocate statically, treat lgpu as named
>> resource
>> ===== ==============================================
>>
>> For example:
>> 226:0 weight=100 count=256 list=0-255
>> 226:1 weight=100 count=4 list=0,2,4,6
>> 226:2 weight=100 count=32 list=32-63
>> 226:3 weight=100 count=0 list=
>> 226:4 weight=500 count=0 list=
>>
>> lgpu is represented by a bitmap and uses the bitmap_parselist
>> kernel function so the list key input format is a
>> comma-separated list of decimal numbers and ranges.
>>
>> Consecutively set bits are shown as two hyphen-separated decimal
>> numbers, the smallest and largest bit numbers set in the range.
>> Optionally each range can be postfixed to denote that only parts
>> of it should be set. The range will divided to groups of
>> specific size.
>> Syntax: range:used_size/group_size
>> Example: 0-1023:2/256 ==> 0,1,256,257,512,513,768,769
>>
>> The count key is the hamming weight / hweight of the bitmap.
>>
>> Weight, count and list accept the max and default keywords.
>>
>> Some DRM devices may only support lgpu as anonymous resources.
>> In such case, the significance of the position of the set bits
>> in list will be ignored.
>>
>> The weight quantity is only in effect when static allocation
>> is not used (by setting count=0) for this cgroup. The weight
>> quantity distributes lgpus that are not statically allocated by
>> the siblings. For example, given siblings cgroupA, cgroupB and
>> cgroupC for a DRM device that has 64 lgpus, if cgroupA occupies
>> 0-63, no lgpu is available to be distributed by weight.
>> Similarly, if cgroupA has list=0-31 and cgroupB has list=16-63,
>> cgroupC will be starved if it tries to allocate by weight.
>>
>> On the other hand, if cgroupA has weight=100 count=0, cgroupB
>> has list=16-47, and cgroupC has weight=100 count=0, then 32
>> lgpus are available to be distributed evenly between cgroupA
>> and cgroupC. In drm.lgpu.effective, cgroupA will have
>> list=0-15 and cgroupC will have list=48-63.
>>
>> This lgpu resource supports the 'allocation' and 'weight'
>> resource distribution model.
>>
>> drm.lgpu.effective
>> A read-only nested-keyed file which exists on all cgroups.
>> Each entry is keyed by the DRM device's major:minor.
>>
>> lgpu stands for logical GPU, it is an abstraction used to
>> subdivide a physical DRM device for the purpose of resource
>> management. This file reflects the actual allocation after
>> considering the relationship between the cgroups and their
>> configurations in drm.lgpu.
>>
>> Change-Id: Idde0ef9a331fd67bb9c7eb8ef9978439e6452488
>> Signed-off-by: Kenny Ho <Kenny.Ho-5C7GfCeVMHo@public.gmane.org>
>> ---
>> Documentation/admin-guide/cgroup-v2.rst | 80 ++++++
>> include/drm/drm_cgroup.h | 3 +
>> include/linux/cgroup_drm.h | 22 ++
>> kernel/cgroup/drm.c | 324 +++++++++++++++++++++++-
>> 4 files changed, 427 insertions(+), 2 deletions(-)
>>
>> diff --git a/Documentation/admin-guide/cgroup-v2.rst b/Documentation/admin-guide/cgroup-v2.rst
>> index ce5dc027366a..d8a41956e5c7 100644
>> --- a/Documentation/admin-guide/cgroup-v2.rst
>> +++ b/Documentation/admin-guide/cgroup-v2.rst
>> @@ -2120,6 +2120,86 @@ DRM Interface Files
>> Set largest allocation for /dev/dri/card1 to 4MB
>> echo "226:1 4m" > drm.buffer.peak.max
>>
>> + drm.lgpu
>> + A read-write nested-keyed file which exists on all cgroups.
>> + Each entry is keyed by the DRM device's major:minor.
>> +
>> + lgpu stands for logical GPU, it is an abstraction used to
>> + subdivide a physical DRM device for the purpose of resource
>> + management. This file stores user configuration while the
>> + drm.lgpu.effective reflects the actual allocation after
>> + considering the relationship between the cgroups and their
>> + configurations.
>> +
>> + The lgpu is a discrete quantity that is device specific (i.e.
>> + some DRM devices may have 64 lgpus while others may have 100
>> + lgpus.) The lgpu is a single quantity that can be allocated
>> + in three different ways denoted by the following nested keys.
>> +
>> + ===== ==============================================
>> + weight Allocate by proportion in relationship with
>> + active sibling cgroups
>> + count Allocate by amount statically, treat lgpu as
>> + anonymous resources
>> + list Allocate statically, treat lgpu as named
>> + resource
>> + ===== ==============================================
>> +
>> + For example:
>> + 226:0 weight=100 count=256 list=0-255
>> + 226:1 weight=100 count=4 list=0,2,4,6
>> + 226:2 weight=100 count=32 list=32-63
>> + 226:3 weight=100 count=0 list=
>> + 226:4 weight=500 count=0 list=
>> +
>> + lgpu is represented by a bitmap and uses the bitmap_parselist
>> + kernel function so the list key input format is a
>> + comma-separated list of decimal numbers and ranges.
>> +
>> + Consecutively set bits are shown as two hyphen-separated decimal
>> + numbers, the smallest and largest bit numbers set in the range.
>> + Optionally each range can be postfixed to denote that only parts
>> + of it should be set. The range will divided to groups of
>> + specific size.
>> + Syntax: range:used_size/group_size
>> + Example: 0-1023:2/256 ==> 0,1,256,257,512,513,768,769
>> +
>> + The count key is the hamming weight / hweight of the bitmap.
>> +
>> + Weight, count and list accept the max and default keywords.
>> +
>> + Some DRM devices may only support lgpu as anonymous resources.
>> + In such case, the significance of the position of the set bits
>> + in list will be ignored.
>> +
>> + The weight quantity is only in effect when static allocation
>> + is not used (by setting count=0) for this cgroup. The weight
>> + quantity distributes lgpus that are not statically allocated by
>> + the siblings. For example, given siblings cgroupA, cgroupB and
>> + cgroupC for a DRM device that has 64 lgpus, if cgroupA occupies
>> + 0-63, no lgpu is available to be distributed by weight.
>> + Similarly, if cgroupA has list=0-31 and cgroupB has list=16-63,
>> + cgroupC will be starved if it tries to allocate by weight.
>> +
>> + On the other hand, if cgroupA has weight=100 count=0, cgroupB
>> + has list=16-47, and cgroupC has weight=100 count=0, then 32
>> + lgpus are available to be distributed evenly between cgroupA
>> + and cgroupC. In drm.lgpu.effective, cgroupA will have
>> + list=0-15 and cgroupC will have list=48-63.
>> +
>> + This lgpu resource supports the 'allocation' and 'weight'
>> + resource distribution model.
>> +
>> + drm.lgpu.effective
>> + A read-only nested-keyed file which exists on all cgroups.
>> + Each entry is keyed by the DRM device's major:minor.
>> +
>> + lgpu stands for logical GPU, it is an abstraction used to
>> + subdivide a physical DRM device for the purpose of resource
>> + management. This file reflects the actual allocation after
>> + considering the relationship between the cgroups and their
>> + configurations in drm.lgpu.
>> +
>> GEM Buffer Ownership
>> ~~~~~~~~~~~~~~~~~~~~
>>
>> diff --git a/include/drm/drm_cgroup.h b/include/drm/drm_cgroup.h
>> index 2b41d4d22e33..619a110cc748 100644
>> --- a/include/drm/drm_cgroup.h
>> +++ b/include/drm/drm_cgroup.h
>> @@ -17,6 +17,9 @@ struct drmcg_props {
>>
>> s64 bo_limits_total_allocated_default;
>> s64 bo_limits_peak_allocated_default;
>> +
>> + int lgpu_capacity;
>> + DECLARE_BITMAP(lgpu_slots, MAX_DRMCG_LGPU_CAPACITY);
>> };
>>
>> void drmcg_bind(struct drm_minor (*(*acq_dm)(unsigned int minor_id)),
>> diff --git a/include/linux/cgroup_drm.h b/include/linux/cgroup_drm.h
>> index eae400f3d9b4..bb09704e7f71 100644
>> --- a/include/linux/cgroup_drm.h
>> +++ b/include/linux/cgroup_drm.h
>> @@ -11,10 +11,14 @@
>> /* limit defined per the way drm_minor_alloc operates */
>> #define MAX_DRM_DEV (64 * DRM_MINOR_RENDER)
>>
>> +#define MAX_DRMCG_LGPU_CAPACITY 256
>> +
>> enum drmcg_res_type {
>> DRMCG_TYPE_BO_TOTAL,
>> DRMCG_TYPE_BO_PEAK,
>> DRMCG_TYPE_BO_COUNT,
>> + DRMCG_TYPE_LGPU,
>> + DRMCG_TYPE_LGPU_EFF,
>> __DRMCG_TYPE_LAST,
>> };
>>
>> @@ -32,6 +36,24 @@ struct drmcg_device_resource {
>> s64 bo_limits_peak_allocated;
>>
>> s64 bo_stats_count_allocated;
>> +
>> + /**
>> + * Logical GPU
>> + *
>> + * *_cfg are properties configured by users
>> + * *_eff are the effective properties being applied to the hardware
>> + * *_stg is used to calculate _eff before applying to _eff
>> + * after considering the entire hierarchy
>> + */
>> + DECLARE_BITMAP(lgpu_stg, MAX_DRMCG_LGPU_CAPACITY);
>> + /* user configurations */
>> + s64 lgpu_weight_cfg;
>> + DECLARE_BITMAP(lgpu_cfg, MAX_DRMCG_LGPU_CAPACITY);
>> + /* effective lgpu for the cgroup after considering
>> + * relationship with other cgroup
>> + */
>> + s64 lgpu_count_eff;
>> + DECLARE_BITMAP(lgpu_eff, MAX_DRMCG_LGPU_CAPACITY);
>> };
>>
>> /**
>> diff --git a/kernel/cgroup/drm.c b/kernel/cgroup/drm.c
>> index 5fcbbc13fa1c..a4e88a3704bb 100644
>> --- a/kernel/cgroup/drm.c
>> +++ b/kernel/cgroup/drm.c
>> @@ -9,6 +9,7 @@
>> #include <linux/seq_file.h>
>> #include <linux/mutex.h>
>> #include <linux/kernel.h>
>> +#include <linux/bitmap.h>
>> #include <linux/cgroup_drm.h>
>> #include <drm/drm_file.h>
>> #include <drm/drm_drv.h>
>> @@ -41,6 +42,10 @@ enum drmcg_file_type {
>> DRMCG_FTYPE_DEFAULT,
>> };
>>
>> +#define LGPU_LIMITS_NAME_LIST "list"
>> +#define LGPU_LIMITS_NAME_COUNT "count"
>> +#define LGPU_LIMITS_NAME_WEIGHT "weight"
>> +
>> /**
>> * drmcg_bind - Bind DRM subsystem to cgroup subsystem
>> * @acq_dm: function pointer to the drm_minor_acquire function
>> @@ -98,6 +103,13 @@ static inline int init_drmcg_single(struct drmcg *drmcg, struct drm_device *dev)
>> ddr->bo_limits_peak_allocated =
>> dev->drmcg_props.bo_limits_peak_allocated_default;
>>
>> + bitmap_copy(ddr->lgpu_cfg, dev->drmcg_props.lgpu_slots,
>> + MAX_DRMCG_LGPU_CAPACITY);
>> + bitmap_copy(ddr->lgpu_stg, dev->drmcg_props.lgpu_slots,
>> + MAX_DRMCG_LGPU_CAPACITY);
>> +
>> + ddr->lgpu_weight_cfg = CGROUP_WEIGHT_DFL;
>> +
>> return 0;
>> }
>>
>> @@ -121,6 +133,120 @@ static inline void drmcg_update_cg_tree(struct drm_device *dev)
>> mutex_unlock(&cgroup_mutex);
>> }
>>
>> +static void drmcg_calculate_effective_lgpu(struct drm_device *dev,
>> + const unsigned long *free_static,
>> + const unsigned long *free_weighted,
>> + struct drmcg *parent_drmcg)
>> +{
>> + int capacity = dev->drmcg_props.lgpu_capacity;
>> + DECLARE_BITMAP(lgpu_unused, MAX_DRMCG_LGPU_CAPACITY);
>> + DECLARE_BITMAP(lgpu_by_weight, MAX_DRMCG_LGPU_CAPACITY);
>> + struct drmcg_device_resource *parent_ddr;
>> + struct drmcg_device_resource *ddr;
>> + int minor = dev->primary->index;
>> + struct cgroup_subsys_state *pos;
>> + struct drmcg *child;
>> + s64 weight_sum = 0;
>> + s64 unused;
>> +
>> + parent_ddr = parent_drmcg->dev_resources[minor];
>> +
>> + if (bitmap_empty(parent_ddr->lgpu_cfg, capacity))
>> + /* no static cfg, use weight for calculating the effective */
>> + bitmap_copy(parent_ddr->lgpu_stg, free_weighted, capacity);
>> + else
>> + /* lgpu statically configured, use the overlap as effective */
>> + bitmap_and(parent_ddr->lgpu_stg, free_static,
>> + parent_ddr->lgpu_cfg, capacity);
>> +
>> + /* calculate lgpu available for distribution by weight for children */
>> + bitmap_copy(lgpu_unused, parent_ddr->lgpu_stg, capacity);
>> + css_for_each_child(pos, &parent_drmcg->css) {
>> + child = css_to_drmcg(pos);
>> + ddr = child->dev_resources[minor];
>> +
>> + if (bitmap_empty(ddr->lgpu_cfg, capacity))
>> + /* no static allocation, participate in weight dist */
>> + weight_sum += ddr->lgpu_weight_cfg;
>> + else
>> + /* take out statically allocated lgpu by siblings */
>> + bitmap_andnot(lgpu_unused, lgpu_unused, ddr->lgpu_cfg,
>> + capacity);
>> + }
>> +
>> + unused = bitmap_weight(lgpu_unused, capacity);
>> +
>> + css_for_each_child(pos, &parent_drmcg->css) {
>> + child = css_to_drmcg(pos);
>> + ddr = child->dev_resources[minor];
>> +
>> + bitmap_zero(lgpu_by_weight, capacity);
>> + /* no static allocation, participate in weight distribution */
>> + if (bitmap_empty(ddr->lgpu_cfg, capacity)) {
>> + int c;
>> + int p = 0;
>> +
>> + for (c = ddr->lgpu_weight_cfg * unused / weight_sum;
>> + c > 0; c--) {
>> + p = find_next_bit(lgpu_unused, capacity, p);
>> + if (p < capacity) {
>> + clear_bit(p, lgpu_unused);
>> + set_bit(p, lgpu_by_weight);
>> + }
>> + }
>> +
>> + }
>> +
>> + drmcg_calculate_effective_lgpu(dev, parent_ddr->lgpu_stg,
>> + lgpu_by_weight, child);
>> + }
>> +}
>> +
>> +static void drmcg_apply_effective_lgpu(struct drm_device *dev)
>> +{
>> + int capacity = dev->drmcg_props.lgpu_capacity;
>> + int minor = dev->primary->index;
>> + struct drmcg_device_resource *ddr;
>> + struct cgroup_subsys_state *pos;
>> + struct drmcg *drmcg;
>> +
>> + if (root_drmcg == NULL) {
>> + WARN_ON(root_drmcg == NULL);
>> + return;
>> + }
>> +
>> + rcu_read_lock();
>> +
>> + /* process the entire cgroup tree from root to simplify the algorithm */
>> + drmcg_calculate_effective_lgpu(dev, dev->drmcg_props.lgpu_slots,
>> + dev->drmcg_props.lgpu_slots, root_drmcg);
>> +
>> + /* apply changes to effective only if there is a change */
>> + css_for_each_descendant_pre(pos, &root_drmcg->css) {
>> + drmcg = css_to_drmcg(pos);
>> + ddr = drmcg->dev_resources[minor];
>> +
>> + if (!bitmap_equal(ddr->lgpu_stg, ddr->lgpu_eff, capacity)) {
>> + bitmap_copy(ddr->lgpu_eff, ddr->lgpu_stg, capacity);
>> + ddr->lgpu_count_eff =
>> + bitmap_weight(ddr->lgpu_eff, capacity);
>> + }
>> + }
>> + rcu_read_unlock();
>> +}
>> +
>> +static void drmcg_apply_effective(enum drmcg_res_type type,
>> + struct drm_device *dev, struct drmcg *changed_drmcg)
>> +{
>> + switch (type) {
>> + case DRMCG_TYPE_LGPU:
>> + drmcg_apply_effective_lgpu(dev);
>> + break;
>> + default:
>> + break;
>> + }
>> +}
>> +
>> /**
>> * drmcg_register_dev - register a DRM device for usage in drm cgroup
>> * @dev: DRM device
>> @@ -143,7 +269,13 @@ void drmcg_register_dev(struct drm_device *dev)
>> {
>> dev->driver->drmcg_custom_init(dev, &dev->drmcg_props);
>>
>> + WARN_ON(dev->drmcg_props.lgpu_capacity !=
>> + bitmap_weight(dev->drmcg_props.lgpu_slots,
>> + MAX_DRMCG_LGPU_CAPACITY));
>> +
>> drmcg_update_cg_tree(dev);
>> +
>> + drmcg_apply_effective(DRMCG_TYPE_LGPU, dev, root_drmcg);
>> }
>> mutex_unlock(&drmcg_mutex);
>> }
>> @@ -297,7 +429,8 @@ static void drmcg_print_stats(struct drmcg_device_resource *ddr,
>> }
>>
>> static void drmcg_print_limits(struct drmcg_device_resource *ddr,
>> - struct seq_file *sf, enum drmcg_res_type type)
>> + struct seq_file *sf, enum drmcg_res_type type,
>> + struct drm_device *dev)
>> {
>> if (ddr == NULL) {
>> seq_puts(sf, "\n");
>> @@ -311,6 +444,25 @@ static void drmcg_print_limits(struct drmcg_device_resource *ddr,
>> case DRMCG_TYPE_BO_PEAK:
>> seq_printf(sf, "%lld\n", ddr->bo_limits_peak_allocated);
>> break;
>> + case DRMCG_TYPE_LGPU:
>> + seq_printf(sf, "%s=%lld %s=%d %s=%*pbl\n",
>> + LGPU_LIMITS_NAME_WEIGHT,
>> + ddr->lgpu_weight_cfg,
>> + LGPU_LIMITS_NAME_COUNT,
>> + bitmap_weight(ddr->lgpu_cfg,
>> + dev->drmcg_props.lgpu_capacity),
>> + LGPU_LIMITS_NAME_LIST,
>> + dev->drmcg_props.lgpu_capacity,
>> + ddr->lgpu_cfg);
>> + break;
>> + case DRMCG_TYPE_LGPU_EFF:
>> + seq_printf(sf, "%s=%lld %s=%*pbl\n",
>> + LGPU_LIMITS_NAME_COUNT,
>> + ddr->lgpu_count_eff,
>> + LGPU_LIMITS_NAME_LIST,
>> + dev->drmcg_props.lgpu_capacity,
>> + ddr->lgpu_eff);
>> + break;
>> default:
>> seq_puts(sf, "\n");
>> break;
>> @@ -329,6 +481,17 @@ static void drmcg_print_default(struct drmcg_props *props,
>> seq_printf(sf, "%lld\n",
>> props->bo_limits_peak_allocated_default);
>> break;
>> + case DRMCG_TYPE_LGPU:
>> + seq_printf(sf, "%s=%d %s=%d %s=%*pbl\n",
>> + LGPU_LIMITS_NAME_WEIGHT,
>> + CGROUP_WEIGHT_DFL,
>> + LGPU_LIMITS_NAME_COUNT,
>> + bitmap_weight(props->lgpu_slots,
>> + props->lgpu_capacity),
>> + LGPU_LIMITS_NAME_LIST,
>> + props->lgpu_capacity,
>> + props->lgpu_slots);
>> + break;
>> default:
>> seq_puts(sf, "\n");
>> break;
>> @@ -358,7 +521,7 @@ static int drmcg_seq_show_fn(int id, void *ptr, void *data)
>> drmcg_print_stats(ddr, sf, type);
>> break;
>> case DRMCG_FTYPE_LIMIT:
>> - drmcg_print_limits(ddr, sf, type);
>> + drmcg_print_limits(ddr, sf, type, minor->dev);
>> break;
>> case DRMCG_FTYPE_DEFAULT:
>> drmcg_print_default(&minor->dev->drmcg_props, sf, type);
>> @@ -415,6 +578,115 @@ static int drmcg_process_limit_s64_val(char *sval, bool is_mem,
>> return rc;
>> }
>>
>> +static void drmcg_nested_limit_parse(struct kernfs_open_file *of,
>> + struct drm_device *dev, char *attrs)
>> +{
>> + DECLARE_BITMAP(tmp_bitmap, MAX_DRMCG_LGPU_CAPACITY);
>> + DECLARE_BITMAP(chk_bitmap, MAX_DRMCG_LGPU_CAPACITY);
>> + enum drmcg_res_type type =
>> + DRMCG_CTF_PRIV2RESTYPE(of_cft(of)->private);
>> + struct drmcg *drmcg = css_to_drmcg(of_css(of));
>> + struct drmcg_props *props = &dev->drmcg_props;
>> + char *cft_name = of_cft(of)->name;
>> + int minor = dev->primary->index;
>> + char *nested = strstrip(attrs);
>> + struct drmcg_device_resource *ddr =
>> + drmcg->dev_resources[minor];
>> + char *attr;
>> + char sname[256];
>> + char sval[256];
>> + s64 val;
>> + int rc;
>> +
>> + while (nested != NULL) {
>> + attr = strsep(&nested, " ");
>> +
>> + if (sscanf(attr, "%255[^=]=%255[^=]", sname, sval) != 2)
>> + continue;
>> +
>> + switch (type) {
>> + case DRMCG_TYPE_LGPU:
>> + if (strncmp(sname, LGPU_LIMITS_NAME_LIST, 256) &&
>> + strncmp(sname, LGPU_LIMITS_NAME_COUNT, 256) &&
>> + strncmp(sname, LGPU_LIMITS_NAME_WEIGHT, 256))
>> + continue;
>> +
>> + if (strncmp(sname, LGPU_LIMITS_NAME_WEIGHT, 256) &&
>> + (!strcmp("max", sval) ||
>> + !strcmp("default", sval))) {
>> + bitmap_copy(ddr->lgpu_cfg, props->lgpu_slots,
>> + props->lgpu_capacity);
>> +
>> + continue;
>> + }
>> +
>> + if (strncmp(sname, LGPU_LIMITS_NAME_WEIGHT, 256) == 0) {
>> + rc = drmcg_process_limit_s64_val(sval,
>> + false, CGROUP_WEIGHT_DFL,
>> + CGROUP_WEIGHT_MAX, &val);
>> +
>> + if (rc || val < CGROUP_WEIGHT_MIN ||
>> + val > CGROUP_WEIGHT_MAX) {
>> + drmcg_pr_cft_err(drmcg, rc, cft_name,
>> + minor);
>> + continue;
>> + }
>> +
>> + ddr->lgpu_weight_cfg = val;
>> + continue;
>> + }
>> +
>> + if (strncmp(sname, LGPU_LIMITS_NAME_COUNT, 256) == 0) {
>> + rc = drmcg_process_limit_s64_val(sval,
>> + false, props->lgpu_capacity,
>> + props->lgpu_capacity, &val);
>> +
>> + if (rc || val < 0) {
>> + drmcg_pr_cft_err(drmcg, rc, cft_name,
>> + minor);
>> + continue;
>> + }
>> +
>> + bitmap_zero(tmp_bitmap,
>> + MAX_DRMCG_LGPU_CAPACITY);
>> + bitmap_set(tmp_bitmap, 0, val);
>> + }
>> +
>> + if (strncmp(sname, LGPU_LIMITS_NAME_LIST, 256) == 0) {
>> + rc = bitmap_parselist(sval, tmp_bitmap,
>> + MAX_DRMCG_LGPU_CAPACITY);
>> +
>> + if (rc) {
>> + drmcg_pr_cft_err(drmcg, rc, cft_name,
>> + minor);
>> + continue;
>> + }
>> +
>> + bitmap_andnot(chk_bitmap, tmp_bitmap,
>> + props->lgpu_slots,
>> + MAX_DRMCG_LGPU_CAPACITY);
>> +
>> + /* user setting does not intersect with
>> + * available lgpu */
>> + if (!bitmap_empty(chk_bitmap,
>> + MAX_DRMCG_LGPU_CAPACITY)) {
>> + drmcg_pr_cft_err(drmcg, 0, cft_name,
>> + minor);
>> + continue;
>> + }
>> + }
>> +
>> + bitmap_copy(ddr->lgpu_cfg, tmp_bitmap,
>> + props->lgpu_capacity);
>> +
>> + break; /* DRMCG_TYPE_LGPU */
>> + default:
>> + break;
>> + } /* switch (type) */
>> + }
>> +}
>> +
>> +
>> /**
>> * drmcg_limit_write - parse cgroup interface files to obtain user config
>> *
>> @@ -499,9 +771,15 @@ static ssize_t drmcg_limit_write(struct kernfs_open_file *of, char *buf,
>>
>> ddr->bo_limits_peak_allocated = val;
>> break;
>> + case DRMCG_TYPE_LGPU:
>> + drmcg_nested_limit_parse(of, dm->dev, sattr);
>> + break;
>> default:
>> break;
>> }
>> +
>> + drmcg_apply_effective(type, dm->dev, drmcg);
>> +
>> mutex_unlock(&dm->dev->drmcg_mutex);
>>
>> mutex_lock(&drmcg_mutex);
>> @@ -560,12 +838,51 @@ struct cftype files[] = {
>> .private = DRMCG_CTF_PRIV(DRMCG_TYPE_BO_COUNT,
>> DRMCG_FTYPE_STATS),
>> },
>> + {
>> + .name = "lgpu",
>> + .seq_show = drmcg_seq_show,
>> + .write = drmcg_limit_write,
>> + .private = DRMCG_CTF_PRIV(DRMCG_TYPE_LGPU,
>> + DRMCG_FTYPE_LIMIT),
>> + },
>> + {
>> + .name = "lgpu.default",
>> + .seq_show = drmcg_seq_show,
>> + .flags = CFTYPE_ONLY_ON_ROOT,
>> + .private = DRMCG_CTF_PRIV(DRMCG_TYPE_LGPU,
>> + DRMCG_FTYPE_DEFAULT),
>> + },
>> + {
>> + .name = "lgpu.effective",
>> + .seq_show = drmcg_seq_show,
>> + .private = DRMCG_CTF_PRIV(DRMCG_TYPE_LGPU_EFF,
>> + DRMCG_FTYPE_LIMIT),
>> + },
>> { } /* terminate */
>> };
>>
>> +static int drmcg_online_fn(int id, void *ptr, void *data)
>> +{
>> + struct drm_minor *minor = ptr;
>> + struct drmcg *drmcg = data;
>> +
>> + if (minor->type != DRM_MINOR_PRIMARY)
>> + return 0;
>> +
>> + drmcg_apply_effective(DRMCG_TYPE_LGPU, minor->dev, drmcg);
>> +
>> + return 0;
>> +}
>> +
>> +static int drmcg_css_online(struct cgroup_subsys_state *css)
>> +{
>> + return drm_minor_for_each(&drmcg_online_fn, css_to_drmcg(css));
>> +}
>> +
>> struct cgroup_subsys drm_cgrp_subsys = {
>> .css_alloc = drmcg_css_alloc,
>> .css_free = drmcg_css_free,
>> + .css_online = drmcg_css_online,
>> .early_init = false,
>> .legacy_cftypes = files,
>> .dfl_cftypes = files,
>> @@ -585,6 +902,9 @@ void drmcg_device_early_init(struct drm_device *dev)
>> dev->drmcg_props.bo_limits_total_allocated_default = S64_MAX;
>> dev->drmcg_props.bo_limits_peak_allocated_default = S64_MAX;
>>
>> + dev->drmcg_props.lgpu_capacity = MAX_DRMCG_LGPU_CAPACITY;
>> + bitmap_fill(dev->drmcg_props.lgpu_slots, MAX_DRMCG_LGPU_CAPACITY);
>> +
>> drmcg_update_cg_tree(dev);
>> }
>> EXPORT_SYMBOL(drmcg_device_early_init);
>> --
>> 2.25.0
>>
>> _______________________________________________
>> dri-devel mailing list
>> dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org
>> https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: [EXT] Re: [PATCH] bus: fsl-mc: Add ACPI support for fsl-mc
From: Robin Murphy @ 2020-02-14 16:29 UTC (permalink / raw)
To: Pankaj Bansal, Marc Zyngier
Cc: Calvin Johnson, stuyoder@gmail.com, nleeder@codeaurora.org,
Ioana Ciornei, Cristi Sovaiala, Hanjun Guo, Will Deacon,
Lorenzo Pieralisi, jon@solid-run.com, Russell King,
ACPI Devel Maling List, Len Brown, Jason Cooper, Andy Wang,
Makarand Pawagi, Varun Sethi, Thomas Gleixner, linux-arm-kernel,
Laurentiu Tudor, Paul Yang, Ard Biesheuvel,
netdev@vger.kernel.org, Rafael J. Wysocki,
Linux Kernel Mailing List, Shameerali Kolothum Thodi,
Sudeep Holla
In-Reply-To: <VI1PR0401MB2496373E0C6D1097F22B3026F1150@VI1PR0401MB2496.eurprd04.prod.outlook.com>
On 14/02/2020 3:58 pm, Pankaj Bansal wrote:
[...]
>> I don't understand what you mean. Platform MSI using IORT uses the DevID of
>> end-points. How could the ITS could work without specifying a DevID?
>> See for example how the SMMUv3 driver uses platform MSI.
>
> DevID is input ID for PCIe devices. BUT what would be the input ID for platform device? Are we saying that Platform devices can't specify an Input ID ?
No, from the IORT perspective, the input for the ID mappings belonging
to a root complex is the PCI requester ID. The (ITS) DevID is the
ultimate *output* of a root complex mapping.
Whilst you can indeed represent the MC as a black-box Named Component
with an ID mapping range not using the "single mapping" flag, that means
your input IDs come from some device-specific domain beyond the scope of
IORT. That's why you can't easily get away from your special bus
integration code.
>>> While, IORT spec doesn't specify any such limitation.
>>>
>>> we can easily update iort.c to remove this limitation.
>>> But, I am not sure how the input id would be passed from platform MSI
>>> GIC layer to IORT.
>>> Most obviously, the input id should be supplied by dev itself.
>>
>> Why should the device know about its own ID? That's a bus/interconnect thing.
>> And nothing should be passed *to* IORT. IORT is the source.
>
> IORT is translation between Input IDs <-> Output IDs. The Input ID is still expected to be passed to parse IORT table.
...except for single mappings, where the input ID is ignored and the
output ID is the "source", which is exactly what iort_node_get_id()
deals with for devices represented in IORT. With what you're talking
about, "the device" is *not* represented in IORT, but is something
beyond the MC 'bridge'. Now it probably is technically possible to
handle that somehow, but it's definitely not something that the existing
code was ever designed to anticipate.
Robin.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH AUTOSEL 5.5 493/542] KVM: PPC: Book3S HV: Release lock on page-out failure path
From: Sasha Levin @ 2020-02-14 15:48 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Sasha Levin, kvm-ppc, Kamalesh Babulal, Bharata B Rao,
linuxppc-dev
In-Reply-To: <20200214154854.6746-1-sashal@kernel.org>
From: Bharata B Rao <bharata@linux.ibm.com>
[ Upstream commit e032e3b55b6f487e48c163c5dca74086f147a169 ]
When migrate_vma_setup() fails in kvmppc_svm_page_out(),
release kvm->arch.uvmem_lock before returning.
Fixes: ca9f4942670 ("KVM: PPC: Book3S HV: Support for running secure guests")
Signed-off-by: Bharata B Rao <bharata@linux.ibm.com>
Reviewed-by: Kamalesh Babulal <kamalesh@linux.vnet.ibm.com>
Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
arch/powerpc/kvm/book3s_hv_uvmem.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/kvm/book3s_hv_uvmem.c b/arch/powerpc/kvm/book3s_hv_uvmem.c
index 2de264fc31563..5914fbfa5e0a7 100644
--- a/arch/powerpc/kvm/book3s_hv_uvmem.c
+++ b/arch/powerpc/kvm/book3s_hv_uvmem.c
@@ -543,7 +543,7 @@ kvmppc_svm_page_out(struct vm_area_struct *vma, unsigned long start,
ret = migrate_vma_setup(&mig);
if (ret)
- return ret;
+ goto out;
spage = migrate_pfn_to_page(*mig.src);
if (!spage || !(*mig.src & MIGRATE_PFN_MIGRATE))
--
2.20.1
^ permalink raw reply related
* [PATCH AUTOSEL 4.19 246/252] drm/amdgpu/smu10: fix smu10_get_clock_by_type_with_voltage
From: Sasha Levin @ 2020-02-14 16:11 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Alex Deucher, Evan Quan, Sasha Levin, amd-gfx, dri-devel
In-Reply-To: <20200214161147.15842-1-sashal@kernel.org>
From: Alex Deucher <alexander.deucher@amd.com>
[ Upstream commit 1064ad4aeef94f51ca230ac639a9e996fb7867a0 ]
Cull out 0 clocks to avoid a warning in DC.
Bug: https://gitlab.freedesktop.org/drm/amd/issues/963
Reviewed-by: Evan Quan <evan.quan@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/gpu/drm/amd/powerplay/hwmgr/smu10_hwmgr.c | 8 +++++---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/smu10_hwmgr.c b/drivers/gpu/drm/amd/powerplay/hwmgr/smu10_hwmgr.c
index 3fa6e8123b8eb..48e31711bc68f 100644
--- a/drivers/gpu/drm/amd/powerplay/hwmgr/smu10_hwmgr.c
+++ b/drivers/gpu/drm/amd/powerplay/hwmgr/smu10_hwmgr.c
@@ -1048,9 +1048,11 @@ static int smu10_get_clock_by_type_with_voltage(struct pp_hwmgr *hwmgr,
clocks->num_levels = 0;
for (i = 0; i < pclk_vol_table->count; i++) {
- clocks->data[i].clocks_in_khz = pclk_vol_table->entries[i].clk * 10;
- clocks->data[i].voltage_in_mv = pclk_vol_table->entries[i].vol;
- clocks->num_levels++;
+ if (pclk_vol_table->entries[i].clk) {
+ clocks->data[clocks->num_levels].clocks_in_khz = pclk_vol_table->entries[i].clk * 10;
+ clocks->data[clocks->num_levels].voltage_in_mv = pclk_vol_table->entries[i].vol;
+ clocks->num_levels++;
+ }
}
return 0;
--
2.20.1
^ permalink raw reply related
* [PATCH AUTOSEL 4.19 245/252] drm/amdgpu/smu10: fix smu10_get_clock_by_type_with_latency
From: Sasha Levin @ 2020-02-14 16:11 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Alex Deucher, Evan Quan, Sasha Levin, amd-gfx, dri-devel
In-Reply-To: <20200214161147.15842-1-sashal@kernel.org>
From: Alex Deucher <alexander.deucher@amd.com>
[ Upstream commit 4d0a72b66065dd7e274bad6aa450196d42fd8f84 ]
Only send non-0 clocks to DC for validation. This mirrors
what the windows driver does.
Bug: https://gitlab.freedesktop.org/drm/amd/issues/963
Reviewed-by: Evan Quan <evan.quan@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/gpu/drm/amd/powerplay/hwmgr/smu10_hwmgr.c | 15 +++++++++------
1 file changed, 9 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/smu10_hwmgr.c b/drivers/gpu/drm/amd/powerplay/hwmgr/smu10_hwmgr.c
index 1546bc49004f8..3fa6e8123b8eb 100644
--- a/drivers/gpu/drm/amd/powerplay/hwmgr/smu10_hwmgr.c
+++ b/drivers/gpu/drm/amd/powerplay/hwmgr/smu10_hwmgr.c
@@ -994,12 +994,15 @@ static int smu10_get_clock_by_type_with_latency(struct pp_hwmgr *hwmgr,
clocks->num_levels = 0;
for (i = 0; i < pclk_vol_table->count; i++) {
- clocks->data[i].clocks_in_khz = pclk_vol_table->entries[i].clk * 10;
- clocks->data[i].latency_in_us = latency_required ?
- smu10_get_mem_latency(hwmgr,
- pclk_vol_table->entries[i].clk) :
- 0;
- clocks->num_levels++;
+ if (pclk_vol_table->entries[i].clk) {
+ clocks->data[clocks->num_levels].clocks_in_khz =
+ pclk_vol_table->entries[i].clk * 10;
+ clocks->data[clocks->num_levels].latency_in_us = latency_required ?
+ smu10_get_mem_latency(hwmgr,
+ pclk_vol_table->entries[i].clk) :
+ 0;
+ clocks->num_levels++;
+ }
}
return 0;
--
2.20.1
^ permalink raw reply related
* [PATCH AUTOSEL 4.19 247/252] NFS: Fix memory leaks
From: Sasha Levin @ 2020-02-14 16:11 UTC (permalink / raw)
To: linux-kernel, stable; +Cc: Wenwen Wang, Anna Schumaker, Sasha Levin, linux-nfs
In-Reply-To: <20200214161147.15842-1-sashal@kernel.org>
From: Wenwen Wang <wenwen@cs.uga.edu>
[ Upstream commit 123c23c6a7b7ecd2a3d6060bea1d94019f71fd66 ]
In _nfs42_proc_copy(), 'res->commit_res.verf' is allocated through
kzalloc() if 'args->sync' is true. In the following code, if
'res->synchronous' is false, handle_async_copy() will be invoked. If an
error occurs during the invocation, the following code will not be executed
and the error will be returned . However, the allocated
'res->commit_res.verf' is not deallocated, leading to a memory leak. This
is also true if the invocation of process_copy_commit() returns an error.
To fix the above leaks, redirect the execution to the 'out' label if an
error is encountered.
Signed-off-by: Wenwen Wang <wenwen@cs.uga.edu>
Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
fs/nfs/nfs42proc.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/fs/nfs/nfs42proc.c b/fs/nfs/nfs42proc.c
index 94f98e190e632..526441de89c1d 100644
--- a/fs/nfs/nfs42proc.c
+++ b/fs/nfs/nfs42proc.c
@@ -283,14 +283,14 @@ static ssize_t _nfs42_proc_copy(struct file *src,
status = handle_async_copy(res, server, src, dst,
&args->src_stateid);
if (status)
- return status;
+ goto out;
}
if ((!res->synchronous || !args->sync) &&
res->write_res.verifier.committed != NFS_FILE_SYNC) {
status = process_copy_commit(dst, pos_dst, res);
if (status)
- return status;
+ goto out;
}
truncate_pagecache_range(dst_inode, pos_dst,
--
2.20.1
^ permalink raw reply related
* [PATCH AUTOSEL 4.19 248/252] NFSv4: try lease recovery on NFS4ERR_EXPIRED
From: Sasha Levin @ 2020-02-14 16:11 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Robert Milkowski, Trond Myklebust, Anna Schumaker, Sasha Levin,
linux-nfs
In-Reply-To: <20200214161147.15842-1-sashal@kernel.org>
From: Robert Milkowski <rmilkowski@gmail.com>
[ Upstream commit 924491f2e476f7234d722b24171a4daff61bbe13 ]
Currently, if an nfs server returns NFS4ERR_EXPIRED to open(),
we return EIO to applications without even trying to recover.
Fixes: 272289a3df72 ("NFSv4: nfs4_do_handle_exception() handle revoke/expiry of a single stateid")
Signed-off-by: Robert Milkowski <rmilkowski@gmail.com>
Reviewed-by: Trond Myklebust <trond.myklebust@hammerspace.com>
Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
fs/nfs/nfs4proc.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/fs/nfs/nfs4proc.c b/fs/nfs/nfs4proc.c
index 7834b325394fc..fad795041d324 100644
--- a/fs/nfs/nfs4proc.c
+++ b/fs/nfs/nfs4proc.c
@@ -3089,6 +3089,11 @@ static struct nfs4_state *nfs4_do_open(struct inode *dir,
exception.retry = 1;
continue;
}
+ if (status == -NFS4ERR_EXPIRED) {
+ nfs4_schedule_lease_recovery(server->nfs_client);
+ exception.retry = 1;
+ continue;
+ }
if (status == -EAGAIN) {
/* We must have found a delegation */
exception.retry = 1;
--
2.20.1
^ permalink raw reply related
* [PATCH AUTOSEL 4.19 202/252] x86/decoder: Add TEST opcode to Group3-2
From: Sasha Levin @ 2020-02-14 16:10 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Masami Hiramatsu, Randy Dunlap, Borislav Petkov, Sasha Levin
In-Reply-To: <20200214161147.15842-1-sashal@kernel.org>
From: Masami Hiramatsu <mhiramat@kernel.org>
[ Upstream commit 8b7e20a7ba54836076ff35a28349dabea4cec48f ]
Add TEST opcode to Group3-2 reg=001b as same as Group3-1 does.
Commit
12a78d43de76 ("x86/decoder: Add new TEST instruction pattern")
added a TEST opcode assignment to f6 XX/001/XXX (Group 3-1), but did
not add f7 XX/001/XXX (Group 3-2).
Actually, this TEST opcode variant (ModRM.reg /1) is not described in
the Intel SDM Vol2 but in AMD64 Architecture Programmer's Manual Vol.3,
Appendix A.2 Table A-6. ModRM.reg Extensions for the Primary Opcode Map.
Without this fix, Randy found a warning by insn_decoder_test related
to this issue as below.
HOSTCC arch/x86/tools/insn_decoder_test
HOSTCC arch/x86/tools/insn_sanity
TEST posttest
arch/x86/tools/insn_decoder_test: warning: Found an x86 instruction decoder bug, please report this.
arch/x86/tools/insn_decoder_test: warning: ffffffff81000bf1: f7 0b 00 01 08 00 testl $0x80100,(%rbx)
arch/x86/tools/insn_decoder_test: warning: objdump says 6 bytes, but insn_get_length() says 2
arch/x86/tools/insn_decoder_test: warning: Decoded and checked 11913894 instructions with 1 failures
TEST posttest
arch/x86/tools/insn_sanity: Success: decoded and checked 1000000 random instructions with 0 errors (seed:0x871ce29c)
To fix this error, add the TEST opcode according to AMD64 APM Vol.3.
[ bp: Massage commit message. ]
Reported-by: Randy Dunlap <rdunlap@infradead.org>
Signed-off-by: Masami Hiramatsu <mhiramat@kernel.org>
Signed-off-by: Borislav Petkov <bp@suse.de>
Acked-by: Randy Dunlap <rdunlap@infradead.org>
Tested-by: Randy Dunlap <rdunlap@infradead.org>
Link: https://lkml.kernel.org/r/157966631413.9580.10311036595431878351.stgit@devnote2
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
arch/x86/lib/x86-opcode-map.txt | 2 +-
tools/objtool/arch/x86/lib/x86-opcode-map.txt | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/x86/lib/x86-opcode-map.txt b/arch/x86/lib/x86-opcode-map.txt
index 0a0e9112f2842..5cb9f009f2be3 100644
--- a/arch/x86/lib/x86-opcode-map.txt
+++ b/arch/x86/lib/x86-opcode-map.txt
@@ -909,7 +909,7 @@ EndTable
GrpTable: Grp3_2
0: TEST Ev,Iz
-1:
+1: TEST Ev,Iz
2: NOT Ev
3: NEG Ev
4: MUL rAX,Ev
diff --git a/tools/objtool/arch/x86/lib/x86-opcode-map.txt b/tools/objtool/arch/x86/lib/x86-opcode-map.txt
index 0a0e9112f2842..5cb9f009f2be3 100644
--- a/tools/objtool/arch/x86/lib/x86-opcode-map.txt
+++ b/tools/objtool/arch/x86/lib/x86-opcode-map.txt
@@ -909,7 +909,7 @@ EndTable
GrpTable: Grp3_2
0: TEST Ev,Iz
-1:
+1: TEST Ev,Iz
2: NOT Ev
3: NEG Ev
4: MUL rAX,Ev
--
2.20.1
^ permalink raw reply related
* [PATCH AUTOSEL 4.4 082/100] ARM: 8951/1: Fix Kexec compilation issue.
From: Sasha Levin @ 2020-02-14 16:24 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Sasha Levin, Russell King, Vincenzo Frascino, linux-arm-kernel
In-Reply-To: <20200214162425.21071-1-sashal@kernel.org>
From: Vincenzo Frascino <vincenzo.frascino@arm.com>
[ Upstream commit 76950f7162cad51d2200ebd22c620c14af38f718 ]
To perform the reserve_crashkernel() operation kexec uses SECTION_SIZE to
find a memblock in a range.
SECTION_SIZE is not defined for nommu systems. Trying to compile kexec in
these conditions results in a build error:
linux/arch/arm/kernel/setup.c: In function ‘reserve_crashkernel’:
linux/arch/arm/kernel/setup.c:1016:25: error: ‘SECTION_SIZE’ undeclared
(first use in this function); did you mean ‘SECTIONS_WIDTH’?
crash_size, SECTION_SIZE);
^~~~~~~~~~~~
SECTIONS_WIDTH
linux/arch/arm/kernel/setup.c:1016:25: note: each undeclared identifier
is reported only once for each function it appears in
linux/scripts/Makefile.build:265: recipe for target 'arch/arm/kernel/setup.o'
failed
Make KEXEC depend on MMU to fix the compilation issue.
Signed-off-by: Vincenzo Frascino <vincenzo.frascino@arm.com>
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
arch/arm/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 2ba69df49cf86..45f2a5930379a 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -2000,7 +2000,7 @@ config XIP_PHYS_ADDR
config KEXEC
bool "Kexec system call (EXPERIMENTAL)"
depends on (!SMP || PM_SLEEP_SMP)
- depends on !CPU_V7M
+ depends on MMU
select KEXEC_CORE
help
kexec is a system call that implements the ability to shutdown your
--
2.20.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 AUTOSEL 4.19 249/252] help_next should increase position index
From: Sasha Levin @ 2020-02-14 16:11 UTC (permalink / raw)
To: linux-kernel, stable; +Cc: Vasily Averin, Mike Marshall, Sasha Levin, devel
In-Reply-To: <20200214161147.15842-1-sashal@kernel.org>
From: Vasily Averin <vvs@virtuozzo.com>
[ Upstream commit 9f198a2ac543eaaf47be275531ad5cbd50db3edf ]
if seq_file .next fuction does not change position index,
read after some lseek can generate unexpected output.
https://bugzilla.kernel.org/show_bug.cgi?id=206283
Signed-off-by: Vasily Averin <vvs@virtuozzo.com>
Signed-off-by: Mike Marshall <hubcap@omnibond.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
fs/orangefs/orangefs-debugfs.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/fs/orangefs/orangefs-debugfs.c b/fs/orangefs/orangefs-debugfs.c
index 0732cb08173e9..e24738c691f66 100644
--- a/fs/orangefs/orangefs-debugfs.c
+++ b/fs/orangefs/orangefs-debugfs.c
@@ -305,6 +305,7 @@ static void *help_start(struct seq_file *m, loff_t *pos)
static void *help_next(struct seq_file *m, void *v, loff_t *pos)
{
+ (*pos)++;
gossip_debug(GOSSIP_DEBUGFS_DEBUG, "help_next: start\n");
return NULL;
--
2.20.1
^ permalink raw reply related
* [PATCH AUTOSEL 4.19 251/252] virtio_balloon: prevent pfn array overflow
From: Sasha Levin @ 2020-02-14 16:11 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Michael S. Tsirkin, David Hildenbrand, Sasha Levin,
virtualization
In-Reply-To: <20200214161147.15842-1-sashal@kernel.org>
From: "Michael S. Tsirkin" <mst@redhat.com>
[ Upstream commit 6e9826e77249355c09db6ba41cd3f84e89f4b614 ]
Make sure, at build time, that pfn array is big enough to hold a single
page. It happens to be true since the PAGE_SHIFT value at the moment is
20, which is 1M - exactly 256 4K balloon pages.
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Reviewed-by: David Hildenbrand <david@redhat.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/virtio/virtio_balloon.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/virtio/virtio_balloon.c b/drivers/virtio/virtio_balloon.c
index 14ac36ca8fbd3..1afcbef397ab7 100644
--- a/drivers/virtio/virtio_balloon.c
+++ b/drivers/virtio/virtio_balloon.c
@@ -126,6 +126,8 @@ static void set_page_pfns(struct virtio_balloon *vb,
{
unsigned int i;
+ BUILD_BUG_ON(VIRTIO_BALLOON_PAGES_PER_PAGE > VIRTIO_BALLOON_ARRAY_PFNS_MAX);
+
/*
* Set balloon pfns pointing at this page.
* Note that the first pfn points at start of the page.
--
2.20.1
^ permalink raw reply related
* [PATCH AUTOSEL 4.19 250/252] cifs: log warning message (once) if out of disk space
From: Sasha Levin @ 2020-02-14 16:11 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Steve French, Oleg Kravtsov, Ronnie Sahlberg, Pavel Shilovsky,
Sasha Levin, linux-cifs, samba-technical
In-Reply-To: <20200214161147.15842-1-sashal@kernel.org>
From: Steve French <stfrench@microsoft.com>
[ Upstream commit d6fd41905ec577851734623fb905b1763801f5ef ]
We ran into a confusing problem where an application wasn't checking
return code on close and so user didn't realize that the application
ran out of disk space. log a warning message (once) in these
cases. For example:
[ 8407.391909] Out of space writing to \\oleg-server\small-share
Signed-off-by: Steve French <stfrench@microsoft.com>
Reported-by: Oleg Kravtsov <oleg@tuxera.com>
Reviewed-by: Ronnie Sahlberg <lsahlber@redhat.com>
Reviewed-by: Pavel Shilovsky <pshilov@microsoft.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
fs/cifs/smb2pdu.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/fs/cifs/smb2pdu.c b/fs/cifs/smb2pdu.c
index 0d4e4d97e6cf5..e2d2b749c8f38 100644
--- a/fs/cifs/smb2pdu.c
+++ b/fs/cifs/smb2pdu.c
@@ -3425,6 +3425,9 @@ smb2_writev_callback(struct mid_q_entry *mid)
wdata->cfile->fid.persistent_fid,
tcon->tid, tcon->ses->Suid, wdata->offset,
wdata->bytes, wdata->result);
+ if (wdata->result == -ENOSPC)
+ printk_once(KERN_WARNING "Out of space writing to %s\n",
+ tcon->treeName);
} else
trace_smb3_write_done(0 /* no xid */,
wdata->cfile->fid.persistent_fid,
--
2.20.1
^ permalink raw reply related
* [PATCH AUTOSEL 4.19 207/252] ALSA: hda - Add docking station support for Lenovo Thinkpad T420s
From: Sasha Levin @ 2020-02-14 16:11 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Peter Große, Takashi Iwai, Sasha Levin, alsa-devel
In-Reply-To: <20200214161147.15842-1-sashal@kernel.org>
From: Peter Große <pegro@friiks.de>
[ Upstream commit ef7d84caa5928b40b1c93a26dbe5a3f12737c6ab ]
Lenovo Thinkpad T420s uses the same codec as T420, so apply the
same quirk to enable audio output on a docking station.
Signed-off-by: Peter Große <pegro@friiks.de>
Link: https://lore.kernel.org/r/20200122180106.9351-1-pegro@friiks.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
sound/pci/hda/patch_conexant.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/sound/pci/hda/patch_conexant.c b/sound/pci/hda/patch_conexant.c
index 5500dd437b44d..78bb96263bc27 100644
--- a/sound/pci/hda/patch_conexant.c
+++ b/sound/pci/hda/patch_conexant.c
@@ -935,6 +935,7 @@ static const struct snd_pci_quirk cxt5066_fixups[] = {
SND_PCI_QUIRK(0x17aa, 0x215f, "Lenovo T510", CXT_PINCFG_LENOVO_TP410),
SND_PCI_QUIRK(0x17aa, 0x21ce, "Lenovo T420", CXT_PINCFG_LENOVO_TP410),
SND_PCI_QUIRK(0x17aa, 0x21cf, "Lenovo T520", CXT_PINCFG_LENOVO_TP410),
+ SND_PCI_QUIRK(0x17aa, 0x21d2, "Lenovo T420s", CXT_PINCFG_LENOVO_TP410),
SND_PCI_QUIRK(0x17aa, 0x21da, "Lenovo X220", CXT_PINCFG_LENOVO_TP410),
SND_PCI_QUIRK(0x17aa, 0x21db, "Lenovo X220-tablet", CXT_PINCFG_LENOVO_TP410),
SND_PCI_QUIRK(0x17aa, 0x38af, "Lenovo IdeaPad Z560", CXT_FIXUP_MUTE_LED_EAPD),
--
2.20.1
^ permalink raw reply related
* [PATCH AUTOSEL 4.4 072/100] iommu/arm-smmu-v3: Use WRITE_ONCE() when changing validity of an STE
From: Sasha Levin @ 2020-02-14 16:23 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Sasha Levin, Jean-Philippe Brucker, iommu, Will Deacon,
linux-arm-kernel
In-Reply-To: <20200214162425.21071-1-sashal@kernel.org>
From: Will Deacon <will@kernel.org>
[ Upstream commit d71e01716b3606a6648df7e5646ae12c75babde4 ]
If, for some bizarre reason, the compiler decided to split up the write
of STE DWORD 0, we could end up making a partial structure valid.
Although this probably won't happen, follow the example of the
context-descriptor code and use WRITE_ONCE() to ensure atomicity of the
write.
Reported-by: Jean-Philippe Brucker <jean-philippe@linaro.org>
Signed-off-by: Will Deacon <will@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/iommu/arm-smmu-v3.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/iommu/arm-smmu-v3.c b/drivers/iommu/arm-smmu-v3.c
index eb9937225d645..6c10f307a1c98 100644
--- a/drivers/iommu/arm-smmu-v3.c
+++ b/drivers/iommu/arm-smmu-v3.c
@@ -1090,7 +1090,8 @@ static void arm_smmu_write_strtab_ent(struct arm_smmu_device *smmu, u32 sid,
}
arm_smmu_sync_ste_for_sid(smmu, sid);
- dst[0] = cpu_to_le64(val);
+ /* See comment in arm_smmu_write_ctx_desc() */
+ WRITE_ONCE(dst[0], cpu_to_le64(val));
arm_smmu_sync_ste_for_sid(smmu, sid);
/* It's likely that we'll want to use the new STE soon */
--
2.20.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 AUTOSEL 4.4 069/100] ARC: [plat-axs10x]: Add missing multicast filter number to GMAC node
From: Sasha Levin @ 2020-02-14 16:23 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Jose Abreu, devicetree, Sasha Levin, Vineet Gupta, Alexey Brodkin,
linux-snps-arc
In-Reply-To: <20200214162425.21071-1-sashal@kernel.org>
From: Jose Abreu <Jose.Abreu@synopsys.com>
[ Upstream commit 7980dff398f86a618f502378fa27cf7e77449afa ]
Add a missing property to GMAC node so that multicast filtering works
correctly.
Fixes: 556cc1c5f528 ("ARC: [axs101] Add support for AXS101 SDP (software development platform)")
Acked-by: Alexey Brodkin <abrodkin@synopsys.com>
Signed-off-by: Jose Abreu <Jose.Abreu@synopsys.com>
Signed-off-by: Vineet Gupta <vgupta@synopsys.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
arch/arc/boot/dts/axs10x_mb.dtsi | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arc/boot/dts/axs10x_mb.dtsi b/arch/arc/boot/dts/axs10x_mb.dtsi
index 44a578c10732c..2f52e584f3f77 100644
--- a/arch/arc/boot/dts/axs10x_mb.dtsi
+++ b/arch/arc/boot/dts/axs10x_mb.dtsi
@@ -44,6 +44,7 @@
interrupt-names = "macirq";
phy-mode = "rgmii";
snps,pbl = < 32 >;
+ snps,multicast-filter-bins = <256>;
clocks = <&apbclk>;
clock-names = "stmmaceth";
max-speed = <100>;
--
2.20.1
_______________________________________________
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
^ permalink raw reply related
* [PATCH AUTOSEL 4.14 001/186] drm/amdgpu: remove set but not used variable 'mc_shared_chmap' from 'gfx_v6_0.c' and 'gfx_v7_0.c'
From: Sasha Levin @ 2020-02-14 16:14 UTC (permalink / raw)
To: linux-kernel, stable
Cc: yu kuai, Alex Deucher, Sasha Levin, amd-gfx, dri-devel
From: yu kuai <yukuai3@huawei.com>
[ Upstream commit 747a397d394fac0001e4b3c03d7dce3a118af567 ]
Fixes gcc '-Wunused-but-set-variable' warning:
drivers/gpu/drm/amd/amdgpu/gfx_v6_0.c: In function
‘gfx_v6_0_constants_init’:
drivers/gpu/drm/amd/amdgpu/gfx_v6_0.c:1579:6: warning: variable
‘mc_shared_chmap’ set but not used [-Wunused-but-set-variable]
drivers/gpu/drm/amd/amdgpu/gfx_v7_0.c: In function
‘gfx_v7_0_gpu_early_init’:
drivers/gpu/drm/amd/amdgpu/gfx_v7_0.c:4262:6: warning: variable
‘mc_shared_chmap’ set but not used [-Wunused-but-set-variable]
Fixes: 2cd46ad22383 ("drm/amdgpu: add graphic pipeline implementation for si v8")
Fixes: d93f3ca706b8 ("drm/amdgpu/gfx7: rework gpu_init()")
Signed-off-by: yu kuai <yukuai3@huawei.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/gpu/drm/amd/amdgpu/gfx_v6_0.c | 3 +--
drivers/gpu/drm/amd/amdgpu/gfx_v7_0.c | 3 +--
2 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v6_0.c b/drivers/gpu/drm/amd/amdgpu/gfx_v6_0.c
index dbbe986f90f29..4b724c1130290 100644
--- a/drivers/gpu/drm/amd/amdgpu/gfx_v6_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/gfx_v6_0.c
@@ -1554,7 +1554,7 @@ static void gfx_v6_0_config_init(struct amdgpu_device *adev)
static void gfx_v6_0_gpu_init(struct amdgpu_device *adev)
{
u32 gb_addr_config = 0;
- u32 mc_shared_chmap, mc_arb_ramcfg;
+ u32 mc_arb_ramcfg;
u32 sx_debug_1;
u32 hdp_host_path_cntl;
u32 tmp;
@@ -1656,7 +1656,6 @@ static void gfx_v6_0_gpu_init(struct amdgpu_device *adev)
WREG32(mmBIF_FB_EN, BIF_FB_EN__FB_READ_EN_MASK | BIF_FB_EN__FB_WRITE_EN_MASK);
- mc_shared_chmap = RREG32(mmMC_SHARED_CHMAP);
adev->gfx.config.mc_arb_ramcfg = RREG32(mmMC_ARB_RAMCFG);
mc_arb_ramcfg = adev->gfx.config.mc_arb_ramcfg;
diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v7_0.c b/drivers/gpu/drm/amd/amdgpu/gfx_v7_0.c
index 6f76b26464658..1703ace67b527 100644
--- a/drivers/gpu/drm/amd/amdgpu/gfx_v7_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/gfx_v7_0.c
@@ -4345,7 +4345,7 @@ static int gfx_v7_0_late_init(void *handle)
static void gfx_v7_0_gpu_early_init(struct amdgpu_device *adev)
{
u32 gb_addr_config;
- u32 mc_shared_chmap, mc_arb_ramcfg;
+ u32 mc_arb_ramcfg;
u32 dimm00_addr_map, dimm01_addr_map, dimm10_addr_map, dimm11_addr_map;
u32 tmp;
@@ -4422,7 +4422,6 @@ static void gfx_v7_0_gpu_early_init(struct amdgpu_device *adev)
break;
}
- mc_shared_chmap = RREG32(mmMC_SHARED_CHMAP);
adev->gfx.config.mc_arb_ramcfg = RREG32(mmMC_ARB_RAMCFG);
mc_arb_ramcfg = adev->gfx.config.mc_arb_ramcfg;
--
2.20.1
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.