Re: [GIT PULL] Move device tree graph parsing helpers to drivers/of

[Sylwester Nawrocki]

On 13/03/14 12:35, Russell King - ARM Linux wrote:
[...]
> Grant and myself have exchanged emails in private on this discussing what
> should happen - essentially Grant's position is that he's happy to leave
> this stuff queued provided a resolution to his concerns are forthcoming.
> 
> However, what I find incredibly unfair is that we're taking the rap for
> these bad bindings.  From what I can see, these bad bindings were merged
> into the V4L2 code with _zero_ review by DT maintainers.  It's quite
> clear that DT maintainers would have objected to them had they seen them,

Russell, it's just unfair what you're trying to impute here.  These 
bindings were floating on the mailing list for _several_ months before 
getting merged.
They were finally acked by Rob and Grant [1], [2], however it cannot be 
seen from the commits as the Ack come late, after I sent a pull request.

> but they didn't.  And the lack of documentation of the bindings which
> has been something that's been insisted on is also disgusting.
>
> And now we're now taking the pain for that oversight.
> 
> So... frankly, I've walked away from this dysfunctional situation.  I
> don't see imx-drm moving out of drivers/staging due to this debacle for
> many months - possibly never now given that no one can agree on this
> stuff.  This just goes to show what a fscking joke mainline kernels are,
> and why people just give up and go to vendor kernels which offer /much/
> better support all round.
> 
> As far as I can see, it's proved impossible to define a set of bindings
> for display devices which satisfy everyone.  So, rather than doing
> /something/ so we can move forward, we end up doing /nothing/.
> 
> It's times like this where I start believing that /board files/ were the
> best solution for ARM, because DT just carries soo many thorny issues
> (such as these) and is a continual blocker.

My experience and feelings are similar, I started to treat mainline
kernel much less seriously after similar DT related blocking issues.
An example is a simple patch series for couple drivers that was first 
posted in July 2013 and is still not merged, because the subsystem 
maintainer requires a DT binding maintainer Ack for everything and you
can wait to death to get one, specially if there are multiple iterations,
each needing attention of a DT binding maintainer. I remember opinions, 
when the process was being defined during one of the last kernel summits, 
that things may get longer to merge upstream, due to DT binding reviews. 
And that we must live with that. But these latencies are getting so 
ridiculously large that there is nothing left but to move to an 
alternative process.

Regarding moving forward doing /something/, rather than ending up
doing nothing - IMO it's the worst thing to rush DT binding being
merged upstream. I don't think an agreement can't be achieved soon, 
if not for this release then hopefully for next one.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/