On 10 March 2017 at 14:30, Jun Li <jun.li@xxxxxxx> wrote: >> >> > >> >> > Will generic phy need add extcon as well? >> >> >> >> Yes, will add a 'struct extcon_dev*' in 'struct usb_phy', which will >> >> be common code. >> >> >> > >> > I mean the common code need add 'struct extcon_dev' into both 'struct >> > phy' and 'struct usb_phy', right? as some/new usb phy use that generic phy >> driver. >> >> Ah, you remind me. Seems we need also add one 'struct extcon_dev' into >> 'struct phy'. >> >> >> > >> >> >> > >> >> >> >> Secondly, I also agreed with Peter's comments: Not only USB PHY >> >> >> >> to register an extcon, but also for the drivers which can >> >> >> >> detect USB charger type, it may be USB controller driver, USB >> >> >> >> type-c driver, pmic driver, and these drivers may not have an >> >> >> >> extcon device since the internal part can finish the vbus detect. >> >> >> > >> >> >> > Whichever part can detect vbus, the driver for that part must be >> >> >> > able to find the extcon and trigger a notification. >> >> >> > Maybe one part can detect VBUS, another can measure the >> >> >> > resistance on ID and a third can work through the state machine >> >> >> > to determine if D+ and D- are shorted together. >> >> >> > Somehow these three need to work together to determine what is >> >> >> plugged >> >> >> > in to the external connection port. Somewhere there much an >> 'extcon' >> >> >> > device which represents that port and which the three devices >> >> >> > can find and can interact with. >> >> >> > I think it makes sense for the usb_phy to be the connection point. >> >> >> > Each of the devices can get to the phy, and the phy can get to >> >> >> > the >> >> extcon. >> >> >> > It doesn't matter very much if the usb phy driver creates the >> >> >> > extcon, or if something else creates the extcon and the phy >> >> >> > driver performs a lookup to find it (e.g. based on devicetree info). >> >> >> > >> >> >> > The point is that there is obviously an external physical >> >> >> > connection, and so there should be an 'extcon' device that >> represents it. >> >> >> >> >> >> Peter & Jun, is it OK for you every phy has one extcon device to >> >> >> receive VBUS notification, especially for detecting the charger >> >> >> type by >> >> software? >> >> >> >> >> > >> >> > My understanding is phy/usb_phy as the connection point, will send >> >> > the notification to PMIC driver which actually control the charge >> >> > current, also this will be done in your common framework, right? >> >> >> >> Not in USB charger framework. If we are all agree every usb_phy can >> >> register one extcon device, can get correct charger type and send out >> >> correct vbus_draw information, then we don't need USB charger >> >> framework as Neil suggested. So this will be okay for your case >> >> (especially for detecting the charger type by software) ? >> > >> > In my case, charger detection is done by controller driver and I need >> > do charger type detection internally, and only pass the current draw >> > info via phy which will send out, this seems ok for me, but I think it >> > will be good if you or someone can show us an example user based on the >> design Neil suggested. >> > Will you work out that common code if this USB charger framework is not >> needed? >> >> I will add a 'struct extcon_dev*' in 'struct usb_phy' and struct phy“. Others >> are already ready if everyone has no complain about current design, except > > Only adding extcon_dev into usb_phy/phy and all others are ready? > My understanding you will also do: > - We need find a central place to send the notification(phy common part). That will include these implementation when adding extcon_dev. > - If the extcon_dev is directly added in usb_phy/phy, PMIC needs some API to findup it. PMIC can find extcon device by phandle. > >> my one concern. (I am afraid if it is enough to send out vbus draw >> information from USB phy driver, for example you will miss super speed >> (900mA), which need get the speed information from gadget driver.) >> > > Can we handle this in USB(so has super speed information) and just send out > 900mA directly? >From Neil's suggestion, we only have one place to send out current information from usb phy, so I have this concern and doubt if we still need the USB charger framework. -- Baolin.wang Best Regards -- 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
