linux-next: manual merge of the staging tree with the v4l-dvb tree

linux-next: manual merge of the staging tree with the v4l-dvb tree

[Stephen Rothwell]

Hi Greg,

Today's linux-next merge of the staging tree got a conflict in
drivers/staging/Kconfig between commit
a1256092a1e87511c977a3d0ef96151cda77e5c9 ("[media] Altera FPGA firmware
download module") from the v4l-dvb tree and commit
0867b42113ec4eb8646eb361b15cbcfb741ddf5b ("staging: gma500: Intel GMA500
staging driver") from the staging tree.

I fixed it up (see below) and can carry the fix as necessary.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

diff --cc drivers/staging/Kconfig
index 1ae0c1b,5295d85..0000000
--- a/drivers/staging/Kconfig
+++ b/drivers/staging/Kconfig
@@@ -179,7 -177,7 +177,9 @@@ source "drivers/staging/cptm1217/Kconfi
  
  source "drivers/staging/ste_rmi4/Kconfig"
  
 +source "drivers/staging/altera-stapl/Kconfig"
 +
+ source "drivers/staging/gma500/Kconfig"
+ 
  endif # !STAGING_EXCLUDE_BUILD
  endif # STAGING

Re: linux-next: manual merge of the staging tree with the v4l-dvb tree

[Greg KH]

On Fri, Mar 04, 2011 at 04:39:05PM +1100, Stephen Rothwell wrote:
> Hi Greg,
> 
> Today's linux-next merge of the staging tree got a conflict in
> drivers/staging/Kconfig between commit
> a1256092a1e87511c977a3d0ef96151cda77e5c9 ("[media] Altera FPGA firmware
> download module") from the v4l-dvb tree and commit
> 0867b42113ec4eb8646eb361b15cbcfb741ddf5b ("staging: gma500: Intel GMA500
> staging driver") from the staging tree.
> 
> I fixed it up (see below) and can carry the fix as necessary.

That looks correct.

Mauro, what is this driver and why is it added to the staging tree?

curious,

greg k-h

Re: linux-next: manual merge of the staging tree with the v4l-dvb tree

[Mauro Carvalho Chehab]

Hi Greg,

Em 04-03-2011 14:13, Greg KH escreveu:
> On Fri, Mar 04, 2011 at 04:39:05PM +1100, Stephen Rothwell wrote:
>> Hi Greg,
>>
>> Today's linux-next merge of the staging tree got a conflict in
>> drivers/staging/Kconfig between commit
>> a1256092a1e87511c977a3d0ef96151cda77e5c9 ("[media] Altera FPGA firmware
>> download module") from the v4l-dvb tree and commit
>> 0867b42113ec4eb8646eb361b15cbcfb741ddf5b ("staging: gma500: Intel GMA500
>> staging driver") from the staging tree.
>>
>> I fixed it up (see below) and can carry the fix as necessary.
> 
> That looks correct.
> 
> Mauro, what is this driver and why is it added to the staging tree?

This driver implements the FPGA programming logic for a firmware required
by a DVB driver, and was proposed initially for 2.6.37 inclusion. During the
2.6.38 development cycle, it suffered several revisions, based on our input
at the media and lkml mailing lists, where Igor fixed all CodingStyle issues.

In the last minute, during 2.6.38 merge window, two developers (Laurent and Ben) 
[1] complained against adding a driver for loading FPGA firmware as-is. So, I
decided to add it, for now, at staging, to avoid needing to postpone a long series 
of patches again just because of that, especially since a series of DVB-C devices
are without support on Linux without this patch series, and there are very few
DVB-C devices currently supported.

The Altera driver is compliant with CodingStyle, and, from my side, it is ok
to move it to drivers/others, but it doesn't hurt to give some time for Ben and 
Laurent to propose alternative way of implementing the firmware request logic.

If nothing happens until 2.6.40 merge window, I think we should go forward and
move it to the proper place.

Cheers,
Mauro

[1] http://www.mail-archive.com/linux-media@vger.kernel.org/msg26422.html

Re: linux-next: manual merge of the staging tree with the v4l-dvb tree

[Greg KH]

On Fri, Mar 04, 2011 at 02:54:24PM -0300, Mauro Carvalho Chehab wrote:
> Hi Greg,
> 
> Em 04-03-2011 14:13, Greg KH escreveu:
> > On Fri, Mar 04, 2011 at 04:39:05PM +1100, Stephen Rothwell wrote:
> >> Hi Greg,
> >>
> >> Today's linux-next merge of the staging tree got a conflict in
> >> drivers/staging/Kconfig between commit
> >> a1256092a1e87511c977a3d0ef96151cda77e5c9 ("[media] Altera FPGA firmware
> >> download module") from the v4l-dvb tree and commit
> >> 0867b42113ec4eb8646eb361b15cbcfb741ddf5b ("staging: gma500: Intel GMA500
> >> staging driver") from the staging tree.
> >>
> >> I fixed it up (see below) and can carry the fix as necessary.
> > 
> > That looks correct.
> > 
> > Mauro, what is this driver and why is it added to the staging tree?
> 
> This driver implements the FPGA programming logic for a firmware required
> by a DVB driver, and was proposed initially for 2.6.37 inclusion. During the
> 2.6.38 development cycle, it suffered several revisions, based on our input
> at the media and lkml mailing lists, where Igor fixed all CodingStyle issues.
> 
> In the last minute, during 2.6.38 merge window, two developers (Laurent and Ben) 
> [1] complained against adding a driver for loading FPGA firmware as-is. So, I
> decided to add it, for now, at staging, to avoid needing to postpone a long series 
> of patches again just because of that, especially since a series of DVB-C devices
> are without support on Linux without this patch series, and there are very few
> DVB-C devices currently supported.
> 
> The Altera driver is compliant with CodingStyle, and, from my side, it is ok
> to move it to drivers/others, but it doesn't hurt to give some time for Ben and 
> Laurent to propose alternative way of implementing the firmware request logic.
> 
> If nothing happens until 2.6.40 merge window, I think we should go forward and
> move it to the proper place.

Ok, thanks, I'll defer any patches for this code to you.

greg k-h

Re: linux-next: manual merge of the staging tree with the v4l-dvb tree

[Mauro Carvalho Chehab]

Em 04-03-2011 18:23, Greg KH escreveu:
> On Fri, Mar 04, 2011 at 02:54:24PM -0300, Mauro Carvalho Chehab wrote:
>> Hi Greg,
>>
>> Em 04-03-2011 14:13, Greg KH escreveu:
>>> On Fri, Mar 04, 2011 at 04:39:05PM +1100, Stephen Rothwell wrote:
>>>> Hi Greg,
>>>>
>>>> Today's linux-next merge of the staging tree got a conflict in
>>>> drivers/staging/Kconfig between commit
>>>> a1256092a1e87511c977a3d0ef96151cda77e5c9 ("[media] Altera FPGA firmware
>>>> download module") from the v4l-dvb tree and commit
>>>> 0867b42113ec4eb8646eb361b15cbcfb741ddf5b ("staging: gma500: Intel GMA500
>>>> staging driver") from the staging tree.
>>>>
>>>> I fixed it up (see below) and can carry the fix as necessary.
>>>
>>> That looks correct.
>>>
>>> Mauro, what is this driver and why is it added to the staging tree?
>>
>> This driver implements the FPGA programming logic for a firmware required
>> by a DVB driver, and was proposed initially for 2.6.37 inclusion. During the
>> 2.6.38 development cycle, it suffered several revisions, based on our input
>> at the media and lkml mailing lists, where Igor fixed all CodingStyle issues.
>>
>> In the last minute, during 2.6.38 merge window, two developers (Laurent and Ben) 
>> [1] complained against adding a driver for loading FPGA firmware as-is. So, I
>> decided to add it, for now, at staging, to avoid needing to postpone a long series 
>> of patches again just because of that, especially since a series of DVB-C devices
>> are without support on Linux without this patch series, and there are very few
>> DVB-C devices currently supported.
>>
>> The Altera driver is compliant with CodingStyle, and, from my side, it is ok
>> to move it to drivers/others, but it doesn't hurt to give some time for Ben and 
>> Laurent to propose alternative way of implementing the firmware request logic.
>>
>> If nothing happens until 2.6.40 merge window, I think we should go forward and
>> move it to the proper place.
> 
> Ok, thanks, I'll defer any patches for this code to you.

Ok, thanks!
Mauro.

Kernelspace firmware loaders (was: linux-next: manual merge of the staging tree with the v4l-dvb tree)

[Laurent Pinchart]

On Friday 04 March 2011 18:54:24 Mauro Carvalho Chehab wrote:
> Em 04-03-2011 14:13, Greg KH escreveu:
> > On Fri, Mar 04, 2011 at 04:39:05PM +1100, Stephen Rothwell wrote:
> >> Today's linux-next merge of the staging tree got a conflict in
> >> drivers/staging/Kconfig between commit
> >> a1256092a1e87511c977a3d0ef96151cda77e5c9 ("[media] Altera FPGA firmware
> >> download module") from the v4l-dvb tree and commit
> >> 0867b42113ec4eb8646eb361b15cbcfb741ddf5b ("staging: gma500: Intel GMA500
> >> staging driver") from the staging tree.
> >> 
> >> I fixed it up (see below) and can carry the fix as necessary.
> > 
> > That looks correct.
> > 
> > Mauro, what is this driver and why is it added to the staging tree?
> 
> This driver implements the FPGA programming logic for a firmware required
> by a DVB driver, and was proposed initially for 2.6.37 inclusion. During
> the 2.6.38 development cycle, it suffered several revisions, based on our
> input at the media and lkml mailing lists, where Igor fixed all
> CodingStyle issues.
> 
> In the last minute, during 2.6.38 merge window, two developers (Laurent and
> Ben) [1] complained against adding a driver for loading FPGA firmware
> as-is. So, I decided to add it, for now, at staging, to avoid needing to
> postpone a long series of patches again just because of that, especially
> since a series of DVB-C devices are without support on Linux without this
> patch series, and there are very few DVB-C devices currently supported.
> 
> The Altera driver is compliant with CodingStyle, and, from my side, it is
> ok to move it to drivers/others, but it doesn't hurt to give some time for
> Ben and Laurent to propose alternative way of implementing the firmware
> request logic.
> 
> If nothing happens until 2.6.40 merge window, I think we should go forward
> and move it to the proper place.

What's the policy regarding firmware loaders in kernelspace vs. userspace ? 
JTAG is a quite complex protocol, and we already have lots of JTAG libraries 
in userspace (http://urjtag.org/ seems to be the most popular one). We also 
have userspace firmware loaders (such as fxload for the Cypress EZ USB 
microcontrollers). Do we need a kernelspace JTAG implementation ?

> [1] http://www.mail-archive.com/linux-media@vger.kernel.org/msg26422.html

-- 
Regards,

Laurent Pinchart

Re: Kernelspace firmware loaders (was: linux-next: manual merge of the staging tree with the v4l-dvb tree)

[Greg KH]

On Mon, Mar 07, 2011 at 03:07:36PM +0100, Laurent Pinchart wrote:
> On Friday 04 March 2011 18:54:24 Mauro Carvalho Chehab wrote:
> > Em 04-03-2011 14:13, Greg KH escreveu:
> > > On Fri, Mar 04, 2011 at 04:39:05PM +1100, Stephen Rothwell wrote:
> > >> Today's linux-next merge of the staging tree got a conflict in
> > >> drivers/staging/Kconfig between commit
> > >> a1256092a1e87511c977a3d0ef96151cda77e5c9 ("[media] Altera FPGA firmware
> > >> download module") from the v4l-dvb tree and commit
> > >> 0867b42113ec4eb8646eb361b15cbcfb741ddf5b ("staging: gma500: Intel GMA500
> > >> staging driver") from the staging tree.
> > >> 
> > >> I fixed it up (see below) and can carry the fix as necessary.
> > > 
> > > That looks correct.
> > > 
> > > Mauro, what is this driver and why is it added to the staging tree?
> > 
> > This driver implements the FPGA programming logic for a firmware required
> > by a DVB driver, and was proposed initially for 2.6.37 inclusion. During
> > the 2.6.38 development cycle, it suffered several revisions, based on our
> > input at the media and lkml mailing lists, where Igor fixed all
> > CodingStyle issues.
> > 
> > In the last minute, during 2.6.38 merge window, two developers (Laurent and
> > Ben) [1] complained against adding a driver for loading FPGA firmware
> > as-is. So, I decided to add it, for now, at staging, to avoid needing to
> > postpone a long series of patches again just because of that, especially
> > since a series of DVB-C devices are without support on Linux without this
> > patch series, and there are very few DVB-C devices currently supported.
> > 
> > The Altera driver is compliant with CodingStyle, and, from my side, it is
> > ok to move it to drivers/others, but it doesn't hurt to give some time for
> > Ben and Laurent to propose alternative way of implementing the firmware
> > request logic.
> > 
> > If nothing happens until 2.6.40 merge window, I think we should go forward
> > and move it to the proper place.
> 
> What's the policy regarding firmware loaders in kernelspace vs. userspace ? 
> JTAG is a quite complex protocol, and we already have lots of JTAG libraries 
> in userspace (http://urjtag.org/ seems to be the most popular one). We also 
> have userspace firmware loaders (such as fxload for the Cypress EZ USB 
> microcontrollers). Do we need a kernelspace JTAG implementation ?
> 
> > [1] http://www.mail-archive.com/linux-media@vger.kernel.org/msg26422.html

If the code is just a "pass-through" to the hardware, I have no
objection to the driver being in the kernel, if it needs to be in order
to control the hardware properly.

thanks,

greg k-h

Re: Kernelspace firmware loaders (was: linux-next: manual merge of the staging tree with the v4l-dvb tree)

[Linus Torvalds]

On Mon, Mar 7, 2011 at 8:16 AM, Greg KH <greg@kroah.com> wrote:
>
> If the code is just a "pass-through" to the hardware, I have no
> objection to the driver being in the kernel, if it needs to be in order
> to control the hardware properly.

.. or even if it doesn't "need to be", and you _could_ do it in user space.

We've had tons of problems with user space breakage and version skew
etc. It's often been a total pain to have user space-vs-kernel
components that support one version but not the other, making it hard
to upgrade the kernel independently of other things. The whole
experience with X-vs-drm has been very painful.

There are two cases where user-space drivers work fine:

 (a) if there is no kernel component to them at all. Think "this
driver would work on not just Linux, but on FreeBSD and UnixWare".
Examples of this would be the original X approach.

 (b) if there's a kernel driver which exports an interface that is
specified by the hardware (NOT specified by some "abstraction" layer),
and where the kernel just exports an interface and doesn't expect
anything back (ie the kernel is _strictly_ the lower-level driver,
there is no two-way "user space helps kernel" crap)

     A reasonable example of this would be the USB user space drivers:
the kernel interface is clearly _below_ (so the kernel does not depend
on user space), and the defined not by some crazy software interface,
but by the USB hardware standard.

But any other kind of mixing is just a big pain. Having a user-space
thing to set things up for a kernel driver is crazy crap. It
inevitably leads to "one or the other is broken, and people working on
one piece aren't the same people working on the other". Just don't do
it. Every time it's done, it leads to problems. You need special
programs to set things up etc. It's just f*cked up.

(An example of why it's crazy crap: it inevitably means that the
kernel can not "resume" a device. Because it now needs user space help
to get the device going again. Crazy. Don't do it. It's shit).

                               Linus

Re: Kernelspace firmware loaders (was: linux-next: manual merge of the staging tree with the v4l-dvb tree)

[Laurent Pinchart]

Hi Greg,

On Monday 07 March 2011 17:16:58 Greg KH wrote:
> On Mon, Mar 07, 2011 at 03:07:36PM +0100, Laurent Pinchart wrote:
> > On Friday 04 March 2011 18:54:24 Mauro Carvalho Chehab wrote:
> > > Em 04-03-2011 14:13, Greg KH escreveu:
> > > > On Fri, Mar 04, 2011 at 04:39:05PM +1100, Stephen Rothwell wrote:
> > > >> Today's linux-next merge of the staging tree got a conflict in
> > > >> drivers/staging/Kconfig between commit
> > > >> a1256092a1e87511c977a3d0ef96151cda77e5c9 ("[media] Altera FPGA
> > > >> firmware download module") from the v4l-dvb tree and commit
> > > >> 0867b42113ec4eb8646eb361b15cbcfb741ddf5b ("staging: gma500: Intel
> > > >> GMA500 staging driver") from the staging tree.
> > > >> 
> > > >> I fixed it up (see below) and can carry the fix as necessary.
> > > > 
> > > > That looks correct.
> > > > 
> > > > Mauro, what is this driver and why is it added to the staging tree?
> > > 
> > > This driver implements the FPGA programming logic for a firmware
> > > required by a DVB driver, and was proposed initially for 2.6.37
> > > inclusion. During the 2.6.38 development cycle, it suffered several
> > > revisions, based on our input at the media and lkml mailing lists,
> > > where Igor fixed all CodingStyle issues.
> > > 
> > > In the last minute, during 2.6.38 merge window, two developers (Laurent
> > > and Ben) [1] complained against adding a driver for loading FPGA
> > > firmware as-is. So, I decided to add it, for now, at staging, to avoid
> > > needing to postpone a long series of patches again just because of
> > > that, especially since a series of DVB-C devices are without support
> > > on Linux without this patch series, and there are very few DVB-C
> > > devices currently supported.
> > > 
> > > The Altera driver is compliant with CodingStyle, and, from my side, it
> > > is ok to move it to drivers/others, but it doesn't hurt to give some
> > > time for Ben and Laurent to propose alternative way of implementing
> > > the firmware request logic.
> > > 
> > > If nothing happens until 2.6.40 merge window, I think we should go
> > > forward and move it to the proper place.
> > 
> > What's the policy regarding firmware loaders in kernelspace vs. userspace
> > ? JTAG is a quite complex protocol, and we already have lots of JTAG
> > libraries in userspace (http://urjtag.org/ seems to be the most popular
> > one). We also have userspace firmware loaders (such as fxload for the
> > Cypress EZ USB microcontrollers). Do we need a kernelspace JTAG
> > implementation ?
> > 
> > > [1]
> > > http://www.mail-archive.com/linux-media@vger.kernel.org/msg26422.html
> 
> If the code is just a "pass-through" to the hardware, I have no
> objection to the driver being in the kernel, if it needs to be in order
> to control the hardware properly.

The code implements a JTAG TAP state machine with a bit-banging algorithm, 
including direct parallel port (LPT) access, and a bitcode interpreter for the 
files generated by the Altera FPGA proprietary development tools.

-- 
Regards,

Laurent Pinchart

Re: Kernelspace firmware loaders (was: linux-next: manual merge of the staging tree with the v4l-dvb tree)

[Igor M. Liplianin]

В сообщении от 7 марта 2011 18:51:27 автор Laurent Pinchart написал:
> Hi Greg,
> 
> On Monday 07 March 2011 17:16:58 Greg KH wrote:
> > On Mon, Mar 07, 2011 at 03:07:36PM +0100, Laurent Pinchart wrote:
> > > On Friday 04 March 2011 18:54:24 Mauro Carvalho Chehab wrote:
> > > > Em 04-03-2011 14:13, Greg KH escreveu:
> > > > > On Fri, Mar 04, 2011 at 04:39:05PM +1100, Stephen Rothwell wrote:
> > > > >> Today's linux-next merge of the staging tree got a conflict in
> > > > >> drivers/staging/Kconfig between commit
> > > > >> a1256092a1e87511c977a3d0ef96151cda77e5c9 ("[media] Altera FPGA
> > > > >> firmware download module") from the v4l-dvb tree and commit
> > > > >> 0867b42113ec4eb8646eb361b15cbcfb741ddf5b ("staging: gma500: Intel
> > > > >> GMA500 staging driver") from the staging tree.
> > > > >> 
> > > > >> I fixed it up (see below) and can carry the fix as necessary.
> > > > > 
> > > > > That looks correct.
> > > > > 
> > > > > Mauro, what is this driver and why is it added to the staging tree?
> > > > 
> > > > This driver implements the FPGA programming logic for a firmware
> > > > required by a DVB driver, and was proposed initially for 2.6.37
> > > > inclusion. During the 2.6.38 development cycle, it suffered several
> > > > revisions, based on our input at the media and lkml mailing lists,
> > > > where Igor fixed all CodingStyle issues.
> > > > 
> > > > In the last minute, during 2.6.38 merge window, two developers
> > > > (Laurent and Ben) [1] complained against adding a driver for loading
> > > > FPGA firmware as-is. So, I decided to add it, for now, at staging,
> > > > to avoid needing to postpone a long series of patches again just
> > > > because of that, especially since a series of DVB-C devices are
> > > > without support on Linux without this patch series, and there are
> > > > very few DVB-C devices currently supported.
> > > > 
> > > > The Altera driver is compliant with CodingStyle, and, from my side,
> > > > it is ok to move it to drivers/others, but it doesn't hurt to give
> > > > some time for Ben and Laurent to propose alternative way of
> > > > implementing the firmware request logic.
> > > > 
> > > > If nothing happens until 2.6.40 merge window, I think we should go
> > > > forward and move it to the proper place.
> > > 
> > > What's the policy regarding firmware loaders in kernelspace vs.
> > > userspace ? JTAG is a quite complex protocol, and we already have lots
> > > of JTAG libraries in userspace (http://urjtag.org/ seems to be the
> > > most popular one). We also have userspace firmware loaders (such as
> > > fxload for the Cypress EZ USB microcontrollers). Do we need a
> > > kernelspace JTAG implementation ?
> > > 
> > > > [1]
> > > > http://www.mail-archive.com/linux-media@vger.kernel.org/msg26422.html
> > 
> > If the code is just a "pass-through" to the hardware, I have no
> > objection to the driver being in the kernel, if it needs to be in order
> > to control the hardware properly.
> 
> The code implements a JTAG TAP state machine with a bit-banging algorithm,
> including direct parallel port (LPT) access, and a bitcode interpreter for
LPT access procedure included for historical reason, on early development stages it was used for 
program FPGA, then we swithed to cx23885 GPIO's. Developer can choose(develop) his own procedure 
for JTAG pins access.

> the files generated by the Altera FPGA proprietary development tools.
So, we used this tools. And the code is from widely opened sources.

-- 
Igor M. Liplianin
Microsoft Windows Free Zone - Linux used for all Computing Tasks

Re: Kernelspace firmware loaders (was: linux-next: manual merge of the staging tree with the v4l-dvb tree)

[Laurent Pinchart]

Hi Igor,

On Monday 07 March 2011 18:40:28 Igor M. Liplianin wrote:
> В сообщении от 7 марта 2011 18:51:27 автор Laurent Pinchart написал:
> > On Monday 07 March 2011 17:16:58 Greg KH wrote:
> > > On Mon, Mar 07, 2011 at 03:07:36PM +0100, Laurent Pinchart wrote:
> > > > On Friday 04 March 2011 18:54:24 Mauro Carvalho Chehab wrote:
> > > > > Em 04-03-2011 14:13, Greg KH escreveu:
> > > > > > On Fri, Mar 04, 2011 at 04:39:05PM +1100, Stephen Rothwell wrote:
> > > > > >> Today's linux-next merge of the staging tree got a conflict in
> > > > > >> drivers/staging/Kconfig between commit
> > > > > >> a1256092a1e87511c977a3d0ef96151cda77e5c9 ("[media] Altera FPGA
> > > > > >> firmware download module") from the v4l-dvb tree and commit
> > > > > >> 0867b42113ec4eb8646eb361b15cbcfb741ddf5b ("staging: gma500:
> > > > > >> Intel GMA500 staging driver") from the staging tree.
> > > > > >> 
> > > > > >> I fixed it up (see below) and can carry the fix as necessary.
> > > > > > 
> > > > > > That looks correct.
> > > > > > 
> > > > > > Mauro, what is this driver and why is it added to the staging
> > > > > > tree?
> > > > > 
> > > > > This driver implements the FPGA programming logic for a firmware
> > > > > required by a DVB driver, and was proposed initially for 2.6.37
> > > > > inclusion. During the 2.6.38 development cycle, it suffered several
> > > > > revisions, based on our input at the media and lkml mailing lists,
> > > > > where Igor fixed all CodingStyle issues.
> > > > > 
> > > > > In the last minute, during 2.6.38 merge window, two developers
> > > > > (Laurent and Ben) [1] complained against adding a driver for
> > > > > loading FPGA firmware as-is. So, I decided to add it, for now, at
> > > > > staging, to avoid needing to postpone a long series of patches
> > > > > again just because of that, especially since a series of DVB-C
> > > > > devices are without support on Linux without this patch series,
> > > > > and there are very few DVB-C devices currently supported.
> > > > > 
> > > > > The Altera driver is compliant with CodingStyle, and, from my side,
> > > > > it is ok to move it to drivers/others, but it doesn't hurt to give
> > > > > some time for Ben and Laurent to propose alternative way of
> > > > > implementing the firmware request logic.
> > > > > 
> > > > > If nothing happens until 2.6.40 merge window, I think we should go
> > > > > forward and move it to the proper place.
> > > > 
> > > > What's the policy regarding firmware loaders in kernelspace vs.
> > > > userspace ? JTAG is a quite complex protocol, and we already have
> > > > lots of JTAG libraries in userspace (http://urjtag.org/ seems to be
> > > > the most popular one). We also have userspace firmware loaders (such
> > > > as fxload for the Cypress EZ USB microcontrollers). Do we need a
> > > > kernelspace JTAG implementation ?
> > > > 
> > > > > [1]
> > > > > http://www.mail-archive.com/linux-media@vger.kernel.org/msg26422.ht
> > > > > ml
> > > 
> > > If the code is just a "pass-through" to the hardware, I have no
> > > objection to the driver being in the kernel, if it needs to be in order
> > > to control the hardware properly.
> > 
> > The code implements a JTAG TAP state machine with a bit-banging
> > algorithm, including direct parallel port (LPT) access, and a bitcode
> > interpreter for
> 
> LPT access procedure included for historical reason, on early development
> stages it was used for program FPGA, then we swithed to cx23885 GPIO's.
> Developer can choose(develop) his own procedure for JTAG pins access.

Shouldn't LPT support be removed then ?

> > the files generated by the Altera FPGA proprietary development tools.
> 
> So, we used this tools. And the code is from widely opened sources.

Are we going to add support for all proprietary (and standard ?) FPGA file 
formats, with FPGA programming algorithms from multiple vendors, and TAP 
access support at various levels (not all JTAG interfaces can be controlled at 
the bit-banging level, some use higher level commands) to the kernel ? That 
would be a big amount of complex code, for very little benefit.

You could simplify this by going for a single file format across multiple 
devices from multiple vendors, such as XSVF, but I'm not sure it's a good 
solution either.

-- 
Regards,

Laurent Pinchart

Re: Kernelspace firmware loaders (was: linux-next: manual merge of the staging tree with the v4l-dvb tree)

[Laurent Pinchart]

Hi Linus,

On Monday 07 March 2011 17:39:43 Linus Torvalds wrote:
> On Mon, Mar 7, 2011 at 8:16 AM, Greg KH <greg@kroah.com> wrote:
> > If the code is just a "pass-through" to the hardware, I have no
> > objection to the driver being in the kernel, if it needs to be in order
> > to control the hardware properly.
> 
> .. or even if it doesn't "need to be", and you _could_ do it in user space.
> 
> We've had tons of problems with user space breakage and version skew
> etc. It's often been a total pain to have user space-vs-kernel
> components that support one version but not the other, making it hard
> to upgrade the kernel independently of other things. The whole
> experience with X-vs-drm has been very painful.
> 
> There are two cases where user-space drivers work fine:
> 
>  (a) if there is no kernel component to them at all. Think "this
> driver would work on not just Linux, but on FreeBSD and UnixWare".
> Examples of this would be the original X approach.
> 
>  (b) if there's a kernel driver which exports an interface that is
> specified by the hardware (NOT specified by some "abstraction" layer),
> and where the kernel just exports an interface and doesn't expect
> anything back (ie the kernel is _strictly_ the lower-level driver,
> there is no two-way "user space helps kernel" crap)
> 
>      A reasonable example of this would be the USB user space drivers:
> the kernel interface is clearly _below_ (so the kernel does not depend
> on user space), and the defined not by some crazy software interface,
> but by the USB hardware standard.
> 
> But any other kind of mixing is just a big pain. Having a user-space
> thing to set things up for a kernel driver is crazy crap. It
> inevitably leads to "one or the other is broken, and people working on
> one piece aren't the same people working on the other". Just don't do
> it. Every time it's done, it leads to problems. You need special
> programs to set things up etc. It's just f*cked up.
> 
> (An example of why it's crazy crap: it inevitably means that the
> kernel can not "resume" a device. Because it now needs user space help
> to get the device going again. Crazy. Don't do it. It's shit).

I agree with you on the pain introduced by mixing drivers with userspace 
helpers. However, I'm still concerned about having a full JTAG stack in the 
kernel.

The Altera JTAG driver is basically a firmware loader. There's nothing wrong 
with firmare loaders in the kernel per-se, we have plenty of them and they 
usually request firmware data from userspace (hopefully specially crafted for 
the Linux driver, or pre-processed when the firmware is extracted from a 
Windows driver) and more of less dump it to the device.

Now, if a vendor provided a firmware in the form of a Java bytecode file, 
requiring the kernel driver to implement a JVM to load the firmware into the 
device, would you accept it ? JTAG is not Java, but it still requires several 
non-trivial layers, from controller drivers (we need to support multiple APIs 
there, as controllers can range from simple bit-banging adapters to more 
complex and faster devices with a higher level interface) to binary firmware 
interpreters (and I'm really talking about intepreters here, not just parsers 
- the Altera firmware file requires a VM) with of course incompatible vendor-
specific formats.

-- 
Regards,

Laurent Pinchart

Re: Kernelspace firmware loaders (was: linux-next: manual merge of the staging tree with the v4l-dvb tree)

[Olivier Galibert]

On Wed, Mar 09, 2011 at 11:30:59PM +0100, Laurent Pinchart wrote:
> Now, if a vendor provided a firmware in the form of a Java bytecode file, 
> requiring the kernel driver to implement a JVM to load the firmware into the 
> device, would you accept it ?

You extract the data in userspace, turn it into something passive in a
format you define, and implement the actual loader in C in the kernel.
It would not be the first or last time the actual data is extracted
from a vendor-provided package.

  OG.

Re: linux-next: manual merge of the staging tree with the v4l-dvb tree

[Greg KH]

On Mon, Feb 13, 2023 at 01:13:18PM +1100, Stephen Rothwell wrote:
> Hi all,
> 
> Today's linux-next merge of the staging tree got a conflict in:
> 
>   MAINTAINERS
> 
> between commit:
> 
>   ba47652ba655 ("media: meye: remove this deprecated driver")
> 
> from the v4l-dvb tree and commit:
> 
>   eec8ccab1b57 ("most: add maintainer entry")
> 
> from the staging tree.
> 
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging.  You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.

Fix up looks good, thanks!

greg k-h

linux-next: manual merge of the staging tree with the v4l-dvb tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 1612 bytes --]

Hi all,

Today's linux-next merge of the staging tree got a conflict in:

  MAINTAINERS

between commit:

  ba47652ba655 ("media: meye: remove this deprecated driver")

from the v4l-dvb tree and commit:

  eec8ccab1b57 ("most: add maintainer entry")

from the staging tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc MAINTAINERS
index ccbc53c08734,12a35773db78..000000000000
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@@ -14090,6 -14149,23 +14090,16 @@@ F:	drivers/regulator/mpq7920.
  F:	drivers/regulator/mpq7920.h
  F:	include/linux/mfd/mp2629.h
  
+ MOST(R) TECHNOLOGY DRIVER
+ M:	Parthiban Veerasooran <parthiban.veerasooran@microchip.com>
+ M:	Christian Gromm <christian.gromm@microchip.com>
+ S:	Maintained
+ F:	Documentation/ABI/testing/configfs-most
+ F:	Documentation/ABI/testing/sysfs-bus-most
+ F:	drivers/most/
+ F:	drivers/staging/most/
+ F:	include/linux/most.h
+ 
 -MOTION EYE VAIO PICTUREBOOK CAMERA DRIVER
 -S:	Orphan
 -W:	http://popies.net/meye/
 -F:	Documentation/userspace-api/media/drivers/meye*
 -F:	drivers/staging/media/deprecated/meye/
 -F:	include/uapi/linux/meye.h
 -
  MOTORCOMM PHY DRIVER
  M:	Peter Geis <pgwipeout@gmail.com>
  M:	Frank <Frank.Sae@motor-comm.com>

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: linux-next: manual merge of the staging tree with the v4l-dvb tree

[Greg KH]

On Mon, Mar 23, 2020 at 03:18:05PM +1100, Stephen Rothwell wrote:
> Hi all,
> 
> Today's linux-next merge of the staging tree got a conflict in:
> 
>   drivers/staging/media/allegro-dvt/allegro-core.c
> 
> between several commits from the v4l-dvb tree and commits:
> 
>   5979afa2c4d1 ("staging: Replace zero-length array with flexible-array member")
>   e3d21cbfa978 ("staging: media: allegro: align with parenthesis")
> 
> from the staging tree.
> 
> I fixed it up (see bottom and below merge fix patch) and can carry the
> fix as necessary. This is now fixed as far as linux-next is concerned,
> but any non trivial conflicts should be mentioned to your upstream
> maintainer when your tree is submitted for merging.  You may also want
> to consider cooperating with the maintainer of the conflicting tree to
> minimise any particularly complex conflicts.
> 
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Mon, 23 Mar 2020 15:12:50 +1100
> Subject: [PATCH] fix up for "staging: Replace zero-length array with flexible-array member"
> 
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> ---
>  drivers/staging/media/allegro-dvt/allegro-mail.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/staging/media/allegro-dvt/allegro-mail.h b/drivers/staging/media/allegro-dvt/allegro-mail.h
> index 1fd36f65be78..17db665f8e1e 100644
> --- a/drivers/staging/media/allegro-dvt/allegro-mail.h
> +++ b/drivers/staging/media/allegro-dvt/allegro-mail.h
> @@ -169,7 +169,7 @@ struct mcu_msg_push_buffers_internal_buffer {
>  struct mcu_msg_push_buffers_internal {
>  	struct mcu_msg_header header;
>  	u32 channel_id;
> -	struct mcu_msg_push_buffers_internal_buffer buffer[0];
> +	struct mcu_msg_push_buffers_internal_buffer buffer[];
>  } __attribute__ ((__packed__));
>  
>  struct mcu_msg_put_stream_buffer {
> -- 
> 2.25.0
> 
> -- 
> Cheers,
> Stephen Rothwell
> 
> diff --cc drivers/staging/media/allegro-dvt/allegro-core.c
> index 34c3e55be902,1162cc38f3fc..000000000000
> --- a/drivers/staging/media/allegro-dvt/allegro-core.c
> +++ b/drivers/staging/media/allegro-dvt/allegro-core.c
> @@@ -2403,19 -2324,12 +2403,19 @@@ static int allegro_open(struct file *fi
>   			0, ALLEGRO_GOP_SIZE_MAX,
>   			1, channel->gop_size);
>   	v4l2_ctrl_new_std(handler,
> - 			&allegro_ctrl_ops,
> - 			V4L2_CID_MIN_BUFFERS_FOR_OUTPUT,
> - 			1, 32,
> - 			1, 1);
> + 			  &allegro_ctrl_ops,
> + 			  V4L2_CID_MIN_BUFFERS_FOR_OUTPUT,
> + 			  1, 32,
> + 			  1, 1);
>  +	if (handler->error != 0) {
>  +		ret = handler->error;
>  +		goto error;
>  +	}
>  +
>   	channel->fh.ctrl_handler = handler;
>   
>  +	v4l2_ctrl_cluster(3, &channel->mpeg_video_bitrate_mode);
>  +
>   	channel->mcu_channel_id = -1;
>   	channel->user_id = -1;
>   



Looks good, thanks!

greg k-h

linux-next: manual merge of the staging tree with the v4l-dvb tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 2624 bytes --]

Hi all,

Today's linux-next merge of the staging tree got a conflict in:

  drivers/staging/media/allegro-dvt/allegro-core.c

between several commits from the v4l-dvb tree and commits:

  5979afa2c4d1 ("staging: Replace zero-length array with flexible-array member")
  e3d21cbfa978 ("staging: media: allegro: align with parenthesis")

from the staging tree.

I fixed it up (see bottom and below merge fix patch) and can carry the
fix as necessary. This is now fixed as far as linux-next is concerned,
but any non trivial conflicts should be mentioned to your upstream
maintainer when your tree is submitted for merging.  You may also want
to consider cooperating with the maintainer of the conflicting tree to
minimise any particularly complex conflicts.

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Mon, 23 Mar 2020 15:12:50 +1100
Subject: [PATCH] fix up for "staging: Replace zero-length array with flexible-array member"

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 drivers/staging/media/allegro-dvt/allegro-mail.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/media/allegro-dvt/allegro-mail.h b/drivers/staging/media/allegro-dvt/allegro-mail.h
index 1fd36f65be78..17db665f8e1e 100644
--- a/drivers/staging/media/allegro-dvt/allegro-mail.h
+++ b/drivers/staging/media/allegro-dvt/allegro-mail.h
@@ -169,7 +169,7 @@ struct mcu_msg_push_buffers_internal_buffer {
 struct mcu_msg_push_buffers_internal {
 	struct mcu_msg_header header;
 	u32 channel_id;
-	struct mcu_msg_push_buffers_internal_buffer buffer[0];
+	struct mcu_msg_push_buffers_internal_buffer buffer[];
 } __attribute__ ((__packed__));
 
 struct mcu_msg_put_stream_buffer {
-- 
2.25.0

-- 
Cheers,
Stephen Rothwell

diff --cc drivers/staging/media/allegro-dvt/allegro-core.c
index 34c3e55be902,1162cc38f3fc..000000000000
--- a/drivers/staging/media/allegro-dvt/allegro-core.c
+++ b/drivers/staging/media/allegro-dvt/allegro-core.c
@@@ -2403,19 -2324,12 +2403,19 @@@ static int allegro_open(struct file *fi
  			0, ALLEGRO_GOP_SIZE_MAX,
  			1, channel->gop_size);
  	v4l2_ctrl_new_std(handler,
- 			&allegro_ctrl_ops,
- 			V4L2_CID_MIN_BUFFERS_FOR_OUTPUT,
- 			1, 32,
- 			1, 1);
+ 			  &allegro_ctrl_ops,
+ 			  V4L2_CID_MIN_BUFFERS_FOR_OUTPUT,
+ 			  1, 32,
+ 			  1, 1);
 +	if (handler->error != 0) {
 +		ret = handler->error;
 +		goto error;
 +	}
 +
  	channel->fh.ctrl_handler = handler;
  
 +	v4l2_ctrl_cluster(3, &channel->mpeg_video_bitrate_mode);
 +
  	channel->mcu_channel_id = -1;
  	channel->user_id = -1;
  

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: linux-next: manual merge of the staging tree with the v4l-dvb tree

[Greg KH]

On Thu, Mar 19, 2020 at 02:44:11PM +1100, Stephen Rothwell wrote:
> Hi all,
> 
> Today's linux-next merge of the staging tree got a conflict in:
> 
>   drivers/staging/media/allegro-dvt/allegro-core.c
> 
> between commit:
> 
>   cc62c74749a3 ("media: allegro: add missed checks in allegro_open()")
> 
> from the v4l-dvb tree and commit:
> 
>   e3d21cbfa978 ("staging: media: allegro: align with parenthesis")
> 
> from the staging tree.
> 
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging.  You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.

Fix looks good, thanks!

greg k-h

linux-next: manual merge of the staging tree with the v4l-dvb tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 1506 bytes --]

Hi all,

Today's linux-next merge of the staging tree got a conflict in:

  drivers/staging/media/allegro-dvt/allegro-core.c

between commit:

  cc62c74749a3 ("media: allegro: add missed checks in allegro_open()")

from the v4l-dvb tree and commit:

  e3d21cbfa978 ("staging: media: allegro: align with parenthesis")

from the staging tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc drivers/staging/media/allegro-dvt/allegro-core.c
index 3c949090e8d2,1162cc38f3fc..000000000000
--- a/drivers/staging/media/allegro-dvt/allegro-core.c
+++ b/drivers/staging/media/allegro-dvt/allegro-core.c
@@@ -2321,15 -2324,10 +2321,15 @@@ static int allegro_open(struct file *fi
  			0, ALLEGRO_GOP_SIZE_MAX,
  			1, channel->gop_size);
  	v4l2_ctrl_new_std(handler,
- 			&allegro_ctrl_ops,
- 			V4L2_CID_MIN_BUFFERS_FOR_OUTPUT,
- 			1, 32,
- 			1, 1);
+ 			  &allegro_ctrl_ops,
+ 			  V4L2_CID_MIN_BUFFERS_FOR_OUTPUT,
+ 			  1, 32,
+ 			  1, 1);
 +	if (handler->error != 0) {
 +		ret = handler->error;
 +		goto error;
 +	}
 +
  	channel->fh.ctrl_handler = handler;
  
  	channel->mcu_channel_id = -1;

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: linux-next: manual merge of the staging tree with the v4l-dvb tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 1640 bytes --]

Hi all,

On Fri, 26 Apr 2019 16:06:58 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Today's linux-next merge of the staging tree got conflicts in:
> 
>   drivers/staging/media/zoran/Kconfig
>   drivers/staging/media/zoran/videocodec.c
>   drivers/staging/media/zoran/videocodec.h
>   drivers/staging/media/zoran/zoran.h
>   drivers/staging/media/zoran/zoran_card.c
>   drivers/staging/media/zoran/zoran_card.h
>   drivers/staging/media/zoran/zoran_device.c
>   drivers/staging/media/zoran/zoran_device.h
>   drivers/staging/media/zoran/zoran_driver.c
>   drivers/staging/media/zoran/zoran_procfs.c
>   drivers/staging/media/zoran/zoran_procfs.h
>   drivers/staging/media/zoran/zr36016.c
>   drivers/staging/media/zoran/zr36016.h
>   drivers/staging/media/zoran/zr36050.c
>   drivers/staging/media/zoran/zr36050.h
>   drivers/staging/media/zoran/zr36057.h
>   drivers/staging/media/zoran/zr36060.c
>   drivers/staging/media/zoran/zr36060.h
> 
> between commit:
> 
>   8dce4b265a53 ("media: zoran: remove deprecated driver")
> 
> from the v4l-dvb tree and various commits from the staging tree.
> 
> I fixed it up (I just removed the files) and can carry the fix as
> necessary. This is now fixed as far as linux-next is concerned, but any
> non trivial conflicts should be mentioned to your upstream maintainer
> when your tree is submitted for merging.  You may also want to consider
> cooperating with the maintainer of the conflicting tree to minimise any
> particularly complex conflicts.

This is now a conflict between the v4l-dvb tree and Linus' tree.
-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: linux-next: manual merge of the staging tree with the v4l-dvb tree

[Greg KH]

On Fri, Apr 26, 2019 at 04:06:58PM +1000, Stephen Rothwell wrote:
> Hi all,
> 
> Today's linux-next merge of the staging tree got conflicts in:
> 
>   drivers/staging/media/zoran/Kconfig
>   drivers/staging/media/zoran/videocodec.c
>   drivers/staging/media/zoran/videocodec.h
>   drivers/staging/media/zoran/zoran.h
>   drivers/staging/media/zoran/zoran_card.c
>   drivers/staging/media/zoran/zoran_card.h
>   drivers/staging/media/zoran/zoran_device.c
>   drivers/staging/media/zoran/zoran_device.h
>   drivers/staging/media/zoran/zoran_driver.c
>   drivers/staging/media/zoran/zoran_procfs.c
>   drivers/staging/media/zoran/zoran_procfs.h
>   drivers/staging/media/zoran/zr36016.c
>   drivers/staging/media/zoran/zr36016.h
>   drivers/staging/media/zoran/zr36050.c
>   drivers/staging/media/zoran/zr36050.h
>   drivers/staging/media/zoran/zr36057.h
>   drivers/staging/media/zoran/zr36060.c
>   drivers/staging/media/zoran/zr36060.h
> 
> between commit:
> 
>   8dce4b265a53 ("media: zoran: remove deprecated driver")
> 
> from the v4l-dvb tree and various commits from the staging tree.

Yeah! glad the driver is now gone, sorry for the merge issues.

greg k-h

linux-next: manual merge of the staging tree with the v4l-dvb tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 1422 bytes --]

Hi all,

Today's linux-next merge of the staging tree got conflicts in:

  drivers/staging/media/zoran/Kconfig
  drivers/staging/media/zoran/videocodec.c
  drivers/staging/media/zoran/videocodec.h
  drivers/staging/media/zoran/zoran.h
  drivers/staging/media/zoran/zoran_card.c
  drivers/staging/media/zoran/zoran_card.h
  drivers/staging/media/zoran/zoran_device.c
  drivers/staging/media/zoran/zoran_device.h
  drivers/staging/media/zoran/zoran_driver.c
  drivers/staging/media/zoran/zoran_procfs.c
  drivers/staging/media/zoran/zoran_procfs.h
  drivers/staging/media/zoran/zr36016.c
  drivers/staging/media/zoran/zr36016.h
  drivers/staging/media/zoran/zr36050.c
  drivers/staging/media/zoran/zr36050.h
  drivers/staging/media/zoran/zr36057.h
  drivers/staging/media/zoran/zr36060.c
  drivers/staging/media/zoran/zr36060.h

between commit:

  8dce4b265a53 ("media: zoran: remove deprecated driver")

from the v4l-dvb tree and various commits from the staging tree.

I fixed it up (I just removed the files) and can carry the fix as
necessary. This is now fixed as far as linux-next is concerned, but any
non trivial conflicts should be mentioned to your upstream maintainer
when your tree is submitted for merging.  You may also want to consider
cooperating with the maintainer of the conflicting tree to minimise any
particularly complex conflicts.

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

linux-next: manual merge of the staging tree with the v4l-dvb tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 883 bytes --]

Hi all,

Today's linux-next merge of the staging tree got conflicts in:

  drivers/staging/media/mt9t031/Kconfig
  drivers/staging/media/mt9t031/Makefile

between commit:

  dfe571ca8daa ("media: soc_camera: Remove leftover files, add TODO")

from the v4l-dvb tree and commits:

  99b75a4e3275 ("staging: add missing SPDX lines to Kconfig files")
  97ed8eab2a00 ("staging: add missing SPDX lines to Makefile files")

from the staging tree.

I fixed it up (I just removed the files) and can carry the fix as
necessary. This is now fixed as far as linux-next is concerned, but any
non trivial conflicts should be mentioned to your upstream maintainer
when your tree is submitted for merging.  You may also want to consider
cooperating with the maintainer of the conflicting tree to minimise any
particularly complex conflicts.

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

linux-next: manual merge of the staging tree with the v4l-dvb tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 859 bytes --]

Hi all,

Today's linux-next merge of the staging tree got a conflict in:

  drivers/staging/media/tegra-vde/tegra-vde.c

between commit:

  91dc5e91edf7 ("media: staging: tegra-vde: Replace debug messages with trace points")

from the v4l-dvb tree and commit:

  9483804a725a ("media: staging: tegra-vde: print long unsigned using %lu format specifier")

from the staging tree.

I fixed it up (the former removed the code updated by the latter, so I
did that) and can carry the fix as necessary. This is now fixed as far
as linux-next is concerned, but any non trivial conflicts should be
mentioned to your upstream maintainer when your tree is submitted for
merging.  You may also want to consider cooperating with the maintainer
of the conflicting tree to minimise any particularly complex conflicts.

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

linux-next: manual merge of the staging tree with the v4l-dvb tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 2843 bytes --]

Hi Greg,

Today's linux-next merge of the staging tree got a conflict in:

  drivers/staging/media/imx/imx-media-of.c

between commit:

  21711787045d ("media: staging/imx: of: Remove recursive graph walk")

from the v4l-dvb tree and commit:

  f93861c2d611 ("staging: Convert to using %pOFn instead of device_node.name")

from the staging tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc drivers/staging/media/imx/imx-media-of.c
index 1c9175433ba6,163437e421c5..000000000000
--- a/drivers/staging/media/imx/imx-media-of.c
+++ b/drivers/staging/media/imx/imx-media-of.c
@@@ -20,13 -20,67 +20,13 @@@
  #include <video/imx-ipu-v3.h>
  #include "imx-media.h"
  
 -static int of_get_port_count(const struct device_node *np)
 +static int of_add_csi(struct imx_media_dev *imxmd, struct device_node *csi_np)
  {
 -	struct device_node *ports, *child;
 -	int num = 0;
 +	int ret;
  
 -	/* check if this node has a ports subnode */
 -	ports = of_get_child_by_name(np, "ports");
 -	if (ports)
 -		np = ports;
 -
 -	for_each_child_of_node(np, child)
 -		if (of_node_cmp(child->name, "port") == 0)
 -			num++;
 -
 -	of_node_put(ports);
 -	return num;
 -}
 -
 -/*
 - * find the remote device node given local endpoint node
 - */
 -static bool of_get_remote(struct device_node *epnode,
 -			  struct device_node **remote_node)
 -{
 -	struct device_node *rp, *rpp;
 -	struct device_node *remote;
 -	bool is_csi_port;
 -
 -	rp = of_graph_get_remote_port(epnode);
 -	rpp = of_graph_get_remote_port_parent(epnode);
 -
 -	if (of_device_is_compatible(rpp, "fsl,imx6q-ipu")) {
 -		/* the remote is one of the CSI ports */
 -		remote = rp;
 -		of_node_put(rpp);
 -		is_csi_port = true;
 -	} else {
 -		remote = rpp;
 -		of_node_put(rp);
 -		is_csi_port = false;
 -	}
 -
 -	if (!of_device_is_available(remote)) {
 -		of_node_put(remote);
 -		*remote_node = NULL;
 -	} else {
 -		*remote_node = remote;
 -	}
 -
 -	return is_csi_port;
 -}
 -
 -static int
 -of_parse_subdev(struct imx_media_dev *imxmd, struct device_node *sd_np,
 -		bool is_csi_port)
 -{
 -	int i, num_ports, ret;
 -
 -	if (!of_device_is_available(sd_np)) {
 +	if (!of_device_is_available(csi_np)) {
- 		dev_dbg(imxmd->md.dev, "%s: %s not enabled\n", __func__,
- 			csi_np->name);
+ 		dev_dbg(imxmd->md.dev, "%s: %pOFn not enabled\n", __func__,
 -			sd_np);
++			csi_np);
  		/* unavailable is not an error */
  		return 0;
  	}

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

linux-next: manual merge of the staging tree with the v4l-dvb tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 3267 bytes --]

Hi all,

Today's linux-next merge of the staging tree got a conflict in:

  drivers/staging/media/imx/imx-media-dev.c

between commit:

  b803cd359833 ("media: staging/imx: Switch to v4l2_async_notifier_add_*_subdev")

from the v4l-dvb tree and commit:

  f93861c2d611 ("staging: Convert to using %pOFn instead of device_node.name")

from the staging tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc drivers/staging/media/imx/imx-media-dev.c
index 481840195071,3f48f5ceb6ea..000000000000
--- a/drivers/staging/media/imx/imx-media-dev.c
+++ b/drivers/staging/media/imx/imx-media-dev.c
@@@ -47,34 -80,52 +47,43 @@@ int imx_media_add_async_subdev(struct i
  	struct imx_media_async_subdev *imxasd;
  	struct v4l2_async_subdev *asd;
  	const char *devname = NULL;
 -	int ret = 0;
 -
 -	mutex_lock(&imxmd->mutex);
 +	int ret;
  
 -	if (pdev)
 +	if (fwnode) {
 +		asd = v4l2_async_notifier_add_fwnode_subdev(
 +			&imxmd->notifier, fwnode, sizeof(*imxasd));
 +	} else {
  		devname = dev_name(&pdev->dev);
 -
 -	/* return -EEXIST if this asd already added */
 -	if (find_async_subdev(imxmd, fwnode, devname)) {
 -		if (np)
 -			dev_dbg(imxmd->md.dev, "%s: already added %pOFn\n",
 -			__func__, np);
 -		else
 -			dev_dbg(imxmd->md.dev, "%s: already added %s\n",
 -			__func__, devname);
 -		ret = -EEXIST;
 -		goto out;
 +		asd = v4l2_async_notifier_add_devname_subdev(
 +			&imxmd->notifier, devname, sizeof(*imxasd));
  	}
  
 -	imxasd = devm_kzalloc(imxmd->md.dev, sizeof(*imxasd), GFP_KERNEL);
 -	if (!imxasd) {
 -		ret = -ENOMEM;
 -		goto out;
 +	if (IS_ERR(asd)) {
 +		ret = PTR_ERR(asd);
- 		if (ret == -EEXIST)
- 			dev_dbg(imxmd->md.dev, "%s: already added %s\n",
- 				__func__, np ? np->name : devname);
++		if (ret == -EEXIST) {
++			if (np)
++				dev_dbg(imxmd->md.dev, "%s: already added %pOFn\n",
++				__func__, np);
++			else
++				dev_dbg(imxmd->md.dev, "%s: already added %s\n",
++				__func__, devname);
++		}
 +		return ret;
  	}
 -	asd = &imxasd->asd;
  
 -	if (fwnode) {
 -		asd->match_type = V4L2_ASYNC_MATCH_FWNODE;
 -		asd->match.fwnode = fwnode;
 +	imxasd = to_imx_media_asd(asd);
 +
 +	if (devname)
 +		imxasd->pdev = pdev;
 +
- 	dev_dbg(imxmd->md.dev, "%s: added %s, match type %s\n",
- 		__func__, np ? np->name : devname, np ? "FWNODE" : "DEVNAME");
++	if (fwnode)
+ 		dev_dbg(imxmd->md.dev, "%s: added %pOFn, match type FWNODE\n",
+ 			__func__, np);
 -	} else {
 -		asd->match_type = V4L2_ASYNC_MATCH_DEVNAME;
 -		asd->match.device_name = devname;
 -		imxasd->pdev = pdev;
++	else
+ 		dev_dbg(imxmd->md.dev, "%s: added %s, match type DEVNAME\n",
+ 			__func__, devname);
 -	}
 -
 -	list_add_tail(&imxasd->list, &imxmd->asd_list);
 -
 -	imxmd->subdev_notifier.num_subdevs++;
  
 -out:
 -	mutex_unlock(&imxmd->mutex);
 -	return ret;
 +	return 0;
  }
  
  /*

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: linux-next: manual merge of the staging tree with the v4l-dvb tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 1806 bytes --]

Hi Mauro,

On Thu, 17 May 2018 07:06:57 -0300 Mauro Carvalho Chehab <mchehab+samsung@kernel.org> wrote:
>
> What do you use in order to check it? Maybe we could have some git
> hook running such check, in order to prevent merging patches without
> the right SOBs.

I run the script below on the range of new commits each time a fetch a
tree ...

-- 
Cheers,
Stephen Rothwell

------------------------------------------------------------------------
#!/bin/bash

if [ "$#" -lt 1 ]; then
	printf "Usage: %s <commit range>\n", "$0" 1>&2
	exit 1
fi

commits=$(git rev-list --no-merges "$@")
if [ -z "$commits" ]; then
	printf "No commits\n"
	exit 0
fi

for c in $commits; do
	ae=$(git log -1 --format='%ae' "$c")
	aE=$(git log -1 --format='%aE' "$c")
	an=$(git log -1 --format='%an' "$c")
	aN=$(git log -1 --format='%aN' "$c")
	ce=$(git log -1 --format='%ce' "$c")
	cE=$(git log -1 --format='%cE' "$c")
	cn=$(git log -1 --format='%cn' "$c")
	cN=$(git log -1 --format='%cN' "$c")
	sob=$(git log -1 --format='%b' "$c" | grep -i '^[[:space:]]*Signed-off-by:')

	am=false
	cm=false
	grep -i -q "<$ae>" <<<"$sob" ||
		grep -i -q "<$aE>" <<<"$sob" ||
		grep -i -q ":[[:space:]]*$an[[:space:]]*<" <<<"$sob" ||
		grep -i -q ":[[:space:]]*$aN[[:space:]]*<" <<<"$sob" ||
		am=true
	grep -i -q "<$ce>" <<<"$sob" ||
		grep -i -q "<$cE>" <<<"$sob" ||
		grep -i -q ":[[:space:]]*$cn[[:space:]]*<" <<<"$sob" ||
		grep -i -q ":[[:space:]]*$cN[[:space:]]*<" <<<"$sob" ||
		cm=true

	if "$am" || "$cm"; then
		printf "Commit %s\n" "$c"
		"$am" && printf "\tauthor SOB missing\n"
		"$cm" && printf "\tcommitter SOB missing\n"
		printf "%s %s\n%s\n" "$ae" "$ce" "$sob"
	fi
done

exec gitk "$@"
------------------------------------------------------------------------

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: linux-next: manual merge of the staging tree with the v4l-dvb tree

[Mauro Carvalho Chehab]

Em Thu, 17 May 2018 14:17:27 +1000
Stephen Rothwell <sfr@canb.auug.org.au> escreveu:

> Hi all,
> 
> Today's linux-next merge of the staging tree got a conflict in:
> 
>   drivers/staging/media/atomisp/TODO
> 
> between commit:
> 
>   51b8dc5163d2 ("media: staging: atomisp: Remove driver")
> 
> from the v4l-dvb tree and commit:
> 
>   1bd421154821 ("staging: atomisp: Augment TODO file with GPIO work item")
> 
> from the staging tree.
> 
> I fixed it up (I just removed the file) and can carry the fix as
> necessary. This is now fixed as far as linux-next is concerned, but any
> non trivial conflicts should be mentioned to your upstream maintainer
> when your tree is submitted for merging.  You may also want to consider
> cooperating with the maintainer of the conflicting tree to minimise any
> particularly complex conflicts.
> 

Hi Stephen,

What do you use in order to check it? Maybe we could have some git
hook running such check, in order to prevent merging patches without
the right SOBs.

Thanks,
Mauro

Re: linux-next: manual merge of the staging tree with the v4l-dvb tree

[Greg KH]

On Thu, May 17, 2018 at 02:17:27PM +1000, Stephen Rothwell wrote:
> Hi all,
> 
> Today's linux-next merge of the staging tree got a conflict in:
> 
>   drivers/staging/media/atomisp/TODO
> 
> between commit:
> 
>   51b8dc5163d2 ("media: staging: atomisp: Remove driver")
> 
> from the v4l-dvb tree and commit:
> 
>   1bd421154821 ("staging: atomisp: Augment TODO file with GPIO work item")
> 
> from the staging tree.
> 
> I fixed it up (I just removed the file) and can carry the fix as
> necessary. This is now fixed as far as linux-next is concerned, but any
> non trivial conflicts should be mentioned to your upstream maintainer
> when your tree is submitted for merging.  You may also want to consider
> cooperating with the maintainer of the conflicting tree to minimise any
> particularly complex conflicts.

Looks correct, glad to see this code be removed :)

thanks,

greg k-h

linux-next: manual merge of the staging tree with the v4l-dvb tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 762 bytes --]

Hi all,

Today's linux-next merge of the staging tree got a conflict in:

  drivers/staging/media/atomisp/TODO

between commit:

  51b8dc5163d2 ("media: staging: atomisp: Remove driver")

from the v4l-dvb tree and commit:

  1bd421154821 ("staging: atomisp: Augment TODO file with GPIO work item")

from the staging tree.

I fixed it up (I just removed the file) and can carry the fix as
necessary. This is now fixed as far as linux-next is concerned, but any
non trivial conflicts should be mentioned to your upstream maintainer
when your tree is submitted for merging.  You may also want to consider
cooperating with the maintainer of the conflicting tree to minimise any
particularly complex conflicts.

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

linux-next: manual merge of the staging tree with the v4l-dvb tree

[Stephen Rothwell]

Hi Greg,

Today's linux-next merge of the staging tree got a conflict in:

  drivers/staging/media/atomisp/pci/atomisp2/hmm/hmm_bo.c

between commit:

  309167b966b6 ("media: staging: atomisp: cleanup out of memory messages")

from the v4l-dvb tree and commit:

  63342e75e661 ("Staging: media: atomisp: Use kmalloc_array instead of kmalloc")

from the staging tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc drivers/staging/media/atomisp/pci/atomisp2/hmm/hmm_bo.c
index 9e957514108e,5232327f5d9c..000000000000
--- a/drivers/staging/media/atomisp/pci/atomisp2/hmm/hmm_bo.c
+++ b/drivers/staging/media/atomisp/pci/atomisp2/hmm/hmm_bo.c
@@@ -721,10 -725,12 +721,10 @@@ static int alloc_private_pages(struct h
  
  	pgnr = bo->pgnr;
  
- 	bo->page_obj = kmalloc(sizeof(struct hmm_page_object) * pgnr,
+ 	bo->page_obj = kmalloc_array(pgnr, sizeof(struct hmm_page_object),
  				GFP_KERNEL);
 -	if (unlikely(!bo->page_obj)) {
 -		dev_err(atomisp_dev, "out of memory for bo->page_obj\n");
 +	if (unlikely(!bo->page_obj))
  		return -ENOMEM;
 -	}
  
  	i = 0;
  	alloc_pgnr = 0;
@@@ -984,13 -990,16 +984,13 @@@ static int alloc_user_pages(struct hmm_
  	struct vm_area_struct *vma;
  	struct page **pages;
  
- 	pages = kmalloc(sizeof(struct page *) * bo->pgnr, GFP_KERNEL);
+ 	pages = kmalloc_array(bo->pgnr, sizeof(struct page *), GFP_KERNEL);
 -	if (unlikely(!pages)) {
 -		dev_err(atomisp_dev, "out of memory for pages...\n");
 +	if (unlikely(!pages))
  		return -ENOMEM;
 -	}
  
- 	bo->page_obj = kmalloc(sizeof(struct hmm_page_object) * bo->pgnr,
+ 	bo->page_obj = kmalloc_array(bo->pgnr, sizeof(struct hmm_page_object),
  		GFP_KERNEL);
  	if (unlikely(!bo->page_obj)) {
 -		dev_err(atomisp_dev, "out of memory for bo->page_obj...\n");
  		kfree(pages);
  		return -ENOMEM;
  	}
@@@ -1350,9 -1363,10 +1350,9 @@@ void *hmm_bo_vmap(struct hmm_buffer_obj
  		bo->status &= ~(HMM_BO_VMAPED | HMM_BO_VMAPED_CACHED);
  	}
  
- 	pages = kmalloc(sizeof(*pages) * bo->pgnr, GFP_KERNEL);
+ 	pages = kmalloc_array(bo->pgnr, sizeof(*pages), GFP_KERNEL);
  	if (unlikely(!pages)) {
  		mutex_unlock(&bo->mutex);
 -		dev_err(atomisp_dev, "out of memory for pages...\n");
  		return NULL;
  	}
  

linux-next: manual merge of the staging tree with the v4l-dvb tree

[Stephen Rothwell]

Hi Greg,

Today's linux-next merge of the staging tree got conflicts in:

  drivers/staging/media/Kconfig
  drivers/staging/media/Makefile

between commits:

  fc4e009c6c98 ("[media] stih-cec: add CEC notifier support")
  a93d429b51fb ("[media] s5p-cec: add cec-notifier support, move out of staging")

from the v4l-dvb tree and commits:

  212afb97efe1 ("staging: bcm2835-camera: Move driver under vc04_services")
  a49d25364dfb ("staging/atomisp: Add support for the Intel IPU v2")

from the staging tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc drivers/staging/media/Kconfig
index 8ed8202da57a,5a26eb211c7a..000000000000
--- a/drivers/staging/media/Kconfig
+++ b/drivers/staging/media/Kconfig
@@@ -27,9 -27,12 +27,9 @@@ source "drivers/staging/media/davinci_v
  
  source "drivers/staging/media/omap4iss/Kconfig"
  
- source "drivers/staging/media/platform/bcm2835/Kconfig"
 -source "drivers/staging/media/s5p-cec/Kconfig"
--
  # Keep LIRC at the end, as it has sub-menus
  source "drivers/staging/media/lirc/Kconfig"
  
 -source "drivers/staging/media/st-cec/Kconfig"
 -
+ source "drivers/staging/media/atomisp/Kconfig"
++
  endif
diff --cc drivers/staging/media/Makefile
index 3a6adeabede1,ab60a89c6593..000000000000
--- a/drivers/staging/media/Makefile
+++ b/drivers/staging/media/Makefile
@@@ -1,6 -1,8 +1,6 @@@
  obj-$(CONFIG_I2C_BCM2048)	+= bcm2048/
 -obj-$(CONFIG_VIDEO_SAMSUNG_S5P_CEC) += s5p-cec/
  obj-$(CONFIG_DVB_CXD2099)	+= cxd2099/
  obj-$(CONFIG_LIRC_STAGING)	+= lirc/
- obj-$(CONFIG_VIDEO_BCM2835)	+= platform/bcm2835/
  obj-$(CONFIG_VIDEO_DM365_VPFE)	+= davinci_vpfe/
  obj-$(CONFIG_VIDEO_OMAP4)	+= omap4iss/
 -obj-$(CONFIG_VIDEO_STI_HDMI_CEC) += st-cec/
+ obj-$(CONFIG_INTEL_ATOMISP)     += atomisp/

Re: linux-next: manual merge of the staging tree with the v4l-dvb tree

[Stephen Rothwell]

Hi Sean,

On Thu, 6 Apr 2017 21:39:05 +0100 Sean Young <sean@mess.org> wrote:
>
> I think this is happening:
> 
> On the v4l-dvb tree, 5cd6522 modifies both lirc_sasem.c and lirc_sir.c;
> then both files are removed. Now 87ddb91067b9 is merged from the staging
> tree and both files don't exist any more, so it no longer applies even
> though the patch is the same.

That is exactly right, but ...

> If I drop 87ddb91067b9 from staging-next, I can merge it to v4l-dvb, 
> otherwise I get merge conflicts.

The resolution is trivial, so don't worry about it.

-- 
Cheers,
Stephen Rothwell

Re: linux-next: manual merge of the staging tree with the v4l-dvb tree

[Sean Young]

On Thu, Apr 06, 2017 at 09:19:22PM +0200, Greg KH wrote:
> On Thu, Apr 06, 2017 at 07:58:57PM +0100, Sean Young wrote:
> > On Thu, Apr 06, 2017 at 01:34:20PM +1000, Stephen Rothwell wrote:
> > > Hi all,
> > > 
> > > Today's linux-next merge of the staging tree got conflicts in:
> > > 
> > >   drivers/staging/media/lirc/lirc_sasem.c
> > >   drivers/staging/media/lirc/lirc_sir.c
> > > 
> > > between commits:
> > > 
> > >   e66267161971 ("[media] rc: promote lirc_sir out of staging")
> > >   51bb3fd788cb ("[media] staging: lirc_sasem: remove")
> > > 
> > > from the v4l-dvb tree and commit:
> > > 
> > >   87ddb91067b9 ("Staging: media: lirc - style fix")
> > 
> > There are two commits which do similar things. In the v4l-dvb tree we have
> > 5cd6522 ("[media] staging: lirc: use octal instead of symbolic permission"
> > and in the staging tree there is 
> > 87ddb91067b9 ("Staging: media: lirc - style fix")
> > 
> > Is it possible to drop the latter from the staging tree? That would resolve
> > the issue.
> 
> I can revert the staging patch, if that really helps anything.  Is is
> really an issue as both patches do the same thing?

I think this is happening:

On the v4l-dvb tree, 5cd6522 modifies both lirc_sasem.c and lirc_sir.c;
then both files are removed. Now 87ddb91067b9 is merged from the staging
tree and both files don't exist any more, so it no longer applies even
though the patch is the same.

If I drop 87ddb91067b9 from staging-next, I can merge it to v4l-dvb, 
otherwise I get merge conflicts.

Thanks
Sean

Re: linux-next: manual merge of the staging tree with the v4l-dvb tree

[Greg KH]

On Thu, Apr 06, 2017 at 07:58:57PM +0100, Sean Young wrote:
> On Thu, Apr 06, 2017 at 01:34:20PM +1000, Stephen Rothwell wrote:
> > Hi all,
> > 
> > Today's linux-next merge of the staging tree got conflicts in:
> > 
> >   drivers/staging/media/lirc/lirc_sasem.c
> >   drivers/staging/media/lirc/lirc_sir.c
> > 
> > between commits:
> > 
> >   e66267161971 ("[media] rc: promote lirc_sir out of staging")
> >   51bb3fd788cb ("[media] staging: lirc_sasem: remove")
> > 
> > from the v4l-dvb tree and commit:
> > 
> >   87ddb91067b9 ("Staging: media: lirc - style fix")
> 
> There are two commits which do similar things. In the v4l-dvb tree we have
> 5cd6522 ("[media] staging: lirc: use octal instead of symbolic permission"
> and in the staging tree there is 
> 87ddb91067b9 ("Staging: media: lirc - style fix")
> 
> Is it possible to drop the latter from the staging tree? That would resolve
> the issue.

I can revert the staging patch, if that really helps anything.  Is is
really an issue as both patches do the same thing?

thanks,

greg k-h

Re: linux-next: manual merge of the staging tree with the v4l-dvb tree

[Sean Young]

On Thu, Apr 06, 2017 at 01:34:20PM +1000, Stephen Rothwell wrote:
> Hi all,
> 
> Today's linux-next merge of the staging tree got conflicts in:
> 
>   drivers/staging/media/lirc/lirc_sasem.c
>   drivers/staging/media/lirc/lirc_sir.c
> 
> between commits:
> 
>   e66267161971 ("[media] rc: promote lirc_sir out of staging")
>   51bb3fd788cb ("[media] staging: lirc_sasem: remove")
> 
> from the v4l-dvb tree and commit:
> 
>   87ddb91067b9 ("Staging: media: lirc - style fix")

There are two commits which do similar things. In the v4l-dvb tree we have
5cd6522 ("[media] staging: lirc: use octal instead of symbolic permission"
and in the staging tree there is 
87ddb91067b9 ("Staging: media: lirc - style fix")

Is it possible to drop the latter from the staging tree? That would resolve
the issue.

Thanks

Sean

linux-next: manual merge of the staging tree with the v4l-dvb tree

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the staging tree got conflicts in:

  drivers/staging/media/lirc/lirc_sasem.c
  drivers/staging/media/lirc/lirc_sir.c

between commits:

  e66267161971 ("[media] rc: promote lirc_sir out of staging")
  51bb3fd788cb ("[media] staging: lirc_sasem: remove")

from the v4l-dvb tree and commit:

  87ddb91067b9 ("Staging: media: lirc - style fix")

from the staging tree.

I fixed it up (I removed both files - the updates to lirc_sir.c were
also done in the v4l-dvb tree) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

Re: linux-next: manual merge of the staging tree with the v4l-dvb tree

[Greg KH]

On Mon, Feb 06, 2017 at 03:31:51PM +1100, Stephen Rothwell wrote:
> Hi Greg,
> 
> Today's linux-next merge of the staging tree got a conflict in:
> 
>   drivers/staging/media/lirc/lirc_parallel.c
> 
> between commit:
> 
>   2933974cbb03 ("[media] staging: lirc_parallel: remove")
> 
> from the v4l-dvb tree and commit:
> 
>   1c5fa1c7dbff ("staging: media: lirc: use new parport device model")
> 
> from the staging tree.
> 
> Unfortunate ...

That's fine, thanks for letting me know, I didn't realize the file was
removed until after I had applied the patch :(

thanks,

greg k-h

linux-next: manual merge of the staging tree with the v4l-dvb tree

[Stephen Rothwell]

Hi Greg,

Today's linux-next merge of the staging tree got a conflict in:

  drivers/staging/media/lirc/lirc_parallel.c

between commit:

  2933974cbb03 ("[media] staging: lirc_parallel: remove")

from the v4l-dvb tree and commit:

  1c5fa1c7dbff ("staging: media: lirc: use new parport device model")

from the staging tree.

Unfortunate ...

I fixed it up (I removed the file) and can carry the fix as
necessary. This is now fixed as far as linux-next is concerned, but any
non trivial conflicts should be mentioned to your upstream maintainer
when your tree is submitted for merging.  You may also want to consider
cooperating with the maintainer of the conflicting tree to minimise any
particularly complex conflicts.

-- 
Cheers,
Stephen Rothwell

Re: linux-next: manual merge of the staging tree with the v4l-dvb tree

[Greg KH]

On Fri, Mar 04, 2016 at 04:24:44PM +1100, Stephen Rothwell wrote:
> Hi Greg,
> 
> Today's linux-next merge of the staging tree got a conflict in:
> 
>   drivers/media/dvb-frontends/mn88473.c
> 
> between commit:
> 
>   7908fad99a6c ("[media] mn88473: finalize driver")
> 
> from the v4l-dvb tree and commit:
> 
>   3a35be2a1443 ("staging: media: Remove unneeded parentheses")
> 
> from the staging tree.
> 
> I fixed it up (I just used the v4l-dvb tree version) and can carry the
> fix as necessary (no action is required).

Thanks for this, that sounds fine.

greg k-h

linux-next: manual merge of the staging tree with the v4l-dvb tree

[Stephen Rothwell]

Hi Greg,

Today's linux-next merge of the staging tree got a conflict in:

  drivers/media/dvb-frontends/mn88473.c

between commit:

  7908fad99a6c ("[media] mn88473: finalize driver")

from the v4l-dvb tree and commit:

  3a35be2a1443 ("staging: media: Remove unneeded parentheses")

from the staging tree.

I fixed it up (I just used the v4l-dvb tree version) and can carry the
fix as necessary (no action is required).

-- 
Cheers,
Stephen Rothwell

Re: linux-next: manual merge of the staging tree with the v4l-dvb tree

[Greg KH]

On Mon, May 11, 2015 at 03:28:04PM +1000, Stephen Rothwell wrote:
> Hi Greg,
> 
> Today's linux-next merge of the staging tree got a conflict in
> drivers/staging/media/dt3155v4l/dt3155v4l.c between commit cc11b140c3f1
> ("[media] dt3155: move out of staging into drivers/media/pci") from the
> v4l-dvb tree and commit ec80e2428046 ("staging: dt3155v4l: remove
> unused including <linux/version.h>") from the staging tree (which moved
> the file to drivers/media/pci/dt3155/dt3155.c).
> 
> I fixed it up (I just deleted the file from staging - the
> linux/config.h patch needs to be applied to the new file) and can carry
> the fix as necessary (no action is required).

Sounds good, thanks for doing this.

greg k-h

linux-next: manual merge of the staging tree with the v4l-dvb tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 666 bytes --]

Hi Greg,

Today's linux-next merge of the staging tree got a conflict in
drivers/staging/media/dt3155v4l/dt3155v4l.c between commit cc11b140c3f1
("[media] dt3155: move out of staging into drivers/media/pci") from the
v4l-dvb tree and commit ec80e2428046 ("staging: dt3155v4l: remove
unused including <linux/version.h>") from the staging tree (which moved
the file to drivers/media/pci/dt3155/dt3155.c).

I fixed it up (I just deleted the file from staging - the
linux/config.h patch needs to be applied to the new file) and can carry
the fix as necessary (no action is required).

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

linux-next: manual merge of the staging tree with the v4l-dvb tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 550 bytes --]

Hi Greg,

Today's linux-next merge of the staging tree got a conflict in
drivers/staging/media/mn88473/mn88473.c between commit 3b786f131645
("[media] mn88473: calculate the IF register values") from the v4l-dvb
tree and commit b4c2c314c140 ("Staging: media: mn88473: Match alignment
with open parenthesis") from the staging tree.

I fixed it up (the former removed part of the code updated by the
latter) and can carry the fix as necessary (no action is required).

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

linux-next: manual merge of the staging tree with the v4l-dvb tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 539 bytes --]

Hi Greg,

Today's linux-next merge of the staging tree got a conflict in
drivers/staging/media/omap24xx/tcm825x.c between commit db85a0403be4
("[media] omap24xx/tcm825x: remove deprecated omap2 camera drivers")
from the v4l-dvb tree and commit 1002a240ed72 ("staging: media:
omap24xx: Use min_t instead of min") from the staging tree.

I fixed it up (the former removed the file, so I did that) and can
carry the fix as necessary (no action is required).

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

linux-next: manual merge of the staging tree with the v4l-dvb tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 666 bytes --]

Hi Greg,

Today's linux-next merge of the staging tree got a conflict in
drivers/staging/media/omap24xx/omap24xxcam.c between commit
db85a0403be4 ("[media] omap24xx/tcm825x: remove deprecated omap2 camera
drivers") from the v4l-dvb tree and commits cfafe92c1e94 ("staging:
media: omap24xx: Remove unnecessary 'out of memory' message") and
1d06bb4e9df3 ("staging: remove unneeded parentheses around the right
hand side of an assignment") from the staging tree.

I fixed it up (the former removed the file, so I did that) and can
carry the fix as necessary (no action is required).

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: linux-next: manual merge of the staging tree with the v4l-dvb tree

[Greg KH]

On Wed, Nov 05, 2014 at 03:29:11PM +1100, Stephen Rothwell wrote:
> Hi Greg,
> 
> Today's linux-next merge of the staging tree got a conflict in
> drivers/staging/media/lirc/lirc_imon.c between commit f3a75505ab5f
> ("[media] Staging: media: lirc: cleaned up packet dump in 2 files")
> from the v4l-dvb tree and commit 732ba199ab07 ("staging: media: lirc:
> lirc_imon.c: replace printk by dev_dbg") from the staging tree.
> 
> I fixed it up (the staging tree patch was not complete, so I did the
> below) and can carry the fix as necessary (no action is required).

Thanks for all 3 of these, they look fine.

greg k-h

linux-next: manual merge of the staging tree with the v4l-dvb tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 1212 bytes --]

Hi Greg,

Today's linux-next merge of the staging tree got a conflict in
drivers/staging/media/lirc/lirc_sasem.c between commit f3a75505ab5f
("[media] Staging: media: lirc: cleaned up packet dump in 2 files")
from the v4l-dvb tree and commit eca6a8872a04 ("staging: media: lirc:
Use pr_* instead of printk") from the staging tree.

I fixed it up (I just used the v4l-dvb tree version - see below) and
can carry the fix as necessary (no action is required).

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

diff --cc drivers/staging/media/lirc/lirc_sasem.c
index 2f0463eb9887,123ddf68b587..000000000000
--- a/drivers/staging/media/lirc/lirc_sasem.c
+++ b/drivers/staging/media/lirc/lirc_sasem.c
@@@ -581,8 -582,13 +581,9 @@@ static void incoming_packet(struct sase
  		return;
  	}
  
 -	if (debug) {
 -		pr_info("Incoming data: ");
 -		for (i = 0; i < 8; ++i)
 -			pr_cont("%02x ", buf[i]);
 -		pr_cont("\n");
 -	}
 +	if (debug)
 +		dev_info(&context->dev->dev, "Incoming data: %*ph\n", len, buf);
+ 
  	/*
  	 * Lirc could deal with the repeat code, but we really need to block it
  	 * if it arrives too late.  Otherwise we could repeat the wrong code.

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

linux-next: manual merge of the staging tree with the v4l-dvb tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 500 bytes --]

Hi Greg,

Today's linux-next merge of the staging tree got a conflict in
drivers/staging/media/lirc/lirc_igorplugusb.c between commit
3e5907e695f2 ("[media] lirc_igorplugusb: remove") from the v4l-dvb tree
and commit d82e62deb51b ("staging: media: lirc: Remove useless cast on
void pointer") from the staging tree.

I fixed it up (I just removed the file) and can carry the fix as
necessary (no action is required).

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

linux-next: manual merge of the staging tree with the v4l-dvb tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 1245 bytes --]

Hi Greg,

Today's linux-next merge of the staging tree got a conflict in
drivers/staging/media/lirc/lirc_imon.c between commit f3a75505ab5f
("[media] Staging: media: lirc: cleaned up packet dump in 2 files")
from the v4l-dvb tree and commit 732ba199ab07 ("staging: media: lirc:
lirc_imon.c: replace printk by dev_dbg") from the staging tree.

I fixed it up (the staging tree patch was not complete, so I did the
below) and can carry the fix as necessary (no action is required).

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

diff --cc drivers/staging/media/lirc/lirc_imon.c
index 232edd5b1742,f98418cd2305..000000000000
--- a/drivers/staging/media/lirc/lirc_imon.c
+++ b/drivers/staging/media/lirc/lirc_imon.c
@@@ -619,8 -597,13 +596,9 @@@ static void imon_incoming_packet(struc
  		return;
  	}
  
 -	if (debug) {
 -		dev_info(dev, "raw packet: ");
 -		for (i = 0; i < len; ++i)
 -			dev_dbg(dev, "%02x ", buf[i]);
 -		dev_dbg(dev, "\n");
 -	}
 +	if (debug)
- 		dev_info(dev, "raw packet: %*ph\n", len, buf);
++		dev_dbg(dev, "raw packet: %*ph\n", len, buf);
+ 
  	/*
  	 * Translate received data to pulse and space lengths.
  	 * Received data is active low, i.e. pulses are 0 and

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: linux-next: manual merge of the staging tree with the v4l-dvb tree

[Greg KH]

On Wed, Jul 16, 2014 at 04:46:54PM +1000, Stephen Rothwell wrote:
> Hi Greg,
> 
> Today's linux-next merge of the staging tree got a conflict in
> drivers/staging/media/sn9c102/Kconfig between commit c0e11a2a24db
> ("[media] sn9c102: remove deprecated driver") from the v4l-dvb tree and
> commit cfa880069d09 ("staging: sn9c102 depends on USB") from the
> staging tree.
> 
> I fixed it up (I just removed the file) and can carry the fix as
> necessary (no action is required).

Thanks, lots of staging drivers are getting deleted here, which is a
good thing :)

greg k-h

linux-next: manual merge of the staging tree with the v4l-dvb tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 475 bytes --]

Hi Greg,

Today's linux-next merge of the staging tree got a conflict in
drivers/staging/media/sn9c102/Kconfig between commit c0e11a2a24db
("[media] sn9c102: remove deprecated driver") from the v4l-dvb tree and
commit cfa880069d09 ("staging: sn9c102 depends on USB") from the
staging tree.

I fixed it up (I just removed the file) and can carry the fix as
necessary (no action is required).

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: linux-next: manual merge of the staging tree with the v4l-dvb tree

[Grant Likely]

On Fri, Mar 21, 2014 at 12:24 PM, Grant Likely <grant.likely@linaro.org> wrote:
> On Wed, 19 Mar 2014 08:30:08 -0700, Greg KH <greg@kroah.com> wrote:
>> On Mon, Mar 17, 2014 at 10:27:36PM +0000, Russell King wrote:
>> > 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.
>>
>> Thanks for the details, I'll just leave my tree as-is for now, as that
>> seems the simplest thing to do.
>
> Yes, please leave it in your tree. I've caused noise and trouble than I
> should, and could have handled it differently. I apologize.

s/should/should not have/

g.

Re: linux-next: manual merge of the staging tree with the v4l-dvb tree

[Grant Likely]

On Wed, 19 Mar 2014 08:30:08 -0700, Greg KH <greg@kroah.com> wrote:
> On Mon, Mar 17, 2014 at 10:27:36PM +0000, Russell King wrote:
> > 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.
> 
> Thanks for the details, I'll just leave my tree as-is for now, as that
> seems the simplest thing to do.

Yes, please leave it in your tree. I've caused noise and trouble than I
should, and could have handled it differently. I apologize.

g.

Re: linux-next: manual merge of the staging tree with the v4l-dvb tree

[Greg KH]

On Mon, Mar 17, 2014 at 10:27:36PM +0000, Russell King wrote:
> 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.

Thanks for the details, I'll just leave my tree as-is for now, as that
seems the simplest thing to do.

greg k-h

linux-next: manual merge of the staging tree with the v4l-dvb tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 1104 bytes --]

Hi Greg,

Today's linux-next merge of the staging tree got a conflict in
drivers/staging/media/msi3101/sdr-msi3101.c between commit 3d0c8fa3c5a0
("[media] msi3101: convert to SDR API") from the v4l-dvb tree and commit
6e878c0299c1 ("staging: media/msi3101/sdr-msi3101.c removed warning")
from the staging tree.

I fixed it up (see below) and can carry the fix as necessary (no action
is required).

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

diff --cc drivers/staging/media/msi3101/sdr-msi3101.c
index 011db2c08014,5a0400fdb98c..000000000000
--- a/drivers/staging/media/msi3101/sdr-msi3101.c
+++ b/drivers/staging/media/msi3101/sdr-msi3101.c
@@@ -132,7 -411,7 +132,7 @@@ struct msi3101_state 
  	unsigned int vb_full; /* vb is full and packets dropped */
  
  	struct urb *urbs[MAX_ISO_BUFS];
- 	int (*convert_stream) (struct msi3101_state *s, u8 *dst, u8 *src,
 -	int (*convert_stream)(struct msi3101_state *s, u32 *dst, u8 *src,
++	int (*convert_stream)(struct msi3101_state *s, u8 *dst, u8 *src,
  			unsigned int src_len);
  
  	/* Controls */

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

Re: linux-next: manual merge of the staging tree with the v4l-dvb tree

[Russell King]

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@kroah.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@canb.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

Re: linux-next: manual merge of the staging tree with the v4l-dvb tree

[Mauro Carvalho Chehab]

Em Mon, 17 Mar 2014 11:29:53 -0700
Greg KH <greg@kroah.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@canb.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.

At the first series, there's one DT patch in the middle.

Both patch series was being discussed for a while at the
pertinent MLs.

My understanding on March, 7, after an email from Russell,
was that everybody was happy with the first patch series, 
and that I should be applying it on my tree. So, I did it.

However, on the same day, Grant nacked the patch series,
because of some DT bindings, mainly focused on this one:
	"Documentation: of: Document graph bindings"

After lots of discussions and no agreements with regards
to it, Grant asked me to rewind my git tree, in order to
discard the git pull from the first series.

Even hating the idea of doing a git rebase upstream, 
after talking with the media submaintainers on IRC,
I did a git rewind, as I was afraid that just reverting
the 6 individual patches would cause merge conflicts with
other trees that might have merged those patches, or some
newer version of it.

Latter, Laurent also rised some other points about for the
DT binding discussions, and, AFAICT, there's still no
consensus about that.

In the mean time, it seems you applied those 6 patches on your 
staging tree - at least, I received 6 messages from you about
those commits. Also, as this conflict arrived at -next, I
suspect that those patches are still on your tree.

Please notice that, from my side, I don't have anything
against those patch series, as the changes on the media 
drivers are just at the ABI glue, and I already acked with
those changes. 

The only thing that concerns me is that, if this series gets applied
upstream, the patch that Stephen did will needed to be applied
upstream to, to avoid compilation breakages there due to the 
Exynos patches on my tree that depend on the current ABI.

Regards,
Mauro
> 
> greg k-h




Regards,
Mauro

Re: linux-next: manual merge of the staging tree with the v4l-dvb tree

[Greg KH]

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@canb.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,

greg k-h

Re: linux-next: manual merge of the staging tree with the v4l-dvb tree

[Mauro Carvalho Chehab]

Em Mon, 17 Mar 2014 18:55:42 +1100
Stephen Rothwell <sfr@canb.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.

Regards,
Mauro

linux-next: manual merge of the staging tree with the v4l-dvb tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 1520 bytes --]

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).

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

diff --cc drivers/media/platform/exynos4-is/fimc-is.c
index c289d5a69d09,9bdfa4599bc3..000000000000
--- a/drivers/media/platform/exynos4-is/fimc-is.c
+++ b/drivers/media/platform/exynos4-is/fimc-is.c
@@@ -168,19 -167,11 +168,19 @@@ static int fimc_is_parse_sensor_config(
  	u32 tmp = 0;
  	int ret;
  
 -	np = of_graph_get_next_endpoint(np, NULL);
 -	if (!np)
 +	sensor->drvdata = fimc_is_sensor_get_drvdata(node);
 +	if (!sensor->drvdata) {
 +		dev_err(&is->pdev->dev, "no driver data found for: %s\n",
 +							 node->full_name);
 +		return -EINVAL;
 +	}
 +
- 	node = v4l2_of_get_next_endpoint(node, NULL);
++	node = of_graph_get_next_endpoint(node, NULL);
 +	if (!node)
  		return -ENXIO;
 -	np = of_graph_get_remote_port(np);
 -	if (!np)
 +
- 	node = v4l2_of_get_remote_port(node);
++	node = of_graph_get_remote_port(node);
 +	if (!node)
  		return -ENXIO;
  
  	/* Use MIPI-CSIS channel id to determine the ISP I2C bus index. */

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

Re: linux-next: manual merge of the staging tree with the v4l-dvb tree

[Paul Gortmaker]

On 11-09-27 02:10 AM, Stephen Rothwell wrote:
> Hi Greg,
> 
> Today's linux-next merge of the staging tree got a conflict in
> drivers/misc/altera-stapl/altera.c between commit cff4fa8415a3 ("[media]
> altera-stapl: it is time to move out from staging") from the v4l-dvb tree
> and commit 99c978529a40 ("staging: Add module.h to drivers/staging
> users") from the staging tree.

Hey Greg/Stephen,

So that I could revalidate the module.h stuff with randconfig builds,
I've taken the above staging commit and re-applied it to the module.h
tree -- I'm pretty sure git will see it as the same commit and just
move on with no complaints, but just a heads up for Stephen in case.

This won't happen until Stephen takes the module.h from one of our
internal servers as a temporary measure while kernel.org is down.
I'll be sending that information to linux-next and Stephen later
today.

Paul.

> 
> Just context changes.  I fixed it up (see below) and can carry the fix as
> necessary.
> 
> Mauro, you could, of course, apply Paul's patch to the file in its new
> location.

Re: linux-next: manual merge of the staging tree with the v4l-dvb tree

[Greg KH]

On Tue, Sep 27, 2011 at 04:10:55PM +1000, Stephen Rothwell wrote:
> Hi Greg,
> 
> Today's linux-next merge of the staging tree got a conflict in
> drivers/misc/altera-stapl/altera.c between commit cff4fa8415a3 ("[media]
> altera-stapl: it is time to move out from staging") from the v4l-dvb tree
> and commit 99c978529a40 ("staging: Add module.h to drivers/staging
> users") from the staging tree.
> 
> Just context changes.  I fixed it up (see below) and can carry the fix as
> necessary.

Looks fine, thanks.

greg k-h

linux-next: manual merge of the staging tree with the v4l-dvb tree

[Stephen Rothwell]

Hi Greg,

Today's linux-next merge of the staging tree got a conflict in
drivers/misc/altera-stapl/altera.c between commit cff4fa8415a3 ("[media]
altera-stapl: it is time to move out from staging") from the v4l-dvb tree
and commit 99c978529a40 ("staging: Add module.h to drivers/staging
users") from the staging tree.

Just context changes.  I fixed it up (see below) and can carry the fix as
necessary.

Mauro, you could, of course, apply Paul's patch to the file in its new
location.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

diff --cc drivers/misc/altera-stapl/altera.c
index 1a2c50b,c2eff6a..0000000
--- a/drivers/misc/altera-stapl/altera.c
+++ b/drivers/misc/altera-stapl/altera.c
@@@ -28,7 -28,8 +28,8 @@@
  #include <linux/string.h>
  #include <linux/firmware.h>
  #include <linux/slab.h>
+ #include <linux/module.h>
 -#include "altera.h"
 +#include <misc/altera.h>
  #include "altera-exprt.h"
  #include "altera-jtag.h"
  

Re: linux-next: manual merge of the staging tree with the v4l-dvb tree

[Greg KH]

On Sat, Jul 16, 2011 at 11:03:58PM +1000, Stephen Rothwell wrote:
> Hi Greg,
> 
> Today's linux-next merge of the staging tree got a conflict in
> drivers/staging/tm6000/tm6000-alsa.c between commit 58d73afffaac
> ("[media] tm6000: remove a check for NO_PCM_LOCK") from the v4l-dvb tree
> and commit d684aee316ec ("tm6000: Cleaned up code style in
> tm6000-alsa.c") from the staging tree.
> 
> I fixed it up (see below) and can carry the fix as necessary.

That fix looks fine, thanks for doing it.

greg k-h

linux-next: manual merge of the staging tree with the v4l-dvb tree

[Stephen Rothwell]

Hi Greg,

Today's linux-next merge of the staging tree got a conflict in
drivers/staging/tm6000/tm6000-alsa.c between commit 58d73afffaac
("[media] tm6000: remove a check for NO_PCM_LOCK") from the v4l-dvb tree
and commit d684aee316ec ("tm6000: Cleaned up code style in
tm6000-alsa.c") from the staging tree.

I fixed it up (see below) and can carry the fix as necessary.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

diff --cc drivers/staging/tm6000/tm6000-alsa.c
index 018ff73,ddfd7c3..0000000
--- a/drivers/staging/tm6000/tm6000-alsa.c
+++ b/drivers/staging/tm6000/tm6000-alsa.c
@@@ -254,7 -254,9 +254,7 @@@ static int tm6000_fillbuf(struct tm6000
  		memcpy(runtime->dma_area + buf_pos * stride, buf,
  			length * stride);
  
-        snd_pcm_stream_lock(substream);
 -#ifndef NO_PCM_LOCK
+ 	snd_pcm_stream_lock(substream);
 -#endif
  
  	chip->buf_pos += length;
  	if (chip->buf_pos >= runtime->buffer_size)
@@@ -266,7 -268,9 +266,7 @@@
  		period_elapsed = 1;
  	}
  
-        snd_pcm_stream_unlock(substream);
 -#ifndef NO_PCM_LOCK
+ 	snd_pcm_stream_unlock(substream);
 -#endif
  
  	if (period_elapsed)
  		snd_pcm_period_elapsed(substream);

Re: linux-next: manual merge of the staging tree with the v4l-dvb tree

[Greg KH]

On Fri, Mar 04, 2011 at 04:39:15PM +1100, Stephen Rothwell wrote:
> Hi Greg,
> 
> Today's linux-next merge of the staging tree got a conflict in
> drivers/staging/easycap/easycap_ioctl.c between commit
> 0ff69fe7cebb65856eba7feb3fd76fb4ba365bf8 ("[media] v4l: removal of old,
> obsolete ioctls") from the v4l-dvb tree and commits
> f62bc44e055712fc8ccf34654a79137dd4a4d8af ("staging/easycap: remove
> obsolete VIDIOC_S_CTRL_OLD ioctl") and
> 50e1fbdc1c9965b6ddbc5c9900377ff18bbf9ae8 ("staging/easycap: add first
> level indentation to easycap_ioctl.c") from the staging tree.
> 
> The latter two were a superset of the former, so I used that.

Thanks, that looks correct.

greg k-h

Re: linux-next: manual merge of the staging tree with the v4l-dvb tree

[Greg KH]

On Fri, Mar 04, 2011 at 04:39:11PM +1100, Stephen Rothwell wrote:
> Hi Greg,
> 
> Today's linux-next merge of the staging tree got a conflict in
> drivers/staging/Makefile between commit
> a1256092a1e87511c977a3d0ef96151cda77e5c9 ("[media] Altera FPGA firmware
> download module") from the v4l-dvb tree and commit
> 0867b42113ec4eb8646eb361b15cbcfb741ddf5b ("staging: gma500: Intel GMA500
> staging driver") from the staging tree.
> 
> One of the reasons I dislike unrelated white space changes ... I fixed it
> up (see below) and can carry the fix as necessary.

Looks good, thanks.

greg k-h

Re: linux-next: manual merge of the staging tree with the v4l-dvb tree

[Greg KH]

On Fri, Mar 04, 2011 at 04:38:49PM +1100, Stephen Rothwell wrote:
> Hi Greg,
> 
> Today's linux-next merge of the staging tree got a conflict in
> drivers/staging/usbvideo/vicam.c between commit
> af6302700e87a883481c342001ef81b77641bf98 ("[media] staging-usbvideo:
> remove") from the v4l-dvb tree and commits
> 046d747e0d2cb597e0b6fa4a79c32b43e97ed792 ("Staging: usbvideo: vicam:
> fixed some coding style issues") and
> 38a26ef272d8a93c88de54d8d3bd14ac3ce36056 ("staging: usbvideo: vicam: Fix
> build in -next") from the staging tree.
> 
> I removed the file.

thanks for doing this.

greg k-h

Re: linux-next: manual merge of the staging tree with the v4l-dvb tree

[Greg KH]

On Fri, Mar 04, 2011 at 04:38:56PM +1100, Stephen Rothwell wrote:
> Hi Greg,
> 
> Today's linux-next merge of the staging tree got a conflict in
> drivers/staging/dabusb/dabusb.c and drivers/staging/dabusb/dabusb.h
> between commit f8f4a7f5c1219571acf55f3889138b594e5b3b68 ("[media] dabusb:
> remove obsolete driver") from the v4l-dvb tree and commit
> 868788278eaa5b841ec1a810b41e156f5fba0ab5 ("Staging: dabusb: fixed coding
> style issues") from the staging tree.
> 
> I removed the files.

That sounds correct, thanks.

greg k-h

Re: linux-next: manual merge of the staging tree with the v4l-dvb tree

[Greg KH]

On Fri, Mar 04, 2011 at 04:38:41PM +1100, Stephen Rothwell wrote:
> Hi Greg,
> 
> Today's linux-next merge of the staging tree got a conflict in
> drivers/staging/usbvideo/usbvideo.c between commit
> af6302700e87a883481c342001ef81b77641bf98 ([media] staging-usbvideo:
> remove"") from the v4l-dvb tree and commit  ("Staging: usbvideo:
> usbvideo: fixed some coding style issues") from the staging tree.
> 
> I removed the file.

Thanks, that's the correct thing to do.

greg k-h

linux-next: manual merge of the staging tree with the v4l-dvb tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 672 bytes --]

Hi Greg,

Today's linux-next merge of the staging tree got a conflict in
drivers/staging/easycap/easycap_ioctl.c between commit
0ff69fe7cebb65856eba7feb3fd76fb4ba365bf8 ("[media] v4l: removal of old,
obsolete ioctls") from the v4l-dvb tree and commits
f62bc44e055712fc8ccf34654a79137dd4a4d8af ("staging/easycap: remove
obsolete VIDIOC_S_CTRL_OLD ioctl") and
50e1fbdc1c9965b6ddbc5c9900377ff18bbf9ae8 ("staging/easycap: add first
level indentation to easycap_ioctl.c") from the staging tree.

The latter two were a superset of the former, so I used that.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]

linux-next: manual merge of the staging tree with the v4l-dvb tree

[Stephen Rothwell]

Hi Greg,

Today's linux-next merge of the staging tree got a conflict in
drivers/staging/Makefile between commit
a1256092a1e87511c977a3d0ef96151cda77e5c9 ("[media] Altera FPGA firmware
download module") from the v4l-dvb tree and commit
0867b42113ec4eb8646eb361b15cbcfb741ddf5b ("staging: gma500: Intel GMA500
staging driver") from the staging tree.

One of the reasons I dislike unrelated white space changes ... I fixed it
up (see below) and can carry the fix as necessary.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

diff --cc drivers/staging/Makefile
index 0269142,0983edc..0000000
--- a/drivers/staging/Makefile
+++ b/drivers/staging/Makefile
@@@ -61,13 -61,13 +61,14 @@@ obj-$(CONFIG_SOLO6X10)		+= solo6x10
  obj-$(CONFIG_TIDSPBRIDGE)	+= tidspbridge/
  obj-$(CONFIG_ACPI_QUICKSTART)	+= quickstart/
  obj-$(CONFIG_WESTBRIDGE_ASTORIA)	+= westbridge/astoria/
- obj-$(CONFIG_SBE_2T3E3)	+= sbe-2t3e3/
+ obj-$(CONFIG_SBE_2T3E3)		+= sbe-2t3e3/
  obj-$(CONFIG_ATH6K_LEGACY)	+= ath6kl/
  obj-$(CONFIG_USB_ENESTORAGE)	+= keucr/
- obj-$(CONFIG_BCM_WIMAX)	+= bcm/
+ obj-$(CONFIG_BCM_WIMAX)		+= bcm/
  obj-$(CONFIG_FT1000)		+= ft1000/
- obj-$(CONFIG_SND_INTEL_SST)		+= intel_sst/
- obj-$(CONFIG_SPEAKUP)	+= speakup/
+ obj-$(CONFIG_SND_INTEL_SST)	+= intel_sst/
+ obj-$(CONFIG_SPEAKUP)		+= speakup/
 +obj-$(CONFIG_ALTERA_STAPL)	+=altera-stapl/
  obj-$(CONFIG_TOUCHSCREEN_CLEARPAD_TM1217)	+= cptm1217/
  obj-$(CONFIG_TOUCHSCREEN_SYNAPTICS_I2C_RMI4)	+= ste_rmi4/
+ obj-$(CONFIG_DRM_PSB)		+= gma500/

linux-next: manual merge of the staging tree with the v4l-dvb tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 523 bytes --]

Hi Greg,

Today's linux-next merge of the staging tree got a conflict in
drivers/staging/dabusb/dabusb.c and drivers/staging/dabusb/dabusb.h
between commit f8f4a7f5c1219571acf55f3889138b594e5b3b68 ("[media] dabusb:
remove obsolete driver") from the v4l-dvb tree and commit
868788278eaa5b841ec1a810b41e156f5fba0ab5 ("Staging: dabusb: fixed coding
style issues") from the staging tree.

I removed the files.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]

linux-next: manual merge of the staging tree with the v4l-dvb tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 592 bytes --]

Hi Greg,

Today's linux-next merge of the staging tree got a conflict in
drivers/staging/usbvideo/vicam.c between commit
af6302700e87a883481c342001ef81b77641bf98 ("[media] staging-usbvideo:
remove") from the v4l-dvb tree and commits
046d747e0d2cb597e0b6fa4a79c32b43e97ed792 ("Staging: usbvideo: vicam:
fixed some coding style issues") and
38a26ef272d8a93c88de54d8d3bd14ac3ce36056 ("staging: usbvideo: vicam: Fix
build in -next") from the staging tree.

I removed the file.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]

linux-next: manual merge of the staging tree with the v4l-dvb tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 460 bytes --]

Hi Greg,

Today's linux-next merge of the staging tree got a conflict in
drivers/staging/usbvideo/usbvideo.c between commit
af6302700e87a883481c342001ef81b77641bf98 ([media] staging-usbvideo:
remove"") from the v4l-dvb tree and commit  ("Staging: usbvideo:
usbvideo: fixed some coding style issues") from the staging tree.

I removed the file.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]