stable.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: <gregkh@linuxfoundation.org>
To: dwoods@mellanox.com, cmetcalf@mellanox.com,
	jh80.chung@samsung.com, ulf.hansson@linaro.org
Cc: <stable@vger.kernel.org>
Subject: 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: Mon, 24 Jul 2017 16:32:17 -0700	[thread overview]
Message-ID: <150093913718756@kroah.com> (raw)

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.

I could be totally wrong, and if so, please respond to 
<stable@vger.kernel.org> and let me know why this patch should be
applied.  Otherwise, it is now dropped from my patch queues, never to be
seen again.

thanks,

greg k-h

------------------ original commit in Linus's tree ------------------

>From 852ff5fea9eb6a9799f1881d6df2cd69a9e6eed5 Mon Sep 17 00:00:00 2001
From: David Woods <dwoods@mellanox.com>
Date: Fri, 26 May 2017 17:53:20 -0400
Subject: [PATCH] mmc: dw_mmc: Use device_property_read instead of
 of_property_read

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>

diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
index 0e2d6f7de469..4a0841cee39b 100644
--- a/drivers/mmc/host/dw_mmc.c
+++ b/drivers/mmc/host/dw_mmc.c
@@ -2723,8 +2723,8 @@ static int dw_mci_init_slot(struct dw_mci *host, unsigned int id)
 	host->slot[id] = slot;
 
 	mmc->ops = &dw_mci_ops;
-	if (of_property_read_u32_array(host->dev->of_node,
-				       "clock-freq-min-max", freq, 2)) {
+	if (device_property_read_u32_array(host->dev, "clock-freq-min-max",
+					   freq, 2)) {
 		mmc->f_min = DW_MCI_FREQ_MIN;
 		mmc->f_max = DW_MCI_FREQ_MAX;
 	} else {
@@ -2828,7 +2828,6 @@ static void dw_mci_init_dma(struct dw_mci *host)
 {
 	int addr_config;
 	struct device *dev = host->dev;
-	struct device_node *np = dev->of_node;
 
 	/*
 	* Check tansfer mode from HCON[17:16]
@@ -2889,8 +2888,9 @@ static void dw_mci_init_dma(struct dw_mci *host)
 		dev_info(host->dev, "Using internal DMA controller.\n");
 	} else {
 		/* TRANS_MODE_EDMAC: check dma bindings again */
-		if ((of_property_count_strings(np, "dma-names") < 0) ||
-		    (!of_find_property(np, "dmas", NULL))) {
+		if ((device_property_read_string_array(dev, "dma-names",
+						       NULL, 0) < 0) ||
+		    !device_property_present(dev, "dmas")) {
 			goto no_dma;
 		}
 		host->dma_ops = &dw_mci_edmac_ops;
@@ -2957,7 +2957,6 @@ static struct dw_mci_board *dw_mci_parse_dt(struct dw_mci *host)
 {
 	struct dw_mci_board *pdata;
 	struct device *dev = host->dev;
-	struct device_node *np = dev->of_node;
 	const struct dw_mci_drv_data *drv_data = host->drv_data;
 	int ret;
 	u32 clock_frequency;
@@ -2974,20 +2973,21 @@ static struct dw_mci_board *dw_mci_parse_dt(struct dw_mci *host)
 	}
 
 	/* find out number of slots supported */
-	of_property_read_u32(np, "num-slots", &pdata->num_slots);
+	device_property_read_u32(dev, "num-slots", &pdata->num_slots);
 
-	if (of_property_read_u32(np, "fifo-depth", &pdata->fifo_depth))
+	if (device_property_read_u32(dev, "fifo-depth", &pdata->fifo_depth))
 		dev_info(dev,
 			 "fifo-depth property not found, using value of FIFOTH register as default\n");
 
-	of_property_read_u32(np, "card-detect-delay", &pdata->detect_delay_ms);
+	device_property_read_u32(dev, "card-detect-delay",
+				 &pdata->detect_delay_ms);
 
-	of_property_read_u32(np, "data-addr", &host->data_addr_override);
+	device_property_read_u32(dev, "data-addr", &host->data_addr_override);
 
-	if (of_get_property(np, "fifo-watermark-aligned", NULL))
+	if (device_property_present(dev, "fifo-watermark-aligned"))
 		host->wm_aligned = true;
 
-	if (!of_property_read_u32(np, "clock-frequency", &clock_frequency))
+	if (!device_property_read_u32(dev, "clock-frequency", &clock_frequency))
 		pdata->bus_hz = clock_frequency;
 
 	if (drv_data && drv_data->parse_dt) {

             reply	other threads:[~2017-07-24 23:32 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-07-24 23:32 gregkh [this message]
2017-07-25  1:22 ` WTF: patch "[PATCH] mmc: dw_mmc: Use device_property_read instead of" was seriously submitted to be applied to the 4.12-stable tree? Chris Metcalf
2017-07-25 14:48   ` Greg KH
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=150093913718756@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).