Re: Lockdep annotation introduced warn in VMD driver
Imre Deak wrote:
[..]
> > > Also Imre tried with 2 PCI patches together
> > > https://patchwork.freedesktop.org/series/134193/
> > > And still not good for those 4 systems (mtlp-9, bat-dg2-13/14 and
> > > bat-adlp-11) :
> > > https://intel-gfx-ci.01.org/tree/drm-tip/Trybot_134193v1/index.html?
> > > Dave, Dan, thoughts?
> >
> > Can you provide the dmesg from the failure system with the 2 patches
> > applied please?
>
> For the above 4 machines, mtlp-9 not having the originally reported WARN
> (at pci.c:4886) only some other lockdep issue, while the other 3
> machines having both the originally reported one and the other lockdep
> issue:
> https://intel-gfx-ci.01.org/tree/drm-tip/Trybot_134193v1/bat-mtlp-9/boot0.txt
This one does not seem to implicate cfg_access_lock at all. I wonder if
you revert the lockdep annotation completely if it still fails. I.e.
this is a new lockdep report for v6.10-rc independent of this new
cfg_access_lock annotation.
> https://intel-gfx-ci.01.org/tree/drm-tip/Trybot_134193v1/bat-dg2-13/boot0.txt
> https://intel-gfx-ci.01.org/tree/drm-tip/Trybot_134193v1/bat-dg2-14/boot0.txt
> https://intel-gfx-ci.01.org/tree/drm-tip/Trybot_134193v1/bat-adlp-11/boot0.txt
These are all identical and are pointing out that vmd, via
pci_reset_bus(), has long been performing an unlocked secondary bus
reset that userspace could race and confuse the kernel.
I think the fix for that is below, but this is an increasingly spicy
level of change that gives me some pause, i.e. teach pci_bus_lock() to
lock the bridge itself:
-- 8< --
diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index 59e0949fb079..ac3999bc59e8 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -5442,6 +5442,7 @@ static void pci_bus_lock(struct pci_bus *bus)
{
struct pci_dev *dev;
+ pci_dev_lock(bus->self);
list_for_each_entry(dev, &bus->devices, bus_list) {
pci_dev_lock(dev);
if (dev->subordinate)
@@ -5459,6 +5460,7 @@ static void pci_bus_unlock(struct pci_bus *bus)
pci_bus_unlock(dev->subordinate);
pci_dev_unlock(dev);
}
+ pci_dev_unlock(bus->self);
}
/* Return 1 on successful lock, 0 on contention */
@@ -5466,6 +5468,7 @@ static int pci_bus_trylock(struct pci_bus *bus)
{
struct pci_dev *dev;
+ pci_dev_lock(bus->self);
list_for_each_entry(dev, &bus->devices, bus_list) {
if (!pci_dev_trylock(dev))
goto unlock;
@@ -5484,6 +5487,7 @@ static int pci_bus_trylock(struct pci_bus *bus)
pci_bus_unlock(dev->subordinate);
pci_dev_unlock(dev);
}
+ pci_dev_unlock(bus->self);
return 0;
}
Re: [Intel-gfx] [PATCH][next] treewide: uapi: Replace zero-length arrays with flexible-array members
Gustavo A. R. Silva wrote:
> There is a regular need in the kernel to provide a way to declare
> having a dynamically sized set of trailing elements in a structure.
> Kernel code should always use “flexible array members”[1] for these
> cases. The older style of one-element or zero-length arrays should
> no longer be used[2].
>
> This code was transformed with the help of Coccinelle:
> (linux-5.19-rc2$ spatch --jobs $(getconf _NPROCESSORS_ONLN) --sp-file
> script.cocci --include-headers --dir . > output.patch)
>
> @@
> identifier S, member, array;
> type T1, T2;
> @@
>
> struct S {
> ...
> T1 member;
> T2 array[
> - 0
> ];
> };
>
> -fstrict-flex-arrays=3 is coming and we need to land these changes
> to prevent issues like these in the short future:
>
> ../fs/minix/dir.c:337:3: warning: 'strcpy' will always overflow; destination
> buffer has size 0,
> but the source string has length 2 (including NUL byte) [-Wfortify-source]
> strcpy(de3->name, ".");
> ^
>
> Since these are all [0] to [] changes, the risk to UAPI is nearly zero. If
> this breaks anything, we can use a union with a new member name.
>
> [1] https://en.wikipedia.org/wiki/Flexible_array_member
> [2]
> https://www.kernel.org/doc/html/v5.16/process/deprecated.html#zero-length-and-one-element-arrays
>
> Link: https://github.com/KSPP/linux/issues/78
> Build-tested-by:
> https://lore.kernel.org/lkml/62b675ec.wkx6aoz6cbe71vtf%25...@intel.com/
> Signed-off-by: Gustavo A. R. Silva
> ---
> Hi all!
>
> JFYI: I'm adding this to my -next tree. :)
>
[..]
> include/uapi/linux/ndctl.h| 10 +--
For ndctl.h
Acked-by: Dan Williams
Re: [Intel-gfx] [PATCH RFC PKS/PMEM 33/58] fs/cramfs: Utilize new kmap_thread()
On Tue, Oct 13, 2020 at 12:37 PM Matthew Wilcox wrote:
>
> On Tue, Oct 13, 2020 at 11:44:29AM -0700, Dan Williams wrote:
> > On Fri, Oct 9, 2020 at 12:52 PM wrote:
> > >
> > > From: Ira Weiny
> > >
> > > The kmap() calls in this FS are localized to a single thread. To avoid
> > > the over head of global PKRS updates use the new kmap_thread() call.
> > >
> > > Cc: Nicolas Pitre
> > > Signed-off-by: Ira Weiny
> > > ---
> > > fs/cramfs/inode.c | 10 +-
> > > 1 file changed, 5 insertions(+), 5 deletions(-)
> > >
> > > diff --git a/fs/cramfs/inode.c b/fs/cramfs/inode.c
> > > index 912308600d39..003c014a42ed 100644
> > > --- a/fs/cramfs/inode.c
> > > +++ b/fs/cramfs/inode.c
> > > @@ -247,8 +247,8 @@ static void *cramfs_blkdev_read(struct super_block
> > > *sb, unsigned int offset,
> > > struct page *page = pages[i];
> > >
> > > if (page) {
> > > - memcpy(data, kmap(page), PAGE_SIZE);
> > > - kunmap(page);
> > > + memcpy(data, kmap_thread(page), PAGE_SIZE);
> > > + kunmap_thread(page);
> >
> > Why does this need a sleepable kmap? This looks like a textbook
> > kmap_atomic() use case.
>
> There's a lot of code of this form. Could we perhaps have:
>
> static inline void copy_to_highpage(struct page *to, void *vfrom, unsigned
> int size)
> {
> char *vto = kmap_atomic(to);
>
> memcpy(vto, vfrom, size);
> kunmap_atomic(vto);
> }
>
> in linux/highmem.h ?
Nice, yes, that could also replace the local ones in lib/iov_iter.c
(memcpy_{to,from}_page())
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH RFC PKS/PMEM 33/58] fs/cramfs: Utilize new kmap_thread()
On Fri, Oct 9, 2020 at 12:52 PM wrote:
>
> From: Ira Weiny
>
> The kmap() calls in this FS are localized to a single thread. To avoid
> the over head of global PKRS updates use the new kmap_thread() call.
>
> Cc: Nicolas Pitre
> Signed-off-by: Ira Weiny
> ---
> fs/cramfs/inode.c | 10 +-
> 1 file changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/fs/cramfs/inode.c b/fs/cramfs/inode.c
> index 912308600d39..003c014a42ed 100644
> --- a/fs/cramfs/inode.c
> +++ b/fs/cramfs/inode.c
> @@ -247,8 +247,8 @@ static void *cramfs_blkdev_read(struct super_block *sb,
> unsigned int offset,
> struct page *page = pages[i];
>
> if (page) {
> - memcpy(data, kmap(page), PAGE_SIZE);
> - kunmap(page);
> + memcpy(data, kmap_thread(page), PAGE_SIZE);
> + kunmap_thread(page);
Why does this need a sleepable kmap? This looks like a textbook
kmap_atomic() use case.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3 1/5] acpi, nfit: Switch to use new generic UUID API
On Mon, Jun 5, 2017 at 9:40 AM, Andy Shevchenko wrote: > There are new types and helpers that are supposed to be used in new code. > > As a preparation to get rid of legacy types and API functions do > the conversion here. > > Reviewed-by: Dan Williams > Signed-off-by: Andy Shevchenko > --- > drivers/acpi/nfit/core.c | 54 > > drivers/acpi/nfit/nfit.h | 3 +-- > include/linux/acpi.h | 1 + > 3 files changed, 29 insertions(+), 29 deletions(-) Is there a git branch with these available, so I can run it through the nvdimm regression suite? ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 1/5] acpi, nfit: Switch to use new generic UUID API
On Wed, May 31, 2017 at 12:41 PM, Andy Shevchenko wrote: > There are new types and helpers that are supposed to be used in new code. > > As a preparation to get rid of legacy types and API functions do > the conversion here. > > Cc: Dan Williams > Signed-off-by: Andy Shevchenko > --- > drivers/acpi/nfit/core.c | 54 > > drivers/acpi/nfit/nfit.h | 3 +-- > include/linux/acpi.h | 1 + > 3 files changed, 29 insertions(+), 29 deletions(-) > Looks good to me. Reviewed-by: Dan Williams ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 5/5] ACPI: Switch to use generic guid_t in acpi_evaluate_dsm()
On Wed, May 31, 2017 at 12:41 PM, Andy Shevchenko wrote: > acpi_evaluate_dsm() and friends take a pointer to a raw buffer of 16 > bytes. Instead we convert them to use guid_t type. At the same time we > convert current users. > > acpi_str_to_uuid() becomes useless after the conversion and it's safe to > get rid of it. > > Cc: Borislav Petkov > Cc: Dan Williams > Cc: Amir Goldstein > Cc: Jarkko Sakkinen > Reviewed-by: Jani Nikula > Acked-by: Jani Nikula > Cc: Ben Skeggs > Acked-by: Benjamin Tissoires > Acked-by: Joerg Roedel > Cc: Adrian Hunter > Cc: Yisen Zhuang > Acked-by: Bjorn Helgaas > Acked-by: Felipe Balbi > Acked-by: Mathias Nyman > Reviewed-by: Heikki Krogerus > Cc: Liam Girdwood > Cc: Mark Brown > Signed-off-by: Andy Shevchenko > --- > drivers/acpi/acpi_extlog.c | 4 ++-- > drivers/acpi/bus.c | 23 > ------ > drivers/acpi/nfit/core.c | 6 +++--- Acked-by: Dan Williams ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v1] ACPI: Switch to use generic UUID API
On Thu, May 4, 2017 at 2:21 AM, Andy Shevchenko
wrote:
> acpi_evaluate_dsm() and friends take a pointer to a raw buffer of 16
> bytes. Instead we convert them to use uuid_le type. At the same time we
> convert current users.
>
> acpi_str_to_uuid() becomes useless after the conversion and it's safe to
> get rid of it.
>
> The conversion fixes a potential bug in int340x_thermal as well since
> we have to use memcmp() on binary data.
>
> Cc: Rafael J. Wysocki
> Cc: Mika Westerberg
> Cc: Borislav Petkov
> Cc: Dan Williams
> Cc: Amir Goldstein
> Cc: Jarkko Sakkinen
> Cc: Jani Nikula
> Cc: Ben Skeggs
> Cc: Benjamin Tissoires
> Cc: Joerg Roedel
> Cc: Adrian Hunter
> Cc: Yisen Zhuang
> Cc: Bjorn Helgaas
> Cc: Zhang Rui
> Cc: Felipe Balbi
> Cc: Mathias Nyman
> Cc: Heikki Krogerus
> Cc: Liam Girdwood
> Cc: Mark Brown
> Signed-off-by: Andy Shevchenko
[..]
> diff --git a/drivers/acpi/nfit/core.c b/drivers/acpi/nfit/core.c
> index 0f7982a1caaf..bd3e45ede056 100644
> --- a/drivers/acpi/nfit/core.c
> +++ b/drivers/acpi/nfit/core.c
> @@ -74,11 +74,11 @@ struct nfit_table_prev {
> struct list_head flushes;
> };
>
> -static u8 nfit_uuid[NFIT_UUID_MAX][16];
> +static uuid_le nfit_uuid[NFIT_UUID_MAX];
>
> -const u8 *to_nfit_uuid(enum nfit_uuids id)
> +const uuid_le *to_nfit_uuid(enum nfit_uuids id)
> {
> - return nfit_uuid[id];
> + return &nfit_uuid[id];
> }
> EXPORT_SYMBOL(to_nfit_uuid);
>
> @@ -207,7 +207,7 @@ int acpi_nfit_ctl(struct nvdimm_bus_descriptor *nd_desc,
> struct nvdimm *nvdimm,
> u32 offset, fw_status = 0;
> acpi_handle handle;
> unsigned int func;
> - const u8 *uuid;
> + const uuid_le *uuid;
> int rc, i;
>
> func = cmd;
> @@ -394,7 +394,7 @@ int nfit_spa_type(struct acpi_nfit_system_address *spa)
> int i;
>
> for (i = 0; i < NFIT_UUID_MAX; i++)
> - if (memcmp(to_nfit_uuid(i), spa->range_guid, 16) == 0)
> + if (!uuid_le_cmp_pp(to_nfit_uuid(i), (uuid_le
> *)spa->range_guid))
What is _cmp_pp? Why not _compare?
Other than that, looks ok to me.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 09/20] i915: switch from acpi_os_ioremap to memremap
On Tue, Oct 13, 2015 at 1:24 AM, Daniel Vetter wrote: > On Mon, Oct 12, 2015 at 09:12:57PM +, Williams, Dan J wrote: >> On Mon, 2015-10-12 at 09:01 +0200, Daniel Vetter wrote: >> > On Fri, Oct 09, 2015 at 06:16:25PM -0400, Dan Williams wrote: >> > > i915 expects the OpRegion to be cached (i.e. not __iomem), so explicitly >> > > map it with memremap rather than the implied cache setting of >> > > acpi_os_ioremap(). >> > > >> > > Cc: Daniel Vetter >> > > Cc: Jani Nikula >> > > Cc: intel-gfx@lists.freedesktop.org >> > > Cc: David Airlie >> > > Cc: dri-de...@lists.freedesktop.org >> > > Signed-off-by: Dan Williams >> > >> > Assuming you've run sparse over this to make sure you've caught them all, >> > and with the nit below addressed this is >> > >> > Reviewed-by: Daniel Vetter >> >> Indeed, re-running sparse again found a few conversions of ioread* I >> missed as well as moving the force casting out of validate_vbt() to >> find_vbt(). >> >> > Feel free to pull v2 into whatever tree you think it's suitable for (but >> > you can also resend and I'll pick it up). >> >> Please pick up v2 below. > > Queued for -next, thanks for the patch. Aside: Attached or separate mail > seems easier, somehow git apply-mbox can't auto-eat this for of patch. > -Daniel > "git am --scissors" should detect the "8<---" cut line. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 09/20] i915: switch from acpi_os_ioremap to memremap
i915 expects the OpRegion to be cached (i.e. not __iomem), so explicitly
map it with memremap rather than the implied cache setting of
acpi_os_ioremap().
Cc: Daniel Vetter
Cc: Jani Nikula
Cc: intel-gfx@lists.freedesktop.org
Cc: David Airlie
Cc: dri-de...@lists.freedesktop.org
Signed-off-by: Dan Williams
---
drivers/gpu/drm/i915/i915_debugfs.c |2 -
drivers/gpu/drm/i915/i915_drv.h | 12 +++--
drivers/gpu/drm/i915/intel_bios.c |7 +--
drivers/gpu/drm/i915/intel_opregion.c | 73 -
drivers/gpu/drm/i915/intel_panel.c|2 -
5 files changed, 47 insertions(+), 49 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index e3ec9049081f..15989cc16e92 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -1849,7 +1849,7 @@ static int i915_opregion(struct seq_file *m, void *unused)
goto out;
if (opregion->header) {
- memcpy_fromio(data, opregion->header, OPREGION_SIZE);
+ memcpy(data, opregion->header, OPREGION_SIZE);
seq_write(m, data, OPREGION_SIZE);
}
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index e1db8de52851..d8684634a31d 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -444,14 +444,14 @@ struct opregion_swsci;
struct opregion_asle;
struct intel_opregion {
- struct opregion_header __iomem *header;
- struct opregion_acpi __iomem *acpi;
- struct opregion_swsci __iomem *swsci;
+ struct opregion_header *header;
+ struct opregion_acpi *acpi;
+ struct opregion_swsci *swsci;
u32 swsci_gbda_sub_functions;
u32 swsci_sbcb_sub_functions;
- struct opregion_asle __iomem *asle;
- void __iomem *vbt;
- u32 __iomem *lid_state;
+ struct opregion_asle *asle;
+ void *vbt;
+ u32 *lid_state;
struct work_struct asle_work;
};
#define OPREGION_SIZE(8*1024)
diff --git a/drivers/gpu/drm/i915/intel_bios.c
b/drivers/gpu/drm/i915/intel_bios.c
index c19e669ffe50..1ee2f11d355d 100644
--- a/drivers/gpu/drm/i915/intel_bios.c
+++ b/drivers/gpu/drm/i915/intel_bios.c
@@ -1238,11 +1238,10 @@ static const struct bdb_header *validate_vbt(const void
__iomem *_base,
{
/*
* This is the one place where we explicitly discard the address space
-* (__iomem) of the BIOS/VBT. (And this will cause a sparse complaint.)
-* From now on everything is based on 'base', and treated as regular
-* memory.
+* (__iomem) of the BIOS/VBT. From now on everything is based on
+* 'base', and treated as regular memory.
*/
- const void *base = (const void *) _base;
+ const void *base = (const void __force *) _base;
size_t offset = _vbt - _base;
const struct vbt_header *vbt = base + offset;
const struct bdb_header *bdb;
diff --git a/drivers/gpu/drm/i915/intel_opregion.c
b/drivers/gpu/drm/i915/intel_opregion.c
index cb1c65739425..4f65cdb38e1b 100644
--- a/drivers/gpu/drm/i915/intel_opregion.c
+++ b/drivers/gpu/drm/i915/intel_opregion.c
@@ -239,7 +239,7 @@ struct opregion_asle {
static int swsci(struct drm_device *dev, u32 function, u32 parm, u32 *parm_out)
{
struct drm_i915_private *dev_priv = dev->dev_private;
- struct opregion_swsci __iomem *swsci = dev_priv->opregion.swsci;
+ struct opregion_swsci *swsci = dev_priv->opregion.swsci;
u32 main_function, sub_function, scic;
u16 pci_swsci;
u32 dslp;
@@ -264,7 +264,7 @@ static int swsci(struct drm_device *dev, u32 function, u32
parm, u32 *parm_out)
}
/* Driver sleep timeout in ms. */
- dslp = ioread32(&swsci->dslp);
+ dslp = swsci->dslp;
if (!dslp) {
/* The spec says 2ms should be the default, but it's too small
* for some machines. */
@@ -277,7 +277,7 @@ static int swsci(struct drm_device *dev, u32 function, u32
parm, u32 *parm_out)
}
/* The spec tells us to do this, but we are the only user... */
- scic = ioread32(&swsci->scic);
+ scic = swsci->scic;
if (scic & SWSCI_SCIC_INDICATOR) {
DRM_DEBUG_DRIVER("SWSCI request already in progress\n");
return -EBUSY;
@@ -285,8 +285,8 @@ static int swsci(struct drm_device *dev, u32 function, u32
parm, u32 *parm_out)
scic = function | SWSCI_SCIC_INDICATOR;
- iowrite32(parm, &swsci->parm);
- iowrite32(scic, &swsci->scic);
+ swsci->parm = parm;
+ swsci->scic = scic;
/* Ensure SCI event is selected and event trigger is cleared. */
pci_read_config_word(dev->pdev, PCI_SWSCI, &pci_swsci);
@@ -301,7 +301,7 @@ static int swsci(struct drm
[Intel-gfx] [PATCH 00/20] tree-wide convert to memremap()
The memremap() api [1] was merged in 4.3 [2] with an initial implementation for x86 and a conversion of the pmem driver. Complete the conversion for the rest of the kernel. Feel free to either ack or directly apply a conversion-patch as I will defer the final removal patches until all the conversions have landed. [1]: https://lwn.net/Articles/653585/ [2]: commit 92281dee825f arch: introduce memremap() --- Dan Williams (20): x86: introduce arch_memremap() arm: introduce arch_memremap() ia64: introduce arch_memremap() sh: introduce arch_memremap() m68k: introduce arch_memremap() arm: switch from ioremap_cache to memremap x86: switch from ioremap_cache to memremap gma500: switch from acpi_os_ioremap to memremap i915: switch from acpi_os_ioremap to memremap acpi: switch from ioremap_cache to memremap sound, skylake: switch from ioremap_cache to memremap memconsole: fix __iomem mishandling, switch to memremap intel-iommu: switch from ioremap_cache to memremap pxa2xx-flash: switch from ioremap_cache to memremap sfi: switch from ioremap_cache to memremap fbdev: switch from ioremap_wt to memremap arch: kill ioremap_cached() arch: kill ioremap_fullcache() arch: remove ioremap_cache, replace with arch_memremap arch: remove ioremap_wt, optionally replace with arch_memremap Documentation/x86/pat.txt |6 +-- arch/arc/include/asm/io.h |1 arch/arm/Kconfig |1 arch/arm/include/asm/io.h |7 --- arch/arm/include/asm/xen/page.h |4 +- arch/arm/mm/ioremap.c | 12 - arch/arm/mm/mmu.c |2 - arch/arm/mm/nommu.c | 11 +++-- arch/arm64/Kconfig|1 arch/arm64/include/asm/acpi.h | 11 - arch/arm64/include/asm/dmi.h |8 ++-- arch/arm64/include/asm/io.h |2 - arch/arm64/kernel/efi.c |9 ++-- arch/arm64/kernel/smp_spin_table.c| 19 - arch/arm64/mm/ioremap.c | 20 +++-- arch/avr32/include/asm/io.h |1 arch/frv/include/asm/io.h | 12 - arch/ia64/Kconfig |1 arch/ia64/include/asm/io.h|6 --- arch/ia64/mm/ioremap.c| 10 + arch/m32r/include/asm/io.h|1 arch/m68k/Kconfig |1 arch/m68k/include/asm/io_mm.h | 13 -- arch/m68k/include/asm/io_no.h | 11 - arch/m68k/include/asm/raw_io.h|1 arch/m68k/mm/kmap.c | 17 +++- arch/m68k/mm/sun3kmap.c |7 +++ arch/metag/include/asm/io.h |6 --- arch/microblaze/include/asm/io.h |2 - arch/mn10300/include/asm/io.h |1 arch/nios2/include/asm/io.h |1 arch/s390/include/asm/io.h|1 arch/sh/Kconfig |1 arch/sh/include/asm/io.h |7 --- arch/sh/mm/ioremap.c |9 arch/sparc/include/asm/io_32.h|1 arch/sparc/include/asm/io_64.h|1 arch/tile/include/asm/io.h|2 - arch/unicore32/include/asm/io.h |4 -- arch/unicore32/mm/ioremap.c |8 arch/x86/Kconfig |1 arch/x86/include/asm/efi.h|3 + arch/x86/include/asm/io.h |4 -- arch/x86/kernel/crash_dump_64.c |6 +-- arch/x86/kernel/kdebugfs.c|8 ++-- arch/x86/kernel/ksysfs.c | 28 ++--- arch/x86/mm/ioremap.c | 43 --- arch/xtensa/include/asm/io.h | 12 - drivers/acpi/apei/einj.c |9 ++-- drivers/acpi/apei/erst.c |6 +-- drivers/acpi/nvs.c|6 +-- drivers/acpi/osl.c| 70 +--- drivers/firmware/google/memconsole.c |7 ++- drivers/gpu/drm/gma500/opregion.c |8 ++-- drivers/gpu/drm/gma500/psb_drv.h |2 - drivers/gpu/drm/gma500/psb_lid.c |8 ++-- drivers/gpu/drm/i915/i915_debugfs.c |2 - drivers/gpu/drm/i915/i915_drv.h | 12 +++-- drivers/gpu/drm/i915/intel_bios.c |7 +-- drivers/gpu/drm/i915/intel_opregion.c | 73 - drivers/gpu/drm/i915/intel_panel.c|2 - drivers/iommu/intel-iommu.c | 20 + drivers/iommu/intel_irq_remapping.c |8 ++-- drivers/mtd/maps/pxa2xx-flash.c |6 +-- drivers/nvdimm/Kconfig|2 - drivers/sfi/sfi_core.c|4 +- drivers/video/fbdev/Kconfig |2 - drivers/video/fbdev/amifb.c |5 +- drivers/video/fbdev/atafb.c |5 +- drivers/video/fbdev/hpfb.c|6 +-- include/acpi/acpi_io.h
[Intel-gfx] [PATCH v3 09/24] i915: switch from acpi_os_ioremap to memremap
i915 expects the OpRegion to be cached (i.e. not __iomem), so explicitly
map it with memremap rather than the implied cache setting of
acpi_os_ioremap().
Cc: Daniel Vetter
Cc: Jani Nikula
Cc: intel-gfx@lists.freedesktop.org
Cc: David Airlie
Cc: dri-de...@lists.freedesktop.org
Signed-off-by: Dan Williams
---
drivers/gpu/drm/i915/i915_debugfs.c |2 -
drivers/gpu/drm/i915/i915_drv.h | 12 ++---
drivers/gpu/drm/i915/intel_bios.c |7 +--
drivers/gpu/drm/i915/intel_opregion.c | 87 -
drivers/gpu/drm/i915/intel_panel.c|2 -
5 files changed, 52 insertions(+), 58 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 82bbe3f2a7e1..9228d6048bde 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -1831,7 +1831,7 @@ static int i915_opregion(struct seq_file *m, void *unused)
goto out;
if (opregion->header) {
- memcpy_fromio(data, opregion->header, OPREGION_SIZE);
+ memcpy(data, opregion->header, OPREGION_SIZE);
seq_write(m, data, OPREGION_SIZE);
}
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 5f27290201e0..2efbfd53be51 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -403,14 +403,14 @@ struct opregion_swsci;
struct opregion_asle;
struct intel_opregion {
- struct opregion_header __iomem *header;
- struct opregion_acpi __iomem *acpi;
- struct opregion_swsci __iomem *swsci;
+ struct opregion_header *header;
+ struct opregion_acpi *acpi;
+ struct opregion_swsci *swsci;
u32 swsci_gbda_sub_functions;
u32 swsci_sbcb_sub_functions;
- struct opregion_asle __iomem *asle;
- void __iomem *vbt;
- u32 __iomem *lid_state;
+ struct opregion_asle *asle;
+ void *vbt;
+ u32 *lid_state;
struct work_struct asle_work;
};
#define OPREGION_SIZE(8*1024)
diff --git a/drivers/gpu/drm/i915/intel_bios.c
b/drivers/gpu/drm/i915/intel_bios.c
index 198fc3c3291b..3e2dca4f5e6e 100644
--- a/drivers/gpu/drm/i915/intel_bios.c
+++ b/drivers/gpu/drm/i915/intel_bios.c
@@ -1206,11 +1206,10 @@ static const struct bdb_header *validate_vbt(const void
__iomem *_base,
{
/*
* This is the one place where we explicitly discard the address space
-* (__iomem) of the BIOS/VBT. (And this will cause a sparse complaint.)
-* From now on everything is based on 'base', and treated as regular
-* memory.
+* (__iomem) of the BIOS/VBT. From now on everything is based on
+* 'base', and treated as regular memory.
*/
- const void *base = (const void *) _base;
+ const void *base = (const void __force *) _base;
size_t offset = _vbt - _base;
const struct vbt_header *vbt = base + offset;
const struct bdb_header *bdb;
diff --git a/drivers/gpu/drm/i915/intel_opregion.c
b/drivers/gpu/drm/i915/intel_opregion.c
index 481337436f72..7deed1062871 100644
--- a/drivers/gpu/drm/i915/intel_opregion.c
+++ b/drivers/gpu/drm/i915/intel_opregion.c
@@ -232,7 +232,7 @@ struct opregion_asle {
static int swsci(struct drm_device *dev, u32 function, u32 parm, u32 *parm_out)
{
struct drm_i915_private *dev_priv = dev->dev_private;
- struct opregion_swsci __iomem *swsci = dev_priv->opregion.swsci;
+ struct opregion_swsci *swsci = dev_priv->opregion.swsci;
u32 main_function, sub_function, scic;
u16 pci_swsci;
u32 dslp;
@@ -257,7 +257,7 @@ static int swsci(struct drm_device *dev, u32 function, u32
parm, u32 *parm_out)
}
/* Driver sleep timeout in ms. */
- dslp = ioread32(&swsci->dslp);
+ dslp = swsci->dslp;
if (!dslp) {
/* The spec says 2ms should be the default, but it's too small
* for some machines. */
@@ -270,7 +270,7 @@ static int swsci(struct drm_device *dev, u32 function, u32
parm, u32 *parm_out)
}
/* The spec tells us to do this, but we are the only user... */
- scic = ioread32(&swsci->scic);
+ scic = swsci->scic;
if (scic & SWSCI_SCIC_INDICATOR) {
DRM_DEBUG_DRIVER("SWSCI request already in progress\n");
return -EBUSY;
@@ -278,8 +278,8 @@ static int swsci(struct drm_device *dev, u32 function, u32
parm, u32 *parm_out)
scic = function | SWSCI_SCIC_INDICATOR;
- iowrite32(parm, &swsci->parm);
- iowrite32(scic, &swsci->scic);
+ swsci->parm = parm;
+ swsci->scic = scic;
/* Ensure SCI event is selected and event trigger is cleared. */
pci_read_config_word(dev->pdev, PCI_SWSCI, &pci_swsci);
@@ -294,7 +294,7 @@ static int swsci(struct drm
[Intel-gfx] [PATCH v3 00/24] replace ioremap_{cache|wt} with memremap
Changes since v2 [1]:
1/ Move arch_memremap() and arch_memunmap() out of line (Christoph)
2/ Convert region_is_ram() to region_intersects() and define an enum for
its 3 return values. (Luis)
3/ Fix gma500 and i915 to explicitly use cached mappings and clean up
the __iomem usage. (Daniel)
4/ Kill unused ioremap aliases (ioremap_cached() and
ioremap_fullcache()) (Christoph)
5/ Clarify some change logs and documentation (Luis, Christoph, and
Ross)
6/ Add a unified CONFIG_MMU=n implementation with __weak symbols. (Luis)
---
While developing the pmem driver we noticed that the __iomem annotation
on the return value from ioremap_cache() was being mishandled by several
callers. We also observed that all of the call sites expected to be
able to treat the return value from ioremap_cache() as normal
(non-__iomem) pointer to memory.
This patchset takes the opportunity to clean up the above confusion as
well as a few issues with the ioremap_{cache|wt} interface, including:
1/ Eliminating the possibility of function prototypes differing between
architectures by defining a central memremap() prototype that takes
flags to determine the mapping type.
2/ Returning NULL rather than falling back silently to a different
mapping-type. This allows drivers to be stricter about the
mapping-type fallbacks that are permissible.
[1]: http://marc.info/?l=linux-arch&m=14377917405&w=2
---
Dan Williams (24):
mm: enhance region_is_ram() to region_intersects()
arch, drivers: don't include directly, use instead
cleanup IORESOURCE_CACHEABLE vs ioremap()
intel_iommu: fix leaked ioremap mapping
arch: introduce memremap()
arm: switch from ioremap_cache to memremap
x86: switch from ioremap_cache to memremap
gma500: switch from acpi_os_ioremap to memremap
i915: switch from acpi_os_ioremap to memremap
acpi: switch from ioremap_cache to memremap
toshiba laptop: replace ioremap_cache with ioremap
memconsole: fix __iomem mishandling, switch to memremap
visorbus: switch from ioremap_cache to memremap
intel-iommu: switch from ioremap_cache to memremap
libnvdimm, pmem: push call to ioremap_cache out of line
pxa2xx-flash: switch from ioremap_cache to memremap
sfi: switch from ioremap_cache to memremap
fbdev: switch from ioremap_wt to memremap
pmem: switch from ioremap_wt to memremap
arch: kill ioremap_cached()
arch: kill ioremap_fullcache()
arch: remove ioremap_cache, replace with arch_memremap
arch: remove ioremap_wt, optionally replace with arch_memremap
pmem: convert to generic memremap
Documentation/x86/pat.txt |6 +
arch/arc/include/asm/io.h |1
arch/arm/Kconfig |1
arch/arm/include/asm/io.h |7 --
arch/arm/include/asm/xen/page.h|4 -
arch/arm/mach-clps711x/board-cdb89712.c|2
arch/arm/mach-shmobile/pm-rcar.c |2
arch/arm/mm/ioremap.c | 18 +++-
arch/arm/mm/mmu.c |2
arch/arm/mm/nommu.c| 11 ++
arch/arm64/Kconfig |1
arch/arm64/include/asm/acpi.h | 11 --
arch/arm64/include/asm/dmi.h |8 +-
arch/arm64/include/asm/io.h|2
arch/arm64/kernel/efi.c|9 +-
arch/arm64/kernel/smp_spin_table.c | 19 ++--
arch/arm64/mm/ioremap.c| 20 ++--
arch/avr32/include/asm/io.h|1
arch/frv/include/asm/io.h | 12 ---
arch/ia64/Kconfig |1
arch/ia64/include/asm/io.h |5 -
arch/ia64/kernel/cyclone.c |2
arch/ia64/mm/ioremap.c | 16 +++
arch/m32r/include/asm/io.h |1
arch/m68k/Kconfig |1
arch/m68k/include/asm/io_mm.h | 12 ---
arch/m68k/include/asm/io_no.h | 11 --
arch/m68k/include/asm/raw_io.h |1
arch/m68k/mm/kmap.c| 17 +++-
arch/m68k/mm/sun3kmap.c|6 +
arch/metag/include/asm/io.h|6 -
arch/microblaze/include/asm/io.h |2
arch/mn10300/include/asm/io.h |1
arch/nios2/include/asm/io.h|1
arch/powerpc/kernel/pci_of_scan.c |2
arch/s390/include/asm/io.h |1
arch/sh/Kconfig|1
arch/sh/include/asm/io.h |6 -
arch/sh/mm/ioremap.c | 15 +++
arch/sparc/include/asm/io_32.h |1
arch/sparc/includ
[Intel-gfx] [PATCH v2 12/25] i915: switch from acpi_os_ioremap to ioremap
acpi_os_ioremap uses cached mappings, however it appears that i915 wants to read dynamic platform state. Switch to ioremap() to prevent it reading stale state from cache. Cc: Daniel Vetter Cc: Jani Nikula Cc: intel-gfx@lists.freedesktop.org Cc: David Airlie Cc: dri-de...@lists.freedesktop.org Signed-off-by: Dan Williams --- drivers/gpu/drm/i915/intel_opregion.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/intel_opregion.c b/drivers/gpu/drm/i915/intel_opregion.c index 481337436f72..16ba7c67410d 100644 --- a/drivers/gpu/drm/i915/intel_opregion.c +++ b/drivers/gpu/drm/i915/intel_opregion.c @@ -863,7 +863,7 @@ int intel_opregion_setup(struct drm_device *dev) INIT_WORK(&opregion->asle_work, asle_work); #endif - base = acpi_os_ioremap(asls, OPREGION_SIZE); + base = ioremap(asls, OPREGION_SIZE); if (!base) return -ENOMEM; ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 00/25] replace ioremap_{cache|wt} with memremap
Changes since v1 [1]:
1/ Drop the attempt at unifying ioremap() prototypes, just focus on
converting ioremap_cache and ioremap_wt over to memremap (Christoph)
2/ Drop the unrelated cleanups to use %pa in __ioremap_caller (Thomas)
3/ Add support for memremap() attempts on "System RAM" to simply return
the kernel virtual address for that range. ARM depends on this
functionality in ioremap_cache() and ACPI was open coding a similar
solution. (Mark)
4/ Split the conversions of ioremap_{cache|wt} into separate patches per
driver / arch.
5/ Fix bisection breakage and other reports from 0day-kbuild
---
While developing the pmem driver we noticed that the __iomem annotation
on the return value from ioremap_cache() was being mishandled by several
callers. We also observed that all of the call sites expected to be
able to treat the return value from ioremap_cache() as normal
(non-__iomem) pointer to memory.
This patchset takes the opportunity to clean up the above confusion as
well as a few issues with the ioremap_{cache|wt} interface, including:
1/ Eliminating the possibility of function prototypes differing between
architectures by defining a central memremap() prototype that takes
flags to determine the mapping type.
2/ Returning NULL rather than falling back silently to a different
mapping-type. This allows drivers to be stricter about the
mapping-type fallbacks that are permissible.
[1]: http://marc.info/?l=linux-arm-kernel&m=143735199029255&w=2
---
Dan Williams (22):
mm: enhance region_is_ram() to distinguish 'unknown' vs 'mixed'
arch, drivers: don't include directly, use instead
cleanup IORESOURCE_CACHEABLE vs ioremap()
intel_iommu: fix leaked ioremap mapping
arch: introduce memremap()
arm: switch from ioremap_cache to memremap
x86: switch from ioremap_cache to memremap
gma500: switch from acpi_os_ioremap to ioremap
i915: switch from acpi_os_ioremap to ioremap
acpi: switch from ioremap_cache to memremap
toshiba laptop: replace ioremap_cache with ioremap
memconsole: fix __iomem mishandling, switch to memremap
visorbus: switch from ioremap_cache to memremap
intel-iommu: switch from ioremap_cache to memremap
libnvdimm, pmem: switch from ioremap_cache to memremap
pxa2xx-flash: switch from ioremap_cache to memremap
sfi: switch from ioremap_cache to memremap
fbdev: switch from ioremap_wt to memremap
pmem: switch from ioremap_wt to memremap
arch: remove ioremap_cache, replace with arch_memremap
arch: remove ioremap_wt, replace with arch_memremap
pmem: convert to generic memremap
Toshi Kani (3):
mm, x86: Fix warning in ioremap RAM check
mm, x86: Remove region_is_ram() call from ioremap
mm: Fix bugs in region_is_ram()
arch/arc/include/asm/io.h |1
arch/arm/Kconfig |1
arch/arm/include/asm/io.h | 13 +++-
arch/arm/include/asm/xen/page.h|4 +
arch/arm/mach-clps711x/board-cdb89712.c|2 -
arch/arm/mach-shmobile/pm-rcar.c |2 -
arch/arm/mm/ioremap.c | 12 +++-
arch/arm/mm/nommu.c| 11 ++-
arch/arm64/Kconfig |1
arch/arm64/include/asm/acpi.h | 10 +--
arch/arm64/include/asm/dmi.h |8 +--
arch/arm64/include/asm/io.h|8 ++-
arch/arm64/kernel/efi.c|9 ++-
arch/arm64/kernel/smp_spin_table.c | 19 +++---
arch/arm64/mm/ioremap.c| 20 ++
arch/avr32/include/asm/io.h|1
arch/frv/Kconfig |1
arch/frv/include/asm/io.h | 17 ++---
arch/frv/mm/kmap.c |6 ++
arch/ia64/Kconfig |1
arch/ia64/include/asm/io.h | 11 +++
arch/ia64/kernel/cyclone.c |2 -
arch/m32r/include/asm/io.h |1
arch/m68k/Kconfig |1
arch/m68k/include/asm/io_mm.h | 14 +---
arch/m68k/include/asm/io_no.h | 12 ++--
arch/m68k/include/asm/raw_io.h |4 +
arch/m68k/mm/kmap.c| 17 +
arch/m68k/mm/sun3kmap.c|6 ++
arch/metag/include/asm/io.h|3 -
arch/microblaze/include/asm/io.h |1
arch/mn10300/include/asm/io.h |1
arch/nios2/include/asm/io.h|1
arch/powerpc/kernel/pci_of_scan.c |2 -
arch/s390/include/asm/io.h |1
arch/sh/Kconfig|1
arch/sh/in
