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

From: Sylwester Nawrocki
Date: Thu Mar 13 2014 - 11:37:54 EST


On 13/03/14 16:13, Sylwester Nawrocki wrote:
> 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.

Sorry about the missing links:

[1] http://www.spinics.net/lists/linux-media/msg61899.html
[2] http://www.spinics.net/lists/linux-media/msg62458.html

--
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/