On 09/13/2014 09:46 PM, Grant Likely wrote: > On Mon, 08 Sep 2014 13:22:44 -0700, Stephen Boyd <sboyd@xxxxxxxxxxxxxx> wrote: >> >> Where is this described? From the commit text that introduces >> IORESOURCE_REG I see: >> >> "Currently a bunch of I2C/SPI MFD drivers are using IORESOURCE_IO for >> register address ranges. Since this causes some confusion due to the >> primary use of this resource type for PCI/ISA I/O ports create a new >> resource type IORESOURCE_REG." > Sorry, I mistook IORESOURCE_REG or IORESOURCE_IO. You're right, this > isn't an issue. > > I'm still concerned about the implications of automatically populating > platform_devices with this resource type. I'll talk to Mark about it > face to fact at Connect this week. > > Where did this end up? When we talked at Connect I think we settled on exploring a driver core specific API like dev_get_localbus_address() that calls of_get_localbus_address() for devices with an of_node and in the future it could call something like acpi_get_localbus_address() when there's an acpi_node. I believe the biggest concern is that we're making an API that is OF or platform bus specific when it doesn't need to be. Making a driver core specific API avoids this problem by making it bus agnostic. That's fine, but I still think we want to have the IORESOURCE_REG resources given that we have drivers in-flight and some already merged that are using the IORESOURCE_REG resource. Furthermore, ACPI is using the platform bus for MFDs so it's not like we're going to be using a different bus in the future for these pmic sub-device drivers if we decide to do pmic devices in ACPI (looks like there is at least precedence for that with Intel's i2c pmic). Supporting this on ACPI is going to take the same effort if we plumb it into the resource table or we plumb it into a new driver core API, so the bus agnostic angle isn't looking all that convincing. Not to say I'm opposed to some driver core specific API (that's similar to the proposed device_property_read_*() API) but I don't see any benefit for something that is already "unified" between ACPI and OF via the platform bus resources table. If the resources table didn't already exist I'd be more inclined to say we should use some new driver core API. So what's the way forward? I see a few options: 1) Take this patch after some minor tweaks 2) Add a driver core API and fixup all drivers to use it 3) Layer the platform resource stuff on top of a driver core API I'd prefer we went with option #1. -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
