en Copyright 2015 Java http://172.16.0.5:8080/history/freebsd-13.1/sys/modules/esp/Makefile#8f11c997 - Cleanups related to sparc64 removal.- Remove remains of sparc64 files.Reviewed by: impDifferential Revision: https://reviews.freebsd.org/D25831 List of files: /freebsd-13.1/sys/modules/esp/Makefile Tue, 28 Jul 2020 10:58:37 +0000 Yoshihiro Takahashi <nyan@FreeBSD.org> http://172.16.0.5:8080/history/freebsd-13.1/sys/modules/esp/Makefile#58aa35d4 Remove sparc64 kernel supportRemove all sparc64 specific filesRemove all sparc64 ifdefsRemovee indireeect sparc64 ifdefs List of files: /freebsd-13.1/sys/modules/esp/Makefile Mon, 03 Feb 2020 17:35:11 +0000 Warner Losh <imp@FreeBSD.org> http://172.16.0.5:8080/history/freebsd-13.1/sys/modules/esp/Makefile#193d9e76 sys/modules: normalize .CURDIR-relative paths to SRCTOPThis simplifies make output/logicTested with: `cd sys/modules; make ALL_MODULES=` on amd64MFC after: 1 monthSponsored by: Dell EMC Isilon List of files: /freebsd-13.1/sys/modules/esp/Makefile Sat, 04 Mar 2017 10:10:17 +0000 Enji Cooper <ngie@FreeBSD.org> http://172.16.0.5:8080/history/freebsd-13.1/sys/modules/esp/Makefile#a9ab459b Add a PCI front-end to esp(4) allowing it to support AMD Am53C974 andreplace amd(4) with the former in the amd64, i386 and pc98 GENERIC kernelconfiguration files. Besides duplicating functionality, amd(4), whichpreviously also supported the AMD Am53C974, unlike esp(4) is no longermaintained and has accumulated enough bit rot over time to always causea panic during boot as long as at least one target is attached to it(see PR 124667).PR: 124667Obtained from: NetBSD (based on)MFC after: 3 days List of files: /freebsd-13.1/sys/modules/esp/Makefile Tue, 01 Nov 2011 21:26:57 +0000 Marius Strobl <marius@FreeBSD.org> http://172.16.0.5:8080/history/freebsd-13.1/sys/modules/esp/Makefile#07f35f4b Don't build unused SBus front-ends for sun4v, don't build EBus front-endswhich are also likely to be irrelevant for sun4v (there's no SBus on sun4vand only some EBus devices). While at it fix some style bugs according tostyle.Makefile(5) where appropriate.MFC after: 3 days List of files: /freebsd-13.1/sys/modules/esp/Makefile Sun, 04 May 2008 14:59:25 +0000 Marius Strobl <marius@FreeBSD.org> http://172.16.0.5:8080/history/freebsd-13.1/sys/modules/esp/Makefile#65fb49a9 - Try to not leak resources in the attach functions of the esp(4) SBus front-end and the LSI64854 and NCR53C9x code in case one of these functions fails. Add detach functions to these parts and make esp(4) detachable.- Revert rev. 1.7 of esp_sbus.c, since rev. 1.34 of sbus.c the clockfreq IVAR defaults to the per-child values.- Merge ncr53c9x.c rev. 1.111 from NetBSD (partial): On reset, clear state flags and the msgout queue. In NetBSD code to notify the upper layer (i.e. CAM in FreeBSD) on reset was also added with this revision. This is believed to be not necessary in FreeBSD and was not merged. This makes ncr53c9x.c to be in sync with NetBSD up to rev. 1.114.- Conditionalize the LSI64854 support on sbus(4) only instead of sbus(4) and esp(4) as it's also required for the 'dma', 'espdma' and 'ledma' busses/devices as well as the 'SUNW,bpp' device (printer port) which all hang off of sbus(4).- Add a driver for the 'dma', 'espdma' and 'ledma' (pseudo-)busses/ devices. These busses and devices actually represent the LSI64854 DMA engines for the ESP SCSI and LANCE Ethernet controllers found on the SBus of Ultra 1 and SBus add-on cards. With 'espdma' and 'ledma' the 'esp' and 'le' devices hang off of the respective DMA bus instead of directly from the SBus. The 'dma' devices are either also used in this manner or on some add-on cards also as a companion device to an 'esp' device which also hangs off directly from the SBus. With the latter variant it's a bit tricky to glue the DMA engine to the core logic of the respective 'esp' device. With rev. 1.35 of sbus.c we are however guaranteed that such a 'dma' device is probed before the respective 'esp' device which simplifies things a lot. [1]- In the esp(4) SBus front-end read the part-unique ID code of Fast-SCSI capable chips the right way. This fixes erroneously detecting some chips as FAS366 when in fact they are not. Add explicit checks for the FAS100A, FAS216 and FAS236 variants instead treating all of these as ESP200. That way we can correctly set the respective Fast-SCSI config bits instead of driving them out of specs. This includes adding the FAS100A and FAS236 variants to the NCR53C9x core code. We probably still subsume some chip variants as ESP200 while in fact they are another variant which however shouldn't really matter as this will only happen when these chips are driven at 25MHz or less which implies not being able to run Fast-SCSI. [3]- Add a workaround to the NCR53C9x interrupt handler which ignores the stray interrupt generated by FAS100A when doing path inquiry during boot and which otherwiese would trigger a panic.- Add support for the 'esp' devices hanging off of a 'dma' or 'espdma' busses or which are companions of 'dma' devices to esp(4). In case of the variants that hang off of a DMA device this is a bit hackish as esp(4) then directly uses the softc of the respective parent to talk to the DMA engine. It might make sense to add an interface for this in order to implement this in a cleaner way however it's not yet clear how the requirements for the LANCE Ethernet controllers are and the hack works for now. [2] This effectively adds support for the onboard SCSI controller in Ultra 1 as well as most of the ESP-based SBus add-on cards to esp(4). With this the code for supporting the Performance Technologies SBS430 SBus SCSI add-on cards is also largely in place the remaining bits were however omitted as it's unclear from the NetBSD how to couple the DMA engine and the core logic together for these cards.Obtained from: OpenBSD [1]Obtained from: NetBSD [2]Clue from: BSD/OS [3]Reviewed by: scottl (earlier version)Tested with: FSBE/S add-on card (FAS236), SSHA add-on card (ESP100A), Ultra 1 (onboard FAS100A), Ultra 2 (onboard FAS366) List of files: /freebsd-13.1/sys/modules/esp/Makefile Thu, 19 May 2005 14:51:10 +0000 Marius Strobl <marius@FreeBSD.org> http://172.16.0.5:8080/history/freebsd-13.1/sys/modules/esp/Makefile#acad3381 Fix paths after repocopies done by scottlReviewed by: mariusOK'ed by: scottl List of files: /freebsd-13.1/sys/modules/esp/Makefile Wed, 10 Nov 2004 14:09:52 +0000 Tom Rhodes <trhodes@FreeBSD.org> http://172.16.0.5:8080/history/freebsd-13.1/sys/modules/esp/Makefile#26280d88 - Introduce an ofw_bus kobj-interface for retrieving the OFW node and a 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, tmmApproved by: re (scottl)Discussed with: tmmTested with: Sun AX1105, AXe, Ultra 2, Ultra 60; PPC cross-build on i386 List of files: /freebsd-13.1/sys/modules/esp/Makefile Thu, 12 Aug 2004 17:41:33 +0000 Marius Strobl <marius@FreeBSD.org> http://172.16.0.5:8080/history/freebsd-13.1/sys/modules/esp/Makefile#7ad8bf41 Fix typo that prevents esp_sbus.c and lsi64854.c from being built on sparc64. List of files: /freebsd-13.1/sys/modules/esp/Makefile Thu, 10 Jun 2004 13:02:29 +0000 Marius Strobl <marius@FreeBSD.org> http://172.16.0.5:8080/history/freebsd-13.1/sys/modules/esp/Makefile#c31d0cf7 Port the NetBSD esp(4) driver. This only includes the sbus front-end, soits primary use is for the FEPS/FAS366 SCSI found in Sun Ultra 1e and 2machines. Once the pci front-end is ported, this driver can replace theamd(4) driver.The code as-is is fairly stable. I've disabled tagged-queueing until I canfigure out a corruption bug related to it. I'm importing it now so thatpeople with these machines can (finally) stop netbooting and report bugsbefore 5.3. List of files: /freebsd-13.1/sys/modules/esp/Makefile Thu, 10 Jun 2004 05:11:39 +0000 Scott Long <scottl@FreeBSD.org>