Re: [GIT PULL] Char/Misc driver patches for 4.12-rc1

[Stephen Rothwell]

Hi all,

On Sat, 06 May 2017 11:12:36 -0700 James Bottomley 
 wrote:
>
> What about resending the conflict reminders at -rc7 ... that way we
> only have a week or two to forget again?

OK, I attempted to do that this time ... I wonder if it made a
difference :-)

> The other issue is that one of the potential trees only got notified
> directly (the char-misc one) because the tpmdd tree takes an indirect
> pull route.  I'm not sure what we can do about this one.

I have also tried (in most cases) to notify the effected maintainers
that ask Linus to pull.
 
-- 
Cheers,
Stephen Rothwell

Re: [GIT PULL] Char/Misc driver patches for 4.12-rc1

[Stephen Rothwell]

Hi all,

On Sat, 06 May 2017 11:12:36 -0700 James Bottomley 
 wrote:
>
> What about resending the conflict reminders at -rc7 ... that way we
> only have a week or two to forget again?

OK, I attempted to do that this time ... I wonder if it made a
difference :-)

> The other issue is that one of the potential trees only got notified
> directly (the char-misc one) because the tpmdd tree takes an indirect
> pull route.  I'm not sure what we can do about this one.

I have also tried (in most cases) to notify the effected maintainers
that ask Linus to pull.
 
-- 
Cheers,
Stephen Rothwell

Re: [GIT PULL] Char/Misc driver patches for 4.12-rc1

[James Bottomley]

On Sat, 2017-05-06 at 11:00 -0700, Linus Torvalds wrote:
> On Fri, May 5, 2017 at 10:09 PM, Stephen Rothwell <
> s...@canb.auug.org.au> wrote:
> > 
> > On Fri, 5 May 2017 13:01:34 -0700 Linus Torvalds <
> > torva...@linux-foundation.org> wrote:
> > > 
> > > 
> > > I prefer doing merge resolutions myself, but I *also* really 
> > > really prefer the two sides of the conflict having been more 
> > > aware of the clash.
> > 
> > Would that be this?
> 
> Yup. Apparently neither Greg nor James ended up reacting to that
> email, though,

Yes, we did, but for the one in SCSI ... as I said the original
conflict resolution with our tree was eventually found to be slightly
wrong so there was an email thread over it.

There's not much I can do about the one in tpmdd-devel because it's not
my tree.  Even Jarkko can't do much more than tell James Morris for the
Security tree, and I think this came up after it had already been
pulled into that tree.

>  so by the time I got the pull requests there was no
> mention of it anywhere.

Well, there was in the SCSI pull request, but the only reason I
remembered is because I'd made a special note of the potential resolve
problem when this came up on the SCSI mailing list.  The original merge
conflict email came 6 weeks before the merge window, which is why
everyone had had time to forget.

What about resending the conflict reminders at -rc7 ... that way we
only have a week or two to forget again?

The other issue is that one of the potential trees only got notified
directly (the char-misc one) because the tpmdd tree takes an indirect
pull route.  I'm not sure what we can do about this one.

James

Re: [GIT PULL] Char/Misc driver patches for 4.12-rc1

[James Bottomley]

On Sat, 2017-05-06 at 11:00 -0700, Linus Torvalds wrote:
> On Fri, May 5, 2017 at 10:09 PM, Stephen Rothwell <
> s...@canb.auug.org.au> wrote:
> > 
> > On Fri, 5 May 2017 13:01:34 -0700 Linus Torvalds <
> > torva...@linux-foundation.org> wrote:
> > > 
> > > 
> > > I prefer doing merge resolutions myself, but I *also* really 
> > > really prefer the two sides of the conflict having been more 
> > > aware of the clash.
> > 
> > Would that be this?
> 
> Yup. Apparently neither Greg nor James ended up reacting to that
> email, though,

Yes, we did, but for the one in SCSI ... as I said the original
conflict resolution with our tree was eventually found to be slightly
wrong so there was an email thread over it.

There's not much I can do about the one in tpmdd-devel because it's not
my tree.  Even Jarkko can't do much more than tell James Morris for the
Security tree, and I think this came up after it had already been
pulled into that tree.

>  so by the time I got the pull requests there was no
> mention of it anywhere.

Well, there was in the SCSI pull request, but the only reason I
remembered is because I'd made a special note of the potential resolve
problem when this came up on the SCSI mailing list.  The original merge
conflict email came 6 weeks before the merge window, which is why
everyone had had time to forget.

What about resending the conflict reminders at -rc7 ... that way we
only have a week or two to forget again?

The other issue is that one of the potential trees only got notified
directly (the char-misc one) because the tpmdd tree takes an indirect
pull route.  I'm not sure what we can do about this one.

James

Re: [GIT PULL] Char/Misc driver patches for 4.12-rc1

[Linus Torvalds]

On Fri, May 5, 2017 at 10:09 PM, Stephen Rothwell  wrote:
>
> On Fri, 5 May 2017 13:01:34 -0700 Linus Torvalds 
>  wrote:
>>
>>
>> I prefer doing merge resolutions myself, but I *also* really really
>> prefer the two sides of the conflict having been more aware of the
>> clash.
>
> Would that be this?

Yup. Apparently neither Greg nor James ended up reacting to that
email, though, so by the time I got the pull requests there was no
mention of it anywhere.

 Linus

Re: [GIT PULL] Char/Misc driver patches for 4.12-rc1

[Linus Torvalds]

On Fri, May 5, 2017 at 10:09 PM, Stephen Rothwell  wrote:
>
> On Fri, 5 May 2017 13:01:34 -0700 Linus Torvalds 
>  wrote:
>>
>>
>> I prefer doing merge resolutions myself, but I *also* really really
>> prefer the two sides of the conflict having been more aware of the
>> clash.
>
> Would that be this?

Yup. Apparently neither Greg nor James ended up reacting to that
email, though, so by the time I got the pull requests there was no
mention of it anywhere.

 Linus

Re: [GIT PULL] Char/Misc driver patches for 4.12-rc1

[Stephen Rothwell]

Hi Linus,

On Fri, 5 May 2017 13:01:34 -0700 Linus Torvalds 
 wrote:
>
> I actually would have preferred to not get any early merges, but what
> I was unhappy about is that I also didn't really get any heads-up
> about the cdev_device_add() conflict.
> 
> I did get notified about the other conflict (thanks, James), but
> somehow the cdev_device_add() changes didn't cause the same kind of
> notification.
> 
> So my unhappiness is not about me having to resolve things (I'm happy
> to do that) but about how apparently -next failed to notice that part
> of my merge resolution. Or maybe it was noticed in -next, but then the
> information about it got lost.
> 
> I prefer doing merge resolutions myself, but I *also* really really
> prefer the two sides of the conflict having been more aware of the
> clash.

Would that be this?

From: Stephen Rothwell 
To: Greg KH , Arnd Bergmann , Jarkko Sakkinen  

Cc: linux-n...@vger.kernel.org, linux-kernel@vger.kernel.org, Logan  Gunthorpe 
, James Bottomley  
Subject: linux-next: manual merge of the char-misc tree with the tpmdd tree
Date: Fri, 24 Mar 2017 14:33:02 +1100

Hi all,

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

  drivers/char/tpm/tpm-chip.c

between commits:

  67b67480db8b ("tpm: infrastructure for TPM spaces")
  b8e3586e8536 ("tpm: expose spaces via a device link /dev/tpmrm")

from the tpmdd tree and commit:

  8dbbf5825181 ("tpm-chip: utilize new cdev_device_add helper function")

from the char-misc 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/char/tpm/tpm-chip.c
index aade6995f310,935f0e92ad61..
--- a/drivers/char/tpm/tpm-chip.c
+++ b/drivers/char/tpm/tpm-chip.c
@@@ -214,22 -186,7 +214,20 @@@ struct tpm_chip *tpm_chip_alloc(struct 
chip->flags |= TPM_CHIP_FLAG_VIRTUAL;
  
cdev_init(>cdev, _fops);
 +  cdev_init(>cdevs, _fops);
chip->cdev.owner = THIS_MODULE;
 +  chip->cdevs.owner = THIS_MODULE;
-   chip->cdev.kobj.parent = >dev.kobj;
-   chip->cdevs.kobj.parent = >devs.kobj;
 +
 +  chip->work_space.context_buf = kzalloc(PAGE_SIZE, GFP_KERNEL);
 +  if (!chip->work_space.context_buf) {
 +  rc = -ENOMEM;
 +  goto out;
 +  }
 +  chip->work_space.session_buf = kzalloc(PAGE_SIZE, GFP_KERNEL);
 +  if (!chip->work_space.session_buf) {
 +  rc = -ENOMEM;
 +  goto out;
 +  }
  
return chip;
  
@@@ -273,44 -229,13 +271,22 @@@ static int tpm_add_char_device(struct t
  {
int rc;
  
-   rc = cdev_add(>cdev, chip->dev.devt, 1);
+   rc = cdev_device_add(>cdev, >dev);
if (rc) {
dev_err(>dev,
-   "unable to cdev_add() %s, major %d, minor %d, err=%d\n",
+   "unable to cdev_device_add() %s, major %d, minor %d, 
err=%d\n",
dev_name(>dev), MAJOR(chip->dev.devt),
MINOR(chip->dev.devt), rc);
 +  return rc;
 +  }
  
-   rc = device_add(>dev);
-   if (rc) {
-   dev_err(>dev,
-   "unable to device_register() %s, major %d, minor %d, 
err=%d\n",
-   dev_name(>dev), MAJOR(chip->dev.devt),
-   MINOR(chip->dev.devt), rc);
- 
-   cdev_del(>cdev);
-   return rc;
-   }
- 
-   if (chip->flags & TPM_CHIP_FLAG_TPM2)
-   rc = cdev_add(>cdevs, chip->devs.devt, 1);
-   if (rc) {
-   dev_err(>dev,
-   "unable to cdev_add() %s, major %d, minor %d, err=%d\n",
-   dev_name(>devs), MAJOR(chip->devs.devt),
-   MINOR(chip->devs.devt), rc);
-   return rc;
-   }
- 
 +  if (chip->flags & TPM_CHIP_FLAG_TPM2)
-   rc = device_add(>devs);
++  rc = cdev_device_add(>cdevs, >devs);
 +  if (rc) {
 +  dev_err(>dev,
-   "unable to device_register() %s, major %d, minor %d, 
err=%d\n",
++  "unable to cdev_device_add() %s, major %d, minor %d, 
err=%d\n",
 +  dev_name(>devs), MAJOR(chip->devs.devt),
 +  MINOR(chip->devs.devt), rc);
-   cdev_del(>cdevs);
return rc;
}
  
@@@ -447,10 -371,6 +422,8 @@@ void tpm_chip_unregister(struct tpm_chi
  {
tpm_del_legacy_sysfs(chip);

Re: [GIT PULL] Char/Misc driver patches for 4.12-rc1

[Stephen Rothwell]

Hi Linus,

On Fri, 5 May 2017 13:01:34 -0700 Linus Torvalds 
 wrote:
>
> I actually would have preferred to not get any early merges, but what
> I was unhappy about is that I also didn't really get any heads-up
> about the cdev_device_add() conflict.
> 
> I did get notified about the other conflict (thanks, James), but
> somehow the cdev_device_add() changes didn't cause the same kind of
> notification.
> 
> So my unhappiness is not about me having to resolve things (I'm happy
> to do that) but about how apparently -next failed to notice that part
> of my merge resolution. Or maybe it was noticed in -next, but then the
> information about it got lost.
> 
> I prefer doing merge resolutions myself, but I *also* really really
> prefer the two sides of the conflict having been more aware of the
> clash.

Would that be this?

From: Stephen Rothwell 
To: Greg KH , Arnd Bergmann , Jarkko Sakkinen  

Cc: linux-n...@vger.kernel.org, linux-kernel@vger.kernel.org, Logan  Gunthorpe 
, James Bottomley  
Subject: linux-next: manual merge of the char-misc tree with the tpmdd tree
Date: Fri, 24 Mar 2017 14:33:02 +1100

Hi all,

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

  drivers/char/tpm/tpm-chip.c

between commits:

  67b67480db8b ("tpm: infrastructure for TPM spaces")
  b8e3586e8536 ("tpm: expose spaces via a device link /dev/tpmrm")

from the tpmdd tree and commit:

  8dbbf5825181 ("tpm-chip: utilize new cdev_device_add helper function")

from the char-misc 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/char/tpm/tpm-chip.c
index aade6995f310,935f0e92ad61..
--- a/drivers/char/tpm/tpm-chip.c
+++ b/drivers/char/tpm/tpm-chip.c
@@@ -214,22 -186,7 +214,20 @@@ struct tpm_chip *tpm_chip_alloc(struct 
chip->flags |= TPM_CHIP_FLAG_VIRTUAL;
  
cdev_init(>cdev, _fops);
 +  cdev_init(>cdevs, _fops);
chip->cdev.owner = THIS_MODULE;
 +  chip->cdevs.owner = THIS_MODULE;
-   chip->cdev.kobj.parent = >dev.kobj;
-   chip->cdevs.kobj.parent = >devs.kobj;
 +
 +  chip->work_space.context_buf = kzalloc(PAGE_SIZE, GFP_KERNEL);
 +  if (!chip->work_space.context_buf) {
 +  rc = -ENOMEM;
 +  goto out;
 +  }
 +  chip->work_space.session_buf = kzalloc(PAGE_SIZE, GFP_KERNEL);
 +  if (!chip->work_space.session_buf) {
 +  rc = -ENOMEM;
 +  goto out;
 +  }
  
return chip;
  
@@@ -273,44 -229,13 +271,22 @@@ static int tpm_add_char_device(struct t
  {
int rc;
  
-   rc = cdev_add(>cdev, chip->dev.devt, 1);
+   rc = cdev_device_add(>cdev, >dev);
if (rc) {
dev_err(>dev,
-   "unable to cdev_add() %s, major %d, minor %d, err=%d\n",
+   "unable to cdev_device_add() %s, major %d, minor %d, 
err=%d\n",
dev_name(>dev), MAJOR(chip->dev.devt),
MINOR(chip->dev.devt), rc);
 +  return rc;
 +  }
  
-   rc = device_add(>dev);
-   if (rc) {
-   dev_err(>dev,
-   "unable to device_register() %s, major %d, minor %d, 
err=%d\n",
-   dev_name(>dev), MAJOR(chip->dev.devt),
-   MINOR(chip->dev.devt), rc);
- 
-   cdev_del(>cdev);
-   return rc;
-   }
- 
-   if (chip->flags & TPM_CHIP_FLAG_TPM2)
-   rc = cdev_add(>cdevs, chip->devs.devt, 1);
-   if (rc) {
-   dev_err(>dev,
-   "unable to cdev_add() %s, major %d, minor %d, err=%d\n",
-   dev_name(>devs), MAJOR(chip->devs.devt),
-   MINOR(chip->devs.devt), rc);
-   return rc;
-   }
- 
 +  if (chip->flags & TPM_CHIP_FLAG_TPM2)
-   rc = device_add(>devs);
++  rc = cdev_device_add(>cdevs, >devs);
 +  if (rc) {
 +  dev_err(>dev,
-   "unable to device_register() %s, major %d, minor %d, 
err=%d\n",
++  "unable to cdev_device_add() %s, major %d, minor %d, 
err=%d\n",
 +  dev_name(>devs), MAJOR(chip->devs.devt),
 +  MINOR(chip->devs.devt), rc);
-   cdev_del(>cdevs);
return rc;
}
  
@@@ -447,10 -371,6 +422,8 @@@ void tpm_chip_unregister(struct tpm_chi
  {
tpm_del_legacy_sysfs(chip);
tpm_bios_log_teardown(chip);
-   if (chip->flags & TPM_CHIP_FLAG_TPM2) {
-   cdev_del(>cdevs);
-   device_del(>devs);
-   }
++  if (chip->flags & 

Re: [GIT PULL] Char/Misc driver patches for 4.12-rc1

[Linus Torvalds]

On Fri, May 5, 2017 at 9:38 AM, Greg KH  wrote:
> On Fri, May 05, 2017 at 09:00:06AM -0700, James Bottomley wrote:
>> On Thu, 2017-05-04 at 19:28 -0700, Linus Torvalds wrote:
>> >
>> > Ugh. I'm not particularly happy with the conflicts I got and my
>> > resolutions there-of.
>>
>> Yes, we really should have done this via a postmerge tree.  We've had
>> so little cause to use them recently, I suspect everyone's forgotten
>> how.
>
> Huh?  You could have pulled in my tree into this one, or I could have
> done that for you, my trees are not rebased at all, and they get used
> this way every other release or so for this very reason.

I actually would have preferred to not get any early merges, but what
I was unhappy about is that I also didn't really get any heads-up
about the cdev_device_add() conflict.

I did get notified about the other conflict (thanks, James), but
somehow the cdev_device_add() changes didn't cause the same kind of
notification.

So my unhappiness is not about me having to resolve things (I'm happy
to do that) but about how apparently -next failed to notice that part
of my merge resolution. Or maybe it was noticed in -next, but then the
information about it got lost.

I prefer doing merge resolutions myself, but I *also* really really
prefer the two sides of the conflict having been more aware of the
clash.

  Linus

Re: [GIT PULL] Char/Misc driver patches for 4.12-rc1

[Linus Torvalds]

On Fri, May 5, 2017 at 9:38 AM, Greg KH  wrote:
> On Fri, May 05, 2017 at 09:00:06AM -0700, James Bottomley wrote:
>> On Thu, 2017-05-04 at 19:28 -0700, Linus Torvalds wrote:
>> >
>> > Ugh. I'm not particularly happy with the conflicts I got and my
>> > resolutions there-of.
>>
>> Yes, we really should have done this via a postmerge tree.  We've had
>> so little cause to use them recently, I suspect everyone's forgotten
>> how.
>
> Huh?  You could have pulled in my tree into this one, or I could have
> done that for you, my trees are not rebased at all, and they get used
> this way every other release or so for this very reason.

I actually would have preferred to not get any early merges, but what
I was unhappy about is that I also didn't really get any heads-up
about the cdev_device_add() conflict.

I did get notified about the other conflict (thanks, James), but
somehow the cdev_device_add() changes didn't cause the same kind of
notification.

So my unhappiness is not about me having to resolve things (I'm happy
to do that) but about how apparently -next failed to notice that part
of my merge resolution. Or maybe it was noticed in -next, but then the
information about it got lost.

I prefer doing merge resolutions myself, but I *also* really really
prefer the two sides of the conflict having been more aware of the
clash.

  Linus

Re: [GIT PULL] Char/Misc driver patches for 4.12-rc1

[James Bottomley]

On Fri, 2017-05-05 at 09:38 -0700, Greg KH wrote:
> On Fri, May 05, 2017 at 09:00:06AM -0700, James Bottomley wrote:
> > On Thu, 2017-05-04 at 19:28 -0700, Linus Torvalds wrote:
> > > On Thu, May 4, 2017 at 5:18 PM, Greg KH <
> > > gre...@linuxfoundation.org>
> > > wrote:
> > > > 
> > > > Here is the big set of new char/misc driver drivers and
> > > > features 
> > > > for 4.12-rc1.
> > > 
> > > Ugh. I'm not particularly happy with the conflicts I got and my
> > > resolutions there-of.
> > 
> > Yes, we really should have done this via a postmerge tree.  We've 
> > had so little cause to use them recently, I suspect everyone's
> > forgotten how.
> 
> Huh?  You could have pulled in my tree into this one, or I could have
> done that for you, my trees are not rebased at all, and they get used
> this way every other release or so for this very reason.

Well, I think this is the process issue, isn't it?  You're telling me I
could have run the tree or you could (actually, you don't mean me: this
is a security subsystem where Jarkko sends a pull to James Morris who
sends it on to Linus so it would be JamesM running it).  I'm asking the
question why we didn't.  I think we didn't because once Stephen worked
out the merge commit everyone forgot about the problem.

So the first process question is: "is what we did what should happen". 
 We can say yes and stop here: linux-next did the merges with conflict
resolution.  The osd initial merge was wrong, so we went back on linux
-scsi and had it corrected and I remembered to send in the resolution
from linux-next with the SCSI pull request so as not to have the
obvious but wrong resolution problem happen again.  The same thing
could be done with the security tree.  I think it's easy to conclude
that this is probably good enough.

If we have more of a desire to avoid tree conflicts, then postmerge
trees could be the answer, but in in this case, since changing the
existing API users to the new API (which is where all the nasty
conflicts were) weren't really time critical, the code could have been
staged as a new API plus patches that use it in one cycle and
conversions of existing users in a second.  The later could have gone
through the proper Maintainer trees and we'd never have seen a conflict
in any of the subsystems.

James

Re: [GIT PULL] Char/Misc driver patches for 4.12-rc1

[James Bottomley]

On Fri, 2017-05-05 at 09:38 -0700, Greg KH wrote:
> On Fri, May 05, 2017 at 09:00:06AM -0700, James Bottomley wrote:
> > On Thu, 2017-05-04 at 19:28 -0700, Linus Torvalds wrote:
> > > On Thu, May 4, 2017 at 5:18 PM, Greg KH <
> > > gre...@linuxfoundation.org>
> > > wrote:
> > > > 
> > > > Here is the big set of new char/misc driver drivers and
> > > > features 
> > > > for 4.12-rc1.
> > > 
> > > Ugh. I'm not particularly happy with the conflicts I got and my
> > > resolutions there-of.
> > 
> > Yes, we really should have done this via a postmerge tree.  We've 
> > had so little cause to use them recently, I suspect everyone's
> > forgotten how.
> 
> Huh?  You could have pulled in my tree into this one, or I could have
> done that for you, my trees are not rebased at all, and they get used
> this way every other release or so for this very reason.

Well, I think this is the process issue, isn't it?  You're telling me I
could have run the tree or you could (actually, you don't mean me: this
is a security subsystem where Jarkko sends a pull to James Morris who
sends it on to Linus so it would be JamesM running it).  I'm asking the
question why we didn't.  I think we didn't because once Stephen worked
out the merge commit everyone forgot about the problem.

So the first process question is: "is what we did what should happen". 
 We can say yes and stop here: linux-next did the merges with conflict
resolution.  The osd initial merge was wrong, so we went back on linux
-scsi and had it corrected and I remembered to send in the resolution
from linux-next with the SCSI pull request so as not to have the
obvious but wrong resolution problem happen again.  The same thing
could be done with the security tree.  I think it's easy to conclude
that this is probably good enough.

If we have more of a desire to avoid tree conflicts, then postmerge
trees could be the answer, but in in this case, since changing the
existing API users to the new API (which is where all the nasty
conflicts were) weren't really time critical, the code could have been
staged as a new API plus patches that use it in one cycle and
conversions of existing users in a second.  The later could have gone
through the proper Maintainer trees and we'd never have seen a conflict
in any of the subsystems.

James

Re: [GIT PULL] Char/Misc driver patches for 4.12-rc1

[James Bottomley]

On Fri, 2017-05-05 at 09:33 -0700, Linus Torvalds wrote:
> On Fri, May 5, 2017 at 9:00 AM, James Bottomley
>  wrote:
> > 
> > I'm not going to defend the earlier coding, but you've lost the 
> > real device_add() calls in the merge, meaning the tpm devices don't
> > actually get made visible at all.  I suspect assuming device_add() 
> > is done by cdev_device_add() because of the name is going to be our 
> > next anti-pattern, so you're at least ahead of the game ...
> 
> Don't be silly. That's *exactly* what cdev_device_add() does.

Oh, you're right, sorry, I was going by the patches that were cc'd to
the TPM list, which only had the two line addition for
cdev_device_add() ... apparently no-one sent any updates.  Yes, the new
function looks much better and the resolution works.  Sorry for the
noise.

James

Re: [GIT PULL] Char/Misc driver patches for 4.12-rc1

[James Bottomley]

On Fri, 2017-05-05 at 09:33 -0700, Linus Torvalds wrote:
> On Fri, May 5, 2017 at 9:00 AM, James Bottomley
>  wrote:
> > 
> > I'm not going to defend the earlier coding, but you've lost the 
> > real device_add() calls in the merge, meaning the tpm devices don't
> > actually get made visible at all.  I suspect assuming device_add() 
> > is done by cdev_device_add() because of the name is going to be our 
> > next anti-pattern, so you're at least ahead of the game ...
> 
> Don't be silly. That's *exactly* what cdev_device_add() does.

Oh, you're right, sorry, I was going by the patches that were cc'd to
the TPM list, which only had the two line addition for
cdev_device_add() ... apparently no-one sent any updates.  Yes, the new
function looks much better and the resolution works.  Sorry for the
noise.

James

Re: [GIT PULL] Char/Misc driver patches for 4.12-rc1

[Greg KH]

On Fri, May 05, 2017 at 09:00:06AM -0700, James Bottomley wrote:
> On Thu, 2017-05-04 at 19:28 -0700, Linus Torvalds wrote:
> > On Thu, May 4, 2017 at 5:18 PM, Greg KH 
> > wrote:
> > > 
> > > Here is the big set of new char/misc driver drivers and features 
> > > for 4.12-rc1.
> > 
> > Ugh. I'm not particularly happy with the conflicts I got and my
> > resolutions there-of.
> 
> Yes, we really should have done this via a postmerge tree.  We've had
> so little cause to use them recently, I suspect everyone's forgotten
> how.

Huh?  You could have pulled in my tree into this one, or I could have
done that for you, my trees are not rebased at all, and they get used
this way every other release or so for this very reason.

> > James, Jarkko, you need to look at that tpm merge of mine. And James,
> > double-check my osd_uld thing too.
> 
> I'm not going to defend the earlier coding, but you've lost the real
> device_add() calls in the merge, meaning the tpm devices don't actually
> get made visible at all.  I suspect assuming device_add() is done by
> cdev_device_add() because of the name is going to be our next anti
> -pattern, so you're at least ahead of the game ...

It's not an anti-pattern at all, it is ment to fix the bugs you, and
others, keep making :)

> @@ -272,24 +272,30 @@ EXPORT_SYMBOL_GPL(tpmm_chip_alloc);
>  static int tpm_add_char_device(struct tpm_chip *chip)
>  {
>   int rc;
> + const char *errstr;
> + struct device *errdev = >dev;
>  
>   rc = cdev_device_add(>cdev, >dev);
>   if (rc) {
> - dev_err(>dev,
> - "unable to cdev_device_add() %s, major %d, minor %d, 
> err=%d\n",
> - dev_name(>dev), MAJOR(chip->dev.devt),
> - MINOR(chip->dev.devt), rc);
> - return rc;
> + errstr = "cdev_device_add for main device";
> + goto error1;
> + }
> + rc = device_add(>dev);

Not to pile on, but as Linus said, this is totally wrong.  Did you test
it?  chip->dev is already registered at this point in time...

thanks,

greg k-h

Re: [GIT PULL] Char/Misc driver patches for 4.12-rc1

[Greg KH]

On Fri, May 05, 2017 at 09:00:06AM -0700, James Bottomley wrote:
> On Thu, 2017-05-04 at 19:28 -0700, Linus Torvalds wrote:
> > On Thu, May 4, 2017 at 5:18 PM, Greg KH 
> > wrote:
> > > 
> > > Here is the big set of new char/misc driver drivers and features 
> > > for 4.12-rc1.
> > 
> > Ugh. I'm not particularly happy with the conflicts I got and my
> > resolutions there-of.
> 
> Yes, we really should have done this via a postmerge tree.  We've had
> so little cause to use them recently, I suspect everyone's forgotten
> how.

Huh?  You could have pulled in my tree into this one, or I could have
done that for you, my trees are not rebased at all, and they get used
this way every other release or so for this very reason.

> > James, Jarkko, you need to look at that tpm merge of mine. And James,
> > double-check my osd_uld thing too.
> 
> I'm not going to defend the earlier coding, but you've lost the real
> device_add() calls in the merge, meaning the tpm devices don't actually
> get made visible at all.  I suspect assuming device_add() is done by
> cdev_device_add() because of the name is going to be our next anti
> -pattern, so you're at least ahead of the game ...

It's not an anti-pattern at all, it is ment to fix the bugs you, and
others, keep making :)

> @@ -272,24 +272,30 @@ EXPORT_SYMBOL_GPL(tpmm_chip_alloc);
>  static int tpm_add_char_device(struct tpm_chip *chip)
>  {
>   int rc;
> + const char *errstr;
> + struct device *errdev = >dev;
>  
>   rc = cdev_device_add(>cdev, >dev);
>   if (rc) {
> - dev_err(>dev,
> - "unable to cdev_device_add() %s, major %d, minor %d, 
> err=%d\n",
> - dev_name(>dev), MAJOR(chip->dev.devt),
> - MINOR(chip->dev.devt), rc);
> - return rc;
> + errstr = "cdev_device_add for main device";
> + goto error1;
> + }
> + rc = device_add(>dev);

Not to pile on, but as Linus said, this is totally wrong.  Did you test
it?  chip->dev is already registered at this point in time...

thanks,

greg k-h

Re: [GIT PULL] Char/Misc driver patches for 4.12-rc1

[Linus Torvalds]

On Fri, May 5, 2017 at 9:00 AM, James Bottomley
 wrote:
>
> I'm not going to defend the earlier coding, but you've lost the real
> device_add() calls in the merge, meaning the tpm devices don't actually
> get made visible at all.  I suspect assuming device_add() is done by
> cdev_device_add() because of the name is going to be our next anti
> -pattern, so you're at least ahead of the game ...

Don't be silly. That's *exactly* what cdev_device_add() does.

That's the whole and only point of the whole function: it does *both*
the cdev_add() _and_ the device_add(), and it handles errors sanely
and unwinds things.

So removing the device_add() is what the code should do. It's also
exactly what the commit I pointed you at does (the one that clashed
with your addition of the new ":[c]devs" cases. Let me repeat:

  8dbbf5825181 tpm-chip: utilize new cdev_device_add helper function

So your patch looks like complete garbage, and I think you're confused
about what cdev_device_add() is.

I think you're confusing it with the nasty old "cdev_add()" function
that indeed didn't do a "device_add()", but that's exactly why
"cdev_device_add()" as added, so that you don't have to have that
nasty pattern of having both.

That said, I do think that my merge is missing a "cdev_device_del()"
in the [c]dev if the second cdev_device_add() (on [c]devs) fails.

Although I also considered just saying "maybe if the second device
register fails, we still want to just succeed, and at least leave the
first one available".  Because why shouldn't you let people access at
least the old interface even if the new interface couldn't be set up?

So that's part of why I'd like people to look at that resolutin. But
more importantly it should be tested.

   Linus

Re: [GIT PULL] Char/Misc driver patches for 4.12-rc1

[Linus Torvalds]

On Fri, May 5, 2017 at 9:00 AM, James Bottomley
 wrote:
>
> I'm not going to defend the earlier coding, but you've lost the real
> device_add() calls in the merge, meaning the tpm devices don't actually
> get made visible at all.  I suspect assuming device_add() is done by
> cdev_device_add() because of the name is going to be our next anti
> -pattern, so you're at least ahead of the game ...

Don't be silly. That's *exactly* what cdev_device_add() does.

That's the whole and only point of the whole function: it does *both*
the cdev_add() _and_ the device_add(), and it handles errors sanely
and unwinds things.

So removing the device_add() is what the code should do. It's also
exactly what the commit I pointed you at does (the one that clashed
with your addition of the new ":[c]devs" cases. Let me repeat:

  8dbbf5825181 tpm-chip: utilize new cdev_device_add helper function

So your patch looks like complete garbage, and I think you're confused
about what cdev_device_add() is.

I think you're confusing it with the nasty old "cdev_add()" function
that indeed didn't do a "device_add()", but that's exactly why
"cdev_device_add()" as added, so that you don't have to have that
nasty pattern of having both.

That said, I do think that my merge is missing a "cdev_device_del()"
in the [c]dev if the second cdev_device_add() (on [c]devs) fails.

Although I also considered just saying "maybe if the second device
register fails, we still want to just succeed, and at least leave the
first one available".  Because why shouldn't you let people access at
least the old interface even if the new interface couldn't be set up?

So that's part of why I'd like people to look at that resolutin. But
more importantly it should be tested.

   Linus

Re: [GIT PULL] Char/Misc driver patches for 4.12-rc1

[James Bottomley]

On Thu, 2017-05-04 at 19:28 -0700, Linus Torvalds wrote:
> On Thu, May 4, 2017 at 5:18 PM, Greg KH 
> wrote:
> > 
> > Here is the big set of new char/misc driver drivers and features 
> > for 4.12-rc1.
> 
> Ugh. I'm not particularly happy with the conflicts I got and my
> resolutions there-of.

Yes, we really should have done this via a postmerge tree.  We've had
so little cause to use them recently, I suspect everyone's forgotten
how.

> I did resolve them - in the case of drivers/scsi/osd/osd_uld.c as per
> James' suggestion from his SCSI pull. Thanks.
> 
> But even that resolution I'm not entirely happy with: somebody should
> check that it cleans up oud properly

It looks fine to me, but I'll ask the osd people (well person, since
it's very little used).

> But the one I'm really unhappy with is my tpm-chip.c resolution.
> 
> In particular, commit 8dbbf5825181 ("tpm-chip: utilize new
> cdev_device_add helper function") made the tpm-chip code use that
> cdev_device_add/del pattern for chip->[c]dev. Fine.
> 
> But then commit fdc915f7f719 ("tpm: expose spaces via a device link
> /dev/tpmrm") added the *exact* same old pattern to a new
> "chip->[c]devs" (note the extra 's') and did so in a particularly
> ugly
> way too.
> 
> James, why did you do that nasty
> 
> if (chip->flags & TPM_CHIP_FLAG_TPM2)
> 
> *twice*, instead of just doing things properly inside *one* test?
> 
> Anyway, my merge resolution tries to just apply the same
> cdev_device_add/del pattern to the new chip->[c]devs entries, because
> not doing so seemed criminally ugly.
> 
> It compiles. It looks better than the mess it was. But it may not
> work.
> 
> James, Jarkko, you need to look at that tpm merge of mine. And James,
> double-check my osd_uld thing too.

I'm not going to defend the earlier coding, but you've lost the real
device_add() calls in the merge, meaning the tpm devices don't actually
get made visible at all.  I suspect assuming device_add() is done by
cdev_device_add() because of the name is going to be our next anti
-pattern, so you're at least ahead of the game ...

I think the below is the correct fix, but we should really take it
through the TPM list (or at least give me time for some runtime
testing) because I suddenly think the error leg unwinding isn't correct
in the original, so I've redone that too.

James

---

diff --git a/drivers/char/tpm/tpm-chip.c b/drivers/char/tpm/tpm-chip.c
index 322b8a51ffc6..867cef5ca9e5 100644
--- a/drivers/char/tpm/tpm-chip.c
+++ b/drivers/char/tpm/tpm-chip.c
@@ -272,24 +272,30 @@ EXPORT_SYMBOL_GPL(tpmm_chip_alloc);
 static int tpm_add_char_device(struct tpm_chip *chip)
 {
int rc;
+   const char *errstr;
+   struct device *errdev = >dev;
 
rc = cdev_device_add(>cdev, >dev);
if (rc) {
-   dev_err(>dev,
-   "unable to cdev_device_add() %s, major %d, minor %d, 
err=%d\n",
-   dev_name(>dev), MAJOR(chip->dev.devt),
-   MINOR(chip->dev.devt), rc);
-   return rc;
+   errstr = "cdev_device_add for main device";
+   goto error1;
+   }
+   rc = device_add(>dev);
+   if (rc) {
+   errstr = "device_add for main device";
+   goto error2;
}
-
if (chip->flags & TPM_CHIP_FLAG_TPM2) {
+   errdev = >devs;
rc = cdev_device_add(>cdevs, >devs);
if (rc) {
-   dev_err(>devs,
-   "unable to cdev_device_add() %s, major %d, 
minor %d, err=%d\n",
-   dev_name(>devs), MAJOR(chip->devs.devt),
-   MINOR(chip->devs.devt), rc);
-   return rc;
+   errstr = "cdev_device_add for rm device";
+   goto error3;
+   }
+   rc = device_add(>devs);
+   if (rc) {
+   errstr = "device_add for rm device";
+   goto error4;
}
}
 
@@ -299,6 +305,19 @@ static int tpm_add_char_device(struct tpm_chip *chip)
mutex_unlock(_lock);
 
return rc;
+
+ error4:
+   cdev_del(>cdevs);
+ error3:
+   device_del(>dev);
+ error2:
+   cdev_del(>cdev);
+ error1:
+   dev_err(>dev,
+   "Failed %s %s, major %d, minor %d, err=%d\n",
+   errstr, dev_name(errdev), MAJOR(errdev->devt),
+   MINOR(errdev->devt), rc);
+   return rc;
 }
 
 static void tpm_del_char_device(struct tpm_chip *chip)

Re: [GIT PULL] Char/Misc driver patches for 4.12-rc1

[James Bottomley]

On Thu, 2017-05-04 at 19:28 -0700, Linus Torvalds wrote:
> On Thu, May 4, 2017 at 5:18 PM, Greg KH 
> wrote:
> > 
> > Here is the big set of new char/misc driver drivers and features 
> > for 4.12-rc1.
> 
> Ugh. I'm not particularly happy with the conflicts I got and my
> resolutions there-of.

Yes, we really should have done this via a postmerge tree.  We've had
so little cause to use them recently, I suspect everyone's forgotten
how.

> I did resolve them - in the case of drivers/scsi/osd/osd_uld.c as per
> James' suggestion from his SCSI pull. Thanks.
> 
> But even that resolution I'm not entirely happy with: somebody should
> check that it cleans up oud properly

It looks fine to me, but I'll ask the osd people (well person, since
it's very little used).

> But the one I'm really unhappy with is my tpm-chip.c resolution.
> 
> In particular, commit 8dbbf5825181 ("tpm-chip: utilize new
> cdev_device_add helper function") made the tpm-chip code use that
> cdev_device_add/del pattern for chip->[c]dev. Fine.
> 
> But then commit fdc915f7f719 ("tpm: expose spaces via a device link
> /dev/tpmrm") added the *exact* same old pattern to a new
> "chip->[c]devs" (note the extra 's') and did so in a particularly
> ugly
> way too.
> 
> James, why did you do that nasty
> 
> if (chip->flags & TPM_CHIP_FLAG_TPM2)
> 
> *twice*, instead of just doing things properly inside *one* test?
> 
> Anyway, my merge resolution tries to just apply the same
> cdev_device_add/del pattern to the new chip->[c]devs entries, because
> not doing so seemed criminally ugly.
> 
> It compiles. It looks better than the mess it was. But it may not
> work.
> 
> James, Jarkko, you need to look at that tpm merge of mine. And James,
> double-check my osd_uld thing too.

I'm not going to defend the earlier coding, but you've lost the real
device_add() calls in the merge, meaning the tpm devices don't actually
get made visible at all.  I suspect assuming device_add() is done by
cdev_device_add() because of the name is going to be our next anti
-pattern, so you're at least ahead of the game ...

I think the below is the correct fix, but we should really take it
through the TPM list (or at least give me time for some runtime
testing) because I suddenly think the error leg unwinding isn't correct
in the original, so I've redone that too.

James

---

diff --git a/drivers/char/tpm/tpm-chip.c b/drivers/char/tpm/tpm-chip.c
index 322b8a51ffc6..867cef5ca9e5 100644
--- a/drivers/char/tpm/tpm-chip.c
+++ b/drivers/char/tpm/tpm-chip.c
@@ -272,24 +272,30 @@ EXPORT_SYMBOL_GPL(tpmm_chip_alloc);
 static int tpm_add_char_device(struct tpm_chip *chip)
 {
int rc;
+   const char *errstr;
+   struct device *errdev = >dev;
 
rc = cdev_device_add(>cdev, >dev);
if (rc) {
-   dev_err(>dev,
-   "unable to cdev_device_add() %s, major %d, minor %d, 
err=%d\n",
-   dev_name(>dev), MAJOR(chip->dev.devt),
-   MINOR(chip->dev.devt), rc);
-   return rc;
+   errstr = "cdev_device_add for main device";
+   goto error1;
+   }
+   rc = device_add(>dev);
+   if (rc) {
+   errstr = "device_add for main device";
+   goto error2;
}
-
if (chip->flags & TPM_CHIP_FLAG_TPM2) {
+   errdev = >devs;
rc = cdev_device_add(>cdevs, >devs);
if (rc) {
-   dev_err(>devs,
-   "unable to cdev_device_add() %s, major %d, 
minor %d, err=%d\n",
-   dev_name(>devs), MAJOR(chip->devs.devt),
-   MINOR(chip->devs.devt), rc);
-   return rc;
+   errstr = "cdev_device_add for rm device";
+   goto error3;
+   }
+   rc = device_add(>devs);
+   if (rc) {
+   errstr = "device_add for rm device";
+   goto error4;
}
}
 
@@ -299,6 +305,19 @@ static int tpm_add_char_device(struct tpm_chip *chip)
mutex_unlock(_lock);
 
return rc;
+
+ error4:
+   cdev_del(>cdevs);
+ error3:
+   device_del(>dev);
+ error2:
+   cdev_del(>cdev);
+ error1:
+   dev_err(>dev,
+   "Failed %s %s, major %d, minor %d, err=%d\n",
+   errstr, dev_name(errdev), MAJOR(errdev->devt),
+   MINOR(errdev->devt), rc);
+   return rc;
 }
 
 static void tpm_del_char_device(struct tpm_chip *chip)

Re: [GIT PULL] Char/Misc driver patches for 4.12-rc1

[Linus Torvalds]

On Thu, May 4, 2017 at 5:18 PM, Greg KH  wrote:
>
> Here is the big set of new char/misc driver drivers and features for
> 4.12-rc1.

Ugh. I'm not particularly happy with the conflicts I got and my
resolutions there-of.

I did resolve them - in the case of drivers/scsi/osd/osd_uld.c as per
James' suggestion from his SCSI pull. Thanks.

But even that resolution I'm not entirely happy with: somebody should
check that it cleans up oud properly

But the one I'm really unhappy with is my tpm-chip.c resolution.

In particular, commit 8dbbf5825181 ("tpm-chip: utilize new
cdev_device_add helper function") made the tpm-chip code use that
cdev_device_add/del pattern for chip->[c]dev. Fine.

But then commit fdc915f7f719 ("tpm: expose spaces via a device link
/dev/tpmrm") added the *exact* same old pattern to a new
"chip->[c]devs" (note the extra 's') and did so in a particularly ugly
way too.

James, why did you do that nasty

if (chip->flags & TPM_CHIP_FLAG_TPM2)

*twice*, instead of just doing things properly inside *one* test?

Anyway, my merge resolution tries to just apply the same
cdev_device_add/del pattern to the new chip->[c]devs entries, because
not doing so seemed criminally ugly.

It compiles. It looks better than the mess it was. But it may not work.

James, Jarkko, you need to look at that tpm merge of mine. And James,
double-check my osd_uld thing too.

 Linus

Re: [GIT PULL] Char/Misc driver patches for 4.12-rc1

[Linus Torvalds]

On Thu, May 4, 2017 at 5:18 PM, Greg KH  wrote:
>
> Here is the big set of new char/misc driver drivers and features for
> 4.12-rc1.

Ugh. I'm not particularly happy with the conflicts I got and my
resolutions there-of.

I did resolve them - in the case of drivers/scsi/osd/osd_uld.c as per
James' suggestion from his SCSI pull. Thanks.

But even that resolution I'm not entirely happy with: somebody should
check that it cleans up oud properly

But the one I'm really unhappy with is my tpm-chip.c resolution.

In particular, commit 8dbbf5825181 ("tpm-chip: utilize new
cdev_device_add helper function") made the tpm-chip code use that
cdev_device_add/del pattern for chip->[c]dev. Fine.

But then commit fdc915f7f719 ("tpm: expose spaces via a device link
/dev/tpmrm") added the *exact* same old pattern to a new
"chip->[c]devs" (note the extra 's') and did so in a particularly ugly
way too.

James, why did you do that nasty

if (chip->flags & TPM_CHIP_FLAG_TPM2)

*twice*, instead of just doing things properly inside *one* test?

Anyway, my merge resolution tries to just apply the same
cdev_device_add/del pattern to the new chip->[c]devs entries, because
not doing so seemed criminally ugly.

It compiles. It looks better than the mess it was. But it may not work.

James, Jarkko, you need to look at that tpm merge of mine. And James,
double-check my osd_uld thing too.

 Linus

[GIT PULL] Char/Misc driver patches for 4.12-rc1

[Greg KH]

The following changes since commit c02ed2e75ef4c74e41e421acb4ef1494671585e8:

  Linux 4.11-rc4 (2017-03-26 14:15:16 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc.git/ 
tags/char-misc-4.12-rc1

for you to fetch changes up to 2a76f89fa58c769241cfc21f2614705591519ae3:

  firmware: google memconsole: Fix return value check in 
platform_memconsole_init() (2017-04-26 22:54:54 +0200)


char/misc patches for 4.12-rc1

Here is the big set of new char/misc driver drivers and features for
4.12-rc1.

There's lots of new drivers added this time around, new firmware drivers
from Google, more auxdisplay drivers, extcon drivers, fpga drivers, and
a bunch of other driver updates.  Nothing major, except if you happen to
have the hardware for these drivers, and then you will be happy :)

All of these have been in linux-next for a while with no reported
issues.

Signed-off-by: Greg Kroah-Hartman 


Aban Bedel (1):
  nvmem: core: Allow allocating several anonymous nvmem devices

Alan Tull (2):
  fpga: add config complete timeout
  MAINTAINERS: fpga: update email and directory paths

Alexander Usyskin (2):
  mei: drop amthif internal client
  mei: implement fsync

Anatolij Gustschin (2):
  dt: bindings: fpga: add xilinx slave-serial binding description
  fpga manager: Add Xilinx slave serial SPI driver

Andrew F. Davis (2):
  w1: Use kernel common min() implementation
  w1: Remove unneeded use of assert() and remove w1_log.h

Andy Shevchenko (3):
  Revert "extcon: usb-gpio: add support for ACPI gpio interface"
  auxdisplay: Move panel.c to drivers/auxdisplay folder
  auxdisplay: Move arm-charlcd.c to drivers/auxdisplay folder

Arnd Bergmann (4):
  drivers/misc: aspeed-lpc-ctrl: fix printk format warning again
  aspeed-lpc-ctrl: include linux/types.h for uapi header
  auxdisplay: ht16k33: don't access uninitialized data
  lkdtm: turn off kcov for lkdtm_rodata_do_nothing:

Chanwoo Choi (4):
  extcon: Add new extcon_register_notifier_all() to monitor all external 
connectors
  Merge branch 'ib-extcon-4.12' into HEAD
  extcon: Remove porting compatibility of swich class
  extcon: Use BIT() macro for the left-shift operation

Charles Keepax (1):
  extcon: arizona: Wait for any running HPDETs to complete on jack removal

Cyril Bur (2):
  drivers/misc: Add Aspeed LPC control driver
  drivers/misc: Aspeed LPC control fix compile error and warning

Dan Williams (1):
  device-dax: fix cdev leak

Dinh Nguyen (1):
  fpga: fix sparse warnings in fpga-mgr and fpga-bridge

Dmitry Torokhov (3):
  rapidio: use is_visible() to hide switch-specific attributes
  zorro: stop creating attributes by hand
  auxdisplay: ht16k33: use le16_to_cpup() to fetch LE16 data

Elena Reshetova (2):
  drivers, char: convert vma_data.refcnt from atomic_t to refcount_t
  drivers, firewire: convert fw_node.ref_count from atomic_t to refcount_t

Florian Fainelli (2):
  FPGA: Add TS-7300 FPGA manager
  ARM: ep93xx: Register ts73xx-fpga manager driver for TS-7300

Geert Uytterhoeven (7):
  auxdisplay: charlcd: Extract character LCD core from misc/panel
  auxdisplay: charlcd: Add support for 4-bit interfaces
  auxdisplay: charlcd: Add support for displays with more than two lines
  dt-bindings: auxdisplay: Add bindings for Hitachi HD44780
  auxdisplay: Add HD44780 Character LCD support
  MAINTAINERS: Add file patterns for fpga device tree bindings
  auxdisplay: hd44780: Fix DT properties to include units of measurement

Greg Kroah-Hartman (3):
  Merge 4.11-rc4 into char-misc-next
  Merge tag 'extcon-next-for-4.12' of 
git://git.kernel.org/.../chanwoo/extcon into char-misc-next
  goldfish_pipe: fix build warning about using too much stack.

Hans de Goede (3):
  extcon: intel-cht-wc: Add Intel Cherry Trail Whiskey Cove PMIC extcon 
driver
  extcon: intel-cht-wc: Disable external 5v boost converter on probe
  extcon: intel-cht-wc: Ignore failure to detect charger-type on host mode 
exit

Icenowy Zheng (2):
  nvmem: sunxi-sid: read NVMEM size from device compatible
  nvmem: sunxi-sid: add support for H3's SID controller

Jason Gunthorpe (1):
  IB/ucm: utilize new cdev_device_add helper function

Javier Martinez Canillas (4):
  auxdisplay: img-ascii-lcd: Fix module autoload
  misc: tsl2550: Add OF device ID table
  misc: ds1682: Add OF device ID table
  eeprom: idt_89hpesx: Add OF device ID table

Jin Qian (1):
  goldfish_pipe: An implementation of more parallel pipe

Joe Perches (1):
  drivers/char: Convert remaining use of pr_warning to pr_warn

Joel Holdsworth (2):
  Documentation: Add binding document for Lattice iCE40 FPGA manager

[GIT PULL] Char/Misc driver patches for 4.12-rc1

[Greg KH]

The following changes since commit c02ed2e75ef4c74e41e421acb4ef1494671585e8:

  Linux 4.11-rc4 (2017-03-26 14:15:16 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc.git/ 
tags/char-misc-4.12-rc1

for you to fetch changes up to 2a76f89fa58c769241cfc21f2614705591519ae3:

  firmware: google memconsole: Fix return value check in 
platform_memconsole_init() (2017-04-26 22:54:54 +0200)


char/misc patches for 4.12-rc1

Here is the big set of new char/misc driver drivers and features for
4.12-rc1.

There's lots of new drivers added this time around, new firmware drivers
from Google, more auxdisplay drivers, extcon drivers, fpga drivers, and
a bunch of other driver updates.  Nothing major, except if you happen to
have the hardware for these drivers, and then you will be happy :)

All of these have been in linux-next for a while with no reported
issues.

Signed-off-by: Greg Kroah-Hartman 


Aban Bedel (1):
  nvmem: core: Allow allocating several anonymous nvmem devices

Alan Tull (2):
  fpga: add config complete timeout
  MAINTAINERS: fpga: update email and directory paths

Alexander Usyskin (2):
  mei: drop amthif internal client
  mei: implement fsync

Anatolij Gustschin (2):
  dt: bindings: fpga: add xilinx slave-serial binding description
  fpga manager: Add Xilinx slave serial SPI driver

Andrew F. Davis (2):
  w1: Use kernel common min() implementation
  w1: Remove unneeded use of assert() and remove w1_log.h

Andy Shevchenko (3):
  Revert "extcon: usb-gpio: add support for ACPI gpio interface"
  auxdisplay: Move panel.c to drivers/auxdisplay folder
  auxdisplay: Move arm-charlcd.c to drivers/auxdisplay folder

Arnd Bergmann (4):
  drivers/misc: aspeed-lpc-ctrl: fix printk format warning again
  aspeed-lpc-ctrl: include linux/types.h for uapi header
  auxdisplay: ht16k33: don't access uninitialized data
  lkdtm: turn off kcov for lkdtm_rodata_do_nothing:

Chanwoo Choi (4):
  extcon: Add new extcon_register_notifier_all() to monitor all external 
connectors
  Merge branch 'ib-extcon-4.12' into HEAD
  extcon: Remove porting compatibility of swich class
  extcon: Use BIT() macro for the left-shift operation

Charles Keepax (1):
  extcon: arizona: Wait for any running HPDETs to complete on jack removal

Cyril Bur (2):
  drivers/misc: Add Aspeed LPC control driver
  drivers/misc: Aspeed LPC control fix compile error and warning

Dan Williams (1):
  device-dax: fix cdev leak

Dinh Nguyen (1):
  fpga: fix sparse warnings in fpga-mgr and fpga-bridge

Dmitry Torokhov (3):
  rapidio: use is_visible() to hide switch-specific attributes
  zorro: stop creating attributes by hand
  auxdisplay: ht16k33: use le16_to_cpup() to fetch LE16 data

Elena Reshetova (2):
  drivers, char: convert vma_data.refcnt from atomic_t to refcount_t
  drivers, firewire: convert fw_node.ref_count from atomic_t to refcount_t

Florian Fainelli (2):
  FPGA: Add TS-7300 FPGA manager
  ARM: ep93xx: Register ts73xx-fpga manager driver for TS-7300

Geert Uytterhoeven (7):
  auxdisplay: charlcd: Extract character LCD core from misc/panel
  auxdisplay: charlcd: Add support for 4-bit interfaces
  auxdisplay: charlcd: Add support for displays with more than two lines
  dt-bindings: auxdisplay: Add bindings for Hitachi HD44780
  auxdisplay: Add HD44780 Character LCD support
  MAINTAINERS: Add file patterns for fpga device tree bindings
  auxdisplay: hd44780: Fix DT properties to include units of measurement

Greg Kroah-Hartman (3):
  Merge 4.11-rc4 into char-misc-next
  Merge tag 'extcon-next-for-4.12' of 
git://git.kernel.org/.../chanwoo/extcon into char-misc-next
  goldfish_pipe: fix build warning about using too much stack.

Hans de Goede (3):
  extcon: intel-cht-wc: Add Intel Cherry Trail Whiskey Cove PMIC extcon 
driver
  extcon: intel-cht-wc: Disable external 5v boost converter on probe
  extcon: intel-cht-wc: Ignore failure to detect charger-type on host mode 
exit

Icenowy Zheng (2):
  nvmem: sunxi-sid: read NVMEM size from device compatible
  nvmem: sunxi-sid: add support for H3's SID controller

Jason Gunthorpe (1):
  IB/ucm: utilize new cdev_device_add helper function

Javier Martinez Canillas (4):
  auxdisplay: img-ascii-lcd: Fix module autoload
  misc: tsl2550: Add OF device ID table
  misc: ds1682: Add OF device ID table
  eeprom: idt_89hpesx: Add OF device ID table

Jin Qian (1):
  goldfish_pipe: An implementation of more parallel pipe

Joe Perches (1):
  drivers/char: Convert remaining use of pr_warning to pr_warn

Joel Holdsworth (2):
  Documentation: Add binding document for Lattice iCE40 FPGA manager
  fpga: Add support for