All of lore.kernel.org
 help / color / mirror / Atom feed
From: James Bottomley <James.Bottomley@HansenPartnership.com>
To: Linus Torvalds <torvalds@linux-foundation.org>,
	Greg KH <gregkh@linuxfoundation.org>,
	Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
Cc: 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, 05 May 2017 09:00:06 -0700	[thread overview]
Message-ID: <1494000006.2399.7.camel@HansenPartnership.com> (raw)
In-Reply-To: <CA+55aFx-ZxaveO=_YMaPb+bO8tia8eKZik16zVt83Ewkrj41og@mail.gmail.com>

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.

> 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<n>") 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 = &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);
+	if (rc) {
+		errstr = "device_add for main device";
+		goto error2;
 	}
-
 	if (chip->flags & TPM_CHIP_FLAG_TPM2) {
+		errdev = &chip->devs;
 		rc = cdev_device_add(&chip->cdevs, &chip->devs);
 		if (rc) {
-			dev_err(&chip->devs,
-				"unable to cdev_device_add() %s, major %d, minor %d, err=%d\n",
-				dev_name(&chip->devs), MAJOR(chip->devs.devt),
-				MINOR(chip->devs.devt), rc);
-			return rc;
+			errstr = "cdev_device_add for rm device";
+			goto error3;
+		}
+		rc = device_add(&chip->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(&idr_lock);
 
 	return rc;
+
+ error4:
+	cdev_del(&chip->cdevs);
+ error3:
+	device_del(&chip->dev);
+ error2:
+	cdev_del(&chip->cdev);
+ error1:
+	dev_err(&chip->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)

  reply	other threads:[~2017-05-05 16:00 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 [this message]
2017-05-05 16:33     ` Linus Torvalds
2017-05-05 16:49       ` James Bottomley
2017-05-05 16:38     ` Greg KH
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=1494000006.2399.7.camel@HansenPartnership.com \
    --to=james.bottomley@hansenpartnership.com \
    --cc=akpm@linux-foundation.org \
    --cc=arnd@arndb.de \
    --cc=gregkh@linuxfoundation.org \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.