Re: [PATCH] mmc: block: Use the mmc host device index as the mmcblk device index

Laszlo Fiat
2016-05-16T16:57:00Z

Compiling a new kernel with that patch applied. I will report back
when it is finished.

Bye,

Laszlo Fiat

On Mon, May 16, 2016 at 6:39 PM, nick <xerofoify@gmail.com> wrote:
>
>
> On 2016-05-16 07:43 AM, Adrian Hunter wrote:
>> On 16/05/16 12:12, Adrian Hunter wrote:
>>> On 16/05/16 11:47, Ulf Hansson wrote:
>>>> + Nicholas Krause
>>>>
>>>> On 13 April 2016 at 20:19, Laszlo Fiat <laszlo.fiat@gmail.com> wrote:
>>>>> Adrian, Ulf,
>>>>>
>>>>> Here are the two v4.6-rc3 kernel dmesg with mmc-debug option, both
>>>>> without additional patches, one working case [1], one failing case
>>>>> [2], the working case has patch [3] reverted.
>>>>>
>>>>> I also uploaded the acpidump [4] for Teclast X80h Baytrail-T tablet.
>>>>>
>>>>> [1]: https://bugzilla.kernel.org/show_bug.cgi?id=112571#c11
>>>>> [2]: https://bugzilla.kernel.org/show_bug.cgi?id=112571#c10
>>>>> [3]: patch 520bd7a8b4152aacfbd34eb7f7a447354b631039 ("mmc: core:
>>>>> Optimize boot time by detecting cards simultaneously")
>>>>> [4]: https://bugzilla.kernel.org/show_bug.cgi?id=112571#c12
>>>>>
>>>>
>>>> Adrian, did you manage to get some time to look into the debug data
>>>> from this issue?
>>>
>>> Not yet.
>>>
>>>> I understand if you have been busy and no worries, although I don't
>>>> know who else to ping about this.
>>>
>>> I will have a look today.
>>>
>>>>
>>>> I don't want to us revert 520bd7a8b4152aacfbd34eb7f7a447354b631039,
>>>> because I believe it will just hide the problem in sdhci(-acpi).
>>>> Instead, I intend to wait for a proper fix, does that sounds
>>>> reasonable to you as well?
>>>
>>> Sure
>>
>> Here is a patch that might help:
>>
>> From: Adrian Hunter <adrian.hunter@intel.com>
>> Date: Mon, 16 May 2016 14:29:51 +0300
>> Subject: [PATCH] mmc: sdhci-acpi: Ensure connected devices are powered on
>> before probing
>>
>> Some devices connected to the SDHCI controller may have
>> separate enabling lines that are controlled through GPIO.
>> These devices need to be powered on and enabled before
>> probing. This is to ensure all devices connected can be
>> seen by the controller.
>>
>> Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
>> ---
>> drivers/mmc/host/sdhci-acpi.c | 7 ++++++-
>> 1 file changed, 6 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/mmc/host/sdhci-acpi.c b/drivers/mmc/host/sdhci-acpi.c
>> index b2d70ba6caa7..2d1c4870c285 100644
>> --- a/drivers/mmc/host/sdhci-acpi.c
>> +++ b/drivers/mmc/host/sdhci-acpi.c
>> @@ -378,7 +378,7 @@ static int sdhci_acpi_probe(struct platform_device *pdev)
>> {
>> struct device *dev = &pdev->dev;
>> acpi_handle handle = ACPI_HANDLE(dev);
>> - struct acpi_device *device;
>> + struct acpi_device *device, *child;
>> struct sdhci_acpi_host *c;
>> struct sdhci_host *host;
>> struct resource *iomem;
>> @@ -390,6 +390,11 @@ static int sdhci_acpi_probe(struct platform_device *pdev)
>> if (acpi_bus_get_device(handle, &device))
>> return -ENODEV;
>>
>> + /* Power on the SDHCI controller and its children */
>> + acpi_device_fix_up_power(device);
>> + list_for_each_entry(child, &device->children, node)
>> + acpi_device_fix_up_power(child);
>> +
>> if (acpi_bus_get_status(device) || !device->status.present)
>> return -ENODEV;
>>
>>
> That should fix the issue at least to my knowledge. Seems it's related to a regression with
> not probing/fixing the power on certain child devices. However since I don't have any hardware
> that can verify this regression I am unable to help much further.
> Cheers,
> Nick