src/sys/dev/ofw, branch releng/12.2

MFC r346332:

2020-06-16T20:22:56Z

ofw_graph: Add functions for graph bindings Those functions are helpers to work on graph bindings. graphs are mostly use with video related devices. See https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/graph.txt?id=4436a3711e3249840e0679e92d3c951bcaf25515 Differential Revision: https://reviews.freebsd.org/D19877

MFC r346645, r346664, r346687, r347387, r347836, r347088, 347089, r346956,

2020-05-01T09:46:27Z

r346957, r346958, r347088, r347089, r347385, r353938, r350570, r350572 and r350573: Implement full bus_dma(9) support in the LinuxKPI and pull in all dependencies. Bump FreeBSD version to force recompilation of external modules. Sponsored by: Mellanox Technologies

MFC r360051: tty: convert tty_lock_assert to tty_assert_locked

2020-04-24T13:31:22Z

A later change, currently being iterated on in D24459, will in-fact change the lock type to an sx so that TTY drivers can sleep on it if they need to. Committing this ahead of time to make the review in question a little more palatable. tty_lock_assert() is unfortunately still needed for now in two places to make sure that the tty lock has not been recursed upon, for those scenarios where it's supplied by the TTY driver and possibly a mutex that is allowed to recurse.

MFC r355214, r355239, r355274, r355276-r355277, r355295, r355298

2019-12-07T17:10:03Z

r355214: Ignore "gpio-hog" nodes when instantiating ofw_gpiobus children. Also, in ofw_gpiobus_probe() return BUS_PROBE_DEFAULT rather than 0; we are not the only possible driver to handle this device, we're just slightly better than the base gpiobus (which probes at BUS_PROBE_GENERIC). In the time since this code was first written, the gpio controller bindings aquired the concept of a "hog" node which could be used to preset one or more gpio pins as input or output at a specified level. This change doesn't fully implement the hogging concept, it just filters out hog nodes when instantiating child devices by scanning for child nodes in the fdt data. The whole concept of having child nodes under the controller node is not supported by the standard bindings, and appears to be a freebsd extension, probably left over from the days when we had no support for cross-tree phandle references in the fdt data. r355239: Add an OFWBUS_PNP_INFO() macro for devices that hang directly off the root ofwbus. Also, apply some style(9) whitespace fixing to the SIMPLEBUS_PNP_INFO() macro (no functional change). r355274: Move most of the gpio_pin_* functions from ofw_gpiobus.c to gpiobus.c so that they can be used by drivers on non-FDT-configured systems. Only the functions related to acquiring pins by parsing FDT data remain in ofw_gpiobus. Also, add two new functions for acquiring gpio pins based on child device_t and index, or on the bus device_t and pin number. And finally, defer reserving pins for gpiobus children until they acquire the pin, rather than reserving them as soon as the child is added (before it's even known whether the child will attach). This will allow drivers configured with hints (or any other mechanism) to use the same code as drivers configured via FDT data. Until now, a hinted driver and an FDT driver had to be two completely different sets of code, because hinted drivers could only use gpiobus calls to manipulate pins, while fdt-configured drivers could not use that API (due to not always being children of the bus that owns the pins) and had to use the newer gpio_pin_xxxx() functions. Now drivers can be written in the more traditional form, where most of the code is shared and only the resource acquisition code at attachment time changes. r355276: Rewrite gpioiic(4) to use the gpio_pin_* API, and to conform to the modern FDT bindings document for gpio-i2c devices. Using the gpio_pin_* functions to acquire/release/manipulate gpio pins removes the constraint that both gpio pins must belong to the same gpio controller/bank, and that the gpioiic instance must be a child of gpiobus. Removing those constraints allows the driver to be fully compatible with the modern dts bindings for a gpio bitbanged i2c bus. For hinted attachment, the two gpio pins still must be on the same gpiobus, and the device instance must be a child of that bus. This preserves compatibility for existing installations that have use gpioiic(4) with hints. r355277: Fix leading whitespace (spaces->tabs) in comments; no functional change. r355295: Remove "all rights reserved" from copyright after getting a response from Luiz that he also was not intentionally asserting that right, it was already there when he added his name. r355298: Do not initialize the flags field in struct gpiobus_pin from the flags in struct gpio_pin. It turns out these two sets of flags are completely unrelated to each other. Also, update the comment for GPIO_ACTIVE_LOW to reflect the fact that it does get set, somewhat unobviously, by code that parses FDT data. The bits from the FDT cell containing flags are just copied to gpiobus_pin.flags, so there's never any obvious reference to the symbol GPIO_ACTIVE_LOW being stored into the flags field.

MFC r350229-r350230, r350408, r350410, r350673-r350674

2019-08-10T13:50:15Z

r350229: arm: ti: Get the hwmods property from the parent node Since the Linux 5.0 dts the ti,hwmods property is on the parent ti.sysc node. r350230: arm: ti: Add a driver for ti,sysc bus ti,sysc is a simple-bus like driver. Add a driver for it so child nodes can attach. r350408: arm: ti: Get the hwmods property either from the node or the parent r350229 changed the code to lookup the ti,hwmods property in the parent as it's now like that in the DTS from >= Linux 5.0, allow the property to be also in the node itself so we can boot with an older DTB. Reported by: "Dr. Rolf Jansen" r350410: arm: ti: cpsw: Check the new slave node address Since DTS from >= Linux 5.0 the slave address are relative to the parent node address and aren't the full ones. Check both so the cpsw driver can find the phy id. r350673: arm: dts: am33xx: Fix the region for uart0 The region for uart0 is declared to be 0x2000 in size but the parent node only declare 0x1000. As the parent only declare a size of 0x1000 in the ranges for it's children this cause the device to not be mappable. https://patchwork.kernel.org/patch/11056769/ r350674: ofw: ofw_reg_to_paddr: Use a 256 static array for the cell Some hardware needs more than 32, bump this value. We cannot use the _alloc for of getencprop as this function is called too early in the boot before pmap is initialized and we only have 2k of stack when cninit is called. Discussed with: ian

MFC r348169-r348170, r348172-r348173, r348183-r348184

2019-06-23T16:16:55Z

r348169: Define macros making it easier to define bus-specific pnpinfo for FDT systems. Pnpinfo is bus-specific and requires the bus name. The FDTCOMPAT_PNP_INFO() macro makes it easier to define new FDT-based pnpinfo for busses other than simplebus. Differential Revision: https://reviews.freebsd.org/D20382 r348170: Add pnpinfo for icee(4) on fdt systems. r348172: Use the new FDTCOMPAT_PNP_INFO() macro to define SPIBUS_FDT_PNP_INFO(). Also rename SPIBUS_PNP_INFO -> SPIBUS_FDT_PNP_INFO because there could be other kinds of pnpinfo for other (non-fdt) bus attachments. r348173: Rename IICBUS_FDT_PNPINFO -> IICBUS_FDT_PNP_INFO because all the other existing pnpinfo-related macros right now use PNP_INFO, not PNPINFO. r348183: Add pnpinfo. r348184: Add pnpinfo to all i2c drivers that have FDT compat data.

Reapply, with minor tweaks, r338025, from the original commit:

2018-09-26T17:12:14Z

Remove unused and easy to misuse PNP macro parameter Inspired by r338025, just remove the element size parameter to the MODULE_PNP_INFO macro entirely. The 'table' parameter is now required to have correct pointer (or array) type. Since all invocations of the macro already had this property and the emitted PNP data continues to include the element size, there is no functional change. Mostly done with the coccinelle 'spatch' tool: $ cat modpnpsize0.cocci @normaltables@ identifier b,c; expression a,d,e; declarer MODULE_PNP_INFO; @@ MODULE_PNP_INFO(a,b,c,d, -sizeof(d[0]), e); @singletons@ identifier b,c,d; expression a; declarer MODULE_PNP_INFO; @@ MODULE_PNP_INFO(a,b,c,&d, -sizeof(d), 1); $ rg -l MODULE_PNP_INFO -- sys | \ xargs spatch --in-place --sp-file modpnpsize0.cocci (Note that coccinelle invokes diff(1) via a PATH search and expects diff to tolerate the -B flag, which BSD diff does not. So I had to link gdiff into PATH as diff to use spatch.) Tinderbox'd (-DMAKE_JUST_KERNELS). Approved by: re (glen)

Back out r338035 until Warner is finished churning GSoC PNP patches

2018-08-19T00:46:22Z

I was not aware Warner was making or planning to make forward progress in this area and have since been informed of that. It's easy to apply/reapply when churn dies down.

Remove unused and easy to misuse PNP macro parameter

2018-08-19T00:22:21Z

Inspired by r338025, just remove the element size parameter to the MODULE_PNP_INFO macro entirely. The 'table' parameter is now required to have correct pointer (or array) type. Since all invocations of the macro already had this property and the emitted PNP data continues to include the element size, there is no functional change. Mostly done with the coccinelle 'spatch' tool: $ cat modpnpsize0.cocci @normaltables@ identifier b,c; expression a,d,e; declarer MODULE_PNP_INFO; @@ MODULE_PNP_INFO(a,b,c,d, -sizeof(d[0]), e); @singletons@ identifier b,c,d; expression a; declarer MODULE_PNP_INFO; @@ MODULE_PNP_INFO(a,b,c,&d, -sizeof(d), 1); $ rg -l MODULE_PNP_INFO -- sys | \ xargs spatch --in-place --sp-file modpnpsize0.cocci (Note that coccinelle invokes diff(1) via a PATH search and expects diff to tolerate the -B flag, which BSD diff does not. So I had to link gdiff into PATH as diff to use spatch.) Tinderbox'd (-DMAKE_JUST_KERNELS).

ofw_cpu: Add support for getting cpu clock via clock property

2018-07-31T20:50:50Z

Nominal Mhz is either expressed via the clock-frequency property or can be get via the clock property that holds the cpu clock. Add support for the later. Reviewed by: nwhitehorn Differential Revision: https://reviews.freebsd.org/D16346