Re: [PATCH v2 0/5] Generic PHY Framework
On 02/19/2013 09:05:00 AM, Felipe Balbi wrote: Greg, can you pitch your suggestion here ? It would be great to hear your rationale behind dropping class infrastructure, couldn't find anything through Google and since feature-removal-schedule.txt has been removed (without adding it to feature-removal-schedule.txt, I must add :-) I don't know what's the idea behind removing classes. I actually went through and poked a couple of people about old entries in feature-removal-shedule.txt last year, but I haven't been very active since the kernel.org breakin because my account got disabled, and I needed to meet kernel developers in person to get keys signed to get it switched back on (or set up a separate git tree with signed commits -next could pull from). I don't get out much; as a consultant I have to take time off from work and pay for my own travel and lodging. So I've been to exactly two conferences in the past 3 years: last year's Texas Linux Fest (my house got broken into and a netbook with the key on it stolen the following wednesday), and CELF (which I'm on the plane back from now, Greg KH signed my key! Woo!). If I can use that to get my account back, set up a tree feeding into linux-next, and maybe even recover the ability to update http://kernel.org/doc, I'd happily field some sort of feature-removal-schedule list and make sure it stays current. (Linus didn't ask me about removing the old one, I found out about it from the git log. But I can't blame him, I haven't exactly been tearing through the bureaucracy to get my access back. Volunteer work and painful tend not to combine well on my todo list in terms of scheduling priority...) Rob-- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 0/5] Generic PHY Framework
On Tuesday 19 February 2013, Kishon Vijay Abraham I wrote: Added a generic PHY framework that provides a set of APIs for the PHY drivers to create/destroy a PHY and APIs for the PHY users to obtain a reference to the PHY with or without using phandle. To obtain a reference to the PHY without using phandle, the platform specfic intialization code (say from board file) should have already called phy_bind with the binding information. The binding information consists of phy's device name, phy user device name and an index. The index is used when the same phy user binds to mulitple phys. This framework will be of use only to devices that uses external PHY (PHY functionality is not embedded within the controller). The intention of creating this framework is to bring the phy drivers spread all over the Linux kernel to drivers/phy to increase code re-use and to increase code maintainability. Comments to make PHY as bus wasn't done because PHY devices can be part of other bus and making a same device attached to multiple bus leads to bad design. How does this relate to the generic PHY interfaces in drivers/net/phy? Do you expect that to get merged into drivers/phy in the long run, or do you want to keep the generic phy only for everything but ethernet? I think it would be problematic to have two alternative interfaces for ethernet PHYs because then an ethernet driver still needs to decide which subsystem to interface with. Arnd -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 0/5] Generic PHY Framework
Hi, On Tuesday 19 February 2013 04:14 PM, Arnd Bergmann wrote: On Tuesday 19 February 2013, Kishon Vijay Abraham I wrote: Added a generic PHY framework that provides a set of APIs for the PHY drivers to create/destroy a PHY and APIs for the PHY users to obtain a reference to the PHY with or without using phandle. To obtain a reference to the PHY without using phandle, the platform specfic intialization code (say from board file) should have already called phy_bind with the binding information. The binding information consists of phy's device name, phy user device name and an index. The index is used when the same phy user binds to mulitple phys. This framework will be of use only to devices that uses external PHY (PHY functionality is not embedded within the controller). The intention of creating this framework is to bring the phy drivers spread all over the Linux kernel to drivers/phy to increase code re-use and to increase code maintainability. Comments to make PHY as bus wasn't done because PHY devices can be part of other bus and making a same device attached to multiple bus leads to bad design. How does this relate to the generic PHY interfaces in drivers/net/phy? Currently drivers/phy and drivers/net/phy are independent and are not related to each other. There are some fundamental differences on how these frameworks work. IIUC, the *net* uses bus layer (MDIO bus) to match a PHY device with a PHY driver and the Ethernet device uses the bus layer to get the PHY. The Generic PHY Framework however doesn't have any bus layer. The PHY should be like any other Platform Devices and Drivers and the framework will provide some APIs to register with the framework. And there are other APIs which any controller can use to get the PHY (for e.g., in the case of dt boot, it can use phandle to get a reference to the PHY). Do you expect that to get merged into drivers/phy in the long run, or do you want to keep the generic phy only for everything but ethernet? We'd like the PHY drivers spread all over the kernel to get merged to drivers/phy including Ethernet. Having said that, Ethernet itself has a huge PHY framework and it's going to be little challenging to adapt to the new PHY framework (of course there'll be changes in this PHY framework when we want to have network PHY added here). But adapting USB PHYs to the new framework will be simpler and will be taken first. Also when we add SATA PHY (OMAP5), it will make use of this framework as both SATA and USB3 uses the same PHY IP. I think it would be problematic to have two alternative interfaces for ethernet PHYs because then an ethernet driver still needs to decide which subsystem to interface with. Right. For now Ethernet should continue to use their own PHY abstraction layer till we are a bit more clear on how to move it to drivers/phy. Thanks Kishon -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 0/5] Generic PHY Framework
On Tuesday 19 February 2013, kishon wrote: On Tuesday 19 February 2013 04:14 PM, Arnd Bergmann wrote: On Tuesday 19 February 2013, Kishon Vijay Abraham I wrote: Added a generic PHY framework that provides a set of APIs for the PHY drivers to create/destroy a PHY and APIs for the PHY users to obtain a reference to the PHY with or without using phandle. To obtain a reference to the PHY without using phandle, the platform specfic intialization code (say from board file) should have already called phy_bind with the binding information. The binding information consists of phy's device name, phy user device name and an index. The index is used when the same phy user binds to mulitple phys. This framework will be of use only to devices that uses external PHY (PHY functionality is not embedded within the controller). The intention of creating this framework is to bring the phy drivers spread all over the Linux kernel to drivers/phy to increase code re-use and to increase code maintainability. Comments to make PHY as bus wasn't done because PHY devices can be part of other bus and making a same device attached to multiple bus leads to bad design. How does this relate to the generic PHY interfaces in drivers/net/phy? Currently drivers/phy and drivers/net/phy are independent and are not related to each other. There are some fundamental differences on how these frameworks work. IIUC, the *net* uses bus layer (MDIO bus) to match a PHY device with a PHY driver and the Ethernet device uses the bus layer to get the PHY. The Generic PHY Framework however doesn't have any bus layer. The PHY should be like any other Platform Devices and Drivers and the framework will provide some APIs to register with the framework. And there are other APIs which any controller can use to get the PHY (for e.g., in the case of dt boot, it can use phandle to get a reference to the PHY). Hmm, I think the use of a bus_type for a PHY actually sounds quite appropriate. The actual PHY device would then be a child of the platform_device (or something else) that gets probed by its parent bus or the DT. The operations that you define for the PHY actually mirror some of the things that we have for a 'struct device', so I think it would be quite logical to do it the same way. Note that MDIO has both a 'bus' and a 'class', and what we want here is more like what the 'class' was meant for, except that for new classes, we should actually use a 'bus', since the long-term plan is to kill off the concept of a 'class'. I hope that was not too confusing. :) Do you expect that to get merged into drivers/phy in the long run, or do you want to keep the generic phy only for everything but ethernet? We'd like the PHY drivers spread all over the kernel to get merged to drivers/phy including Ethernet. Having said that, Ethernet itself has a huge PHY framework and it's going to be little challenging to adapt to the new PHY framework (of course there'll be changes in this PHY framework when we want to have network PHY added here). But adapting USB PHYs to the new framework will be simpler and will be taken first. Also when we add SATA PHY (OMAP5), it will make use of this framework as both SATA and USB3 uses the same PHY IP. I think you need to have at least a concept of where you want to end up. It's totally fine to introduce a new subsystem that does only the minimum of what you need here, and add things as you go, but if you already plan to merge the existing mdio bus into this, you should really have an idea of what that will mean in the long run. I think it would be problematic to have two alternative interfaces for ethernet PHYs because then an ethernet driver still needs to decide which subsystem to interface with. Right. For now Ethernet should continue to use their own PHY abstraction layer till we are a bit more clear on how to move it to drivers/phy. Ok. Arnd -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 0/5] Generic PHY Framework
Hi, On Tue, Feb 19, 2013 at 12:33:54PM +, Arnd Bergmann wrote: On Tuesday 19 February 2013, kishon wrote: On Tuesday 19 February 2013 04:14 PM, Arnd Bergmann wrote: On Tuesday 19 February 2013, Kishon Vijay Abraham I wrote: Added a generic PHY framework that provides a set of APIs for the PHY drivers to create/destroy a PHY and APIs for the PHY users to obtain a reference to the PHY with or without using phandle. To obtain a reference to the PHY without using phandle, the platform specfic intialization code (say from board file) should have already called phy_bind with the binding information. The binding information consists of phy's device name, phy user device name and an index. The index is used when the same phy user binds to mulitple phys. This framework will be of use only to devices that uses external PHY (PHY functionality is not embedded within the controller). The intention of creating this framework is to bring the phy drivers spread all over the Linux kernel to drivers/phy to increase code re-use and to increase code maintainability. Comments to make PHY as bus wasn't done because PHY devices can be part of other bus and making a same device attached to multiple bus leads to bad design. How does this relate to the generic PHY interfaces in drivers/net/phy? Currently drivers/phy and drivers/net/phy are independent and are not related to each other. There are some fundamental differences on how these frameworks work. IIUC, the *net* uses bus layer (MDIO bus) to match a PHY device with a PHY driver and the Ethernet device uses the bus layer to get the PHY. The Generic PHY Framework however doesn't have any bus layer. The PHY should be like any other Platform Devices and Drivers and the framework will provide some APIs to register with the framework. And there are other APIs which any controller can use to get the PHY (for e.g., in the case of dt boot, it can use phandle to get a reference to the PHY). Hmm, I think the use of a bus_type for a PHY actually sounds quite appropriate. The actual PHY device would then be a child of the really ? I'm not so sure, the *bus* used by the PHY is ULPI, UTMI, UTMI+, PIP3, I2C, etc... adding another 'fake' bus representation is a bit overkill IMO. Imagine an I2C-controlled PHY driver like isp1301, that driver will have to register i2c_driver and phy_driver, which looks weird to me. If the only substitute for class is a bus, we can't drop classes just yet, I'm afraid. Imagine a regulator bus, a pwm bus, an LED bus etc. They don't make sense IMHO. platform_device (or something else) that gets probed by its parent bus or the DT. The operations that you define for the PHY actually mirror some of the things that we have for a 'struct device', so I think it would be quite logical to do it the same way. Note that MDIO has both a 'bus' and a 'class', and what we want here is more like what the 'class' was meant for, except that for new classes, we should actually use a 'bus', since the long-term plan is to kill off the concept of a 'class'. I hope that was not too confusing. :) :) -- balbi signature.asc Description: Digital signature
Re: [PATCH v2 0/5] Generic PHY Framework
On Tuesday 19 February 2013, Felipe Balbi wrote: On Tue, Feb 19, 2013 at 12:33:54PM +, Arnd Bergmann wrote: Currently drivers/phy and drivers/net/phy are independent and are not related to each other. There are some fundamental differences on how these frameworks work. IIUC, the *net* uses bus layer (MDIO bus) to match a PHY device with a PHY driver and the Ethernet device uses the bus layer to get the PHY. The Generic PHY Framework however doesn't have any bus layer. The PHY should be like any other Platform Devices and Drivers and the framework will provide some APIs to register with the framework. And there are other APIs which any controller can use to get the PHY (for e.g., in the case of dt boot, it can use phandle to get a reference to the PHY). Hmm, I think the use of a bus_type for a PHY actually sounds quite appropriate. The actual PHY device would then be a child of the really ? I'm not so sure, the *bus* used by the PHY is ULPI, UTMI, UTMI+, PIP3, I2C, etc... adding another 'fake' bus representation is a bit overkill IMO. Imagine an I2C-controlled PHY driver like isp1301, that driver will have to register i2c_driver and phy_driver, which looks weird to me. If the only substitute for class is a bus, we can't drop classes just yet, I'm afraid. Imagine a regulator bus, a pwm bus, an LED bus etc. They don't make sense IMHO. It's a fine line, but I think a phy is something that resembles a device more than an LED does. When I read patch 1, I also noticed and commented on the fact that it does use a 'class'. Now, according to Greg, we should use 'bus_type' instead of 'class' in new code. I originally disagreed with that concept, but he's the boss here and it's good if he has a vision how things should be lined out. In practice, there is little difference between a 'bus_type' and a 'class', so just replace any instance of the former with the latter in your head when reading the code ;-) I understand that there is not a real common bus here, and the bus_type infrastructure would basically be used as a way to represent each PHY in sysfs and provide a way to enumerate and look them up inside of the kernel. Arnd -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 0/5] Generic PHY Framework
Hi, On Tue, Feb 19, 2013 at 02:34:40PM +, Arnd Bergmann wrote: On Tuesday 19 February 2013, Felipe Balbi wrote: On Tue, Feb 19, 2013 at 12:33:54PM +, Arnd Bergmann wrote: Currently drivers/phy and drivers/net/phy are independent and are not related to each other. There are some fundamental differences on how these frameworks work. IIUC, the *net* uses bus layer (MDIO bus) to match a PHY device with a PHY driver and the Ethernet device uses the bus layer to get the PHY. The Generic PHY Framework however doesn't have any bus layer. The PHY should be like any other Platform Devices and Drivers and the framework will provide some APIs to register with the framework. And there are other APIs which any controller can use to get the PHY (for e.g., in the case of dt boot, it can use phandle to get a reference to the PHY). Hmm, I think the use of a bus_type for a PHY actually sounds quite appropriate. The actual PHY device would then be a child of the really ? I'm not so sure, the *bus* used by the PHY is ULPI, UTMI, UTMI+, PIP3, I2C, etc... adding another 'fake' bus representation is a bit overkill IMO. Imagine an I2C-controlled PHY driver like isp1301, that driver will have to register i2c_driver and phy_driver, which looks weird to me. If the only substitute for class is a bus, we can't drop classes just yet, I'm afraid. Imagine a regulator bus, a pwm bus, an LED bus etc. They don't make sense IMHO. It's a fine line, but I think a phy is something that resembles a device more than an LED does. When I read patch 1, I also noticed and commented on the fact that it does use a 'class'. Now, according to Greg, we should use 'bus_type' instead of 'class' in new code. I originally disagreed with that concept, but he's the boss here and it's good if he has a vision how things should be lined out. In practice, there is little difference between a 'bus_type' and a 'class', so just replace any instance of the former with the latter in your head when reading the code ;-) it's not so simple :-) if we must use bus_type we need to introduce all the device/driver matching mechanism which isn't necessary with a class. I understand that there is not a real common bus here, and the bus_type infrastructure would basically be used as a way to represent each PHY in sysfs and provide a way to enumerate and look them up inside of the kernel. right, but maybe we need another mechanism. If, in the long run we must use bus_type, then eventually pwm, led, regulators, etc will all be converted to bus_type. It will look quite weird IMHO. Greg, can you pitch your suggestion here ? It would be great to hear your rationale behind dropping class infrastructure, couldn't find anything through Google and since feature-removal-schedule.txt has been removed (without adding it to feature-removal-schedule.txt, I must add :-) I don't know what's the idea behind removing classes. cheers -- balbi signature.asc Description: Digital signature
Re: [PATCH v2 0/5] Generic PHY Framework
On Tuesday 19 February 2013, Felipe Balbi wrote: On Tue, Feb 19, 2013 at 02:34:40PM +, Arnd Bergmann wrote: On Tuesday 19 February 2013, Felipe Balbi wrote: On Tue, Feb 19, 2013 at 12:33:54PM +, Arnd Bergmann wrote: It's a fine line, but I think a phy is something that resembles a device more than an LED does. When I read patch 1, I also noticed and commented on the fact that it does use a 'class'. Now, according to Greg, we should use 'bus_type' instead of 'class' in new code. I originally disagreed with that concept, but he's the boss here and it's good if he has a vision how things should be lined out. In practice, there is little difference between a 'bus_type' and a 'class', so just replace any instance of the former with the latter in your head when reading the code ;-) it's not so simple :-) if we must use bus_type we need to introduce all the device/driver matching mechanism which isn't necessary with a class. I think the idea is to use a bus_type that has devices but no drivers associated with it, but I might be misremembering things. I understand that there is not a real common bus here, and the bus_type infrastructure would basically be used as a way to represent each PHY in sysfs and provide a way to enumerate and look them up inside of the kernel. right, but maybe we need another mechanism. If, in the long run we must use bus_type, then eventually pwm, led, regulators, etc will all be converted to bus_type. It will look quite weird IMHO. Yes, it would be a bit unusual, I agree. Greg, can you pitch your suggestion here ? It would be great to hear your rationale behind dropping class infrastructure, couldn't find anything through Google and since feature-removal-schedule.txt has been removed (without adding it to feature-removal-schedule.txt, I must add :-) I don't know what's the idea behind removing classes. I believe for now, the idea is to not add any new classes, but keep the existing ones for compatibility. 'struct class_device' however was already removed and got turned into 'struct device'. Arnd -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 0/5] Generic PHY Framework
On Tue, Feb 19, 2013 at 03:28:17PM +, Arnd Bergmann wrote:
On Tuesday 19 February 2013, Felipe Balbi wrote:
On Tue, Feb 19, 2013 at 02:34:40PM +, Arnd Bergmann wrote:
On Tuesday 19 February 2013, Felipe Balbi wrote:
On Tue, Feb 19, 2013 at 12:33:54PM +, Arnd Bergmann wrote:
It's a fine line, but I think a phy is something that resembles a device
more than an LED does. When I read patch 1, I also noticed and commented
on the fact that it does use a 'class'. Now, according to Greg, we should
use 'bus_type' instead of 'class' in new code. I originally disagreed with
that concept, but he's the boss here and it's good if he has a vision
how things should be lined out.
In practice, there is little difference between a 'bus_type' and a
'class',
so just replace any instance of the former with the latter in your head
when reading the code ;-)
it's not so simple :-) if we must use bus_type we need to introduce all
the device/driver matching mechanism which isn't necessary with a class.
I think the idea is to use a bus_type that has devices but no drivers
associated with it, but I might be misremembering things.
but then drivers wouldn't probe ever, although devices would get
created, so maybe it'll work...
Greg, can you pitch your suggestion here ? It would be great to hear
your rationale behind dropping class infrastructure, couldn't find
anything through Google and since feature-removal-schedule.txt has been
removed (without adding it to feature-removal-schedule.txt, I must add
:-) I don't know what's the idea behind removing classes.
I believe for now, the idea is to not add any new classes, but keep
the existing ones for compatibility. 'struct class_device' however
was already removed and got turned into 'struct device'.
was there ever a struct class_device.
What about struct class ?
linux/device.h ::
334 struct class {
335 const char *name;
336 struct module *owner;
337
338 struct class_attribute *class_attrs;
339 struct device_attribute *dev_attrs;
340 struct bin_attribute*dev_bin_attrs;
341 struct kobject *dev_kobj;
342
343 int (*dev_uevent)(struct device *dev, struct kobj_uevent_env *env);
344 char *(*devnode)(struct device *dev, umode_t *mode);
345
346 void (*class_release)(struct class *class);
347 void (*dev_release)(struct device *dev);
348
349 int (*suspend)(struct device *dev, pm_message_t state);
350 int (*resume)(struct device *dev);
351
352 const struct kobj_ns_type_operations *ns_type;
353 const void *(*namespace)(struct device *dev);
354
355 const struct dev_pm_ops *pm;
356
357 struct subsys_private *p;
358 };
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH v2 0/5] Generic PHY Framework
On 02/19/2013 04:05 PM, Felipe Balbi wrote: Hi, On Tue, Feb 19, 2013 at 02:34:40PM +, Arnd Bergmann wrote: On Tuesday 19 February 2013, Felipe Balbi wrote: On Tue, Feb 19, 2013 at 12:33:54PM +, Arnd Bergmann wrote: Currently drivers/phy and drivers/net/phy are independent and are not related to each other. There are some fundamental differences on how these frameworks work. IIUC, the *net* uses bus layer (MDIO bus) to match a PHY device with a PHY driver and the Ethernet device uses the bus layer to get the PHY. The Generic PHY Framework however doesn't have any bus layer. The PHY should be like any other Platform Devices and Drivers and the framework will provide some APIs to register with the framework. And there are other APIs which any controller can use to get the PHY (for e.g., in the case of dt boot, it can use phandle to get a reference to the PHY). Hmm, I think the use of a bus_type for a PHY actually sounds quite appropriate. The actual PHY device would then be a child of the really ? I'm not so sure, the *bus* used by the PHY is ULPI, UTMI, UTMI+, PIP3, I2C, etc... adding another 'fake' bus representation is a bit overkill IMO. Imagine an I2C-controlled PHY driver like isp1301, that driver will have to register i2c_driver and phy_driver, which looks weird to me. If the only substitute for class is a bus, we can't drop classes just yet, I'm afraid. Imagine a regulator bus, a pwm bus, an LED bus etc. They don't make sense IMHO. It's a fine line, but I think a phy is something that resembles a device more than an LED does. When I read patch 1, I also noticed and commented on the fact that it does use a 'class'. Now, according to Greg, we should use 'bus_type' instead of 'class' in new code. I originally disagreed with that concept, but he's the boss here and it's good if he has a vision how things should be lined out. In practice, there is little difference between a 'bus_type' and a 'class', so just replace any instance of the former with the latter in your head when reading the code ;-) it's not so simple :-) if we must use bus_type we need to introduce all the device/driver matching mechanism which isn't necessary with a class. You have the code for phy - device matching in your framework anyway. Using the bus infrastructure brings changes the open coded matching into bus callbacks. regards, Marc -- Pengutronix e.K. | Marc Kleine-Budde | Industrial Linux Solutions| Phone: +49-231-2826-924 | Vertretung West/Dortmund | Fax: +49-5121-206917- | Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de | signature.asc Description: OpenPGP digital signature
[PATCH v2 0/5] Generic PHY Framework
Added a generic PHY framework that provides a set of APIs for the PHY drivers to create/destroy a PHY and APIs for the PHY users to obtain a reference to the PHY with or without using phandle. To obtain a reference to the PHY without using phandle, the platform specfic intialization code (say from board file) should have already called phy_bind with the binding information. The binding information consists of phy's device name, phy user device name and an index. The index is used when the same phy user binds to mulitple phys. This framework will be of use only to devices that uses external PHY (PHY functionality is not embedded within the controller). The intention of creating this framework is to bring the phy drivers spread all over the Linux kernel to drivers/phy to increase code re-use and to increase code maintainability. Comments to make PHY as bus wasn't done because PHY devices can be part of other bus and making a same device attached to multiple bus leads to bad design. Changes from v1: * Added Documentation for the PHY framework * Added few more APIs mostly w.r.t devres * Modified omap-usb2 and twl4030 to make use of the new framework Did USB enumeration testing in panda and beagle. Kishon Vijay Abraham I (5): drivers: phy: add generic PHY framework usb: phy: omap-usb2: use the new generic PHY framework usb: otg: twl4030: use the new generic PHY framework ARM: OMAP: USB: Add phy binding information usb: musb: omap2430: use the new generic PHY framework Documentation/ABI/testing/sysfs-class-phy| 15 + Documentation/phy.txt| 113 ++ MAINTAINERS |7 + arch/arm/mach-omap2/board-2430sdp.c |2 + arch/arm/mach-omap2/board-3430sdp.c |2 + arch/arm/mach-omap2/board-4430sdp.c |2 + arch/arm/mach-omap2/board-cm-t35.c |2 + arch/arm/mach-omap2/board-devkit8000.c |2 + arch/arm/mach-omap2/board-igep0020.c |2 + arch/arm/mach-omap2/board-ldp.c |2 + arch/arm/mach-omap2/board-omap3beagle.c |2 + arch/arm/mach-omap2/board-omap3evm.c |2 + arch/arm/mach-omap2/board-omap3logic.c |2 + arch/arm/mach-omap2/board-omap3pandora.c |2 + arch/arm/mach-omap2/board-omap3stalker.c |2 + arch/arm/mach-omap2/board-omap3touchbook.c |2 + arch/arm/mach-omap2/board-omap4panda.c |2 + arch/arm/mach-omap2/board-overo.c|2 + arch/arm/mach-omap2/board-rm680.c|2 + arch/arm/mach-omap2/board-zoom-peripherals.c |2 + drivers/Kconfig |2 + drivers/Makefile |2 + drivers/phy/Kconfig | 13 + drivers/phy/Makefile |5 + drivers/phy/phy-core.c | 519 ++ drivers/usb/musb/musb_core.h |2 + drivers/usb/musb/omap2430.c | 22 +- drivers/usb/otg/twl4030-usb.c| 41 ++ drivers/usb/phy/omap-usb2.c | 49 +++ include/linux/phy/phy.h | 198 ++ include/linux/usb/omap_usb.h |3 + 31 files changed, 1019 insertions(+), 6 deletions(-) create mode 100644 Documentation/ABI/testing/sysfs-class-phy create mode 100644 Documentation/phy.txt create mode 100644 drivers/phy/Kconfig create mode 100644 drivers/phy/Makefile create mode 100644 drivers/phy/phy-core.c create mode 100644 include/linux/phy/phy.h -- 1.7.10.4 -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
