All of lore.kernel.org
 help / color / mirror / Atom feed
* WTF: patch "[PATCH] mmc: dw_mmc: Use device_property_read instead of" was seriously submitted to be applied to the 4.12-stable tree?
@ 2017-07-24 23:32 gregkh
  2017-07-25  1:22 ` Chris Metcalf
  0 siblings, 1 reply; 11+ messages in thread
From: gregkh @ 2017-07-24 23:32 UTC (permalink / raw)
  To: dwoods, cmetcalf, jh80.chung, ulf.hansson; +Cc: stable

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) {

^ permalink raw reply related	[flat|nested] 11+ messages in thread

* 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?
  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
  0 siblings, 1 reply; 11+ messages in thread
From: Chris Metcalf @ 2017-07-25  1:22 UTC (permalink / raw)
  To: gregkh, dwoods, jh80.chung, ulf.hansson; +Cc: stable

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.

Thanks!

-- 
Chris Metcalf, Mellanox Technologies
http://www.mellanox.com

^ permalink raw reply	[flat|nested] 11+ messages in thread

* 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?
  2017-07-25  1:22 ` Chris Metcalf
@ 2017-07-25 14:48   ` Greg KH
  2017-07-25 15:55     ` Chris Metcalf
  0 siblings, 1 reply; 11+ messages in thread
From: Greg KH @ 2017-07-25 14:48 UTC (permalink / raw)
  To: Chris Metcalf; +Cc: dwoods, jh80.chung, ulf.hansson, stable

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

^ permalink raw reply	[flat|nested] 11+ messages in thread

* 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?
  2017-07-25 14:48   ` Greg KH
@ 2017-07-25 15:55     ` Chris Metcalf
  2017-07-28 13:52       ` Chris Metcalf
  0 siblings, 1 reply; 11+ messages in thread
From: Chris Metcalf @ 2017-07-25 15:55 UTC (permalink / raw)
  To: Greg KH; +Cc: dwoods, jh80.chung, ulf.hansson, stable

On 7/25/2017 10:48 AM, Greg KH wrote:
> 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?

As far as we know, these are the only patches needed to get RHEL booted.
There are additional drivers for new IP on our SoC, but those are
orthogonal to actually booting up the system.

For the 4.9 backport you may want to also just take e44bb0cbdc88
("device property: Make dev_fwnode() public") or else just open-code
the place in the patch where dev_fwnode() is used.

-- 
Chris Metcalf, Mellanox Technologies
http://www.mellanox.com

^ permalink raw reply	[flat|nested] 11+ messages in thread

* 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?
  2017-07-25 15:55     ` Chris Metcalf
@ 2017-07-28 13:52       ` Chris Metcalf
  2017-07-28 23:30         ` Greg KH
  0 siblings, 1 reply; 11+ messages in thread
From: Chris Metcalf @ 2017-07-28 13:52 UTC (permalink / raw)
  To: Greg KH; +Cc: dwoods, jh80.chung, ulf.hansson, stable

Ping?  Greg, I see that you released 4.12.4/4.9.40 without these 
patches, but
not having heard back from you, I wondered if my reply below was lost and we
were both waiting on each other.  Thanks!

On 7/25/2017 11:55 AM, Chris Metcalf wrote:
> On 7/25/2017 10:48 AM, Greg KH wrote:
>> 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?
>
> As far as we know, these are the only patches needed to get RHEL booted.
> There are additional drivers for new IP on our SoC, but those are
> orthogonal to actually booting up the system.
>
> For the 4.9 backport you may want to also just take e44bb0cbdc88
> ("device property: Make dev_fwnode() public") or else just open-code
> the place in the patch where dev_fwnode() is used.
>

-- 
Chris Metcalf, Mellanox Technologies
http://www.mellanox.com

^ permalink raw reply	[flat|nested] 11+ messages in thread

* 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?
  2017-07-28 13:52       ` Chris Metcalf
@ 2017-07-28 23:30         ` Greg KH
  2017-07-29  2:02           ` Chris Metcalf
  0 siblings, 1 reply; 11+ messages in thread
From: Greg KH @ 2017-07-28 23:30 UTC (permalink / raw)
  To: Chris Metcalf; +Cc: dwoods, jh80.chung, ulf.hansson, stable


A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

A: No.
Q: Should I include quotations after my reply?


http://daringfireball.net/2007/07/on_top

On Fri, Jul 28, 2017 at 09:52:57AM -0400, Chris Metcalf wrote:
> Ping?  Greg, I see that you released 4.12.4/4.9.40 without these patches,
> but
> not having heard back from you, I wondered if my reply below was lost and we
> were both waiting on each other.  Thanks!

No, it just went to the bottom of more important patches (i.e.
bugfixes.)  I'll reconsider this at a later point in time when I get a
chance...

thanks,

greg k-h

^ permalink raw reply	[flat|nested] 11+ messages in thread

* 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?
  2017-07-28 23:30         ` Greg KH
@ 2017-07-29  2:02           ` Chris Metcalf
  2017-08-07 19:51             ` Greg KH
  0 siblings, 1 reply; 11+ messages in thread
From: Chris Metcalf @ 2017-07-29  2:02 UTC (permalink / raw)
  To: Greg KH; +Cc: dwoods, jh80.chung, ulf.hansson, stable

On 7/28/2017 7:30 PM, Greg KH wrote:
> https://daringfireball.net/2007/07/on_top

Good for you for trying to educate - hopefully it will stick, occasionally.

In 30+ years of emailing, I can honestly say that "Ping" emails are
the only ones where I appreciate top-posting.  The whole point of such
an email is a "TL;DR" sanity check, but at the same time, quoting the
entire email is actually important when you think the previous email
might have been lost in transit or misplaced.  I get irritated when
someone quotes the whole damn email and I get to the bottom just to
find a  "ping".

>> Ping?  Greg, I see that you released 4.12.4/4.9.40 without these patches, but
>> not having heard back from you, I wondered if my reply below was lost and we
>> were both waiting on each other.  Thanks!
> No, it just went to the bottom of more important patches (i.e.
> bugfixes.)  I'll reconsider this at a later point in time when I get a
> chance...

Great, thanks!

-- 
Chris Metcalf, Mellanox Technologies
http://www.mellanox.com

^ permalink raw reply	[flat|nested] 11+ messages in thread

* 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?
  2017-07-29  2:02           ` Chris Metcalf
@ 2017-08-07 19:51             ` Greg KH
  2017-08-07 21:01               ` Greg KH
  0 siblings, 1 reply; 11+ messages in thread
From: Greg KH @ 2017-08-07 19:51 UTC (permalink / raw)
  To: Chris Metcalf; +Cc: dwoods, jh80.chung, ulf.hansson, stable

On Fri, Jul 28, 2017 at 10:02:58PM -0400, Chris Metcalf wrote:
> On 7/28/2017 7:30 PM, Greg KH wrote:
> > > Ping?  Greg, I see that you released 4.12.4/4.9.40 without these patches, but
> > > not having heard back from you, I wondered if my reply below was lost and we
> > > were both waiting on each other.  Thanks!
> > No, it just went to the bottom of more important patches (i.e.
> > bugfixes.)  I'll reconsider this at a later point in time when I get a
> > chance...
> 
> Great, thanks!

Ok, I've applied this for 4.12 and 4.9 trees, let's see what breaks...

^ permalink raw reply	[flat|nested] 11+ messages in thread

* 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?
  2017-08-07 19:51             ` Greg KH
@ 2017-08-07 21:01               ` Greg KH
  2017-08-08 14:29                 ` Chris Metcalf
  0 siblings, 1 reply; 11+ messages in thread
From: Greg KH @ 2017-08-07 21:01 UTC (permalink / raw)
  To: Chris Metcalf; +Cc: dwoods, jh80.chung, ulf.hansson, stable

On Mon, Aug 07, 2017 at 12:51:38PM -0700, Greg KH wrote:
> On Fri, Jul 28, 2017 at 10:02:58PM -0400, Chris Metcalf wrote:
> > On 7/28/2017 7:30 PM, Greg KH wrote:
> > > > Ping?  Greg, I see that you released 4.12.4/4.9.40 without these patches, but
> > > > not having heard back from you, I wondered if my reply below was lost and we
> > > > were both waiting on each other.  Thanks!
> > > No, it just went to the bottom of more important patches (i.e.
> > > bugfixes.)  I'll reconsider this at a later point in time when I get a
> > > chance...
> > 
> > Great, thanks!
> 
> Ok, I've applied this for 4.12 and 4.9 trees, let's see what breaks...

Ok, 4.9 breaks badly, can you provide working backports of the two
patches for that kernel tree please?

thanks,

greg k-h

^ permalink raw reply	[flat|nested] 11+ messages in thread

* 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?
  2017-08-07 21:01               ` Greg KH
@ 2017-08-08 14:29                 ` Chris Metcalf
  2017-08-08 14:51                   ` Greg KH
  0 siblings, 1 reply; 11+ messages in thread
From: Chris Metcalf @ 2017-08-08 14:29 UTC (permalink / raw)
  To: Greg KH; +Cc: dwoods, jh80.chung, ulf.hansson, stable

On 8/7/2017 5:01 PM, Greg KH wrote:
> On Mon, Aug 07, 2017 at 12:51:38PM -0700, Greg KH wrote:
>> Ok, I've applied this for 4.12 and 4.9 trees, let's see what breaks... 
> Ok, 4.9 breaks badly, can you provide working backports of the two
> patches for that kernel tree please?

Sure.  There were some additional of_property_*() calls added since
4.9, so the patches failed to apply cleanly.  I'll reply to the two "FAILED"
emails with properly backported versions.

Note that you will have to apply commit e44bb0cbdc88 ("device
property: Make dev_fwnode() public") as well to allow the code to
compile, since it uses dev_fwnode.

-- 
Chris Metcalf, Mellanox Technologies
http://www.mellanox.com

^ permalink raw reply	[flat|nested] 11+ messages in thread

* 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?
  2017-08-08 14:29                 ` Chris Metcalf
@ 2017-08-08 14:51                   ` Greg KH
  0 siblings, 0 replies; 11+ messages in thread
From: Greg KH @ 2017-08-08 14:51 UTC (permalink / raw)
  To: Chris Metcalf; +Cc: dwoods, jh80.chung, ulf.hansson, stable

On Tue, Aug 08, 2017 at 10:29:24AM -0400, Chris Metcalf wrote:
> On 8/7/2017 5:01 PM, Greg KH wrote:
> > On Mon, Aug 07, 2017 at 12:51:38PM -0700, Greg KH wrote:
> > > Ok, I've applied this for 4.12 and 4.9 trees, let's see what
> > > breaks...
> > Ok, 4.9 breaks badly, can you provide working backports of the two
> > patches for that kernel tree please?
> 
> Sure.  There were some additional of_property_*() calls added since
> 4.9, so the patches failed to apply cleanly.  I'll reply to the two "FAILED"
> emails with properly backported versions.
> 
> Note that you will have to apply commit e44bb0cbdc88 ("device
> property: Make dev_fwnode() public") as well to allow the code to
> compile, since it uses dev_fwnode.

Yes, that patch is in the tree now.

thanks,

greg k-h

^ permalink raw reply	[flat|nested] 11+ messages in thread

end of thread, other threads:[~2017-08-08 14:51 UTC | newest]

Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
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
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

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.