Hi Kishon, And happy new year.. On Tue, Jan 07, 2014 at 07:10:36PM +0530, Kishon Vijay Abraham I wrote: > >>> /** > >>> - * phy_get() - lookup and obtain a reference to a phy. > >>> + * phy_get_index() - obtain a phy based on index > >> > >> NAK. It still takes a 'char' argument and the name is misleading. > >> Btw are you replacing phy_get() or adding a new API in addition to phy_get()? > > > > Additional API. The phy_get() would in practice act as a wrapper after > > In this patch it looks like you've replaced phy_get(). > > this. It could actually be just a #define macro in the include file. > > The function naming I just copied straight from gpiolib.c. I did not > > have the imagination for anything fancier. > > > > I would like to be able to use some function like phy_get_index() and > > be able to deliver it both the name and the index. With DT you guys > > will always be able to use the name (and the string will always > > supersede the index if we do it like this), but with ACPI, and possibly > > the platform lookup tables, the index can be used... > > I think in that case, we should drop the 'string' from phy_get_index since we > have the other API to handle that? I don't know about ACPI, but is it not > possible to use strings with ACPI? No unfortunately. We just have what the ACPI tables provide. The PHYs would be "child" device entries under the controller and we can only get handle to them based on the index. I think I'll skip this patch from this set. Let's wait until we have an actual ACPI DSDT describing some PHYs. Thanks, -- heikki -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
