Re: [PATCH] mmc: sdhci-acpi: set non-removable in ACPI table

From: Rafael J. Wysocki
Date: Fri Dec 11 2015 - 17:23:41 EST


On Friday, December 11, 2015 10:17:18 AM Adrian Hunter wrote:
> On 10/12/15 22:57, Philip Elcan wrote:
> >
> > On 12/07/2015 03:30 AM, Adrian Hunter wrote:
> >> On 04/12/15 17:40, Philip Elcan wrote:
> >>> On 12/03/2015 09:14 AM, Adrian Hunter wrote:
> >>>> On 03/12/15 15:48, Philip Elcan wrote:
> >>>>> This allows setting an SDHC controller as non-removable
> >>>>> by using the _RMV method in the ACPI table. It doesn't
> >>>> Is that _RMV on the host controller? Shouldn't it be on the card i.e. child
> >>>> device node?
> >>> Yes, this is on the host controller. The ACPI table only describes the
> >>> host controller, not the child nodes.
> >>>
> >> If you look at Intel devices, the _RMV is on the child e.g.
> >>
> >> Device (SDHA)
> >> {
> >> Name (_HID, "80860F14") // _HID: Hardware ID
> >> Name (_CID, "PNP0D40") // _CID: Compatible ID
> >> Name (_DDN, "Intel(R) eMMC Controller - 80860F14") // _DDN: DOS Device Name
> >> ...
> >> Device (EMMD)
> >> {
> >> ...
> >> Method (_RMV, 0, NotSerialized) // _RMV: Removal Status
> >> {
> >> Return (Zero)
> >> }
> >> }
> >> }
> >>
> >> I am not an ACPI expert but that seems like the correct place for it.
> > My understanding is that in ACPI you don't generally create child devices on buses that are discoverable.
>
> I've cc'ed Rafael and the linux-acpi mailing list. Maybe someone there can
> comment.

The context here is a bit unclear to me.

Quite frankly, I don't see now _RMV above is useful for anything. As per the
spec, _RMV is only necessary for devices that *can* be removed from the system
and where there's no eject mechanism controlled by software. For those
devices _RMV is intended to indicate that it is safe to remove the device
at the time _RMV is evaluated. Devices that can never be removed don't
need _RMV at all.

Thanks,
Rafael

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/