stable.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Greg KH <gregkh@linuxfoundation.org>
To: Chris Metcalf <cmetcalf@mellanox.com>
Cc: dwoods@mellanox.com, jh80.chung@samsung.com,
	ulf.hansson@linaro.org, stable@vger.kernel.org
Subject: Re: WTF: patch "[PATCH] mmc: dw_mmc: Use device_property_read instead of" was seriously submitted to be applied to the 4.12-stable tree?
Date: Tue, 25 Jul 2017 07:48:37 -0700	[thread overview]
Message-ID: <20170725144837.GC1618@kroah.com> (raw)
In-Reply-To: <1f17f58c-9b54-58b1-9717-4a50a29799c0@mellanox.com>

On Mon, Jul 24, 2017 at 09:22:44PM -0400, Chris Metcalf wrote:
> On 7/24/2017 7:32 PM, gregkh@linuxfoundation.org wrote:
> > The patch below was submitted to be applied to the 4.12-stable tree.
> > 
> > I fail to see how this patch meets the stable kernel rules as found at
> > Documentation/process/stable_kernel_rules.rst.
> > 
> > [...]
> > 
> > Using the device_property interfaces allows the dw_mmc driver to work
> > on platforms which run on either device tree or ACPI.
> > 
> > Signed-off-by: David Woods <dwoods@mellanox.com>
> > Reviewed-by: Chris Metcalf <cmetcalf@mellanox.com>
> > Cc: stable@vger.linux.org
> > Acked-by: Jaehoon Chung <jh80.chung@samsung.com>
> > Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
> 
> I encouraged Dave to cc stable, so this is on me if it was a bad call.
> 
> This bug is the only thing blocking our ARM64 hardware (Mellanox
> BlueField, google if curious) from booting up with RedHat 7 on our
> standard hardware config with an eMMC rootfs.  RedHat 7 requires
> ACPI for server configuration builds, and the eMMC drivers didn't
> support ACPI, just device tree, so the chip couldn't boot.
> 
> The two changes are obviously correct (mechanical substitution
> of "of_*" to "device_*"), short, and fix a clear bug in booting up RHEL.
> Now obviously we are working with RedHat directly to get them to
> include the fix (RH bugzilla 1466917) but it seemed plausible to
> push the fix upstream so it would get picked up elsewhere as well and
> enable booting older mainstream ARM64 kernels on our hardware.

So is this the _only_ change that is needed to get a 4.9 and/or a 4.12
kernel running on your hardware?  Or would they need other ones as well?

thanks,

greg k-h

  reply	other threads:[~2017-07-25 14:48 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-07-24 23:32 WTF: patch "[PATCH] mmc: dw_mmc: Use device_property_read instead of" was seriously submitted to be applied to the 4.12-stable tree? gregkh
2017-07-25  1:22 ` Chris Metcalf
2017-07-25 14:48   ` Greg KH [this message]
2017-07-25 15:55     ` Chris Metcalf
2017-07-28 13:52       ` Chris Metcalf
2017-07-28 23:30         ` Greg KH
2017-07-29  2:02           ` Chris Metcalf
2017-08-07 19:51             ` Greg KH
2017-08-07 21:01               ` Greg KH
2017-08-08 14:29                 ` Chris Metcalf
2017-08-08 14:51                   ` Greg KH

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=20170725144837.GC1618@kroah.com \
    --to=gregkh@linuxfoundation.org \
    --cc=cmetcalf@mellanox.com \
    --cc=dwoods@mellanox.com \
    --cc=jh80.chung@samsung.com \
    --cc=stable@vger.kernel.org \
    --cc=ulf.hansson@linaro.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).