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

Laszlo Fiat
2016-05-16T20:30:52Z

I ran into a problem with the kernel compilation using Adrian's patch:
ERROR: "acpi_device_fix_up_power" [drivers/mmc/host/sdhci-acpi.ko] undefined!
scripts/Makefile.modpost:91: recipe for target '__modpost' failed
make[1]: *** [__modpost] Error 1
Makefile:1142: recipe for target 'modules' failed
make: *** [modules] Error 2

The acpi_device_fix_up_power routine is in drivers/acpi/device_pm.c,
but I don't know how can I make it to find it.

Any help is appreciated.

Bye,

Laszlo Fiat

On Mon, May 16, 2016 at 6:56 PM, Laszlo Fiat <laszlo.fiat@gmail.com> wrote:
> 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