lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Mon, 17 Mar 2014 22:27:36 +0000
From:	Russell King <rmk@....linux.org.uk>
To:	Mauro Carvalho Chehab <mchehab@...radead.org>
Cc:	Greg KH <greg@...ah.com>, Stephen Rothwell <sfr@...b.auug.org.au>,
	linux-next@...r.kernel.org, linux-kernel@...r.kernel.org,
	Philipp Zabel <p.zabel@...gutronix.de>,
	Sylwester Nawrocki <s.nawrocki@...sung.com>,
	Laurent Pinchart <laurent.pinchart@...asonboard.com>,
	Grant Likely <grant.likely@...aro.org>,
	Mauro Carvalho Chehab <m.chehab@...sung.com>
Subject: Re: linux-next: manual merge of the staging tree with the v4l-dvb
	tree

On Mon, Mar 17, 2014 at 04:29:37PM -0300, Mauro Carvalho Chehab wrote:
> Em Mon, 17 Mar 2014 11:29:53 -0700
> Greg KH <greg@...ah.com> escreveu:
> 
> > On Mon, Mar 17, 2014 at 08:01:22AM -0300, Mauro Carvalho Chehab wrote:
> > > Em Mon, 17 Mar 2014 18:55:42 +1100
> > > Stephen Rothwell <sfr@...b.auug.org.au> escreveu:
> > > 
> > > > Hi Greg,
> > > > 
> > > > Today's linux-next merge of the staging tree got a conflict in
> > > > drivers/media/platform/exynos4-is/fimc-is.c between commit d265d9ac6c7c
> > > > ("[media] exynos4-is: Use external s5k6a3 sensor driver") from the
> > > > v4l-dvb tree and commit fd9fdb78a9bf ("[media] of: move graph helpers
> > > > from drivers/media/v4l2-core to drivers/of") from the staging tree.
> > > > I fixed it up (see below, though I suspect it is wasted?) and can carry
> > > > the fix as necessary (no action is required).
> > > 
> > > I used to have those OF patches on my tree, but I was forced to remove,
> > > as Grant rejected the patches. After his nack, lots of dicussions about
> > > the DT bindings started and, until last week, there were no consensus
> > > about that (as far as I followed the discussions).
> > > 
> > > So, reluctantly, I just dropped this series from my tree, pretending
> > > it never existed, as reverting them could cause troubles if it 
> > > (or some version of it) got merged via Greg, Grant and/or Russell
> > > trees.
> > > 
> > > On my head, it become too late to merge it for 3.15, as first
> > > people must agree on the DT bindings. Also, I already closed the
> > > media merge window, as -rc7 seems to be the last -rc.
> > > 
> > > One possible approach for this would be to merge the patches that move
> > > the OF graph code away from drivers/media, and the corresponding
> > > internal ABI changes early at -rc, and applying the DT binding
> > > patches, and the staging imx-drm driver for 3.16.
> > 
> > I don't understand, was I supposed to do something in my staging-next
> > tree for this as well?
> > 
> > totally confused,
> 
> Hi Greg,
> 
> Let me summarize what was discussed so far with regards to it.
> 
> There are two changesets related to this:
> - a 6 patch series moving OF graph functions from
>   /drivers/media to /drivers/of;
> - a 12 patch series (at version 11 - not sure if are there any
>   newer version) that adds the imx-drm driver to staging.

No, it's not adding the imx-drm driver to staging, that driver has been
there for getting on for 18 months.  What Grant's nack does is destroy
the work which both Philipp and myself have put in to try and get this
out of staging for (maybe) 3.16.

The individual status of the patches are:

  of: move graph helpers from drivers/media/v4l2-core to drivers/of

"This patch is fine because it only moves code, but I'm not providing an
 ack yet.  I'll supply one when I'm happy with the collection of fixups."

though there is more discussion of a previous patch version.

  Documentation: of: Document graph bindings

"See my comments on the previous version. My concerns are the handling of
 the optional 'ports' node and the usage of reverse links."

The odd thing is that this patch is only documenting what is /already/ in
the kernel, and has /already/ been reviewed by Grant and Rob as DT
maintainers as part of the v4l2 OF graph parsing code.  It's rather late
to object to it now.

Grant has subsequently acked all these cleanup patches:

  of: Warn if of_graph_get_next_endpoint is called with the root node
  of: Reduce indentation in of_graph_get_next_endpoint
  of: move common endpoint parsing to drivers/of

The following was totally ignored, even though it was a simple patch:

  of: Warn if of_graph_parse_endpoint is called with the root node

and the last patch is a build fix for the previous patches.

And to top it off, Grant seems to have gone non-responsive again during
the last week.

Now, what Grant's most recent response (10 March) said was:
| It means any tree containing that branch *must* be rewound. See my reply
| to rmk. I've made a proposal on how I could be happy with leaving the
| branches alone. I'm not particularly happy, but there is a way to
| resolve things without reverts or rewinds.

What Grant doesn't realise is that his last reply to me was in response to
an email I sent privately to Grant, so the reply is private.  Policy is
not to share private emails publically.

It was based upon solving Grant's objections, which as agreement hasn't
been reached, hasn't happened.

However, I still find myself coming back to a fundamental question: why
were these bindings fine in April 2013, passed review, and were acked,
but not fine today.  Here's the links to the emails acking their
introduction which Sylwester Nawrocki sent me:

  http://www.spinics.net/lists/linux-media/msg61899.html
  http://www.spinics.net/lists/linux-media/msg62458.html

So... *shrug*.  Make of this what you will.

-- 
Russell King
ARM architecture Linux Kernel maintainer
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ