[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