On Wed, Oct 16, 2013 at 01:04:02AM +0100, Grant Likely wrote: > 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> I think we have a whole session about this at the ARM summit next week, and if someone wants to bring beer into it, that will make me happy! -- 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
