> From: Felipe Balbi [mailto:balbi@xxxxxx] > Sent: Thursday, March 01, 2012 12:45 AM > > Hi, > > On Tue, Feb 28, 2012 at 06:06:38PM -0800, Paul Zimmerman wrote: > > > > > You could split the PCI address space into DWC USB3 IP specific and the > > > > > rest (which is HAPS specific), unless you're mapping your HAPS-specific > > > > > part on an unused area of the DWC USB3 IP address space, then, well, we > > > > > need to think how to handle it. > > > > > > > > I played around with that, but it was really ugly, and there were still > > > > problems because 'struct dwc3' was not accessible from dwc3-pci. > > > > > > > > Let me cook up an RFC patch for the modifications I have in mind. Code > > > > talks, after all :) It might take me a few days, I have some higher- > > > > priority stuff going on right now. > > > > > > Sure, go ahead ;-) I'll go over the other patches you sent meanwhile. > > > > Hi Felipe, > > > > I think I found a less invasive way to do what I need, by defining a > > platform_data struct for the dwc3 device, so that it can share function > > that won't fly. We're all moving to devicetree so that will not work > properly :-( Ah, so maybe my more invasive approach, which eliminates the platform device for the dwc3 module, would be the best way after all. It results in an overall reduction in the lines of code, too. > > pointers and the dwc3 context with the bus glue. Below is a POC patch > > to show roughly what I plan to do. Is this an acceptable use of platform > > data? > > The way you use to pass function pointers is ok (if we weren't concerned > about devicetree), but using it to pass dwc3 pointer back to glue layer > isn't very wise and we have proven that with MUSB. > > > If so, maybe we could also remove the dwc3_{get|put}_device_id functions > > and just have dwc3_probe write the devid into the platform_data? Then we > > could get rid of those two exported functions. > > We need the ID before dwc3 platform_device is added to driver core, > otherwise dwc3's probe() won't be called. Another issue with the ID is > that as soon as you add the platform_device to the driver model, sysfs > files will be created and if we don't have a unique name at that time > ($name.$id) we could try to create directories which already exist. Yeah, I noticed after I sent the email that we need the ID in order to allocate the platform device. So never mind about that. > One thing that I still didn't understand and you didn't answer when I > asked, if why you don't do the haps_power_control from the dwc3-pci.c > file ? I already explained that a couple of times. But anyway, I have talked to the hardware guys, and they are willing to look at redesigning the PME mechanism to use the standard PCIe methods. So let's put this discussion on hold until they have done that, and I have a chance to experiment with making that work. -- Paul -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
