| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <550AA591.2080703@ti.com> Date: Thu, 19 Mar 2015 12:31:45 +0200 From: Roger Quadros <rogerq@...com> To: Tony Lindgren <tony@...mide.com> CC: <gregkh@...uxfoundation.org>, <balbi@...com>, <stern@...land.harvard.edu>, <dan.j.williams@...el.com>, <peter.chen@...escale.com>, <jun.li@...escale.com>, <mathias.nyman@...ux.intel.com>, <linux-usb@...r.kernel.org>, <linux-kernel@...r.kernel.org>, <linux-omap@...r.kernel.org> Subject: Re: [RFC][PATCH 0/9] USB: OTG Core functionality On 18/03/15 19:37, Tony Lindgren wrote: > * Roger Quadros <rogerq@...com> [150318 07:00]: >> Hi, >> >> [NOTE: RFC only. Not for merge yet.] >> >> This is an attempt to centralize OTG functionality in the kernel. >> Still work in progress but I wanted to get an early feedback >> to avoid major rework. :) >> >> Why?: >> ---- >> >> Most of the OTG drivers have been dealing with the OTG state machine >> themselves and there is a scope for code re-use. This has been >> partly addressed by the usb/common/usb-otg-fsm.c but it still >> leaves the instantiation of the state machine and OTG timers >> to the controller drivers. We re-use usb-otg-fsm.c but >> go one step further by instantiating the state machine and timers >> thus making it easier for drivers to implement OTG functionality. >> >> Newer OTG cores support standard host interface (e.g. xHCI?) so >> host and gadget functionality are no longer closely knit like older >> cores. There needs to be a way to co-ordinate the operation of the >> host and gadget in OTG mode. i.e. to stop and start them from a >> central location. This central location should be the USB OTG core. >> >> Host and gadget controllers might be sharing resources and can't >> be always running. One has to be stopped for the other to run. >> This can't be done as of now and can be done from the OTG core. >> >> What?: >> ----- >> >> The OTG core instantiates the OTG Finite State Machine >> per OTG controller and manages starting/stopping the >> host and gadget controllers based on the bus state. >> >> It provides APIs for the following >> >> - Registering an OTG capable controller >> struct otg_fsm *usb_otg_register(struct device *parent_dev, >> struct otg_fsm_ops *fsm_ops); >> int usb_otg_unregister(struct device *parent_dev); >> >> - Registering Host controllers to OTG core (used by hcd-core) >> int usb_otg_register_hcd(struct usb_hcd *hcd); >> int usb_otg_unregister_hcd(struct usb_hcd *hcd); >> >> - Registering Gadget controllers to OTG core (used by udc-core) >> int usb_otg_register_gadget(struct usb_gadget *gadget); >> int usb_otg_unregister_gadget(struct usb_gadget *gadget); >> >> - Providing inputs to and kicking the OTG state machine >> void usb_otg_sync_inputs(struct otg_fsm *fsm); >> int usb_otg_kick_fsm(struct device *hcd_gcd_device); >> >> 'struct otg_fsm' is the interface to the OTG state machine. >> It contains inputs to the fsm, status of the fsm and operations >> for the OTG controller driver. > > Sounds good to me. I take you're also planning to provide some > common /sys/kernel/debug/otg type interfaces for OTG validation > tests? For things like SRP etc. Yes that's the plan. cheers, -roger > > Regards, > > Tony > >> Usage model: >> ----------- >> >> - The OTG controller device is assumed to be the parent of >> the host and gadget controller. It must call usb_otg_register() >> before populating the host and gadget devices so that the OTG >> core is aware that it is an OTG device before the host & gadget >> register. The OTG controller must provide struct otg_fsm_ops * >> which will be called by the OTG core depending on OTG bus state. >> >> - The host/gadget core stacks are modified to inform the OTG core >> whenever a new host/gadget device is added. The OTG core then >> checks if the host/gadget is part of the OTG controller and if yes >> then prevents the host/gadget from starting till both host and >> gadget are registered, OTG state machine is running and the >> USB bus state is appropriate to start host/gadget. >> For this APIs have been added to host/gadget stacks to start/stop >> the controllers from the OTG core. >> >> - No modification is needed for the host/gadget controller drivers. >> They must ensure that their start/stop methods can be called repeatedly >> and any shared resources between host & gadget are properly managed. >> The OTG core ensures that both are not started simultaneously. >> >> - The OTG core instantiates one OTG state machine per OTG >> controller and the necessary OTG timers to manage OTG state timeouts. >> The state machine is started when both host & gadget register and >> stopped when either of them unregisters. The controllers are started >> and stopped depending on bus state. >> >> - During the lifetime of the OTG state machine, inputs can be >> provided to it by modifying the appropriate members of 'struct otg_fsm' >> and calling usb_otg_sync_inputs(). This is typically done by the >> OTG controller driver that called usb_otg_register() since it is >> the only external component that has the 'struct otg_fsm' handle. >> >> Pending items: >> - We probably need a otg class. >> - sysfs interface for application OTG inputs and OTG status information >> - resolve symbol dependency for module use. >> - otg driver for dwc3 core to get dual-role working on dra7-evm. >> >> cheers, >> -roger >> >> Roger Quadros (9): >> usb: hcd: Introduce usb_start/stop_hcd() >> usb: gadget: add usb_gadget_start/stop() >> usb: otg: add OTG core >> usb: otg: hub: Notify OTG fsm when A device sets b_hnp_enable >> usb: hcd: adapt to OTG >> usb: gadget: udc: adapt to OTG >> usb: dwc3: adapt to OTG core >> usb: otg-fsm: Remove unused members in struct otg_fsm >> usb: otg-fsm: Add documentation for struct otg_fsm >> >> drivers/usb/Makefile | 1 + >> drivers/usb/common/Makefile | 1 + >> drivers/usb/common/usb-otg.c | 732 ++++++++++++++++++++++++++++++++++++++ >> drivers/usb/common/usb-otg.h | 71 ++++ >> drivers/usb/core/Kconfig | 8 + >> drivers/usb/core/hcd.c | 153 +++++--- >> drivers/usb/core/hub.c | 11 +- >> drivers/usb/dwc3/core.c | 101 ++++++ >> drivers/usb/dwc3/core.h | 6 + >> drivers/usb/dwc3/platform_data.h | 1 + >> drivers/usb/gadget/udc/udc-core.c | 172 ++++++++- >> include/linux/usb/gadget.h | 3 + >> include/linux/usb/hcd.h | 2 + >> include/linux/usb/otg-fsm.h | 81 ++++- >> include/linux/usb/usb-otg.h | 86 +++++ >> 15 files changed, 1357 insertions(+), 72 deletions(-) >> create mode 100644 drivers/usb/common/usb-otg.c >> create mode 100644 drivers/usb/common/usb-otg.h >> create mode 100644 include/linux/usb/usb-otg.h >> >> -- >> 2.1.0 >> >> -- >> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in >> the body of a message to majordomo@...r.kernel.org >> More majordomo info at http://vger.kernel.org/majordomo-info.html >> Please read the FAQ at http://www.tux.org/lkml/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists