An error occurred fetching the project authors.
  1. 20 Apr, 2023 5 commits
    • Paul Gortmaker's avatar
      powerpc: drop HPC-NET/MPC8641D evaluation platform support · c1d85f3f
      Paul Gortmaker authored
      There is no denying that this was an interesting platform in its day.
      Access to a SMP powerpc platform became a bit more obtainable for folks
      in the BSP industry in the 2007 era, thanks to this platform.
      
      Add to that the move to the black Antec case vs. the generic white 2005
      era case of the MPC8548CDS or the retro 1950s 1/2 height horizontal case
      of the HPC II, and it was pretty interesting to people like myself then.
      
      However, like all the other evaluation platforms, the overall system
      was complex out of necessity, as it tried to showcase all possible
      features and use-cases.  That included an AMP option, where you could run
      two bootloaders and two kernels over two serial consoles.  Peripheral
      sharing got a bit more tricky when you got to the hard disk and similar.
      
      In any case we still have the same circumstance.  A relatively rare and
      expensive evaluation platform that is now 15+ years old and not out there
      in large numbers in the general public.  Removal in 2023 just makes sense.
      Signed-off-by: default avatarPaul Gortmaker <paul.gortmaker@windriver.com>
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      Link: https://msgid.link/20230225201318.3682-3-paul.gortmaker@windriver.com
      c1d85f3f
    • Paul Gortmaker's avatar
      powerpc: drop MPC832x_MDS platform support · b8fa3af2
      Paul Gortmaker authored
      This final variant in the e300 family of Modular Development System
      (MDS) in this series was actually aimed at feature reduction - things
      like floating point and ethernet were removed in order to make for a
      lower power and lower cost system.
      
      Like all the MDS systems, it was meant as a vehicle to get the CPU out
      early to hardware OEMs so software and board development could take place
      in parallel.
      
      These were made in limited numbers and availability preference was given
      to partners who were planning to make their own boards.
      
      Given that the whole reason for existence was to assist in enabling new
      board designs [not happening for 10+ years], and that they weren't
      generally available, and that the hardware wasn't really hobbyist friendly
      even for retro computing, it makes sense to retire the support for this
      particular platform.
      Signed-off-by: default avatarPaul Gortmaker <paul.gortmaker@windriver.com>
      Acked-by: default avatarLi Yang <leoyang.li@nxp.com>
      [mpe: Drop stale reference to MPC832x_MDS in arch/powerpc/boot/Makefile]
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      Link: https://msgid.link/20230220115913.25811-5-paul.gortmaker@windriver.com
      b8fa3af2
    • Paul Gortmaker's avatar
      powerpc: drop MPC837x_MDS platform support · aa572079
      Paul Gortmaker authored
      This next evolutionary step in the e300 family of Modular Development
      System (MDS) still has, at its core component, a full length card with a
      PCI edge.  No case.  Serial and network connectors were on card, so it
      could optionally be fitted with plastic stand-offs and run stand-alone
      off a power brick.
      
      This is very similar to the MPC834x_MDS and MPC836x_MDS removed in the
      prior commits, but with this board variant as yet another evolutionary
      step.  SATA and PCI-e were now available.  But overall the form factor
      and design goals were unchanged.
      
      Like all the MDS systems, it was meant as a vehicle to get the CPU out
      early to hardware OEMs so software and board development could take place
      in parallel.
      
      These were made in limited numbers and availability preference was given
      to partners who were planning to make their own boards.
      
      Given that the whole reason for existence was to assist in enabling new
      board designs [not happening for 10+ years], and that they weren't
      generally available, and that the hardware wasn't really hobbyist friendly
      even for retro computing, it makes sense to retire the support for this
      particular platform.
      Signed-off-by: default avatarPaul Gortmaker <paul.gortmaker@windriver.com>
      Acked-by: default avatarLi Yang <leoyang.li@nxp.com>
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      Link: https://msgid.link/20230220115913.25811-4-paul.gortmaker@windriver.com
      aa572079
    • Paul Gortmaker's avatar
      powerpc: drop MPC836x_MDS platform support · 7840b08a
      Paul Gortmaker authored
      This 2006 era Modular Development System (MDS) has, at its core component,
      a full length card with a PCI edge.  No case.  Serial and network
      connectors were on card, so it could optionally be fitted with plastic
      stand-offs and run stand-alone off a power brick.
      
      This is very similar to the MPC834x_MDS removed in the prior commit, but
      with this board variant as an evolutionary step.  DDR2 was now an option,
      and the card edge was revised down to PCI-32 as PCI-64 never got traction.
      But overall the form factor and design goals were unchanged.
      
      Like all the MDS systems, it was meant as a vehicle to get the CPU out
      early to hardware OEMs so software and board development could take place
      in parallel.
      
      To that end, the BGA CPU was held in place with a mechanical spring loaded
      pressure assembly (vs. solder) so that early rev silicon could be replaced
      in the field.  Not for COTS deployment!
      
      These were made in limited numbers and availability preference was given
      to partners who were planning to make their own boards.
      
      Given that the whole reason for existence was to assist in enabling new
      board designs [not happening for 10+ years], and that they weren't
      generally available, and that the hardware wasn't really hobbyist friendly
      even for retro computing, it makes sense to retire the support for this
      particular platform.
      Signed-off-by: default avatarPaul Gortmaker <paul.gortmaker@windriver.com>
      Acked-by: default avatarLi Yang <leoyang.li@nxp.com>
      [mpe: Drop stale reference to MPC836x_MDS in arch/powerpc/boot/Makefile]
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      Link: https://msgid.link/20230220115913.25811-3-paul.gortmaker@windriver.com
      7840b08a
    • Paul Gortmaker's avatar
      powerpc: drop MPC834x_MDS platform support · da031017
      Paul Gortmaker authored
      This 2006 era Modular Development System (MDS) has, at its core
      component, a full length card with a PCI-64 edge.  No case.  Serial
      and network connectors were on card, so it could optionally be fitted
      with plastic stand-offs and run stand-alone off a power brick.
      
      Like all the MDS systems, it was meant as a vehicle to get the CPU
      out early to hardware OEMs so software and board development could
      take place in parallel.
      
      To that end, the BGA CPU was held in place with a mechanical spring
      loaded pressure assembly (vs. solder) so that early rev silicon could
      be replaced in the field.  Not for COTS deployment!
      
      These were made in limited numbers and availability preference was
      given to partners who were planning to make their own boards, like
      our WR SBC8349 [since retired in v4.18 (2017, commit 3bc6cf5a)]
      
      Given that the whole reason for existence was to assist in enabling
      new board designs [not happening for 10+ years], and that they weren't
      generally available, and that the hardware wasn't really hobbyist
      friendly even for retro computing, it makes sense to retire the
      support for this platform.
      Signed-off-by: default avatarPaul Gortmaker <paul.gortmaker@windriver.com>
      Acked-by: default avatarLi Yang <leoyang.li@nxp.com>
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      Link: https://msgid.link/20230220115913.25811-2-paul.gortmaker@windriver.com
      da031017
  2. 09 Mar, 2023 1 commit
  3. 08 Dec, 2022 1 commit
  4. 27 Oct, 2022 1 commit
  5. 30 Sep, 2022 1 commit
  6. 22 Aug, 2022 1 commit
  7. 29 Jun, 2022 1 commit
  8. 23 May, 2022 1 commit
  9. 17 Dec, 2021 1 commit
  10. 26 Aug, 2021 1 commit
    • Paul Gortmaker's avatar
      powerpc: retire sbc8641d board support · d7c1814f
      Paul Gortmaker authored
      The support was for this was added to mainline over 12 years ago, in
      v2.6.26 [4e8aae89] just around the ppc --> powerpc migration.
      
      I believe the board was introduced shortly after the sbc8548 board,
      making it roughly a 14 year old platform - with the CPU speed and
      memory size typical for that era.
      
      I haven't had one of these boards for several years, and availability
      was discontinued several years before that.
      
      Given that, there is no point in adding a burden to testing coverage
      that builds all possible defconfigs, so it makes sense to remove it.
      
      Of course it will remain in the git history forever, for anyone who
      happens to find a functional board and wants to tinker with it.
      Acked-by: default avatarScott Wood <oss@buserror.net>
      Signed-off-by: default avatarPaul Gortmaker <paul.gortmaker@windriver.com>
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      d7c1814f
  11. 13 May, 2021 1 commit
  12. 10 Mar, 2021 1 commit
  13. 08 Feb, 2021 1 commit
  14. 29 Jan, 2021 1 commit
  15. 10 Dec, 2020 1 commit
    • Dmitry Torokhov's avatar
      Input: gtco - remove driver · b2058cd9
      Dmitry Torokhov authored
      The driver has its own HID descriptor parsing code, that had and still
      has several issues discovered by syzbot and other tools. Ideally we
      should move the driver over to the HID subsystem, so that it uses proven
      parsing code.  However the devices in question are EOL, and GTCO is not
      willing to extend resources for that, so let's simply remove the driver.
      
      Note that our HID support has greatly improved over the last 10 years,
      we may also consider reverting 6f8d9e26 ("hid-core.c: Adds all GTCO
      CalComp Digitizers and InterWrite School Products to blacklist") and see
      if GTCO devices actually work with normal HID drivers.
      
      Link: https://lore.kernel.org/r/X8wbBtO5KidME17K@google.comSigned-off-by: default avatarDmitry Torokhov <dmitry.torokhov@gmail.com>
      b2058cd9
  16. 06 Nov, 2020 2 commits
  17. 04 Nov, 2020 1 commit
  18. 14 Sep, 2020 1 commit
    • Linus Torvalds's avatar
      vgacon: remove software scrollback support · 973c096f
      Linus Torvalds authored
      Yunhai Zhang recently fixed a VGA software scrollback bug in commit
      ebfdfeea ("vgacon: Fix for missing check in scrollback handling"),
      but that then made people look more closely at some of this code, and
      there were more problems on the vgacon side, but also the fbcon software
      scrollback.
      
      We don't really have anybody who maintains this code - probably because
      nobody actually _uses_ it any more.  Sure, people still use both VGA and
      the framebuffer consoles, but they are no longer the main user
      interfaces to the kernel, and haven't been for decades, so these kinds
      of extra features end up bitrotting and not really being used.
      
      So rather than try to maintain a likely unused set of code, I'll just
      aggressively remove it, and see if anybody even notices.  Maybe there
      are people who haven't jumped on the whole GUI badnwagon yet, and think
      it's just a fad.  And maybe those people use the scrollback code.
      
      If that turns out to be the case, we can resurrect this again, once
      we've found the sucker^Wmaintainer for it who actually uses it.
      Reported-by: default avatarNopNop Nop <nopitydays@gmail.com>
      Tested-by: default avatarWilly Tarreau <w@1wt.eu>
      Cc: 张云海 <zhangyunhai@nsfocus.com>
      Acked-by: default avatarAndy Lutomirski <luto@amacapital.net>
      Acked-by: default avatarWilly Tarreau <w@1wt.eu>
      Reviewed-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      973c096f
  19. 29 Jul, 2020 1 commit
  20. 24 Feb, 2020 1 commit
  21. 31 Jan, 2020 1 commit
  22. 13 Nov, 2019 1 commit
  23. 04 Jul, 2019 1 commit
  24. 03 Jul, 2019 1 commit
  25. 15 Jun, 2019 2 commits
    • Jiri Pirko's avatar
      net: sched: remove NET_CLS_IND config option · a5148626
      Jiri Pirko authored
      This config option makes only couple of lines optional.
      Two small helpers and an int in couple of cls structs.
      
      Remove the config option and always compile this in.
      This saves the user from unexpected surprises when he adds
      a filter with ingress device match which is silently ignored
      in case the config option is not set.
      Signed-off-by: default avatarJiri Pirko <jiri@mellanox.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      a5148626
    • Masahiro Yamada's avatar
      kbuild: add CONFIG_HEADERS_INSTALL and loosen the dependency of samples · e949f4c2
      Masahiro Yamada authored
      Commit 5318321d ("samples: disable CONFIG_SAMPLES for UML") used
      a big hammer to fix the build errors under the samples/ directory.
      Only some samples actually include uapi headers from usr/include.
      
      Introduce CONFIG_HEADERS_INSTALL since 'depends on HEADERS_INSTALL' is
      clearer than 'depends on !UML'. If this option is enabled, uapi headers
      are installed before starting directory descending.
      
      I added 'depends on HEADERS_INSTALL' to per-sample CONFIG options.
      This allows UML to compile some samples.
      
      $ make ARCH=um allmodconfig samples/
        [ snip ]
        CC [M]  samples/configfs/configfs_sample.o
        CC [M]  samples/kfifo/bytestream-example.o
        CC [M]  samples/kfifo/dma-example.o
        CC [M]  samples/kfifo/inttype-example.o
        CC [M]  samples/kfifo/record-example.o
        CC [M]  samples/kobject/kobject-example.o
        CC [M]  samples/kobject/kset-example.o
        CC [M]  samples/trace_events/trace-events-sample.o
        CC [M]  samples/trace_printk/trace-printk.o
        AR      samples/vfio-mdev/built-in.a
        AR      samples/built-in.a
      Signed-off-by: default avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      e949f4c2
  26. 08 Mar, 2019 1 commit
  27. 20 Dec, 2018 1 commit
    • Michael Ellerman's avatar
      powerpc/configs: Don't enable PPC_EARLY_DEBUG in defconfigs · 2b874a5c
      Michael Ellerman authored
      This reverts the remains of commit b9ef7d6b ("powerpc: Update
      default configurations").
      
      That commit was proceeded by a commit which added a config option to
      control use of BOOTX for early debug, ie. PPC_EARLY_DEBUG_BOOTX, and
      then the update of the defconfigs was intended to not change behaviour
      by then enabling the new config option.
      
      However enabling PPC_EARLY_DEBUG had other consequences, notably
      causing us to register the udbg console at the end of udbg_early_init().
      
      This means on a system which doesn't have anything that BOOTX can
      use (most systems), we register the udbg console very early but the
      bootx code just throws everything away, meaning early boot messages
      are never printed to the console.
      
      What we want to happen is for the udbg console to only be registered
      later (from setup_arch()) once we've setup udbg_putc, and then all
      early boot messages will be replayed.
      
      Fixes: b9ef7d6b ("powerpc: Update default configurations")
      Reported-by: default avatarTorsten Duwe <duwe@lst.de>
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      2b874a5c
  28. 25 Jan, 2018 1 commit
  29. 20 Sep, 2017 1 commit
  30. 28 Aug, 2017 5 commits