ACPI device without physical node (pnpacpi oddity?)

ACPI device without physical node (pnpacpi oddity?)

[Andy Lutomirski]

I have this device:

        Device (HIDD)
        {
            Name (_HID, "INT33D5")  // _HID: Hardware ID
            Name (_CID, "PNP0C02" /* PNP Motherboard Resources */)  //
_CID: Compatible ID
            Name (HBSY, Zero)
            Name (HIDX, Zero)
            Name (HMDE, Zero)
            Name (HRDY, Zero)
            Method (_STA, 0, Serialized)  // _STA: Status
            {
                If ((OIDE () < One))
                {
                    Return (Zero)
                }

                Return (0x0F)
            }

            Method (HDDM, 0, Serialized)
            {
                Name (DPKG, Package (0x04)
                {
                    0x11111111,
                    0x22222222,
                    0x33333333,
                    0x44444444
                })
                Return (DPKG) /* \_SB_.HIDD.HDDM.DPKG */
            }

            Method (HDEM, 0, Serialized)
            {
                HBSY = Zero
                If ((HMDE == Zero))
                {
                    Return (HIDX) /* \_SB_.HIDD.HIDX */
                }

                Return (HMDE) /* \_SB_.HIDD.HMDE */
            }

            Method (HDMM, 0, Serialized)
            {
                Return (HMDE) /* \_SB_.HIDD.HMDE */
            }

            Method (HDSM, 1, Serialized)
            {
                HRDY = Arg0
            }

            Method (HPEM, 1, Serialized)
            {
                HBSY = One
                If ((HMDE == Zero))
                {
                    HIDX = Arg0
                }
                Else
                {
                    HIDX = Arg0
                }

                Notify (HIDD, 0xC0) // Hardware-Specific
                Local0 = Zero
                While (((Local0 < 0xFA) && HBSY))
                {
                    Sleep (0x04)
                    Local0++
                }

                If ((HBSY == One))
                {
                    HBSY = Zero
                    HIDX = Zero
                    Return (One)
                }
                Else
                {
                    Return (Zero)
                }
            }

            Method (NRBT, 2, NotSerialized)
            {
                If ((OIDE () >= One))
                {
                    If ((HRDY == One))
                    {
                        HIDX = 0x08
                        Notify (HIDD, 0xC0) // Hardware-Specific
                    }
                }
            }
        }

_STA returns 0x0f, and the device is functional if I attach to it
directly.  But I want to write a proper driver for it and to attach to
the correct device, and the ACPI and PnP bus code isn't cooperating.

>From inspection of the code, acpi_pnp.c determines that the device is
a pnp device because pnp0c02 is in acpi_pnp_device_ids.  This causes
the device to have a concrete handler, so no platform device is
created.  However, pnpacpi/core.c rejects it because it has no _CRS
method.  As a result, it's in limbo.

What's the right thing to do here?  I could modify acpi_pnp.c to
reject the device, which will let the generic platform fallback claim
it.  I could modify pnpacpi to accept the device despite the lack of
_CRS, so a pnp device will be created.  I could bind directly as an
ACPI driver (somewhat suboptimal because apparently that's frowned
upon).  I could also write *both* an ACPI driver and platform driver
and call acpi_create_platform_device from the ACPI driver, but that
seems a bit ugly.

Thoughts?

--Andy


-- 
Andy Lutomirski
AMA Capital Management, LLC

Re: ACPI device without physical node (pnpacpi oddity?)

[Andy Lutomirski]

On Sun, Nov 29, 2015 at 9:19 PM, Andy Lutomirski <luto@amacapital.net> wrote:
> I have this device:
>
>         Device (HIDD)
>         {
>             Name (_HID, "INT33D5")  // _HID: Hardware ID
>             Name (_CID, "PNP0C02" /* PNP Motherboard Resources */)  //
> _CID: Compatible ID
>             Name (HBSY, Zero)
>             Name (HIDX, Zero)
>             Name (HMDE, Zero)
>             Name (HRDY, Zero)
>             Method (_STA, 0, Serialized)  // _STA: Status
>             {
>                 If ((OIDE () < One))
>                 {
>                     Return (Zero)
>                 }
>
>                 Return (0x0F)
>             }
>
>             Method (HDDM, 0, Serialized)
>             {
>                 Name (DPKG, Package (0x04)
>                 {
>                     0x11111111,
>                     0x22222222,
>                     0x33333333,
>                     0x44444444
>                 })
>                 Return (DPKG) /* \_SB_.HIDD.HDDM.DPKG */
>             }
>
>             Method (HDEM, 0, Serialized)
>             {
>                 HBSY = Zero
>                 If ((HMDE == Zero))
>                 {
>                     Return (HIDX) /* \_SB_.HIDD.HIDX */
>                 }
>
>                 Return (HMDE) /* \_SB_.HIDD.HMDE */
>             }
>
>             Method (HDMM, 0, Serialized)
>             {
>                 Return (HMDE) /* \_SB_.HIDD.HMDE */
>             }
>
>             Method (HDSM, 1, Serialized)
>             {
>                 HRDY = Arg0
>             }
>
>             Method (HPEM, 1, Serialized)
>             {
>                 HBSY = One
>                 If ((HMDE == Zero))
>                 {
>                     HIDX = Arg0
>                 }
>                 Else
>                 {
>                     HIDX = Arg0
>                 }
>
>                 Notify (HIDD, 0xC0) // Hardware-Specific
>                 Local0 = Zero
>                 While (((Local0 < 0xFA) && HBSY))
>                 {
>                     Sleep (0x04)
>                     Local0++
>                 }
>
>                 If ((HBSY == One))
>                 {
>                     HBSY = Zero
>                     HIDX = Zero
>                     Return (One)
>                 }
>                 Else
>                 {
>                     Return (Zero)
>                 }
>             }
>
>             Method (NRBT, 2, NotSerialized)
>             {
>                 If ((OIDE () >= One))
>                 {
>                     If ((HRDY == One))
>                     {
>                         HIDX = 0x08
>                         Notify (HIDD, 0xC0) // Hardware-Specific
>                     }
>                 }
>             }
>         }
>
> _STA returns 0x0f, and the device is functional if I attach to it
> directly.  But I want to write a proper driver for it and to attach to
> the correct device, and the ACPI and PnP bus code isn't cooperating.
>
> From inspection of the code, acpi_pnp.c determines that the device is
> a pnp device because pnp0c02 is in acpi_pnp_device_ids.  This causes
> the device to have a concrete handler, so no platform device is
> created.  However, pnpacpi/core.c rejects it because it has no _CRS
> method.  As a result, it's in limbo.
>
> What's the right thing to do here?  I could modify acpi_pnp.c to
> reject the device, which will let the generic platform fallback claim
> it.  I could modify pnpacpi to accept the device despite the lack of
> _CRS, so a pnp device will be created.  I could bind directly as an
> ACPI driver (somewhat suboptimal because apparently that's frowned
> upon).  I could also write *both* an ACPI driver and platform driver
> and call acpi_create_platform_device from the ACPI driver, but that
> seems a bit ugly.
>
> Thoughts?

If this is firmware bug (the ACPI spec suggests that _CRS may be
mandatory for non-natively-enumerable things like this), then there's
also a chance that the vendor will fix it.  On the other hand, maybe
this is already compliant and we should just interpret missing _CRS as
an empty set of resources.  (By inspection of the ASL, it really does
look like this thing has no resources beyond the ACPI methods in it.)

--Andy

Re: ACPI device without physical node (pnpacpi oddity?)

[Rafael J. Wysocki]

On Monday, November 30, 2015 12:15:27 PM Andy Lutomirski wrote:
> On Sun, Nov 29, 2015 at 9:19 PM, Andy Lutomirski <luto@amacapital.net> wrote:

[cut]

> > From inspection of the code, acpi_pnp.c determines that the device is
> > a pnp device because pnp0c02 is in acpi_pnp_device_ids.  This causes
> > the device to have a concrete handler, so no platform device is
> > created.  However, pnpacpi/core.c rejects it because it has no _CRS
> > method.  As a result, it's in limbo.
> >
> > What's the right thing to do here?  I could modify acpi_pnp.c to
> > reject the device, which will let the generic platform fallback claim
> > it.

pnp0c02 is a special device ID.  It is defined by MS as "General ID for
reserving resources required by PnP motherboard", so having no _CRS for
that particular device ID doesn't really make sense.

Moreover, we have a PNP driver that (normally) binds to that device ID,
so a PNP device object should be created for it.

> > I could modify pnpacpi to accept the device despite the lack of
> > _CRS, so a pnp device will be created.

I'm not sure if that's going to work, you'd need to try it.

The PNP layer is built around resources management, so the lack of resources
to manage may uncover some dusty corners in it.

> > I could bind directly as an
> > ACPI driver (somewhat suboptimal because apparently that's frowned
> > upon).

The policy here is "avoid that if reasonably possible", but in this particular
case there should be a PNP device.

> > I could also write *both* an ACPI driver and platform driver
> > and call acpi_create_platform_device from the ACPI driver, but that
> > seems a bit ugly.
> >
> > Thoughts?
> 
> If this is firmware bug (the ACPI spec suggests that _CRS may be
> mandatory for non-natively-enumerable things like this), then there's
> also a chance that the vendor will fix it.  On the other hand, maybe
> this is already compliant and we should just interpret missing _CRS as
> an empty set of resources.  (By inspection of the ASL, it really does
> look like this thing has no resources beyond the ACPI methods in it.)

OK, so it this in the context of the WMI bus type you're working on?

Rafael

Re: ACPI device without physical node (pnpacpi oddity?)

[Andy Lutomirski]

On Nov 30, 2015 2:40 PM, "Rafael J. Wysocki" <rjw@rjwysocki.net> wrote:
>
> On Monday, November 30, 2015 12:15:27 PM Andy Lutomirski wrote:
> > On Sun, Nov 29, 2015 at 9:19 PM, Andy Lutomirski <luto@amacapital.net> wrote:
>
> [cut]
>
> > > From inspection of the code, acpi_pnp.c determines that the device is
> > > a pnp device because pnp0c02 is in acpi_pnp_device_ids.  This causes
> > > the device to have a concrete handler, so no platform device is
> > > created.  However, pnpacpi/core.c rejects it because it has no _CRS
> > > method.  As a result, it's in limbo.
> > >
> > > What's the right thing to do here?  I could modify acpi_pnp.c to
> > > reject the device, which will let the generic platform fallback claim
> > > it.
>
> pnp0c02 is a special device ID.  It is defined by MS as "General ID for
> reserving resources required by PnP motherboard", so having no _CRS for
> that particular device ID doesn't really make sense.
>
> Moreover, we have a PNP driver that (normally) binds to that device ID,
> so a PNP device object should be created for it.

Given that the pnpacpi driver is going to reject it anyway, it could
make sense to keep it from binding at all (and maybe warn?) so that
the platform fallback code picks it up, though.

>
> > > I could modify pnpacpi to accept the device despite the lack of
> > > _CRS, so a pnp device will be created.
>
> I'm not sure if that's going to work, you'd need to try it.
>
> The PNP layer is built around resources management, so the lack of resources
> to manage may uncover some dusty corners in it.
>
> > > I could bind directly as an
> > > ACPI driver (somewhat suboptimal because apparently that's frowned
> > > upon).
>
> The policy here is "avoid that if reasonably possible", but in this particular
> case there should be a PNP device.
>
> > > I could also write *both* an ACPI driver and platform driver
> > > and call acpi_create_platform_device from the ACPI driver, but that
> > > seems a bit ugly.
> > >
> > > Thoughts?
> >
> > If this is firmware bug (the ACPI spec suggests that _CRS may be
> > mandatory for non-natively-enumerable things like this), then there's
> > also a chance that the vendor will fix it.  On the other hand, maybe
> > this is already compliant and we should just interpret missing _CRS as
> > an empty set of resources.  (By inspection of the ASL, it really does
> > look like this thing has no resources beyond the ACPI methods in it.)
>
> OK, so it this in the context of the WMI bus type you're working on?

Actually, no.  It's another magic pure ACPI device on the same laptop, though.

My current draft has:

/*
 * Unfortunately, some systems fail to enumerate our device as a
 * platform device.  Force the issue.
 */
static acpi_status __init
check_acpi_dev(acpi_handle handle, u32 lvl, void *context, void **rv)
{
    const struct acpi_device_id *ids = context;
    struct acpi_device *dev;

    if (acpi_bus_get_device(handle, &dev) != 0)
        return AE_OK;

    if (acpi_match_device_ids(dev, ids) == 0)
        if (acpi_create_platform_device(dev))
            dev_info(&dev->dev,
                 "created platform device\n");

    return AE_OK;
}

...

    acpi_walk_namespace(ACPI_TYPE_DEVICE, ACPI_ROOT_OBJECT,
                ACPI_UINT32_MAX, check_acpi_dev, NULL,
                (void *)ids, NULL);

It works, but it's not fantastic.

--Andy

Re: ACPI device without physical node (pnpacpi oddity?)

[Rafael J. Wysocki]

On Monday, November 30, 2015 03:45:15 PM Andy Lutomirski wrote:
> On Nov 30, 2015 2:40 PM, "Rafael J. Wysocki" <rjw@rjwysocki.net> wrote:
> >
> > On Monday, November 30, 2015 12:15:27 PM Andy Lutomirski wrote:
> > > On Sun, Nov 29, 2015 at 9:19 PM, Andy Lutomirski <luto@amacapital.net> wrote:
> >
> > [cut]
> >
> > > > From inspection of the code, acpi_pnp.c determines that the device is
> > > > a pnp device because pnp0c02 is in acpi_pnp_device_ids.  This causes
> > > > the device to have a concrete handler, so no platform device is
> > > > created.  However, pnpacpi/core.c rejects it because it has no _CRS
> > > > method.  As a result, it's in limbo.
> > > >
> > > > What's the right thing to do here?  I could modify acpi_pnp.c to
> > > > reject the device, which will let the generic platform fallback claim
> > > > it.
> >
> > pnp0c02 is a special device ID.  It is defined by MS as "General ID for
> > reserving resources required by PnP motherboard", so having no _CRS for
> > that particular device ID doesn't really make sense.
> >
> > Moreover, we have a PNP driver that (normally) binds to that device ID,
> > so a PNP device object should be created for it.
> 
> Given that the pnpacpi driver is going to reject it anyway, it could
> make sense to keep it from binding at all (and maybe warn?) so that
> the platform fallback code picks it up, though.

The point is that we'll create a PNP device for the same device ID on other
platforms and that's going to be confusing, isn't it?

I guess one option might be to hack the driver in question to accept a
device without _CRS and then do what you need to be done for that device.

> >
> > > > I could modify pnpacpi to accept the device despite the lack of
> > > > _CRS, so a pnp device will be created.
> >
> > I'm not sure if that's going to work, you'd need to try it.
> >
> > The PNP layer is built around resources management, so the lack of resources
> > to manage may uncover some dusty corners in it.
> >
> > > > I could bind directly as an
> > > > ACPI driver (somewhat suboptimal because apparently that's frowned
> > > > upon).
> >
> > The policy here is "avoid that if reasonably possible", but in this particular
> > case there should be a PNP device.
> >
> > > > I could also write *both* an ACPI driver and platform driver
> > > > and call acpi_create_platform_device from the ACPI driver, but that
> > > > seems a bit ugly.
> > > >
> > > > Thoughts?
> > >
> > > If this is firmware bug (the ACPI spec suggests that _CRS may be
> > > mandatory for non-natively-enumerable things like this), then there's
> > > also a chance that the vendor will fix it.  On the other hand, maybe
> > > this is already compliant and we should just interpret missing _CRS as
> > > an empty set of resources.  (By inspection of the ASL, it really does
> > > look like this thing has no resources beyond the ACPI methods in it.)
> >
> > OK, so it this in the context of the WMI bus type you're working on?
> 
> Actually, no.  It's another magic pure ACPI device on the same laptop, though.
> 
> My current draft has:
> 
> /*
>  * Unfortunately, some systems fail to enumerate our device as a
>  * platform device.  Force the issue.
>  */
> static acpi_status __init
> check_acpi_dev(acpi_handle handle, u32 lvl, void *context, void **rv)
> {
>     const struct acpi_device_id *ids = context;
>     struct acpi_device *dev;
> 
>     if (acpi_bus_get_device(handle, &dev) != 0)
>         return AE_OK;
> 
>     if (acpi_match_device_ids(dev, ids) == 0)
>         if (acpi_create_platform_device(dev))
>             dev_info(&dev->dev,
>                  "created platform device\n");
> 
>     return AE_OK;
> }
> 
> ...
> 
>     acpi_walk_namespace(ACPI_TYPE_DEVICE, ACPI_ROOT_OBJECT,
>                 ACPI_UINT32_MAX, check_acpi_dev, NULL,
>                 (void *)ids, NULL);
> 
> It works, but it's not fantastic.

What exactly do you need that platform device for?

Thanks,
Rafael

Re: ACPI device without physical node (pnpacpi oddity?)

[Andy Lutomirski]

On Nov 30, 2015 5:41 PM, "Rafael J. Wysocki" <rjw@rjwysocki.net> wrote:
>
> On Monday, November 30, 2015 03:45:15 PM Andy Lutomirski wrote:
> > On Nov 30, 2015 2:40 PM, "Rafael J. Wysocki" <rjw@rjwysocki.net> wrote:
> > >
> > > On Monday, November 30, 2015 12:15:27 PM Andy Lutomirski wrote:
> > > > On Sun, Nov 29, 2015 at 9:19 PM, Andy Lutomirski <luto@amacapital.net> wrote:
> > >
> > > [cut]
> > >
> > > > > From inspection of the code, acpi_pnp.c determines that the device is
> > > > > a pnp device because pnp0c02 is in acpi_pnp_device_ids.  This causes
> > > > > the device to have a concrete handler, so no platform device is
> > > > > created.  However, pnpacpi/core.c rejects it because it has no _CRS
> > > > > method.  As a result, it's in limbo.
> > > > >
> > > > > What's the right thing to do here?  I could modify acpi_pnp.c to
> > > > > reject the device, which will let the generic platform fallback claim
> > > > > it.
> > >
> > > pnp0c02 is a special device ID.  It is defined by MS as "General ID for
> > > reserving resources required by PnP motherboard", so having no _CRS for
> > > that particular device ID doesn't really make sense.
> > >
> > > Moreover, we have a PNP driver that (normally) binds to that device ID,
> > > so a PNP device object should be created for it.
> >
> > Given that the pnpacpi driver is going to reject it anyway, it could
> > make sense to keep it from binding at all (and maybe warn?) so that
> > the platform fallback code picks it up, though.
>
> The point is that we'll create a PNP device for the same device ID on other
> platforms and that's going to be confusing, isn't it?
>
> I guess one option might be to hack the driver in question to accept a
> device without _CRS and then do what you need to be done for that device.
>

The driver being the one I'm writing or the pnpacpi driver?

Maybe I should ask the vendor if they're willing to drop the pnp0c02
cid.  This thing is an event-generating device, not a
resource-managing device.

> > >
> > > > > I could modify pnpacpi to accept the device despite the lack of
> > > > > _CRS, so a pnp device will be created.
> > >
> > > I'm not sure if that's going to work, you'd need to try it.
> > >
> > > The PNP layer is built around resources management, so the lack of resources
> > > to manage may uncover some dusty corners in it.
> > >
> > > > > I could bind directly as an
> > > > > ACPI driver (somewhat suboptimal because apparently that's frowned
> > > > > upon).
> > >
> > > The policy here is "avoid that if reasonably possible", but in this particular
> > > case there should be a PNP device.
> > >
> > > > > I could also write *both* an ACPI driver and platform driver
> > > > > and call acpi_create_platform_device from the ACPI driver, but that
> > > > > seems a bit ugly.
> > > > >
> > > > > Thoughts?
> > > >
> > > > If this is firmware bug (the ACPI spec suggests that _CRS may be
> > > > mandatory for non-natively-enumerable things like this), then there's
> > > > also a chance that the vendor will fix it.  On the other hand, maybe
> > > > this is already compliant and we should just interpret missing _CRS as
> > > > an empty set of resources.  (By inspection of the ASL, it really does
> > > > look like this thing has no resources beyond the ACPI methods in it.)
> > >
> > > OK, so it this in the context of the WMI bus type you're working on?
> >
> > Actually, no.  It's another magic pure ACPI device on the same laptop, though.
> >
> > My current draft has:
> >
> > /*
> >  * Unfortunately, some systems fail to enumerate our device as a
> >  * platform device.  Force the issue.
> >  */
> > static acpi_status __init
> > check_acpi_dev(acpi_handle handle, u32 lvl, void *context, void **rv)
> > {
> >     const struct acpi_device_id *ids = context;
> >     struct acpi_device *dev;
> >
> >     if (acpi_bus_get_device(handle, &dev) != 0)
> >         return AE_OK;
> >
> >     if (acpi_match_device_ids(dev, ids) == 0)
> >         if (acpi_create_platform_device(dev))
> >             dev_info(&dev->dev,
> >                  "created platform device\n");
> >
> >     return AE_OK;
> > }
> >
> > ...
> >
> >     acpi_walk_namespace(ACPI_TYPE_DEVICE, ACPI_ROOT_OBJECT,
> >                 ACPI_UINT32_MAX, check_acpi_dev, NULL,
> >                 (void *)ids, NULL);
> >
> > It works, but it's not fantastic.
>
> What exactly do you need that platform device for?

I want some kind of physical device to bind my driver to.  I probably
want suspend/resume callbacks, too.

--Andy

RE: ACPI device without physical node (pnpacpi oddity?)

[Zhang, Rui]

Hi, all,

The problem here is that the ACPI device node has
            Name (_HID, "INT33D5")  // _HID: Hardware ID
            Name (_CID, "PNP0C02" /* PNP Motherboard Resources */)  //
_CID: Compatible ID

Andy wants to write a driver for INT33D5 device, but unfortunately
1. _CID "PNP0C02" makes it impossible to bind via platform bus
2. Lacking of _CRS makes it impossible to bind via PNP bus.

I've seen similar problem before, and the solution is to ask BIOS people to remove the _CID "PNP0C02".
IMO, such AML code does not make sense at all (even if _CRS is provided), because in this case, the _CID and the _HID of the same ACPI device node actually represent two totally different devices.
OR, a clean way to fix this in Linux is to make the motherboard resource reservation stuff a function call instead of a driver, and invoke the function call in either PNP or ACPI bus code by checking "PNP0C02". In this case, only the device id that represents the physical device (INT33D5 in this case) can be used for device enumeration and driver probing.

Thanks,
rui

> -----Original Message-----
> From: linux-acpi-owner@vger.kernel.org [mailto:linux-acpi-
> owner@vger.kernel.org] On Behalf Of Andy Lutomirski
> Sent: Tuesday, December 01, 2015 10:23 AM
> To: Rafael J. Wysocki <rjw@rjwysocki.net>
> Cc: Linux ACPI <linux-acpi@vger.kernel.org>
> Subject: Re: ACPI device without physical node (pnpacpi oddity?)
> 
> On Nov 30, 2015 5:41 PM, "Rafael J. Wysocki" <rjw@rjwysocki.net> wrote:
> >
> > On Monday, November 30, 2015 03:45:15 PM Andy Lutomirski wrote:
> > > On Nov 30, 2015 2:40 PM, "Rafael J. Wysocki" <rjw@rjwysocki.net>
> wrote:
> > > >
> > > > On Monday, November 30, 2015 12:15:27 PM Andy Lutomirski wrote:
> > > > > On Sun, Nov 29, 2015 at 9:19 PM, Andy Lutomirski
> <luto@amacapital.net> wrote:
> > > >
> > > > [cut]
> > > >
> > > > > > From inspection of the code, acpi_pnp.c determines that the
> > > > > > device is a pnp device because pnp0c02 is in
> > > > > > acpi_pnp_device_ids.  This causes the device to have a
> > > > > > concrete handler, so no platform device is created.  However,
> > > > > > pnpacpi/core.c rejects it because it has no _CRS method.  As a
> result, it's in limbo.
> > > > > >
> > > > > > What's the right thing to do here?  I could modify acpi_pnp.c
> > > > > > to reject the device, which will let the generic platform
> > > > > > fallback claim it.
> > > >
> > > > pnp0c02 is a special device ID.  It is defined by MS as "General
> > > > ID for reserving resources required by PnP motherboard", so having
> > > > no _CRS for that particular device ID doesn't really make sense.
> > > >
> > > > Moreover, we have a PNP driver that (normally) binds to that
> > > > device ID, so a PNP device object should be created for it.
> > >
> > > Given that the pnpacpi driver is going to reject it anyway, it could
> > > make sense to keep it from binding at all (and maybe warn?) so that
> > > the platform fallback code picks it up, though.
> >
> > The point is that we'll create a PNP device for the same device ID on
> > other platforms and that's going to be confusing, isn't it?
> >
> > I guess one option might be to hack the driver in question to accept a
> > device without _CRS and then do what you need to be done for that
> device.
> >
> 
> The driver being the one I'm writing or the pnpacpi driver?
> 
> Maybe I should ask the vendor if they're willing to drop the pnp0c02 cid.  This
> thing is an event-generating device, not a resource-managing device.
> 
> > > >
> > > > > > I could modify pnpacpi to accept the device despite the lack
> > > > > > of _CRS, so a pnp device will be created.
> > > >
> > > > I'm not sure if that's going to work, you'd need to try it.
> > > >
> > > > The PNP layer is built around resources management, so the lack of
> > > > resources to manage may uncover some dusty corners in it.
> > > >
> > > > > > I could bind directly as an
> > > > > > ACPI driver (somewhat suboptimal because apparently that's
> > > > > > frowned upon).
> > > >
> > > > The policy here is "avoid that if reasonably possible", but in
> > > > this particular case there should be a PNP device.
> > > >
> > > > > > I could also write *both* an ACPI driver and platform driver
> > > > > > and call acpi_create_platform_device from the ACPI driver, but
> > > > > > that seems a bit ugly.
> > > > > >
> > > > > > Thoughts?
> > > > >
> > > > > If this is firmware bug (the ACPI spec suggests that _CRS may be
> > > > > mandatory for non-natively-enumerable things like this), then
> > > > > there's also a chance that the vendor will fix it.  On the other
> > > > > hand, maybe this is already compliant and we should just
> > > > > interpret missing _CRS as an empty set of resources.  (By
> > > > > inspection of the ASL, it really does look like this thing has
> > > > > no resources beyond the ACPI methods in it.)
> > > >
> > > > OK, so it this in the context of the WMI bus type you're working on?
> > >
> > > Actually, no.  It's another magic pure ACPI device on the same laptop,
> though.
> > >
> > > My current draft has:
> > >
> > > /*
> > >  * Unfortunately, some systems fail to enumerate our device as a
> > >  * platform device.  Force the issue.
> > >  */
> > > static acpi_status __init
> > > check_acpi_dev(acpi_handle handle, u32 lvl, void *context, void
> > > **rv) {
> > >     const struct acpi_device_id *ids = context;
> > >     struct acpi_device *dev;
> > >
> > >     if (acpi_bus_get_device(handle, &dev) != 0)
> > >         return AE_OK;
> > >
> > >     if (acpi_match_device_ids(dev, ids) == 0)
> > >         if (acpi_create_platform_device(dev))
> > >             dev_info(&dev->dev,
> > >                  "created platform device\n");
> > >
> > >     return AE_OK;
> > > }
> > >
> > > ...
> > >
> > >     acpi_walk_namespace(ACPI_TYPE_DEVICE, ACPI_ROOT_OBJECT,
> > >                 ACPI_UINT32_MAX, check_acpi_dev, NULL,
> > >                 (void *)ids, NULL);
> > >
> > > It works, but it's not fantastic.
> >
> > What exactly do you need that platform device for?
> 
> I want some kind of physical device to bind my driver to.  I probably want
> suspend/resume callbacks, too.
> 
> --Andy
> --
> To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the
> body of a message to majordomo@vger.kernel.org More majordomo info at
> http://vger.kernel.org/majordomo-info.html

Re: ACPI device without physical node (pnpacpi oddity?)

[Rafael J. Wysocki]

On Monday, November 30, 2015 06:23:26 PM Andy Lutomirski wrote:
> On Nov 30, 2015 5:41 PM, "Rafael J. Wysocki" <rjw@rjwysocki.net> wrote:
> >
> > On Monday, November 30, 2015 03:45:15 PM Andy Lutomirski wrote:
> > > On Nov 30, 2015 2:40 PM, "Rafael J. Wysocki" <rjw@rjwysocki.net> wrote:
> > > >
> > > > On Monday, November 30, 2015 12:15:27 PM Andy Lutomirski wrote:
> > > > > On Sun, Nov 29, 2015 at 9:19 PM, Andy Lutomirski <luto@amacapital.net> wrote:
> > > >
> > > > [cut]
> > > >
> > > > > > From inspection of the code, acpi_pnp.c determines that the device is
> > > > > > a pnp device because pnp0c02 is in acpi_pnp_device_ids.  This causes
> > > > > > the device to have a concrete handler, so no platform device is
> > > > > > created.  However, pnpacpi/core.c rejects it because it has no _CRS
> > > > > > method.  As a result, it's in limbo.
> > > > > >
> > > > > > What's the right thing to do here?  I could modify acpi_pnp.c to
> > > > > > reject the device, which will let the generic platform fallback claim
> > > > > > it.
> > > >
> > > > pnp0c02 is a special device ID.  It is defined by MS as "General ID for
> > > > reserving resources required by PnP motherboard", so having no _CRS for
> > > > that particular device ID doesn't really make sense.
> > > >
> > > > Moreover, we have a PNP driver that (normally) binds to that device ID,
> > > > so a PNP device object should be created for it.
> > >
> > > Given that the pnpacpi driver is going to reject it anyway, it could
> > > make sense to keep it from binding at all (and maybe warn?) so that
> > > the platform fallback code picks it up, though.
> >
> > The point is that we'll create a PNP device for the same device ID on other
> > platforms and that's going to be confusing, isn't it?
> >
> > I guess one option might be to hack the driver in question to accept a
> > device without _CRS and then do what you need to be done for that device.
> >
> 
> The driver being the one I'm writing or the pnpacpi driver?
> 
> Maybe I should ask the vendor if they're willing to drop the pnp0c02
> cid.  This thing is an event-generating device, not a
> resource-managing device.

[cut]

OK, I see what's the problem now.

> >
> > What exactly do you need that platform device for?
> 
> I want some kind of physical device to bind my driver to.  I probably
> want suspend/resume callbacks, too.

I see.

For your use case we could make the PNP layer ignore the pnp0c02 device id if
(a) _CRS is missing and (b) pnp0c02 is in the _CID list (not a _HID).

We have a deeper problem here, but let me discuss that with Rui.

Thanks,
Rafael

Re: ACPI device without physical node (pnpacpi oddity?)

[Andy Lutomirski]

On Tue, Dec 1, 2015 at 5:18 PM, Rafael J. Wysocki <rjw@rjwysocki.net> wrote:
> On Tuesday, December 01, 2015 03:25:41 AM Zhang, Rui wrote:
>> Hi, all,
>>
>> The problem here is that the ACPI device node has
>>             Name (_HID, "INT33D5")  // _HID: Hardware ID
>>             Name (_CID, "PNP0C02" /* PNP Motherboard Resources */)  //
>> _CID: Compatible ID
>>
>> Andy wants to write a driver for INT33D5 device, but unfortunately
>> 1. _CID "PNP0C02" makes it impossible to bind via platform bus
>> 2. Lacking of _CRS makes it impossible to bind via PNP bus.
>>
>> I've seen similar problem before, and the solution is to ask BIOS people to remove the _CID "PNP0C02".
>
> What if they refuse?
>
>> IMO, such AML code does not make sense at all (even if _CRS is provided), because in this case, the _CID and the _HID of the same ACPI device node actually represent two totally different devices.
>
> That's correct.  I guess this is a hack for Windows to prevent it from
> displaying "yellow bangs" for devices without "real" drivers.
>
>> OR, a clean way to fix this in Linux is to make the motherboard resource reservation stuff a function call instead of a driver, and invoke the function call in either PNP or ACPI bus code by checking "PNP0C02". In this case, only the device id that represents the physical device (INT33D5 in this case) can be used for device enumeration and driver probing.
>
> OK, but we need to keep the current ordering or there will be regressions in
> some odball configurations.
>
> What about walking (a) creating a list of things that have "PNP0C02" in their
> list of PNP IDs and (b) walking that list after we've completed the initial
> scan and reserving the resources for the ones that still have no drivers?
>

I'm not really sure how this can work.  The driver might be
demand-loaded (maybe even after we're done with initramfs) as a result
of a modalias.

Could we just change acpi_pnp_attach to return 0 for devices that have
HID != "PNP0C02" and don't have _CRS?

We could also consider something crazy like allowing ACPI platform
drivers (platform drivers with .acpi_match_table set) to bind pnp
devices.  I find it a bit odd that we have two different busses that
have non-natively-enumerable things that come from ACPI.

Or we could have a more general kind of driver interface that can bind
both platform and pnp devices.  (It should presumably bind any other
similar busses.)  It would match solely based on ACPI/OF data.

--Andy

Re: ACPI device without physical node (pnpacpi oddity?)

[Rafael J. Wysocki]

On Tuesday, December 01, 2015 03:25:41 AM Zhang, Rui wrote:
> Hi, all,
> 
> The problem here is that the ACPI device node has
>             Name (_HID, "INT33D5")  // _HID: Hardware ID
>             Name (_CID, "PNP0C02" /* PNP Motherboard Resources */)  //
> _CID: Compatible ID
> 
> Andy wants to write a driver for INT33D5 device, but unfortunately
> 1. _CID "PNP0C02" makes it impossible to bind via platform bus
> 2. Lacking of _CRS makes it impossible to bind via PNP bus.
> 
> I've seen similar problem before, and the solution is to ask BIOS people to remove the _CID "PNP0C02".

What if they refuse?

> IMO, such AML code does not make sense at all (even if _CRS is provided), because in this case, the _CID and the _HID of the same ACPI device node actually represent two totally different devices.

That's correct.  I guess this is a hack for Windows to prevent it from
displaying "yellow bangs" for devices without "real" drivers.

> OR, a clean way to fix this in Linux is to make the motherboard resource reservation stuff a function call instead of a driver, and invoke the function call in either PNP or ACPI bus code by checking "PNP0C02". In this case, only the device id that represents the physical device (INT33D5 in this case) can be used for device enumeration and driver probing.

OK, but we need to keep the current ordering or there will be regressions in
some odball configurations.

What about walking (a) creating a list of things that have "PNP0C02" in their
list of PNP IDs and (b) walking that list after we've completed the initial
scan and reserving the resources for the ones that still have no drivers?

That should preserve the current behavior at least, shouldn't it?

Thanks,
Rafael

Re: ACPI device without physical node (pnpacpi oddity?)

[Rafael J. Wysocki]

On Tuesday, December 01, 2015 05:04:33 PM Andy Lutomirski wrote:
> On Tue, Dec 1, 2015 at 5:18 PM, Rafael J. Wysocki <rjw@rjwysocki.net> wrote:
> > On Tuesday, December 01, 2015 03:25:41 AM Zhang, Rui wrote:
> >> Hi, all,
> >>
> >> The problem here is that the ACPI device node has
> >>             Name (_HID, "INT33D5")  // _HID: Hardware ID
> >>             Name (_CID, "PNP0C02" /* PNP Motherboard Resources */)  //
> >> _CID: Compatible ID
> >>
> >> Andy wants to write a driver for INT33D5 device, but unfortunately
> >> 1. _CID "PNP0C02" makes it impossible to bind via platform bus
> >> 2. Lacking of _CRS makes it impossible to bind via PNP bus.
> >>
> >> I've seen similar problem before, and the solution is to ask BIOS people to remove the _CID "PNP0C02".
> >
> > What if they refuse?
> >
> >> IMO, such AML code does not make sense at all (even if _CRS is provided), because in this case, the _CID and the _HID of the same ACPI device node actually represent two totally different devices.
> >
> > That's correct.  I guess this is a hack for Windows to prevent it from
> > displaying "yellow bangs" for devices without "real" drivers.
> >
> >> OR, a clean way to fix this in Linux is to make the motherboard resource reservation stuff a function call instead of a driver, and invoke the function call in either PNP or ACPI bus code by checking "PNP0C02". In this case, only the device id that represents the physical device (INT33D5 in this case) can be used for device enumeration and driver probing.
> >
> > OK, but we need to keep the current ordering or there will be regressions in
> > some odball configurations.
> >
> > What about walking (a) creating a list of things that have "PNP0C02" in their
> > list of PNP IDs and (b) walking that list after we've completed the initial
> > scan and reserving the resources for the ones that still have no drivers?
> >
> 
> I'm not really sure how this can work.  The driver might be
> demand-loaded (maybe even after we're done with initramfs) as a result
> of a modalias.
> 
> Could we just change acpi_pnp_attach to return 0 for devices that have
> HID != "PNP0C02" and don't have _CRS?

Yes, we could.  Didn't I say that in the other message?

> We could also consider something crazy like allowing ACPI platform
> drivers (platform drivers with .acpi_match_table set) to bind pnp
> devices.  I find it a bit odd that we have two different busses that
> have non-natively-enumerable things that come from ACPI.

Yeah.  The reason is that the PNP bus type was there before and we have
a bunch of drivers on it.  Plus it handles things that don't enumerate
through ACPI and some of them may enumerate via ACPI or non-ACPI.

> Or we could have a more general kind of driver interface that can bind
> both platform and pnp devices.  (It should presumably bind any other
> similar busses.)  It would match solely based on ACPI/OF data.

The rule should be that we always create the same type of a device (either
PNP or platform) for the same device ID.  Problem is if the device has
multiple IDs and some of them are in our list of "knon PNP device IDs"
and some of them aren't.

I'm tempted to guess that "PNP0C02" may be the only case here and therefore
I'm tempted to simply decide to ignore "PNP0C02" in *all* cases when it isn't
the device's _HID.  Because, honestly, the only reason to put "PNP0C02" into
a _CID list I can think about is to make Windows stop complaining about it.

Thanks,
Rafael

Re: ACPI device without physical node (pnpacpi oddity?)

[Zhang Rui]

On Wed, 2015-12-02 at 01:48 +0100, Rafael J. Wysocki wrote:
> On Monday, November 30, 2015 06:23:26 PM Andy Lutomirski wrote:
> > On Nov 30, 2015 5:41 PM, "Rafael J. Wysocki" <rjw@rjwysocki.net> wrote:
> > >
> > > On Monday, November 30, 2015 03:45:15 PM Andy Lutomirski wrote:
> > > > On Nov 30, 2015 2:40 PM, "Rafael J. Wysocki" <rjw@rjwysocki.net> wrote:
> > > > >
> > > > > On Monday, November 30, 2015 12:15:27 PM Andy Lutomirski wrote:
> > > > > > On Sun, Nov 29, 2015 at 9:19 PM, Andy Lutomirski <luto@amacapital.net> wrote:
> > > > >
> > > > > [cut]
> > > > >
> > > > > > > From inspection of the code, acpi_pnp.c determines that the device is
> > > > > > > a pnp device because pnp0c02 is in acpi_pnp_device_ids.  This causes
> > > > > > > the device to have a concrete handler, so no platform device is
> > > > > > > created.  However, pnpacpi/core.c rejects it because it has no _CRS
> > > > > > > method.  As a result, it's in limbo.
> > > > > > >
> > > > > > > What's the right thing to do here?  I could modify acpi_pnp.c to
> > > > > > > reject the device, which will let the generic platform fallback claim
> > > > > > > it.
> > > > >
> > > > > pnp0c02 is a special device ID.  It is defined by MS as "General ID for
> > > > > reserving resources required by PnP motherboard", so having no _CRS for
> > > > > that particular device ID doesn't really make sense.
> > > > >
> > > > > Moreover, we have a PNP driver that (normally) binds to that device ID,
> > > > > so a PNP device object should be created for it.
> > > >
> > > > Given that the pnpacpi driver is going to reject it anyway, it could
> > > > make sense to keep it from binding at all (and maybe warn?) so that
> > > > the platform fallback code picks it up, though.
> > >
> > > The point is that we'll create a PNP device for the same device ID on other
> > > platforms and that's going to be confusing, isn't it?
> > >
> > > I guess one option might be to hack the driver in question to accept a
> > > device without _CRS and then do what you need to be done for that device.
> > >
> > 
> > The driver being the one I'm writing or the pnpacpi driver?
> > 
> > Maybe I should ask the vendor if they're willing to drop the pnp0c02
> > cid.  This thing is an event-generating device, not a
> > resource-managing device.
> 
> [cut]
> 
> OK, I see what's the problem now.
> 
> > >
> > > What exactly do you need that platform device for?
> > 
> > I want some kind of physical device to bind my driver to.  I probably
> > want suspend/resume callbacks, too.
> 
> I see.
> 
> For your use case we could make the PNP layer ignore the pnp0c02 device id if
> (a) _CRS is missing and (b) pnp0c02 is in the _CID list (not a _HID).
> 
Yes, this could work.
But I'm concerning another case, say, a device with both _CRS and _CID
"PNP0C02", we don't have a way to probe the device via _HID.

thanks,
rui

Re: ACPI device without physical node (pnpacpi oddity?)

[Andy Lutomirski]

On Tue, Dec 1, 2015 at 6:00 PM, Zhang Rui <rui.zhang@intel.com> wrote:
> On Wed, 2015-12-02 at 01:48 +0100, Rafael J. Wysocki wrote:
>> For your use case we could make the PNP layer ignore the pnp0c02 device id if
>> (a) _CRS is missing and (b) pnp0c02 is in the _CID list (not a _HID).
>>
> Yes, this could work.
> But I'm concerning another case, say, a device with both _CRS and _CID
> "PNP0C02", we don't have a way to probe the device via _HID.

Doesn't .acpi_match_table do exactly this?

--Andy

Re: ACPI device without physical node (pnpacpi oddity?)

[Zhang Rui]

On Wed, 2015-12-02 at 02:18 +0100, Rafael J. Wysocki wrote:
> On Tuesday, December 01, 2015 03:25:41 AM Zhang, Rui wrote:
> > Hi, all,
> > 
> > The problem here is that the ACPI device node has
> >             Name (_HID, "INT33D5")  // _HID: Hardware ID
> >             Name (_CID, "PNP0C02" /* PNP Motherboard Resources */)  //
> > _CID: Compatible ID
> > 
> > Andy wants to write a driver for INT33D5 device, but unfortunately
> > 1. _CID "PNP0C02" makes it impossible to bind via platform bus
> > 2. Lacking of _CRS makes it impossible to bind via PNP bus.
> > 
> > I've seen similar problem before, and the solution is to ask BIOS people to remove the _CID "PNP0C02".
> 
> What if they refuse?

Well, we don't have a kernel solution for this case so far.
> 
> > IMO, such AML code does not make sense at all (even if _CRS is provided), because in this case, the _CID and the _HID of the same ACPI device node actually represent two totally different devices.
> 
> That's correct.  I guess this is a hack for Windows to prevent it from
> displaying "yellow bangs" for devices without "real" drivers.

Does this mean that the Windows "PNP0C02" driver won't prevent any other
driver from probing its devices?
> 
> > OR, a clean way to fix this in Linux is to make the motherboard resource reservation stuff a function call instead of a driver, and invoke the function call in either PNP or ACPI bus code by checking "PNP0C02". In this case, only the device id that represents the physical device (INT33D5 in this case) can be used for device enumeration and driver probing.
> 
> OK, but we need to keep the current ordering or there will be regressions in
> some odball configurations.
> 
> What about walking (a) creating a list of things that have "PNP0C02" in their
> list of PNP IDs and (b) walking that list after we've completed the initial
> scan and reserving the resources for the ones that still have no drivers?
> 
hmmm, first of all, a question, say, for a device have _CID "PNP0C02"
and _HID, if we want to bind the _HID, what should we do?
should we reserve the resources before loading the _HID driver, and free
the resources after unloading the _HID driver?
or should we always reserve such resources, no matter if the _HID driver
is loaded or not?

If it is the latter one, then IMO, we can use a scan handler to reserve
the resources, before all the other handlers.
If it is the first one, then it's much more complex, because what we
want is to make "PNP0C02" resource reservation work as a "shadow"
driver, which only takes effect when there is no other driver binded.

thanks,
rui
> That should preserve the current behavior at least, shouldn't it?
> 
> Thanks,
> Rafael
> 

Re: ACPI device without physical node (pnpacpi oddity?)

[Zhang Rui]

On Tue, 2015-12-01 at 18:03 -0800, Andy Lutomirski wrote:
> On Tue, Dec 1, 2015 at 6:00 PM, Zhang Rui <rui.zhang@intel.com> wrote:
> > On Wed, 2015-12-02 at 01:48 +0100, Rafael J. Wysocki wrote:
> >> For your use case we could make the PNP layer ignore the pnp0c02 device id if
> >> (a) _CRS is missing and (b) pnp0c02 is in the _CID list (not a _HID).
> >>
> > Yes, this could work.
> > But I'm concerning another case, say, a device with both _CRS and _CID
> > "PNP0C02", we don't have a way to probe the device via _HID.
> 
> Doesn't .acpi_match_table do exactly this?
> 
I mean, even if _CRS is available, the device will be bound to the PNP
system driver (drivers/pnp/system.c) forever, thus you still cannot
write a new driver to probe INT33D5.

thanks,
rui

Re: ACPI device without physical node (pnpacpi oddity?)

[Rafael J. Wysocki]

On Wednesday, December 02, 2015 10:34:44 AM Zhang Rui wrote:
> On Wed, 2015-12-02 at 02:18 +0100, Rafael J. Wysocki wrote:
> > On Tuesday, December 01, 2015 03:25:41 AM Zhang, Rui wrote:
> > > Hi, all,
> > > 
> > > The problem here is that the ACPI device node has
> > >             Name (_HID, "INT33D5")  // _HID: Hardware ID
> > >             Name (_CID, "PNP0C02" /* PNP Motherboard Resources */)  //
> > > _CID: Compatible ID
> > > 
> > > Andy wants to write a driver for INT33D5 device, but unfortunately
> > > 1. _CID "PNP0C02" makes it impossible to bind via platform bus
> > > 2. Lacking of _CRS makes it impossible to bind via PNP bus.
> > > 
> > > I've seen similar problem before, and the solution is to ask BIOS people to remove the _CID "PNP0C02".
> > 
> > What if they refuse?
> 
> Well, we don't have a kernel solution for this case so far.
> > 
> > > IMO, such AML code does not make sense at all (even if _CRS is provided), because in this case, the _CID and the _HID of the same ACPI device node actually represent two totally different devices.
> > 
> > That's correct.  I guess this is a hack for Windows to prevent it from
> > displaying "yellow bangs" for devices without "real" drivers.
> 
> Does this mean that the Windows "PNP0C02" driver won't prevent any other
> driver from probing its devices?
> > 
> > > OR, a clean way to fix this in Linux is to make the motherboard resource reservation stuff a function call instead of a driver, and invoke the function call in either PNP or ACPI bus code by checking "PNP0C02". In this case, only the device id that represents the physical device (INT33D5 in this case) can be used for device enumeration and driver probing.
> > 
> > OK, but we need to keep the current ordering or there will be regressions in
> > some odball configurations.
> > 
> > What about walking (a) creating a list of things that have "PNP0C02" in their
> > list of PNP IDs and (b) walking that list after we've completed the initial
> > scan and reserving the resources for the ones that still have no drivers?
> > 
> hmmm, first of all, a question, say, for a device have _CID "PNP0C02"
> and _HID, if we want to bind the _HID, what should we do?
> should we reserve the resources before loading the _HID driver, and free
> the resources after unloading the _HID driver?

No, we shouldn't.  Handling the resources is up to the driver then.

> or should we always reserve such resources, no matter if the _HID driver
> is loaded or not?

We shoudln't do that too.

Basically, the rule is that compatible IDs only should take effect if
there's no driver for the _HID.

We handle that correctly in the majority of cases, but we have a problem
specifically related to the PNP vs platform device creation.  Namely,
(as I said in one of the previous messages) if the device has multiple IDs
and some of them are "known PNP IDs", it will trigger the PNP scan handler,
because the platform device creation is the "if nothing else works" thing.

That said I *think* that having "PNP0C02" as a _CID is just a Windows hack
and nothing else, so presumably we can simply ignore that specific device ID
if it is not the _HID.  Because honestly, what does it mean to be compatbile
with "motherboard resources"?

So why don't we add a special case for "PNP0C02" to simply skip adding it
to the list of PNP IDs unless it is returned by _HID?

Thanks,
Rafael

Re: ACPI device without physical node (pnpacpi oddity?)

[Rafael J. Wysocki]

On Tuesday, December 01, 2015 06:03:31 PM Andy Lutomirski wrote:
> On Tue, Dec 1, 2015 at 6:00 PM, Zhang Rui <rui.zhang@intel.com> wrote:
> > On Wed, 2015-12-02 at 01:48 +0100, Rafael J. Wysocki wrote:
> >> For your use case we could make the PNP layer ignore the pnp0c02 device id if
> >> (a) _CRS is missing and (b) pnp0c02 is in the _CID list (not a _HID).
> >>
> > Yes, this could work.
> > But I'm concerning another case, say, a device with both _CRS and _CID
> > "PNP0C02", we don't have a way to probe the device via _HID.
> 
> Doesn't .acpi_match_table do exactly this?

It does, but then we'll create a PNP device which isn't going to be handled
by a platform driver.

So (as I said before) we need to ensure that we'll consistently create the
same type of a device for the given device ID every time we see it.

Thanks,
Rafael

Re: ACPI device without physical node (pnpacpi oddity?)

[Rafael J. Wysocki]

On Wednesday, December 02, 2015 01:22:16 PM Rafael J. Wysocki wrote:
> On Wednesday, December 02, 2015 10:34:44 AM Zhang Rui wrote:
> > On Wed, 2015-12-02 at 02:18 +0100, Rafael J. Wysocki wrote:
> > > On Tuesday, December 01, 2015 03:25:41 AM Zhang, Rui wrote:
> > > > Hi, all,
> > > > 
> > > > The problem here is that the ACPI device node has
> > > >             Name (_HID, "INT33D5")  // _HID: Hardware ID
> > > >             Name (_CID, "PNP0C02" /* PNP Motherboard Resources */)  //
> > > > _CID: Compatible ID
> > > > 
> > > > Andy wants to write a driver for INT33D5 device, but unfortunately
> > > > 1. _CID "PNP0C02" makes it impossible to bind via platform bus
> > > > 2. Lacking of _CRS makes it impossible to bind via PNP bus.
> > > > 
> > > > I've seen similar problem before, and the solution is to ask BIOS people to remove the _CID "PNP0C02".
> > > 
> > > What if they refuse?
> > 
> > Well, we don't have a kernel solution for this case so far.
> > > 
> > > > IMO, such AML code does not make sense at all (even if _CRS is provided), because in this case, the _CID and the _HID of the same ACPI device node actually represent two totally different devices.
> > > 
> > > That's correct.  I guess this is a hack for Windows to prevent it from
> > > displaying "yellow bangs" for devices without "real" drivers.
> > 
> > Does this mean that the Windows "PNP0C02" driver won't prevent any other
> > driver from probing its devices?
> > > 
> > > > OR, a clean way to fix this in Linux is to make the motherboard resource reservation stuff a function call instead of a driver, and invoke the function call in either PNP or ACPI bus code by checking "PNP0C02". In this case, only the device id that represents the physical device (INT33D5 in this case) can be used for device enumeration and driver probing.
> > > 
> > > OK, but we need to keep the current ordering or there will be regressions in
> > > some odball configurations.
> > > 
> > > What about walking (a) creating a list of things that have "PNP0C02" in their
> > > list of PNP IDs and (b) walking that list after we've completed the initial
> > > scan and reserving the resources for the ones that still have no drivers?
> > > 
> > hmmm, first of all, a question, say, for a device have _CID "PNP0C02"
> > and _HID, if we want to bind the _HID, what should we do?
> > should we reserve the resources before loading the _HID driver, and free
> > the resources after unloading the _HID driver?
> 
> No, we shouldn't.  Handling the resources is up to the driver then.

Actually, scratch that.

We should register IO and memory resources for everything with _CRS to prevent
them from being allocated to something else (and possibly use _PRS/_SRS if
available to resolve conflicts).

If we do that, we won't need the special driver for "PNP0C02" at all.

Thanks,
Rafael

Re: ACPI device without physical node (pnpacpi oddity?)

[Zhang Rui]

On Wed, 2015-12-02 at 13:22 +0100, Rafael J. Wysocki wrote:
> On Wednesday, December 02, 2015 10:34:44 AM Zhang Rui wrote:
> > On Wed, 2015-12-02 at 02:18 +0100, Rafael J. Wysocki wrote:
> > > On Tuesday, December 01, 2015 03:25:41 AM Zhang, Rui wrote:
> > > > Hi, all,
> > > > 
> > > > The problem here is that the ACPI device node has
> > > >             Name (_HID, "INT33D5")  // _HID: Hardware ID
> > > >             Name (_CID, "PNP0C02" /* PNP Motherboard Resources */)  //
> > > > _CID: Compatible ID
> > > > 
> > > > Andy wants to write a driver for INT33D5 device, but unfortunately
> > > > 1. _CID "PNP0C02" makes it impossible to bind via platform bus
> > > > 2. Lacking of _CRS makes it impossible to bind via PNP bus.
> > > > 
> > > > I've seen similar problem before, and the solution is to ask BIOS people to remove the _CID "PNP0C02".
> > > 
> > > What if they refuse?
> > 
> > Well, we don't have a kernel solution for this case so far.
> > > 
> > > > IMO, such AML code does not make sense at all (even if _CRS is provided), because in this case, the _CID and the _HID of the same ACPI device node actually represent two totally different devices.
> > > 
> > > That's correct.  I guess this is a hack for Windows to prevent it from
> > > displaying "yellow bangs" for devices without "real" drivers.
> > 
> > Does this mean that the Windows "PNP0C02" driver won't prevent any other
> > driver from probing its devices?
> > > 
> > > > OR, a clean way to fix this in Linux is to make the motherboard resource reservation stuff a function call instead of a driver, and invoke the function call in either PNP or ACPI bus code by checking "PNP0C02". In this case, only the device id that represents the physical device (INT33D5 in this case) can be used for device enumeration and driver probing.
> > > 
> > > OK, but we need to keep the current ordering or there will be regressions in
> > > some odball configurations.
> > > 
> > > What about walking (a) creating a list of things that have "PNP0C02" in their
> > > list of PNP IDs and (b) walking that list after we've completed the initial
> > > scan and reserving the resources for the ones that still have no drivers?
> > > 
> > hmmm, first of all, a question, say, for a device have _CID "PNP0C02"
> > and _HID, if we want to bind the _HID, what should we do?
> > should we reserve the resources before loading the _HID driver, and free
> > the resources after unloading the _HID driver?
> 
> No, we shouldn't.  Handling the resources is up to the driver then.
> 
> > or should we always reserve such resources, no matter if the _HID driver
> > is loaded or not?
> 
> We shoudln't do that too.
> 
> Basically, the rule is that compatible IDs only should take effect if
> there's no driver for the _HID.
> 

> We handle that correctly in the majority of cases, but we have a problem
> specifically related to the PNP vs platform device creation.  Namely,
> (as I said in one of the previous messages) if the device has multiple IDs
> and some of them are "known PNP IDs", it will trigger the PNP scan handler,
> because the platform device creation is the "if nothing else works" thing.
> 
> That said I *think* that having "PNP0C02" as a _CID is just a Windows hack
> and nothing else, so presumably we can simply ignore that specific device ID
> if it is not the _HID.  Because honestly, what does it mean to be compatbile
> with "motherboard resources"?
> 
By saying "ignore that specific device ID", do you mean we should do
nothing for _CID "PNP0C02", or we should reserve the resources if there
is no driver for _HID?

thanks,
rui
> So why don't we add a special case for "PNP0C02" to simply skip adding it
> to the list of PNP IDs unless it is returned by _HID?
> 
> Thanks,
> Rafael
> 

Re: ACPI device without physical node (pnpacpi oddity?)

[Rafael J. Wysocki]

On Thursday, December 03, 2015 07:25:02 AM Zhang Rui wrote:
> On Wed, 2015-12-02 at 13:22 +0100, Rafael J. Wysocki wrote:
> > On Wednesday, December 02, 2015 10:34:44 AM Zhang Rui wrote:
> > > On Wed, 2015-12-02 at 02:18 +0100, Rafael J. Wysocki wrote:
> > > > On Tuesday, December 01, 2015 03:25:41 AM Zhang, Rui wrote:
> > > > > Hi, all,
> > > > > 
> > > > > The problem here is that the ACPI device node has
> > > > >             Name (_HID, "INT33D5")  // _HID: Hardware ID
> > > > >             Name (_CID, "PNP0C02" /* PNP Motherboard Resources */)  //
> > > > > _CID: Compatible ID
> > > > > 
> > > > > Andy wants to write a driver for INT33D5 device, but unfortunately
> > > > > 1. _CID "PNP0C02" makes it impossible to bind via platform bus
> > > > > 2. Lacking of _CRS makes it impossible to bind via PNP bus.
> > > > > 
> > > > > I've seen similar problem before, and the solution is to ask BIOS people to remove the _CID "PNP0C02".
> > > > 
> > > > What if they refuse?
> > > 
> > > Well, we don't have a kernel solution for this case so far.
> > > > 
> > > > > IMO, such AML code does not make sense at all (even if _CRS is provided), because in this case, the _CID and the _HID of the same ACPI device node actually represent two totally different devices.
> > > > 
> > > > That's correct.  I guess this is a hack for Windows to prevent it from
> > > > displaying "yellow bangs" for devices without "real" drivers.
> > > 
> > > Does this mean that the Windows "PNP0C02" driver won't prevent any other
> > > driver from probing its devices?
> > > > 
> > > > > OR, a clean way to fix this in Linux is to make the motherboard resource reservation stuff a function call instead of a driver, and invoke the function call in either PNP or ACPI bus code by checking "PNP0C02". In this case, only the device id that represents the physical device (INT33D5 in this case) can be used for device enumeration and driver probing.
> > > > 
> > > > OK, but we need to keep the current ordering or there will be regressions in
> > > > some odball configurations.
> > > > 
> > > > What about walking (a) creating a list of things that have "PNP0C02" in their
> > > > list of PNP IDs and (b) walking that list after we've completed the initial
> > > > scan and reserving the resources for the ones that still have no drivers?
> > > > 
> > > hmmm, first of all, a question, say, for a device have _CID "PNP0C02"
> > > and _HID, if we want to bind the _HID, what should we do?
> > > should we reserve the resources before loading the _HID driver, and free
> > > the resources after unloading the _HID driver?
> > 
> > No, we shouldn't.  Handling the resources is up to the driver then.
> > 
> > > or should we always reserve such resources, no matter if the _HID driver
> > > is loaded or not?
> > 
> > We shoudln't do that too.
> > 
> > Basically, the rule is that compatible IDs only should take effect if
> > there's no driver for the _HID.
> > 
> 
> > We handle that correctly in the majority of cases, but we have a problem
> > specifically related to the PNP vs platform device creation.  Namely,
> > (as I said in one of the previous messages) if the device has multiple IDs
> > and some of them are "known PNP IDs", it will trigger the PNP scan handler,
> > because the platform device creation is the "if nothing else works" thing.
> > 
> > That said I *think* that having "PNP0C02" as a _CID is just a Windows hack
> > and nothing else, so presumably we can simply ignore that specific device ID
> > if it is not the _HID.  Because honestly, what does it mean to be compatbile
> > with "motherboard resources"?
> > 
> By saying "ignore that specific device ID", do you mean we should do
> nothing for _CID "PNP0C02", or we should reserve the resources if there
> is no driver for _HID?
> 
> thanks,
> rui
> > So why don't we add a special case for "PNP0C02" to simply skip adding it
> > to the list of PNP IDs unless it is returned by _HID?

Exactly as I said in the above sentence. :-)

That said, I think that long term we should register all IO and memory
resources (possibly combining them if they form a contiguous range together
etc) from every _CRS we can find.

Thanks,
Rafael