Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1380533
| From | Ingo Molnar <mingo@kernel.org> |
|---|---|
| Newsgroups | linux.kernel |
| Subject | Re: Overlapping ioremap() calls, set_memory_*() semantics |
| Date | 2016-04-16 11:30 +0200 |
| Message-ID | <rouIa-1dw-15@gated-at.bofh.it> (permalink) |
| References | (5 earlier) <rbCNb-3SY-5@gated-at.bofh.it> <rd8L0-1Vv-3@gated-at.bofh.it> <rdO7w-4AL-5@gated-at.bofh.it> <rnAmC-7DR-3@gated-at.bofh.it> <rodnY-4BO-23@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
* Toshi Kani <toshi.kani@hpe.com> wrote: > On x86, ioremap() and remap_pfn_range() already fail on a conflicting cache > type if it is not allowed by the rule defined in is_new_memtype_allowed(). > This exception handling is necessary for remap_pfn_range() called by > /dev/mem, but I do not think it's necessary for ioremap(). I think we can > start from adding a warning message to ioremap(). Agreed, we should warn and map the situation before doing any behavioral change that isn't a fix. Thanks, Ingo
Back to linux.kernel | Previous | Next | Find similar | Unroll thread
Re: Overlapping ioremap() calls, set_memory_*() semantics Ingo Molnar <mingo@kernel.org> - 2016-04-16 11:30 +0200
csiph-web