09:33 <DuClare> So uh

09:34 <DuClare> There's pdata support in ehci-platform but from the looks of it, it's hardly used anywhere

09:36 <DuClare> Is that right? Instead of defining platform data, the way of the land is to start with a tweaked copy of ehci-platform.c and call it a new driver?

10:23 <eballetbo[m]> Hi, I'm having some problems trying to switch between USB roles on my kevin, trying to debug a little bit the issue and having a USB hub connected I just noticed that the driver of the usb phyter is reporting OTG_STATE_B_IDLE instead of OTG_STATE_A_HOST, that looks weird to me but the port is working ... anyone knows about this?

11:33 <DuClare> mmind00: Am I going to make a copy of the ehci platform driver just so I can poke a register or two? Or do I add pdata?

11:34 <DuClare> I get the impression that pdata is discouraged

11:47 <mmind00> DuClare: I'd think the copy might be the way to go ... i.e. pdata is mostly from the time where boards where defined in c-board-files, so there isn't really a way to infer that from the devicetree

11:48 <DuClare> Yea

11:49 <DuClare> Kinda weird to see a whole bunch of these copies though.. especially since most of them do the same thing, more or less, and ehci-platform has most of the right hooks for the custom bits

11:50 <DuClare> Another thing I worry about is how'd you differentiate between the different types of phy?

11:51 <DuClare> phy-rockchip-usb assumes they are all alike, poking the same bits in each phy's corresponding register

11:51 <DuClare> But that is not right for hsic

11:52 <mmind00> DuClare: you want a separate phy-driver ... like phy-rockchip-hsic or so

11:52 <DuClare> Aha

11:52 <mmind00> DuClare: i.e. you can see multiple phys already ... phy-rockchip-usb is used for the Designware blocks, phy-rockchip-usb2 is used by the Innosilicon usb2 phys, etc

11:53 <DuClare> I see

11:53 <mmind00> (correction, phy-rockchip-inno-usb2 of course)

12:00 <DuClare> I don't think I have any way to test or verify that any of the CONFIG_PM_SLEEP bits work properly.. so is it better to leave that code out entirely?

12:09 <mmind00> DuClare: if it's just a copy of the generic ehci driver, you should be able to leave it in

12:16 <DuClare> I guess it can be a straight copy, or a stripped down copy without all the parts that try to make it generic (and which don't really apply in this case)

12:19 <DuClare> I don't know if it's cool to duplicate all the generic driver logic if it's never going to be used with this driver? Although I suppose the suspend parts could be left in

12:29 <mmind00> DuClare: generic stuff like these then unused hook-function-calls should not be copied of course

12:32 <DuClare> Right

22:33 <willmore> Hello, all!

22:33 <willmore> What is the general impression of the Tinker Board?

23:51 <hanetzer> apparently it has some wierd emmc lockup on reboot :P