Re: i2c and indirect vs. direct config

[Jason Thorpe <thorpej%me.com@localhost>]

On Jun 5, 2018, at 1:19 AM, Paul Goyette <paul%whooppee.com@localhost> wrote:

I think I like this approach.


But I'm unclear on how/where the i2c-SMBus device's property-list gets
set in the first place.

For modular drivers loaded from the file-system after the system is up
and running, there is a module prop-list, but I don't think it gets
"hooked in" to the device's prop-list.

For non-modular (built-in) drivers on fdt-based platforms, I suppose
that the fdt stuff could provide the prop-list.  (Does it?)  But on
non-fdt systems the prop-list would have to be specified somehow,
presumably at "build" time, which to me implies something in the
config language?

Or maybe there's some other mechanism(s) of which I'm not aware?

Or maybe I'm just blind (or more likely, clueless)!

No, it’s just that I didn’t include that particular patch yet :-)

Right now, the only good hook we have for this is device_register(), which is a MD function used to insert it self into the device attachment process.  It was originally devised by cgd@ for finding the boot device, but it’s also used to attach platform-specific properties to MI driver instances, for example on-board Ethernet addresses on embedded boards (certainly for the ones that pre-date FDT).

Certainly for this purpose, it’s not perfect — I’d rather attach these properties in the imcsmb driver itself… but as I lamented earlier in the thread, our auto configuration system doesn’t give the parent access to the child device_t until after the child is fully attached.  One of these days, maybe we should change that (I also think that we should probably change the “match” routine’s signature to also provide a proto-device_t to which properties may be attached, and that was part of the thinking when I originally made the change to separate “struct device” from the driver’s private-data).

Anyway, I haven’t even compiled this patch yet, but at least you’ll get the idea…

Index: x86_autoconf.c
===================================================================
RCS file: /cvsroot/src/sys/arch/x86/x86/x86_autoconf.c,v
retrieving revision 1.76
diff -u -p -r1.76 x86_autoconf.c
--- x86_autoconf.c	9 Nov 2017 01:02:56 -0000	1.76
+++ x86_autoconf.c	5 Jun 2018 12:56:05 -0000
@@ -54,6 +54,8 @@ __KERNEL_RCSID(0, "$NetBSD: x86_autoconf
 #include <machine/bootinfo.h>
 #include <machine/pio.h>
 
+#include <dev/i2c/i2cvar.h>
+
 #include "acpica.h"
 #include "wsdisplay.h"
 
@@ -547,6 +549,36 @@ device_register(device_t dev, void *aux)
 {
 	device_t isaboot, pciboot;
 
+	/*
+	 * The Intel Integrated Memory Controller has a built-in i2c
+	 * controller that's rather limited in capability; it is intended
+	 * only for reading memory module EERPOMs and sensors.
+	 */
+	if (device_is_a(dev, "iic") &&
+	    device_is_a(dev->dv_parent, "imcsmb")) {
+		static const char *imcsmb_device_whitelist[] = {
+			"spdmem",
+			"sdtemp",
+			NULL;
+		};
+		prop_array_t whitelist = prop_array_create();
+		prop_dictionary_t props = device_properties(dev);
+		int i;
+
+		for (i = 0; imcsmb_device_whitelist[i] != NULL; i++) {
+			prop_string_t pstr = prop_string_create_cstring_nocopy(
+			    imcsmb_device_whitelist[i]);
+			(void) prop_array_add(whitelist, pstr);
+			prop_object_release(pstr);
+		}
+		(void) prop_dictionary_set(props,
+					   I2C_PROP_INDIRECT_DEVICE_WHITELIST,
+					   whitelist);
+		(void) prop_dictionary_set_cstring_nocopy(props,
+					   I2C_PROP_INDIRECT_PROBE_STRATEGY,
+					   I2C_PROBE_STRATEGY_NONE);
+	}
+
 	device_acpi_register(dev, aux);
 
 	isaboot = device_isa_register(dev, aux);

-- thorpej