[GIT PULL] Pull request for 4.13 for IPMI

[GIT PULL] Pull request for 4.13 for IPMI

[Corey Minyard]

The following changes since commit 13e0988140374123bead1dd27c287354cb95108e:

   docs: complete bumping minimal GNU Make version to 3.81 (2017-05-06 
18:49:09 -0700)

are available in the git repository at:

   https://github.com/cminyard/linux-ipmi.git tags/for-linus-4.13

for you to fetch changes up to 4495ec6d770e1bca7a04e93ac453ab6720c56c5d:

   ipmi:ssif: Add missing unlock in error branch (2017-06-30 07:18:08 -0500)

----------------------------------------------------------------
Some small fixes for IPMI, and one medium sized changed.

The medium sized change is adding a platform device for IPMI entries
in the DMI table.  Otherwise there is no auto loading for IPMI
devices if they are only in the DMI table.

----------------------------------------------------------------
Arvind Yadav (1):
       char: ipmi: constify bmc_dev_attr_group and bmc_device_type

Colin Ian King (1):
       ipmi_ssif: remove redundant null check on array client->adapter->name

Corey Minyard (6):
       ipmi: Use the proper default value for register size in ACPI
       ipmi:ssif: Use i2c_adapter_id instead of adapter->nr
       ipmi: Create a platform device for a DMI-specified IPMI interface
       ipmi: Convert DMI handling over to a platform device
       ipmi:ssif: Check dev before setting drvdata
       ipmi:ssif: Add missing unlock in error branch

Dan Carpenter (1):
       ipmi_ssif: unlock on allocation failure

Tony Camuso (1):
       ipmi: use rcu lock around call to intf->handlers->sender()

Valentin Vidic (1):
       ipmi/watchdog: fix watchdog timeout set on reboot

  drivers/char/ipmi/Kconfig           |   4 +
  drivers/char/ipmi/Makefile          |   1 +
  drivers/char/ipmi/ipmi_dmi.c        | 273 
++++++++++++++++++++++++++++++++++++
  drivers/char/ipmi/ipmi_dmi.h        |  12 ++
  drivers/char/ipmi/ipmi_msghandler.c |   9 +-
  drivers/char/ipmi/ipmi_si_intf.c    | 265 
++++++++++++++++------------------
  drivers/char/ipmi/ipmi_ssif.c       | 176 ++++++++++++++---------
  drivers/char/ipmi/ipmi_watchdog.c   |   7 +-
  8 files changed, 533 insertions(+), 214 deletions(-)
  create mode 100644 drivers/char/ipmi/ipmi_dmi.c
  create mode 100644 drivers/char/ipmi/ipmi_dmi.h

Re: [GIT PULL] Pull request for 4.13 for IPMI

[Linus Torvalds]

On Mon, Jul 10, 2017 at 5:47 AM, Corey Minyard <minyard@acm.org> wrote:
>
>   https://github.com/cminyard/linux-ipmi.git tags/for-linus-4.13

Hmm.

This is signed using a completely new key.

That part is fine: the new key is 4k bits instead of the old 1k key.

But the new key is signed by absolutely nothing - not even the old key.

That makes the new key entirely pointless, and I'm not going to pull
from a github account with absolutely nothing to show that it's the
saem Corey Minyard.

Can you please at least self-sign with your old key?

Because even if you *yourself* don't trust the new key, why should I do so?

              Linus

Re: [GIT PULL] Pull request for 4.13 for IPMI

[Corey Minyard]

On 07/10/2017 12:12 PM, Linus Torvalds wrote:
> On Mon, Jul 10, 2017 at 5:47 AM, Corey Minyard <minyard@acm.org> wrote:
>>    https://github.com/cminyard/linux-ipmi.git tags/for-linus-4.13
> Hmm.
>
> This is signed using a completely new key.
>
> That part is fine: the new key is 4k bits instead of the old 1k key.
>
> But the new key is signed by absolutely nothing - not even the old key.
>
> That makes the new key entirely pointless, and I'm not going to pull
> from a github account with absolutely nothing to show that it's the
> saem Corey Minyard.
>
> Can you please at least self-sign with your old key?
>
> Because even if you *yourself* don't trust the new key, why should I do so?
>
>                Linus

Dang it.  I generated a new key to replace the old key, waiting to have 
it signed an such, and it defaulted to the new key.  I'll do a v2 with 
the right key.  Sorry.

-corey

Re: [GIT PULL] Pull request for 4.13 for IPMI

[Linus Torvalds]

On Mon, Jul 10, 2017 at 10:45 AM, Corey Minyard <minyard@acm.org> wrote:
>
> Dang it.  I generated a new key to replace the old key, waiting to have it
> signed an such, and it defaulted to the new key.  I'll do a v2 with the
> right key.  Sorry.

I would have been perfectly happy with the new key if you just signed
it with the old one, which is kind of the usual thing anyway.

In fact, I do accept unsigned keys when new people start using them,
in that they can get signatures later and in the meantime the key at
least shows that multiple pull requests were generated with the same
key.

It's just that combination of "new key, not signed by an old key I
know should have been available" that makes me go "Hmm.."

(Of course, I do also prefer to get a heads-up about key changes that
don't just involve a refresh of the expiration date, but nobody ever
remembers to let people know, so I just say "oh, new key" and then
look to make sure that it looks sane).

                 Linus