Fwd: [PATCH 2/5] ARM: OMAP3+: hwmod: Add AM33XX HWMOD data for davinci_mdio

Hiremath, Vaibhav hvaibhav at ti.com
Fri Oct 26 04:23:18 EDT 2012

On Fri, Oct 19, 2012 at 21:30:41, Tony Lindgren wrote:
> * Richard Cochran <richardcochran at gmail.com> [121018 23:18]:
> > On Fri, Oct 19, 2012 at 02:18:29AM +0530, Vaibhav Hiremath wrote:
> > > 
> > > Another important point is, this driver is also required and used for
> > > Davinci family of devices (arch/mach/mach-davinci/).
> > 
> > That is really beside the point. If the code isn't ready yet, then
> > don't merge it.
> > 
> > When I asked about the beaglebone, I was given the impression that it
> > will be ready for v3.7-rc1.  But, as I know realize, at the current
> > rate, it might not even be ready for v3.8.
> > 
> > I don't mind waiting, but please make sure that whatever lands into a
> > release is really, truly working.
> Indeed. This has been a problem with many of the TI patches in
> general. People are working on separate product trees and then produce
> patches for the mainline kernel that are poorly tested.


It may not be true always, as we always work simultaneously and there are 
high chances that some patches/development is dependent on others from 
functionality perspective (especially baseport), but still they are 
independent modules (may be for other devices).

Lets take a example of AM33xx and OMAP5 here, we started submitting baseport 
patches to the list (almost 6-8 months now), not all the patches gets 
accepted together in one shot.
As you know, when we started pushing AM33xx and OMAP5 baseport patches, we 
were at the stage where both DT and hwmod was required. First attempt for 
board file submission did not went through, since we decided to force all 
new devices migrate to DT, right?

So the criteria initially was, build should not break and submit patches 

Now, with baseport patches submitted to list, individual developer can also 
start submitting patches to the respective driver's list, making sure that, 
driver doesn't change irrespective of platform. I do not see anything wrong
with this, as we always consider driver independent.

In this particular case, note that, all the patches Richard posted recently 
are AM33xx SoC integration specific patches only.


More information about the linux-arm-kernel mailing list