linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Linus Torvalds <torvalds@linux-foundation.org>
To: Greg KH <gregkh@linuxfoundation.org>,
	James Bottomley <James.Bottomley@hansenpartnership.com>,
	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: Thu, 4 May 2017 19:28:05 -0700	[thread overview]
Message-ID: <CA+55aFx-ZxaveO=_YMaPb+bO8tia8eKZik16zVt83Ewkrj41og@mail.gmail.com> (raw)
In-Reply-To: <20170505001808.GA16769@kroah.com>

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.

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

                 Linus

  reply	other threads:[~2017-05-05  2:28 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 [this message]
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
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='CA+55aFx-ZxaveO=_YMaPb+bO8tia8eKZik16zVt83Ewkrj41og@mail.gmail.com' \
    --to=torvalds@linux-foundation.org \
    --cc=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 \
    /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;
as well as URLs for NNTP newsgroup(s).