From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754017AbcDSMpD (ORCPT ); Tue, 19 Apr 2016 08:45:03 -0400 Received: from mailout3.samsung.com ([203.254.224.33]:44105 "EHLO mailout3.samsung.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752486AbcDSMpA (ORCPT ); Tue, 19 Apr 2016 08:45:00 -0400 X-AuditID: cbfee68f-f79c86d0000012ad-70-57162849f393 Message-id: <57162849.3070108@samsung.com> Date: Tue, 19 Apr 2016 21:44:57 +0900 From: Jaehoon Chung User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-version: 1.0 To: Olliver Schinagl , Ulf Hansson Cc: Maxime Ripard , Chen-Yu Tsai , Venu Byravarasu , Adrian Hunter , Michal Hocko , Lars-Peter Clausen , Sudeep Holla , Sergei Shtylyov , Wolfram Sang , Wenkai Du , Chaotian Jing , Kuninori Morimoto , Hans de Goede , Michal Suchanek , linux-mmc , "linux-kernel@vger.kernel.org" , "linux-arm-kernel@lists.infradead.org" Subject: Re: [PATCH 1/2] mmc: core: Improve marking broken HPI through devicetree References: <1461049934-12848-1-git-send-email-oliver@schinagl.nl> <1461049934-12848-2-git-send-email-oliver@schinagl.nl> <5715FD6B.5000809@schinagl.nl> <5715FF1B.80402@samsung.com> <57162270.6040701@schinagl.nl> In-reply-to: <57162270.6040701@schinagl.nl> Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA02Se0hTURzHObsPryvhuOY8DUpYRuWr1FknsjAiuomkECQIYcsuZrlHm0aW lGlFWfmajxipWVbLls6ZbaXWukVWak8aJWlaahnrQZC4INfmjPrvyzmf8/l9D/wYQqSnpEyW KofTqhTZMlpImsRyTeTGxZLUZe7mMPxoxERjR389jZ3dNQJsbSbx53u3AG7U11PY8sFB4Ze3 ztL4vrsU4HZLF4HflSTg8YphCvc29fvhy49tJO6+lorf8+UE7uttJbCLfyrAJU82JMxhTXUm wA5VuQWs+f1Vih2xPAfsTcOAH3uhc1zAvnV00mxb4yH2yKM7JNvo5Cn2dNFXmv12+xXNTvSW k+xYQwvJHj1ymWJbrr8iUwLThPE7uOysvZx26Zptwp0/6l74aUaX7Kv68ZssAG9CioE/g6Ac jfacFPiyBD0bbKGLgZARQSNAxV9sxF/I5v5I+S4uAjR1ZnSGGgLoxPEa4KUCYBhq675PezMJ F6Kn9nY/b6ZhBLJOdE+PCIJb0FBzF+XjA9GkfpD0ZjFMRrzzksArJWAZjVp7yqdFc+BmNPDB RfqmNQjQQ2vdtNUfhiN9ZYHHxHheLEKVlUrvMQFDUJvpC+HlEXQz6JO9mvI1gmhCz5NeHsF5 yGKf+dpcdNf4miwDEsN/nQz/rIb/rOcA0QSCOE2GRrc9UxsbpVModbmqzKgMtdICPLvSMzVW agMD9lU8gAyQzQ5I0QSliijFXl2ekgdxnhLlhDQoQ+1ZL1VOenTs8hgcJ4+LjVmxcrksOKBB 6tosgpmKHG43x2k4bbo2N5vT8UDA+EsLQETwguH+wbstz6NRZLzxDTyg/mVLS+J3dKWYnara xYXr5n+vP5UrTeow7LqXnJdntgVmqW4c+zXLkRk6ZnasjlorTh4x1qza9bO6QzHpPHi4gikq zBeeH/sc0qdeoioIF8mtiUUuev8eyZWPD6zjs/KtWzdpatfrE7cG+4uNoUoZqdupiA4jtDrF Hxgh570mAwAA X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrAKsWRmVeSWpSXmKPExsVy+t9jAV1PDbFwg8PXlCxOPlnDZnHt1nw2 izfHpzNZbF/HYvHq8C5GiyWT57NabHp8jdXi8q45bBZH/vczWmzdtJfZ4n6fg8XLSQ9ZLc6s usVusfzUDhaL42vDLR4dmshscfbMRmaLn4fOM1n0nXN3EPZYM28No8eDqf+ZPDY8Ws3q8WTT RUaPnbPusnss3vOSyePOtT1sHpuX1Hu0nNzP4rHkzSFWj97md2we7/ddZfP4dmYii8ezhetZ PFpblrN6rN9ylSVAMKqB0SYjNTEltUghNS85PyUzL91WyTs43jne1MzAUNfQ0sJcSSEvMTfV VsnFJ0DXLTMH6G0lhbLEnFKgUEBicbGSvh2mCaEhbroWMI0Rur4hQXA9RgZoIGENY8aneZfY C55qVkz99JelgfGmfBcjJ4eEgInEjv/PWSFsMYkL99azdTFycQgJLGWU+DfjKZTzgFGis2M6 I0gVr4CWxObjR9hAbBYBVYnzB7ayg9hsAjoS278dZwKxRQXCJB6s28sKUS8o8WPyPRYQW0TA X+LQm2VMIEOZBSawSWw8PRFskLBAsMTdxz9ZILYtZJI4sX0e2FROAW2JyVMagCZxAHWoS0yZ kgsSZhaQl9i85i3zBEaBWUh2zEKomoWkagEj8ypGidSC5ILipPRcw7zUcr3ixNzi0rx0veT8 3E2M4NT1TGoH48Fd7ocYBTgYlXh4VxSJhguxJpYVV+YeYpTgYFYS4XVWEwsX4k1JrKxKLcqP LyrNSS0+xGgKDISJzFKiyfnAtJpXEm9obGJmZGlkbmhhZGyuJM77+P+6MCGB9MSS1OzU1ILU Ipg+Jg5OqQbGw2cn+d26kv67S3nmOcmcaZ8myP5Of7Yo1ra/aG7R0aJT/gbuG2+f1LxwfIFi +GGuRaozuR59/7LlQ21uj//55zyXPe5O5VprE2C5dXqq5SU/GXndw1kpXC1hnsukxVOOrZFl uOaWG+Gk+PLrlPdmVcKyPX9XTnLYcPzU9rf6cc81X5U3xvw9r8RSnJFoqMVcVJwIACybtK9z AwAA DLP-Filter: Pass X-MTR: 20000000000000000@CPGS X-CFilter-Loop: Reflected Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Olliver, On 04/19/2016 09:20 PM, Olliver Schinagl wrote: > Hey Jaehoon, > > On 19-04-16 11:49, Jaehoon Chung wrote: >> Hi >> >> On 04/19/2016 06:42 PM, Olliver Schinagl wrote: >>> Hi Ulf, >>> >>> On 19-04-16 11:29, Ulf Hansson wrote: >>>> On 19 April 2016 at 09:12, Olliver Schinagl wrote: >>>>> In patch 81f8a7be66 Hans de Goede added a patch to allow marking an mmc >>>>> device as to having an broken HPI implementation. After talking some >>>>> with Hans, we now think it is actually the mmc controller that can be >>>>> broken and not support broken HPI's. >>>> I don't want us to invent a DT binding for something you *think* is a >>>> HW controller issue. >>>> >>>> Have you really excluded that this isn't a software issue? Me >>>> personally haven't been using HPI that much so I can't really tell >>>> about the code robustness from the mmc core (mmc protocol point of >>>> view). >>> Well this patch goes hand in hand so to speak with the broken-hpi patch introduced by him, he did most of the investigation. We just discussed how to handle it and asked me to cook up the patch. >> I didn't understand why add this property. Is this same patch? >> >> commit 81f8a7be6642b4c26ab681b2e0f4c4120a6de1b0 >> Author: Hans de Goede >> Date: Wed Apr 1 17:26:23 2015 +0200 >> >> mmc: Add support for marking hpi as broken through devicetree >> >> The eMMC on a tablet I've will stop working / communicating as soon as >> the kernel executes: >> >> mmc_switch(card, EXT_CSD_CMD_SET_NORMAL, >> EXT_CSD_HPI_MGMT, 1, >> card->ext_csd.generic_cmd6_time); >> >> There seems to be no way to reliable identify eMMC-s which have a broken >> hpi implementation, but at least for eMMC's which are soldered onto a board >> we can work around this by specifying that hpi is broken in devicetree. > Similar, this does it on the card level, e.g. you mark a card as having a broken HPI implementation. > > The truth is, the card may not be broken at all, but the mmc controller so we add a property on the controller level. > > What Ulf is pondering, if this is not a software stack problem, rather then a hardware implementation, which I don't know. Hmm..problem is mmc controller side..it's strange. How did you know this problem is on mmc controller side? Well, i should be also missing something for HPI feature..but it's not relevant to mmc controller. Ok. i will check more.. Best Regards, Jaehoon Chung >>> @hans, what do you think? >>>> Kind regards >>>> Uffe >>>> >>>>> This patch adds a new capability, mmc-broken-hpi, which allows us to >>>>> mark a broken hpi implementation on the host level. >>>>> >>>>> Signed-off-by: Olliver Schinagl >>>>> --- >>>>> drivers/mmc/core/host.c | 2 ++ >>>>> drivers/mmc/core/mmc.c | 2 +- >>>>> include/linux/mmc/host.h | 1 + >>>>> 3 files changed, 4 insertions(+), 1 deletion(-) >>>>> >>>>> diff --git a/drivers/mmc/core/host.c b/drivers/mmc/core/host.c >>>>> index 6e4c55a..9b63b36 100644 >>>>> --- a/drivers/mmc/core/host.c >>>>> +++ b/drivers/mmc/core/host.c >>>>> @@ -270,6 +270,8 @@ int mmc_of_parse(struct mmc_host *host) >>>>> host->caps |= MMC_CAP_HW_RESET; >>>>> if (of_property_read_bool(np, "cap-sdio-irq")) >>>>> host->caps |= MMC_CAP_SDIO_IRQ; >>>>> + if (of_property_read_bool(np, "mmc-broken-hpi")) >>>>> + host->caps |= MMC_CAP_BROKEN_HPI; >>>>> if (of_property_read_bool(np, "full-pwr-cycle")) >>>>> host->caps2 |= MMC_CAP2_FULL_PWR_CYCLE; >>>>> if (of_property_read_bool(np, "keep-power-in-suspend")) >>>>> diff --git a/drivers/mmc/core/mmc.c b/drivers/mmc/core/mmc.c >>>>> index 4dbe3df..9a19562 100644 >>>>> --- a/drivers/mmc/core/mmc.c >>>>> +++ b/drivers/mmc/core/mmc.c >>>>> @@ -1592,7 +1592,7 @@ static int mmc_init_card(struct mmc_host *host, u32 ocr, >>>>> /* >>>>> * Enable HPI feature (if supported) >>>>> */ >>>>> - if (card->ext_csd.hpi) { >>>>> + if (card->ext_csd.hpi && !(host->caps & MMC_CAP_BROKEN_HPI)) { >>>>> err = mmc_switch(card, EXT_CSD_CMD_SET_NORMAL, >>>>> EXT_CSD_HPI_MGMT, 1, >>>>> card->ext_csd.generic_cmd6_time); >>>>> diff --git a/include/linux/mmc/host.h b/include/linux/mmc/host.h >>>>> index 8dd4d29..20f758e 100644 >>>>> --- a/include/linux/mmc/host.h >>>>> +++ b/include/linux/mmc/host.h >>>>> @@ -264,6 +264,7 @@ struct mmc_host { >>>>> #define MMC_CAP_DRIVER_TYPE_A (1 << 23) /* Host supports Driver Type A */ >>>>> #define MMC_CAP_DRIVER_TYPE_C (1 << 24) /* Host supports Driver Type C */ >>>>> #define MMC_CAP_DRIVER_TYPE_D (1 << 25) /* Host supports Driver Type D */ >>>>> +#define MMC_CAP_BROKEN_HPI (1 << 29) /* Host support for HPI is broken */ >>>>> #define MMC_CAP_CMD23 (1 << 30) /* CMD23 supported. */ >>>>> #define MMC_CAP_HW_RESET (1 << 31) /* Hardware reset */ >>>>> >>>>> -- >>>>> 2.8.0.rc3 >>>>> >>> >>> > > > From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jaehoon Chung Subject: Re: [PATCH 1/2] mmc: core: Improve marking broken HPI through devicetree Date: Tue, 19 Apr 2016 21:44:57 +0900 Message-ID: <57162849.3070108@samsung.com> References: <1461049934-12848-1-git-send-email-oliver@schinagl.nl> <1461049934-12848-2-git-send-email-oliver@schinagl.nl> <5715FD6B.5000809@schinagl.nl> <5715FF1B.80402@samsung.com> <57162270.6040701@schinagl.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Return-path: Received: from mailout3.samsung.com ([203.254.224.33]:44105 "EHLO mailout3.samsung.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752486AbcDSMpA (ORCPT ); Tue, 19 Apr 2016 08:45:00 -0400 In-reply-to: <57162270.6040701@schinagl.nl> Sender: linux-mmc-owner@vger.kernel.org List-Id: linux-mmc@vger.kernel.org To: Olliver Schinagl , Ulf Hansson Cc: Maxime Ripard , Chen-Yu Tsai , Venu Byravarasu , Adrian Hunter , Michal Hocko , Lars-Peter Clausen , Sudeep Holla , Sergei Shtylyov , Wolfram Sang , Wenkai Du , Chaotian Jing , Kuninori Morimoto , Hans de Goede , Michal Suchanek , linux-mmc , "linux-kernel@vger.kernel.org" , "linux-arm-kernel@lists.infradead.org" Hi Olliver, On 04/19/2016 09:20 PM, Olliver Schinagl wrote: > Hey Jaehoon, > > On 19-04-16 11:49, Jaehoon Chung wrote: >> Hi >> >> On 04/19/2016 06:42 PM, Olliver Schinagl wrote: >>> Hi Ulf, >>> >>> On 19-04-16 11:29, Ulf Hansson wrote: >>>> On 19 April 2016 at 09:12, Olliver Schinagl wrote: >>>>> In patch 81f8a7be66 Hans de Goede added a patch to allow marking an mmc >>>>> device as to having an broken HPI implementation. After talking some >>>>> with Hans, we now think it is actually the mmc controller that can be >>>>> broken and not support broken HPI's. >>>> I don't want us to invent a DT binding for something you *think* is a >>>> HW controller issue. >>>> >>>> Have you really excluded that this isn't a software issue? Me >>>> personally haven't been using HPI that much so I can't really tell >>>> about the code robustness from the mmc core (mmc protocol point of >>>> view). >>> Well this patch goes hand in hand so to speak with the broken-hpi patch introduced by him, he did most of the investigation. We just discussed how to handle it and asked me to cook up the patch. >> I didn't understand why add this property. Is this same patch? >> >> commit 81f8a7be6642b4c26ab681b2e0f4c4120a6de1b0 >> Author: Hans de Goede >> Date: Wed Apr 1 17:26:23 2015 +0200 >> >> mmc: Add support for marking hpi as broken through devicetree >> >> The eMMC on a tablet I've will stop working / communicating as soon as >> the kernel executes: >> >> mmc_switch(card, EXT_CSD_CMD_SET_NORMAL, >> EXT_CSD_HPI_MGMT, 1, >> card->ext_csd.generic_cmd6_time); >> >> There seems to be no way to reliable identify eMMC-s which have a broken >> hpi implementation, but at least for eMMC's which are soldered onto a board >> we can work around this by specifying that hpi is broken in devicetree. > Similar, this does it on the card level, e.g. you mark a card as having a broken HPI implementation. > > The truth is, the card may not be broken at all, but the mmc controller so we add a property on the controller level. > > What Ulf is pondering, if this is not a software stack problem, rather then a hardware implementation, which I don't know. Hmm..problem is mmc controller side..it's strange. How did you know this problem is on mmc controller side? Well, i should be also missing something for HPI feature..but it's not relevant to mmc controller. Ok. i will check more.. Best Regards, Jaehoon Chung >>> @hans, what do you think? >>>> Kind regards >>>> Uffe >>>> >>>>> This patch adds a new capability, mmc-broken-hpi, which allows us to >>>>> mark a broken hpi implementation on the host level. >>>>> >>>>> Signed-off-by: Olliver Schinagl >>>>> --- >>>>> drivers/mmc/core/host.c | 2 ++ >>>>> drivers/mmc/core/mmc.c | 2 +- >>>>> include/linux/mmc/host.h | 1 + >>>>> 3 files changed, 4 insertions(+), 1 deletion(-) >>>>> >>>>> diff --git a/drivers/mmc/core/host.c b/drivers/mmc/core/host.c >>>>> index 6e4c55a..9b63b36 100644 >>>>> --- a/drivers/mmc/core/host.c >>>>> +++ b/drivers/mmc/core/host.c >>>>> @@ -270,6 +270,8 @@ int mmc_of_parse(struct mmc_host *host) >>>>> host->caps |= MMC_CAP_HW_RESET; >>>>> if (of_property_read_bool(np, "cap-sdio-irq")) >>>>> host->caps |= MMC_CAP_SDIO_IRQ; >>>>> + if (of_property_read_bool(np, "mmc-broken-hpi")) >>>>> + host->caps |= MMC_CAP_BROKEN_HPI; >>>>> if (of_property_read_bool(np, "full-pwr-cycle")) >>>>> host->caps2 |= MMC_CAP2_FULL_PWR_CYCLE; >>>>> if (of_property_read_bool(np, "keep-power-in-suspend")) >>>>> diff --git a/drivers/mmc/core/mmc.c b/drivers/mmc/core/mmc.c >>>>> index 4dbe3df..9a19562 100644 >>>>> --- a/drivers/mmc/core/mmc.c >>>>> +++ b/drivers/mmc/core/mmc.c >>>>> @@ -1592,7 +1592,7 @@ static int mmc_init_card(struct mmc_host *host, u32 ocr, >>>>> /* >>>>> * Enable HPI feature (if supported) >>>>> */ >>>>> - if (card->ext_csd.hpi) { >>>>> + if (card->ext_csd.hpi && !(host->caps & MMC_CAP_BROKEN_HPI)) { >>>>> err = mmc_switch(card, EXT_CSD_CMD_SET_NORMAL, >>>>> EXT_CSD_HPI_MGMT, 1, >>>>> card->ext_csd.generic_cmd6_time); >>>>> diff --git a/include/linux/mmc/host.h b/include/linux/mmc/host.h >>>>> index 8dd4d29..20f758e 100644 >>>>> --- a/include/linux/mmc/host.h >>>>> +++ b/include/linux/mmc/host.h >>>>> @@ -264,6 +264,7 @@ struct mmc_host { >>>>> #define MMC_CAP_DRIVER_TYPE_A (1 << 23) /* Host supports Driver Type A */ >>>>> #define MMC_CAP_DRIVER_TYPE_C (1 << 24) /* Host supports Driver Type C */ >>>>> #define MMC_CAP_DRIVER_TYPE_D (1 << 25) /* Host supports Driver Type D */ >>>>> +#define MMC_CAP_BROKEN_HPI (1 << 29) /* Host support for HPI is broken */ >>>>> #define MMC_CAP_CMD23 (1 << 30) /* CMD23 supported. */ >>>>> #define MMC_CAP_HW_RESET (1 << 31) /* Hardware reset */ >>>>> >>>>> -- >>>>> 2.8.0.rc3 >>>>> >>> >>> > > > From mboxrd@z Thu Jan 1 00:00:00 1970 From: jh80.chung@samsung.com (Jaehoon Chung) Date: Tue, 19 Apr 2016 21:44:57 +0900 Subject: [PATCH 1/2] mmc: core: Improve marking broken HPI through devicetree In-Reply-To: <57162270.6040701@schinagl.nl> References: <1461049934-12848-1-git-send-email-oliver@schinagl.nl> <1461049934-12848-2-git-send-email-oliver@schinagl.nl> <5715FD6B.5000809@schinagl.nl> <5715FF1B.80402@samsung.com> <57162270.6040701@schinagl.nl> Message-ID: <57162849.3070108@samsung.com> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org Hi Olliver, On 04/19/2016 09:20 PM, Olliver Schinagl wrote: > Hey Jaehoon, > > On 19-04-16 11:49, Jaehoon Chung wrote: >> Hi >> >> On 04/19/2016 06:42 PM, Olliver Schinagl wrote: >>> Hi Ulf, >>> >>> On 19-04-16 11:29, Ulf Hansson wrote: >>>> On 19 April 2016 at 09:12, Olliver Schinagl wrote: >>>>> In patch 81f8a7be66 Hans de Goede added a patch to allow marking an mmc >>>>> device as to having an broken HPI implementation. After talking some >>>>> with Hans, we now think it is actually the mmc controller that can be >>>>> broken and not support broken HPI's. >>>> I don't want us to invent a DT binding for something you *think* is a >>>> HW controller issue. >>>> >>>> Have you really excluded that this isn't a software issue? Me >>>> personally haven't been using HPI that much so I can't really tell >>>> about the code robustness from the mmc core (mmc protocol point of >>>> view). >>> Well this patch goes hand in hand so to speak with the broken-hpi patch introduced by him, he did most of the investigation. We just discussed how to handle it and asked me to cook up the patch. >> I didn't understand why add this property. Is this same patch? >> >> commit 81f8a7be6642b4c26ab681b2e0f4c4120a6de1b0 >> Author: Hans de Goede >> Date: Wed Apr 1 17:26:23 2015 +0200 >> >> mmc: Add support for marking hpi as broken through devicetree >> >> The eMMC on a tablet I've will stop working / communicating as soon as >> the kernel executes: >> >> mmc_switch(card, EXT_CSD_CMD_SET_NORMAL, >> EXT_CSD_HPI_MGMT, 1, >> card->ext_csd.generic_cmd6_time); >> >> There seems to be no way to reliable identify eMMC-s which have a broken >> hpi implementation, but at least for eMMC's which are soldered onto a board >> we can work around this by specifying that hpi is broken in devicetree. > Similar, this does it on the card level, e.g. you mark a card as having a broken HPI implementation. > > The truth is, the card may not be broken at all, but the mmc controller so we add a property on the controller level. > > What Ulf is pondering, if this is not a software stack problem, rather then a hardware implementation, which I don't know. Hmm..problem is mmc controller side..it's strange. How did you know this problem is on mmc controller side? Well, i should be also missing something for HPI feature..but it's not relevant to mmc controller. Ok. i will check more.. Best Regards, Jaehoon Chung >>> @hans, what do you think? >>>> Kind regards >>>> Uffe >>>> >>>>> This patch adds a new capability, mmc-broken-hpi, which allows us to >>>>> mark a broken hpi implementation on the host level. >>>>> >>>>> Signed-off-by: Olliver Schinagl >>>>> --- >>>>> drivers/mmc/core/host.c | 2 ++ >>>>> drivers/mmc/core/mmc.c | 2 +- >>>>> include/linux/mmc/host.h | 1 + >>>>> 3 files changed, 4 insertions(+), 1 deletion(-) >>>>> >>>>> diff --git a/drivers/mmc/core/host.c b/drivers/mmc/core/host.c >>>>> index 6e4c55a..9b63b36 100644 >>>>> --- a/drivers/mmc/core/host.c >>>>> +++ b/drivers/mmc/core/host.c >>>>> @@ -270,6 +270,8 @@ int mmc_of_parse(struct mmc_host *host) >>>>> host->caps |= MMC_CAP_HW_RESET; >>>>> if (of_property_read_bool(np, "cap-sdio-irq")) >>>>> host->caps |= MMC_CAP_SDIO_IRQ; >>>>> + if (of_property_read_bool(np, "mmc-broken-hpi")) >>>>> + host->caps |= MMC_CAP_BROKEN_HPI; >>>>> if (of_property_read_bool(np, "full-pwr-cycle")) >>>>> host->caps2 |= MMC_CAP2_FULL_PWR_CYCLE; >>>>> if (of_property_read_bool(np, "keep-power-in-suspend")) >>>>> diff --git a/drivers/mmc/core/mmc.c b/drivers/mmc/core/mmc.c >>>>> index 4dbe3df..9a19562 100644 >>>>> --- a/drivers/mmc/core/mmc.c >>>>> +++ b/drivers/mmc/core/mmc.c >>>>> @@ -1592,7 +1592,7 @@ static int mmc_init_card(struct mmc_host *host, u32 ocr, >>>>> /* >>>>> * Enable HPI feature (if supported) >>>>> */ >>>>> - if (card->ext_csd.hpi) { >>>>> + if (card->ext_csd.hpi && !(host->caps & MMC_CAP_BROKEN_HPI)) { >>>>> err = mmc_switch(card, EXT_CSD_CMD_SET_NORMAL, >>>>> EXT_CSD_HPI_MGMT, 1, >>>>> card->ext_csd.generic_cmd6_time); >>>>> diff --git a/include/linux/mmc/host.h b/include/linux/mmc/host.h >>>>> index 8dd4d29..20f758e 100644 >>>>> --- a/include/linux/mmc/host.h >>>>> +++ b/include/linux/mmc/host.h >>>>> @@ -264,6 +264,7 @@ struct mmc_host { >>>>> #define MMC_CAP_DRIVER_TYPE_A (1 << 23) /* Host supports Driver Type A */ >>>>> #define MMC_CAP_DRIVER_TYPE_C (1 << 24) /* Host supports Driver Type C */ >>>>> #define MMC_CAP_DRIVER_TYPE_D (1 << 25) /* Host supports Driver Type D */ >>>>> +#define MMC_CAP_BROKEN_HPI (1 << 29) /* Host support for HPI is broken */ >>>>> #define MMC_CAP_CMD23 (1 << 30) /* CMD23 supported. */ >>>>> #define MMC_CAP_HW_RESET (1 << 31) /* Hardware reset */ >>>>> >>>>> -- >>>>> 2.8.0.rc3 >>>>> >>> >>> > > >