| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Merge "ARM Versatile multi-platform support" from Rob Herring:
Arnd lit a fire under me to dust this off and get it merged. So here it
is. The main change from prior version is I merged all the code to a
single file. It's a bigger patch than I'd like, but I don't think trying
to do it in multiple steps is worth it.
This is dependent on some solution for the default platform choice on
!MMU builds (allnoconfig) as it can't be Versatile after this series.
Arnd has some ideas on how to address that.
This is tested under QEMU. Linus previously tested this on actual h/w
and had a problem with the display identification which needs
investigation or agreement to worry about it if and when someone
actually cares.
* versatile/multiplatform:
ARM: versatile: convert to multi-platform
ARM: versatile: merge mach code into a single file
ARM: versatile: switch to DT only booting and remove legacy code
ARM: versatile: add DT based PCI detection
Acked-by: Marc Zyngier <marc.zyngier@arm.com>
|
|
Now that all the prerequisites are in place, we can enable Versatile
boards for multi-platform kernels.
Signed-off-by: Rob Herring <robh@kernel.org>
Cc: Russell King <linux@arm.linux.org.uk>
Cc: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
|
|
With DT-only support now in place and most of the legacy code removed,
the separation of core.c and versatile_dt.c makes little sense. The
headers in mach include directory also have to move for multi-platform
support, but with a single .c file the remaining definitions needed can
also be moved into the versatile_dt.c.
In the move, the system registers and IB2 registers are converted to
run-time mappings and all register accesses converted to use
readl/writel.
Signed-off-by: Rob Herring <robh@kernel.org>
Cc: Russell King <linux@arm.linux.org.uk>
Cc: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
|
|
With DT support for clocks, irqchips, timers, and PCI now in place, DT
based booting has feature parity with non-DT legacy boot. The final
piece is actually enabling common clock support on Versatile. Enabling
full DT support requires either removing the old Versatile clock code,
updating the legacy boot to use the common clock code, or making DT and
legacy boot mutually exclusive. Given that removing legacy boot code is
the goal anyway, I am going with the 1st option.
Signed-off-by: Rob Herring <robh@kernel.org>
Cc: Russell King <linux@arm.linux.org.uk>
Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: Mike Turquette <mturquette@linaro.org>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
|
|
Disable the Versatile PCI DT node when no PCI backplane is detected. This
will prevent the Versatile PCI driver from probing when PCI is not
populated.
Signed-off-by: Rob Herring <robh@kernel.org>
Cc: Russell King <linux@arm.linux.org.uk>
Cc: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
|
|
The ezx platform contains multiple machine descriptors, but not all
of them use all of the data structures, and it's possible to disable
all of the machines, which produces some harmless warnings:
mach-pxa/ezx.c:53:26: warning: 'ezx_pwm_lookup' defined but not used [-Wunused-variable]
mach-pxa/ezx.c:86:31: warning: 'ezx_fb_info_1' defined but not used [-Wunused-variable]
mach-pxa/ezx.c:107:31: warning: 'ezx_fb_info_2' defined but not used [-Wunused-variable]
mach-pxa/ezx.c:113:32: warning: 'ezx_devices' defined but not used [-Wunused-variable]
mach-pxa/ezx.c:117:22: warning: 'ezx_pin_config' defined but not used [-Wunused-variable]
This marks all those structures as __maybe_unused to avoid the warnings.
Obviously a configuration that contains the ezx platform but no specific
model is a bit silly, but it should not cause compile-time warnings.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Robert Jarzmik <robert.jarzmik@free.fr>
|
|
The raumfeld.c file contains three similar machine definitions,
each with their own init function. If one or more of them are
disabled, we get compile-time warnings:
arm/mach-pxa/raumfeld.c:1070:123: warning: 'raumfeld_connector_init' defined but not used [-Wunused-function]
arm/mach-pxa/raumfeld.c:1082:123: warning: 'raumfeld_speaker_init' defined but not used [-Wunused-function]
This marks the functions as __maybe_unused to avoid the warnings.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Daniel Mack <daniel@zonque.org>
|
|
In an old commit, we worked around the duplicate definition of
GPIO24_SSP1_SFRM in cm-x2xx.c, which includes files for both
pxa25x and pxa27x. Apparently the problem has come back and we
now have four additional duplicate symbols that cause warnings:
In file included from /git/arm-soc/arch/arm/mach-pxa/pxa27x.h:7:0,
from /git/arm-soc/arch/arm/mach-pxa/cm-x2xx.c:27:
/git/arm-soc/arch/arm/mach-pxa/mfp-pxa27x.h:21:0: warning: "GPIO86_GPIO" redefined
#define GPIO86_GPIO MFP_CFG_IN(GPIO86, AF0)
This uses the same hack as before and undefines all symbols that
are defined more than once. Fortunately, cm-x2xx does not need
any of these.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Robert Jarzmik <robert.jarzmik@free.fr>
|
|
* mmp/multiplatform:
ARM: mmp: avoid unused functions
ARM: mmp: move into ARCH_MULTIPLATFORM
ARM: mmp: make all header files local
ARM: mmp: make plat-pxa build standalone
ARM: mmp: remove remaining legacy pxa-dma support
ARM: mohawk: allow building with MMU disabled
ARM: make xscale iwmmxt code multiplatform aware
clk: mmp: stop using platform headers
|
|
* s3c64xx/multiplatform:
ARM: s3c64xx: allow building without board support
ARM: s3c64xx: multiplatform support
ARM: s3c64xx: use common debug-ll implementation
ARM: s3c64xx: use new adc/touchscreen driver
iio: exynos-adc: add experimental touchscreen support
ARM: s3c64xx: enable sparse IRQ support
ARM: s3c64xx: prepare initcalls for multiplatform
gpio: samsung: move gpio-samsung driver back to platform code
ASoC: samsung/smartq: use dynamic registration
Input: s3c2410_ts: fix S3C_ADC dependency
Conflicts:
arch/arm/Kconfig.debug
|
|
* multiplatform/debug-ll:
ARM: debug-ll: reorder Kconfig alphanumerically
ARM: debug-ll: rework footbridge handling
ARM: debug-ll: rework lpc32xx handling
ARM: debug-ll: rework gemini handling
ARM: debug-ll: rework integrator/versatile handling
ARM: debug-ll: rework SPEAr handling
ARM: debug-ll: rework ep93xx handling
ARM: debug-ll: reorganize mvebu debug uart config
ARM: debug-ll: fix UART configuration with ARCH_KEYSTONE
|
|
The file has gotten a little out of sync, as platforms got
added in the wrong place, or have been renamed. This moves
the options around, but should not change any functionality.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
|
|
Footbridge has two debug ports that are handled a bit differently:
The 8250 port uses the normal debug/8250.S implementation that is shared
with a lot of other platforms, but it relies on the DEBUG_UART_8250
option to be turned on automatically instead of being selected by
DEBUG_FOOTBRIDGE_COM1 as we do for most other platforms. I'm changing
this to use a 'select' and change the dependency to the debug symbol
rather than the platform symbol for consistency.
The DC21285 UART has a separate top-level option, and relies on
the traditional include/mach/debug-macro.S method. With the s3c64xx
multiplatform series queued up for 4.5, it is now the last one that does
this, so by moving this file to include/debug/dc21285.S, we can get
all platforms to do things the same way.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
|
|
LPC32xx can not yet be configured in a multiplatform kernel, but
if we ever get there, enabling one of the LPC32xx platforms
while trying to use DEBUG_LL for another platform can default to
the wrong UART address, as the options are purely based on the
architecture being enabled or not.
This changes the logic to use the LPC32xx default addresses only
if we have also picked the respective Kconfig symbols introduced
here.
While we're at it, this also reorders the virtual address as
it should be.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Vladimir Zapolskiy <vz@mleia.com>
|
|
Gemini can not yet be configured in a multiplatform kernel, but
if we ever get there, enabling one of the gemini platforms
while trying to use DEBUG_LL for another platform can default to
the wrong UART address, as the options are purely based on the
architecture being enabled or not.
This changes the logic to use the gemini default addresses and
the flow control settings only if we have also picked the respective
Kconfig symbols introduced here.
While we're at it, this also reorders the virtual address as
it should be.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Hans Ulli Kroll <ulli.kroll@googlemail.com>
|
|
Enabling one of the integrator platforms in a multiplatform kernel
while trying to use DEBUG_LL for another platform can default to
the wrong UART address, as the options are purely based on the
architecture being enabled or not.
This changes the logic to use the integrator default addresses only
if we have also picked the respective Kconfig symbols introduced
here. Versatile is not yet part of multiplatform, but hopefully
soon will be, so we do the same change for versatile as well.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
|
|
Enabling one of the SPEAr platforms in a multiplatform kernel
while trying to use DEBUG_LL for another platform can default to
the wrong UART address, as the options are purely based on the
architecture being enabled or not.
This changes the logic to use the SPEAr default addresses only
if we have also picked the respective Kconfig symbols introduced
here.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
|
|
This makes ep93xx debug-ll handling more consistent with the other
platforms, by adding a separate Kconfig symbol for it that
in turn selects the standard DEBUG_UART_PL01X symbol.
We still have to pick a physical address even if DEBUG_LL is disabled
here, because the EP93xx uncompress output code uses
CONFIG_DEBUG_UART_PHYS. If we ever move to multiplatform support,
this can go away.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
|
|
As we are moving dove/mv78xx0/orion into multiplatform, the debug-ll
configuration options for these platforms are conflicting with the
multiplatform configuration: enabling one of those platforms sometimes
changes the default addresses to the ones used on one of them, rather
than the one that was selected in Kconfig.
This changes the configuration so we share the physical address
configuration with mach-mvebu.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
|
|
We may have multiple platforms enabled and also DEBUG_LL
configured for one of them. However if we enable ARCH_KEYSTONE,
we default to using 32-bit UART access independent of which
platform we are actually using, which can be confusing.
This changes the logic so the 32-bit default gets only
used by default if we actually configure the keystone
UART, as opposed to picking some other 8250 setting on
a kernel that has keystone support enabled.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
|
|
I could not find any users of this file, past or present, and
it contains only a comment, so let's remove it.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
|
|
Some header files are never included outside of a mach-w90x900
directory and do not need to be made visible in include/mach,
so let's just move them all down one level.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
|
|
Some header files are never included outside of a mach-iop13xx
directory and do not need to be made visible in include/mach,
so let's just move them all down one level.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
|
|
Some header files are never included outside of a mach-davinci
directory and do not need to be made visible in include/mach,
so let's just move them all down one level.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Sekhar Nori <nsekhar@ti.com>
|
|
Some header files are never included outside of a mach-ks8695
directory and do not need to be made visible in include/mach,
so let's just move them all down one level.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Greg Ungerer <gerg@uclinux.org>
|
|
Some header files are never included outside of a mach-omap1
directory and do not need to be made visible in include/mach,
so let's just move them all down one level.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Tony Lindgren <tony@atomide.com>
|
|
Lots of header files are never included outside of a mach-pxa
directory and do not need to be made visible in include/mach,
so let's just move them all down one level.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
|
|
Most of the code for the s3c64xx platform is only used when booting
with ATAGS based board files, but not when using device-tree.
This tries to identify all the s3c64xx specific code that is
unneeded when CONFIG_ATAGS is not set, so we can build a smaller
DT-only kernel if configured that way.
All board support is still left intact but now depends on the
CONFIG_ATAGS symbol that users may intentionally disable.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
|
|
After all preparation work is done, we can finally move the Kconfig
option for s3c64xx into ARCH_MULTIPLATFORM. This implies allowing
SAMSUNG_ATAGS for multiplatform again, but now disallowing the
ADC driver below it, as that still has dependencies on header files.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
|
|
The uart on s3c64xx is essentially the same as on s3c24xx,
so we can share a single assembler file. However, the addresses
are different, and we need to add the respective Kconfig magic
to get the right addresses.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
|
|
The old ADC and touchscreen drivers are not compatible with
multiplatform support, but we can use the exynos-adc driver
as a replacement.
This changes the common device creation functions for s3c64xx
(but not s3c24xx for now) to use the new driver. To do this,
we have to pass the interrupt resources in the opposite order
and pass the platform data in the adc device node.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
|
|
This adds support for the touchscreen on Samsung s3c64xx.
The driver is completely untested but shows roughly how
it could be done, following the example of the at91 driver.
compared to the old plat-samsung/adc driver, there is
no support for prioritizing ts over other clients, nor
for oversampling. From my reading of the code, the
priorities didn't actually have any effect at all, but
the oversampling might be needed.
Verifying this driver is the main issue that is currently
holding up multiplatform support for s3c64xx, so any help
in testing is very much appreciated.
The current version uses the IS_REACHABLE() that is
going to be introduced in the linux-media tree, please
comment this out for testing.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
|
|
This is another prerequisite for enabling multiplatform
support, and it is the part I am least certain about.
I assume it will cause the extra boot message "Cannot
allocate irq_descs @ IRQ%d, assuming pre-allocated" to
be printed, but otherwise work ok. This definitely needs
to be tested on real hardware to see if it works.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
|
|
In a multiplatform kernel, each initcall is run regardless
of the platform it is meant for, so it must not attempt to
access SoC-specific registers.
This adds 'if (soc_is_s3c64xx)' to all initcalls that are
specific to the s3c64xx platform, to prevent them from breaking
other platforms once we can build them into a combined kernel.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Reviewed-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
|
|
The gpio-samsung driver is special in the sense that it
interacts directly in multiple ways with the legacy platform
code for the s3c24xx and s3c64xx platforms. In contrast,
all devicetree based machines for Samsung, including the
ones on those two SoC families use a different driver.
The header files that define the interface between the platform
code and the gpio driver are not visible when building a
kernel for ARCH_MULTIPLATFORM, which prevents us from
turning on this option for s3c64xx.
To work around this, we now move the driver back into platform
code, from where it was originally moved to as part of commit
1b39d5f2cc5c28 ("gpio/samsung: gpio-samsung.c to support
Samsung GPIOs").
The long-term plan for this driver would be to remove it
entirely, after all Samsung machines have been converted
over to boot from DT, but there is currently no timeline
for when that might happen.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Reviewed-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
|
|
As a prerequisite for moving s3c64xx into multiplatform configurations,
we need to change the smartq audio driver to stop using hardcoded
gpio numbers from the header file, and instead pass the gpio data
through platform_data.
In order to do that, we also move the code to use module_platform_driver
and register the platform device using platform_device_register_simple
and register the gpios through the gpiod API.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Mark Brown <broonie@kernel.org>
Reviewed-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
|
|
S3C_ADC is only available on machines that don't do ARCH_MULTIPLATFORM,
so changing the 'select' into 'depends on' here helps us move to
ARCH_MULTIPLATFORM without introducing regressions.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Reviewed-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
|
|
mach-mmp/devices.c:81:21: warning: 'u2o_get' defined but not used [-Wunused-function]
static unsigned int u2o_get(void __iomem *base, unsigned int offset)
^
mach-mmp/devices.c:86:13: warning: 'u2o_set' defined but not used [-Wunused-function]
static void u2o_set(void __iomem *base, unsigned int offset,
^
mach-mmp/devices.c:97:13: warning: 'u2o_clear' defined but not used [-Wunused-function]
static void u2o_clear(void __iomem *base, unsigned int offset,
^
mach-mmp/devices.c:108:13: warning: 'u2o_write' defined but not used [-Wunused-function]
static void u2o_write(void __iomem *base, unsigned int offset,
^
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
|
|
With all dependencies taken care of, this enables building
the Marvell mmp platform as part of ARCH_MULTIPLATFORM, along
with other ARMv5 and ARMv7 platforms.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Andrew Lunn <andrew@lunn.ch>
|
|
The mach/*.h headers are now inaccessible to any external code,
so we can move them all into the mach-mmp directory itself
and remove the subdirectories.
A few headers are not used at all, so we remove them here.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
|
|
The ssp.c driver in plat-pxa is the only remaining file including a
mach/*.h header from mmp. It actually doesn't need mach/hardware.h at
all, so we can remove the #include.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
|
|
All drivers have stopped using this code, so we can just
as well stop initializing it.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
|
|
It is in principle possible to build an MMP kernel for
the mohawk CPU with the MMU code disabled, except for one
simple build error:
proc-mohawk.S:345: Error: invalid operands (*UND* and *UND* sections) for `|'
proc-mohawk.S:345: Error: invalid operands (*ABS* and *UND* sections) for `|'
proc-mohawk.S:345: Error: invalid operands (*UND* and *UND* sections) for `|'
proc-mohawk.S:345: Error: invalid operands (*UND* and *UND* sections) for `|'
proc-mohawk.S:345: Error: undefined symbol L_PTE_USER used as an immediate value
This patch changes the proc-mohawk code to do the same as the
other CPUs and not try to actually do anything for the
cpu_mohawk_set_pte_ext function, which won't be used anyway.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
|
|
In a multiplatform configuration, we may end up building a kernel for
both Marvell PJ1 and an ARMv4 CPU implementation. In that case, the
xscale-cp0 code is built with gcc -march=armv4{,t}, which results in a
build error from the coprocessor instructions.
Since we know this code will only have to run on an actual xscale
processor, we can simply build the entire file for ARMv5TE.
Related to this, we need to handle the iWMMXT initialization sequence
differently during boot, to ensure we don't try to touch xscale
specific registers on other CPUs from the xscale_cp0_init initcall.
cpu_is_xscale() used to be hardcoded to '1' in any configuration that
enables any XScale-compatible core, but this breaks once we can have a
combined kernel with MMP1 and something else.
In this patch, I replace the existing cpu_is_xscale() macro with a new
cpu_is_xscale_family() macro that evaluates true for xscale, xsc3 and
mohawk, which makes the behavior more deterministic.
The two existing users of cpu_is_xscale() are modified accordingly,
but slightly change behavior for kernels that enable CPU_MOHAWK without
also enabling CPU_XSCALE or CPU_XSC3. Previously, these would leave leave
PMD_BIT4 in the page tables untouched, now they clear it as we've always
done for kernels that enable both MOHAWK and the support for the older
CPU types.
Since the previous behavior was inconsistent, I assume it was
unintentional.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
|
|
The mmp clock drivers currently hardcode the physical addresses for
the clock registers. This is generally a bad idea, and it also gets in
the way of multiplatform builds, which make the platform header files
inaccessible to device drivers.
To work around the header file problem, this patch changes the calling
convention so the three mmp clock drivers get initialized with the base
addresses as arguments from the platform code.
It would still be useful to have a larger rework of the clock drivers,
with DT integration to let the clocks actually be probed automatically,
and the base addresses passed as DT properties. I am unsure if anyone
is still interested in the mmp platform, so it is possible that this
won't happen.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Mike Turquette <mturquette@linaro.org>
Cc: Chao Xie <chao.xie@marvell.com>
Cc: Eric Miao <eric.y.miao@gmail.com>
Cc: Haojian Zhuang <haojian.zhuang@gmail.com>
|
|
|
|
Pull nouveau and radeon fixes from Dave Airlie:
"Just some nouveau and radeon/amdgpu fixes.
The nouveau fixes look large as the firmware context files are
regenerated, but the actual change is quite small"
* 'drm-fixes' of git://people.freedesktop.org/~airlied/linux:
drm/radeon: make some dpm errors debug only
drm/nouveau/volt/pwm/gk104: fix an off-by-one resulting in the voltage not being set
drm/nouveau/nvif: allow userspace access to its own client object
drm/nouveau/gr/gf100-: fix oops when calling zbc methods
drm/nouveau/gr/gf117-: assume no PPC if NV_PGRAPH_GPC_GPM_PD_PES_TPC_ID_MASK is zero
drm/nouveau/gr/gf117-: read NV_PGRAPH_GPC_GPM_PD_PES_TPC_ID_MASK from correct GPC
drm/nouveau/gr/gf100-: split out per-gpc address calculation macro
drm/nouveau/bios: return actual size of the buffer retrieved via _ROM
drm/nouveau/instmem: protect instobj list with a spinlock
drm/nouveau/pci: enable c800 magic for some unknown Samsung laptop
drm/nouveau/pci: enable c800 magic for Clevo P157SM
drm/radeon: make rv770_set_sw_state failures non-fatal
drm/amdgpu: move dependency handling out of atomic section v2
drm/amdgpu: optimize scheduler fence handling
drm/amdgpu: remove vm->mutex
drm/amdgpu: add mutex for ba_va->valids/invalids
drm/amdgpu: adapt vce session create interface changes
drm/amdgpu: vce use multiple cache surface starting from stoney
drm/amdgpu: reset vce trap interrupt flag
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/abelloni/linux
Pull RTC fixes from Alexandre Belloni:
"Two fixes for the ds1307 alarm and wakeup"
* tag 'rtc-4.4-2' of git://git.kernel.org/pub/scm/linux/kernel/git/abelloni/linux:
rtc: ds1307: fix alarm reading at probe time
rtc: ds1307: fix kernel splat due to wakeup irq handling
|
|
Pull MIPS fix from Ralf Baechle:
"Just a fix for empty loops that may be removed by non-antique GCC"
* 'upstream' of git://git.linux-mips.org/pub/scm/ralf/upstream-linus:
MIPS: Fix delay loops which may be removed by GCC.
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/geert/linux-m68k
Pull m68k fixes from Geert Uytterhoeven:
"Summary:
- Add missing initialization of max_pfn, which is needed to make
selftests/vm/mlock2-tests succeed,
- Wire up new mlock2 syscall"
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/geert/linux-m68k:
m68k: Wire up mlock2
m68knommu: Add missing initialization of max_pfn and {min,max}_low_pfn
m68k/mm: sun3 - Add missing initialization of max_pfn and {min,max}_low_pfn
m68k/mm: m54xx - Add missing initialization of max_pfn
m68k/mm: motorola - Add missing initialization of max_pfn
|
