summaryrefslogtreecommitdiff
path: root/sys/modules/uart
AgeCommit message (Collapse)Author
2024-07-15Remove residual blank line at start of MakefileWarner Losh
This is a residual of the $FreeBSD$ removal. MFC After: 3 days (though I'll just run the command on the branches) Sponsored by: Netflix
2023-08-16sys: Remove $FreeBSD$: one-line sh patternWarner Losh
Remove /^\s*#[#!]?\s*\$FreeBSD\$.*$\n/
2022-10-27Stop building FDT-only modules in an ACPI only kernelAndrew Turner
When building a kernel without FDT these modules don't build. As they depend on FDT and don't work with ACPI disable them. Reviewed by: imp, kevans Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D37178
2021-01-07pccard: Remove uart(4) PC Card attachmentWarner Losh
pccard is going away, so remove uart's attachment. Relnotes: Yes
2020-12-26scc(4)/uart(4): Remove obsolete support for Siemens SAB 82532Marius Strobl
It's no longer used since 58aa35d42975c298ca0adba705c042596303c9f5 and r357455 respectively.
2020-07-28- Cleanups related to sparc64 removal.Yoshihiro Takahashi
- Remove remains of sparc64 files. Reviewed by: imp Differential Revision: https://reviews.freebsd.org/D25831 Notes: svn path=/head/; revision=363644
2020-02-03Remove sparc64 kernel supportWarner Losh
Remove all sparc64 specific files Remove all sparc64 ifdefs Removee indireeect sparc64 ifdefs Notes: svn path=/head/; revision=357455
2019-12-22Compile uart_cpu_acpi.c, added in r348195, into uart.ko.Mark Johnston
PR: 242771 MFC after: 3 days Sponsored by: The FreeBSD Foundation Notes: svn path=/head/; revision=356030
2018-08-19add snps IP uart support / genaralize UARTMatt Macy
This is an amalgam of a patch by Doug Ambrisko to generalize uart_acpi_find_device, imp moving the ACPI table to uart_dev_ns8250.c and advice by jhb to work around a bug in the EPYC 3151 BIOS (the BIOS incorrectly marks the serial ports as disabled) Reviewed by: imp MFC after: 8 weeks Differential Revision: https://reviews.freebsd.org/D16432 Notes: svn path=/head/; revision=338074
2018-06-12Add a driver for the BCM2835 Mini-UART as seen on the RPi3Diane Bruce
Reviewed by: andrew Approved by: andrew Differential Revision: https://reviews.freebsd.org/D15684 Notes: svn path=/head/; revision=334997
2018-01-24arm: lpc: Remove supportEmmanuel Vadot
Code hasn't been touch this it's original commit in 2012 beside api changes. Reviewed by: ian Differential Revision: https://reviews.freebsd.org/D13625 Discussed with: freebsd-arm@freebsd.org (no reply) Notes: svn path=/head/; revision=328380
2017-09-11Restore alphabetical order in UART MakefileMarcin Wojtas
Commit r323359 introduced new Marvell UART controller driver and by mistake it broke correct order in the Makefile. Fix this. Reported by: emaste Notes: svn path=/head/; revision=323459
2017-09-09Don't build uart_dev_mvebu unless we're on arm64.Warner Losh
This module is specific to a single Marvel board that we currently only support in 64-bit mode. Remove it from the build otherwise. It likely should be completely removed, but this unbreaks x86 building. Noticed by: sbruno@ Notes: svn path=/head/; revision=323375
2017-09-09Introduce UART driver module for Armada 3700Marcin Wojtas
This patch adds support for UART in Armada 3700 family. It exposes both low-level UART interface, as well as standard driver methods. Submitted by: Patryk Duda <pdk@semihalf.com> Obtained from: Semihalf Sponsored by: Semihalf Differential Revision: https://reviews.freebsd.org/D12250 Notes: svn path=/head/; revision=323359
2017-03-04sys/modules: normalize .CURDIR-relative paths to SRCTOPEnji Cooper
This simplifies make output/logic Tested with: `cd sys/modules; make ALL_MODULES=` on amd64 MFC after: 1 month Sponsored by: Dell EMC Isilon Notes: svn path=/head/; revision=314651
2016-07-28Build ofw_bus_if.h for modules for RISC-V.Ruslan Bukin
Notes: svn path=/head/; revision=303440
2016-07-21Fix the build:Andrew Turner
* Add acpi_if.h to the SRC list in the uart module * Only include new acpi headers when they are needed Obtained from: ABT Systems Ltd MFC after: 1 month Sponsored by: The FreeBSD Foundation Notes: svn path=/head/; revision=303143
2015-11-29Fix make dependUlrich Spörlein
Notes: svn path=/head/; revision=291450
2015-10-21Build ofw_bus_if.h for modules that need it on arm64Ed Maste
Notes: svn path=/head/; revision=289710
2015-07-03Kill MFILES and find things automatically. It turned out to be onlyWarner Losh
lightly used. Find the proper .m file when we depend on *_if.[ch] in the srcs line, with seat-belts for false positive matches. This uses make's path mechanism. A further refinement would be to calculate this once, and then pass the resulting _MPATH to modules submakes. Differential Revision: https://reviews.freebsd.org/D2327 Notes: svn path=/head/; revision=285068
2015-01-03PowerPC also needs ofw_bus_if.h when using FDT.Justin Hibbits
Notes: svn path=/head/; revision=276637
2013-04-22Build uart_dev_lpc.c on arm only. This fixes pc98 build.Yoshihiro Takahashi
Notes: svn path=/head/; revision=249765
2013-04-19Fix the uart(4) module build. Without uart_dev_lpc the module cannot be loaded.Justin Hibbits
Notes: svn path=/head/; revision=249636
2013-03-17In the uart module build ofw_bus_if.h on arm along with sparc64 as LINTAndrew Turner
fails when built locally without it. Notes: svn path=/head/; revision=248411
2013-03-06Fix 'make depend'Ulrich Spörlein
Notes: svn path=/head/; revision=247891
2012-04-18Compensate for the replacement of uart_cpu_{amd64|i386}.c withMarcel Moolenaar
uart_cpu_x86.c Pointy hat: marcel Notes: svn path=/head/; revision=234427
2011-05-14Disconnect sun4v architecture from the three.Attilio Rao
Some files keep the SUN4V tags as a code reference, for the future, if any rewamped sun4v support wants to be added again. Reviewed by: marius Tested by: sbruno Approved by: re Notes: svn path=/head/; revision=221869
2010-08-23MFtbemd:Warner Losh
Use MACHINE_CPUARCH in preference to MACHINE_ARCH. The former is the source code location of the machine, the latter the binary output. In general, we want to use MACHINE_CPUARCH instead of MACHINE_ARCH unless we're tesitng for a specific target. The isn't even moot for i386/amd64 where there's momemntum towards a MACHINE_CPUARCH == x86, although a specific cleanup for that likely would be needed... Notes: svn path=/head/; revision=211690
2010-05-23Correct the path to the MD source so r206569 actually works as intended.Marius Strobl
Notes: svn path=/head/; revision=208462
2010-04-13Only compile in uart_cpu_$MACHINE.c if it exists. I'm not sure howWarner Losh
useful it will be, but we really need to be keying off something other than MACHINE for this anyway since on arm and mips we have lots of these running around (one for each SoC family)... Notes: svn path=/head/; revision=206569
2008-11-22Include the QUICC backend in the kernel module.Marcel Moolenaar
PR: 127120 Notes: svn path=/head/; revision=185188
2006-10-16In sun4v, use the sparc64 version. We haven't used the serial port onJohn Birrell
sun4v yet, so this is a 'best-guess'. Notes: svn path=/head/; revision=163445
2006-03-30o Add scc(4) to the build.Marcel Moolenaar
o Add the scc(4) manpage to the build. o Update the uart(4) manpage to account for scc(4). o Update the uart(4) module build to include support for scc(4). Notes: svn path=/head/; revision=157301
2006-02-24Remove dev/uart/uart_if.m from the default MFILES (in kmod.mk) andMarcel Moolenaar
instead define MFILES appropriately for the uart(4) module build. Notes: svn path=/head/; revision=155966
2004-11-20Stop building uart_dev_i8251.c. It was copied from uart_dev_ns8250.cMarcel Moolenaar
without ever being changed to actually work with an i8251. Nobody is working on this either at the moment, so it's not about to change soon. When the code necessary to support the i8251 is committed, this can be reverted again. Notes: svn path=/head/; revision=137950
2004-11-17o sparc64/isa/isa.c:Marius Strobl
- The claim in the commit log of rev. 1.11 of dev/uart/uart_cpu_sparc64.c etc. that UARTs are the only relevant ISA devices on sparc64 turned out to be false. While there are sparc64 models where UARTs are the only devices on the ISA bus there are in fact also low-cost models where all devices traditionally found on the EBus are hooked up to the ISA bus. There are also models that use a mix between EBus and ISA devices with things like an AT keyboard controller and other rather interesting devices that we might want to support in the futute hook up to the ISA bus. In order to not need to add sparc64 specific device_identify methods to all of the respective ISA drivers and also not add OFW specific code to the common ISA code make the sparc64 ISA bus code fake up PnP devices so most ISA drivers probe their devices without further changes. Unfortunately Sun doesn't adhere to the ISA bindings defined in IEEE 1275-1994 for the properties of most of the ISA devices which would allow to obtain the vendor and logical IDs from their properties. So we we just use a simple table which maps the name properties to PnP IDs. This could be done in a more sophisticated way but I courrently don't see the need for this. [1] - Add the children with fully mapped and specified resources (in the OFW sense) similar to what is done in the EBus code for the IRQ resources of the children as adjusting the resources and the resource list entries respectively in isa_alloc_resource() as done perviously causes trouble with drivers which use rman_get_start(), pass-through or allocate and release resources multiple times, etc. Adjusting the resources might be better off in a bus_activate_resource method but the common ISA code currently doesn't allow for an isa_activate_resource(). [2] With this change: - ppbus(4) and lpt(4) attach and work (modulo ECP mode, which requires real ISADMA code but it currently only consists of stubs on sparc64). - atkbdc(4) and atkbdc(4) attach, no further testing done. - fdc(4) itself attaches but causes a hang while attaching fd0 also when is DMA disabled, further work in fdc(4) is required here as e.g. fd0 uses the address of fd1 on sparc64 (not sure if sparc64 supports more than one floppy drive at all). All of these drivers previously caused panics in the sparc64 ISA code. - Minor changes, e.g. use __FBSDID, remove a dupe word in a comment and declare one global variable which isn't used outside of isa.c static. o dev/uart/uart_cpu_sparc64.c and modules/uart/Makefile: - Remove the code for registering the UARTs on the ISA bus from the sparc64 uart_cpu_identify() again and rely on probing them via PnP. Original idea by: tmm [1] No objections by: tmm [1], [2] Notes: svn path=/head/; revision=137819
2004-08-14- Introduce an uart_cpu_identify() which is implemented in uart_cpu_<arch>.cMarius Strobl
and that can be used as an identify function for all kinds of busses on a certain platform. Expect for sparc64 these are only stubs right now. [1] - For sparc64, add code to its uart_cpu_identify() for registering the on- board ISA UARTs and their resources based on information obtained from Open Firmware. It would be better if this would be done in the OFW ISA code. However, due to the common FreeBSD ISA code and PNP-IDs not always being present in the properties of the ISA nodes there seems to be no good way to implement that. Therefore special casing UARTs as the sole really relevant ISA devices on sparc64 seemed reasonable. [2] Approved by: marcel Discussed with: marcel [1], tmm [2] Tested by: make universe Notes: svn path=/head/; revision=133735
2004-08-12- Introduce an ofw_bus kobj-interface for retrieving the OFW node and aMarius Strobl
subset ("compatible", "device_type", "model" and "name") of the standard properties in drivers for devices on Open Firmware supported busses. The standard properties "reg", "interrupts" und "address" are not covered by this interface because they are only of interest in the respective bridge code. There's a remaining standard property "status" which is unclear how to support properly but which also isn't used in FreeBSD at present. This ofw_bus kobj-interface allows to replace the various (ebus_get_node(), ofw_pci_get_node(), etc.) and partially inconsistent (central_get_type() vs. sbus_get_device_type(), etc.) existing IVAR ones with a common one. This in turn allows to simplify and remove code-duplication in drivers for devices that can hang off of more than one OFW supported bus. - Convert the sparc64 Central, EBus, FHC, PCI and SBus bus drivers and the drivers for their children to use the ofw_bus kobj-interface. The IVAR- interfaces of the Central, EBus and FHC are entirely replaced by this. The PCI bus driver used its own kobj-interface and now also uses the ofw_bus one. The IVARs special to the SBus, e.g. for retrieving the burst size, remain. Beware: this causes an ABI-breakage for modules of drivers which used the IVAR-interfaces, i.e. esp(4), hme(4), isp(4) and uart(4), which need to be recompiled. The style-inconsistencies introduced in some of the bus drivers will be fixed by tmm@ in a generic clean-up of the respective drivers later (he requested to add the changes in the "new" style). - Convert the powerpc MacIO bus driver and the drivers for its children to use the ofw_bus kobj-interface. This invloves removing the IVARs related to the "reg" property which were unused and a leftover from the NetBSD origini of the code. There's no ABI-breakage caused by this because none of these driver are currently built as modules. There are other powerpc bus drivers which can be converted to the ofw_bus kobj-interface, e.g. the PCI bus driver, which should be done together with converting powerpc to use the OFW PCI code from sparc64. - Make the SBus and FHC front-end of zs(4) and the sparc64 eeprom(4) take advantage of the ofw_bus kobj-interface and simplify them a bit. Reviewed by: grehan, tmm Approved by: re (scottl) Discussed with: tmm Tested with: Sun AX1105, AXe, Ultra 2, Ultra 60; PPC cross-build on i386 Notes: svn path=/head/; revision=133589
2004-07-10Build uart_dbg.c for remote GDB support.Marcel Moolenaar
Notes: svn path=/head/; revision=131946
2004-05-26Move to generating pccarddevs.h on the fly, both for the kernel andWarner Losh
the modules. Also generate usbdevs.h automatically now, but a non-kernel file is stopping that at the moment. Notes: svn path=/head/; revision=129740
2004-03-20Add uart_subr.cMarcel Moolenaar
Notes: svn path=/head/; revision=127245
2003-09-17Only build the ebus driver on sparc64. It includes a header directlyMarcel Moolenaar
from the sparc64 subtree, which breaks building non-sparc64 platforms in the event the sparc64 subtree does not exist. The problem is specific to the module, because non-module builds are affected by the presence or absence of "device ebus" in the kernel configuration. PR: kern/56869 Notes: svn path=/head/; revision=120145
2003-09-15Sort: build uart_bus_pccard.c before uart_bus_pci.c.Marcel Moolenaar
Notes: svn path=/head/; revision=120085
2003-09-14Add uart pccard bus attachment,based on sio_pccard.c .Takanori Watanabe
Wrote at: Hakone. Powered by: Warner Losh's scotch whisky. Tested by: nork Notes: svn path=/head/; revision=120056
2003-09-07Now that PC98 has it's own MD file, use uart_cpu_${MACHINE}.c andMarcel Moolenaar
not uart_cpu_${MACHINE_ARCH}.c. Notes: svn path=/head/; revision=119831
2003-09-07add i8251Warner Losh
Notes: svn path=/head/; revision=119823
2003-09-06Hook-up the uart(4) driver to the build. For a detailed descriptionMarcel Moolenaar
of what uart(4) is and/or is not see the initial commit log of one of the files in sys/dev/uart (or see share/man/man4/uart.4). Note that currently pc98 shares the MD file with i386. This needs to change when pc98 support is fleshed-out to properly support the various UARTs. A good example is sparc64 in this respect. We build uart(4) as a module on all platforms. This may break the ppc port. That depends on whether they do actually build modules. To use uart(4) on alpha, one must use the NO_SIO option. Notes: svn path=/head/; revision=119816
generated by cgit v1.2.3 (git 2.25.1) at 2026-01-21 07:52:30 +0000