[RFC PATCH 2/3] usb: udc: delete the vbus indicator at individual driver

Peter Chen peter.chen at freescale.com
Wed Mar 13 03:49:19 EDT 2013


On Wed, Mar 13, 2013 at 09:44:09AM +0200, Felipe Balbi wrote:
> On Wed, Mar 13, 2013 at 11:10:43AM +0800, Peter Chen wrote:
> > On Tue, Mar 12, 2013 at 11:46:49AM +0200, Felipe Balbi wrote:
> > > On Tue, Mar 12, 2013 at 05:03:18PM +0800, Peter Chen wrote:
> > > > Let the common struct usb_gadget own it.
> > > > 
> > > > CC: Alexander Shishkin <alexander.shishkin at linux.intel.com>
> > > > CC: Jean-Christophe PLAGNIOL-VILLARD <plagnioj at jcrosoft.com>
> > > > CC: Li Yang <leoli at freescale.com>
> > > > CC: Roland Stigge <stigge at antcom.de>
> > > > CC: Yu Xu <yuxu at marvell.com>
> > > > CC: Chao Xie <chao.xie at marvell.com>
> > > > CC: Eric Miao <eric.y.miao at gmail.com>
> > > > CC: Ben Dooks <ben-linux at fluff.org>
> > > > Signed-off-by: Peter Chen <peter.chen at freescale.com>
> > > 
> > > you need to split this patch, should be something like below:
> > > 
> > > for_each_driver() {
> > > 	initialize gadget->vbus_active (don't remove private method)
> > > }
> > > 
> > > add vbus_active support to udc-core
> > > 
> > > for_each_driver() {
> > > 	remove driver's private vbus_active method
> > > }
> > > 
> > > you need one patch per driver so it's easy to review and ack.
> > 
> > Eg, If I changed 10 udc drivers, I need
> > 1(add vbus_active to struct usb_gadget) + 10 + 1 + 10 = 22 patches?
> 
> in order to keep possible regressions localized to a single driver.
> Imagine if you cause a regression on omap_udc, then we decide to revert
> your patch. All other drivers, which can be correct will loose the
> change as well.


I agree, why we can't merge below two steps into one step, if there
are problems for single driver, we also need to revert one patch.

> > > for_each_driver() {
> > > 	initialize gadget->vbus_active (don't remove private method)
> > > }
> > > for_each_driver() {
> > > 	remove driver's private vbus_active method
> > > }


> 
> -- 
> balbi



-- 

Best Regards,
Peter Chen




More information about the linux-arm-kernel mailing list