From: Greg KH <gregkh@linuxfoundation.org>
To: James Bottomley <James.Bottomley@HansenPartnership.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>,
Andrew Morton <akpm@linux-foundation.org>,
Arnd Bergmann <arnd@arndb.de>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [GIT PULL] Char/Misc driver patches for 4.12-rc1
Date: Fri, 5 May 2017 09:38:46 -0700 [thread overview]
Message-ID: <20170505163846.GA31211@kroah.com> (raw)
In-Reply-To: <1494000006.2399.7.camel@HansenPartnership.com>
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 <gregkh@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.
> > 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 = &chip->dev;
>
> rc = cdev_device_add(&chip->cdev, &chip->dev);
> if (rc) {
> - dev_err(&chip->dev,
> - "unable to cdev_device_add() %s, major %d, minor %d, err=%d\n",
> - dev_name(&chip->dev), MAJOR(chip->dev.devt),
> - MINOR(chip->dev.devt), rc);
> - return rc;
> + errstr = "cdev_device_add for main device";
> + goto error1;
> + }
> + rc = device_add(&chip->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
next prev parent reply other threads:[~2017-05-05 16:38 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-05-05 0:18 [GIT PULL] Char/Misc driver patches for 4.12-rc1 Greg KH
2017-05-05 2:28 ` Linus Torvalds
2017-05-05 16:00 ` James Bottomley
2017-05-05 16:33 ` Linus Torvalds
2017-05-05 16:49 ` James Bottomley
2017-05-05 16:38 ` Greg KH [this message]
2017-05-05 19:46 ` James Bottomley
2017-05-05 20:01 ` Linus Torvalds
2017-05-06 5:09 ` Stephen Rothwell
2017-05-06 18:00 ` Linus Torvalds
2017-05-06 18:12 ` James Bottomley
2017-07-12 4:50 ` Stephen Rothwell
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20170505163846.GA31211@kroah.com \
--to=gregkh@linuxfoundation.org \
--cc=James.Bottomley@HansenPartnership.com \
--cc=akpm@linux-foundation.org \
--cc=arnd@arndb.de \
--cc=jarkko.sakkinen@linux.intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=torvalds@linux-foundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox