On Wed, Oct 16, 2013 at 12:47 AM, Rafael J. Wysocki <rjw@xxxxxxx> wrote: > On Tuesday, October 15, 2013 04:31:43 PM Greg Kroah-Hartman wrote: >> On Tue, Oct 15, 2013 at 11:24:01PM +0200, Rafael J. Wysocki wrote: >> > On Tuesday, October 15, 2013 01:48:29 PM Greg Kroah-Hartman wrote: >> > > On Tue, Oct 15, 2013 at 10:37:02PM +0200, Rafael J. Wysocki wrote: >> > > > On Tuesday, October 15, 2013 07:44:44 PM Zhang Rui wrote: >> > > > > On Mon, 2013-10-14 at 20:47 +0800, Zhang Rui wrote: >> > > > > > On Mon, 2013-10-14 at 14:18 +0300, Jarkko Nikula wrote: >> > > > > > > On 10/14/2013 12:23 PM, Zhang Rui wrote: >> > > > > > > > Hi, >> > > > > > > > >> > > > > > > > On Thu, 2013-10-10 at 17:17 +0300, Jarkko Nikula wrote: >> > > > > > > >> There is a minor fault about ACPI enumerated I2C devices with their modalias >> > > > > > > >> attribute. Now modalias is set by device instance not by hardware ID. >> > > > > > > >> For example "i2c:INTABCD:00", "i2c:INTABCD:01" etc. >> > > > > > > >> >> > > > > > > >> This means each device instance gets different modalias which does match >> > > > > > > >> with generated modules.alias. Currently this is not problem as matching can >> > > > > > > >> happen also with "acpi:INTABCD" modalias. >> > > > > > > >> >> > > > > > > > IMO, this is not the proper fix for the modalias problem because ACPI >> > > > > > > > enumerated I2C device may have compatible ids. >> > > > > > > > Instead, we should export all the compatible ids as the modules alias of >> > > > > > > > the ACPI enumerated I2C device. >> > > > > > > > >> > > > > > > > can you please take a look at the patch I sent out earlier? >> > > > > > > > https://patchwork.kernel.org/patch/3034991/ >> > > > > > > > https://patchwork.kernel.org/patch/3035041/ >> > > > > > > > https://patchwork.kernel.org/patch/3035021/ >> > > > > > > I see. This makes sense as it avoids that same device has two different >> > > > > > > modaliases from both acpi and other subsystem. >> > > > > > > >> > > > > > > How about modalias nodes in sysfs, should they also reflect what is >> > > > > > > matching uvent? >> > > > > > > >> > > > > > good catch, will fix "modalias" as well in next version. >> > > > > >> > > > > Hi, >> > > > > >> > > > > I have a question about the device "uevent" and "modalias" sysfs >> > > > > attributes. >> > > > > what is the relationship between these two? >> > > > > Am I right to say that, if there is the "MODALIAS" field in uevent file, >> > > > > this field must be consistent with the content in "modalias" attribute? >> > > >> > > Well, if it isn't, it's pretty pointless, right? >> > > >> > > > > I checked the code in drivers/base/platform.c, >> > > > > static ssize_t modalias_show(struct device *dev, struct device_attribute >> > > > > *a, >> > > > > char *buf) >> > > > > { >> > > > > struct platform_device *pdev = to_platform_device(dev); >> > > > > int len = snprintf(buf, PAGE_SIZE, "platform:%s\n", pdev->name); >> > > > > >> > > > > return (len >= PAGE_SIZE) ? (PAGE_SIZE - 1) : len; >> > > > > } >> > > > > >> > > > > static int platform_uevent(struct device *dev, struct kobj_uevent_env >> > > > > *env) >> > > > > { >> > > > > struct platform_device *pdev = to_platform_device(dev); >> > > > > int rc; >> > > > > >> > > > > /* Some devices have extra OF data and an OF-style MODALIAS */ >> > > > > rc = of_device_uevent_modalias(dev, env); >> > > > > if (rc != -ENODEV) >> > > > > return rc; >> > > > > >> > > > > add_uevent_var(env, "MODALIAS=%s%s", PLATFORM_MODULE_PREFIX, >> > > > > pdev->name); >> > > > > return 0; >> > > > > } >> > > > > >> > > > > This means that the OF-style MODALIAS is not shown in "modalias" sysfs >> > > > > attribute. >> > > > > is this a bug? >> > > > >> > > > I would consider that as a bug, but I'm not sure what the recommended practice >> > > > is. Greg? >> > > >> > > I have no idea how the OF stuff is working, and honestly, I really have >> > > no wish to ever know anything about it. Especially when it comes to >> > > platform devices/drivers, something that I personally hate and wish >> > > would be deleted. <digress>Greg, I've heard you say that a lot, but regardless of what platform devices/drivers were originally designed for, it is pretty much exactly what we need for non-discoverable memory mapped busses. I've yet to heard a viable alternative proposed. I've heard the proposal of creating new bus types and new driver binding to that bus type for each variant of a non-discoverable memory mapped bus, but I think it is a non-starter. There are too many combinations. What /might/ work to replace the platform_bus_type would be to have a mechanism for drivers to transparently bind to multiple bus types, but then I suspect that it will end up looking an awful lot like the existing platform_bus_type. Probably worth discussing over beer next week</digress> >> > > >> > > So go ask the OF maintainers/developers, this is their domain :) >> > >> > Well, OK. Whom in particular? >> >> The "OPEN FIRMWARE AND FLATTENED DEVICE TREE" entries in MAINTAINERS? > > Hmm, that looks like Grant and Rob Herring. > > Grant, Rob, do we want the OF-style MODALIAS to be shown in "modalias" sysfs > attributes of platform devices? I've not actually had to deal with modutils and modalias on any of the platforms I've worked with so I've only looked at it superficially. Yes, that does look like a bug, but Ben would probably have a much better idea [cc'd]. g. -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
