Re: [PATCH v7 1/7] usb: move the OTG state from the USB PHY to the OTG structure

[Felipe Balbi]

Hi,

On Fri, Oct 31, 2014 at 02:55:35PM +0100, Antoine Tenart wrote:
> > > > > > > > > > Before using the PHY framework instead of the USB
> > > > > > > > > > PHY one, we need to move the OTG state into another
> > > > > > > > > > place, since it won't be available when USB PHY
> > > > > > > > > > isn't used. This patch moves the OTG state into the
> > > > > > > > > > OTG structure, and makes all the needed
> > > > > > > > > > modifications in the drivers using the OTG state.
> > > > > > > > > > 
> > > > > > > > > > Signed-off-by: Antoine Tenart <antoine.tenart@xxxxxxxxxxxxxxxxxx>
> > > > > > > > > > Acked-by: Peter Chen <peter.chen@xxxxxxxxxxxxx>
> > > > > > > > > 
> > > > > > > > > Acked-by: Felipe Balbi <balbi@xxxxxx>
> > > > > > > > 
> > > > > > > > Please rebase on my testing/next and I'll take the
> > > > > > > > series. When rebasing, then add Peter's
> > > > > > > > Tested-by/Acked-by where they're missing.
> > > > > > > 
> > > > > > > I just re-sent the series, rebased on your testing/next
> > > > > > > branch.
> > > > > > 
> > > > > > Thanks, I put them on my testing/next and I'm running build
> > > > > > tests.
> > > > > > 
> > > > > 
> > > > > I see them, I will rebase your testing/next tree for coming
> > > > > chipidea dev, thanks.
> > > > 
> > > > I fixed a build breakage caused by $subject which I fixed,
> > > > updated patch below: (Aaro, can I get a tested-by by any chance
> > > > ?)
> > > 
> > > two more build regressions found (did you build test your patches
> > > ??)
> > 
> > and yet another one on phy-isp1301-omap.c. Seriously, if I find
> > another build regression I'll drop your series from my queue and
> > defer it to 3.20. This is ridiculous already.
> 
> Sorry for the inconvenience, the series modify quite a lot of files
> and testing all of them is quite difficult. If you'd like I can fully
> test

how come ? build testing is difficult ? if you have x86 and ARM
compilers you can build all of these modules with make allmodconfig.

You know, I have a very a simple 20-line script running randconfigs and
saving the output, after that I just grep for "error" on the logs and
look at what's broken.

> it and send a new version early next week.
> 
> Deferring it to 3.20 will not solve the issue and will raise the same
> errors as these build failures. The series has been sent for quite a
> long time now, without having any comments on the latests revisions
> and was therefore delayed. Each time it is delayed, it makes it more
> difficult to ensure everything is working fine because of all the
> modifications done in this subsystem... I tried to keep it up with all
> the other patches introduced between my revisions, but this is not as
> easy as it sounds.

all the places I fixed haven't been touched for months, in some cases
years. This is a broken argument.

> Again, sorry for these failures, I can send to you a new version early
> next week so that no other patches comes in between, breaking the
> build...

nevermind, I already fixed so many of these mistakes anyway, it's
probably all clean now.

-- 
balbi

Attachment: signature.asc
Description: Digital signature