Re: [PATCH v7 4/4] uprobe: use FOLL_SPLIT_PMD instead of FOLL_SPLIT
* Song Liu [2019-06-25 16:53:25]: > This patches uses newly added FOLL_SPLIT_PMD in uprobe. This enables easy > regroup of huge pmd after the uprobe is disabled (in next patch). > > Acked-by: Kirill A. Shutemov > Signed-off-by: Song Liu > --- > kernel/events/uprobes.c | 6 ++ > 1 file changed, 2 insertions(+), 4 deletions(-) Looks good to me. Reviewed-by: Srikar Dronamraju -- Thanks and Regards Srikar Dronamraju
[PATCH] media:vivid: add sanity check to avoid divide error and set value to 1 if 0.
Syzbot reported divide error in vivid_thread_vid_cap, which has been seen only once and doesnot have a reproducer. This patch sanity checks for the denominator value with WARN_ON if it is 0 and replaces it with 1. Reported-by: syz...@syzkaller.appspotmail.com divide error: [#1] PREEMPT SMP KASAN kobject: 'tx-0' (17161f7f): kobject_uevent_env CPU: 0 PID: 23689 Comm: vivid-003-vid-c Not tainted 5.0.0-rc4+ #58 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:vivid_cap_update_frame_period drivers/media/platform/vivid/vivid-kthread-cap.c:661 [inline] RIP: 0010:vivid_thread_vid_cap+0x221/0x284 drivers/media/platform/vivid/vivid-kthread-cap.c:789 Code: 48 c1 e9 03 0f b6 0c 11 48 89 f2 48 69 c0 00 ca 9a 3b 83 c2 03 38 ca 7c 08 84 c9 0f 85 f0 1e 00 00 41 8b 8f 24 64 00 00 31 d2 <48> f7 f1 49 89 c4 48 89 c3 49 8d 87 28 64 00 00 48 89 c2 48 89 45 RSP: 0018:88808b4afd68 EFLAGS: 00010246 kobject: 'tx-0' (17161f7f): fill_kobj_path: path = '/devices/virtual/net/gre0/queues/tx-0' RAX: 00de5a6f8e00 RBX: 000100047b22 RCX: RDX: RSI: 0004 RDI: 0004 RBP: 88808b4aff00 R08: 88804862e1c0 R09: 89997008 R10: 89997010 R11: 0001 R12: fffc R13: 8880a17e0500 R14: 88803e40f760 R15: 8882182b0140 FS: () GS:8880ae80() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: 004cdc90 CR3: 5d827000 CR4: 001426f0 Call Trace: kobject: 'gretap0' (d7549098): kobject_add_internal: parent: 'net', set: 'devices' kobject: 'loop2' (94ed4ee4): kobject_uevent_env kobject: 'loop2' (94ed4ee4): fill_kobj_path: path = '/devices/virtual/block/loop2' kthread+0x357/0x430 kernel/kthread.c:246 kobject: 'gretap0' (d7549098): kobject_uevent_env ret_from_fork+0x3a/0x50 arch/x86/entry/entry_64.S:352 Modules linked in: kobject: 'gretap0' (d7549098): fill_kobj_path: path = '/devices/virtual/net/gretap0' ---[ end trace bc5c8b25b64d768f ]--- kobject: 'loop1' (32036b86): kobject_uevent_env RIP: 0010:vivid_cap_update_frame_period drivers/media/platform/vivid/vivid-kthread-cap.c:661 [inline] RIP: 0010:vivid_thread_vid_cap+0x221/0x2840 drivers/media/platform/vivid/vivid-kthread-cap.c:789 kobject: 'loop1' (32036b86): fill_kobj_path: path = '/devices/virtual/block/loop1' Code: 48 c1 e9 03 0f b6 0c 11 48 89 f2 48 69 c0 00 ca 9a 3b 83 c2 03 38 ca 7c 08 84 c9 0f 85 f0 1e 00 00 41 8b 8f 24 64 00 00 31 d2 <48> f7 f1 49 89 c4 48 89 c3 49 8d 87 28 64 00 00 48 89 c2 48 89 45 kobject: 'loop0' (dd9927c3): kobject_uevent_env RSP: 0018:88808b4afd68 EFLAGS: 00010246 RAX: 00de5a6f8e00 RBX: 000100047b22 RCX: kobject: 'queues' (7ed20666): kobject_add_internal: parent: 'gretap0', set: '' RDX: RSI: 0004 RDI: 0004 RBP: 88808b4aff00 R08: 88804862e1c0 R09: 89997008 kobject: 'loop0' (dd9927c3): fill_kobj_path: path = '/devices/virtual/block/loop0' R10: 89997010 R11: 0001 R12: fffc kobject: 'queues' (7ed20666): kobject_uevent_env R13: 8880a17e0500 R14: 88803e40f760 R15: 8882182b0140 FS: () GS:8880ae80() knlGS: kobject: 'loop5' (a41f9e79): kobject_uevent_env CS: 0010 DS: ES: CR0: 80050033 kobject: 'queues' (7ed20666): kobject_uevent_env: filter function caused the event to drop! CR2: 004cdc90 CR3: 5d827000 CR4: 001426f0 kobject: 'loop5' (a41f9e79): fill_kobj_path: path = '/devices/virtual/block/loop5' Signed-off-by: Vandana BN --- drivers/media/platform/vivid/vivid-kthread-cap.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/media/platform/vivid/vivid-kthread-cap.c b/drivers/media/platform/vivid/vivid-kthread-cap.c index f8006a30c12f..025a8c68bd1c 100644 --- a/drivers/media/platform/vivid/vivid-kthread-cap.c +++ b/drivers/media/platform/vivid/vivid-kthread-cap.c @@ -658,6 +658,8 @@ static void vivid_cap_update_frame_period(struct vivid_dev *dev) u64 f_period; f_period = (u64)dev->timeperframe_vid_cap.numerator * 10; + if(WARN_ON(dev->timeperframe_vid_cap.denominator == 0)) + dev->timeperframe_vid_cap.denominator = 1; do_div(f_period, dev->timeperframe_vid_cap.denominator); if (dev->field_cap == V4L2_FIELD_ALTERNATE) f_period >>= 1; -- 2.17.1
Re: [PATCH v7 3/5] mtd: Add support for HyperBus memory devices
On 26/06/19 6:46 AM, masonccy...@mxic.com.tw wrote: > Hi Vignesh, > >> >> Subject >> >> [PATCH v7 3/5] mtd: Add support for HyperBus memory devices >> >> Cypress' HyperBus is Low Signal Count, High Performance Double Data Rate >> Bus interface between a host system master and one or more slave >> interfaces. HyperBus is used to connect microprocessor, microcontroller, >> or ASIC devices with random access NOR flash memory (called HyperFlash) >> or self refresh DRAM (called HyperRAM). >> >> Its a 8-bit data bus (DQ[7:0]) with Read-Write Data Strobe (RWDS) >> signal and either Single-ended clock(3.0V parts) or Differential clock >> (1.8V parts). It uses ChipSelect lines to select b/w multiple slaves. >> At bus level, it follows a separate protocol described in HyperBus >> specification[1]. >> >> HyperFlash follows CFI AMD/Fujitsu Extended Command Set (0x0002) similar >> to that of existing parallel NORs. Since HyperBus is x8 DDR bus, >> its equivalent to x16 parallel NOR flash wrt bits per clock cycle. But >> HyperBus operates at >166MHz frequencies. >> HyperRAM provides direct random read/write access to flash memory >> array. >> >> But, HyperBus memory controllers seem to abstract implementation details >> and expose a simple MMIO interface to access connected flash. >> >> Add support for registering HyperFlash devices with MTD framework. MTD >> maps framework along with CFI chip support framework are used to support >> communicating with flash. >> >> Framework is modelled along the lines of spi-nor framework. HyperBus >> memory controller (HBMC) drivers calls hyperbus_register_device() to >> register a single HyperFlash device. HyperFlash core parses MMIO access >> information from DT, sets up the map_info struct, probes CFI flash and >> registers it with MTD framework. >> >> Some HBMC masters need calibration/training sequence[3] to be carried >> out, in order for DLL inside the controller to lock, by reading a known >> string/pattern. This is done by repeatedly reading CFI Query >> Identification String. Calibration needs to be done before trying to > detect >> flash as part of CFI flash probe. >> >> HyperRAM is not supported at the moment. >> >> HyperBus specification can be found at[1] >> HyperFlash datasheet can be found at[2] >> >> [1] https://www.cypress.com/file/213356/download >> [2] https://www.cypress.com/file/213346/download >> [3] http://www.ti.com/lit/ug/spruid7b/spruid7b.pdf >> Table 12-5741. HyperFlash Access Sequence >> >> Signed-off-by: Vignesh Raghavendra > > Cypress has announced the inclusion of Cypress’ high-bandwidth > HyperBus™ 8-bit serial memory interface into the new eXpanded SPI (xSPI) > electrical interface standard from the JEDEC Solid State Technology > Association > > for detail, please goes to > https://www.cypress.com/news/cypress-hyperbus-memory-interface-instant-applications-incorporated-jedec-xspi-electrical > > Thanks for the link! Announcement seems to be from March 2018 since then Cypress has published detailed HyperBus protocol in public domain . Comparing JEDEC xSPI specification and HyperBus protocol that Cypress has published, they seem to be following 8D-8D-8D Profile 2.0 with Extended Command Modifier of JEDEC xSPI spec. Did you see anything missing/different? I need to study xSPI spec in more detail, but seems like as long as we support HyperBus Protocol spec from Cypress we should be safe. -- Regards Vignesh
Re: [PATCH v7 2/4] uprobe: use original page when all uprobes are removed
* Song Liu [2019-06-25 16:53:23]: > Currently, uprobe swaps the target page with a anonymous page in both > install_breakpoint() and remove_breakpoint(). When all uprobes on a page > are removed, the given mm is still using an anonymous page (not the > original page). > > This patch allows uprobe to use original page when possible (all uprobes > on the page are already removed). > > Acked-by: Kirill A. Shutemov > Signed-off-by: Song Liu > Looks good to me. Reviewed-by: Srikar Dronamraju -- Thanks and Regards Srikar Dronamraju
Re: [PATCH V3 2/3] thermal/drivers/cpu_cooling: Unregister with the policy
Hi Viresh,
On 26/06/2019 04:58, Viresh Kumar wrote:
> On 25-06-19, 13:32, Daniel Lezcano wrote:
>> diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
>> index aee024e42618..f07454249fbc 100644
>> --- a/drivers/cpufreq/cpufreq.c
>> +++ b/drivers/cpufreq/cpufreq.c
>> @@ -1379,8 +1379,8 @@ static int cpufreq_online(unsigned int cpu)
>> cpufreq_driver->ready(policy);
>>
>> if (cpufreq_thermal_control_enabled(cpufreq_driver))
>> -policy->cdev = of_cpufreq_cooling_register(policy);
>> -
>> +of_cpufreq_cooling_register(policy);
>> +
>
> We don't need any error checking here anymore ?
There was no error checking initially. This comment and the others below
are for an additional patch IMO, not a change in this one.
>> pr_debug("initialization complete\n");
>>
>> return 0;
>> @@ -1468,10 +1468,8 @@ static int cpufreq_offline(unsigned int cpu)
>> goto unlock;
>> }
>>
>> -if (cpufreq_thermal_control_enabled(cpufreq_driver)) {
>> -cpufreq_cooling_unregister(policy->cdev);
>> -policy->cdev = NULL;
>> -}
>> +if (cpufreq_thermal_control_enabled(cpufreq_driver))
>> +cpufreq_cooling_unregister(policy);
>
> And we unregister unconditionally, even if we failed ? What if this
> routine prints error messages for such an case ?
>>
>> if (cpufreq_driver->stop_cpu)
>> cpufreq_driver->stop_cpu(policy);
>> diff --git a/drivers/thermal/cpu_cooling.c b/drivers/thermal/cpu_cooling.c
>> index 83486775e593..007c7c6bf845 100644
>> --- a/drivers/thermal/cpu_cooling.c
>> +++ b/drivers/thermal/cpu_cooling.c
>> @@ -78,6 +78,7 @@ struct cpufreq_cooling_device {
>> struct cpufreq_policy *policy;
>> struct list_head node;
>> struct time_in_idle *idle_time;
>> +struct thermal_cooling_device *cdev;
>> };
>>
>> static DEFINE_IDA(cpufreq_ida);
>> @@ -606,6 +607,7 @@ __cpufreq_cooling_register(struct device_node *np,
>> goto remove_ida;
>>
>> cpufreq_cdev->clipped_freq = get_state_freq(cpufreq_cdev, 0);
>> +cpufreq_cdev->cdev = cdev;
>>
>> mutex_lock(_list_lock);
>> /* Register the notifier for first cpufreq cooling device */
>> @@ -699,18 +701,18 @@ EXPORT_SYMBOL_GPL(of_cpufreq_cooling_register);
>> *
>> * This interface function unregisters the "thermal-cpufreq-%x" cooling
>> device.
>> */
>> -void cpufreq_cooling_unregister(struct thermal_cooling_device *cdev)
>> +void cpufreq_cooling_unregister(struct cpufreq_policy *policy)
>> {
>> struct cpufreq_cooling_device *cpufreq_cdev;
>> bool last;
>>
>> -if (!cdev)
>> -return;
>> -
>> -cpufreq_cdev = cdev->devdata;
>> -
>> mutex_lock(_list_lock);
>> -list_del(_cdev->node);
>> +list_for_each_entry(cpufreq_cdev, _cdev_list, node) {
>> +if (cpufreq_cdev->policy == policy) {
>> +list_del(_cdev->node);
>> +break;
>> +}
>> +}
>
> What if we reach here without a match for the policy ? We shouldn't
> continue and error out, right ? Print an error message as well ?
>
--
Facebook |
Twitter |
[PATCH] nvdimm: remove prototypes for nonexistent functions
From: Alastair D'Silva These functions don't exist, so remove the prototypes for them. Signed-off-by: Alastair D'Silva --- drivers/nvdimm/nd-core.h | 4 1 file changed, 4 deletions(-) diff --git a/drivers/nvdimm/nd-core.h b/drivers/nvdimm/nd-core.h index 391e88de3a29..57d162dbefaa 100644 --- a/drivers/nvdimm/nd-core.h +++ b/drivers/nvdimm/nd-core.h @@ -136,11 +136,7 @@ void nd_region_disable(struct nvdimm_bus *nvdimm_bus, struct device *dev); int nvdimm_bus_create_ndctl(struct nvdimm_bus *nvdimm_bus); void nvdimm_bus_destroy_ndctl(struct nvdimm_bus *nvdimm_bus); void nd_synchronize(void); -int nvdimm_bus_register_dimms(struct nvdimm_bus *nvdimm_bus); -int nvdimm_bus_register_regions(struct nvdimm_bus *nvdimm_bus); -int nvdimm_bus_init_interleave_sets(struct nvdimm_bus *nvdimm_bus); void __nd_device_register(struct device *dev); -int nd_match_dimm(struct device *dev, void *data); struct nd_label_id; char *nd_label_gen_id(struct nd_label_id *label_id, u8 *uuid, u32 flags); bool nd_is_uuid_unique(struct device *dev, u8 *uuid); -- 2.21.0
Re: [PATCH] nvdimm: remove prototypes for nonexistent functions
On Wed, 2019-06-26 at 16:03 +1000, Alastair D'Silva wrote: > From: Alastair D'Silva > > These functions don't exist, so remove the prototypes for them. > > Signed-off-by: Alastair D'Silva > --- > drivers/nvdimm/nd-core.h | 4 > 1 file changed, 4 deletions(-) > > diff --git a/drivers/nvdimm/nd-core.h b/drivers/nvdimm/nd-core.h > index 391e88de3a29..57d162dbefaa 100644 > --- a/drivers/nvdimm/nd-core.h > +++ b/drivers/nvdimm/nd-core.h > @@ -136,11 +136,7 @@ void nd_region_disable(struct nvdimm_bus > *nvdimm_bus, struct device *dev); > int nvdimm_bus_create_ndctl(struct nvdimm_bus *nvdimm_bus); > void nvdimm_bus_destroy_ndctl(struct nvdimm_bus *nvdimm_bus); > void nd_synchronize(void); > -int nvdimm_bus_register_dimms(struct nvdimm_bus *nvdimm_bus); > -int nvdimm_bus_register_regions(struct nvdimm_bus *nvdimm_bus); > -int nvdimm_bus_init_interleave_sets(struct nvdimm_bus *nvdimm_bus); > void __nd_device_register(struct device *dev); > -int nd_match_dimm(struct device *dev, void *data); > struct nd_label_id; > char *nd_label_gen_id(struct nd_label_id *label_id, u8 *uuid, u32 > flags); > bool nd_is_uuid_unique(struct device *dev, u8 *uuid); Whoops, fat-fingered this, nothing has changed. -- Alastair D'Silva mob: 0423 762 819 skype: alastair_dsilva Twitter: @EvilDeece blog: http://alastair.d-silva.org
Re: [PATCH 1/5] mm: Enable CONFIG_NODES_SPAN_OTHER_NODES by default for NUMA
On Tue 25-06-19 22:30:24, Hoan Tran OS wrote:
> This patch enables CONFIG_NODES_SPAN_OTHER_NODES by default
> for NUMA. As some NUMA nodes have memory ranges that span other
> nodes. Even though a pfn is valid and between a node's start and
> end pfns, it may not reside on that node.
Please describe the problem more thoroughly. What is the layout, what
doesn't work with the default configuration and why do we need this
particular fix rather than enabling of the config option for the
specific HW.
>
> Signed-off-by: Hoan Tran
> ---
> mm/page_alloc.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> index d66bc8a..6335505 100644
> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
> @@ -1413,7 +1413,7 @@ int __meminit early_pfn_to_nid(unsigned long pfn)
> }
> #endif
>
> -#ifdef CONFIG_NODES_SPAN_OTHER_NODES
> +#ifdef CONFIG_NUMA
> /* Only safe to use early in boot when initialisation is single-threaded */
> static inline bool __meminit early_pfn_in_nid(unsigned long pfn, int node)
> {
> --
> 2.7.4
>
--
Michal Hocko
SUSE Labs
[PATCH v2 2/3] mm: don't hide potentially null memmap pointer in sparse_remove_one_section
From: Alastair D'Silva
By adding offset to memmap before passing it in to clear_hwpoisoned_pages,
we hide a potentially null memmap from the null check inside
clear_hwpoisoned_pages.
This patch passes the offset to clear_hwpoisoned_pages instead, allowing
memmap to successfully peform it's null check.
Signed-off-by: Alastair D'Silva
---
mm/sparse.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/mm/sparse.c b/mm/sparse.c
index 57a1a3d9c1cf..1ec32aef5590 100644
--- a/mm/sparse.c
+++ b/mm/sparse.c
@@ -753,7 +753,8 @@ int __meminit sparse_add_one_section(int nid, unsigned long
start_pfn,
#ifdef CONFIG_MEMORY_HOTREMOVE
#ifdef CONFIG_MEMORY_FAILURE
-static void clear_hwpoisoned_pages(struct page *memmap, int nr_pages)
+static void clear_hwpoisoned_pages(struct page *memmap,
+ unsigned long start, unsigned long count)
{
int i;
@@ -769,7 +770,7 @@ static void clear_hwpoisoned_pages(struct page *memmap, int
nr_pages)
if (atomic_long_read(_poisoned_pages) == 0)
return;
- for (i = 0; i < nr_pages; i++) {
+ for (i = start; i < start + count; i++) {
if (PageHWPoison([i])) {
atomic_long_sub(1, _poisoned_pages);
ClearPageHWPoison([i]);
@@ -777,7 +778,8 @@ static void clear_hwpoisoned_pages(struct page *memmap, int
nr_pages)
}
}
#else
-static inline void clear_hwpoisoned_pages(struct page *memmap, int nr_pages)
+static inline void clear_hwpoisoned_pages(struct page *memmap,
+ unsigned long start, unsigned long count)
{
}
#endif
@@ -824,7 +826,7 @@ void sparse_remove_one_section(struct zone *zone, struct
mem_section *ms,
ms->pageblock_flags = NULL;
}
- clear_hwpoisoned_pages(memmap + map_offset,
+ clear_hwpoisoned_pages(memmap, map_offset,
PAGES_PER_SECTION - map_offset);
free_section_usemap(memmap, usemap, altmap);
}
--
2.21.0
[PATCH v2 1/3] mm: Trigger bug on if a section is not found in __section_nr
From: Alastair D'Silva
If a memory section comes in where the physical address is greater than
that which is managed by the kernel, this function would not trigger the
bug and instead return a bogus section number.
This patch tracks whether the section was actually found, and triggers the
bug if not.
Signed-off-by: Alastair D'Silva
---
drivers/base/memory.c | 18 +++---
mm/sparse.c | 7 ++-
2 files changed, 21 insertions(+), 4 deletions(-)
diff --git a/drivers/base/memory.c b/drivers/base/memory.c
index f180427e48f4..9244c122abf1 100644
--- a/drivers/base/memory.c
+++ b/drivers/base/memory.c
@@ -585,13 +585,21 @@ int __weak arch_get_memory_phys_device(unsigned long
start_pfn)
struct memory_block *find_memory_block_hinted(struct mem_section *section,
struct memory_block *hint)
{
- int block_id = base_memory_block_id(__section_nr(section));
+ int block_id, section_nr;
struct device *hintdev = hint ? >dev : NULL;
struct device *dev;
+ section_nr = __section_nr(section);
+ if (section_nr < 0) {
+ if (hintdev)
+ put_device(hintdev);
+ return NULL;
+ }
+
+ block_id = base_memory_block_id(section_nr);
dev = subsys_find_device_by_id(_subsys, block_id, hintdev);
- if (hint)
- put_device(>dev);
+ if (hintdev)
+ put_device(hintdev);
if (!dev)
return NULL;
return to_memory_block(dev);
@@ -664,6 +672,10 @@ static int init_memory_block(struct memory_block **memory,
return -ENOMEM;
scn_nr = __section_nr(section);
+
+ if (scn_nr < 0)
+ return scn_nr;
+
mem->start_section_nr =
base_memory_block_id(scn_nr) * sections_per_block;
mem->end_section_nr = mem->start_section_nr + sections_per_block - 1;
diff --git a/mm/sparse.c b/mm/sparse.c
index fd13166949b5..57a1a3d9c1cf 100644
--- a/mm/sparse.c
+++ b/mm/sparse.c
@@ -113,10 +113,15 @@ int __section_nr(struct mem_section* ms)
continue;
if ((ms >= root) && (ms < (root + SECTIONS_PER_ROOT)))
-break;
+ break;
}
VM_BUG_ON(!root);
+ if (root_nr == NR_SECTION_ROOTS) {
+ VM_BUG_ON(true);
+
+ return -EINVAL;
+ }
return (root_nr * SECTIONS_PER_ROOT) + (ms - root);
}
--
2.21.0
[PATCH v2 3/3] mm: Don't manually decrement num_poisoned_pages
From: Alastair D'Silva
Use the function written to do it instead.
Signed-off-by: Alastair D'Silva
---
mm/sparse.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/mm/sparse.c b/mm/sparse.c
index 1ec32aef5590..d9b3625bfdf0 100644
--- a/mm/sparse.c
+++ b/mm/sparse.c
@@ -11,6 +11,8 @@
#include
#include
#include
+#include
+#include
#include "internal.h"
#include
@@ -772,7 +774,7 @@ static void clear_hwpoisoned_pages(struct page *memmap,
for (i = start; i < start + count; i++) {
if (PageHWPoison([i])) {
- atomic_long_sub(1, _poisoned_pages);
+ num_poisoned_pages_dec();
ClearPageHWPoison([i]);
}
}
--
2.21.0
[PATCH v2 0/3] mm: Cleanup & allow modules to hotplug memory
From: Alastair D'Silva This series addresses some minor issues found when developing a persistent memory driver. Changelog: V2: - Drop mm/hotplug: export try_online_node (not necessary) - Return errors from __section_nr - Remove errant whitespace change in mm: don't hide potentially null memmap pointer - Rework mm: don't hide potentially null memmap pointer to use a start & count - Drop mm/hotplug: Avoid RCU stalls when removing large amounts of memory (similar patch already went in) Alastair D'Silva (3): mm: Trigger bug on if a section is not found in __section_nr mm: don't hide potentially null memmap pointer in sparse_remove_one_section mm: Don't manually decrement num_poisoned_pages drivers/base/memory.c | 18 +++--- mm/sparse.c | 21 +++-- 2 files changed, 30 insertions(+), 9 deletions(-) -- 2.21.0
Re: RX CRC errors on I219-V (6) 8086:15be
Hi Sasha at 5:09 PM, Kai-Heng Feng wrote: Hi Jeffrey, We’ve encountered another issue, which causes multiple CRC errors and renders ethernet completely useless, here’s the network stats: I also tried ignore_ltr for this issue, seems like it alleviates the symptom a bit for a while, then the network still becomes useless after some usage. And yes, it’s also a Whiskey Lake platform. What’s the next step to debug this problem? Kai-Heng /sys/class/net/eno1/statistics$ grep . * collisions:0 multicast:95 rx_bytes:1499851 rx_compressed:0 rx_crc_errors:1165 rx_dropped:0 rx_errors:2330 rx_fifo_errors:0 rx_frame_errors:0 rx_length_errors:0 rx_missed_errors:0 rx_nohandler:0 rx_over_errors:0 rx_packets:4789 tx_aborted_errors:0 tx_bytes:864312 tx_carrier_errors:0 tx_compressed:0 tx_dropped:0 tx_errors:0 tx_fifo_errors:0 tx_heartbeat_errors:0 tx_packets:7370 tx_window_errors:0 Same behavior can be observed on both mainline kernel and on your dev-queue branch. OTOH, the same issue can’t be observed on out-of-tree e1000e. Is there any plan to close the gap between upstream and out-of-tree version? Kai-Heng
[GIT PULL] csky fixup gcc unwind for v5.2
Hi Linus, Only one bugfix for v5.2, please pull. The following changes since commit 9e0babf2c06c73cda2c0cd37a1653d823adb40ec: Linux 5.2-rc5 (2019-06-16 08:49:45 -1000) are available in the git repository at: https://github.com/c-sky/csky-linux.git tags/csky-for-linus-5.2-fixup-gcc-unwind for you to fetch changes up to 19e5e2ae9c883f5651eaaeab2f258e2c4b78fda3: csky: Fixup libgcc unwind error (2019-06-26 13:45:48 +0800) arch/csky fixup for 5.2 Only 1 fixup patch for rt_sigframe in signal.c Guo Ren (1): csky: Fixup libgcc unwind error arch/csky/kernel/signal.c | 5 + 1 file changed, 5 insertions(+)
Re: [PATCH v8 1/5] mtd: cfi_cmdset_0002: Add support for polling status register
On 25/06/19 10:31 PM, Tokunori Ikegami wrote:
> Hi,
>
> Thanks for the fix.
>
> Reviewed-by: Tokunori Ikegami
>
> I have just tested the patch quickly on my local environment that uses
> the cfi_cmdset_0002 flash device but not HyperFlash family.
> So tested as not affected by the change.
>
Thanks for testing!
> On 2019/06/25 16:57, Vignesh Raghavendra wrote:
>> HyperFlash devices are compliant with CFI AMD/Fujitsu Extended Command
>> Set (0x0002) for flash operations, therefore
>> drivers/mtd/chips/cfi_cmdset_0002.c can be used as is. But these devices
>> do not support DQ polling method of determining chip ready/good status.
>> These flashes provide Status Register whose bits can be polled to know
>> status of flash operation.
>>
>> Cypress HyperFlash datasheet here[1], talks about CFI Amd/Fujitsu
>> Extended Query version 1.5. Bit 0 of "Software Features supported" field
>> of CFI Primary Vendor-Specific Extended Query table indicates
>> presence/absence of status register and Bit 1 indicates whether or not
>> DQ polling is supported. Using these bits, its possible to determine
>> whether flash supports DQ polling or need to use Status Register.
>>
>> Add support for polling Status Register to know device ready/status of
>> erase/write operations when DQ polling is not supported.
>> Print error messages on erase/program failure by looking at related
>> Status Register bits.
>>
>> [1] https://www.cypress.com/file/213346/download
>>
>> Signed-off-by: Vignesh Raghavendra
>> ---
>> v8:
>> Fix up status register polling to support banked flashes in patch 1/5.
>>
>>
>> drivers/mtd/chips/cfi_cmdset_0002.c | 130
>> include/linux/mtd/cfi.h | 7 ++
>> 2 files changed, 120 insertions(+), 17 deletions(-)
>>
>> diff --git a/drivers/mtd/chips/cfi_cmdset_0002.c
>> b/drivers/mtd/chips/cfi_cmdset_0002.c
>> index c8fa5906bdf9..09f8aaf1e763 100644
>> --- a/drivers/mtd/chips/cfi_cmdset_0002.c
>> +++ b/drivers/mtd/chips/cfi_cmdset_0002.c
>> @@ -49,6 +49,16 @@
>> #define SST49LF008A 0x005a
>> #define AT49BV6416 0x00d6
>> +/*
>> + * Status Register bit description. Used by flash devices that don't
>> + * support DQ polling (e.g. HyperFlash)
>> + */
>> +#define CFI_SR_DRB BIT(7)
>> +#define CFI_SR_ESB BIT(5)
>> +#define CFI_SR_PSB BIT(4)
>> +#define CFI_SR_WBASB BIT(3)
>> +#define CFI_SR_SLSB BIT(1)
>> +
>> static int cfi_amdstd_read (struct mtd_info *, loff_t, size_t,
>> size_t *, u_char *);
>> static int cfi_amdstd_write_words(struct mtd_info *, loff_t, size_t,
>> size_t *, const u_char *);
>> static int cfi_amdstd_write_buffers(struct mtd_info *, loff_t,
>> size_t, size_t *, const u_char *);
>> @@ -97,6 +107,50 @@ static struct mtd_chip_driver cfi_amdstd_chipdrv = {
>> .module = THIS_MODULE
>> };
>> +/*
>> + * Use status register to poll for Erase/write completion when DQ is not
>> + * supported. This is indicated by Bit[1:0] of SoftwareFeatures field in
>> + * CFI Primary Vendor-Specific Extended Query table 1.5
>> + */
>> +static int cfi_use_status_reg(struct cfi_private *cfi)
>> +{
>> + struct cfi_pri_amdstd *extp = cfi->cmdset_priv;
>> + u8 poll_mask = CFI_POLL_STATUS_REG | CFI_POLL_DQ;
>> +
>> + return extp->MinorVersion >= '5' &&
>> + (extp->SoftwareFeatures & poll_mask) == CFI_POLL_STATUS_REG;
>> +}
>> +
>> +static void cfi_check_err_status(struct map_info *map, struct flchip
>> *chip,
>
> Just a minor comment.
> I though that it is better to be called this function in chip_good()
> instead of to be called separately.
> But I can understand that the chip_good() is called repeatedly in
> do_erase_chip(), do_erase_oneblock() and do_write_buffer() until timeout.
> Also do_write_oneword() is also possible to be changed to call the
> chip_good() repeatedly instead of chip_ready().
> So additional logics is needed to avoid the repeated error messages in
> the function above.
> Anyway it is okay for the current implementation to me.
>
Will do that as an incremental change once base support for HyperFlash
is in.
Regards
Vignesh
> Regards,
> Ikegami
>
>> + unsigned long adr)
>> +{
>> + struct cfi_private *cfi = map->fldrv_priv;
>> + map_word status;
>> +
>> + if (!cfi_use_status_reg(cfi))
>> + return;
>> +
>> + cfi_send_gen_cmd(0x70, cfi->addr_unlock1, chip->start, map, cfi,
>> + cfi->device_type, NULL);
>> + status = map_read(map, adr);
>> +
>> + if (map_word_bitsset(map, status, CMD(0x3a))) {
>> + unsigned long chipstatus = MERGESTATUS(status);
>> +
>> + if (chipstatus & CFI_SR_ESB)
>> + pr_err("%s erase operation failed, status %lx\n",
>> + map->name, chipstatus);
>> + if (chipstatus & CFI_SR_PSB)
>> + pr_err("%s program operation failed, status %lx\n",
>> + map->name, chipstatus);
>> + if (chipstatus & CFI_SR_WBASB)
>> +
Re: [PATCH] orangefs: remove redundant assignment to variable buffer_index
On Tue, Jun 25, 2019 at 02:55:11PM -0400, Mike Marshall wrote: > >> You often send these patches before they hit linux-next so I had skipped > >> reviewing this one when you sent it. > > I know Linus is likely to refuse pull requests for stuff that > has not been through linux-next, so I make sure stuff has been > there at least a few days before asking for it to be pulled. > "A few days" is long enough for robots to see it, perhaps not > long enough for humans. I especially appreciate the human review. One of > the good things about Orangefs is that it is easy to install and configure, > especially for testing. Documentation/filesystems/orangefs.txt has > instructions for dnf installing orangefs on Fedora, and also how to download > a source tarball and install from that. No, no, that comment was to Colin. It's good that he's sending patches for all the trees as soon as possible like the zero day bot does. But it does make it hard to review at times. regards, dan carpenter
Re: [PATCH v2 1/3] mm: Trigger bug on if a section is not found in __section_nr
On Wed 26-06-19 16:11:21, Alastair D'Silva wrote:
> From: Alastair D'Silva
>
> If a memory section comes in where the physical address is greater than
> that which is managed by the kernel, this function would not trigger the
> bug and instead return a bogus section number.
>
> This patch tracks whether the section was actually found, and triggers the
> bug if not.
Why do we want/need that? In other words the changelog should contina
WHY and WHAT. This one contains only the later one.
> Signed-off-by: Alastair D'Silva
> ---
> drivers/base/memory.c | 18 +++---
> mm/sparse.c | 7 ++-
> 2 files changed, 21 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/base/memory.c b/drivers/base/memory.c
> index f180427e48f4..9244c122abf1 100644
> --- a/drivers/base/memory.c
> +++ b/drivers/base/memory.c
> @@ -585,13 +585,21 @@ int __weak arch_get_memory_phys_device(unsigned long
> start_pfn)
> struct memory_block *find_memory_block_hinted(struct mem_section *section,
> struct memory_block *hint)
> {
> - int block_id = base_memory_block_id(__section_nr(section));
> + int block_id, section_nr;
> struct device *hintdev = hint ? >dev : NULL;
> struct device *dev;
>
> + section_nr = __section_nr(section);
> + if (section_nr < 0) {
> + if (hintdev)
> + put_device(hintdev);
> + return NULL;
> + }
> +
> + block_id = base_memory_block_id(section_nr);
> dev = subsys_find_device_by_id(_subsys, block_id, hintdev);
> - if (hint)
> - put_device(>dev);
> + if (hintdev)
> + put_device(hintdev);
> if (!dev)
> return NULL;
> return to_memory_block(dev);
> @@ -664,6 +672,10 @@ static int init_memory_block(struct memory_block
> **memory,
> return -ENOMEM;
>
> scn_nr = __section_nr(section);
> +
> + if (scn_nr < 0)
> + return scn_nr;
> +
> mem->start_section_nr =
> base_memory_block_id(scn_nr) * sections_per_block;
> mem->end_section_nr = mem->start_section_nr + sections_per_block - 1;
> diff --git a/mm/sparse.c b/mm/sparse.c
> index fd13166949b5..57a1a3d9c1cf 100644
> --- a/mm/sparse.c
> +++ b/mm/sparse.c
> @@ -113,10 +113,15 @@ int __section_nr(struct mem_section* ms)
> continue;
>
> if ((ms >= root) && (ms < (root + SECTIONS_PER_ROOT)))
> - break;
> + break;
> }
>
> VM_BUG_ON(!root);
> + if (root_nr == NR_SECTION_ROOTS) {
> + VM_BUG_ON(true);
> +
> + return -EINVAL;
> + }
>
> return (root_nr * SECTIONS_PER_ROOT) + (ms - root);
> }
> --
> 2.21.0
--
Michal Hocko
SUSE Labs
Re: Steam is broken on new kernels
On Wed, Jun 26, 2019 at 06:20:17AM +0200, Eric Dumazet wrote:
> On Wed, Jun 26, 2019 at 5:43 AM Guenter Roeck wrote:
> >
> > On 6/25/19 7:29 PM, Greg Kroah-Hartman wrote:
> > > On Tue, Jun 25, 2019 at 07:02:20PM -0700, Guenter Roeck wrote:
> > >> Hi Greg,
> > >>
> > >> On Sat, Jun 22, 2019 at 09:37:53AM +0200, Greg Kroah-Hartman wrote:
> > >>> On Fri, Jun 21, 2019 at 10:28:21PM -0700, Linus Torvalds wrote:
> > On Fri, Jun 21, 2019 at 6:03 PM Pierre-Loup A. Griffais
> > wrote:
> > >
> > > I applied Eric's path to the tip of the branch and ran that kernel and
> > > the bug didn't occur through several logout / login cycles, so things
> > > look good at first glance. I'll keep running that kernel and report
> > > back
> > > if anything crops up in the future, but I believe we're good, beyond
> > > getting distros to ship this additional fix.
> >
> > Good. It's now in my tree, so we can get it quickly into stable and
> > then quickly to distributions.
> >
> > Greg, it's commit b6653b3629e5 ("tcp: refine memory limit test in
> > tcp_fragment()"), and I'm building it right now and I'll push it out
> > in a couple of minutes assuming nothing odd is going on.
> > >>>
> > >>> This looks good for 4.19 and 5.1, so I'll push out new stable kernels in
> > >>> a bit for them.
> > >>>
> > >>> But for 4.14 and older, we don't have the "hint" to know this is an
> > >>> outbound going packet and not to apply these checks at that point in
> > >>> time, so this patch doesn't work.
> > >>>
> > >>> I'll see if I can figure anything else later this afternoon for those
> > >>> kernels...
> > >>>
> > >>
> > >> I may have missed it, but I don't see a fix for the problem in
> > >> older stable branches. Any news ?
> > >>
> > >> One possibility might be be to apply the part of 75c119afe14f7 which
> > >> introduces TCP_FRAG_IN_WRITE_QUEUE and TCP_FRAG_IN_RTX_QUEUE, if that
> > >> is acceptable.
> > >
> > > That's what people have already discussed on the stable mailing list a
> > > few hours ago, hopefully a patch shows up soon as I'm traveling at the
> > > moment and can't do it myself...
> > >
> >
> > Sounds good. Let me know if nothing shows up; I'll be happy to do it
> > if needed.
>
>
> Without the rb-tree for rtx queues, old kernels are vulnerable to SACK
> attacks if sk_sndbuf is too big,
> so I would simply add a cushion in the test, instead of trying to
> backport an illusion of the rb-tree fixes.
>
>
>
> diff --git a/net/ipv4/tcp_output.c b/net/ipv4/tcp_output.c
> index
> a8772e11dc1cb42d4319b6fc072c625d284c7ad5..a554213afa4ac41120d781fe64b7cd18ff9b56e8
> 100644
> --- a/net/ipv4/tcp_output.c
> +++ b/net/ipv4/tcp_output.c
> @@ -1274,7 +1274,7 @@ int tcp_fragment(struct sock *sk, struct sk_buff
> *skb, u32 len,
> if (nsize < 0)
> nsize = 0;
>
> - if (unlikely((sk->sk_wmem_queued >> 1) > sk->sk_sndbuf)) {
> + if (unlikely((sk->sk_wmem_queued >> 1) > sk->sk_sndbuf + 131072)) {
> NET_INC_STATS(sock_net(sk), LINUX_MIB_TCPWQUEUETOOBIG);
> return -ENOMEM;
> }
That's a funny magic number, can we document what it means?
And yes, it's a much simpler patch, I'd rather take this than the fake
backport.
thanks,
greg k-h
Re: [PATCH v2 2/3] mm: don't hide potentially null memmap pointer in sparse_remove_one_section
On Wed 26-06-19 16:11:22, Alastair D'Silva wrote:
> From: Alastair D'Silva
>
> By adding offset to memmap before passing it in to clear_hwpoisoned_pages,
> we hide a potentially null memmap from the null check inside
> clear_hwpoisoned_pages.
>
> This patch passes the offset to clear_hwpoisoned_pages instead, allowing
> memmap to successfully peform it's null check.
Same issue with the changelog as the previous patch (missing WHY).
>
> Signed-off-by: Alastair D'Silva
> ---
> mm/sparse.c | 10 ++
> 1 file changed, 6 insertions(+), 4 deletions(-)
>
> diff --git a/mm/sparse.c b/mm/sparse.c
> index 57a1a3d9c1cf..1ec32aef5590 100644
> --- a/mm/sparse.c
> +++ b/mm/sparse.c
> @@ -753,7 +753,8 @@ int __meminit sparse_add_one_section(int nid, unsigned
> long start_pfn,
>
> #ifdef CONFIG_MEMORY_HOTREMOVE
> #ifdef CONFIG_MEMORY_FAILURE
> -static void clear_hwpoisoned_pages(struct page *memmap, int nr_pages)
> +static void clear_hwpoisoned_pages(struct page *memmap,
> + unsigned long start, unsigned long count)
> {
> int i;
>
> @@ -769,7 +770,7 @@ static void clear_hwpoisoned_pages(struct page *memmap,
> int nr_pages)
> if (atomic_long_read(_poisoned_pages) == 0)
> return;
>
> - for (i = 0; i < nr_pages; i++) {
> + for (i = start; i < start + count; i++) {
> if (PageHWPoison([i])) {
> atomic_long_sub(1, _poisoned_pages);
> ClearPageHWPoison([i]);
> @@ -777,7 +778,8 @@ static void clear_hwpoisoned_pages(struct page *memmap,
> int nr_pages)
> }
> }
> #else
> -static inline void clear_hwpoisoned_pages(struct page *memmap, int nr_pages)
> +static inline void clear_hwpoisoned_pages(struct page *memmap,
> + unsigned long start, unsigned long count)
> {
> }
> #endif
> @@ -824,7 +826,7 @@ void sparse_remove_one_section(struct zone *zone, struct
> mem_section *ms,
> ms->pageblock_flags = NULL;
> }
>
> - clear_hwpoisoned_pages(memmap + map_offset,
> + clear_hwpoisoned_pages(memmap, map_offset,
> PAGES_PER_SECTION - map_offset);
> free_section_usemap(memmap, usemap, altmap);
> }
> --
> 2.21.0
--
Michal Hocko
SUSE Labs
Re: [PATCH v2 3/3] mm: Don't manually decrement num_poisoned_pages
On Wed 26-06-19 16:11:23, Alastair D'Silva wrote:
> From: Alastair D'Silva
>
> Use the function written to do it instead.
I am not sure a single line helper is a great win but this makes the
code consistent at least.
> Signed-off-by: Alastair D'Silva
Acked-by: Michal Hocko
> ---
> mm/sparse.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/mm/sparse.c b/mm/sparse.c
> index 1ec32aef5590..d9b3625bfdf0 100644
> --- a/mm/sparse.c
> +++ b/mm/sparse.c
> @@ -11,6 +11,8 @@
> #include
> #include
> #include
> +#include
> +#include
>
> #include "internal.h"
> #include
> @@ -772,7 +774,7 @@ static void clear_hwpoisoned_pages(struct page *memmap,
>
> for (i = start; i < start + count; i++) {
> if (PageHWPoison([i])) {
> - atomic_long_sub(1, _poisoned_pages);
> + num_poisoned_pages_dec();
> ClearPageHWPoison([i]);
> }
> }
> --
> 2.21.0
--
Michal Hocko
SUSE Labs
Re: [PATCH] can: mcp251x: add error check when wq alloc failed
On 25/06/2019 16.03, Willem de Bruijn wrote: On Tue, Jun 25, 2019 at 8:51 AM Weitao Hou wrote: add error check when workqueue alloc failed, and remove redundant code to make it clear Signed-off-by: Weitao Hou Acked-by: Willem de Bruijn Tested-by: Sean Nyekjaer
Re: [PATCH] i2c: designware: Add disable runtime pm quirk
On 6/26/19 5:32 AM, AceLan Kao wrote:
Adding I2C_HID_QUIRK_NO_RUNTIME_PM quirk doesn't help on this issue.
Actually, Goodix touchpad already has that PM quirk in the list for other issue.
{ I2C_VENDOR_ID_GOODIX, I2C_DEVICE_ID_GOODIX_01F0,
I2C_HID_QUIRK_NO_RUNTIME_PM },
I also modify the code as you suggested, but no luck.
Yeah, I realized it won't help as the i2c-hid device is anyway powered
on constantly when the device is open by the pm_runtime_get_sync() call
in i2c_hid_open().
It's not Goodix takes time to wakeup, it's designware I2C controller.
Designware doesn't do anything wrong here, it's Goodix set the interrupt timeout
that leads to the issue, so we have to prevent designware from runtime
suspended.
But only on that bus where Goodix is connected and open by user space.
What I mean something like below:
diff --git a/drivers/hid/i2c-hid/i2c-hid-core.c
b/drivers/hid/i2c-hid/i2c-hid-core.c
index 90164fed08d3..bbeaa39ddc23 100644
--- a/drivers/hid/i2c-hid/i2c-hid-core.c
+++ b/drivers/hid/i2c-hid/i2c-hid-core.c
@@ -795,6 +795,9 @@ static int i2c_hid_open(struct hid_device *hid)
struct i2c_hid *ihid = i2c_get_clientdata(client);
int ret = 0;
+ /* some quirk test here */
+ pm_runtime_get_sync(>adapter->dev);
+
ret = pm_runtime_get_sync(>dev);
if (ret < 0)
return ret;
@@ -812,6 +815,9 @@ static void i2c_hid_close(struct hid_device *hid)
/* Save some power */
pm_runtime_put(>dev);
+
+ /* some quirk test here */
+ pm_runtime_put(>adapter->dev);
}
static int i2c_hid_power(struct hid_device *hid, int lvl)
--
Jarkko
Re: RX CRC errors on I219-V (6) 8086:15be
On 6/26/2019 09:14, Kai Heng Feng wrote: Hi Sasha at 5:09 PM, Kai-Heng Feng wrote: Hi Jeffrey, We’ve encountered another issue, which causes multiple CRC errors and renders ethernet completely useless, here’s the network stats: I also tried ignore_ltr for this issue, seems like it alleviates the symptom a bit for a while, then the network still becomes useless after some usage. And yes, it’s also a Whiskey Lake platform. What’s the next step to debug this problem? Kai-Heng CRC errors not related to the LTR. Please, try to disable the ME on your platform. Hope you have this option in BIOS. Another way is to contact your PC vendor and ask to provide NVM without ME. Let's start debugging with these steps. /sys/class/net/eno1/statistics$ grep . * collisions:0 multicast:95 rx_bytes:1499851 rx_compressed:0 rx_crc_errors:1165 rx_dropped:0 rx_errors:2330 rx_fifo_errors:0 rx_frame_errors:0 rx_length_errors:0 rx_missed_errors:0 rx_nohandler:0 rx_over_errors:0 rx_packets:4789 tx_aborted_errors:0 tx_bytes:864312 tx_carrier_errors:0 tx_compressed:0 tx_dropped:0 tx_errors:0 tx_fifo_errors:0 tx_heartbeat_errors:0 tx_packets:7370 tx_window_errors:0 Same behavior can be observed on both mainline kernel and on your dev-queue branch. OTOH, the same issue can’t be observed on out-of-tree e1000e. Is there any plan to close the gap between upstream and out-of-tree version? Kai-Heng
Re: [PATCH v2 1/3] mm: Trigger bug on if a section is not found in __section_nr
On Wed, 2019-06-26 at 08:21 +0200, Michal Hocko wrote: > On Wed 26-06-19 16:11:21, Alastair D'Silva wrote: > > From: Alastair D'Silva > > > > If a memory section comes in where the physical address is greater > > than > > that which is managed by the kernel, this function would not > > trigger the > > bug and instead return a bogus section number. > > > > This patch tracks whether the section was actually found, and > > triggers the > > bug if not. > > Why do we want/need that? In other words the changelog should contina > WHY and WHAT. This one contains only the later one. > Thanks, I'll update the comment. During driver development, I tried adding peristent memory at a memory address that exceeded the maximum permissable address for the platform. This caused __section_nr to silently return bogus section numbers, rather than complaining. -- Alastair D'Silva mob: 0423 762 819 skype: alastair_dsilva Twitter: @EvilDeece blog: http://alastair.d-silva.org
Re: [PATCH v2 2/3] mm: don't hide potentially null memmap pointer in sparse_remove_one_section
On Wed, 2019-06-26 at 08:23 +0200, Michal Hocko wrote: > On Wed 26-06-19 16:11:22, Alastair D'Silva wrote: > > From: Alastair D'Silva > > > > By adding offset to memmap before passing it in to > > clear_hwpoisoned_pages, > > we hide a potentially null memmap from the null check inside > > clear_hwpoisoned_pages. > > > > This patch passes the offset to clear_hwpoisoned_pages instead, > > allowing > > memmap to successfully peform it's null check. > > Same issue with the changelog as the previous patch (missing WHY). > The first paragraph explains what the problem is with the existing code (same applies to 1/3 too). -- Alastair D'Silva mob: 0423 762 819 skype: alastair_dsilva Twitter: @EvilDeece blog: http://alastair.d-silva.org
Re: [PATCH 6/9] KVM: x86: Provide paravirtualized flush_tlb_multi()
> On Jun 25, 2019, at 8:56 PM, Andy Lutomirski wrote:
>
> On Tue, Jun 25, 2019 at 8:41 PM Nadav Amit wrote:
>>> On Jun 25, 2019, at 8:35 PM, Andy Lutomirski wrote:
>>>
>>> On Tue, Jun 25, 2019 at 7:39 PM Nadav Amit wrote:
> On Jun 25, 2019, at 2:40 PM, Dave Hansen wrote:
>
> On 6/12/19 11:48 PM, Nadav Amit wrote:
>> Support the new interface of flush_tlb_multi, which also flushes the
>> local CPU's TLB, instead of flush_tlb_others that does not. This
>> interface is more performant since it parallelize remote and local TLB
>> flushes.
>>
>> The actual implementation of flush_tlb_multi() is almost identical to
>> that of flush_tlb_others().
>
> This confused me a bit. I thought we didn't support paravirtualized
> flush_tlb_multi() from reading earlier in the series.
>
> But, it seems like that might be Xen-only and doesn't apply to KVM and
> paravirtualized KVM has no problem supporting flush_tlb_multi(). Is
> that right? It might be good to include some of that background in the
> changelog to set the context.
I’ll try to improve the change-logs a bit. There is no inherent reason for
PV TLB-flushers not to implement their own flush_tlb_multi(). It is left
for future work, and here are some reasons:
1. Hyper-V/Xen TLB-flushing code is not very simple
2. I don’t have a proper setup
3. I am lazy
>>>
>>> In the long run, I think that we're going to want a way for one CPU to
>>> do a remote flush and then, with appropriate locking, update the
>>> tlb_gen fields for the remote CPU. Getting this right may be a bit
>>> nontrivial.
>>
>> What do you mean by “do a remote flush”?
>
> I mean a PV-assisted flush on a CPU other than the CPU that started
> it. If you look at flush_tlb_func_common(), it's doing some work that
> is rather fancier than just flushing the TLB. By replacing it with
> just a pure flush on Xen or Hyper-V, we're losing the potential CR3
> switch and this bit:
>
>/* Both paths above update our state to mm_tlb_gen. */
>this_cpu_write(cpu_tlbstate.ctxs[loaded_mm_asid].tlb_gen, mm_tlb_gen);
>
> Skipping the former can hurt idle performance, although we should
> consider just disabling all the lazy optimizations on systems with PV
> flush. (And I've asked Intel to help us out here in future hardware.
> I have no idea what the result of asking will be.) Skipping the
> cpu_tlbstate write means that we will do unnecessary flushes in the
> future, and that's not doing us any favors.
>
> In principle, we should be able to do something like:
>
> flush_tlb_multi(...);
> for(each CPU that got flushed) {
> spin_lock(something appropriate?);
> per_cpu_write(cpu, cpu_tlbstate.ctxs[loaded_mm_asid].tlb_gen,
> f->new_tlb_gen);
> spin_unlock(...);
> }
>
> with the caveat that it's more complicated than this if the flush is a
> partial flush, and that we'll want to check that the ctx_id still
> matches, etc.
>
> Does this make sense?
Thanks for the detailed explanation. Let me check that I got it right.
You want to optimize cases in which:
1. A virtual machine
2. Which issues mtultiple (remote) TLB shootdowns
2. To remote vCPU which is preempted by the hypervisor
4. And unlike KVM, the hypervisor does not provide facilities for the VM to
know which vCPU is preempted, and atomically request TLB flush when the vCPU
is scheduled.
Right?
Re: [PATCH v1 0/3] Add required-opps support to devfreq passive gov
On 24-06-19, 22:29, Saravana Kannan wrote: > No, the CPUs will be the "parent" and the cache will be the "child". > CPU is a special case when it comes to the actual software (not DT) as > we'll need the devfreq governor to look at all the CPUfreq policies to > decide the cache frequency (max of all their requirements). > > I think "master" and "slave" would have been a better term as the > master device determines its frequency using whatever means and the > "slave" device just "follows" the master device. Okay, so to confirm again this is what we will have: - CPUs are called masters and Caches are slaves. - The devfreq governor we are talking about takes care of changing frequency of caches (slaves) and chooses a target frequency for caches based on what the masters are running at. - The CPUs OPP nodes will have required-opps property and will be pointing to the caches OPP nodes. The CPUs may already be using required-opps node for PM domain performance state thing. Now the problem is "required-opp" means something really *required* and it is not optional. Like a specific voltage level before we can switch to a particular frequency. And this is how I have though of it until now. And this shouldn't be handled asynchronously, i.e. required OPPs must be set while configuring OPP of a device. So, when a CPU changes frequency, we must change the performance state of PM domain and change frequency/bw of the cache synchronously. And in such a case "required-opps" can be a very good fit for this use case. But with what you are trying to do it is no longer required-opp but good-to-have-opp. And that worries me. -- viresh
Re: [PATCH V3 2/3] thermal/drivers/cpu_cooling: Unregister with the policy
On 26-06-19, 08:02, Daniel Lezcano wrote:
> On 26/06/2019 04:58, Viresh Kumar wrote:
> > On 25-06-19, 13:32, Daniel Lezcano wrote:
> >> diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
> >> index aee024e42618..f07454249fbc 100644
> >> --- a/drivers/cpufreq/cpufreq.c
> >> +++ b/drivers/cpufreq/cpufreq.c
> >> @@ -1379,8 +1379,8 @@ static int cpufreq_online(unsigned int cpu)
> >>cpufreq_driver->ready(policy);
> >>
> >>if (cpufreq_thermal_control_enabled(cpufreq_driver))
> >> - policy->cdev = of_cpufreq_cooling_register(policy);
> >> -
> >> + of_cpufreq_cooling_register(policy);
> >> +
> >
> > We don't need any error checking here anymore ?
>
> There was no error checking initially. This comment and the others below
> are for an additional patch IMO, not a change in this one.
right, but ...
> >> -void cpufreq_cooling_unregister(struct thermal_cooling_device *cdev)
> >> +void cpufreq_cooling_unregister(struct cpufreq_policy *policy)
> >> {
> >>struct cpufreq_cooling_device *cpufreq_cdev;
> >>bool last;
> >>
> >> - if (!cdev)
> >> - return;
we used to return without any errors from here. Now we will have
problems if regsitering fails for some reason.
--
viresh
Re: Steam is broken on new kernels
On Wed, Jun 26, 2019 at 8:22 AM Greg Kroah-Hartman
wrote:
>
> On Wed, Jun 26, 2019 at 06:20:17AM +0200, Eric Dumazet wrote:
> > On Wed, Jun 26, 2019 at 5:43 AM Guenter Roeck wrote:
> > >
> > > On 6/25/19 7:29 PM, Greg Kroah-Hartman wrote:
> > > > On Tue, Jun 25, 2019 at 07:02:20PM -0700, Guenter Roeck wrote:
> > > >> Hi Greg,
> > > >>
> > > >> On Sat, Jun 22, 2019 at 09:37:53AM +0200, Greg Kroah-Hartman wrote:
> > > >>> On Fri, Jun 21, 2019 at 10:28:21PM -0700, Linus Torvalds wrote:
> > > On Fri, Jun 21, 2019 at 6:03 PM Pierre-Loup A. Griffais
> > > wrote:
> > > >
> > > > I applied Eric's path to the tip of the branch and ran that kernel
> > > > and
> > > > the bug didn't occur through several logout / login cycles, so
> > > > things
> > > > look good at first glance. I'll keep running that kernel and report
> > > > back
> > > > if anything crops up in the future, but I believe we're good, beyond
> > > > getting distros to ship this additional fix.
> > >
> > > Good. It's now in my tree, so we can get it quickly into stable and
> > > then quickly to distributions.
> > >
> > > Greg, it's commit b6653b3629e5 ("tcp: refine memory limit test in
> > > tcp_fragment()"), and I'm building it right now and I'll push it out
> > > in a couple of minutes assuming nothing odd is going on.
> > > >>>
> > > >>> This looks good for 4.19 and 5.1, so I'll push out new stable kernels
> > > >>> in
> > > >>> a bit for them.
> > > >>>
> > > >>> But for 4.14 and older, we don't have the "hint" to know this is an
> > > >>> outbound going packet and not to apply these checks at that point in
> > > >>> time, so this patch doesn't work.
> > > >>>
> > > >>> I'll see if I can figure anything else later this afternoon for those
> > > >>> kernels...
> > > >>>
> > > >>
> > > >> I may have missed it, but I don't see a fix for the problem in
> > > >> older stable branches. Any news ?
> > > >>
> > > >> One possibility might be be to apply the part of 75c119afe14f7 which
> > > >> introduces TCP_FRAG_IN_WRITE_QUEUE and TCP_FRAG_IN_RTX_QUEUE, if that
> > > >> is acceptable.
> > > >
> > > > That's what people have already discussed on the stable mailing list a
> > > > few hours ago, hopefully a patch shows up soon as I'm traveling at the
> > > > moment and can't do it myself...
> > > >
> > >
> > > Sounds good. Let me know if nothing shows up; I'll be happy to do it
> > > if needed.
> >
> >
> > Without the rb-tree for rtx queues, old kernels are vulnerable to SACK
> > attacks if sk_sndbuf is too big,
> > so I would simply add a cushion in the test, instead of trying to
> > backport an illusion of the rb-tree fixes.
> >
> >
> >
> > diff --git a/net/ipv4/tcp_output.c b/net/ipv4/tcp_output.c
> > index
> > a8772e11dc1cb42d4319b6fc072c625d284c7ad5..a554213afa4ac41120d781fe64b7cd18ff9b56e8
> > 100644
> > --- a/net/ipv4/tcp_output.c
> > +++ b/net/ipv4/tcp_output.c
> > @@ -1274,7 +1274,7 @@ int tcp_fragment(struct sock *sk, struct sk_buff
> > *skb, u32 len,
> > if (nsize < 0)
> > nsize = 0;
> >
> > - if (unlikely((sk->sk_wmem_queued >> 1) > sk->sk_sndbuf)) {
> > + if (unlikely((sk->sk_wmem_queued >> 1) > sk->sk_sndbuf + 131072)) {
> > NET_INC_STATS(sock_net(sk), LINUX_MIB_TCPWQUEUETOOBIG);
> > return -ENOMEM;
> > }
>
> That's a funny magic number, can we document what it means?
This is because TCP can cook skb with about 64KB of payload in
tcp_sendmsg() before
checking if memory limits are exceeded. (This is mentioned in commit
b6653b3629e5b88202be3c9abc44713973f5c4b4
" tcp: refine memory limit test in tcp_fragment()" changelog)
Then, if this giant TSO skb needs to be split in ~45 smaller skbs of
one segment each,
the resulting truesize might be twice bigger.
You could use 2 * 65536 if that looks better, and possibly a macro,
but I feel that adding a macro for this one particular spot and
stable kernels might be overkill ?
>
> And yes, it's a much simpler patch, I'd rather take this than the fake
> backport.
Re: [PATCH v3 2/3] mm, oom: remove redundant task_in_mem_cgroup() check
On Mon 24-06-19 14:26:30, Shakeel Butt wrote:
> oom_unkillable_task() can be called from three different contexts i.e.
> global OOM, memcg OOM and oom_score procfs interface. At the moment
> oom_unkillable_task() does a task_in_mem_cgroup() check on the given
> process. Since there is no reason to perform task_in_mem_cgroup()
> check for global OOM and oom_score procfs interface, those contexts
> provide NULL memcg and skips the task_in_mem_cgroup() check. However for
> memcg OOM context, the oom_unkillable_task() is always called from
> mem_cgroup_scan_tasks() and thus task_in_mem_cgroup() check becomes
> redundant. So, just remove the task_in_mem_cgroup() check altogether.
Just a nit. Not only it is redundant but it is effectively a dead code
after your previous patch.
> Signed-off-by: Shakeel Butt
> Signed-off-by: Tetsuo Handa
Acked-by: Michal Hocko
Thanks!
> ---
> Changelog since v2:
> - Further divided the patch into two patches.
> - Incorporated the task_in_mem_cgroup() from Tetsuo.
>
> Changelog since v1:
> - Divide the patch into two patches.
>
> fs/proc/base.c | 2 +-
> include/linux/memcontrol.h | 7 ---
> include/linux/oom.h| 2 +-
> mm/memcontrol.c| 26 --
> mm/oom_kill.c | 19 +++
> 5 files changed, 9 insertions(+), 47 deletions(-)
>
> diff --git a/fs/proc/base.c b/fs/proc/base.c
> index b8d5d100ed4a..5eacce5e924a 100644
> --- a/fs/proc/base.c
> +++ b/fs/proc/base.c
> @@ -532,7 +532,7 @@ static int proc_oom_score(struct seq_file *m, struct
> pid_namespace *ns,
> unsigned long totalpages = totalram_pages() + total_swap_pages;
> unsigned long points = 0;
>
> - points = oom_badness(task, NULL, NULL, totalpages) *
> + points = oom_badness(task, NULL, totalpages) *
> 1000 / totalpages;
> seq_printf(m, "%lu\n", points);
>
> diff --git a/include/linux/memcontrol.h b/include/linux/memcontrol.h
> index 9abf31bbe53a..2cbce1fe7780 100644
> --- a/include/linux/memcontrol.h
> +++ b/include/linux/memcontrol.h
> @@ -407,7 +407,6 @@ static inline struct lruvec *mem_cgroup_lruvec(struct
> pglist_data *pgdat,
>
> struct lruvec *mem_cgroup_page_lruvec(struct page *, struct pglist_data *);
>
> -bool task_in_mem_cgroup(struct task_struct *task, struct mem_cgroup *memcg);
> struct mem_cgroup *mem_cgroup_from_task(struct task_struct *p);
>
> struct mem_cgroup *get_mem_cgroup_from_mm(struct mm_struct *mm);
> @@ -896,12 +895,6 @@ static inline bool mm_match_cgroup(struct mm_struct *mm,
> return true;
> }
>
> -static inline bool task_in_mem_cgroup(struct task_struct *task,
> - const struct mem_cgroup *memcg)
> -{
> - return true;
> -}
> -
> static inline struct mem_cgroup *get_mem_cgroup_from_mm(struct mm_struct *mm)
> {
> return NULL;
> diff --git a/include/linux/oom.h b/include/linux/oom.h
> index d07992009265..b75104690311 100644
> --- a/include/linux/oom.h
> +++ b/include/linux/oom.h
> @@ -108,7 +108,7 @@ static inline vm_fault_t
> check_stable_address_space(struct mm_struct *mm)
> bool __oom_reap_task_mm(struct mm_struct *mm);
>
> extern unsigned long oom_badness(struct task_struct *p,
> - struct mem_cgroup *memcg, const nodemask_t *nodemask,
> + const nodemask_t *nodemask,
> unsigned long totalpages);
>
> extern bool out_of_memory(struct oom_control *oc);
> diff --git a/mm/memcontrol.c b/mm/memcontrol.c
> index db46a9dc37ab..27c92c2b99be 100644
> --- a/mm/memcontrol.c
> +++ b/mm/memcontrol.c
> @@ -1259,32 +1259,6 @@ void mem_cgroup_update_lru_size(struct lruvec *lruvec,
> enum lru_list lru,
> *lru_size += nr_pages;
> }
>
> -bool task_in_mem_cgroup(struct task_struct *task, struct mem_cgroup *memcg)
> -{
> - struct mem_cgroup *task_memcg;
> - struct task_struct *p;
> - bool ret;
> -
> - p = find_lock_task_mm(task);
> - if (p) {
> - task_memcg = get_mem_cgroup_from_mm(p->mm);
> - task_unlock(p);
> - } else {
> - /*
> - * All threads may have already detached their mm's, but the oom
> - * killer still needs to detect if they have already been oom
> - * killed to prevent needlessly killing additional tasks.
> - */
> - rcu_read_lock();
> - task_memcg = mem_cgroup_from_task(task);
> - css_get(_memcg->css);
> - rcu_read_unlock();
> - }
> - ret = mem_cgroup_is_descendant(task_memcg, memcg);
> - css_put(_memcg->css);
> - return ret;
> -}
> -
> /**
> * mem_cgroup_margin - calculate chargeable space of a memory cgroup
> * @memcg: the memory cgroup
> diff --git a/mm/oom_kill.c b/mm/oom_kill.c
> index bd80997e0969..e0cdcbd58b0b 100644
> --- a/mm/oom_kill.c
> +++ b/mm/oom_kill.c
> @@ -153,17 +153,13 @@ static inline bool is_memcg_oom(struct
Re: [PATCH 1/3] lib/vdso: Delay mask application in do_hres()
On Tue, 25 Jun 2019, Thomas Gleixner wrote: > On Tue, 25 Jun 2019, Vincenzo Frascino wrote: > > do_hres() in the vDSO generic library masks the hw counter value > > immediately after reading it. > > > > Postpone the mask application after checking if the syscall fallback is > > enabled, in order to be able to detect a possible fallback for the > > architectures that have masks smaller than ULLONG_MAX. > > Right. This only worked on x86 because the mask is there ULLONG_MAX for all > VDSO capable clocksources, i.e. that ever worked just by chance. But it's actually worse than that: > > + cycles &= vd->mask; > > if (cycles > last) > > ns += (cycles - last) * vd->mult; > > ns >>= vd->shift; This is broken for any clocksource which can legitimately wrap around. The core timekeeping does the right thing: (cycles - last) & mask That makes sure that a wraparound is correctly handled. With the above the wrap around would be ignored due to if (cycles > last) Stupid me. I should have added big fat comments to the x86 vdso why this all works correctly and only correctly for the x86 crud. That was part of squeezing the last cycles out of the vdso. Sorry for not noticing earlier. Working on a fix. Thanks, tglx
RE: [PATCH] reset: Add driver for dispmix reset
Hi Philipp, Thanks for your comments. And please see my answers below. -Original Message- From: Philipp Zabel Sent: Tuesday, June 25, 2019 10:57 PM To: Fancy Fang ; shawn...@kernel.org; s.ha...@pengutronix.de Cc: feste...@gmail.com; ker...@pengutronix.de; linux-arm-ker...@lists.infradead.org; linux-kernel@vger.kernel.org; dl-linux-imx Subject: Re: [PATCH] reset: Add driver for dispmix reset Hi Fancy, thank you for the patch. I have a few questions below. On Tue, 2019-06-25 at 05:54 +, Fancy Fang wrote: > This is an reset driver to implement a reset controller device DISPMIX > on IMX8MM and IMX8MN platforms. Dispmix reset is used to reset or > enable related buses and clks for the submodules in DISPMIX. Unfortunately DISPMIX is not very well documented, so forgive my ignorance. It looks to me like some of those bits don't control reset lines, but are used to gate clocks. Especially the i.MX8MN DISPMIX bits with clock enable bits and corresponding resets look like this should just be a clock controller that automatically (de)asserts the resets as necessary when clocks are enabled. The same goes for the clock soft enable bits on i.MX8MM. If those bits actually control clock gates, they should not be described as reset controls in the device tree. [FF] Make sense. The functions provided by the "dispmix reset" is more likely to be a combination of a clock gating module and a reset control than a standard reset controller. The reason why I choose reset framework to implement this device is that: First, this module is named as "dispmix reset" in the dispmix's design spec, so it gives me the first impression that it should be acted as a reset controller. And I'll check this with the IC designer Second, the "dispmix reset" is separated from the CCM LPCG module which is used as the only clock controller device for the whole platform. So the CCM clock driver seems cannot cover this device. Last, the "dispmix reset" is shared by all the submodules in the dispmix, so I abstract this device to be a reset controller driver to simplify the 'reset' logic for all the submodules drivers. If using clock framework to cover this device, another driver needs to be implemented. I'll take a close look at it to see if this can happen. > All the dispmix resets are divided into three subgroups: > sft_rstn, clk_en and mipi_rst, and each of them contains several reset > lines to control several different modules on and off in DISPMIX which > doesn't require the standard reset flow, but only line assert and > deassert operations. > > Signed-off-by: Fancy Fang > --- > .../bindings/reset/nxp,dispmix-clk-en.txt | 58 +++ > .../bindings/reset/nxp,dispmix-mipi-rst.txt | 57 +++ > .../bindings/reset/nxp,dispmix-sft-rstn.txt | 58 +++ > drivers/reset/Kconfig | 9 + > drivers/reset/Makefile| 1 + > drivers/reset/reset-dispmix.c | 399 ++ > include/dt-bindings/reset/imx8mm-dispmix.h| 49 +++ > include/dt-bindings/reset/imx8mn-dispmix.h| 47 +++ > 8 files changed, 678 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/reset/nxp,dispmix-clk-en.txt > create mode 100644 > Documentation/devicetree/bindings/reset/nxp,dispmix-mipi-rst.txt > create mode 100644 > Documentation/devicetree/bindings/reset/nxp,dispmix-sft-rstn.txt > create mode 100644 drivers/reset/reset-dispmix.c create mode 100644 > include/dt-bindings/reset/imx8mm-dispmix.h > create mode 100644 include/dt-bindings/reset/imx8mn-dispmix.h > > diff --git > a/Documentation/devicetree/bindings/reset/nxp,dispmix-clk-en.txt > b/Documentation/devicetree/bindings/reset/nxp,dispmix-clk-en.txt > new file mode 100644 > index ..4375039eb072 > --- /dev/null > +++ b/Documentation/devicetree/bindings/reset/nxp,dispmix-clk-en.txt > @@ -0,0 +1,58 @@ > +NXP Display Mix clk-en Reset Controller > +=== > + > +This binding describes a reset controller device that is used to > +enable or disable the internal clocks for all the submodules(such as, > +LCDIF, MIPI DSI, MIPI CSI, ISI and etc) included by the Display Mix > +subsystem on IMX8MM and IMX8MN platforms. Like sft-rstn, only assert > +and deassert functions are required for submodule internal clocks > +enable or disable, ^^ See, doesn't this sound like it should be a clock driver? [FF] As described above. > +that means the clk-en can be treated as a real reset controller. > + > +Please also refer to reset.txt in this directory for common reset > +controller binding usage. > + > +Required properties: > +- compatible: Should be "fsl,imx8mm-dispmix-clk-en" or > + "fsl,imx8mn-dispmix-clk-en". > +- reg: should be register base and length as documented in the datasheet. > +- clocks: phandle and clock specifier to disp apb clock for
Re: [LINUX PATCH v17 1/2] mtd: rawnand: nand_micron: Do not over write driver's read_page()/write_page()
On Mon, 24 Jun 2019 22:46:29 -0600
Naga Sureshkumar Relli wrote:
> Add check before assigning chip->ecc.read_page() and chip->ecc.write_page()
>
> Signed-off-by: Naga Sureshkumar Relli
> ---
> drivers/mtd/nand/raw/nand_micron.c | 7 +--
> 1 file changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/mtd/nand/raw/nand_micron.c
> b/drivers/mtd/nand/raw/nand_micron.c
> index cbd4f09ac178..565f2696c747 100644
> --- a/drivers/mtd/nand/raw/nand_micron.c
> +++ b/drivers/mtd/nand/raw/nand_micron.c
> @@ -500,8 +500,11 @@ static int micron_nand_init(struct nand_chip *chip)
> chip->ecc.size = 512;
> chip->ecc.strength = chip->base.eccreq.strength;
> chip->ecc.algo = NAND_ECC_BCH;
> - chip->ecc.read_page = micron_nand_read_page_on_die_ecc;
> - chip->ecc.write_page = micron_nand_write_page_on_die_ecc;
> + if (!chip->ecc.read_page)
> + chip->ecc.read_page = micron_nand_read_page_on_die_ecc;
> +
> + if (!chip->ecc.write_page)
> + chip->ecc.write_page =
> micron_nand_write_page_on_die_ecc;
That's wrong, if you don't want on-die ECC to be used, simply don't set
nand-ecc-mode to "on-die".
>
> if (ondie == MICRON_ON_DIE_MANDATORY) {
> chip->ecc.read_page_raw = nand_read_page_raw_notsupp;
Re: DMA coherency in drivers/tty/serial/mpsc.c
On Tue, Jun 25, 2019 at 09:37:22AM -0700, Mark Greer wrote: > Yeah, the mpsc driver had lots of ugly cache related hacks because of > cache coherency bugs in the early version of the MV64x60 bridge chips > that it was embedded in. That chip is pretty much dead now and I've > removed core support for it from the powerpc tree. Removing the mpsc > driver is on my todo list but I've been busy and lazy. So, to sum it > up, don't spend any more time worrying about it as it should be removed. > > I'll post a patch to do that tonight and I'm sorry for any time you've > spent looking at it so far. No problem. And if future such broken chips show up we now have support for per-device DMA coherency settings and could actually handle it in a reaѕonably clean way.
[PATCH 1/1] perf annotate csky: Add perf annotate support
This patch add basic arch initialization and instruction associate support
for csky.
perf annotate --stdio2
Samples: 161 of event 'cpu-clock:pppH', 4000 Hz, Event count (approx.):
4025, [percent: local period]
test_4() /usr/lib/perf-test/callchain_test
Percent
Disassembly of section .text:
8420 :
test_4():
subi sp, sp, 4
st.w r8, (sp, 0x0)
mov r8, sp
subi sp, sp, 8
subi r3, r8, 4
movi r2, 0
st.w r2, (r3, 0x0)
↓ br2e
100.00 14: subi r3, r8, 4
ld.w r2, (r3, 0x0)
subi r3, r8, 8
st.w r2, (r3, 0x0)
subi r3, r8, 4
ld.w r3, (r3, 0x0)
addi r2, r3, 1
subi r3, r8, 4
st.w r2, (r3, 0x0)
2e: subi r3, r8, 4
ld.w r2, (r3, 0x0)
lrw r3, 0x98967f// 8598
cmplt r3, r2
↑ bf14
mov r0, r0
mov r0, r0
mov sp, r8
ld.w r8, (sp, 0x0)
addi sp, sp, 4
← rts
Signed-off-by: Mao Han
Cc: Guo Ren
Cc: Peter Zijlstra
Cc: Ingo Molnar
Cc: Arnaldo Carvalho de Melo
Cc: Alexander Shishkin
Cc: Jiri Olsa
Cc: Namhyung Kim
---
tools/perf/arch/csky/annotate/instructions.c | 48
tools/perf/util/annotate.c | 5 +++
2 files changed, 53 insertions(+)
create mode 100644 tools/perf/arch/csky/annotate/instructions.c
diff --git a/tools/perf/arch/csky/annotate/instructions.c
b/tools/perf/arch/csky/annotate/instructions.c
new file mode 100644
index 000..5337bfb
--- /dev/null
+++ b/tools/perf/arch/csky/annotate/instructions.c
@@ -0,0 +1,48 @@
+// SPDX-License-Identifier: GPL-2.0
+// Copyright (C) 2019 Hangzhou C-SKY Microsystems co.,ltd.
+
+#include
+
+static struct ins_ops *csky__associate_ins_ops(struct arch *arch,
+ const char *name)
+{
+ struct ins_ops *ops = NULL;
+
+ /* catch all kind of jumps */
+ if (!strcmp(name, "bt") ||
+ !strcmp(name, "bf") ||
+ !strcmp(name, "bez") ||
+ !strcmp(name, "bnez") ||
+ !strcmp(name, "bnezad") ||
+ !strcmp(name, "bhsz") ||
+ !strcmp(name, "bhz") ||
+ !strcmp(name, "blsz") ||
+ !strcmp(name, "blz") ||
+ !strcmp(name, "br") ||
+ !strcmp(name, "jmpi") ||
+ !strcmp(name, "jmp"))
+ ops = _ops;
+
+ /* catch function call */
+ if (!strcmp(name, "bsr") ||
+ !strcmp(name, "jsri") ||
+ !strcmp(name, "jsr"))
+ ops = _ops;
+
+ /* catch function return */
+ if (!strcmp(name, "rts"))
+ ops = _ops;
+
+ if (ops)
+ arch__associate_ins_ops(arch, name, ops);
+ return ops;
+}
+
+static int csky__annotate_init(struct arch *arch, char *cpuid __maybe_unused)
+{
+ arch->initialized = true;
+ arch->objdump.comment_char = '/';
+ arch->associate_instruction_ops = csky__associate_ins_ops;
+
+ return 0;
+}
diff --git a/tools/perf/util/annotate.c b/tools/perf/util/annotate.c
index 79db038..eb2456e 100644
--- a/tools/perf/util/annotate.c
+++ b/tools/perf/util/annotate.c
@@ -144,6 +144,7 @@ static int arch__associate_ins_ops(struct arch* arch, const
char *name, struct i
#include "arch/arc/annotate/instructions.c"
#include "arch/arm/annotate/instructions.c"
#include "arch/arm64/annotate/instructions.c"
+#include "arch/csky/annotate/instructions.c"
#include "arch/x86/annotate/instructions.c"
#include "arch/powerpc/annotate/instructions.c"
#include "arch/s390/annotate/instructions.c"
@@ -163,6 +164,10 @@ static struct arch architectures[] = {
.init = arm64__annotate_init,
},
{
+ .name = "csky",
+ .init = csky__annotate_init,
+ },
+ {
.name = "x86",
.init = x86__annotate_init,
.instructions = x86__instructions,
--
2.7.4
Re: [PATCH v3 3/3] oom: decouple mems_allowed from oom_unkillable_task
On Mon 24-06-19 14:26:31, Shakeel Butt wrote:
> The commit ef08e3b4981a ("[PATCH] cpusets: confine oom_killer to
> mem_exclusive cpuset") introduces a heuristic where a potential
> oom-killer victim is skipped if the intersection of the potential victim
> and the current (the process triggered the oom) is empty based on the
> reason that killing such victim most probably will not help the current
> allocating process. However the commit 7887a3da753e ("[PATCH] oom:
> cpuset hint") changed the heuristic to just decrease the oom_badness
> scores of such potential victim based on the reason that the cpuset of
> such processes might have changed and previously they might have
> allocated memory on mems where the current allocating process can
> allocate from.
>
> Unintentionally commit 7887a3da753e ("[PATCH] oom: cpuset hint")
> introduced a side effect as the oom_badness is also exposed to the
> user space through /proc/[pid]/oom_score, so, readers with different
> cpusets can read different oom_score of th same process.
>
> Later the commit 6cf86ac6f36b ("oom: filter tasks not sharing the same
> cpuset") fixed the side effect introduced by 7887a3da753e by moving the
> cpuset intersection back to only oom-killer context and out of
> oom_badness. However the combination of the commit ab290adbaf8f ("oom:
> make oom_unkillable_task() helper function") and commit 26ebc984913b
> ("oom: /proc//oom_score treat kernel thread honestly")
> unintentionally brought back the cpuset intersection check into the
> oom_badness calculation function.
Thanks for this excursion into the history. I think it is very useful.
> Other than doing cpuset/mempolicy intersection from oom_badness, the
> memcg oom context is also doing cpuset/mempolicy intersection which is
> quite wrong and is caught by syzcaller with the following report:
>
> kasan: CONFIG_KASAN_INLINE enabled
> kasan: GPF could be caused by NULL-ptr deref or user memory access
> general protection fault: [#1] PREEMPT SMP KASAN
> CPU: 0 PID: 28426 Comm: syz-executor.5 Not tainted 5.2.0-rc3-next-20190607
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> Google 01/01/2011
> RIP: 0010:__read_once_size include/linux/compiler.h:194 [inline]
> RIP: 0010:has_intersects_mems_allowed mm/oom_kill.c:84 [inline]
> RIP: 0010:oom_unkillable_task mm/oom_kill.c:168 [inline]
> RIP: 0010:oom_unkillable_task+0x180/0x400 mm/oom_kill.c:155
> Code: c1 ea 03 80 3c 02 00 0f 85 80 02 00 00 4c 8b a3 10 07 00 00 48 b8 00
> 00 00 00 00 fc ff df 4d 8d 74 24 10 4c 89 f2 48 c1 ea 03 <80> 3c 02 00 0f
> 85 67 02 00 00 49 8b 44 24 10 4c 8d a0 68 fa ff ff
> RSP: 0018:888000127490 EFLAGS: 00010a03
> RAX: dc00 RBX: 8880a4cd5438 RCX: 818dae9c
> RDX: 1c3cc602 RSI: 818dac8d RDI: 0001
> RBP: 8880001274d0 R08: 88886180 R09: ed1015d26be0
> R10: ed1015d26bdf R11: 8880ae935efb R12: 800061e63007
> R13: R14: 800061e63017 R15: 11124ea6
> FS: 561f5940() GS:8880ae80() knlGS:
> CS: 0010 DS: ES: CR0: 80050033
> CR2: 00607304 CR3: 9237e000 CR4: 001426f0
> DR0: DR1: DR2:
> DR3: DR6: fffe0ff0 DR7: 0600
> Call Trace:
> oom_evaluate_task+0x49/0x520 mm/oom_kill.c:321
> mem_cgroup_scan_tasks+0xcc/0x180 mm/memcontrol.c:1169
> select_bad_process mm/oom_kill.c:374 [inline]
> out_of_memory mm/oom_kill.c:1088 [inline]
> out_of_memory+0x6b2/0x1280 mm/oom_kill.c:1035
> mem_cgroup_out_of_memory+0x1ca/0x230 mm/memcontrol.c:1573
> mem_cgroup_oom mm/memcontrol.c:1905 [inline]
> try_charge+0xfbe/0x1480 mm/memcontrol.c:2468
> mem_cgroup_try_charge+0x24d/0x5e0 mm/memcontrol.c:6073
> mem_cgroup_try_charge_delay+0x1f/0xa0 mm/memcontrol.c:6088
> do_huge_pmd_wp_page_fallback+0x24f/0x1680 mm/huge_memory.c:1201
> do_huge_pmd_wp_page+0x7fc/0x2160 mm/huge_memory.c:1359
> wp_huge_pmd mm/memory.c:3793 [inline]
> __handle_mm_fault+0x164c/0x3eb0 mm/memory.c:4006
> handle_mm_fault+0x3b7/0xa90 mm/memory.c:4053
> do_user_addr_fault arch/x86/mm/fault.c:1455 [inline]
> __do_page_fault+0x5ef/0xda0 arch/x86/mm/fault.c:1521
> do_page_fault+0x71/0x57d arch/x86/mm/fault.c:1552
> page_fault+0x1e/0x30 arch/x86/entry/entry_64.S:1156
> RIP: 0033:0x400590
> Code: 06 e9 49 01 00 00 48 8b 44 24 10 48 0b 44 24 28 75 1f 48 8b 14 24 48
> 8b 7c 24 20 be 04 00 00 00 e8 f5 56 00 00 48 8b 74 24 08 <89> 06 e9 1e 01
> 00 00 48 8b 44 24 08 48 8b 14 24 be 04 00 00 00 8b
> RSP: 002b:7fff7bc49780 EFLAGS: 00010206
> RAX: 0001 RBX: 0076 RCX:
> RDX: RSI: 2000cffc RDI: 0001
> RBP: fffe R08: R09:
> R10: 0075 R11: 0246 R12: 00760008
> R13: 004c55f2 R14:
Re: [PATCH 2/4] mfd: Add initial MFD driver for ATC260x PMICs
On Mon, 17 Jun 2019, Manivannan Sadhasivam wrote:
> Add initial MFD driver for Actions Semi ATC260x PMICs. ATC260x series
> PMICs integrates Audio Codec, Power management, Clock generation, and GPIO
> controller blocks. This driver only supports Regulator functionality on
> ATC2609A PMIC variant for now.
Until you supply other functionality, this is not an MFD.
Please add additional support for more child devices.
> Since the PMICs can be accessed using both I2C and SPI busses, following
> driver structure has been adapted:
>
>->atc260x-core.c (Implements core funtionalities)
> /
> ATC260x->atc260x-i2c.c (Implements I2C interface)
> \
>->atc2609a-helpers.c (Implements ATC2609A specific helpers)
>
> Signed-off-by: Manivannan Sadhasivam
> ---
> drivers/mfd/Kconfig | 22 +++
> drivers/mfd/Makefile | 7 +
> drivers/mfd/atc2609a-helpers.c| 91 +
> drivers/mfd/atc260x-core.c| 85
> drivers/mfd/atc260x-i2c.c | 98 ++
Taking this set on it's own merits alone, I don't see a good reason to
split these up. Please either supply the SPI interface within this
patch-set or amalgamate them into a single file.
> drivers/mfd/atc260x.h | 22 +++
> include/linux/mfd/atc260x/atc2609a_regs.h | 228 ++
> include/linux/mfd/atc260x/core.h | 64 ++
> 8 files changed, 617 insertions(+)
> create mode 100644 drivers/mfd/atc2609a-helpers.c
> create mode 100644 drivers/mfd/atc260x-core.c
> create mode 100644 drivers/mfd/atc260x-i2c.c
> create mode 100644 drivers/mfd/atc260x.h
> create mode 100644 include/linux/mfd/atc260x/atc2609a_regs.h
> create mode 100644 include/linux/mfd/atc260x/core.h
>
> diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
> index a17d275bf1d4..eb388505357b 100644
> --- a/drivers/mfd/Kconfig
> +++ b/drivers/mfd/Kconfig
> @@ -1945,6 +1945,28 @@ config MFD_STMFX
> additional drivers must be enabled in order to use the functionality
> of the device.
>
> +config MFD_ATC260X
> + tristate "Actions Semi ATC260x PMICs"
> + select MFD_CORE
> + select REGMAP
> + select REGMAP_IRQ
> + help
> + Support for the Actions Semi ATC260x PMICs.
> +
> +config MFD_ATC260X_I2C
> + tristate "Actions Semi ATC260x PMICs with I2C"
> + depends on MFD_ATC260X
> + depends on I2C
> + select REGMAP_I2C
> + help
> + Support for the Actions Semi ATC260x PMICs controlled via I2C.
> +
> +config MFD_ATC2609A
> + bool "Actions Semi ATC2609A PMIC"
> + depends on MFD_ATC260X
> + help
> + Support for Actions Semi ATC2609A PMIC
> +
> menu "Multimedia Capabilities Port drivers"
> depends on ARCH_SA1100
>
> diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
> index 52b1a90ff515..a87e7ed55a02 100644
> --- a/drivers/mfd/Makefile
> +++ b/drivers/mfd/Makefile
> @@ -249,3 +249,10 @@ obj-$(CONFIG_MFD_SC27XX_PMIC)+= sprd-sc27xx-spi.o
> obj-$(CONFIG_RAVE_SP_CORE) += rave-sp.o
> obj-$(CONFIG_MFD_ROHM_BD718XX) += rohm-bd718x7.o
> obj-$(CONFIG_MFD_STMFX) += stmfx.o
> +
> +atc260x-objs := atc260x-core.o
> +ifeq ($(CONFIG_MFD_ATC2609A),y)
> +atc260x-objs += atc2609a-helpers.o
> +endif
> +obj-$(CONFIG_MFD_ATC260X)+= atc260x.o
> +obj-$(CONFIG_MFD_ATC260X_I2C)+= atc260x-i2c.o
> diff --git a/drivers/mfd/atc2609a-helpers.c b/drivers/mfd/atc2609a-helpers.c
> new file mode 100644
> index ..6d304ea61552
> --- /dev/null
> +++ b/drivers/mfd/atc2609a-helpers.c
> @@ -0,0 +1,91 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Helper functions for ATC2609A PMIC
> + *
> + * Copyright (C) 2019 Manivannan Sadhasivam
>
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +
> +#include "atc260x.h"
> +
> +const struct regmap_config atc2609a_regmap_config = {
> + .reg_bits = 8,
> + .val_bits = 16,
> + .max_register = ATC2609A_SADDR,
> + .cache_type = REGCACHE_NONE,
> +};
> +
> +const struct regmap_irq atc2609a_irqs[] = {
> + [ATC2609A_IRQ_AUDIO] = {
> + .reg_offset = 0,
> + .mask = BIT(0),
> + },
> + [ATC2609A_IRQ_OV] = {
> + .reg_offset = 0,
> + .mask = BIT(1),
> + },
> + [ATC2609A_IRQ_OC] = {
> + .reg_offset = 0,
> + .mask = BIT(2),
> + },
> + [ATC2609A_IRQ_OT] = {
> + .reg_offset = 0,
> + .mask = BIT(3),
> + },
> + [ATC2609A_IRQ_UV] = {
> + .reg_offset = 0,
> + .mask = BIT(4),
> + },
> + [ATC2609A_IRQ_ALARM] = {
> + .reg_offset = 0,
> + .mask = BIT(5),
> + },
> + [ATC2609A_IRQ_ONOFF] = {
> + .reg_offset = 0,
> + .mask = BIT(6),
> + },
> + [ATC2609A_IRQ_WKUP] = {
> + .reg_offset = 0,
> +
Re: [PATCH v2 1/3] mm: Trigger bug on if a section is not found in __section_nr
On Wed 26-06-19 16:27:30, Alastair D'Silva wrote: > On Wed, 2019-06-26 at 08:21 +0200, Michal Hocko wrote: > > On Wed 26-06-19 16:11:21, Alastair D'Silva wrote: > > > From: Alastair D'Silva > > > > > > If a memory section comes in where the physical address is greater > > > than > > > that which is managed by the kernel, this function would not > > > trigger the > > > bug and instead return a bogus section number. > > > > > > This patch tracks whether the section was actually found, and > > > triggers the > > > bug if not. > > > > Why do we want/need that? In other words the changelog should contina > > WHY and WHAT. This one contains only the later one. > > > > Thanks, I'll update the comment. > > During driver development, I tried adding peristent memory at a memory > address that exceeded the maximum permissable address for the platform. > > This caused __section_nr to silently return bogus section numbers, > rather than complaining. OK, I see, but is an additional code worth it for the non-development case? I mean why should we be testing for something that shouldn't happen normally? Is it too easy to get things wrong or what is the underlying reason to change it now? -- Michal Hocko SUSE Labs
Re: [RFC PATCH 00/28] Removing struct page from P2PDMA
On Tue, Jun 25, 2019 at 01:54:21PM -0600, Logan Gunthorpe wrote:
> Well whether it's dma_addr_t, phys_addr_t, pfn_t the result isn't all
> that different. You still need roughly the same 'if' hooks for any
> backed memory that isn't in the linear mapping and you can't get a
> kernel mapping for directly.
>
> It wouldn't be too hard to do a similar patch set that uses something
> like phys_addr_t instead and have a request and queue flag for support
> of non-mappable memory. But you'll end up with very similar 'if' hooks
> and we'd have to clean up all bio-using drivers that access the struct
> pages directly.
We'll need to clean that mess up anyway, and I've been chugging
along doing some of that. A lot still assume no highmem, so we need
to convert them over to something that kmaps anyway. If we get
the abstraction right that will actually help converting over to
a better reprsentation.
> Though, we'd also still have the problem of how to recognize when the
> address points to P2PDMA and needs to be translated to the bus offset.
> The map-first inversion was what helped here because the driver
> submitting the requests had all the information. Though it could be
> another request flag and indicating non-mappable memory could be a flag
> group like REQ_NOMERGE_FLAGS -- REQ_NOMAP_FLAGS.
The assumes the request all has the same memory, which is a simplifing
assuption. My idea was that if had our new bio_vec like this:
struct bio_vec {
phys_addr_t paddr; // 64-bit on 64-bit systems
unsigned long len;
};
we have a hole behind len where we could store flag. Preferably
optionally based on a P2P or other magic memory types config
option so that 32-bit systems with 32-bit phys_addr_t actually
benefit from the smaller and better packing structure.
> If you think any of the above ideas sound workable I'd be happy to try
> to code up another prototype.
Іt sounds workable. To some of the first steps are cleanups independent
of how the bio_vec is eventually going to look like. That is making
the DMA-API internals work on the phys_addr_t, which also unifies the
map_resource implementation with map_page. I plan to do that relatively
soon. The next is sorting out access to bios data by virtual address.
All these need nice kmapping helper that avoid too much open coding.
I was going to look into that next, mostly to kill the block layer
bounce buffering code. Similar things will also be needed at the
scatterlist level I think. After that we need to more audits of
how bv_page is still used. something like a bv_phys() helper that
does "page_to_phys(bv->bv_page) + bv->bv_offset" might come in handy
for example.
Re: [PATCH 1/1] perf annotate csky: Add perf annotate support
Thx Mao,
Approved!
Best Regards
Guo Ren
On Wed, Jun 26, 2019 at 2:53 PM Mao Han wrote:
>
> This patch add basic arch initialization and instruction associate support
> for csky.
>
> perf annotate --stdio2
> Samples: 161 of event 'cpu-clock:pppH', 4000 Hz, Event count (approx.):
> 4025, [percent: local period]
> test_4() /usr/lib/perf-test/callchain_test
> Percent
>
> Disassembly of section .text:
>
> 8420 :
> test_4():
> subi sp, sp, 4
> st.w r8, (sp, 0x0)
> mov r8, sp
> subi sp, sp, 8
> subi r3, r8, 4
> movi r2, 0
> st.w r2, (r3, 0x0)
> ↓ br2e
> 100.00 14: subi r3, r8, 4
> ld.w r2, (r3, 0x0)
> subi r3, r8, 8
> st.w r2, (r3, 0x0)
> subi r3, r8, 4
> ld.w r3, (r3, 0x0)
> addi r2, r3, 1
> subi r3, r8, 4
> st.w r2, (r3, 0x0)
> 2e: subi r3, r8, 4
> ld.w r2, (r3, 0x0)
> lrw r3, 0x98967f// 8598
> cmplt r3, r2
> ↑ bf14
> mov r0, r0
> mov r0, r0
> mov sp, r8
> ld.w r8, (sp, 0x0)
> addi sp, sp, 4
> ← rts
>
> Signed-off-by: Mao Han
> Cc: Guo Ren
> Cc: Peter Zijlstra
> Cc: Ingo Molnar
> Cc: Arnaldo Carvalho de Melo
> Cc: Alexander Shishkin
> Cc: Jiri Olsa
> Cc: Namhyung Kim
> ---
> tools/perf/arch/csky/annotate/instructions.c | 48
>
> tools/perf/util/annotate.c | 5 +++
> 2 files changed, 53 insertions(+)
> create mode 100644 tools/perf/arch/csky/annotate/instructions.c
>
> diff --git a/tools/perf/arch/csky/annotate/instructions.c
> b/tools/perf/arch/csky/annotate/instructions.c
> new file mode 100644
> index 000..5337bfb
> --- /dev/null
> +++ b/tools/perf/arch/csky/annotate/instructions.c
> @@ -0,0 +1,48 @@
> +// SPDX-License-Identifier: GPL-2.0
> +// Copyright (C) 2019 Hangzhou C-SKY Microsystems co.,ltd.
> +
> +#include
> +
> +static struct ins_ops *csky__associate_ins_ops(struct arch *arch,
> + const char *name)
> +{
> + struct ins_ops *ops = NULL;
> +
> + /* catch all kind of jumps */
> + if (!strcmp(name, "bt") ||
> + !strcmp(name, "bf") ||
> + !strcmp(name, "bez") ||
> + !strcmp(name, "bnez") ||
> + !strcmp(name, "bnezad") ||
> + !strcmp(name, "bhsz") ||
> + !strcmp(name, "bhz") ||
> + !strcmp(name, "blsz") ||
> + !strcmp(name, "blz") ||
> + !strcmp(name, "br") ||
> + !strcmp(name, "jmpi") ||
> + !strcmp(name, "jmp"))
> + ops = _ops;
> +
> + /* catch function call */
> + if (!strcmp(name, "bsr") ||
> + !strcmp(name, "jsri") ||
> + !strcmp(name, "jsr"))
> + ops = _ops;
> +
> + /* catch function return */
> + if (!strcmp(name, "rts"))
> + ops = _ops;
> +
> + if (ops)
> + arch__associate_ins_ops(arch, name, ops);
> + return ops;
> +}
> +
> +static int csky__annotate_init(struct arch *arch, char *cpuid __maybe_unused)
> +{
> + arch->initialized = true;
> + arch->objdump.comment_char = '/';
> + arch->associate_instruction_ops = csky__associate_ins_ops;
> +
> + return 0;
> +}
> diff --git a/tools/perf/util/annotate.c b/tools/perf/util/annotate.c
> index 79db038..eb2456e 100644
> --- a/tools/perf/util/annotate.c
> +++ b/tools/perf/util/annotate.c
> @@ -144,6 +144,7 @@ static int arch__associate_ins_ops(struct arch* arch,
> const char *name, struct i
> #include "arch/arc/annotate/instructions.c"
> #include "arch/arm/annotate/instructions.c"
> #include "arch/arm64/annotate/instructions.c"
> +#include "arch/csky/annotate/instructions.c"
> #include "arch/x86/annotate/instructions.c"
> #include "arch/powerpc/annotate/instructions.c"
> #include "arch/s390/annotate/instructions.c"
> @@ -163,6 +164,10 @@ static struct arch architectures[] = {
> .init = arm64__annotate_init,
> },
> {
> + .name = "csky",
> + .init = csky__annotate_init,
> + },
> + {
> .name = "x86",
> .init = x86__annotate_init,
> .instructions = x86__instructions,
> --
> 2.7.4
>
--
Best Regards
Guo Ren
ML: https://lore.kernel.org/linux-csky/
Re: [PATCH v2 2/3] mm: don't hide potentially null memmap pointer in sparse_remove_one_section
On Wed 26-06-19 16:30:55, Alastair D'Silva wrote: > On Wed, 2019-06-26 at 08:23 +0200, Michal Hocko wrote: > > On Wed 26-06-19 16:11:22, Alastair D'Silva wrote: > > > From: Alastair D'Silva > > > > > > By adding offset to memmap before passing it in to > > > clear_hwpoisoned_pages, > > > we hide a potentially null memmap from the null check inside > > > clear_hwpoisoned_pages. > > > > > > This patch passes the offset to clear_hwpoisoned_pages instead, > > > allowing > > > memmap to successfully peform it's null check. > > > > Same issue with the changelog as the previous patch (missing WHY). > > > > The first paragraph explains what the problem is with the existing code > (same applies to 1/3 too). Under what conditions that happens? Is this a theoretical problem or can you hit this by a (buggy) code? Please be much more specific. -- Michal Hocko SUSE Labs
[PATCH] soc: imx-scu: Add SoC UID(unique identifier) support
From: Anson Huang
Add i.MX SCU SoC's UID(unique identifier) support, user
can read it from sysfs:
root@imx8qxpmek:~# cat /sys/devices/soc0/soc_uid
7B64280B57AC1898
Signed-off-by: Anson Huang
---
drivers/soc/imx/soc-imx-scu.c | 35 +++
1 file changed, 35 insertions(+)
diff --git a/drivers/soc/imx/soc-imx-scu.c b/drivers/soc/imx/soc-imx-scu.c
index 676f612..8d322a1 100644
--- a/drivers/soc/imx/soc-imx-scu.c
+++ b/drivers/soc/imx/soc-imx-scu.c
@@ -27,6 +27,36 @@ struct imx_sc_msg_misc_get_soc_id {
} data;
} __packed;
+struct imx_sc_msg_misc_get_soc_uid {
+ struct imx_sc_rpc_msg hdr;
+ u32 uid_low;
+ u32 uid_high;
+} __packed;
+
+static ssize_t soc_uid_show(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ struct imx_sc_msg_misc_get_soc_uid msg;
+ struct imx_sc_rpc_msg *hdr =
+ u64 soc_uid;
+
+ hdr->ver = IMX_SC_RPC_VERSION;
+ hdr->svc = IMX_SC_RPC_SVC_MISC;
+ hdr->func = IMX_SC_MISC_FUNC_UNIQUE_ID;
+ hdr->size = 1;
+
+ /* the return value of SCU FW is in correct, skip return value check */
+ imx_scu_call_rpc(soc_ipc_handle, , true);
+
+ soc_uid = msg.uid_high;
+ soc_uid <<= 32;
+ soc_uid |= msg.uid_low;
+
+ return sprintf(buf, "%016llX\n", soc_uid);
+}
+
+static DEVICE_ATTR_RO(soc_uid);
+
static int imx_scu_soc_id(void)
{
struct imx_sc_msg_misc_get_soc_id msg;
@@ -102,6 +132,11 @@ static int imx_scu_soc_probe(struct platform_device *pdev)
goto free_revision;
}
+ ret = device_create_file(soc_device_to_device(soc_dev),
+_attr_soc_uid);
+ if (ret)
+ goto free_revision;
+
return 0;
free_revision:
--
2.7.4
Re: [PATCH] arm64/efi: Mark __efistub_stext_offset as an absolute symbol explicitly
On Wed, 26 Jun 2019 at 06:20, Nathan Chancellor wrote: > > After r363059 and r363928 in LLVM, a build using ld.lld as the linker > with CONFIG_RANDOMIZE_BASE enabled fails like so: > > ld.lld: error: relocation R_AARCH64_ABS32 cannot be used against symbol > __efistub_stext_offset; recompile with -fPIC > > Fangrui and Peter figured out that ld.lld is incorrectly considering > __efistub_stext_offset as a relative symbol because of the order in > which symbols are evaluated. _text is treated as an absolute symbol > and stext is a relative symbol, making __efistub_stext_offset a > relative symbol. > > Adding ABSOLUTE will force ld.lld to evalute this expression in the > right context and does not change ld.bfd's behavior. ld.lld will > need to be fixed but the developers do not see a quick or simple fix > without some research (see the linked issue for further explanation). > Add this simple workaround so that ld.lld can continue to link kernels. > > Link: https://github.com/ClangBuiltLinux/linux/issues/561 > Link: > https://github.com/llvm/llvm-project/commit/025a815d75d2356f2944136269aa5874721ec236 > Link: > https://github.com/llvm/llvm-project/commit/249fde85832c33f8b06c6b4ac65d1c4b96d23b83 > Debugged-by: Fangrui Song > Debugged-by: Peter Smith > Suggested-by: Fangrui Song > Signed-off-by: Nathan Chancellor > --- > arch/arm64/kernel/image.h | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/arch/arm64/kernel/image.h b/arch/arm64/kernel/image.h > index 04ca08086d35..9a2d2227907c 100644 > --- a/arch/arm64/kernel/image.h > +++ b/arch/arm64/kernel/image.h > @@ -67,7 +67,7 @@ > > #ifdef CONFIG_EFI > > -__efistub_stext_offset = stext - _text; > +__efistub_stext_offset = ABSOLUTE(stext - _text); > > /* > * The EFI stub has its own symbol namespace prefixed by __efistub_, to > -- > 2.22.0 >
Re: [PATCH] arm64/efi: Mark __efistub_stext_offset as an absolute symbol explicitly
On Wed, 26 Jun 2019 at 06:20, Nathan Chancellor wrote: > > After r363059 and r363928 in LLVM, a build using ld.lld as the linker > with CONFIG_RANDOMIZE_BASE enabled fails like so: > > ld.lld: error: relocation R_AARCH64_ABS32 cannot be used against symbol > __efistub_stext_offset; recompile with -fPIC > > Fangrui and Peter figured out that ld.lld is incorrectly considering > __efistub_stext_offset as a relative symbol because of the order in > which symbols are evaluated. _text is treated as an absolute symbol > and stext is a relative symbol, making __efistub_stext_offset a > relative symbol. > > Adding ABSOLUTE will force ld.lld to evalute this expression in the > right context and does not change ld.bfd's behavior. ld.lld will > need to be fixed but the developers do not see a quick or simple fix > without some research (see the linked issue for further explanation). > Add this simple workaround so that ld.lld can continue to link kernels. > > Link: https://github.com/ClangBuiltLinux/linux/issues/561 > Link: > https://github.com/llvm/llvm-project/commit/025a815d75d2356f2944136269aa5874721ec236 > Link: > https://github.com/llvm/llvm-project/commit/249fde85832c33f8b06c6b4ac65d1c4b96d23b83 > Debugged-by: Fangrui Song > Debugged-by: Peter Smith > Suggested-by: Fangrui Song > Signed-off-by: Nathan Chancellor Acked-by: Ard Biesheuvel > --- > arch/arm64/kernel/image.h | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/arch/arm64/kernel/image.h b/arch/arm64/kernel/image.h > index 04ca08086d35..9a2d2227907c 100644 > --- a/arch/arm64/kernel/image.h > +++ b/arch/arm64/kernel/image.h > @@ -67,7 +67,7 @@ > > #ifdef CONFIG_EFI > > -__efistub_stext_offset = stext - _text; > +__efistub_stext_offset = ABSOLUTE(stext - _text); > > /* > * The EFI stub has its own symbol namespace prefixed by __efistub_, to > -- > 2.22.0 >
Re: [PATCH v3 1/4] usb: xhci: add firmware loader for uPD720201 and uPD720202 w/o ROM
On 24-06-19, 11:41, Vinod Koul wrote: > From: Christian Lamparter > > This patch adds a firmware loader for the uPD720201K8-711-BAC-A > and uPD720202K8-711-BAA-A variant. Both of these chips are listed > in Renesas' R19UH0078EJ0500 Rev.5.00 "User's Manual: Hardware" as > devices which need the firmware loader on page 2 in order to > work as they "do not support the External ROM". > > The "Firmware Download Sequence" is describe in chapter > "7.1 FW Download Interface" R19UH0078EJ0500 Rev.5.00 page 131. > > The firmware "K2013080.mem" is available from a USB3.0 Host to > PCIe Adapter (PP2U-E card) "Firmware download" archive. An > alternative version can be sourced from Netgear's WNDR4700 GPL > archives. > > The release notes of the PP2U-E's "Firmware Download" ver 2.0.1.3 > (2012-06-15) state that the firmware is for the following devices: > - uPD720201 ES 2.0 sample whose revision ID is 2. > - uPD720201 ES 2.1 sample & CS sample & Mass product, ID is 3. > - uPD720202 ES 2.0 sample & CS sample & Mass product, ID is 2. > > Cc: Yoshihiro Shimoda > Signed-off-by: Christian Lamparter > Signed-off-by: Bjorn Andersson > [vkoul: fixed comments: > used macros for timeout count and delay > removed renesas_fw_alive_check > cleaned renesas_fw_callback > removed recurion for renesas_fw_download > added MODULE_FIRMWARE > removed length check] > Tested-by: Christian Lamparter > Signed-off-by: Vinod Koul > --- > drivers/usb/host/xhci-pci.c | 454 > 1 file changed, 454 insertions(+) > > diff --git a/drivers/usb/host/xhci-pci.c b/drivers/usb/host/xhci-pci.c > index c2fe218e051f..89ca46dd6825 100644 > --- a/drivers/usb/host/xhci-pci.c > +++ b/drivers/usb/host/xhci-pci.c > @@ -12,6 +12,8 @@ > #include > #include > #include > +#include > +#include > > #include "xhci.h" > #include "xhci-trace.h" > @@ -55,6 +57,9 @@ > #define PCI_DEVICE_ID_AMD_PROMONTORYA_1 0x43bc > #define PCI_DEVICE_ID_ASMEDIA_1042A_XHCI 0x1142 > > +#define RENESAS_RETRY1000 > +#define RENESAS_DELAY10 So some devices are exhibiting failure on both ROM programming as well as RAM load with messages: ROM Download Step 34 failed at position 136 bytes Firmware Download Step 2 failed at position 8 bytes with (-110) So I am going to revert to older delay values! With those we dont get a failures. yeah looks like ROM load takes a while on these Thanks -- ~Vinod
Re: [RFC PATCH v2 1/2] printk-rb: add a new printk ringbuffer implementation
On 2019-06-26, Sergey Senozhatsky wrote:
> [..]
>> > CPU0 CPU1
>> > printk(...)
>> > sz = vscprintf(NULL, "Comm %s\n", current->comm);
>> >
>> > ia64_mca_modify_comm()
>> >
>> > snprintf(comm, sizeof(comm), "%s %d", current->comm,
>> > previous_current->pid);
>> >
>> > memcpy(current->comm, comm, sizeof(current->comm));
>> > if ((buf = prb_reserve(... sz))) {
>> >vscnprintf(buf, "Comm %s\n", current->comm);
>> >^^ ->comm has changed.
>> > Nothing critical, we
>> > should not corrupt
>> > anything, but we will
>> > truncate ->comm if its
>> > new size is larger than
>> > what it used to be when
>> > we did vscprintf(NULL).
>> >prb_commit(...);
>> > }
>
> [..]
>> In my v1 rfc series, I avoided this issue by having a separate dedicated
>> ringbuffer (rb_sprintf) that was used to allocate a temporary max-size
>> (2KB) buffer for sprinting to. Then _that_ was used for the real
>> ringbuffer input (strlen, prb_reserve, memcpy, prb_commit). That would
>> still be the approach of my choice.
>
> In other words per-CPU buffering, AKA printk_safe ;)
Actually, no. I made use of a printk_ringbuffer (which is global). It
was used for temporary memory allocation for sprintf, but the result was
immediately written into the printk buffer from the same context. In
contrast, printk_safe triggers a different context to handle the
insertion.
It is still my intention to eliminate the buffering component of
printk_safe.
After we get a lockless ringbuffer that we are happy with, my next
series to integrate the buffer into printk will again use the sprint_rb
solution to avoid the issue discussed in this thread. Perhaps it would
be best to continue this discussion after I've posted that series.
John Ogness
Re: [PATCH 0/6] workqueue: convert to raw_spinlock_t
On 2019-06-13 16:50:21 [+0200], To linux-kernel@vger.kernel.org wrote: > Hi, > > the workqueue code has been reworked in -RT to use raw_spinlock_t based > locking. This change allows to schedule worker from preempt_disable()ed > or IRQ disabled section on -RT. This is the last patch. The previous > patches are prerequisites or tiny cleanup (like patch #1 and #2). a gentle *ping* Sebastian
Re: [PATCH] au1200fb: don't use DMA_ATTR_NON_CONSISTENT
On Tue, Jun 25, 2019 at 2:13 PM Christoph Hellwig wrote: > > au1200fb allocates DMA memory using DMA_ATTR_NON_CONSISTENT, but never > calls dma_cache_sync to synchronize the memory between the CPU and the > device. If it was use on a not cache coherent bus that would be fatal, > but as far as I can tell from the naming and the mips platform > implementation it always is used in cache coherent systems. Remove > the DMA_ATTR_NON_CONSISTENT flag, which is a no-op in that case. Very early au1200 chips, on which this driver apparently was developed on, had issues with cache coherency, but this was fixed in a later step, none of the 3 steppings I have access to exhibit any problems with this patch applied. > Signed-off-by: Christoph Hellwig Acked-By: Manuel Lauss
[PATCH 6/8] pinctrl: aspeed: Clarify comment about strapping W1C
Writes of 1 to SCU7C clear set bits in SCU70, the hardware strapping
register. The information was correct if you squinted while reading, but
hopefully switching the order of the registers as listed conveys it
better.
Signed-off-by: Andrew Jeffery
---
drivers/pinctrl/aspeed/pinctrl-aspeed.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/pinctrl/aspeed/pinctrl-aspeed.c
b/drivers/pinctrl/aspeed/pinctrl-aspeed.c
index 4c775b8ffdc4..b510bb475851 100644
--- a/drivers/pinctrl/aspeed/pinctrl-aspeed.c
+++ b/drivers/pinctrl/aspeed/pinctrl-aspeed.c
@@ -209,7 +209,7 @@ static int aspeed_sig_expr_set(const struct aspeed_sig_expr
*expr,
if (desc->ip == ASPEED_IP_SCU && desc->reg == HW_STRAP2)
continue;
- /* On AST2500, Set bits in SCU7C are cleared from SCU70 */
+ /* On AST2500, Set bits in SCU70 are cleared from SCU7C */
if (desc->ip == ASPEED_IP_SCU && desc->reg == HW_STRAP1) {
unsigned int rev_id;
--
2.20.1
Re: [v3 1/4] dt-bindngs: display: panel: Add BOE tv101wum-n16 panel bindings
On Wed, Jun 26, 2019 at 10:53:57AM +0800, Jitao Shi wrote:
> Add documentation for boe tv101wum-n16 panel.
>
> Signed-off-by: Jitao Shi
Reviewed-by: Sam Ravnborg
> ---
> .../display/panel/boe,tv101wum-nl6.txt| 34 +++
> 1 file changed, 34 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/display/panel/boe,tv101wum-nl6.txt
>
> diff --git
> a/Documentation/devicetree/bindings/display/panel/boe,tv101wum-nl6.txt
> b/Documentation/devicetree/bindings/display/panel/boe,tv101wum-nl6.txt
> new file mode 100644
> index ..bd44af636390
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/panel/boe,tv101wum-nl6.txt
> @@ -0,0 +1,34 @@
> +Boe Corporation 10.1" WUXGA TFT LCD panel
> +
> +Required properties:
> +- compatible: should be "boe,tv101wum-nl6"
> +- reg: the virtual channel number of a DSI peripheral
> +- enable-gpios: a GPIO spec for the enable pin
> +- pp1800-supply: core voltage supply
> +- avdd-supply: phandle of the regulator that provides positive voltage
> +- avee-supply: phandle of the regulator that provides negative voltage
> +- backlight: phandle of the backlight device attached to the panel
> +
> +The device node can contain one 'port' child node with one child
> +'endpoint' node, according to the bindings defined in
> +media/video-interfaces.txt. This node should describe panel's video bus.
> +
> +Example:
> + {
> + ...
> + panel@0 {
> + compatible = "boe,tv101wum-nl6";
> + reg = <0>;
> + enable-gpios = < 45 0>;
> + avdd-supply = <_lcd>;
> + avee-supply = <_lcd>;
> + pp1800-supply = <_lcd>;
> + backlight = <_lcd0>;
> + status = "okay";
> + port {
> + panel_in: endpoint {
> + remote-endpoint = <_out>;
> + };
> + };
> + };
> +};
> --
> 2.21.0
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/8] dt-bindings: pinctrl: aspeed: Split bindings document in two
Have one for each of the AST2400 and AST2500. The only thing that was
common was the fact that both support ASPEED BMC SoCs.
Signed-off-by: Andrew Jeffery
---
.../pinctrl/aspeed,ast2400-pinctrl.txt| 80 +++
...-aspeed.txt => aspeed,ast2500-pinctrl.txt} | 63 ++-
2 files changed, 85 insertions(+), 58 deletions(-)
create mode 100644
Documentation/devicetree/bindings/pinctrl/aspeed,ast2400-pinctrl.txt
rename Documentation/devicetree/bindings/pinctrl/{pinctrl-aspeed.txt =>
aspeed,ast2500-pinctrl.txt} (66%)
diff --git
a/Documentation/devicetree/bindings/pinctrl/aspeed,ast2400-pinctrl.txt
b/Documentation/devicetree/bindings/pinctrl/aspeed,ast2400-pinctrl.txt
new file mode 100644
index ..67e0325ccf2e
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/aspeed,ast2400-pinctrl.txt
@@ -0,0 +1,80 @@
+=
+Aspeed AST2400 Pin Controller
+=
+
+Required properties for the AST2400:
+- compatible : Should be one of the following:
+ "aspeed,ast2400-pinctrl"
+ "aspeed,g4-pinctrl"
+
+The pin controller node should be the child of a syscon node with the required
+property:
+
+- compatible : Should be one of the following:
+ "aspeed,ast2400-scu", "syscon", "simple-mfd"
+ "aspeed,g4-scu", "syscon", "simple-mfd"
+
+Refer to the the bindings described in
+Documentation/devicetree/bindings/mfd/syscon.txt
+
+Subnode Format
+==
+
+The required properties of pinmux child nodes are:
+- function: the mux function to select
+- groups : the list of groups to select with this function
+
+Required properties of pinconf child nodes are:
+- groups: A list of groups to select (either this or "pins" must be
+ specified)
+- pins : A list of ball names as strings, eg "D14" (either this or "groups"
+ must be specified)
+
+Optional properties of pinconf child nodes are:
+- bias-disable : disable any pin bias
+- bias-pull-down: pull down the pin
+- drive-strength: sink or source at most X mA
+
+Definitions are as specified in
+Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt, with any
+further limitations as described above.
+
+For pinmux, each mux function has only one associated pin group. Each group is
+named by its function. The following values for the function and groups
+properties are supported:
+
+ACPI ADC0 ADC1 ADC10 ADC11 ADC12 ADC13 ADC14 ADC15 ADC2 ADC3 ADC4 ADC5 ADC6
+ADC7 ADC8 ADC9 BMCINT DDCCLK DDCDAT EXTRST FLACK FLBUSY FLWP GPID GPID0 GPID2
+GPID4 GPID6 GPIE0 GPIE2 GPIE4 GPIE6 I2C10 I2C11 I2C12 I2C13 I2C14 I2C3 I2C4
+I2C5 I2C6 I2C7 I2C8 I2C9 LPCPD LPCPME LPCRST LPCSMI MAC1LINK MAC2LINK MDIO1
+MDIO2 NCTS1 NCTS2 NCTS3 NCTS4 NDCD1 NDCD2 NDCD3 NDCD4 NDSR1 NDSR2 NDSR3 NDSR4
+NDTR1 NDTR2 NDTR3 NDTR4 NDTS4 NRI1 NRI2 NRI3 NRI4 NRTS1 NRTS2 NRTS3 OSCCLK PWM0
+PWM1 PWM2 PWM3 PWM4 PWM5 PWM6 PWM7 RGMII1 RGMII2 RMII1 RMII2 ROM16 ROM8 ROMCS1
+ROMCS2 ROMCS3 ROMCS4 RXD1 RXD2 RXD3 RXD4 SALT1 SALT2 SALT3 SALT4 SD1 SD2 SGPMCK
+SGPMI SGPMLD SGPMO SGPSCK SGPSI0 SGPSI1 SGPSLD SIOONCTRL SIOPBI SIOPBO SIOPWREQ
+SIOPWRGD SIOS3 SIOS5 SIOSCI SPI1 SPI1DEBUG SPI1PASSTHRU SPICS1 TIMER3 TIMER4
+TIMER5 TIMER6 TIMER7 TIMER8 TXD1 TXD2 TXD3 TXD4 UART6 USB11D1 USB11H2 USB2D1
+USB2H1 USBCKI VGABIOS_ROM VGAHS VGAVS VPI18 VPI24 VPI30 VPO12 VPO24 WDTRST1
+WDTRST2
+
+Example
+===
+
+syscon: scu@1e6e2000 {
+ compatible = "aspeed,ast2400-scu", "syscon", "simple-mfd";
+ reg = <0x1e6e2000 0x1a8>;
+
+ pinctrl: pinctrl {
+ compatible = "aspeed,g4-pinctrl";
+
+ pinctrl_i2c3_default: i2c3_default {
+ function = "I2C3";
+ groups = "I2C3";
+ };
+
+ pinctrl_gpioh0_unbiased_default: gpioh0 {
+ pins = "A8";
+ bias-disable;
+ };
+ };
+};
diff --git a/Documentation/devicetree/bindings/pinctrl/pinctrl-aspeed.txt
b/Documentation/devicetree/bindings/pinctrl/aspeed,ast2500-pinctrl.txt
similarity index 66%
rename from Documentation/devicetree/bindings/pinctrl/pinctrl-aspeed.txt
rename to Documentation/devicetree/bindings/pinctrl/aspeed,ast2500-pinctrl.txt
index 3b7266c7c438..2f16e401338a 100644
--- a/Documentation/devicetree/bindings/pinctrl/pinctrl-aspeed.txt
+++ b/Documentation/devicetree/bindings/pinctrl/aspeed,ast2500-pinctrl.txt
@@ -1,14 +1,6 @@
-==
-Aspeed Pin Controllers
-==
-
-The Aspeed SoCs vary in functionality inside a generation but have a common mux
-device register layout.
-
-Required properties for g4:
-- compatible : Should be one of the following:
- "aspeed,ast2400-pinctrl"
- "aspeed,g4-pinctrl"
+=
+Aspeed AST2500 Pin Controller
[PATCH 5/8] pinctrl: aspeed: Correct comment that is no longer true
We have handled the GFX register case for quite some time now. Signed-off-by: Andrew Jeffery --- drivers/pinctrl/aspeed/pinctrl-aspeed.h | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/pinctrl/aspeed/pinctrl-aspeed.h b/drivers/pinctrl/aspeed/pinctrl-aspeed.h index 4b06ddbc6aec..c5918c4a087c 100644 --- a/drivers/pinctrl/aspeed/pinctrl-aspeed.h +++ b/drivers/pinctrl/aspeed/pinctrl-aspeed.h @@ -240,8 +240,7 @@ * opposed to naming them e.g. PINMUX_CTRL_[0-9]). Further, signal expressions * reference registers beyond those dedicated to pinmux, such as the system * reset control and MAC clock configuration registers. The AST2500 goes a step - * further and references registers in the graphics IP block, but that isn't - * handled yet. + * further and references registers in the graphics IP block. */ #define SCU2C 0x2C /* Misc. Control Register */ #define SCU3C 0x3C /* System Reset Control/Status Register */ -- 2.20.1
[PATCH 0/8] pinctrl: aspeed: Preparation for AST2600
Hello! The ASPEED AST2600 is in the pipeline, and we have enough information to start preparing to upstream support for it. This series lays some ground work; splitting the bindings and dicing the implementation up a little further to facilitate differences between the 2600 and previous SoC generations. I've added a bit more documentation to the private header to help outline the structures that are generated from the jungle of macros. There will be some tweaks to their behaviour in the future series to support multiple pin groups per function while maintaining the property that improperly describing the pin/signal/group/function relationships causes a failure to compile. Regarding the bindings this is my first attempt at using the json-schema approach. It has previously bugged me that there was no way to enforce the documented bindings on the devicetree, so I think this is an interesting development. Hopefully I've done an okay job there. I think I could better exploit the schema to constrain the function and group names used in the DTS, but I think that can be left as future work. Finally I've added myself in MAINTAINERS as the PoC for the drivers to make sure anyone unfortunate enough to stare at the implementations can ping me about them. Please review! Andrew Andrew Jeffery (8): dt-bindings: pinctrl: aspeed: Split bindings document in two dt-bindings: pinctrl: aspeed: Convert AST2400 bindings to json-schema dt-bindings: pinctrl: aspeed: Convert AST2500 bindings to json-schema MAINTAINERS: Add entry for ASPEED pinctrl drivers pinctrl: aspeed: Correct comment that is no longer true pinctrl: aspeed: Clarify comment about strapping W1C pinctrl: aspeed: Split out pinmux from general pinctrl pinctrl: aspeed: Add implementation-related documentation .../pinctrl/aspeed,ast2400-pinctrl.yaml | 73 ++ .../pinctrl/aspeed,ast2500-pinctrl.yaml | 124 +++ .../bindings/pinctrl/pinctrl-aspeed.txt | 172 MAINTAINERS | 9 + drivers/pinctrl/aspeed/Makefile | 2 +- drivers/pinctrl/aspeed/pinctrl-aspeed-g4.c| 94 ++- drivers/pinctrl/aspeed/pinctrl-aspeed-g5.c| 123 ++- drivers/pinctrl/aspeed/pinctrl-aspeed.c | 250 +- drivers/pinctrl/aspeed/pinctrl-aspeed.h | 549 + drivers/pinctrl/aspeed/pinmux-aspeed.c| 96 +++ drivers/pinctrl/aspeed/pinmux-aspeed.h| 735 ++ 11 files changed, 1294 insertions(+), 933 deletions(-) create mode 100644 Documentation/devicetree/bindings/pinctrl/aspeed,ast2400-pinctrl.yaml create mode 100644 Documentation/devicetree/bindings/pinctrl/aspeed,ast2500-pinctrl.yaml delete mode 100644 Documentation/devicetree/bindings/pinctrl/pinctrl-aspeed.txt create mode 100644 drivers/pinctrl/aspeed/pinmux-aspeed.c create mode 100644 drivers/pinctrl/aspeed/pinmux-aspeed.h -- 2.20.1
[PATCH 4/8] MAINTAINERS: Add entry for ASPEED pinctrl drivers
Add myself as maintainer to avoid burdening others with the madness. Signed-off-by: Andrew Jeffery --- MAINTAINERS | 9 + 1 file changed, 9 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index a6954776a37e..978383f5c1ab 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -2586,6 +2586,15 @@ S: Maintained F: Documentation/hwmon/asc7621.rst F: drivers/hwmon/asc7621.c +ASPEED PINCTRL DRIVERS +M: Andrew Jeffery +L: linux-asp...@lists.ozlabs.org (moderated for non-subscribers) +L: open...@lists.ozlabs.org (moderated for non-subscribers) +L: linux-g...@vger.kernel.org +S: Maintained +F: drivers/pinctrl/aspeed/ +F: Documentation/devicetree/bindings/pinctrl/aspeed,* + ASPEED VIDEO ENGINE DRIVER M: Eddie James L: linux-me...@vger.kernel.org -- 2.20.1
[PATCH 3/8] dt-bindings: pinctrl: aspeed: Convert AST2500 bindings to json-schema
Convert ASPEED pinctrl bindings to DT schema format using json-schema.
Signed-off-by: Andrew Jeffery
---
.../pinctrl/aspeed,ast2500-pinctrl.txt| 119 -
.../pinctrl/aspeed,ast2500-pinctrl.yaml | 124 ++
2 files changed, 124 insertions(+), 119 deletions(-)
delete mode 100644
Documentation/devicetree/bindings/pinctrl/aspeed,ast2500-pinctrl.txt
create mode 100644
Documentation/devicetree/bindings/pinctrl/aspeed,ast2500-pinctrl.yaml
diff --git
a/Documentation/devicetree/bindings/pinctrl/aspeed,ast2500-pinctrl.txt
b/Documentation/devicetree/bindings/pinctrl/aspeed,ast2500-pinctrl.txt
deleted file mode 100644
index 2f16e401338a..
--- a/Documentation/devicetree/bindings/pinctrl/aspeed,ast2500-pinctrl.txt
+++ /dev/null
@@ -1,119 +0,0 @@
-=
-Aspeed AST2500 Pin Controller
-=
-
-Required properties for g5:
-- compatible : Should be one of the following:
- "aspeed,ast2500-pinctrl"
- "aspeed,g5-pinctrl"
-
-- aspeed,external-nodes: A cell of phandles to external controller nodes:
- 0: compatible with "aspeed,ast2500-gfx",
"syscon"
- 1: compatible with "aspeed,ast2500-lhc",
"syscon"
-
-The pin controller node should be the child of a syscon node with the required
-property:
-
-- compatible : Should be one of the following:
- "aspeed,ast2500-scu", "syscon", "simple-mfd"
- "aspeed,g5-scu", "syscon", "simple-mfd"
-
-Refer to the the bindings described in
-Documentation/devicetree/bindings/mfd/syscon.txt
-
-Subnode Format
-==
-
-The required properties of pinmux child nodes are:
-- function: the mux function to select
-- groups : the list of groups to select with this function
-
-Required properties of pinconf child nodes are:
-- groups: A list of groups to select (either this or "pins" must be
- specified)
-- pins : A list of ball names as strings, eg "D14" (either this or "groups"
- must be specified)
-
-Optional properties of pinconf child nodes are:
-- bias-disable : disable any pin bias
-- bias-pull-down: pull down the pin
-- drive-strength: sink or source at most X mA
-
-Definitions are as specified in
-Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt, with any
-further limitations as described above.
-
-For pinmux, each mux function has only one associated pin group. Each group is
-named by its function. The following values for the function and groups
-properties are supported:
-
-ACPI ADC0 ADC1 ADC10 ADC11 ADC12 ADC13 ADC14 ADC15 ADC2 ADC3 ADC4 ADC5 ADC6
-ADC7 ADC8 ADC9 BMCINT DDCCLK DDCDAT ESPI FWSPICS1 FWSPICS2 GPID0 GPID2 GPID4
-GPID6 GPIE0 GPIE2 GPIE4 GPIE6 I2C10 I2C11 I2C12 I2C13 I2C14 I2C3 I2C4 I2C5 I2C6
-I2C7 I2C8 I2C9 LAD0 LAD1 LAD2 LAD3 LCLK LFRAME LPCHC LPCPD LPCPLUS LPCPME
-LPCRST LPCSMI LSIRQ MAC1LINK MAC2LINK MDIO1 MDIO2 NCTS1 NCTS2 NCTS3 NCTS4 NDCD1
-NDCD2 NDCD3 NDCD4 NDSR1 NDSR2 NDSR3 NDSR4 NDTR1 NDTR2 NDTR3 NDTR4 NRI1 NRI2
-NRI3 NRI4 NRTS1 NRTS2 NRTS3 NRTS4 OSCCLK PEWAKE PNOR PWM0 PWM1 PWM2 PWM3 PWM4
-PWM5 PWM6 PWM7 RGMII1 RGMII2 RMII1 RMII2 RXD1 RXD2 RXD3 RXD4 SALT1 SALT10
-SALT11 SALT12 SALT13 SALT14 SALT2 SALT3 SALT4 SALT5 SALT6 SALT7 SALT8 SALT9
-SCL1 SCL2 SD1 SD2 SDA1 SDA2 SGPS1 SGPS2 SIOONCTRL SIOPBI SIOPBO SIOPWREQ
-SIOPWRGD SIOS3 SIOS5 SIOSCI SPI1 SPI1CS1 SPI1DEBUG SPI1PASSTHRU SPI2CK SPI2CS0
-SPI2CS1 SPI2MISO SPI2MOSI TIMER3 TIMER4 TIMER5 TIMER6 TIMER7 TIMER8 TXD1 TXD2
-TXD3 TXD4 UART6 USB11BHID USB2AD USB2AH USB2BD USB2BH USBCKI VGABIOSROM VGAHS
-VGAVS VPI24 VPO WDTRST1 WDTRST2
-
-Example
-===
-
-ahb {
- apb {
- syscon: scu@1e6e2000 {
- compatible = "aspeed,ast2500-scu", "syscon",
"simple-mfd";
- reg = <0x1e6e2000 0x1a8>;
-
- pinctrl: pinctrl {
- compatible = "aspeed,g5-pinctrl";
- aspeed,external-nodes = < >;
-
- pinctrl_i2c3_default: i2c3_default {
- function = "I2C3";
- groups = "I2C3";
- };
-
- pinctrl_gpioh0_unbiased_default: gpioh0 {
- pins = "A18";
- bias-disable;
- };
- };
- };
-
- gfx: display@1e6e6000 {
- compatible = "aspeed,ast2500-gfx", "syscon";
- reg = <0x1e6e6000 0x1000>;
- };
- };
-
- lpc: lpc@1e789000 {
- compatible = "aspeed,ast2500-lpc", "simple-mfd";
- reg = <0x1e789000 0x1000>;
-
- #address-cells = <1>;
-
[PATCH 2/8] dt-bindings: pinctrl: aspeed: Convert AST2400 bindings to json-schema
Convert ASPEED pinctrl bindings to DT schema format using json-schema
Signed-off-by: Andrew Jeffery
---
.../pinctrl/aspeed,ast2400-pinctrl.txt| 80 ---
.../pinctrl/aspeed,ast2400-pinctrl.yaml | 73 +
2 files changed, 73 insertions(+), 80 deletions(-)
delete mode 100644
Documentation/devicetree/bindings/pinctrl/aspeed,ast2400-pinctrl.txt
create mode 100644
Documentation/devicetree/bindings/pinctrl/aspeed,ast2400-pinctrl.yaml
diff --git
a/Documentation/devicetree/bindings/pinctrl/aspeed,ast2400-pinctrl.txt
b/Documentation/devicetree/bindings/pinctrl/aspeed,ast2400-pinctrl.txt
deleted file mode 100644
index 67e0325ccf2e..
--- a/Documentation/devicetree/bindings/pinctrl/aspeed,ast2400-pinctrl.txt
+++ /dev/null
@@ -1,80 +0,0 @@
-=
-Aspeed AST2400 Pin Controller
-=
-
-Required properties for the AST2400:
-- compatible : Should be one of the following:
- "aspeed,ast2400-pinctrl"
- "aspeed,g4-pinctrl"
-
-The pin controller node should be the child of a syscon node with the required
-property:
-
-- compatible : Should be one of the following:
- "aspeed,ast2400-scu", "syscon", "simple-mfd"
- "aspeed,g4-scu", "syscon", "simple-mfd"
-
-Refer to the the bindings described in
-Documentation/devicetree/bindings/mfd/syscon.txt
-
-Subnode Format
-==
-
-The required properties of pinmux child nodes are:
-- function: the mux function to select
-- groups : the list of groups to select with this function
-
-Required properties of pinconf child nodes are:
-- groups: A list of groups to select (either this or "pins" must be
- specified)
-- pins : A list of ball names as strings, eg "D14" (either this or "groups"
- must be specified)
-
-Optional properties of pinconf child nodes are:
-- bias-disable : disable any pin bias
-- bias-pull-down: pull down the pin
-- drive-strength: sink or source at most X mA
-
-Definitions are as specified in
-Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt, with any
-further limitations as described above.
-
-For pinmux, each mux function has only one associated pin group. Each group is
-named by its function. The following values for the function and groups
-properties are supported:
-
-ACPI ADC0 ADC1 ADC10 ADC11 ADC12 ADC13 ADC14 ADC15 ADC2 ADC3 ADC4 ADC5 ADC6
-ADC7 ADC8 ADC9 BMCINT DDCCLK DDCDAT EXTRST FLACK FLBUSY FLWP GPID GPID0 GPID2
-GPID4 GPID6 GPIE0 GPIE2 GPIE4 GPIE6 I2C10 I2C11 I2C12 I2C13 I2C14 I2C3 I2C4
-I2C5 I2C6 I2C7 I2C8 I2C9 LPCPD LPCPME LPCRST LPCSMI MAC1LINK MAC2LINK MDIO1
-MDIO2 NCTS1 NCTS2 NCTS3 NCTS4 NDCD1 NDCD2 NDCD3 NDCD4 NDSR1 NDSR2 NDSR3 NDSR4
-NDTR1 NDTR2 NDTR3 NDTR4 NDTS4 NRI1 NRI2 NRI3 NRI4 NRTS1 NRTS2 NRTS3 OSCCLK PWM0
-PWM1 PWM2 PWM3 PWM4 PWM5 PWM6 PWM7 RGMII1 RGMII2 RMII1 RMII2 ROM16 ROM8 ROMCS1
-ROMCS2 ROMCS3 ROMCS4 RXD1 RXD2 RXD3 RXD4 SALT1 SALT2 SALT3 SALT4 SD1 SD2 SGPMCK
-SGPMI SGPMLD SGPMO SGPSCK SGPSI0 SGPSI1 SGPSLD SIOONCTRL SIOPBI SIOPBO SIOPWREQ
-SIOPWRGD SIOS3 SIOS5 SIOSCI SPI1 SPI1DEBUG SPI1PASSTHRU SPICS1 TIMER3 TIMER4
-TIMER5 TIMER6 TIMER7 TIMER8 TXD1 TXD2 TXD3 TXD4 UART6 USB11D1 USB11H2 USB2D1
-USB2H1 USBCKI VGABIOS_ROM VGAHS VGAVS VPI18 VPI24 VPI30 VPO12 VPO24 WDTRST1
-WDTRST2
-
-Example
-===
-
-syscon: scu@1e6e2000 {
- compatible = "aspeed,ast2400-scu", "syscon", "simple-mfd";
- reg = <0x1e6e2000 0x1a8>;
-
- pinctrl: pinctrl {
- compatible = "aspeed,g4-pinctrl";
-
- pinctrl_i2c3_default: i2c3_default {
- function = "I2C3";
- groups = "I2C3";
- };
-
- pinctrl_gpioh0_unbiased_default: gpioh0 {
- pins = "A8";
- bias-disable;
- };
- };
-};
diff --git
a/Documentation/devicetree/bindings/pinctrl/aspeed,ast2400-pinctrl.yaml
b/Documentation/devicetree/bindings/pinctrl/aspeed,ast2400-pinctrl.yaml
new file mode 100644
index ..3b8cf3e51506
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/aspeed,ast2400-pinctrl.yaml
@@ -0,0 +1,73 @@
+# SPDX-License-Identifier: GPL-2.0+
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pinctrl/aspeed,ast2400-pinctrl.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: ASPEED AST2400 Pin Controller
+
+maintainers:
+ - Andrew Jeffery
+
+properties:
+ compatible:
+oneOf:
+ - items:
+- enum:
+ - aspeed,ast2400-pinctrl
+ - items:
+- enum:
+ - aspeed,g4-pinctrl
+
+required:
+ - compatible
+
+description: |+
+ The pin controller node should be the child of a syscon node with the
+ required property:
+
+ - compatible: Should be one of the following:
+"aspeed,ast2400-scu", "syscon", "simple-mfd"
+
Re: [PATCH 08/17] binfmt_flat: consolidate two version of flat_v2_reloc_t
On 26/6/19 8:29 am, Al Viro wrote:
On Thu, Jun 13, 2019 at 09:08:54AM +0200, Christoph Hellwig wrote:
Two branches of the ifdef maze actually have the same content, so merge
them.
Signed-off-by: Christoph Hellwig
---
include/linux/flat.h | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/include/linux/flat.h b/include/linux/flat.h
index 2b7cda6e9c1b..19c586b74b99 100644
--- a/include/linux/flat.h
+++ b/include/linux/flat.h
@@ -69,15 +69,13 @@ struct flat_hdr {
typedef union {
unsigned long value;
struct {
-# if defined(mc68000) && !defined(CONFIG_COLDFIRE)
+#if defined(__LITTLE_ENDIAN_BITFIELD) || \
+(defined(mc68000) && !defined(CONFIG_COLDFIRE))
signed long offset : 30;
unsigned long type : 2;
# elif defined(__BIG_ENDIAN_BITFIELD)
unsigned long type : 2;
signed long offset : 30;
-# elif defined(__LITTLE_ENDIAN_BITFIELD)
- signed long offset : 30;
- unsigned long type : 2;
# else
# error "Unknown bitfield order for flat files."
# endif
--
2.20.1
FWIW, I wonder if keeping that type is worth bothering.
Something like
old_reloc(__be32 reloc)
{
u32 v = be32_to_cpu(reloc);
int offset, type;
#if (defined(mc68000) && !defined(CONFIG_COLDFIRE))
/* old m68k uses unusual format - type is in lower bits of octet 3 */
type = v % 4;
offset = (int)v / 4;
#else
/* everything else (including coldfire) has it in upper bits of octet 0
*/
type = v >> 30;
offset = (int)(v << 2) >> 2; /* or (v & 0x1fff) - (v & 0x2000)
* 4 */
#endif
...
and to hell with bitfields, aliasing unions, etc. Unless I'm misreading
the whole thing, that is... Greg?
I think you are right. This is much better.
The old mc6800 is the odd one out, the rest have it in network order,
and this makes that much clearer.
Regards
Greg
[PATCH 8/8] pinctrl: aspeed: Add implementation-related documentation
The ASPEED pinctrl driver implementations make heavy use of macros to
minimise tedium of implementation and maximise the chance that the
compiler will catch errors in defining signal and pin configurations.
While the goal of minimising errors is achieved, it is at the cost of
the complexity of the macros.
Document examples of the expanded form of pin declarations to
demonstrate the operation of the macros.
Signed-off-by: Andrew Jeffery
---
drivers/pinctrl/aspeed/pinmux-aspeed.h | 204 -
1 file changed, 200 insertions(+), 4 deletions(-)
diff --git a/drivers/pinctrl/aspeed/pinmux-aspeed.h
b/drivers/pinctrl/aspeed/pinmux-aspeed.h
index a036ce8f1571..329d54d48667 100644
--- a/drivers/pinctrl/aspeed/pinmux-aspeed.h
+++ b/drivers/pinctrl/aspeed/pinmux-aspeed.h
@@ -18,7 +18,8 @@
* priority level are frequently not the same (i.e. cannot just flip a bit to
* change from a high to low priority signal), or even in the same register.
* Further, not all signals can be unmuxed, as some expressions depend on
- * values in the hardware strapping register (which is treated as read-only).
+ * values in the hardware strapping register (which may be treated as
+ * read-only).
*
* SoC Multi-function Pin Expression Examples
* --
@@ -172,9 +173,9 @@
* * A signal expression is the smallest set of signal descriptors whose
* comparisons must evaluate 'true' for a signal to be enabled on a pin.
*
- * * A function's signal is active on a pin if evaluating all signal
- * descriptors in the pin's signal expression for the function yields a
'true'
- * result
+ * * A signal participating in a function is active on a pin if evaluating all
+ * signal descriptors in the pin's signal expression for the function yields
+ * a 'true' result
*
* * A signal at a given priority on a given pin is active if any of the
* functions in which the signal participates are active, and no higher
@@ -221,6 +222,201 @@
* well as pins) required for the group's configuration will already be in use,
* likely in a way that's inconsistent with the requirements of the failed
* group.
+ *
+ * Implementation
+ * --
+ *
+ * Beyond the documentation below the various structures and helper macros that
+ * allow the implementation to hang together are defined. The macros are fairly
+ * dense, so below we walk through some raw examples of the configuration
+ * tables in an effort to clarify the concepts.
+ *
+ * The complexity of configuring the mux combined with the scale of the pins
+ * and functions was a concern, so the table design along with the macro jungle
+ * is an attempt to address it. The rough principles of the approach are:
+ *
+ * 1. Use a data-driven solution rather than embedding state into code
+ * 2. Minimise editing to the specifics of the given mux configuration
+ * 3. Detect as many errors as possible at compile time
+ *
+ * Addressing point 3 leads to naming of symbols in terms of the four
+ * properties associated with a given mux configuration: The pin, the signal,
+ * the group and the function. In this way copy/paste errors cause duplicate
+ * symbols to be defined, which prevents successful compilation. Failing to
+ * properly parent the tables leads to unused symbol warnings, and use of
+ * designated initialisers and additional warnings ensures that there are
+ * no override errors in the pin, group and function arrays.
+ *
+ * Addressing point 2 drives the development of the macro jungle, as it
+ * centralises the definition noise at the cost of taking some time to
+ * understand.
+ *
+ * Here's a complete, concrete "pre-processed" example of the table structures
+ * used to describe the D6 ball from the examples above:
+ *
+ * ```
+ * static const struct aspeed_sig_desc sig_descs_MAC1LINK_MAC1LINK[] = {
+ * {
+ * .ip = ASPEED_IP_SCU,
+ * .reg = 0x80,
+ * .mask = BIT(0),
+ * .enable = 1,
+ * .disable = 0
+ * },
+ * };
+ *
+ * static const struct aspeed_sig_expr sig_expr_MAC1LINK_MAC1LINK = {
+ * .signal = "MAC1LINK",
+ * .function = "MAC1LINK",
+ * .ndescs = ARRAY_SIZE(sig_descs_MAC1LINK_MAC1LINK),
+ * .descs = &(sig_descs_MAC1LINK_MAC1LINK)[0],
+ * };
+ *
+ * static const struct aspeed_sig_expr *sig_exprs_MAC1LINK_MAC1LINK[] = {
+ * _expr_MAC1LINK_MAC1LINK,
+ * NULL,
+ * };
+ *
+ * static const struct aspeed_sig_desc sig_descs_GPIOA0_GPIOA0[] = { };
+ *
+ * static const struct aspeed_sig_expr sig_expr_GPIOA0_GPIOA0 = {
+ * .signal = "GPIOA0",
+ * .function = "GPIOA0",
+ * .ndescs = ARRAY_SIZE(sig_descs_GPIOA0_GPIOA0),
+ * .descs = &(sig_descs_GPIOA0_GPIOA0)[0],
+ * };
+ *
+ * static const struct aspeed_sig_expr *sig_exprs_GPIOA0_GPIOA0[] = {
+ * _expr_GPIOA0_GPIOA0,
+ * NULL
+ * };
+ *
+ * static const struct aspeed_sig_expr **pin_exprs_0[] = {
+ * sig_exprs_MAC1LINK_MAC1LINK,
+ * sig_exprs_GPIOA0_GPIOA0,
+ *
[PATCH 7/8] pinctrl: aspeed: Split out pinmux from general pinctrl
ASPEED have completely rearranged the System Control Unit register
layout with the AST2600. The existing code took advantage of the fact
that the AST2400 and AST2500 had layouts that were similar enough to
have little impact on the pinmux infrastructure (though there is a wart
with read-modify-write vs write-1-clear semantics of the hardware
strapping registers between the two).
Given that any similarity has been thrown out with the AST2600, separate
out the function applying an expression state to be driver-specific.
With it, extract out the pinmux macro jungle to its own header and
implementation so the pieces can be composed without dependency cycles.
Signed-off-by: Andrew Jeffery
---
drivers/pinctrl/aspeed/Makefile| 2 +-
drivers/pinctrl/aspeed/pinctrl-aspeed-g4.c | 94 +++-
drivers/pinctrl/aspeed/pinctrl-aspeed-g5.c | 123 -
drivers/pinctrl/aspeed/pinctrl-aspeed.c| 250 ++
drivers/pinctrl/aspeed/pinctrl-aspeed.h| 548 +
drivers/pinctrl/aspeed/pinmux-aspeed.c | 96
drivers/pinctrl/aspeed/pinmux-aspeed.h | 539
7 files changed, 892 insertions(+), 760 deletions(-)
create mode 100644 drivers/pinctrl/aspeed/pinmux-aspeed.c
create mode 100644 drivers/pinctrl/aspeed/pinmux-aspeed.h
diff --git a/drivers/pinctrl/aspeed/Makefile b/drivers/pinctrl/aspeed/Makefile
index 068729bf4f86..ea8962645e49 100644
--- a/drivers/pinctrl/aspeed/Makefile
+++ b/drivers/pinctrl/aspeed/Makefile
@@ -2,6 +2,6 @@
# Aspeed pinctrl support
ccflags-y += $(call cc-option,-Woverride-init)
-obj-$(CONFIG_PINCTRL_ASPEED) += pinctrl-aspeed.o
+obj-$(CONFIG_PINCTRL_ASPEED) += pinctrl-aspeed.o pinmux-aspeed.o
obj-$(CONFIG_PINCTRL_ASPEED_G4)+= pinctrl-aspeed-g4.o
obj-$(CONFIG_PINCTRL_ASPEED_G5)+= pinctrl-aspeed-g5.o
diff --git a/drivers/pinctrl/aspeed/pinctrl-aspeed-g4.c
b/drivers/pinctrl/aspeed/pinctrl-aspeed-g4.c
index 73e2c9c0e549..384396cbb22d 100644
--- a/drivers/pinctrl/aspeed/pinctrl-aspeed-g4.c
+++ b/drivers/pinctrl/aspeed/pinctrl-aspeed-g4.c
@@ -18,8 +18,34 @@
#include "../core.h"
#include "../pinctrl-utils.h"
+#include "pinmux-aspeed.h"
#include "pinctrl-aspeed.h"
+/*
+ * The "Multi-function Pins Mapping and Control" table in the SoC datasheet
+ * references registers by the device/offset mnemonic. The register macros
+ * below are named the same way to ease transcription and verification (as
+ * opposed to naming them e.g. PINMUX_CTRL_[0-9]). Further, signal expressions
+ * reference registers beyond those dedicated to pinmux, such as the system
+ * reset control and MAC clock configuration registers.
+ */
+#define SCU2C 0x2C /* Misc. Control Register */
+#define SCU3C 0x3C /* System Reset Control/Status Register */
+#define SCU48 0x48 /* MAC Interface Clock Delay Setting */
+#define HW_STRAP1 0x70 /* AST2400 strapping is 33 bits, is split */
+#define HW_REVISION_ID 0x7C /* Silicon revision ID register */
+#define SCU80 0x80 /* Multi-function Pin Control #1 */
+#define SCU84 0x84 /* Multi-function Pin Control #2 */
+#define SCU88 0x88 /* Multi-function Pin Control #3 */
+#define SCU8C 0x8C /* Multi-function Pin Control #4 */
+#define SCU90 0x90 /* Multi-function Pin Control #5 */
+#define SCU94 0x94 /* Multi-function Pin Control #6 */
+#define SCUA0 0xA0 /* Multi-function Pin Control #7 */
+#define SCUA4 0xA4 /* Multi-function Pin Control #8 */
+#define SCUA8 0xA8 /* Multi-function Pin Control #9 */
+#define SCUAC 0xAC /* Multi-function Pin Control #10 */
+#define HW_STRAP2 0xD0 /* Strapping */
+
/*
* Uses undefined macros for symbol naming and references, eg GPIOA0, MAC1LINK,
* TIMER3 etc.
@@ -2386,13 +2412,73 @@ static const struct aspeed_pin_config
aspeed_g4_configs[] = {
{ PIN_CONFIG_INPUT_DEBOUNCE, { C14, B14 }, SCUA8, 27 },
};
+static int aspeed_g4_sig_expr_set(const struct aspeed_pinmux_data *ctx,
+ const struct aspeed_sig_expr *expr,
+ bool enable)
+{
+ int ret;
+ int i;
+
+ for (i = 0; i < expr->ndescs; i++) {
+ const struct aspeed_sig_desc *desc = >descs[i];
+ u32 pattern = enable ? desc->enable : desc->disable;
+ u32 val = (pattern << __ffs(desc->mask));
+
+ if (!ctx->maps[desc->ip])
+ return -ENODEV;
+
+ /*
+* Strap registers are configured in hardware or by early-boot
+* firmware. Treat them as read-only despite that we can write
+* them. This may mean that certain functions cannot be
+* deconfigured and is the reason we re-evaluate after writing
+* all descriptor bits.
+*
+* Port D and port E GPIO loopback modes are the only exception
+*
[PATCH 0/8] staging: kpc2000: style refactoring
A patch-series that will remove warnings, errors and check-messages, noted and highlighted by the checkpatch.pl script concerning kpc2000_spi.c. Signed-off-by: Fabian Krueger Signed-off-by: Michael Scheiderer Cc: Fabian Krueger (8): staging: kpc2000: add line breaks staging: kpc2000: blank lines after declaration staging: kpc2000: introduce usage of __packed staging: kpc2000: remove unnecessary brackets staging: kpc2000: add spaces staging: kpc2000: introduce 'unsigned int' staging: kpc2000: introduce __func__ staging: kpc2000: remove needless 'break' drivers/staging/kpc2000/kpc2000_spi.c | 99 ++- 1 file changed, 51 insertions(+), 48 deletions(-) -- 2.17.1
Re: [PATCH bpf-next v9 02/10] bpf: Add eBPF program subtype and is_valid_subtype() verifier
On 26/06/2019 01:02, Alexei Starovoitov wrote:
> On Tue, Jun 25, 2019 at 3:04 PM Mickaël Salaün wrote:
>>
>> The goal of the program subtype is to be able to have different static
>> fine-grained verifications for a unique program type.
>>
>> The struct bpf_verifier_ops gets a new optional function:
>> is_valid_subtype(). This new verifier is called at the beginning of the
>> eBPF program verification to check if the (optional) program subtype is
>> valid.
>>
>> The new helper bpf_load_program_xattr() enables to verify a program with
>> subtypes.
>>
>> For now, only Landlock eBPF programs are using a program subtype (see
>> next commits) but this could be used by other program types in the
>> future.
>>
>> Signed-off-by: Mickaël Salaün
>> Cc: Alexei Starovoitov
>> Cc: Daniel Borkmann
>> Cc: David S. Miller
>> Link:
>> https://lkml.kernel.org/r/20160827205559.ga43...@ast-mbp.thefacebook.com
>> ---
>>
>> Changes since v8:
>> * use bpf_load_program_xattr() instead of bpf_load_program() and add
>> bpf_verify_program_xattr() to deal with subtypes
>> * remove put_extra() since there is no more "previous" field (for now)
>>
>> Changes since v7:
>> * rename LANDLOCK_SUBTYPE_* to LANDLOCK_*
>> * move subtype in bpf_prog_aux and use only one bit for has_subtype
>> (suggested by Alexei Starovoitov)
>
> sorry to say, but I don't think the landlock will ever land,
> since posting huge patches once a year is missing a lot of development
> that is happening during that time.
You're right that it's been a while since the last patch set, but the
main reasons behind this was a lack of feedback (probably because of the
size of the patch set, which is now reduce to a consistent minimum), the
rework needed to address everyone's concern (Landlock modify kernel
components from different maintainers), and above all, the LSM stacking
infrastructure which was quite beefy and then took some time to land:
https://lore.kernel.org/lkml/50db058a-7dde-441b-a7f9-f6837fe8b...@schaufler-ca.com/
This stacking infrastructure was required to have a useful version of
Landlock (which is used as a use case example), and it was released with
Linux v5.1 (last month). Now, I think everything is finally ready to
move forward.
> This 2/10 patch is an example.
> subtype concept was useful 2 years ago when v6 was posted.
> Since then bpf developers faced very similar problem in other parts
> and it was solved with 'expected_attach_type' field.
> See commit 5e43f899b03a ("bpf: Check attach type at prog load time")
> dated March 2018.
I saw this nice feature but I wasn't sure if it was the right field to
use. Indeed, I need more than a "type", but also some values (triggers)
as shown by this patch. What do you suggest?
[PATCH 1/8] staging: kpc2000: add line breaks
To fix some checkpatch-warnings some lines of this module had to be
shortened so that they do not exceed 80 characters per line.
This refactoring makes the code more readable.
Signed-off-by: Fabian Krueger
Signed-off-by: Michael Scheiderer
Cc:
---
drivers/staging/kpc2000/kpc2000_spi.c | 34 +--
1 file changed, 22 insertions(+), 12 deletions(-)
diff --git a/drivers/staging/kpc2000/kpc2000_spi.c
b/drivers/staging/kpc2000/kpc2000_spi.c
index c3e5c1848f53..b0b5c9b4d35a 100644
--- a/drivers/staging/kpc2000/kpc2000_spi.c
+++ b/drivers/staging/kpc2000/kpc2000_spi.c
@@ -36,6 +36,7 @@ static struct mtd_partition p2kr0_spi0_parts[] = {
{ .name = "SLOT_3", .size = 7798784,.offset =
MTDPART_OFS_NXTBLK},
{ .name = "CS0_EXTRA", .size = MTDPART_SIZ_FULL, .offset =
MTDPART_OFS_NXTBLK},
};
+
static struct mtd_partition p2kr0_spi1_parts[] = {
{ .name = "SLOT_4", .size = 7798784,.offset = 0,
},
{ .name = "SLOT_5", .size = 7798784,.offset =
MTDPART_OFS_NXTBLK},
@@ -182,7 +183,8 @@ kp_spi_write_reg(struct kp_spi_controller_state *cs, int
idx, u64 val)
}
static int
-kp_spi_wait_for_reg_bit(struct kp_spi_controller_state *cs, int idx, unsigned
long bit)
+kp_spi_wait_for_reg_bit(struct kp_spi_controller_state *cs, int idx,
+ unsigned long bit)
{
unsigned long timeout;
timeout = jiffies + msecs_to_jiffies(1000);
@@ -207,6 +209,7 @@ kp_spi_txrx_pio(struct spi_device *spidev, struct
spi_transfer *transfer)
unsigned int c = count;
int i;
+ int res;
u8 *rx = transfer->rx_buf;
const u8 *tx = transfer->tx_buf;
int processed = 0;
@@ -215,9 +218,10 @@ kp_spi_txrx_pio(struct spi_device *spidev, struct
spi_transfer *transfer)
for (i = 0 ; i < c ; i++) {
char val = *tx++;
- if (kp_spi_wait_for_reg_bit(cs, KP_SPI_REG_STATUS,
KP_SPI_REG_STATUS_TXS) < 0) {
+ res = kp_spi_wait_for_reg_bit(cs, KP_SPI_REG_STATUS,
+ KP_SPI_REG_STATUS_TXS);
+ if (res < 0)
goto out;
- }
kp_spi_write_reg(cs, KP_SPI_REG_TXDATA, val);
processed++;
@@ -228,10 +232,10 @@ kp_spi_txrx_pio(struct spi_device *spidev, struct
spi_transfer *transfer)
char test=0;
kp_spi_write_reg(cs, KP_SPI_REG_TXDATA, 0x00);
-
- if (kp_spi_wait_for_reg_bit(cs, KP_SPI_REG_STATUS,
KP_SPI_REG_STATUS_RXS) < 0) {
+ res = kp_spi_wait_for_reg_bit(cs, KP_SPI_REG_STATUS,
+ KP_SPI_REG_STATUS_RXS);
+ if (res < 0)
goto out;
- }
test = kp_spi_read_reg(cs, KP_SPI_REG_RXDATA);
*rx++ = test;
@@ -239,8 +243,10 @@ kp_spi_txrx_pio(struct spi_device *spidev, struct
spi_transfer *transfer)
}
}
- if (kp_spi_wait_for_reg_bit(cs, KP_SPI_REG_STATUS,
KP_SPI_REG_STATUS_EOT) < 0) {
- //TODO: Figure out how to abort transaction?? This has never
happened in practice though...
+ if (kp_spi_wait_for_reg_bit(cs, KP_SPI_REG_STATUS,
+ KP_SPI_REG_STATUS_EOT) < 0) {
+ //TODO: Figure out how to abort transaction??
+ //Ths has never happened in practice though...
}
out:
@@ -307,7 +313,8 @@ kp_spi_transfer_one_message(struct spi_master *master,
struct spi_message *m)
void *rx_buf = transfer->rx_buf;
unsignedlen = transfer->len;
- if (transfer->speed_hz > KP_SPI_CLK || (len && !(rx_buf ||
tx_buf))) {
+ if (transfer->speed_hz > KP_SPI_CLK ||
+ (len && !(rx_buf || tx_buf))) {
dev_dbg(kpspi->dev, " transfer: %d Hz, %d %s%s, %d
bpw\n",
transfer->speed_hz,
len,
@@ -317,7 +324,8 @@ kp_spi_transfer_one_message(struct spi_master *master,
struct spi_message *m)
dev_dbg(kpspi->dev, " transfer -EINVAL\n");
return -EINVAL;
}
- if (transfer->speed_hz && (transfer->speed_hz < (KP_SPI_CLK >>
15))) {
+ if (transfer->speed_hz &&
+ transfer->speed_hz < (KP_SPI_CLK >> 15)) {
dev_dbg(kpspi->dev, "speed_hz %d below minimum %d Hz\n",
transfer->speed_hz,
KP_SPI_CLK >> 15);
@@ -332,14 +340,16 @@ kp_spi_transfer_one_message(struct spi_master
[PATCH 2/8] staging: kpc2000: blank lines after declaration
After the declarations in a function, there should be a blank line, so
that the declaration part is visibly separated from the rest.
This refactoring makes the code more readable.
Signed-off-by: Fabian Krueger
Signed-off-by: Michael Scheiderer
Cc:
---
drivers/staging/kpc2000/kpc2000_spi.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/staging/kpc2000/kpc2000_spi.c
b/drivers/staging/kpc2000/kpc2000_spi.c
index b0b5c9b4d35a..c8fdb7e868f8 100644
--- a/drivers/staging/kpc2000/kpc2000_spi.c
+++ b/drivers/staging/kpc2000/kpc2000_spi.c
@@ -176,6 +176,7 @@ kp_spi_read_reg(struct kp_spi_controller_state *cs, int idx)
kp_spi_write_reg(struct kp_spi_controller_state *cs, int idx, u64 val)
{
u64 __iomem *addr = cs->base;
+
addr += idx;
writeq(val, addr);
if (idx == KP_SPI_REG_CONFIG)
@@ -187,6 +188,7 @@ kp_spi_wait_for_reg_bit(struct kp_spi_controller_state *cs,
int idx,
unsigned long bit)
{
unsigned long timeout;
+
timeout = jiffies + msecs_to_jiffies(1000);
while (!(kp_spi_read_reg(cs, idx) & bit)) {
if (time_after(jiffies, timeout)) {
@@ -416,6 +418,7 @@ kp_spi_transfer_one_message(struct spi_master *master,
struct spi_message *m)
kp_spi_cleanup(struct spi_device *spidev)
{
struct kp_spi_controller_state *cs = spidev->controller_state;
+
if (cs) {
kfree(cs);
}
@@ -507,6 +510,7 @@ kp_spi_probe(struct platform_device *pldev)
kp_spi_remove(struct platform_device *pldev)
{
struct spi_master *master = platform_get_drvdata(pldev);
+
spi_unregister_master(master);
return 0;
}
--
2.17.1
[PATCH 3/8] staging: kpc2000: introduce usage of __packed
Replaced __attribute__((packed)) with __packed. Both ways of attributing
are equivalent, but being shorter, __packed should be preferred.
This refactoring makes the core more readable.
Signed-off-by: Fabian Krueger
Signed-off-by: Michael Scheiderer
Cc:
---
drivers/staging/kpc2000/kpc2000_spi.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/kpc2000/kpc2000_spi.c
b/drivers/staging/kpc2000/kpc2000_spi.c
index c8fdb7e868f8..42d32de2230e 100644
--- a/drivers/staging/kpc2000/kpc2000_spi.c
+++ b/drivers/staging/kpc2000/kpc2000_spi.c
@@ -114,7 +114,7 @@ struct kp_spi_controller_state {
union kp_spi_config {
/* use this to access individual elements */
- struct __attribute__((packed)) spi_config_bitfield {
+ struct __packed spi_config_bitfield {
unsigned int pha : 1; /* spim_clk Phase */
unsigned int pol : 1; /* spim_clk Polarity */
unsigned int epol : 1; /* spim_csx Polarity */
@@ -133,7 +133,7 @@ union kp_spi_config {
};
union kp_spi_status {
- struct __attribute__((packed)) spi_status_bitfield {
+ struct __packed spi_status_bitfield {
unsigned int rx: 1; /* Rx Status */
unsigned int tx: 1; /* Tx Status */
unsigned int eo: 1; /* End of Transfer */
@@ -148,7 +148,7 @@ union kp_spi_status {
};
union kp_spi_ffctrl {
- struct __attribute__((packed)) spi_ffctrl_bitfield {
+ struct __packed spi_ffctrl_bitfield {
unsigned int ffstart : 1; /* FIFO Start */
unsigned int : 31;
} bitfield;
--
2.17.1
Re: [PATCH v3 0/4] Devmap cleanups + arm64 support
Robin, Andrew: I have a series for the hmm tree, which touches the section size bits, and remove device public memory support. It might be best if we include this series in the hmm tree as well to avoid conflicts. Is it ok to include the rebase version of at least the cleanup part (which looks like it is not required for the actual arm64 support) in the hmm tree to avoid conflicts?
[PATCH 4/8] staging: kpc2000: remove unnecessary brackets
Removed brackets on around one-lined if-cases.
This refactoring makes the code more readable.
Signed-off-by: Fabian Krueger
Signed-off-by: Michael Scheiderer
Cc:
---
drivers/staging/kpc2000/kpc2000_spi.c | 30 +--
1 file changed, 10 insertions(+), 20 deletions(-)
diff --git a/drivers/staging/kpc2000/kpc2000_spi.c
b/drivers/staging/kpc2000/kpc2000_spi.c
index 42d32de2230e..b4dba0e42c72 100644
--- a/drivers/staging/kpc2000/kpc2000_spi.c
+++ b/drivers/staging/kpc2000/kpc2000_spi.c
@@ -165,9 +165,8 @@ kp_spi_read_reg(struct kp_spi_controller_state *cs, int idx)
u64 val;
addr += idx;
- if ((idx == KP_SPI_REG_CONFIG) && (cs->conf_cache >= 0)){
+ if ((idx == KP_SPI_REG_CONFIG) && (cs->conf_cache >= 0))
return cs->conf_cache;
- }
val = readq(addr);
return val;
}
@@ -192,11 +191,10 @@ kp_spi_wait_for_reg_bit(struct kp_spi_controller_state
*cs, int idx,
timeout = jiffies + msecs_to_jiffies(1000);
while (!(kp_spi_read_reg(cs, idx) & bit)) {
if (time_after(jiffies, timeout)) {
- if (!(kp_spi_read_reg(cs, idx) & bit)) {
+ if (!(kp_spi_read_reg(cs, idx) & bit))
return -ETIMEDOUT;
- } else {
+ else
return 0;
- }
}
cpu_relax();
}
@@ -305,9 +303,8 @@ kp_spi_transfer_one_message(struct spi_master *master,
struct spi_message *m)
cs = spidev->controller_state;
/* reject invalid messages and transfers */
- if (list_empty(>transfers)) {
+ if (list_empty(>transfers))
return -EINVAL;
- }
/* validate input */
list_for_each_entry(transfer, >transfers, transfer_list) {
@@ -365,17 +362,14 @@ kp_spi_transfer_one_message(struct spi_master *master,
struct spi_message *m)
sc.reg = kp_spi_read_reg(cs, KP_SPI_REG_CONFIG);
/* ...direction */
- if (transfer->tx_buf) {
+ if (transfer->tx_buf)
sc.bitfield.trm = KP_SPI_REG_CONFIG_TRM_TX;
- }
- else if (transfer->rx_buf) {
+ else if (transfer->rx_buf)
sc.bitfield.trm = KP_SPI_REG_CONFIG_TRM_RX;
- }
/* ...word length */
- if (transfer->bits_per_word) {
+ if (transfer->bits_per_word)
word_len = transfer->bits_per_word;
- }
sc.bitfield.wl = word_len-1;
/* ...chip select */
@@ -394,9 +388,8 @@ kp_spi_transfer_one_message(struct spi_master *master,
struct spi_message *m)
}
}
- if (transfer->delay_usecs) {
+ if (transfer->delay_usecs)
udelay(transfer->delay_usecs);
- }
}
/* de-assert chip select to end the sequence */
@@ -419,9 +412,7 @@ kp_spi_cleanup(struct spi_device *spidev)
{
struct kp_spi_controller_state *cs = spidev->controller_state;
- if (cs) {
- kfree(cs);
- }
+ kfree(cs);
}
/**
@@ -463,9 +454,8 @@ kp_spi_probe(struct platform_device *pldev)
kpspi->dev = >dev;
master->num_chipselect = 4;
- if (pldev->id != -1) {
+ if (pldev->id != -1)
master->bus_num = pldev->id;
- }
r = platform_get_resource(pldev, IORESOURCE_MEM, 0);
if (r == NULL) {
--
2.17.1
[PATCH 5/8] staging: kpc2000: add spaces
Added spaces on the left side of parenthesis and on both sides of binary
operators. Also realigned else and else if so it matches the
parenthesis line.
This refactoring makes the code more readable.
Signed-off-by: Fabian Krueger
Signed-off-by: Michael Scheiderer
Cc:
---
drivers/staging/kpc2000/kpc2000_spi.c | 12 +---
1 file changed, 5 insertions(+), 7 deletions(-)
diff --git a/drivers/staging/kpc2000/kpc2000_spi.c
b/drivers/staging/kpc2000/kpc2000_spi.c
index b4dba0e42c72..d5b4bd7b2ea7 100644
--- a/drivers/staging/kpc2000/kpc2000_spi.c
+++ b/drivers/staging/kpc2000/kpc2000_spi.c
@@ -226,10 +226,9 @@ kp_spi_txrx_pio(struct spi_device *spidev, struct
spi_transfer *transfer)
kp_spi_write_reg(cs, KP_SPI_REG_TXDATA, val);
processed++;
}
- }
- else if(rx) {
+ } else if (rx) {
for (i = 0 ; i < c ; i++) {
- char test=0;
+ char test = 0;
kp_spi_write_reg(cs, KP_SPI_REG_TXDATA, 0x00);
res = kp_spi_wait_for_reg_bit(cs, KP_SPI_REG_STATUS,
@@ -267,9 +266,8 @@ kp_spi_setup(struct spi_device *spidev)
cs = spidev->controller_state;
if (!cs) {
cs = kzalloc(sizeof(*cs), GFP_KERNEL);
- if(!cs) {
+ if (!cs)
return -ENOMEM;
- }
cs->base = kpspi->base;
cs->conf_cache = -1;
spidev->controller_state = cs;
@@ -429,7 +427,7 @@ kp_spi_probe(struct platform_device *pldev)
int i;
drvdata = pldev->dev.platform_data;
- if (!drvdata){
+ if (!drvdata) {
dev_err(>dev, "kp_spi_probe: platform_data is NULL!\n");
return -ENODEV;
}
@@ -479,7 +477,7 @@ kp_spi_probe(struct platform_device *pldev)
spi_new_device(master, &(table[i])); \
}
- switch ((drvdata->card_id & 0x) >> 16){
+ switch ((drvdata->card_id & 0x) >> 16) {
case PCI_DEVICE_ID_DAKTRONICS_KADOKA_P2KR0:
NEW_SPI_DEVICE_FROM_BOARD_INFO_TABLE(p2kr0_board_info);
break;
--
2.17.1
[PATCH 6/8] staging: kpc2000: introduce 'unsigned int'
Replaced 'unsigned' with it's equivalent 'unsigned int' to reduce
confusion while reading the code.
Signed-off-by: Fabian Krueger
Signed-off-by: Michael Scheiderer
Cc:
---
drivers/staging/kpc2000/kpc2000_spi.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/kpc2000/kpc2000_spi.c
b/drivers/staging/kpc2000/kpc2000_spi.c
index d5b4bd7b2ea7..eeb36d78402e 100644
--- a/drivers/staging/kpc2000/kpc2000_spi.c
+++ b/drivers/staging/kpc2000/kpc2000_spi.c
@@ -308,7 +308,7 @@ kp_spi_transfer_one_message(struct spi_master *master,
struct spi_message *m)
list_for_each_entry(transfer, >transfers, transfer_list) {
const void *tx_buf = transfer->tx_buf;
void *rx_buf = transfer->rx_buf;
- unsignedlen = transfer->len;
+ unsigned int len = transfer->len;
if (transfer->speed_hz > KP_SPI_CLK ||
(len && !(rx_buf || tx_buf))) {
@@ -354,7 +354,7 @@ kp_spi_transfer_one_message(struct spi_master *master,
struct spi_message *m)
/* transfer */
if (transfer->len) {
unsigned int word_len = spidev->bits_per_word;
- unsigned count;
+ unsigned int count;
/* set up the transfer... */
sc.reg = kp_spi_read_reg(cs, KP_SPI_REG_CONFIG);
--
2.17.1
[PATCH 8/8] staging: kpc2000: remove needless 'break'
The unconditioned jump will prohibit to ever reach the break-statement. Deleting this needless statement, the code becomes more understandable. Signed-off-by: Fabian Krueger Signed-off-by: Michael Scheiderer Cc: --- drivers/staging/kpc2000/kpc2000_spi.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/staging/kpc2000/kpc2000_spi.c b/drivers/staging/kpc2000/kpc2000_spi.c index 55bed617b0d8..1e1e747a0f6c 100644 --- a/drivers/staging/kpc2000/kpc2000_spi.c +++ b/drivers/staging/kpc2000/kpc2000_spi.c @@ -486,7 +486,6 @@ kp_spi_probe(struct platform_device *pldev) default: dev_err(>dev, "Unknown hardware, cant know what partition table to use!\n"); goto free_master; - break; } return status; -- 2.17.1
[PATCH 7/8] staging: kpc2000: introduce __func__
Instead of using the function name hard coded as string, using __func__
and the '%s'-placeholder will always give the current name of the
function. When renaming a function, the debugging-messages won't have to
be rewritten.
Signed-off-by: Fabian Krueger
Signed-off-by: Michael Scheiderer
Cc:
---
drivers/staging/kpc2000/kpc2000_spi.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/kpc2000/kpc2000_spi.c
b/drivers/staging/kpc2000/kpc2000_spi.c
index eeb36d78402e..55bed617b0d8 100644
--- a/drivers/staging/kpc2000/kpc2000_spi.c
+++ b/drivers/staging/kpc2000/kpc2000_spi.c
@@ -428,13 +428,14 @@ kp_spi_probe(struct platform_device *pldev)
drvdata = pldev->dev.platform_data;
if (!drvdata) {
- dev_err(>dev, "kp_spi_probe: platform_data is NULL!\n");
+ dev_err(>dev, "%s: platform_data is NULL\n", __func__);
return -ENODEV;
}
master = spi_alloc_master(>dev, sizeof(struct kp_spi));
if (master == NULL) {
- dev_err(>dev, "kp_spi_probe: master allocation
failed\n");
+ dev_err(>dev, "%s: master allocation failed\n",
+ __func__);
return -ENOMEM;
}
@@ -457,7 +458,8 @@ kp_spi_probe(struct platform_device *pldev)
r = platform_get_resource(pldev, IORESOURCE_MEM, 0);
if (r == NULL) {
- dev_err(>dev, "kp_spi_probe: Unable to get platform
resources\n");
+ dev_err(>dev, "%s: Unable to get platform resources\n",
+ __func__);
status = -ENODEV;
goto free_master;
}
--
2.17.1
[PATCH 1/2] soc: imx8: Add i.MX8MQ UID(unique identifier) support
From: Anson Huang
Add i.MX8MQ SoC UID(unique identifier) support, user
can read it from sysfs:
root@imx8mqevk:~# cat /sys/devices/soc0/soc_uid
D56911D6F060954B
Signed-off-by: Anson Huang
---
drivers/soc/imx/soc-imx8.c | 22 ++
1 file changed, 22 insertions(+)
diff --git a/drivers/soc/imx/soc-imx8.c b/drivers/soc/imx/soc-imx8.c
index f924ae8..c19ef4b 100644
--- a/drivers/soc/imx/soc-imx8.c
+++ b/drivers/soc/imx/soc-imx8.c
@@ -16,6 +16,9 @@
#define IMX8MQ_SW_INFO_B1 0x40
#define IMX8MQ_SW_MAGIC_B1 0xff0055aa
+#define OCOTP_UID_LOW 0x410
+#define OCOTP_UID_HIGH 0x420
+
/* Same as ANADIG_DIGPROG_IMX7D */
#define ANADIG_DIGPROG_IMX8MM 0x800
@@ -24,6 +27,16 @@ struct imx8_soc_data {
u32 (*soc_revision)(void);
};
+static u64 soc_uid;
+
+static ssize_t soc_uid_show(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ return sprintf(buf, "%016llX\n", soc_uid);
+}
+
+static DEVICE_ATTR_RO(soc_uid);
+
static u32 __init imx8mq_soc_revision(void)
{
struct device_node *np;
@@ -42,6 +55,10 @@ static u32 __init imx8mq_soc_revision(void)
if (magic == IMX8MQ_SW_MAGIC_B1)
rev = REV_B1;
+ soc_uid = readl_relaxed(ocotp_base + OCOTP_UID_HIGH);
+ soc_uid <<= 32;
+ soc_uid |= readl_relaxed(ocotp_base + OCOTP_UID_LOW);
+
iounmap(ocotp_base);
out:
@@ -140,6 +157,11 @@ static int __init imx8_soc_init(void)
goto free_rev;
}
+ ret = device_create_file(soc_device_to_device(soc_dev),
+_attr_soc_uid);
+ if (ret)
+ goto free_rev;
+
if (IS_ENABLED(CONFIG_ARM_IMX_CPUFREQ_DT))
platform_device_register_simple("imx-cpufreq-dt", -1, NULL, 0);
--
2.7.4
[PATCH 2/2] soc: imx8: Add i.MX8MM UID(unique identifier) support
From: Anson Huang
Add i.MX8MM SoC UID(unique identifier) support, user
can read it from sysfs:
root@imx8mmevk:~# cat /sys/devices/soc0/soc_uid
B365FA0A5C85D6EE
Signed-off-by: Anson Huang
---
drivers/soc/imx/soc-imx8.c | 23 +++
1 file changed, 23 insertions(+)
diff --git a/drivers/soc/imx/soc-imx8.c b/drivers/soc/imx/soc-imx8.c
index c19ef4b..b9831576 100644
--- a/drivers/soc/imx/soc-imx8.c
+++ b/drivers/soc/imx/soc-imx8.c
@@ -66,6 +66,26 @@ static u32 __init imx8mq_soc_revision(void)
return rev;
}
+static void __init imx8mm_soc_uid(void)
+{
+ void __iomem *ocotp_base;
+ struct device_node *np;
+
+ np = of_find_compatible_node(NULL, NULL, "fsl,imx8mm-ocotp");
+ if (!np)
+ return;
+
+ ocotp_base = of_iomap(np, 0);
+ WARN_ON(!ocotp_base);
+
+ soc_uid = readl_relaxed(ocotp_base + OCOTP_UID_HIGH);
+ soc_uid <<= 32;
+ soc_uid |= readl_relaxed(ocotp_base + OCOTP_UID_LOW);
+
+ iounmap(ocotp_base);
+ of_node_put(np);
+}
+
static u32 __init imx8mm_soc_revision(void)
{
struct device_node *np;
@@ -83,6 +103,9 @@ static u32 __init imx8mm_soc_revision(void)
iounmap(anatop_base);
of_node_put(np);
+
+ imx8mm_soc_uid();
+
return rev;
}
--
2.7.4
Re: [PATCH v5 02/25] mm: userfault: return VM_FAULT_RETRY on signals
On Wed, Jun 26, 2019 at 09:59:58AM +0800, Linus Torvalds wrote: > On Tue, Jun 25, 2019 at 1:31 PM Peter Xu wrote: > > > > Yes that sounds reasonable to me, and that matches perfectly with > > TASK_INTERRUPTIBLE and TASK_KILLABLE. The only thing that I am a bit > > uncertain is whether we should define FAULT_FLAG_INTERRUPTIBLE as a > > new bit or make it simply a combination of: > > > > FAULT_FLAG_KILLABLE | FAULT_FLAG_USER > > It needs to be a new bit, I think. > > Some things could potentially care about the difference between "can I > abort this thing because the task will *die* and never see the end > result" and "can I abort this thing because it will be retried". > > For a regular page fault, maybe FAULT_FLAG_INTERRUPTBLE will always be > set for the same things that set FAULT_FLAG_KILLABLE when it happens > from user mode, but at least conceptually I think they are different, > and it could make a difference for things like get_user_pages() or > similar. > > Also, I actually don't think we should ever expose FAULT_FLAG_USER to > any fault handlers anyway. It has a very specific meaning for memory > cgroup handling, and no other fault handler should likely ever care > about "was this a user fault". So I'd actually prefer for people to > ignore and forget that hacky flag entirely, rather than give it subtle > semantic meaning together with KILLABLE. OK. > > [ Side note: this is the point where I may soon lose internet access, > so I'll probably not be able to participate in the discussion any more > for a while ] Appreciate for these suggestions. I'll prepare something with that new bit and see whether that could be accepted. I'll also try to split those out of the bigger series. Thanks, -- Peter Xu
Re: [PATCH net-next 00/11] net: hns3: some code optimizations & bugfixes
On 2019/6/22 21:53, David Miller wrote: From: Huazhong Tan Date: Thu, 20 Jun 2019 16:52:34 +0800 This patch-set includes code optimizations and bugfixes for the HNS3 ethernet controller driver. [patch 1/11] fixes a selftest issue when doing autoneg. [patch 2/11 - 3-11] adds two code optimizations about VLAN issue. [patch 4/11] restores the MAC autoneg state after reset. [patch 5/11 - 8/11] adds some code optimizations and bugfixes about HW errors handling. [patch 9/11 - 11/11] fixes some issues related to driver loading and unloading. Series applied, thanks. Hi, david, has this patchset merged into net-next, why I cannot see it after pulling net-next? Or is there some problem about this patchset I have missed? .
Re: [RFC PATCH 03/12] powerpc/prom_init: Add the ESM call to prom_init
On 21/05/2019 14:49, Thiago Jung Bauermann wrote:
> From: Ram Pai
>
> Make the Enter-Secure-Mode (ESM) ultravisor call to switch the VM to secure
> mode. Add "svm=" command line option to turn off switching to secure mode.
> Introduce CONFIG_PPC_SVM to control support for secure guests.
>
> Signed-off-by: Ram Pai
> [ Generate an RTAS os-term hcall when the ESM ucall fails. ]
> Signed-off-by: Michael Anderson
> [ Cleaned up the code a bit. ]
> Signed-off-by: Thiago Jung Bauermann
> ---
> .../admin-guide/kernel-parameters.txt | 5 +
> arch/powerpc/include/asm/ultravisor-api.h | 1 +
> arch/powerpc/kernel/prom_init.c | 124 ++
> 3 files changed, 130 insertions(+)
>
> diff --git a/Documentation/admin-guide/kernel-parameters.txt
> b/Documentation/admin-guide/kernel-parameters.txt
> index c45a19d654f3..7237d86b25c6 100644
> --- a/Documentation/admin-guide/kernel-parameters.txt
> +++ b/Documentation/admin-guide/kernel-parameters.txt
> @@ -4501,6 +4501,11 @@
> /sys/power/pm_test). Only available when CONFIG_PM_DEBUG
> is set. Default value is 5.
>
> + svm=[PPC]
> + Format: { on | off | y | n | 1 | 0 }
> + This parameter controls use of the Protected
> + Execution Facility on pSeries.
> +
> swapaccount=[0|1]
> [KNL] Enable accounting of swap in memory resource
> controller if no parameter or 1 is given or disable
> diff --git a/arch/powerpc/include/asm/ultravisor-api.h
> b/arch/powerpc/include/asm/ultravisor-api.h
> index 15e6ce77a131..0e8b72081718 100644
> --- a/arch/powerpc/include/asm/ultravisor-api.h
> +++ b/arch/powerpc/include/asm/ultravisor-api.h
> @@ -19,6 +19,7 @@
>
> /* opcodes */
> #define UV_WRITE_PATE0xF104
> +#define UV_ESM 0xF110
> #define UV_RETURN0xF11C
>
> #endif /* _ASM_POWERPC_ULTRAVISOR_API_H */
> diff --git a/arch/powerpc/kernel/prom_init.c b/arch/powerpc/kernel/prom_init.c
> index 523bb99d7676..5d8a3efb54f2 100644
> --- a/arch/powerpc/kernel/prom_init.c
> +++ b/arch/powerpc/kernel/prom_init.c
> @@ -44,6 +44,7 @@
> #include
> #include
> #include
> +#include
>
> #include
>
> @@ -174,6 +175,10 @@ static unsigned long __prombss prom_tce_alloc_end;
> static bool __prombss prom_radix_disable;
> #endif
>
> +#ifdef CONFIG_PPC_SVM
> +static bool __prombss prom_svm_disable;
> +#endif
> +
> struct platform_support {
> bool hash_mmu;
> bool radix_mmu;
> @@ -809,6 +814,17 @@ static void __init early_cmdline_parse(void)
> if (prom_radix_disable)
> prom_debug("Radix disabled from cmdline\n");
> #endif /* CONFIG_PPC_PSERIES */
> +
> +#ifdef CONFIG_PPC_SVM
> + opt = prom_strstr(prom_cmd_line, "svm=");
> + if (opt) {
> + bool val;
> +
> + opt += sizeof("svm=") - 1;
> + if (!prom_strtobool(opt, ))
> + prom_svm_disable = !val;
> + }
> +#endif /* CONFIG_PPC_SVM */
> }
>
> #ifdef CONFIG_PPC_PSERIES
> @@ -1707,6 +1723,43 @@ static void __init prom_close_stdin(void)
> }
> }
>
> +#ifdef CONFIG_PPC_SVM
> +static int prom_rtas_os_term_hcall(uint64_t args)
This is just an rtas hcall, nothing special about "os-term".
> +{
> + register uint64_t arg1 asm("r3") = 0xf000;
> + register uint64_t arg2 asm("r4") = args;
> +
> + asm volatile("sc 1\n" : "=r" (arg1) :
> + "r" (arg1),
> + "r" (arg2) :);
> + return arg1;
> +}
> +
> +static struct rtas_args __prombss os_term_args;
> +
> +static void __init prom_rtas_os_term(char *str)
> +{
> + phandle rtas_node;
> + __be32 val;
> + u32 token;
> +
> + prom_printf("%s: start...\n", __func__);
> + rtas_node = call_prom("finddevice", 1, 1, ADDR("/rtas"));
> + prom_printf("rtas_node: %x\n", rtas_node);
> + if (!PHANDLE_VALID(rtas_node))
> + return;
> +
> + val = 0;
> + prom_getprop(rtas_node, "ibm,os-term", , sizeof(val));
> + token = be32_to_cpu(val);
> + prom_printf("ibm,os-term: %x\n", token);
> + if (token == 0)
> + prom_panic("Could not get token for ibm,os-term\n");
> + os_term_args.token = cpu_to_be32(token);
> + prom_rtas_os_term_hcall((uint64_t)_term_args);
> +}
> +#endif /* CONFIG_PPC_SVM */
> +
> /*
> * Allocate room for and instantiate RTAS
> */
> @@ -3162,6 +3215,74 @@ static void unreloc_toc(void)
> #endif
> #endif
>
> +#ifdef CONFIG_PPC_SVM
> +/*
> + * The ESM blob is a data structure with information needed by the
> Ultravisor to
> + * validate the integrity of the secure guest.
> + */
> +static void *get_esm_blob(void)
> +{
> + /*
> + * FIXME: We are still finalizing the details on how prom_init will grab
> + * the ESM blob. When that is done, this function will be updated.
Re: [RFC PATCH v2 1/2] printk-rb: add a new printk ringbuffer implementation
On (06/26/19 09:16), John Ogness wrote: > On 2019-06-26, Sergey Senozhatsky wrote: > > [..] > >> In my v1 rfc series, I avoided this issue by having a separate dedicated > >> ringbuffer (rb_sprintf) that was used to allocate a temporary max-size > >> (2KB) buffer for sprinting to. Then _that_ was used for the real > >> ringbuffer input (strlen, prb_reserve, memcpy, prb_commit). That would > >> still be the approach of my choice. > > > > In other words per-CPU buffering, AKA printk_safe ;) > > Actually, no. I made use of a printk_ringbuffer (which is global). It > was used for temporary memory allocation for sprintf, but the result was > immediately written into the printk buffer from the same context. In > contrast, printk_safe triggers a different context to handle the > insertion. I agree that's not relevant to your patch. But let me explain what I meant. printk_safe has many faces. The NMI part of printk_safe has the PRINTK_NMI_DIRECT_CONTEXT_MASK bufferring bypass - when we know that we are in NMI and printk logbuf is unlocked then we can do the normal logbuf_store() from NMI, avoiding irq flush because the data is already in the main log buffer. We also can do the same buffering bypass for non-NMI part of printk_safe, but just sometimes. PRINTK_SAFE_CONTEXT_MASK most of the times indicates that logbuf is locked, but not always - e.g. we call console_drivers under PRINTK_SAFE_CONTEXT_MASK. But like I said, not relevant to your patch. The relevant part is the possibility of race conditions. > It is still my intention to eliminate the buffering component of > printk_safe. That's understandable. > After we get a lockless ringbuffer that we are happy with, my next > series to integrate the buffer into printk will again use the sprint_rb > solution to avoid the issue discussed in this thread. Yes, I agree that either sprint_rb or just 2 LOG_LINE_MAX per-CPU buffers looks safer. This basically means that printk cannot use printk_ringbuffer as is and needs some sort of extra layer next to (or atop of) printk_ringbuffer, but we have the same thing in printk right now, basically. static char textbuf[LOG_LINE_MAX] -> logbuf. -ss
Re: [RFC PATCH v2 1/2] printk-rb: add a new printk ringbuffer implementation
On Wed 2019-06-26 09:16:11, John Ogness wrote:
> On 2019-06-26, Sergey Senozhatsky wrote:
> > [..]
> >> > CPU0 CPU1
> >> > printk(...)
> >> > sz = vscprintf(NULL, "Comm %s\n", current->comm);
> >> >
> >> > ia64_mca_modify_comm()
> >> >
> >> > snprintf(comm, sizeof(comm), "%s %d", current->comm,
> >> > previous_current->pid);
> >> >
> >> > memcpy(current->comm, comm, sizeof(current->comm));
> >> > if ((buf = prb_reserve(... sz))) {
> >> >vscnprintf(buf, "Comm %s\n", current->comm);
> >> > ^^ ->comm has changed.
> >> > Nothing critical, we
> >> > should not corrupt
> >> > anything, but we will
> >> > truncate ->comm if its
> >> > new size is larger than
> >> > what it used to be when
> >> > we did vscprintf(NULL).
> >> >prb_commit(...);
> >> > }
Great catch.
> After we get a lockless ringbuffer that we are happy with, my next
> series to integrate the buffer into printk will again use the sprint_rb
> solution to avoid the issue discussed in this thread. Perhaps it would
> be best to continue this discussion after I've posted that series.
We should keep it in head. But I fully agree with postponing
the discussion.
I personally think that this is a corner case. I would start with
a simple vscprintf(NULL, ...) and vscprintf(reserved_buf, ...)
approach. We could always make it more complex when it causes
real life problems.
If the data might change under the hood then we have bigger
problems. For example, there might be a race when the trailing
"\0" has not been written yet.
Best Regards,
Petr
[PATCH] soc: ti: pm33xx: Fix static checker warnings
The patch fixes a bunch of static checker warnings.
Reported-by: Dan Carpenter
Signed-off-by: Keerthy
---
drivers/soc/ti/pm33xx.c | 15 ++-
1 file changed, 10 insertions(+), 5 deletions(-)
diff --git a/drivers/soc/ti/pm33xx.c b/drivers/soc/ti/pm33xx.c
index bb77c220b6f8..5f3a4499cf40 100644
--- a/drivers/soc/ti/pm33xx.c
+++ b/drivers/soc/ti/pm33xx.c
@@ -252,7 +252,7 @@ static int am33xx_pm_begin(suspend_state_t state)
if (state == PM_SUSPEND_MEM && pm_ops->check_off_mode_enable()) {
nvmem = devm_nvmem_device_get(_rtc->dev,
"omap_rtc_scratch0");
- if (nvmem)
+ if (!IS_ERR(nvmem))
nvmem_device_write(nvmem, RTC_SCRATCH_MAGIC_REG * 4, 4,
(void *)_magic_val);
rtc_only_idle = 1;
@@ -278,9 +278,12 @@ static void am33xx_pm_end(void)
struct nvmem_device *nvmem;
nvmem = devm_nvmem_device_get(_rtc->dev, "omap_rtc_scratch0");
+ if (IS_ERR(nvmem))
+ return;
+
m3_ipc->ops->finish_low_power(m3_ipc);
if (rtc_only_idle) {
- if (retrigger_irq)
+ if (retrigger_irq) {
/*
* 32 bits of Interrupt Set-Pending correspond to 32
* 32 interrupts. Compute the bit offset of the
@@ -291,8 +294,10 @@ static void am33xx_pm_end(void)
writel_relaxed(1 << (retrigger_irq & 31),
gic_dist_base + GIC_INT_SET_PENDING_BASE
+ retrigger_irq / 32 * 4);
- nvmem_device_write(nvmem, RTC_SCRATCH_MAGIC_REG * 4, 4,
- (void *));
+ }
+
+ nvmem_device_write(nvmem, RTC_SCRATCH_MAGIC_REG * 4, 4,
+ (void *));
}
rtc_only_idle = 0;
@@ -415,7 +420,7 @@ static int am33xx_pm_rtc_setup(void)
nvmem = devm_nvmem_device_get(_rtc->dev,
"omap_rtc_scratch0");
- if (nvmem) {
+ if (!IS_ERR(nvmem)) {
nvmem_device_read(nvmem, RTC_SCRATCH_MAGIC_REG * 4,
4, (void *)_magic_val);
if ((rtc_magic_val & 0x) != RTC_REG_BOOT_MAGIC)
--
2.17.1
Re: [PATCH 3/4] powerpc/powernv: remove unused NPU DMA code
On Wed, Jun 26, 2019 at 10:44:38AM +1000, Alexey Kardashevskiy wrote: > > > On 26/06/2019 00:52, Christoph Hellwig wrote: > > None of these routines were ever used anywhere in the kernel tree > > since they were added to the kernel. > > > So none of my comments has been addressed. Nice. Which comment? Last time I asked you complaint "it is still used in exactly the same way as before" which you later clarified that you have a hidden out of tree user somewhere, and you only objected to the word "dead". That has been fixed and there were no further comments.
Re: [PATCH 0/8] staging: kpc2000: style refactoring
This is better. Reviewed-by: Dan Carpenter regards, dan carpenter
Re: [PATCH] drm/virtio: move drm_connector_update_edid_property() call
On Fri, 5 Apr 2019 06:46:02 +0200 Gerd Hoffmann wrote: > drm_connector_update_edid_property can sleep, we must not > call it while holding a spinlock. Move the callsize. s/callsize/callsite/ > > Reported-by: Max Filippov > Signed-off-by: Gerd Hoffmann > --- > drivers/gpu/drm/virtio/virtgpu_vq.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/virtio/virtgpu_vq.c > b/drivers/gpu/drm/virtio/virtgpu_vq.c > index e62fe24b1a2e..5bb0f0a084e9 100644 > --- a/drivers/gpu/drm/virtio/virtgpu_vq.c > +++ b/drivers/gpu/drm/virtio/virtgpu_vq.c > @@ -619,11 +619,11 @@ static void virtio_gpu_cmd_get_edid_cb(struct > virtio_gpu_device *vgdev, > output = vgdev->outputs + scanout; > > new_edid = drm_do_get_edid(>conn, virtio_get_edid_block, resp); > + drm_connector_update_edid_property(>conn, new_edid); > > spin_lock(>display_info_lock); > old_edid = output->edid; > output->edid = new_edid; > - drm_connector_update_edid_property(>conn, output->edid); > spin_unlock(>display_info_lock); > > kfree(old_edid); This gets rid of the sleeping while atomic traces I've been seeing with an s390x guest (both virtio-gpu-pci and virtio-gpu-ccw). Tested-by: Cornelia Huck I have also looked at the code a bit, but don't feel confident enough to give an R-b. Acked-by: Cornelia Huck
Re: [PATCH 0/8] pinctrl: aspeed: Preparation for AST2600
On Wed, Jun 26, 2019 at 9:15 AM Andrew Jeffery wrote: > The ASPEED AST2600 is in the pipeline, and we have enough information to start > preparing to upstream support for it. This series lays some ground work; > splitting the bindings and dicing the implementation up a little further to > facilitate differences between the 2600 and previous SoC generations. All looks good to me, but Rob should have a glance at the DT bindings and YAML syntax before I proceed to apply them. Yours, Linus Walleij
Re: [PATCH 4.19 55/90] drm/arm/mali-dp: Add a loop around the second set CVAL and try 5 times
On Mon 2019-06-24 17:56:45, Greg Kroah-Hartman wrote:
> [ Upstream commit 6a88e0c14813d00f8520d0e16cd4136c6cf8b4d4 ]
>
> This patch trying to fix monitor freeze issue caused by drm error
> 'flip_done timed out' on LS1028A platform. this set try is make a loop
> around the second setting CVAL and try like 5 times before giveing up.
> @@ -204,8 +205,18 @@ static void malidp_atomic_commit_hw_done(struct
> drm_atomic_state *state)
> drm_crtc_vblank_get(>crtc);
>
> /* only set config_valid if the CRTC is enabled */
> - if (malidp_set_and_wait_config_valid(drm) < 0)
> + if (malidp_set_and_wait_config_valid(drm) < 0) {
> + /*
> + * make a loop around the second CVAL setting and
> + * try 5 times before giving up.
> + */
> + while (loop--) {
> + if (!malidp_set_and_wait_config_valid(drm))
> + break;
> + }
> DRM_DEBUG_DRIVER("timed out waiting for updated
> configuration\n");
> + }
> +
We'll still get the debug message even if
malidp_set_and_wait_config_valid() suceeded. That does not sound
right.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
signature.asc
Description: Digital signature
Re: [PATCH 1/2 RESEND2] perf/x86/amd/uncore: Do not set ThreadMask and SliceMask for non-L3 PMCs
On Tue, Jun 25, 2019 at 02:56:23PM +, Phillips, Kim wrote:
> From: Kim Phillips
>
> Commit d7cbbe49a930 ("perf/x86/amd/uncore: Set ThreadMask and SliceMask
> for L3 Cache perf events") enables L3 PMC events for all threads and
> slices by writing 1s in ChL3PmcCfg (L3 PMC PERF_CTL) register fields.
>
> Those bitfields overlap with high order event select bits in the Data
> Fabric PMC control register, however.
>
> So when a user requests raw Data Fabric events (-e amd_df/event=0xYYY/),
> the two highest order bits get inadvertently set, changing the counter
> select to events that don't exist, and for which no counts are read.
>
> This patch changes the logic to write the L3 masks only when dealing
> with L3 PMC counters.
>
> AMD Family 16h and below Northbridge (NB) counters were not affected.
>
> Signed-off-by: Kim Phillips
Still base64 encoded garbage; the actual email reads like below.
Please use a sane MUa and send it plain text.
---
Content-Transfer-Encoding: base64
RnJvbTogS2ltIFBoaWxsaXBzIDxraW0ucGhpbGxpcHNAYW1kLmNvbT4NCg0KQ29tbWl0IGQ3Y2Ji
ZTQ5YTkzMCAoInBlcmYveDg2L2FtZC91bmNvcmU6IFNldCBUaHJlYWRNYXNrIGFuZCBTbGljZU1h
c2sNCmZvciBMMyBDYWNoZSBwZXJmIGV2ZW50cyIpIGVuYWJsZXMgTDMgUE1DIGV2ZW50cyBmb3Ig
YWxsIHRocmVhZHMgYW5kDQpzbGljZXMgYnkgd3JpdGluZyAxcyBpbiBDaEwzUG1jQ2ZnIChMMyBQ
TUMgUEVSRl9DVEwpIHJlZ2lzdGVyIGZpZWxkcy4NCg0KVGhvc2UgYml0ZmllbGRzIG92ZXJsYXAg
d2l0aCBoaWdoIG9yZGVyIGV2ZW50IHNlbGVjdCBiaXRzIGluIHRoZSBEYXRhDQpGYWJyaWMgUE1D
IGNvbnRyb2wgcmVnaXN0ZXIsIGhvd2V2ZXIuDQoNClNvIHdoZW4gYSB1c2VyIHJlcXVlc3RzIHJh
[PATCH v4 0/4] usb: xhci: Add support for Renesas USB controllers
This series add support for Renesas USB controllers uPD720201 and uPD720202. These require firmware to be loaded and in case devices have ROM those can also be programmed if empty. If ROM is programmed, it runs from ROM as well. This includes two patches from Christian which supported these controllers w/o ROM and later my patches for ROM support and multiple firmware versions. Changes in v4: Rollback the delay values as we got device failures Changes in v3: Dropped patch 2 as discussed with Christian Removed aligned 8 bytes check Change order for firware search from highest version to lowest Added entry for new firmware for device 0x14 as well Add tested by Christian Changes in v2: used macros for timeout count and delay removed renesas_fw_alive_check cleaned renesas_fw_callback removed recurion for renesas_fw_download added MODULE_FIRMWARE added comment for multiple fw order Christian Lamparter (1): usb: xhci: add firmware loader for uPD720201 and uPD720202 w/o ROM Vinod Koul (3): usb: xhci: Use register defined and field names usb: xhci: Add ROM loader for uPD720201 usb: xhci: allow multiple firmware versions drivers/usb/host/xhci-pci.c | 875 1 file changed, 875 insertions(+) -- 2.20.1
[PATCH v4 2/4] usb: xhci: Use register defined and field names
Instead of using register values and fields lets define them and
use in the driver.
Signed-off-by: Vinod Koul
Cc: Yoshihiro Shimoda
Cc: Christian Lamparter
Tested-by: Christian Lamparter
---
drivers/usb/host/xhci-pci.c | 60 ++---
1 file changed, 43 insertions(+), 17 deletions(-)
diff --git a/drivers/usb/host/xhci-pci.c b/drivers/usb/host/xhci-pci.c
index 237df5c47fca..0f2574b42cb1 100644
--- a/drivers/usb/host/xhci-pci.c
+++ b/drivers/usb/host/xhci-pci.c
@@ -57,6 +57,27 @@
#define PCI_DEVICE_ID_AMD_PROMONTORYA_10x43bc
#define PCI_DEVICE_ID_ASMEDIA_1042A_XHCI 0x1142
+#define RENESAS_FW_VERSION 0x6C
+#define RENESAS_ROM_CONFIG 0xF0
+#define RENESAS_FW_STATUS 0xF4
+#define RENESAS_FW_STATUS_MSB 0xF5
+#define RENESAS_ROM_STATUS 0xF6
+#define RENESAS_ROM_STATUS_MSB 0xF7
+#define RENESAS_DATA0 0xF8
+#define RENESAS_DATA1 0xFC
+
+#define RENESAS_FW_VERSION_FIELD GENMASK(23, 7)
+#define RENESAS_FW_VERSION_OFFSET 8
+
+#define RENESAS_FW_STATUS_DOWNLOAD_ENABLE BIT(0)
+#define RENESAS_FW_STATUS_LOCK BIT(1)
+#define RENESAS_FW_STATUS_RESULT GENMASK(6, 4)
+ #define RENESAS_FW_STATUS_INVALID0
+ #define RENESAS_FW_STATUS_SUCCESSBIT(4)
+ #define RENESAS_FW_STATUS_ERROR BIT(5)
+#define RENESAS_FW_STATUS_SET_DATA0BIT(8)
+#define RENESAS_FW_STATUS_SET_DATA1BIT(9)
+
#define RENESAS_RETRY 1
#define RENESAS_DELAY 10
@@ -347,7 +368,8 @@ static int renesas_fw_download_image(struct pci_dev *dev,
/* step+1. Read "Set DATAX" and confirm it is cleared. */
for (i = 0; i < RENESAS_RETRY; i++) {
- err = pci_read_config_byte(dev, 0xF5, _status);
+ err = pci_read_config_byte(dev, RENESAS_FW_STATUS_MSB,
+ _status);
if (err)
return pcibios_err_to_errno(err);
if (!(fw_status & BIT(data0_or_data1)))
@@ -362,7 +384,8 @@ static int renesas_fw_download_image(struct pci_dev *dev,
* step+2. Write FW data to "DATAX".
* "LSB is left" => force little endian
*/
- err = pci_write_config_dword(dev, data0_or_data1 ? 0xFC : 0xF8,
+ err = pci_write_config_dword(dev, data0_or_data1 ?
+RENESAS_DATA1 : RENESAS_DATA0,
(__force u32)cpu_to_le32(fw[step]));
if (err)
return pcibios_err_to_errno(err);
@@ -370,7 +393,8 @@ static int renesas_fw_download_image(struct pci_dev *dev,
udelay(100);
/* step+3. Set "Set DATAX". */
- err = pci_write_config_byte(dev, 0xF5, BIT(data0_or_data1));
+ err = pci_write_config_byte(dev, RENESAS_FW_STATUS_MSB,
+ BIT(data0_or_data1));
if (err)
return pcibios_err_to_errno(err);
@@ -440,7 +464,7 @@ static int renesas_fw_check_running(struct pci_dev *pdev)
* BIOSes will initialize the device for us. If the device is
* initialized.
*/
- err = pci_read_config_byte(pdev, 0xF4, _state);
+ err = pci_read_config_byte(pdev, RENESAS_FW_STATUS, _state);
if (err)
return pcibios_err_to_errno(err);
@@ -449,10 +473,10 @@ static int renesas_fw_check_running(struct pci_dev *pdev)
* ready we can simply continue. If the FW is not ready, we have
* to give up.
*/
- if (fw_state & BIT(1)) {
+ if (fw_state & RENESAS_FW_STATUS_LOCK) {
dev_dbg(>dev, "FW Download Lock is engaged.");
- if (fw_state & BIT(4))
+ if (fw_state & RENESAS_FW_STATUS_SUCCESS)
return 0;
dev_err(>dev,
@@ -465,33 +489,33 @@ static int renesas_fw_check_running(struct pci_dev *pdev)
* with it and it can't be resetted, we have to give up too... and
* ask for a forgiveness and a reboot.
*/
- if (fw_state & BIT(0)) {
+ if (fw_state & RENESAS_FW_STATUS_DOWNLOAD_ENABLE) {
dev_err(>dev,
"FW Download Enable is stale. Giving Up
(poweroff/reboot needed).");
return -EIO;
}
/* Otherwise, Check the "Result Code" Bits (6:4) and act accordingly */
- switch ((fw_state & 0x70)) {
+ switch (fw_state & RENESAS_FW_STATUS_RESULT) {
case 0: /* No result yet */
dev_dbg(>dev, "FW is not ready/loaded yet.");
/* tell the caller, that this device needs the firmware. */
Re: [PATCH][V4] lib: fix __sysfs_match_string() helper when n != -1
On Tue, 2019-06-25 at 12:42 -0700, Andrew Morton wrote: > [External] > > > On Tue, 25 Jun 2019 16:28:12 +0300 Andy Shevchenko > wrote: > > > On Tue, Jun 25, 2019 at 04:01:04PM +0300, Alexandru Ardelean wrote: > > > The documentation the `__sysfs_match_string()` helper mentions that `n` > > > (the size of the given array) should be: > > > * @n: number of strings in the array or -1 for NULL terminated arrays > > > > > > The behavior of the function is different, in the sense that it exits on > > > the first NULL element in the array. > > > > > > This patch changes the behavior, to exit the loop when a NULL element is > > > found, and the size of the array is provided as -1. > > > > > > All current users of __sysfs_match_string() & sysfs_match_string() provide > > > contiguous arrays of strings, so this behavior change doesn't influence > > > anything (at this point in time). > > > > > > This behavior change allows for an array of strings to have NULL elements > > > within the array, which will be ignored. This is particularly useful when > > > creating mapping of strings and integers (as bitfields or other HW > > > description). > > > > Since it does nothing for current users and comes without an example, > > it's hard to justify the need. > > Presumably "split this patch away from series" means there's some code > which uses this. A reference to this in the changelog would be good. > > > The code itself looks good to me. > > Sure. But the kerneldoc description of __sysfs_match_string() could do > with an update. > Apologies for any clumsiness here [from my side]. The series tried to handle a change for supporting gaps in IIO enums. Particularly this patch: https://patchwork.kernel.org/patch/10935003/ These enums use __sysfs_match_string() to match strings to enum/int values. There were 3 versions: https://patchwork.kernel.org/project/linux-iio/list/?series=108481 [V1] https://patchwork.kernel.org/project/linux-iio/list/?series=108603 [V2] https://patchwork.kernel.org/project/linux-iio/list/?series=115201 [V3] The last series [V3] has an unresolved discussion about how to handle gaps in IIO enums. This will be resolved at a later point in time. In the meantime, I thought I'd suggest this change on it's own, mostly due to the kerneldoc not being accurate. I'm fine with both fixing the kerneldoc or fixing the code. We will still have to resolve the discussion in IIO about how to handle those gapped enums. >
[PATCH v4 1/4] usb: xhci: add firmware loader for uPD720201 and uPD720202 w/o ROM
From: Christian Lamparter
This patch adds a firmware loader for the uPD720201K8-711-BAC-A
and uPD720202K8-711-BAA-A variant. Both of these chips are listed
in Renesas' R19UH0078EJ0500 Rev.5.00 "User's Manual: Hardware" as
devices which need the firmware loader on page 2 in order to
work as they "do not support the External ROM".
The "Firmware Download Sequence" is describe in chapter
"7.1 FW Download Interface" R19UH0078EJ0500 Rev.5.00 page 131.
The firmware "K2013080.mem" is available from a USB3.0 Host to
PCIe Adapter (PP2U-E card) "Firmware download" archive. An
alternative version can be sourced from Netgear's WNDR4700 GPL
archives.
The release notes of the PP2U-E's "Firmware Download" ver 2.0.1.3
(2012-06-15) state that the firmware is for the following devices:
- uPD720201 ES 2.0 sample whose revision ID is 2.
- uPD720201 ES 2.1 sample & CS sample & Mass product, ID is 3.
- uPD720202 ES 2.0 sample & CS sample & Mass product, ID is 2.
Cc: Yoshihiro Shimoda
Signed-off-by: Christian Lamparter
Signed-off-by: Bjorn Andersson
[vkoul: fixed comments:
used macros for timeout count and delay
removed renesas_fw_alive_check
cleaned renesas_fw_callback
removed recurion for renesas_fw_download
added MODULE_FIRMWARE]
Tested-by: Christian Lamparter
Signed-off-by: Vinod Koul
---
drivers/usb/host/xhci-pci.c | 454
1 file changed, 454 insertions(+)
diff --git a/drivers/usb/host/xhci-pci.c b/drivers/usb/host/xhci-pci.c
index c2fe218e051f..237df5c47fca 100644
--- a/drivers/usb/host/xhci-pci.c
+++ b/drivers/usb/host/xhci-pci.c
@@ -12,6 +12,8 @@
#include
#include
#include
+#include
+#include
#include "xhci.h"
#include "xhci-trace.h"
@@ -55,6 +57,9 @@
#define PCI_DEVICE_ID_AMD_PROMONTORYA_10x43bc
#define PCI_DEVICE_ID_ASMEDIA_1042A_XHCI 0x1142
+#define RENESAS_RETRY 1
+#define RENESAS_DELAY 10
+
static const char hcd_name[] = "xhci_hcd";
static struct hc_driver __read_mostly xhci_pci_hc_driver;
@@ -279,6 +284,429 @@ static void xhci_pme_acpi_rtd3_enable(struct pci_dev *dev)
static void xhci_pme_acpi_rtd3_enable(struct pci_dev *dev) { }
#endif /* CONFIG_ACPI */
+static const struct renesas_fw_entry {
+ const char *firmware_name;
+ u16 device;
+ u8 revision;
+ u16 expected_version;
+} renesas_fw_table[] = {
+ /*
+* Only the uPD720201K8-711-BAC-A or uPD720202K8-711-BAA-A
+* are listed in R19UH0078EJ0500 Rev.5.00 as devices which
+* need the software loader.
+*
+* PP2U/ReleaseNote_USB3-201-202-FW.txt:
+*
+* Note: This firmware is for the following devices.
+* - uPD720201 ES 2.0 sample whose revision ID is 2.
+* - uPD720201 ES 2.1 sample & CS sample & Mass product, ID is 3.
+* - uPD720202 ES 2.0 sample & CS sample & Mass product, ID is 2.
+*/
+ { "K2013080.mem", 0x0014, 0x02, 0x2013 },
+ { "K2013080.mem", 0x0014, 0x03, 0x2013 },
+ { "K2013080.mem", 0x0015, 0x02, 0x2013 },
+};
+
+MODULE_FIRMWARE("K2013080.mem");
+
+static const struct renesas_fw_entry *renesas_needs_fw_dl(struct pci_dev *dev)
+{
+ const struct renesas_fw_entry *entry;
+ size_t i;
+
+ /* This loader will only work with a RENESAS device. */
+ if (!(dev->vendor == PCI_VENDOR_ID_RENESAS))
+ return NULL;
+
+ for (i = 0; i < ARRAY_SIZE(renesas_fw_table); i++) {
+ entry = _fw_table[i];
+ if (entry->device == dev->device &&
+ entry->revision == dev->revision)
+ return entry;
+ }
+
+ return NULL;
+}
+
+static int renesas_fw_download_image(struct pci_dev *dev,
+const u32 *fw,
+size_t step)
+{
+ size_t i;
+ int err;
+ u8 fw_status;
+ bool data0_or_data1;
+
+ /*
+* The hardware does alternate between two 32-bit pages.
+* (This is because each row of the firmware is 8 bytes).
+*
+* for even steps we use DATA0, for odd steps DATA1.
+*/
+ data0_or_data1 = (step & 1) == 1;
+
+ /* step+1. Read "Set DATAX" and confirm it is cleared. */
+ for (i = 0; i < RENESAS_RETRY; i++) {
+ err = pci_read_config_byte(dev, 0xF5, _status);
+ if (err)
+ return pcibios_err_to_errno(err);
+ if (!(fw_status & BIT(data0_or_data1)))
+ break;
+
+ udelay(RENESAS_DELAY);
+ }
+ if (i == RENESAS_RETRY)
+ return -ETIMEDOUT;
+
+ /*
+* step+2. Write FW data to "DATAX".
+* "LSB is left" => force little endian
+*/
+ err = pci_write_config_dword(dev, data0_or_data1 ? 0xFC : 0xF8,
+(__force u32)cpu_to_le32(fw[step]));
+ if (err)
+
Re: [PATCH v2 0/3] mm: Cleanup & allow modules to hotplug memory
On Wed, Jun 26, 2019 at 04:11:20PM +1000, Alastair D'Silva wrote: > - Drop mm/hotplug: export try_online_node > (not necessary) With this the subject line of the cover letter seems incorrect now :)
[PATCH v4 4/4] usb: xhci: allow multiple firmware versions
Allow multiple firmware file versions in table and load them in
increasing order as we find them in the file system.
Signed-off-by: Vinod Koul
Cc: Yoshihiro Shimoda
Cc: Christian Lamparter
Tested-by: Christian Lamparter
---
drivers/usb/host/xhci-pci.c | 47 +++--
1 file changed, 45 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/host/xhci-pci.c b/drivers/usb/host/xhci-pci.c
index 996068ead731..c0341e9f37f7 100644
--- a/drivers/usb/host/xhci-pci.c
+++ b/drivers/usb/host/xhci-pci.c
@@ -336,13 +336,20 @@ static const struct renesas_fw_entry {
* - uPD720201 ES 2.0 sample whose revision ID is 2.
* - uPD720201 ES 2.1 sample & CS sample & Mass product, ID is 3.
* - uPD720202 ES 2.0 sample & CS sample & Mass product, ID is 2.
+*
+* Entry expected_version should be kept in increasing order for a
+* chip, so that driver will pick first version and if that fails
+* then next one will be picked
*/
{ "K2013080.mem", 0x0014, 0x02, 0x2013 },
+ { "K2026090.mem", 0x0014, 0x03, 0x2026 },
{ "K2013080.mem", 0x0014, 0x03, 0x2013 },
+ { "K2026090.mem", 0x0015, 0x02, 0x2026 },
{ "K2013080.mem", 0x0015, 0x02, 0x2013 },
};
MODULE_FIRMWARE("K2013080.mem");
+MODULE_FIRMWARE("K2026090.mem");
static const struct renesas_fw_entry *renesas_needs_fw_dl(struct pci_dev *dev)
{
@@ -363,6 +370,24 @@ static const struct renesas_fw_entry
*renesas_needs_fw_dl(struct pci_dev *dev)
return NULL;
}
+static const struct
+renesas_fw_entry *renesas_get_next_entry(struct pci_dev *dev,
+const struct renesas_fw_entry *entry)
+{
+ const struct renesas_fw_entry *next_entry;
+ size_t i;
+
+ for (i = 0; i < ARRAY_SIZE(renesas_fw_table); i++) {
+ next_entry = _fw_table[i];
+ if (next_entry->device == dev->device &&
+ next_entry->revision == dev->revision &&
+ next_entry->expected_version < entry->expected_version)
+ return next_entry;
+ }
+
+ return NULL;
+}
+
static int renesas_fw_download_image(struct pci_dev *dev,
const u32 *fw,
size_t step)
@@ -705,6 +730,7 @@ struct renesas_fw_ctx {
struct pci_dev *pdev;
const struct pci_device_id *id;
bool resume;
+ const struct renesas_fw_entry *entry;
};
static int xhci_pci_probe(struct pci_dev *pdev,
@@ -964,13 +990,29 @@ static void renesas_fw_callback(const struct firmware *fw,
struct renesas_fw_ctx *ctx = context;
struct pci_dev *pdev = ctx->pdev;
struct device *parent = pdev->dev.parent;
+ const struct renesas_fw_entry *next_entry;
bool rom;
int err;
if (!fw) {
dev_err(>dev, "firmware failed to load\n");
-
- goto cleanup;
+ /*
+* we didn't find firmware, check if we have another
+* entry for this device
+*/
+ next_entry = renesas_get_next_entry(ctx->pdev, ctx->entry);
+ if (next_entry) {
+ ctx->entry = next_entry;
+ dev_dbg(>dev, "Found next entry, requesting:
%s\n",
+ next_entry->firmware_name);
+ request_firmware_nowait(THIS_MODULE, 1,
+ next_entry->firmware_name,
+ >dev, GFP_KERNEL,
+ ctx, renesas_fw_callback);
+ return;
+ } else {
+ goto cleanup;
+ }
}
err = renesas_fw_verify(pdev, fw->data, fw->size);
@@ -1068,6 +1110,7 @@ static int renesas_fw_download_to_hw(struct pci_dev *pdev,
ctx->pdev = pdev;
ctx->resume = do_resume;
ctx->id = id;
+ ctx->entry = entry;
pci_dev_get(pdev);
err = request_firmware_nowait(THIS_MODULE, 1, entry->firmware_name,
--
2.20.1
Re: [RFC PATCH v2 1/2] printk-rb: add a new printk ringbuffer implementation
On (06/26/19 09:47), Petr Mladek wrote: [..] > If the data might change under the hood then we have bigger > problems. For example, there might be a race when the trailing > "\0" has not been written yet. Current printk would not handle such cases. I'm only talking about transition from one consistent state to another, when sprintf(NULL, ptr) == A && sprintf(buf, ptr) != A Wether it's a corner case or not is entirely unclear to me but I probably would not call it "an impossible scenario". -ss
Re: [PATCH] RISC-V: defconfig: enable MMC & SPI for RISC-V
On Tue, 25 Jun 2019 15:56:36 PDT (-0700), Atish Patra wrote: Currently, riscv upstream defconfig doesn't let you boot through userspace if rootfs is on the SD card. Let's enable MMC & SPI drivers as well so that one can boot to the user space using default config in upstream kernel. Signed-off-by: Atish Patra --- arch/riscv/configs/defconfig | 5 + 1 file changed, 5 insertions(+) diff --git a/arch/riscv/configs/defconfig b/arch/riscv/configs/defconfig index 4f02967e55de..04944fb4fa7a 100644 --- a/arch/riscv/configs/defconfig +++ b/arch/riscv/configs/defconfig @@ -69,6 +69,7 @@ CONFIG_VIRTIO_MMIO=y CONFIG_CLK_SIFIVE=y CONFIG_CLK_SIFIVE_FU540_PRCI=y CONFIG_SIFIVE_PLIC=y +CONFIG_SPI_SIFIVE=y CONFIG_EXT4_FS=y CONFIG_EXT4_FS_POSIX_ACL=y CONFIG_AUTOFS4_FS=y @@ -84,4 +85,8 @@ CONFIG_ROOT_NFS=y CONFIG_CRYPTO_USER_API_HASH=y CONFIG_CRYPTO_DEV_VIRTIO=y CONFIG_PRINTK_TIME=y +CONFIG_SPI=y +CONFIG_MMC_SPI=y +CONFIG_MMC=y +CONFIG_DEVTMPFS_MOUNT=y # CONFIG_RCU_TRACE is not set Reviewed-by: Palmer Dabbelt
[PATCH v4 3/4] usb: xhci: Add ROM loader for uPD720201
uPD720201 supports ROM and allows software to program the ROM and boot
from it. Add support for detecting if ROM is present, if so load the ROM
if not programmed earlier.
Signed-off-by: Vinod Koul
Cc: Yoshihiro Shimoda
Cc: Christian Lamparter
Tested-by: Christian Lamparter
---
drivers/usb/host/xhci-pci.c | 352
1 file changed, 352 insertions(+)
diff --git a/drivers/usb/host/xhci-pci.c b/drivers/usb/host/xhci-pci.c
index 0f2574b42cb1..996068ead731 100644
--- a/drivers/usb/host/xhci-pci.c
+++ b/drivers/usb/host/xhci-pci.c
@@ -78,6 +78,20 @@
#define RENESAS_FW_STATUS_SET_DATA0BIT(8)
#define RENESAS_FW_STATUS_SET_DATA1BIT(9)
+#define RENESAS_ROM_STATUS_ACCESS BIT(0)
+#define RENESAS_ROM_STATUS_ERASE BIT(1)
+#define RENESAS_ROM_STATUS_RELOAD BIT(2)
+#define RENESAS_ROM_STATUS_RESULT GENMASK(6, 4)
+ #define RENESAS_ROM_STATUS_INVALID 0
+ #define RENESAS_ROM_STATUS_SUCCESS BIT(4)
+ #define RENESAS_ROM_STATUS_ERROR BIT(5)
+#define RENESAS_ROM_STATUS_SET_DATA0 BIT(8)
+#define RENESAS_ROM_STATUS_SET_DATA1 BIT(9)
+#define RENESAS_ROM_STATUS_ROM_EXISTS BIT(15)
+
+#define RENESAS_ROM_ERASE_MAGIC0x5A65726F
+#define RENESAS_ROM_WRITE_MAGIC0x53524F4D
+
#define RENESAS_RETRY 1
#define RENESAS_DELAY 10
@@ -454,11 +468,79 @@ static int renesas_fw_verify(struct pci_dev *dev,
return 0;
}
+static int renesas_check_rom_state(struct pci_dev *pdev)
+{
+ const struct renesas_fw_entry *entry;
+ u16 rom_state;
+ u32 version;
+ bool valid_version = false;
+ int err, i;
+
+ /* check FW version */
+ err = pci_read_config_dword(pdev, RENESAS_FW_VERSION, );
+ if (err)
+ return pcibios_err_to_errno(err);
+
+ version &= RENESAS_FW_VERSION_FIELD;
+ version = version >> RENESAS_FW_VERSION_OFFSET;
+ dev_dbg(>dev, "Found FW version loaded is %x\n", version);
+
+ /* treat version in renesas_fw_table as correct ones */
+ for (i = 0; i < ARRAY_SIZE(renesas_fw_table); i++) {
+ entry = _fw_table[i];
+ if (version == entry->expected_version) {
+ dev_dbg(>dev, "Detected valid ROM version..\n");
+ valid_version = true;
+ }
+ }
+
+ /*
+* Test if ROM is present and loaded, if so we can skip everything
+*/
+ err = pci_read_config_word(pdev, RENESAS_ROM_STATUS, _state);
+ if (err)
+ return pcibios_err_to_errno(err);
+
+ if (rom_state & BIT(15)) {
+ /* ROM exists */
+ dev_dbg(>dev, "ROM exists\n");
+
+ /* Check the "Result Code" Bits (6:4) and act accordingly */
+ switch (rom_state & RENESAS_ROM_STATUS_RESULT) {
+ case RENESAS_ROM_STATUS_SUCCESS:
+ dev_dbg(>dev, "Success ROM load...");
+ /* we have valid version and status so success */
+ if (valid_version)
+ return 0;
+ break;
+
+ case RENESAS_ROM_STATUS_INVALID: /* No result yet */
+ dev_dbg(>dev, "No result as it is ROM...");
+ /* we have valid version and status so success */
+ if (valid_version)
+ return 0;
+ break;
+
+ case RENESAS_ROM_STATUS_ERROR: /* Error State */
+ default: /* All other states are marked as "Reserved states" */
+ dev_err(>dev, "Invalid ROM..");
+ break;
+ }
+ }
+
+ return -EIO;
+}
+
static int renesas_fw_check_running(struct pci_dev *pdev)
{
int err;
u8 fw_state;
+ /* Check if device has ROM and loaded, if so skip everything */
+ err = renesas_check_rom_state(pdev);
+ if (!err)
+ return err;
+
/*
* Test if the device is actually needing the firmware. As most
* BIOSes will initialize the device for us. If the device is
@@ -628,12 +710,261 @@ struct renesas_fw_ctx {
static int xhci_pci_probe(struct pci_dev *pdev,
const struct pci_device_id *id);
+static bool renesas_check_rom(struct pci_dev *pdev)
+{
+ u16 rom_status;
+ int retval;
+
+ /* 1. Check if external ROM exists */
+ retval = pci_read_config_word(pdev, RENESAS_ROM_STATUS, _status);
+ if (retval)
+ return false;
+
+ rom_status &= RENESAS_ROM_STATUS_ROM_EXISTS;
+ if (rom_status) {
+ dev_dbg(>dev, "External ROM exists\n");
+ return
Re: [PATCH v2 0/5] Allocate memmap from hotadded memory
On Tue, Jun 25, 2019 at 10:25:48AM +0200, David Hildenbrand wrote:
> > [Coverletter]
> >
> > This is another step to make memory hotplug more usable. The primary
> > goal of this patchset is to reduce memory overhead of the hot-added
> > memory (at least for SPARSEMEM_VMEMMAP memory model). The current way we use
> > to populate memmap (struct page array) has two main drawbacks:
First off, thanks for looking into this :-)
>
> Mental note: How will it be handled if a caller specifies "Allocate
> memmap from hotadded memory", but we are running under SPARSEMEM where
> we can't do this.
In add_memory_resource(), we have a call to mhp_check_correct_flags(), which is
in charge of checking if the flags passed are compliant with our configuration
among other things.
It also checks if both flags were passed (_MEMBLOCK|_DEVICE).
If a) any of the flags were specified and we are not on
CONFIG_SPARSEMEM_VMEMMAP,
b) the flags are colliding with each other or c) the flags just do not make
sense,
we print out a warning and drop the flags to 0, so we just ignore them.
I just realized that I can adjust the check even more (something for the next
version).
But to answer your question, flags are ignored under !CONFIG_SPARSEMEM_VMEMMAP.
>
> >
> > a) it consumes an additional memory until the hotadded memory itself is
> >onlined and
> > b) memmap might end up on a different numa node which is especially true
> >for movable_node configuration.
> >
> > a) it is a problem especially for memory hotplug based memory "ballooning"
> >solutions when the delay between physical memory hotplug and the
> >onlining can lead to OOM and that led to introduction of hacks like auto
> >onlining (see 31bc3858ea3e ("memory-hotplug: add automatic onlining
> >policy for the newly added memory")).
> >
> > b) can have performance drawbacks.
> >
> > Another minor case is that I have seen hot-add operations failing on archs
> > because they were running out of order-x pages.
> > E.g On powerpc, in certain configurations, we use order-8 pages,
> > and given 64KB base pagesize, that is 16MB.
> > If we run out of those, we just fail the operation and we cannot add
> > more memory.
>
> At least for SPARSEMEM, we fallback to vmalloc() to work around this
> issue. I haven't looked into the populate_section_memmap() internals
> yet. Can you point me at the code that performs this allocation?
Yes, on SPARSEMEM we first try to allocate the pages physical configuous, and
then fallback to vmalloc.
This is because on CONFIG_SPARSEMEM memory model, the translations pfn_to_page/
page_to_pfn do not expect the memory to be contiguous.
But that is not the case on CONFIG_SPARSEMEM_VMEMMAP.
We do expect the memory to be physical contigous there, that is why a simply
pfn_to_page/page_to_pfn is a matter of adding/substracting vmemmap/pfn.
Powerpc code is at:
https://elixir.bootlin.com/linux/v5.2-rc6/source/arch/powerpc/mm/init_64.c#L175
> So, assuming we add_memory(1GB, MHP_MEMMAP_DEVICE) and then
> remove_memory(128MB) of the added memory, this will work?
No, MHP_MEMMAP_DEVICE is meant to be used when hot-adding and hot-removing work
in the same granularity.
This is because all memmap pages will be stored at the beginning of the memory
range.
Allowing hot-removing in a different granularity on MHP_MEMMAP_DEVICE would
imply
a lot of extra work.
For example, we would have to parse the vmemmap-head of the hot-removed range,
and punch a hole in there to clear the vmemmap pages, and then be very carefull
when deleting those pagetables.
So I followed Michal's advice, and I decided to let the caller specify if he
either wants to allocate per memory block or per hot-added range(device).
Where per memory block, allows us to do:
add_memory(1GB, MHP_MEMMAP_MEMBLOCK)
remove_memory(128MB)
> add_memory(8GB, MHP_MEMMAP_DEVICE)
>
> For 8GB, we will need exactly 128MB of memmap if I did the math right.
> So exactly one section. This section will still be marked as being
> online (although not pages on it are actually online)?
Yap, 8GB will fill the first section with vmemmap pages.
It will be marked as online, yes.
This is not to diverge too much from what we have right now, and starting
treat some sections different than others.
E.g: Early sections that are used for memmap pages on early boot stage.
> >
> > What we do is that since when we hot-remove a memory-range, sections are
> > being
> > removed sequentially, we wait until we hit the last section, and then we
> > free
> > the hole range to vmemmap_free backwards.
> > We know that it is the last section because in every pass we
> > decrease head->_refcount, and when it reaches 0, we got our last section.
> >
> > We also have to be careful about those pages during online and offline
> > operations. They are simply skipped, so online will keep them
> > reserved and so unusable for any other purpose and offline ignores them
> > so they do not block the offline operation.
>
>
Re: [PATCH] perf/x86/intel: Mark expected switch fall-throughs
On Tue, Jun 25, 2019 at 10:12:42AM -0700, Kees Cook wrote: > On Tue, Jun 25, 2019 at 09:18:46AM +0200, Peter Zijlstra wrote: > > Can it build a kernel without patches yet? That is, why should I care > > what LLVM does? > > Yes. LLVM trunk builds and boots x86 now. As for distro availability, If it's not release and not in distros, then no. So then get that same trunk to support the __fallthrough crap so it all lands in the same release and we done ;-)
Re: [PATCH RFC 1/2] PM / devfreq: Generic CPU frequency to device frequency mapping governor
Hello Sibi and Hsin-Yi, On 19. 6. 20. 오후 6:41, Sibi Sankar wrote: > Hey Hsin-Yi, Chanwoo > > On 2019-06-20 15:02, Hsin-Yi Wang wrote: >> Hi Chanwoo Choi, Saravana Kannan and Sibi Sankar, >> >> I've also tested Sibi Sankar's patch[1] locally with mt8183-cci, and >> it works fine too! >> It'd be great if Sibi Sankar or anyone who is familiar with the >> original design can finish this implementation. But if no one has time >> to do that, I think I can also help on address the comments. Thanks! > > Now that we have a user :) I am happy > to repost the patch with the comments > addressed. > > https://lkml.org/lkml/2019/6/14/4 > Also with ^^ patch and few more in the > series the dt parsing of required-opps > should get further simplified. Even if patch[1] suggested by Saravana is merged, the patch[2] is necessary. Because, until now, the child devfreq device cannot catch the timing of CPU frequency without CPUFREQ notification. The existing passive governor only supports between devfreq device and other devfreq device. [1] https://lkml.org/lkml/2019/6/14/4 [2] [PATCH RFC 0/9] Add CPU based scaling support to Passive governor - https://lore.kernel.org/lkml/08c3cff8c39e3d82e044db93e992d...@codeaurora.org/T/ [PATCH RFC 3/9] PM / devfreq: Add cpu based scaling support to passive_governor - https://lore.kernel.org/lkml/08c3cff8c39e3d82e044db93e992d...@codeaurora.org/T/#m1cafb7baf687d2a680d39c85d3ec7d1b590b68fc > >> >> >> [1] >> [RFC,2/9] OPP: Export a number of helpers to prevent code duplication >> - https://patchwork.kernel.org/patch/10875199/ >> [RFC,3/9] PM / devfreq: Add cpu based scaling support to passive_governor >> - https://patchwork.kernel.org/patch/10875195/ >> >> Hsin-Yi >> >> On Thu, Jun 20, 2019 at 2:56 PM Chanwoo Choi wrote: >>> >>> + Sibi Sankar >>> >>> Hi, Hsin-Yi Wang, Saravana Kannan and Sibi Sankar >>> >>> I summarized the history of the related patch about this title. >>> >>> Firstly, >>> As I knew, Saravana sent the patch[1] which contains >>> 'governor_cpufreq_map.c' last year. According to the Myungoo's comment, >>> >>> Secondly, >>> Sibi Sankar modified the 'governor_passive.c'[2] in order to support >>> the mapping between cpu frequency and device frequency. >>> Unfortunately, Sibi Sankar stopped the development about this >>> because he had found the other method to get his purpose as I knew. >>> >>> Thirdly, >>> Hsin-Yi Wang send the original patch of Saravana without modification. >>> >>> >>> Sincerely, I think that the mapping between cpu frequency and device >>> frequency is necessary. And I prefer the Sibi's approach which implements >>> stuff to the existing 'passive' governor. >>> >>> We need to discuss about how to implement them by whom. >>> >>> >>> [1] [v3,1/2] PM / devfreq: Generic CPU frequency to device frequency >>> mapping governor >>> - https://patchwork.kernel.org/patch/10553171/ >>> >>> [2] >>> [PATCH RFC 0/9] Add CPU based scaling support to Passive governor >>> - >>> https://lore.kernel.org/lkml/08c3cff8c39e3d82e044db93e992d...@codeaurora.org/T/ >>> [PATCH RFC 3/9] PM / devfreq: Add cpu based scaling support to >>> passive_governor >>> - >>> https://lore.kernel.org/lkml/08c3cff8c39e3d82e044db93e992d...@codeaurora.org/T/#m1cafb7baf687d2a680d39c85d3ec7d1b590b68fc >>> >>> >>> Best Regards, >>> Chanwoo Choi >>> >>> On 19. 6. 18. 오후 1:14, Hsin-Yi Wang wrote: >>> > From: Saravana Kannan >>> > >>> > From: Saravana Kannan >>> > >>> > Many CPU architectures have caches that can scale independent of the CPUs. >>> > Frequency scaling of the caches is necessary to make sure the cache is not >>> > a performance bottleneck that leads to poor performance and power. The >>> > same >>> > idea applies for RAM/DDR. >>> > >>> > To achieve this, this patch adds a generic devfreq governor that takes the >>> > current frequency of each CPU frequency domain and then adjusts the >>> > frequency of the cache (or any devfreq device) based on the frequency of >>> > the CPUs. It listens to CPU frequency transition notifiers to keep itself >>> > up to date on the current CPU frequency. >>> > >>> > To decide the frequency of the device, the governor does one of the >>> > following: >>> > >>> > * Uses a CPU frequency to device frequency mapping table >>> > - Either one mapping table used for all CPU freq policies (typically >>> >used >>> > for system with homogeneous cores/clusters that have the same OPPs). >>> > - One mapping table per CPU freq policy (typically used for ASMP systems >>> > with heterogeneous CPUs with different OPPs) >>> > >>> > OR >>> > >>> > * Scales the device frequency in proportion to the CPU frequency. So, if >>> > the CPUs are running at their max frequency, the device runs at its max >>> > frequency. If the CPUs are running at their min frequency, the device >>> > runs at its min frequency. And interpolated for frequencies in between. >>> > >>> > Signed-off-by: Saravana Kannan >>> > Signed-off-by: Hsin-Yi Wang >>> > --- >>> >
Re: [PATCH v2 0/5] Allocate memmap from hotadded memory
On 26.06.19 10:03, Oscar Salvador wrote:
> On Tue, Jun 25, 2019 at 10:25:48AM +0200, David Hildenbrand wrote:
>>> [Coverletter]
>>>
>>> This is another step to make memory hotplug more usable. The primary
>>> goal of this patchset is to reduce memory overhead of the hot-added
>>> memory (at least for SPARSEMEM_VMEMMAP memory model). The current way we use
>>> to populate memmap (struct page array) has two main drawbacks:
>
> First off, thanks for looking into this :-)
Thanks for working on this ;)
>
>>
>> Mental note: How will it be handled if a caller specifies "Allocate
>> memmap from hotadded memory", but we are running under SPARSEMEM where
>> we can't do this.
>
> In add_memory_resource(), we have a call to mhp_check_correct_flags(), which
> is
> in charge of checking if the flags passed are compliant with our configuration
> among other things.
> It also checks if both flags were passed (_MEMBLOCK|_DEVICE).
>
> If a) any of the flags were specified and we are not on
> CONFIG_SPARSEMEM_VMEMMAP,
> b) the flags are colliding with each other or c) the flags just do not make
> sense,
> we print out a warning and drop the flags to 0, so we just ignore them.
>
> I just realized that I can adjust the check even more (something for the next
> version).
>
> But to answer your question, flags are ignored under
> !CONFIG_SPARSEMEM_VMEMMAP.
So it is indeed a hint only.
>
>>
>>>
>>> a) it consumes an additional memory until the hotadded memory itself is
>>>onlined and
>>> b) memmap might end up on a different numa node which is especially true
>>>for movable_node configuration.
>>>
>>> a) it is a problem especially for memory hotplug based memory "ballooning"
>>>solutions when the delay between physical memory hotplug and the
>>>onlining can lead to OOM and that led to introduction of hacks like auto
>>>onlining (see 31bc3858ea3e ("memory-hotplug: add automatic onlining
>>>policy for the newly added memory")).
>>>
>>> b) can have performance drawbacks.
>>>
>>> Another minor case is that I have seen hot-add operations failing on archs
>>> because they were running out of order-x pages.
>>> E.g On powerpc, in certain configurations, we use order-8 pages,
>>> and given 64KB base pagesize, that is 16MB.
>>> If we run out of those, we just fail the operation and we cannot add
>>> more memory.
>>
>> At least for SPARSEMEM, we fallback to vmalloc() to work around this
>> issue. I haven't looked into the populate_section_memmap() internals
>> yet. Can you point me at the code that performs this allocation?
>
> Yes, on SPARSEMEM we first try to allocate the pages physical configuous, and
> then fallback to vmalloc.
> This is because on CONFIG_SPARSEMEM memory model, the translations
> pfn_to_page/
> page_to_pfn do not expect the memory to be contiguous.
>
> But that is not the case on CONFIG_SPARSEMEM_VMEMMAP.
> We do expect the memory to be physical contigous there, that is why a simply
> pfn_to_page/page_to_pfn is a matter of adding/substracting vmemmap/pfn.
Yeas, I explored that last week but didn't figure out where the actual
vmmap population code resided - thanks :)
>
> Powerpc code is at:
>
> https://elixir.bootlin.com/linux/v5.2-rc6/source/arch/powerpc/mm/init_64.c#L175
>
>
>
>> So, assuming we add_memory(1GB, MHP_MEMMAP_DEVICE) and then
>> remove_memory(128MB) of the added memory, this will work?
>
> No, MHP_MEMMAP_DEVICE is meant to be used when hot-adding and hot-removing
> work
> in the same granularity.
> This is because all memmap pages will be stored at the beginning of the memory
> range.
> Allowing hot-removing in a different granularity on MHP_MEMMAP_DEVICE would
> imply
> a lot of extra work.
> For example, we would have to parse the vmemmap-head of the hot-removed range,
> and punch a hole in there to clear the vmemmap pages, and then be very
> carefull
> when deleting those pagetables.
>
> So I followed Michal's advice, and I decided to let the caller specify if he
> either wants to allocate per memory block or per hot-added range(device).
> Where per memory block, allows us to do:
>
> add_memory(1GB, MHP_MEMMAP_MEMBLOCK)
> remove_memory(128MB)
Back then, I already mentioned that we might have some users that
remove_memory() they never added in a granularity it wasn't added. My
concerns back then were never fully sorted out.
arch/powerpc/platforms/powernv/memtrace.c
- Will remove memory in memory block size chunks it never added
- What if that memory resides on a DIMM added via MHP_MEMMAP_DEVICE?
Will it at least bail out? Or simply break?
IOW: I am not yet 100% convinced that MHP_MEMMAP_DEVICE is save to be
introduced.
--
Thanks,
David / dhildenb
Re: [PATCH v2 4/5] mm,memory_hotplug: allocate memmap from the added memory range for sparse-vmemmap
On Tue, Jun 25, 2019 at 10:49:10AM +0200, David Hildenbrand wrote:
> On 25.06.19 09:52, Oscar Salvador wrote:
> > Physical memory hotadd has to allocate a memmap (struct page array) for
> > the newly added memory section. Currently, alloc_pages_node() is used
> > for those allocations.
> >
> > This has some disadvantages:
> > a) an existing memory is consumed for that purpose
> > (~2MB per 128MB memory section on x86_64)
> > b) if the whole node is movable then we have off-node struct pages
> > which has performance drawbacks.
> >
> > a) has turned out to be a problem for memory hotplug based ballooning
> >because the userspace might not react in time to online memory while
> >the memory consumed during physical hotadd consumes enough memory to
> >push system to OOM. 31bc3858ea3e ("memory-hotplug: add automatic onlining
> >policy for the newly added memory") has been added to workaround that
> >problem.
> >
> > I have also seen hot-add operations failing on powerpc due to the fact
> > that we try to use order-8 pages. If the base page size is 64KB, this
> > gives us 16MB, and if we run out of those, we simply fail.
> > One could arge that we can fall back to basepages as we do in x86_64, but
> > we can do better when CONFIG_SPARSEMEM_VMEMMAP is enabled.
> >
> > Vmemap page tables can map arbitrary memory.
> > That means that we can simply use the beginning of each memory section and
> > map struct pages there.
> > struct pages which back the allocated space then just need to be treated
> > carefully.
> >
> > Implementation wise we reuse vmem_altmap infrastructure to override
> > the default allocator used by __vmemap_populate. Once the memmap is
> > allocated we need a way to mark altmap pfns used for the allocation.
> > If MHP_MEMMAP_{DEVICE,MEMBLOCK} flag was passed, we set up the layout of the
> > altmap structure at the beginning of __add_pages(), and then we call
> > mark_vmemmap_pages().
> >
> > Depending on which flag is passed (MHP_MEMMAP_DEVICE or
> > MHP_MEMMAP_MEMBLOCK),
> > mark_vmemmap_pages() gets called at a different stage.
> > With MHP_MEMMAP_MEMBLOCK, we call it once we have populated the sections
> > fitting in a single memblock, while with MHP_MEMMAP_DEVICE we wait until all
> > sections have been populated.
>
> So, only MHP_MEMMAP_DEVICE will be used. Would it make sense to only
> implement one for now (after we decide which one to use), to make things
> simpler?
>
> Or do you have a real user in mind for the other?
Currently, only MHP_MEMMAP_DEVICE will be used, as we only pass flags from
acpi memory-hotplug path.
All the others: hyper-v, Xen,... will have to be evaluated to see which one
do they want to use.
Although MHP_MEMMAP_DEVICE is the only one used right now, I introduced
MHP_MEMMAP_MEMBLOCK to give the callers the choice of using MHP_MEMMAP_MEMBLOCK
if they think that a strategy where hot-removing works in a different
granularity
makes sense.
Moreover, since they both use the same API, there is no extra code needed to
handle it. (Just two lines in __add_pages())
This arose here [1].
[1] https://patchwork.kernel.org/project/linux-mm/list/?submitter=137061
--
Oscar Salvador
SUSE L3
Re: [PATCH v2 0/5] Allocate memmap from hotadded memory
On Wed, Jun 26, 2019 at 10:11:06AM +0200, David Hildenbrand wrote: > Back then, I already mentioned that we might have some users that > remove_memory() they never added in a granularity it wasn't added. My > concerns back then were never fully sorted out. > > arch/powerpc/platforms/powernv/memtrace.c > > - Will remove memory in memory block size chunks it never added > - What if that memory resides on a DIMM added via MHP_MEMMAP_DEVICE? > > Will it at least bail out? Or simply break? > > IOW: I am not yet 100% convinced that MHP_MEMMAP_DEVICE is save to be > introduced. Uhm, I will take a closer look and see if I can clear your concerns. TBH, I did not try to use arch/powerpc/platforms/powernv/memtrace.c yet. I will get back to you once I tried it out. -- Oscar Salvador SUSE L3
Re: [PATCH v2 4/5] mm,memory_hotplug: allocate memmap from the added memory range for sparse-vmemmap
On 26.06.19 10:13, Oscar Salvador wrote:
> On Tue, Jun 25, 2019 at 10:49:10AM +0200, David Hildenbrand wrote:
>> On 25.06.19 09:52, Oscar Salvador wrote:
>>> Physical memory hotadd has to allocate a memmap (struct page array) for
>>> the newly added memory section. Currently, alloc_pages_node() is used
>>> for those allocations.
>>>
>>> This has some disadvantages:
>>> a) an existing memory is consumed for that purpose
>>> (~2MB per 128MB memory section on x86_64)
>>> b) if the whole node is movable then we have off-node struct pages
>>> which has performance drawbacks.
>>>
>>> a) has turned out to be a problem for memory hotplug based ballooning
>>>because the userspace might not react in time to online memory while
>>>the memory consumed during physical hotadd consumes enough memory to
>>>push system to OOM. 31bc3858ea3e ("memory-hotplug: add automatic onlining
>>>policy for the newly added memory") has been added to workaround that
>>>problem.
>>>
>>> I have also seen hot-add operations failing on powerpc due to the fact
>>> that we try to use order-8 pages. If the base page size is 64KB, this
>>> gives us 16MB, and if we run out of those, we simply fail.
>>> One could arge that we can fall back to basepages as we do in x86_64, but
>>> we can do better when CONFIG_SPARSEMEM_VMEMMAP is enabled.
>>>
>>> Vmemap page tables can map arbitrary memory.
>>> That means that we can simply use the beginning of each memory section and
>>> map struct pages there.
>>> struct pages which back the allocated space then just need to be treated
>>> carefully.
>>>
>>> Implementation wise we reuse vmem_altmap infrastructure to override
>>> the default allocator used by __vmemap_populate. Once the memmap is
>>> allocated we need a way to mark altmap pfns used for the allocation.
>>> If MHP_MEMMAP_{DEVICE,MEMBLOCK} flag was passed, we set up the layout of the
>>> altmap structure at the beginning of __add_pages(), and then we call
>>> mark_vmemmap_pages().
>>>
>>> Depending on which flag is passed (MHP_MEMMAP_DEVICE or
>>> MHP_MEMMAP_MEMBLOCK),
>>> mark_vmemmap_pages() gets called at a different stage.
>>> With MHP_MEMMAP_MEMBLOCK, we call it once we have populated the sections
>>> fitting in a single memblock, while with MHP_MEMMAP_DEVICE we wait until all
>>> sections have been populated.
>>
>> So, only MHP_MEMMAP_DEVICE will be used. Would it make sense to only
>> implement one for now (after we decide which one to use), to make things
>> simpler?
>>
>> Or do you have a real user in mind for the other?
>
> Currently, only MHP_MEMMAP_DEVICE will be used, as we only pass flags from
> acpi memory-hotplug path.
>
> All the others: hyper-v, Xen,... will have to be evaluated to see which one
> do they want to use.
>
> Although MHP_MEMMAP_DEVICE is the only one used right now, I introduced
> MHP_MEMMAP_MEMBLOCK to give the callers the choice of using
> MHP_MEMMAP_MEMBLOCK
> if they think that a strategy where hot-removing works in a different
> granularity
> makes sense.
>
> Moreover, since they both use the same API, there is no extra code needed to
> handle it. (Just two lines in __add_pages())
>
> This arose here [1].
>
> [1] https://patchwork.kernel.org/project/linux-mm/list/?submitter=137061
>
Just noting that you can emulate MHP_MEMMAP_MEMBLOCK via
MHP_MEMMAP_DEVICE by adding memory in memory block granularity (which is
what hyper-v and xen do if I am not wrong!).
Not yet convinced that both, MHP_MEMMAP_MEMBLOCK and MHP_MEMMAP_DEVICE
are needed. But we can sort that out later.
--
Thanks,
David / dhildenb
