diff mbox series

[v5,3/4] usb: host: xhci-plat: Create platform device for onboard hubs in probe()

Message ID 20210210091015.v5.3.I7a3a7d9d2126c34079b1cab87aa0b2ec3030f9b7@changeid
State Superseded
Headers show
Series USB: misc: Add onboard_usb_hub driver | expand

Commit Message

Matthias Kaehlcke Feb. 10, 2021, 5:10 p.m. UTC
Check during probe() if a hub supported by the onboard_usb_hub
driver is connected to the controller. If such a hub is found
create the corresponding platform device. This requires the
device tree to have a node for the hub with its vendor and
product id (which is not common for USB devices). Further the
platform device is only created when CONFIG_USB_ONBOARD_HUB=y/m.

Signed-off-by: Matthias Kaehlcke <mka@chromium.org>
---

Changes in v5:
- patch added to the series

 drivers/usb/host/xhci-plat.c | 16 ++++++++++++++++
 include/linux/usb/hcd.h      |  2 ++
 2 files changed, 18 insertions(+)

Comments

kernel test robot Feb. 11, 2021, 1:30 a.m. UTC | #1
Hi Matthias,

I love your patch! Yet something to improve:

[auto build test ERROR on usb/usb-testing]
[also build test ERROR on robh/for-next char-misc/char-misc-testing v5.11-rc7 next-20210125]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]

url:    https://github.com/0day-ci/linux/commits/Matthias-Kaehlcke/USB-misc-Add-onboard_usb_hub-driver/20210211-011551
base:   https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git usb-testing
config: xtensa-randconfig-r022-20210209 (attached as .config)
compiler: xtensa-linux-gcc (GCC) 9.3.0
reproduce (this is a W=1 build):
        wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
        chmod +x ~/bin/make.cross
        # https://github.com/0day-ci/linux/commit/c9b9392a809153c27c7c936178f65cb189b49f1a
        git remote add linux-review https://github.com/0day-ci/linux
        git fetch --no-tags linux-review Matthias-Kaehlcke/USB-misc-Add-onboard_usb_hub-driver/20210211-011551
        git checkout c9b9392a809153c27c7c936178f65cb189b49f1a
        # save the attached .config to linux build tree
        COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross ARCH=xtensa 

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp@intel.com>

All errors (new ones prefixed by >>):

   xtensa-linux-ld: drivers/usb/host/xhci-plat.o: in function `xhci_plat_quirks':
>> xhci-plat.c:(.text+0xb8): undefined reference to `of_platform_device_destroy'

   xtensa-linux-ld: drivers/usb/host/xhci-plat.o: in function `xhci_plat_remove':
   xhci-plat.c:(.text+0x2e2): undefined reference to `of_platform_device_destroy'

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
kernel test robot Feb. 11, 2021, 1:33 a.m. UTC | #2
Hi Matthias,

I love your patch! Yet something to improve:

[auto build test ERROR on usb/usb-testing]
[also build test ERROR on robh/for-next char-misc/char-misc-testing v5.11-rc7 next-20210125]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]

url:    https://github.com/0day-ci/linux/commits/Matthias-Kaehlcke/USB-misc-Add-onboard_usb_hub-driver/20210211-011551
base:   https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git usb-testing
config: x86_64-randconfig-m001-20210209 (attached as .config)
compiler: gcc-9 (Debian 9.3.0-15) 9.3.0
reproduce (this is a W=1 build):
        # https://github.com/0day-ci/linux/commit/c9b9392a809153c27c7c936178f65cb189b49f1a
        git remote add linux-review https://github.com/0day-ci/linux
        git fetch --no-tags linux-review Matthias-Kaehlcke/USB-misc-Add-onboard_usb_hub-driver/20210211-011551
        git checkout c9b9392a809153c27c7c936178f65cb189b49f1a
        # save the attached .config to linux build tree
        make W=1 ARCH=x86_64 

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp@intel.com>

All errors (new ones prefixed by >>, old ones prefixed by <<):

>> ERROR: modpost: "of_platform_device_destroy" [drivers/usb/host/xhci-plat-hcd.ko] undefined!


---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
Matthias Kaehlcke Feb. 11, 2021, 6:45 p.m. UTC | #3
Hi Greg,

On Thu, Feb 11, 2021 at 07:58:23AM +0100, Greg Kroah-Hartman wrote:
> On Wed, Feb 10, 2021 at 09:10:38AM -0800, Matthias Kaehlcke wrote:

> > Check during probe() if a hub supported by the onboard_usb_hub

> > driver is connected to the controller. If such a hub is found

> > create the corresponding platform device. This requires the

> > device tree to have a node for the hub with its vendor and

> > product id (which is not common for USB devices). Further the

> > platform device is only created when CONFIG_USB_ONBOARD_HUB=y/m.

> > 

> > Signed-off-by: Matthias Kaehlcke <mka@chromium.org>

> > ---

> > 

> > Changes in v5:

> > - patch added to the series

> > 

> >  drivers/usb/host/xhci-plat.c | 16 ++++++++++++++++

> >  include/linux/usb/hcd.h      |  2 ++

> >  2 files changed, 18 insertions(+)

> > 

> > diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c

> > index 4d34f6005381..e785fa109eea 100644

> > --- a/drivers/usb/host/xhci-plat.c

> > +++ b/drivers/usb/host/xhci-plat.c

> > @@ -15,6 +15,7 @@

> >  #include <linux/of.h>

> >  #include <linux/of_device.h>

> >  #include <linux/platform_device.h>

> > +#include <linux/usb/onboard_hub.h>

> >  #include <linux/usb/phy.h>

> >  #include <linux/slab.h>

> >  #include <linux/acpi.h>

> > @@ -184,6 +185,7 @@ static int xhci_plat_probe(struct platform_device *pdev)

> >  	int			ret;

> >  	int			irq;

> >  	struct xhci_plat_priv	*priv = NULL;

> > +	struct device_node	*np;

> >  

> >  

> >  	if (usb_disabled())

> > @@ -356,6 +358,17 @@ static int xhci_plat_probe(struct platform_device *pdev)

> >  	 */

> >  	pm_runtime_forbid(&pdev->dev);

> >  

> > +	np = usb_of_get_device_node(hcd->self.root_hub, hcd->self.busnum);

> > +	if (np && of_is_onboard_usb_hub(np)) {

> > +		struct platform_device *pdev;

> > +

> > +		pdev = of_platform_device_create(np, NULL, NULL);

> 

> A platform device is a child of another platform device?  Ok, but

> really, why?  What uses this device?


In earlier versions there was a standalone platform device:
https://lore.kernel.org/patchwork/patch/1313001/

However this was rejected by Rob, since the DT would require a node for the
platform device and (implicit or explicit) nodes for the USB devices,
representing the same physical device:

https://lore.kernel.org/patchwork/patch/1305395/
https://lore.kernel.org/patchwork/patch/1313000/

Both Doug Anderson and myself argued that it seems legitimate to distinguish
between the devices connected to the USB bus, and the chip which might have
GPIOs, regulators, clocks, ... but apparently our arguments were not
convincing enough.
Matthias Kaehlcke Feb. 11, 2021, 7:01 p.m. UTC | #4
On Thu, Feb 11, 2021 at 10:45:48AM -0800, Matthias Kaehlcke wrote:
> Hi Greg,

> 

> On Thu, Feb 11, 2021 at 07:58:23AM +0100, Greg Kroah-Hartman wrote:

> > On Wed, Feb 10, 2021 at 09:10:38AM -0800, Matthias Kaehlcke wrote:

> > > Check during probe() if a hub supported by the onboard_usb_hub

> > > driver is connected to the controller. If such a hub is found

> > > create the corresponding platform device. This requires the

> > > device tree to have a node for the hub with its vendor and

> > > product id (which is not common for USB devices). Further the

> > > platform device is only created when CONFIG_USB_ONBOARD_HUB=y/m.

> > > 

> > > Signed-off-by: Matthias Kaehlcke <mka@chromium.org>

> > > ---

> > > 

> > > Changes in v5:

> > > - patch added to the series

> > > 

> > >  drivers/usb/host/xhci-plat.c | 16 ++++++++++++++++

> > >  include/linux/usb/hcd.h      |  2 ++

> > >  2 files changed, 18 insertions(+)

> > > 

> > > diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c

> > > index 4d34f6005381..e785fa109eea 100644

> > > --- a/drivers/usb/host/xhci-plat.c

> > > +++ b/drivers/usb/host/xhci-plat.c

> > > @@ -15,6 +15,7 @@

> > >  #include <linux/of.h>

> > >  #include <linux/of_device.h>

> > >  #include <linux/platform_device.h>

> > > +#include <linux/usb/onboard_hub.h>

> > >  #include <linux/usb/phy.h>

> > >  #include <linux/slab.h>

> > >  #include <linux/acpi.h>

> > > @@ -184,6 +185,7 @@ static int xhci_plat_probe(struct platform_device *pdev)

> > >  	int			ret;

> > >  	int			irq;

> > >  	struct xhci_plat_priv	*priv = NULL;

> > > +	struct device_node	*np;

> > >  

> > >  

> > >  	if (usb_disabled())

> > > @@ -356,6 +358,17 @@ static int xhci_plat_probe(struct platform_device *pdev)

> > >  	 */

> > >  	pm_runtime_forbid(&pdev->dev);

> > >  

> > > +	np = usb_of_get_device_node(hcd->self.root_hub, hcd->self.busnum);

> > > +	if (np && of_is_onboard_usb_hub(np)) {

> > > +		struct platform_device *pdev;

> > > +

> > > +		pdev = of_platform_device_create(np, NULL, NULL);

> > 

> > A platform device is a child of another platform device?  Ok, but

> > really, why?  What uses this device?

> 

> In earlier versions there was a standalone platform device:

> https://lore.kernel.org/patchwork/patch/1313001/

> 

> However this was rejected by Rob, since the DT would require a node for the

> platform device and (implicit or explicit) nodes for the USB devices,

> representing the same physical device:

> 

> https://lore.kernel.org/patchwork/patch/1305395/

> https://lore.kernel.org/patchwork/patch/1313000/

> 

> Both Doug Anderson and myself argued that it seems legitimate to distinguish

> between the devices connected to the USB bus, and the chip which might have

> GPIOs, regulators, clocks, ... but apparently our arguments were not

> convincing enough.


To let the xhci-plat driver create the platform device was suggested by Alan:

https://lore.kernel.org/patchwork/patch/1313000/#1510227

Personally I would favor a standalone platform device, since it provides more
flexiblity (also works for hubs connected to a non-root hub) and doesn't require
cooperation from other driver, however I doubt I could convince Rob of the
corresponding DT bindings.
Stephen Boyd Feb. 11, 2021, 7:14 p.m. UTC | #5
Quoting Matthias Kaehlcke (2021-02-10 14:20:18)
> 
> On Wed, Feb 10, 2021 at 10:06:45PM +0100, Krzysztof Kozlowski wrote:
> > 
> > This looks hackish... what if later we have something else than hub?
> > Another if()?
> > 
> > What if hub could be connected to something else than XHCI controller?
> 
> In earlier versions this was standalone driver, which was more flexible and
> didn't require cooperation from the XHCI driver:
> 
> https://lore.kernel.org/patchwork/patch/1313001/
> 
> Rob Herring raised objections about the DT bindings, since the USB hub would be
> represented twice in the DT, once in the USB hierachry (with an explicit node or
> implicitly) plus a node for the platform device for the new driver:
> 
> https://lore.kernel.org/patchwork/patch/1305395/
> https://lore.kernel.org/patchwork/patch/1313000/
> 
> Alan Stern suggested to create the platform device in the XHCI platform driver:
> 
> https://lore.kernel.org/patchwork/patch/1313000/#1510227
> 
> I wasn't super happy about involving xhci-plat, but at least the code is minimal
> and all the device specific stuff is handled by the onboard_usb_hub driver.
> 
> If you have better suggestions that might satisfy all parties please let us
> know :)
> 

Is it possible to use the graph binding to connect the USB controller on
the SoC to the port on the hub? Then the hub would be a standalone node
at the root of DT connected to the USB controller (or phy) and xhci code
could probe the firmware to see if there's a graph connection downstream
that is a powered hub like this. I didn't see this idea mentioned in the
previous discussions, but maybe I missed it.
Matthias Kaehlcke Feb. 11, 2021, 8:36 p.m. UTC | #6
Hi Stephen,

On Thu, Feb 11, 2021 at 11:14:39AM -0800, Stephen Boyd wrote:
> Quoting Matthias Kaehlcke (2021-02-10 14:20:18)

> > 

> > On Wed, Feb 10, 2021 at 10:06:45PM +0100, Krzysztof Kozlowski wrote:

> > > 

> > > This looks hackish... what if later we have something else than hub?

> > > Another if()?

> > > 

> > > What if hub could be connected to something else than XHCI controller?

> > 

> > In earlier versions this was standalone driver, which was more flexible and

> > didn't require cooperation from the XHCI driver:

> > 

> > https://lore.kernel.org/patchwork/patch/1313001/

> > 

> > Rob Herring raised objections about the DT bindings, since the USB hub would be

> > represented twice in the DT, once in the USB hierachry (with an explicit node or

> > implicitly) plus a node for the platform device for the new driver:

> > 

> > https://lore.kernel.org/patchwork/patch/1305395/

> > https://lore.kernel.org/patchwork/patch/1313000/

> > 

> > Alan Stern suggested to create the platform device in the XHCI platform driver:

> > 

> > https://lore.kernel.org/patchwork/patch/1313000/#1510227

> > 

> > I wasn't super happy about involving xhci-plat, but at least the code is minimal

> > and all the device specific stuff is handled by the onboard_usb_hub driver.

> > 

> > If you have better suggestions that might satisfy all parties please let us

> > know :)

> > 

> 

> Is it possible to use the graph binding to connect the USB controller on

> the SoC to the port on the hub? Then the hub would be a standalone node

> at the root of DT connected to the USB controller (or phy) and xhci code

> could probe the firmware to see if there's a graph connection downstream

> that is a powered hub like this. I didn't see this idea mentioned in the

> previous discussions, but maybe I missed it.


Thanks for bringing this up. I'm not sure I completely understand your
suggestion, but in general it seems a direction that could be worth
exploring.

I think something like the following should work even without requiring
cooperation from the XHCI code:

onboard-usb-hub {
    compatible = “realtek,rts5411”, “onboard_usb_hub”;
    #address-cells = <1>;
    #size-cells = <0>;

    vdd-supply = <&pp3300_hub>;

    port@0 {
        reg = <0>;

        rts5411_3_0: endpoint {
            // should not be needed
            remote-endpoint = <&usb_1_dwc3_port1>;
        };
    };

    port@1 {
        reg = <1>;

        rts5411_2_0: endpoint {
            // should not be needed
            remote-endpoint = <&usb_1_dwc3_port2>;
        };
    };
};

&usb_1_dwc3 {
    dr_mode = "host";
    #address-cells = <1>;
    #size-cells = <0>;

    port@1 {
        reg = <1>;

        usb_1_dwc3_port1: endpoint {
            remote-endpoint = <&rts5411_3_0>;
        };
    };

    port@2 {
        reg = <2>;

        usb_1_dwc3_port2: endpoint {
            remote-endpoint = <&rts5411_2_0>;
        };
    };
};

That looks like an actual description of the hardware, without multiple DT
nodes for the hub.

The USB part of the onboard_hub driver could determine the platform device
from the remote endpoint and register the USB device with it.
Stephen Boyd Feb. 11, 2021, 8:45 p.m. UTC | #7
Quoting Matthias Kaehlcke (2021-02-11 12:36:35)
> Hi Stephen,

> 

> On Thu, Feb 11, 2021 at 11:14:39AM -0800, Stephen Boyd wrote:

> > 

> > Is it possible to use the graph binding to connect the USB controller on

> > the SoC to the port on the hub? Then the hub would be a standalone node

> > at the root of DT connected to the USB controller (or phy) and xhci code

> > could probe the firmware to see if there's a graph connection downstream

> > that is a powered hub like this. I didn't see this idea mentioned in the

> > previous discussions, but maybe I missed it.

> 

> Thanks for bringing this up. I'm not sure I completely understand your

> suggestion, but in general it seems a direction that could be worth

> exploring.


Cool.

> 

> I think something like the following should work even without requiring

> cooperation from the XHCI code:

> 

> onboard-usb-hub {

>     compatible = “realtek,rts5411”, “onboard_usb_hub”;

>     #address-cells = <1>;

>     #size-cells = <0>;

> 

>     vdd-supply = <&pp3300_hub>;

> 

>     port@0 {

>         reg = <0>;

> 

>         rts5411_3_0: endpoint {

>             // should not be needed

>             remote-endpoint = <&usb_1_dwc3_port1>;

>         };

>     };

> 

>     port@1 {

>         reg = <1>;

> 

>         rts5411_2_0: endpoint {

>             // should not be needed

>             remote-endpoint = <&usb_1_dwc3_port2>;

>         };

>     };

> };

> 

> &usb_1_dwc3 {

>     dr_mode = "host";

>     #address-cells = <1>;

>     #size-cells = <0>;

> 

>     port@1 {

>         reg = <1>;

> 

>         usb_1_dwc3_port1: endpoint {

>             remote-endpoint = <&rts5411_3_0>;

>         };

>     };

> 

>     port@2 {

>         reg = <2>;

> 

>         usb_1_dwc3_port2: endpoint {

>             remote-endpoint = <&rts5411_2_0>;

>         };

>     };

> };

> 

> That looks like an actual description of the hardware, without multiple DT

> nodes for the hub.

> 

> The USB part of the onboard_hub driver could determine the platform device

> from the remote endpoint and register the USB device with it.


Yeah you got it, this is what I'm suggesting. I'd like to go even
further and also describe the ports on "the other side" or "downstream
facing side" of the USB hub that go to things like type-c ports or
type-a ports. This would allow us to describe the USB topology and how
it is physically connected to ports on the device that humans see. But
that's mostly a job for the type-c subsystem, so it's a parallel
discussion that's only related because of the graph binding.
Rob Herring Feb. 11, 2021, 10:40 p.m. UTC | #8
On Thu, Feb 11, 2021 at 1:14 PM Stephen Boyd <swboyd@chromium.org> wrote:
>

> Quoting Matthias Kaehlcke (2021-02-10 14:20:18)

> >

> > On Wed, Feb 10, 2021 at 10:06:45PM +0100, Krzysztof Kozlowski wrote:

> > >

> > > This looks hackish... what if later we have something else than hub?

> > > Another if()?

> > >

> > > What if hub could be connected to something else than XHCI controller?

> >

> > In earlier versions this was standalone driver, which was more flexible and

> > didn't require cooperation from the XHCI driver:

> >

> > https://lore.kernel.org/patchwork/patch/1313001/

> >

> > Rob Herring raised objections about the DT bindings, since the USB hub would be

> > represented twice in the DT, once in the USB hierachry (with an explicit node or

> > implicitly) plus a node for the platform device for the new driver:

> >

> > https://lore.kernel.org/patchwork/patch/1305395/

> > https://lore.kernel.org/patchwork/patch/1313000/

> >

> > Alan Stern suggested to create the platform device in the XHCI platform driver:

> >

> > https://lore.kernel.org/patchwork/patch/1313000/#1510227

> >

> > I wasn't super happy about involving xhci-plat, but at least the code is minimal

> > and all the device specific stuff is handled by the onboard_usb_hub driver.

> >

> > If you have better suggestions that might satisfy all parties please let us

> > know :)

> >

>

> Is it possible to use the graph binding to connect the USB controller on

> the SoC to the port on the hub? Then the hub would be a standalone node

> at the root of DT connected to the USB controller (or phy) and xhci code

> could probe the firmware to see if there's a graph connection downstream

> that is a powered hub like this. I didn't see this idea mentioned in the

> previous discussions, but maybe I missed it.


An orphan at the root node is exactly what I don't want to see here.
I'm happy with the binding now from a skim of it. The kernel support
does seem kind of hacky though.

Rob
Rob Herring Feb. 11, 2021, 10:46 p.m. UTC | #9
On Thu, Feb 11, 2021 at 2:45 PM Stephen Boyd <swboyd@chromium.org> wrote:
>

> Quoting Matthias Kaehlcke (2021-02-11 12:36:35)

> > Hi Stephen,

> >

> > On Thu, Feb 11, 2021 at 11:14:39AM -0800, Stephen Boyd wrote:

> > >

> > > Is it possible to use the graph binding to connect the USB controller on

> > > the SoC to the port on the hub? Then the hub would be a standalone node

> > > at the root of DT connected to the USB controller (or phy) and xhci code

> > > could probe the firmware to see if there's a graph connection downstream

> > > that is a powered hub like this. I didn't see this idea mentioned in the

> > > previous discussions, but maybe I missed it.

> >

> > Thanks for bringing this up. I'm not sure I completely understand your

> > suggestion, but in general it seems a direction that could be worth

> > exploring.

>

> Cool.

>

> >

> > I think something like the following should work even without requiring

> > cooperation from the XHCI code:

> >

> > onboard-usb-hub {

> >     compatible = “realtek,rts5411”, “onboard_usb_hub”;

> >     #address-cells = <1>;

> >     #size-cells = <0>;

> >

> >     vdd-supply = <&pp3300_hub>;

> >

> >     port@0 {

> >         reg = <0>;

> >

> >         rts5411_3_0: endpoint {

> >             // should not be needed

> >             remote-endpoint = <&usb_1_dwc3_port1>;

> >         };

> >     };

> >

> >     port@1 {

> >         reg = <1>;

> >

> >         rts5411_2_0: endpoint {

> >             // should not be needed

> >             remote-endpoint = <&usb_1_dwc3_port2>;

> >         };

> >     };

> > };

> >

> > &usb_1_dwc3 {

> >     dr_mode = "host";

> >     #address-cells = <1>;

> >     #size-cells = <0>;

> >

> >     port@1 {

> >         reg = <1>;

> >

> >         usb_1_dwc3_port1: endpoint {

> >             remote-endpoint = <&rts5411_3_0>;

> >         };

> >     };

> >

> >     port@2 {

> >         reg = <2>;

> >

> >         usb_1_dwc3_port2: endpoint {

> >             remote-endpoint = <&rts5411_2_0>;

> >         };

> >     };

> > };

> >

> > That looks like an actual description of the hardware, without multiple DT

> > nodes for the hub.

> >

> > The USB part of the onboard_hub driver could determine the platform device

> > from the remote endpoint and register the USB device with it.

>

> Yeah you got it, this is what I'm suggesting. I'd like to go even

> further and also describe the ports on "the other side" or "downstream

> facing side" of the USB hub that go to things like type-c ports or

> type-a ports. This would allow us to describe the USB topology and how

> it is physically connected to ports on the device that humans see. But

> that's mostly a job for the type-c subsystem, so it's a parallel

> discussion that's only related because of the graph binding.


I'd like to see a complete case that includes connectors. I really
need someone to worry about USB bindings with a view on the big
picture. The piecemeal additions don't result in the best design.

Rob
diff mbox series

Patch

diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c
index 4d34f6005381..e785fa109eea 100644
--- a/drivers/usb/host/xhci-plat.c
+++ b/drivers/usb/host/xhci-plat.c
@@ -15,6 +15,7 @@ 
 #include <linux/of.h>
 #include <linux/of_device.h>
 #include <linux/platform_device.h>
+#include <linux/usb/onboard_hub.h>
 #include <linux/usb/phy.h>
 #include <linux/slab.h>
 #include <linux/acpi.h>
@@ -184,6 +185,7 @@  static int xhci_plat_probe(struct platform_device *pdev)
 	int			ret;
 	int			irq;
 	struct xhci_plat_priv	*priv = NULL;
+	struct device_node	*np;
 
 
 	if (usb_disabled())
@@ -356,6 +358,17 @@  static int xhci_plat_probe(struct platform_device *pdev)
 	 */
 	pm_runtime_forbid(&pdev->dev);
 
+	np = usb_of_get_device_node(hcd->self.root_hub, hcd->self.busnum);
+	if (np && of_is_onboard_usb_hub(np)) {
+		struct platform_device *pdev;
+
+		pdev = of_platform_device_create(np, NULL, NULL);
+		if (pdev)
+			hcd->onboard_hub_dev = &pdev->dev;
+		else
+			xhci_warn(xhci, "failed to create onboard hub platform device\n");
+	}
+
 	return 0;
 
 
@@ -402,6 +415,9 @@  static int xhci_plat_remove(struct platform_device *dev)
 	usb_remove_hcd(hcd);
 	usb_put_hcd(shared_hcd);
 
+	if (hcd->onboard_hub_dev)
+		of_platform_device_destroy(hcd->onboard_hub_dev, NULL);
+
 	clk_disable_unprepare(clk);
 	clk_disable_unprepare(reg_clk);
 	usb_put_hcd(hcd);
diff --git a/include/linux/usb/hcd.h b/include/linux/usb/hcd.h
index 96281cd50ff6..d02a508e19b0 100644
--- a/include/linux/usb/hcd.h
+++ b/include/linux/usb/hcd.h
@@ -225,6 +225,8 @@  struct usb_hcd {
 	 * (ohci 32, uhci 1024, ehci 256/512/1024).
 	 */
 
+	struct device *onboard_hub_dev;
+
 	/* The HC driver's private data is stored at the end of
 	 * this structure.
 	 */