src/sys/modules/i2c, branch releng/12.2

MFC r358818:

2020-03-29T23:38:55Z

acpi: Fix stalled value returned by acpi_get_device() after device deletion Newbus device reference attached to ACPI handle is not cleared when newbus device is deleted with devctl(8) delete command. Fix that with calling of AcpiDetachData() from "child_deleted" bus method like acpi_pci driver does. MFC r358819: acpi: Export functions required by upcoming acpi_iicbus driver. MFC r358820: iicbus(4): Add support for ACPI-based children enumeration When iicbus is attached as child of Designware I2C controller it scans all ACPI nodes for "I2C Serial Bus Connection Resource Descriptor" described in section 19.6.57 of ACPI specs. If such a descriptor is found, I2C child is added to iicbus, it's I2C address, IRQ resource and ACPI handle are added to ivars. Existing ACPI bus-hosted child is deleted afterwards. The driver also installs so called "I2C address space handler" which is disabled by default as nontested. Set hw.iicbus.enable_acpi_space_handler loader tunable to 1 to enable it. Reviewed by: markj Differential Revision: https://reviews.freebsd.org/D22901

MFC r356086, r356278, r356294, r356519, r356521-r356522, r356525-r356526

2020-01-17T17:57:34Z

r356086: Add comments to a couple i2c device lines in NOTES. r356278: Add support for i2c bus mux hardware. An i2c bus can be divided into segments which can be selectively connected and disconnected from the main bus. This is usually done to enable using multiple slave devices having the same address, by isolating the devices onto separate bus segments, only one of which is connected to the main bus at once. There are several types of i2c bus muxes, which break down into two general categories... - Muxes which are themselves i2c slaves. These devices respond to i2c commands on their upstream bus, and based on those commands, connect various downstream buses to the upstream. In newbus terms, they are both a child of an iicbus and the parent of one or more iicbus instances. - Muxes which are not i2c devices themselves. Such devices are part of the i2c bus electrically, but in newbus terms their parent is some other bus. The association with the upstream bus must be established by separate metadata (such as FDT data). In both cases, the mux driver has one or more iicbus child instances representing the downstream buses. The mux driver implements the iicbus_if interface, as if it were an iichb host bridge/i2c controller driver. It services the IO requests sent to it by forwarding them to the iicbus instance representing the upstream bus, after electrically connecting the upstream bus to the downstream bus that hosts the i2c slave device which made the IO request. The net effect is automatic mux switching which is transparent to slaves on the downstream buses. They just do i2c IO they way they normally do, and the bus is electrically connected for the duration of the IO and then idled when it is complete. The existing iicbus_if callback() method is enhanced so that the parameter passed to it can be a struct which contains a device_t for the requesting bus and slave devices. This change is done by adding a flag that indicates the extra values are present, and making the flags field the first field of a new args struct. If the flag is set, the iichb or mux driver can recast the pointer-to-flags into a pointer-to-struct and access the extra fields. Thus abi compatibility with older drivers is retained (but a mux cannot exist on the bus with the older iicbus driver in use.) A new set of core support routines exists in iicbus.c. This code will help implement mux drivers for any type of mux hardware by supplying all the boilerplate code that forwards IO requests upstream. It also has code for parsing metadata and instantiating the child iicbus instances based on it. Two new hardware mux drivers are added. The ltc430x driver supports the LTC4305/4306 mux chips which are controlled via i2c commands. The iic_gpiomux driver supports any mux hardware which is controlled by manipulating the state of one or more gpio pins. Test Plan Tested locally using a variety of mux'd bus configurations involving both ltc4305 and a homebrew gpio-controlled mux. Tested configurations included cascaded muxes (unlikely in the real world, but useful to prove that 'it all just works' in terms of the automatic switching and upstream forwarding of IO requests). r356294: Explicitly include sys/rman.h instead of relying on getting it via some other header. r356519: Ensure any reserved gpio pins get released if an early exit is taken from the attach function. r356521: Init sc->maxbus to -1, not 0. It represents the highest array index that has a non-NULL child bus stored in it, so the "none" value can't be zero since that's a valid array index. Also, when adding all possible buses because there is no specific per-bus config, there's no need to reset sc->maxbus on each loop iteration, it can be set once after the loop. r356522: Change some KASSERT to device_printf + return EINVAL. There's no need to bring the whole kernel down due to a configuration error detected when a module is loaded, it suffices to just not attach the device. r356525: Split the code to find and add iicbus children out to its own function. Move the decision to take an early exit from that function after adding children based on FDT data into the #ifdef FDT block, so that it doesn't offend coverity's notion of how the code should be written. (What's the point of compilers optimizing away dead code if static analyzers won't let you use the feature in conjuction with an #ifdef block?) Reported by: coverity via vangyzen@ r356526: Remove some trailing whitespace; no functional changes.

MFC r355738:

2019-12-22T18:11:57Z

Include ofw_bus_if.h in SRCS only on systems configured with the FDT option.

MFC r350303: enable ig4_acpi on aarch64

2019-09-16T12:54:44Z

The already-listed APMC0D0F ID belongs to the Ampere eMAG aarch64 platform, but ACPI support was not even built on aarch64. Submitted by: Greg V

MFC r350591, r350971, r351724

2019-09-05T16:37:10Z

r350591: Add a driver for Texas Instruments ADS101x/ADS111x i2c ADC chips. Instances of the device can be configured using hints or FDT data. Interfaces to reconfigure the chip and extract voltage measurements from it are available via sysctl(8). r350971: Fix the driver name in ads111x.4, and hook the manpage up to the build. The driver was originally written with the name ads1115, but at the last minute it got renamed to ads111x to reflect its support for many related chips, but I forgot to update the manpage to match the renaming before committing it all. r351724: Fix the name of the devicetree bindings document file cited in the manpage.

Remove jedec_ts(4)

2018-08-01T08:24:34Z

The jedec_ts(4) driver has been marked as deprecated in stable/11, and is now being removed from -HEAD. Add a notice in UPDATING, and update the few remaining references (regarding jedec_dimm(4)'s compatibility and history) to reflect the fact that jedec_ts(4) is now deleted. Reviewed by: avg Relnotes: yes Differential Revision: https://reviews.freebsd.org/D16537

Add opt_platform.h for several modules that have #ifdef FDT in the source.

2018-04-01T18:22:24Z

Submitted by: Andre Albsmeier

Build the ds1672 driver as a module. Add a detach() to unregister the rtc.

2018-03-06T02:30:34Z

Build iicbus/rtc8583 as a module.

2018-03-04T21:06:21Z

imcsmb(4): Intel integrated Memory Controller (iMC) SMBus controller driver

2018-03-03T01:53:51Z

imcsmb(4) provides smbus(4) support for the SMBus controller functionality in the integrated Memory Controllers (iMCs) embedded in Intel Sandybridge- Xeon, Ivybridge-Xeon, Haswell-Xeon, and Broadwell-Xeon CPUs. Each CPU implements one or more iMCs, depending on the number of cores; each iMC implements two SMBus controllers (iMC-SMBs). *** IMPORTANT NOTE *** Because motherboard firmware or the BMC might try to use the iMC-SMBs for monitoring DIMM temperatures and/or managing an NVDIMM, the driver might need to temporarily disable those functions, or take a hardware interlock, before using the iMC-SMBs. Details on how to do this may vary from board to board, and the procedure may be proprietary. It is strongly suggested that anyone wishing to use this driver contact their motherboard vendor, and modify the driver as described in the manual page and in the driver itself. (For what it's worth, the driver as-is has been tested on various SuperMicro motherboards.) Reviewed by: avg, jhb MFC after: 1 week Relnotes: yes Sponsored by: Panasas Differential Revision: https://reviews.freebsd.org/D14447 Discussed with: avg, ian, jhb Tested by: allanjude (previous version), Panasas