I revisited some older patches here, getting two of the remaining
ARM platforms to build with ARCH_MULTIPLATFORM like most others do.

In case of lpc32xx, I created a new set of patches, which seemed
easier than digging out what I did for an older release many
years ago.

* lpc32xx/multiplatform:
  ARM: lpc32xx: allow multiplatform build
  ARM: lpc32xx: clean up header files
  serial: lpc32xx: allow compile testing
  net: lpc-enet: allow compile testing
  net: lpc-enet: fix printk format strings
  net: lpc-enet: fix badzero.cocci warnings
  net: lpc-enet: move phy setup into platform code
  net: lpc-enet: factor out iram access
  gpio: lpc32xx: allow building on non-lpc32xx targets
  serial: lpc32xx_hs: allow compile-testing
  watchdog: pnx4008_wdt: allow compile-testing
  usb: udc: lpc32xx: allow compile-testing
  usb: ohci-nxp: enable compile-testing
Signed-off-by: Arnd Bergmann <arnd@arndb.de>

All preparation work is done, so the platform can finally
be moved into ARCH_MULTIPLATFORM. This requires a small
change to the defconfig file to enable the platform.

Link: https://lore.kernel.org/r/20190809144043.476786-14-arnd@arndb.deSigned-off-by: Arnd Bergmann <arnd@arndb.de>

All device drivers have stopped relying on mach/*.h headers,
so move the remaining headers into arch/arm/mach-lpc32xx/lpc32xx.h
to prepare for multiplatform builds.

The mach/entry-macro.S file has been unused for a long time now
and can simply get removed.

Link: https://lore.kernel.org/r/20190809144043.476786-13-arnd@arndb.deAcked-by: Sylvain Lemieux <slemieux.tyco@gmail.com>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>

The lpc32xx_loopback_set() function in hte lpc32xx_hs driver is the
one thing that relies on platform header files. Move that into the
core platform code so we only need a variable declaration for it,
and enable COMPILE_TEST building.

Link: https://lore.kernel.org/r/20190809144043.476786-12-arnd@arndb.deSigned-off-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>

The lpc-enet driver can now be built on all platforms, so
allow compile testing as well.

Add one missing header inclusion that is required in some
configurations.

Link: https://lore.kernel.org/r/20190809144043.476786-11-arnd@arndb.deSigned-off-by: Arnd Bergmann <arnd@arndb.de>

compile-testing this driver on other architectures showed
multiple warnings:

  drivers/net/ethernet/nxp/lpc_eth.c: In function 'lpc_eth_drv_probe':
  drivers/net/ethernet/nxp/lpc_eth.c:1337:19: warning: format '%d' expects argument of type 'int', but argument 4 has type 'resource_size_t {aka long long unsigned int}' [-Wformat=]

  drivers/net/ethernet/nxp/lpc_eth.c:1342:19: warning: format '%x' expects argument of type 'unsigned int', but argument 4 has type 'dma_addr_t {aka long long unsigned int}' [-Wformat=]

Use format strings that work on all architectures.

Link: https://lore.kernel.org/r/20190809144043.476786-10-arnd@arndb.deReported-by: kbuild test robot <lkp@intel.com>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>

drivers/net/ethernet/nxp/lpc_eth.c:1316:31-32: WARNING comparing pointer to 0

 Compare pointer-typed values to NULL rather than 0

Semantic patch information:
 This makes an effort to choose between !x and x == NULL.  !x is used
 if it has previously been used with the function used to initialize x.
 This relies on type information.  More type information can be obtained
 using the option -all_includes and the option -I to specify an
 include path.

Generated by: scripts/coccinelle/null/badzero.cocci

Link: https://lore.kernel.org/r/20190809144043.476786-9-arnd@arndb.de
Fixes: e42016eb3844 ("net: lpc-enet: allow compile testing")
Signed-off-by: kbuild test robot <lkp@intel.com>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>

Setting the phy mode requires touching a platform specific
register, which prevents us from building the driver without
its header files.

Move it into a separate function in arch/arm/mach/lpc32xx
to hide the core registers from the network driver.

Link: https://lore.kernel.org/r/20190809144043.476786-8-arnd@arndb.deAcked-by: Sylvain Lemieux <slemieux.tyco@gmail.com>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>

The lpc_eth driver uses a platform specific method to find
the internal sram. This prevents building it on other machines.

Rework to only use one function call and keep the other platform
internals where they belong. Ideally this would look up the
sram location from DT, but as this is a rarely used driver,
I want to keep the modifications to a minimum.

Link: https://lore.kernel.org/r/20190809144043.476786-7-arnd@arndb.deSigned-off-by: Arnd Bergmann <arnd@arndb.de>

The driver uses hardwire MMIO addresses instead of the data
that is passed in device tree. Change it over to only
hardcode the register offset values and allow compile-testing.

Link: https://lore.kernel.org/r/20190809144043.476786-6-arnd@arndb.deAcked-by: Sylvain Lemieux <slemieux.tyco@gmail.com>
Tested-by: Sylvain Lemieux <slemieux.tyco@gmail.com>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>

The only thing that prevents building this driver on other
platforms is the mach/hardware.h include, which is not actually
used here at all, so remove the line and allow CONFIG_COMPILE_TEST.

Link: https://lore.kernel.org/r/20190809144043.476786-5-arnd@arndb.deAcked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Acked-by: Sylvain Lemieux <slemieux.tyco@gmail.com>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>

The only thing that prevents building this driver on other
platforms is the mach/hardware.h include, which is not actually
used here at all, so remove the line and allow CONFIG_COMPILE_TEST.

Link: https://lore.kernel.org/r/20190809144043.476786-4-arnd@arndb.deAcked-by: Sylvain Lemieux <slemieux.tyco@gmail.com>
Reviewed-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>

The only thing that prevents building this driver on other
platforms is the mach/hardware.h include, which is not actually
used here at all, so remove the line and allow CONFIG_COMPILE_TEST.

Link: https://lore.kernel.org/r/20190809144043.476786-3-arnd@arndb.deAcked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Acked-by: Sylvain Lemieux <slemieux.tyco@gmail.com>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>

The driver hardcodes a hardware I/O address the way one should
generally not do, and this prevents both compile-testing, and
moving the platform to CONFIG_ARCH_MULTIPLATFORM.

Change the code to be independent of the machine headers
to allow those two. Removing the hardcoded address would
be hard and is not necessary, so leave that in place for now.

Link: https://lore.kernel.org/r/20190809144043.476786-2-arnd@arndb.deSigned-off-by: Arnd Bergmann <arnd@arndb.de>
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>

In a multiplatform configuration, enabling DEBUG_LL breaks booting
on all platforms with incompatible settings. In case of the Marvell
platforms of the Orion/MVEBU family, the physical addresses are
all the same, we just map them at different virtual addresses,
which makes it impossible to run a kernel with DEBUG_LL enabled on
a combination of the merged mvebu and the legacy boardfile based
platforms.

This is easily solved by using the same virtual address everywhere.
I picked the address that is already used by mach-mvebu for UART0:
0xfec12000. All these platforms have a 1MB region with their internal
registers, almost always at physical address 0xf1000000, so I'm
updating the iotable for that entry.

In case of mach-dove, this is slightly trickier, as the existing
mapping is 8MB and a second 8MB mapping is already at the 0xfec00000
address. I have verified from the datasheet that the last 7MB of the
physical mapping are "reserved" and nothing in Linux tries to use
it either. I'm putting this 1MB mapping at the same address as the
others, and the second 8MB register area immediately before that.

Link: https://lore.kernel.org/r/20190731195713.3150463-14-arnd@arndb.de
Link: https://lore.kernel.org/linux-arm-kernel/87si3eb1z8.fsf@free-electrons.com/Signed-off-by: Arnd Bergmann <arnd@arndb.de>

This is a simple move of all header files that are no longer
included by anything else from the include/mach directory
to the platform directory itself as preparation for
multiplatform support.

The mach/uncompress.h headers are left in place for now,
and are mildly modified to be independent of the other
headers. They will be removed entirely when ARCH_MULTIPLATFORM
gets enabled and they become obsolete.

Rather than updating the path names inside of the comments
of each header, I delete those comments to avoid having to
update them again, should they get moved or copied another
time.

Link: https://lore.kernel.org/r/20190731195713.3150463-13-arnd@arndb.deSigned-off-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>

Merge tag 'ux500-v5.4-1' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-stericsson into arm/soc

This is a slew of Ux500 updates for the v5.4 kernel cycle:

- Stop populating the PRCMU devices from the core CPU
  file, it works just fine at device_initcall() level.

- Add a missing of_node_put() in the core file.

- Simplify the debug UART code.

- Add myself to MAINTAINERS

* tag 'ux500-v5.4-1' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-stericsson:
  MAINTAINERS: add soc/ux500
  ARM: ux500: simplify and move debug UART
  ARM: ux500: add missing of_node_put()
  ARM: ux500: Stop populating the PRCMU devices early

Link: https://lore.kernel.org/r/CACRpkdbH-h5fRwuidcpeOp8mtRoKUW65SAk8a4A==BCDzn3QMA@mail.gmail.comSigned-off-by: Arnd Bergmann <arnd@arndb.de>

Various bits of iop32x are now in their traditional locations in plat-iop,
mach-iop/include/mach/ and in include/asm/mach/hardware. As nothing
outside of the iop32x mach code references these any more, this can all
be moved into one place now.

The only remaining things in the include/mach/ directory are now the
NR_IRQS definition, the entry-macros.S file and the the decompressor
uart access. After the irqchip code has been converted to SPARSE_IRQ
and GENERIC_IRQ_MULTI_HANDLER, it can be moved to ARCH_MULTIPLATFORM.

Link: https://lore.kernel.org/r/20190809163334.489360-7-arnd@arndb.deSigned-off-by: Arnd Bergmann <arnd@arndb.de>

All supported uarts use the same address: IQ80321_UART and IQ31244_UART
are both defined to the default value of 0xfe800000. By using that as
the address unconditionally, all dependencies on other machine headers
can be avoided.

Link: https://lore.kernel.org/r/20190809163334.489360-6-arnd@arndb.deSigned-off-by: Arnd Bergmann <arnd@arndb.de>

Building a combined ARMv4+XScale kernel produces these
and other build failures:

/tmp/copypage-xscale-3aa821.s: Assembler messages:
/tmp/copypage-xscale-3aa821.s:167: Error: selected processor does not support `pld [r7,#0]' in ARM mode
/tmp/copypage-xscale-3aa821.s:168: Error: selected processor does not support `pld [r7,#32]' in ARM mode
/tmp/copypage-xscale-3aa821.s:169: Error: selected processor does not support `pld [r1,#0]' in ARM mode
/tmp/copypage-xscale-3aa821.s:170: Error: selected processor does not support `pld [r1,#32]' in ARM mode
/tmp/copypage-xscale-3aa821.s:171: Error: selected processor does not support `pld [r7,#64]' in ARM mode
/tmp/copypage-xscale-3aa821.s:176: Error: selected processor does not support `ldrd r4,r5,[r7],#8' in ARM mode
/tmp/copypage-xscale-3aa821.s:180: Error: selected processor does not support `strd r4,r5,[r1],#8' in ARM mode

Add an explict .arch armv5 in the inline assembly to allow the ARMv5
specific instructions regardless of the compiler -march= target.

Link: https://lore.kernel.org/r/20190809163334.489360-5-arnd@arndb.deSigned-off-by: Arnd Bergmann <arnd@arndb.de>

Now that iop3xx and iop13xx are gone, the iop-adma driver no
longer needs to deal with incompatible register layout defined
in machine specific header files.

Move the iop32x specific definitions into drivers/dma/iop-adma.h
and the platform_data into include/linux/platform_data/dma-iop32x.h,
and change the machine code to no longer reference those.

The DMA0_ID/DMA1_ID/AAU_ID macros are required as part of the
platform data interface and still need to be visible, so move
those from one header to the other.

Link: https://lore.kernel.org/r/20190809163334.489360-4-arnd@arndb.deSigned-off-by: Arnd Bergmann <arnd@arndb.de>

When compile-testing on other architectures, we get lots of warnings
about incorrect format strings, like:

   drivers/dma/iop-adma.c: In function 'iop_adma_alloc_slots':
   drivers/dma/iop-adma.c:307:6: warning: format '%x' expects argument of type 'unsigned int', but argument 6 has type 'dma_addr_t {aka long long unsigned int}' [-Wformat=]

   drivers/dma/iop-adma.c: In function 'iop_adma_prep_dma_memcpy':
>> drivers/dma/iop-adma.c:518:40: warning: format '%u' expects argument of type 'unsigned int', but argument 5 has type 'size_t {aka long unsigned int}' [-Wformat=]

Use %zu for printing size_t as required, and cast the dma_addr_t
arguments to 'u64' for printing with %llx. Ideally this should use
the %pad format string, but that requires an lvalue argument that
doesn't work here.

Link: https://lore.kernel.org/r/20190809163334.489360-3-arnd@arndb.deSigned-off-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Vinod Koul <vkoul@kernel.org>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>

Compile-testing this driver fails on m68k without the
extra header inclusion.

Link: https://lore.kernel.org/r/20190809163334.489360-2-arnd@arndb.deReported-by: kbuild test robot <lkp@intel.com>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Vinod Koul <vkoul@kernel.org>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>

There are three families of IOP machines we support in Linux: iop32x
(which includes EP80219), iop33x and iop13xx (aka IOP34x aka WP8134x).

All products we support in the kernel are based on the first of these,
iop32x, the other families only ever supported the Intel reference
boards but no actual machine anyone could ever buy.

While one could clearly make them all three work in a single kernel
with some work, this takes the easy way out, removing the later two
platforms entirely, under the assumption that there are no remaining
users.

Earlier versions of OpenWRT and Debian both had support for iop32x
but not the others, and they both dropped iop32x as well in their 2015
releases.

Link: https://lore.kernel.org/r/20190809163334.489360-1-arnd@arndb.deSigned-off-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Wolfram Sang <wsa@the-dreams.de> # for I2C parts
Acked-by: Dan Williams <dan.j.williams@intel.com>
Acked-by: Martin Michlmayr <tbm@cyrius.com>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>

This removes the old Winbond w90x900 platform, also known
as Nuvoton NUC900. Wan Zongshun originally contributed
the port and maintained it since then.

From all I can tell, this platform is no longer being used
with modern kernels, based on various indications:

- The supported chips (nuc910/950/960) are no longer marketed
  by the manufacturer

- Newer chips from the same family (nuc97x, nuc980, n329x)
  that are still marketed have Linux BSPs but those were never
  submitted for upstream inclusion.

- The last patch from the platform maintainer was in 2011.

- All patches to w90x900 platform specific files afterwards
  are cleanups that were apparently done without access to
  test hardware.

- Both the website and the email address listed in the
  MAINTAINERS have become unreachable.

Link: https://lore.kernel.org/r/20190809202749.742267-17-arnd@arndb.de
Cc: "Wanzongshun (Vincent)" <wanzongshun@huawei.com>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>

ks8695 is an older SoC originally made by Kendin, which was later acquired
by Micrel, and subsequently by Microchip.

The platform port was originally contributed by Andrew Victor and Ben
Dooks, and later maintained by Greg Ungerer.

When I recently submitted cleanups, but Greg noted that the platform no
longer boots and nobody is using it any more, we decided to remove it.

Link: https://lore.kernel.org/r/20190809202749.742267-2-arnd@arndb.de
Cc: Andrew Victor <linux@maxim.org.za>
Acked-by: Ben Dooks <ben-linux@fluff.org>
Link: https://wikidevi.com/wiki/Micrel
Link: https://lore.kernel.org/linux-arm-kernel/2bc41895-d4f9-896c-0726-0b2862fcbf25@kernel.org/Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Greg Ungerer <gerg@kernel.org>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>

After transitioning the CLCD to use DRM we can now kill off
the final piece of auxdata on the NSPIRE.

Link: https://lore.kernel.org/r/20190810075023.7327-1-linus.walleij@linaro.org
Cc: Daniel Tang <dt.tangr@gmail.com>
Cc: Fabian Vogt <fabian@ritter-vogt.de>
Tested-by: Fabian Vogt <fabian@ritter-vogt.de>
Acked-by: Sam Ravnborg <sam@ravnborg.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>

Pull dax fixes from Dan Williams:
 "A filesystem-dax and device-dax fix for v5.3.

  The filesystem-dax fix is tagged for stable as the implementation has
  been mistakenly throwing away all cow pages on any truncate or hole
  punch operation as part of the solution to coordinate device-dma vs
  truncate to dax pages.

  The device-dax change fixes up a regression this cycle from the
  introduction of a common 'internal per-cpu-ref' implementation.

  Summary:

   - Fix dax_layout_busy_page() to not discard private cow pages of
     fs/dax private mappings.

   - Update the memremap_pages core to properly cleanup on behalf of
     internal reference-count users like device-dax"

* tag 'dax-fixes-5.3-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm:
  mm/memremap: Fix reuse of pgmap instances with internal references
  dax: dax_layout_busy_page() should not unmap cow pages

Pull NTB fix from Jon Mason:
 "Bug fix for NTB MSI kernel compile warning"

* tag 'ntb-5.3-bugfixes' of git://github.com/jonmason/ntb:
  NTB/msi: remove incorrect MODULE defines

Pull RISC-V updates from Paul Walmsley:
 "A few minor RISC-V updates for v5.3-rc4:

   - Remove __udivdi3() from the 32-bit Linux port, converting the only
     upstream user to use do_div(), per Linux policy

   - Convert the RISC-V standard clocksource away from per-cpu data
     structures, since only one is used by Linux, even on a multi-CPU
     system

   - A set of DT binding updates that remove an obsolete text binding in
     favor of a YAML binding, fix a bogus compatible string in the
     schema (thus fixing a "make dtbs_check" warning), and clarifies the
     future values expected in one of the RISC-V CPU properties"

* tag 'riscv/for-v5.3-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux:
  dt-bindings: riscv: fix the schema compatible string for the HiFive Unleashed board
  dt-bindings: riscv: remove obsolete cpus.txt
  RISC-V: Remove udivdi3
  riscv: delay: use do_div() instead of __udivdi3()
  dt-bindings: Update the riscv,isa string description
  RISC-V: Remove per cpu clocksource

Pull x86 fixes from Thomas Gleixner:
 "A few fixes for x86:

   - Don't reset the carefully adjusted build flags for the purgatory
     and remove the unwanted flags instead. The 'reset all' approach led
     to build fails under certain circumstances.

   - Unbreak CLANG build of the purgatory by avoiding the builtin
     memcpy/memset implementations.

   - Address missing prototype warnings by including the proper header

   - Fix yet more fall-through issues"

* 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  x86/lib/cpu: Address missing prototypes warning
  x86/purgatory: Use CFLAGS_REMOVE rather than reset KBUILD_CFLAGS
  x86/purgatory: Do not use __builtin_memcpy and __builtin_memset
  x86: mtrr: cyrix: Mark expected switch fall-through
  x86/ptrace: Mark expected switch fall-through

Pull perf tooling fixes from Thomas Gleixner:
 "Perf tooling fixes all over the place:

   - Fix the selection of the main thread COMM in db-export

   - Fix the disassemmbly display for BPF in annotate

   - Fix cpumap mask setup in perf ftrace when only one CPU is present

   - Add the missing 'cpu_clk_unhalted.core' event

   - Fix CPU 0 bindings in NUMA benchmarks

   - Fix the module size calculations for s390

   - Handle the gap between kernel end and module start on s390
     correctly

   - Build and typo fixes"

* 'perf-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  perf pmu-events: Fix missing "cpu_clk_unhalted.core" event
  perf annotate: Fix s390 gap between kernel end and module start
  perf record: Fix module size on s390
  perf tools: Fix include paths in ui directory
  perf tools: Fix a typo in a variable name in the Documentation Makefile
  perf cpumap: Fix writing to illegal memory in handling cpumap mask
  perf ftrace: Fix failure to set cpumask when only one cpu is present
  perf db-export: Fix thread__exec_comm()
  perf annotate: Fix printing of unaugmented disassembled instructions from BPF
  perf bench numa: Fix cpu0 binding

Pull scheduler fixes from Thomas Gleixner:
 "Three fixlets for the scheduler:

   - Avoid double bandwidth accounting in the push & pull code

   - Use a sane FIFO priority for the Pressure Stall Information (PSI)
     thread.

   - Avoid permission checks when setting the scheduler params for the
     PSI thread"

* 'sched-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  sched/psi: Do not require setsched permission from the trigger creator
  sched/psi: Reduce psimon FIFO priority
  sched/deadline: Fix double accounting of rq/running bw in push & pull

Pull irq fix from Thomas Gleixner:
 "A small fix for the affinity spreading code.

  It failed to handle situations where a single vector was requested
  either due to only one CPU being available or vector exhaustion
  causing only a single interrupt to be granted.

  The fix is to simply remove the requirement in the affinity spreading
  code for more than one interrupt being available"

* 'irq-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  genirq/affinity: Create affinity mask for single vector

Pull objtool warning fix from Thomas Gleixner:
 "The recent objtool fixes/enhancements unearthed a unbalanced CLAC in
  the i915 driver.

  Chris asked me to pick the fix up and route it through"

* 'core-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  drm/i915: Remove redundant user_access_end() from __copy_from_user() error path

Pull gfs2 fix from Andreas Gruenbacher:
 "Fix incorrect lseek / fiemap results"

* tag 'gfs2-v5.3-rc3.fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/gfs2/linux-gfs2:
  gfs2: gfs2_walk_metadata fix

A compilation -Wimplicit-fallthrough warning was enabled by commit
a035d552 ("Makefile: Globally enable fall-through warning")

Even though clang 10.0.0 does not currently support this warning without
a patch, clang currently does not support a value for this option.

  Link: https://bugs.llvm.org/show_bug.cgi?id=39382

The gcc default for this warning is 3 so removing the =3 has no effect
for gcc and enables the warning for patched versions of clang.

Also remove the =3 from an existing use in a parisc Makefile:
arch/parisc/math-emu/Makefile
Signed-off-by: Joe Perches <joe@perches.com>
Reviewed-and-tested-by: Nathan Chancellor <natechancellor@gmail.com>
Cc: Gustavo A. R. Silva <gustavo@embeddedor.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

Pull char/misc driver fixes Greg KH:
 "Here are some small char/misc driver fixes for 5.3-rc4.

  Two of these are for the habanalabs driver for issues found when
  running on a big-endian system (are they still alive?) The others are
  tiny fixes reported by people, and a MAINTAINERS update about the
  location of the fpga development tree.

  All of these have been in linux-next for a while with no reported
  issues"

* tag 'char-misc-5.3-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc:
  coresight: Fix DEBUG_LOCKS_WARN_ON for uninitialized attribute
  MAINTAINERS: Move linux-fpga tree to new location
  nvmem: Use the same permissions for eeprom as for nvmem
  habanalabs: fix host memory polling in BE architecture
  habanalabs: fix F/W download in BE architecture

Pull driver core fixes from Greg KH:
 "Here are two small fixes for some driver core issues that have been
  reported. There is also a kernfs "fix" here, which was then reverted
  because it was found to cause problems in linux-next.

  The driver core fixes both resolve reported issues, one with gpioint
  stuff that showed up in 5.3-rc1, and the other finally (and hopefully)
  resolves a very long standing race when removing glue directories.
  It's nice to get that issue finally resolved and the developers
  involved should be applauded for the persistence it took to get this
  patch finally accepted.

  All of these have been in linux-next for a while with no reported
  issues. Well, the one reported issue, hence the revert :)"

* tag 'driver-core-5.3-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core:
  Revert "kernfs: fix memleak in kernel_ops_readdir()"
  kernfs: fix memleak in kernel_ops_readdir()
  driver core: Fix use-after-free and double free on glue directory
  driver core: platform: return -ENXIO for missing GpioInt