From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-ej1-f52.google.com (mail-ej1-f52.google.com [209.85.218.52]) by mx.groups.io with SMTP id smtpd.web10.8488.1626555606771162644 for ; Sat, 17 Jul 2021 14:00:07 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@gmail.com header.s=20161025 header.b=mYaHaEPN; spf=pass (domain: gmail.com, ip: 209.85.218.52, mailfrom: harlydavidsen@gmail.com) Received: by mail-ej1-f52.google.com with SMTP id gb6so20878539ejc.5 for ; Sat, 17 Jul 2021 14:00:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=qr8QesFJARdQeSBHnOvlBSckzBaeHL7Z6YK5uwEp9kI=; b=mYaHaEPN2paKLUL5v8TpiDUudXLlWWQ4FEqVeKxybRqzk54uU+QAMUwlLz4S7DqUwz gewre9v1ytZM3Hn4eeF85kEf5+IROUGvAVP4rxK2bZton8/1jiSTD0+1E7OORi//gyA1 nfg7rNxCmr1sFYvn1u4PKSXhWt+jJKz5tPmJVN4jW+gIc1RC3uL0rNbu/sS6U3I/JErR fXfZpzXJ0W+AD9MUEGaXAGwruZE101xyglF10Vir11ATARscpsP6jkj4l/loZasSEAM7 2XixHr2wqwitEtDGpXmVqJjcmkkJ2QUTGqRSm6Kv7X4nhae28A6Bziepec4q6wNZUSP9 nnDQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=qr8QesFJARdQeSBHnOvlBSckzBaeHL7Z6YK5uwEp9kI=; b=MvGvBzFRWL2xRYfgnM465dIOnAu5MliSi/MPLdtCl/Yt/Cw7K01opIhpDMWt1gEZ6/ 5AaKDFV9GpOP0JplJGZAHHtQIofE3ofKa+ENgnhywALJNYk+cX1IqDIc9t4R0TnwQZ8P wPMc9smeuwOM1VE+YPbwO65liYRYKdWw71Lcp6okzl3e2jiyicW9klDdZzUKCeljQRDd oURVuogzdJvJyWsDjw1gr6fhzxYHPlSAGWI1f6XGbF+SvhWJwcNL/HbiIlbUlZYB6Ut1 NPz/wjNKCXtloQJzPu1xSiuix2cPT6BYdaSmzNn5AgV+YmCHiV1orkUweCsSOT/QVXz4 iKUA== X-Gm-Message-State: AOAM5323VguYDlrq+o6hoRRqOI77dJzby0covtXQdFtuIcpvsCZBIck5 g9Zg2Ift1MULMgPfZeivcvf5nOJAhRXrd9gm4OI= X-Google-Smtp-Source: ABdhPJwuw6ulPPKZ1AVVoELH7c4wLTjDfSS88lp8QDy+5O/Ng+9jxU+fpIRNSJUgHG9uBwGfsdvoX50vblk9AGd5mIo= X-Received: by 2002:a17:907:10cc:: with SMTP id rv12mr18954586ejb.339.1626555605255; Sat, 17 Jul 2021 14:00:05 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a50:3f89:0:0:0:0:0 with HTTP; Sat, 17 Jul 2021 14:00:04 -0700 (PDT) In-Reply-To: <200C48C1-A7E4-4076-9042-CB62EE3F997A@apple.com> References: <88AE4AB4-12BA-433C-9EA4-EDC01B30DAD1@apple.com> <08756DA4-26D7-4EB9-9E36-0AD739E3B05C@apple.com> <200C48C1-A7E4-4076-9042-CB62EE3F997A@apple.com> From: "Ethin Probst" Date: Sat, 17 Jul 2021 16:00:04 -0500 Message-ID: Subject: Re: [edk2-devel] OpenProtocol() giving me EFI_INVALID_PARAMETER To: Andrew Fish Cc: edk2-devel-groups-io , "Leif Lindholm (Nuvia address)" , Ray Ni Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Tried this and I still get that invalid handle. Definitely confused where that's coming from. On 7/17/21, Andrew Fish wrote: > If I `OvmfPkg/builds.sh qemu -usb -device usb-audio -device qemu-xhci` I= see > 2 USB handle? > > When you open EXCLUSIVE you are kicking other people off the handles. I= =E2=80=99m > not sure that is a good idea for you to do that to every USB handle in t= he > system. If there was a handle that represented a USB to USB bridge seems > like you could kick all the children off=E2=80=A6. > > So when you are probing try using GET_PROTOCOL, and only use EXCLUSIVE a= fter > you find the device you want to manage. > > Thanks, > > Andrew Fish > >> On Jul 17, 2021, at 11:10 AM, Ethin Probst >> wrote: >> >> Thanks, Andrew. So it appears as though only a single handle exists >> ("AF: DevicePath(..)/Pci(0x1D,0x0)/USB(0x0,0x0)) USBIO") but my app is >> getting two handles, one of which doesn't actually exist. I still am >> unsure why though. Getting verbose info about handle AF yields an >> interface with class 0x01, subclass 0x01, and protocol 0x04, so this >> appears to match the USB audio control interface. However, no audio >> streaming device is available, as I would expect. Attempting to set >> the interface to `1` also fails on the UAC device (though the USB >> specification does note that this is not necessarily an error and may >> just indicate that that interface setting is not supported so my app >> currently just continues on regardless). I am running with qemu args >> `-usb -device usb-audio,... -audiodev ...`. I've tried with `-device >> qemu-xhci ...` but I get the same result. >> >> On 7/17/21, Andrew Fish > wrot= e: >>> >>> >>>> On Jul 17, 2021, at 10:06 AM, Ethin Probst >>>> wrote: >>>> >>>> Okay, so I just tried dh -v 7EDE4C18 (that was the handle that I'm >>>> getting from `HandleBuffer()`) and it says "dh: Handle - '7EDE4C18' >>>> not found". So I'm definitely confused because that's what >>>> `HandleBuffer()` is getting me. Should I pre-allocate the buffer? >>>> >>> >>> Ethin, >>> >>> The UEFI Shell `dh` command UI uses handle numbers from 0 - N as hex >>> digits. You have use these abstract values with the `dh` command. For >>> example: use `dh -v A1` to see the actual handle value for A1 >>> (7EBA9598). >>> You can search handles that contain a specific protocol... >>> >>> Shell> dh -p PciIo >>> Handle dump by protocol 'PCIIO' >>> A1: PCIIO DevicePath(PciRoot(0x0)/Pci(0x0,0x0)) >>> A2: PCIIO DevicePath(PciRoot(0x0)/Pci(0x1,0x0)) >>> A3: PCIIO DevicePath(PciRoot(0x0)/Pci(0x2,0x0)) >>> A4: PCIIO DevicePath(..0)/Pci(0x2,0x0)/Pci(0x0,0x0)) >>> A5: PCIIO DevicePath(..0)/Pci(0x2,0x0)/Pci(0x1,0x0)) >>> A6: PCIIO DevicePath(..0)/Pci(0x2,0x0)/Pci(0x2,0x0)) >>> A7: PCIIO DevicePath(..0)/Pci(0x2,0x0)/Pci(0x3,0x0)) >>> A8: PCIIO DevicePath(..0)/Pci(0x2,0x0)/Pci(0x4,0x0)) >>> A9: PCIIO DevicePath(..0)/Pci(0x2,0x0)/Pci(0x5,0x0)) >>> AA: PCIIO DevicePath(PciRoot(0x0)/Pci(0x1E,0x0)) >>> AB: DiskIO BlockIO FA920010-6785-4941-B6EC-498C579F160A PCIIO >>> DevicePath(..)/Pci(0x1E,0x0)/Pci(0x0,0x0)) >>> AC: ISAACPI PCIIO DevicePath(PciRoot(0x0)/Pci(0x1F,0x0)) >>> AD: PCIIO DevicePath(PciRoot(0x0)/Pci(0x1F,0x3)) >>> Shell> dh -v A1 >>> A1: 7EBA9598 >>> PCIIO(7EBA8AA8) >>> Segment #.....: 00 >>> Bus #.........: 00 >>> Device #......: 00 >>> Function #....: 00 >>> ROM Size......: 0 >>> ROM Location..: 00000000 >>> Vendor ID.....: 8086 >>> Device ID.....: 29C0 >>> Class Code....: 00 00 06 >>> Configuration Header : >>> 8680C029070000000000000600000000 >>> 00000000000000000000000000000000 >>> 000000000000000000000000F41A0011 >>> 000000000000000000000000FF000000 >>> DevicePath(7EBA9E18) >>> PciRoot(0x0)/Pci(0x0,0x0) >>> >>> Thanks, >>> >>> Andrew Fish >>> >>>> On 7/17/21, Ethin Probst wrote: >>>>> I mean, possible... The code I'm using to initialize the handle buff= er >>>>> is >>>>> this: >>>>> >>>>> ```C >>>>> EFI_STATUS EFIAPI UefiMain(IN EFI_HANDLE imageHandle, IN >>>>> EFI_SYSTEM_TABLE* >>>>> st) { >>>>> Print(L"Attempting to find USB IO protocol\n"); >>>>> UINTN numHandles =3D 0; >>>>> UINTN i =3D 0; >>>>> UINT32 UsbStatus =3D 0; >>>>> EFI_HANDLE* handles =3D NULL; >>>>> EFI_USB_IO_PROTOCOL* UsbIo =3D NULL; >>>>> EFI_STATUS status =3D st->BootServices->LocateHandleBuffer(ByProtoco= l, >>>>> &gEfiUsbIoProtocolGuid, NULL, &numHandles, &handles); >>>>> if (EFI_ERROR(status)) { >>>>> Print(L"Cannot find any handles for USB devices, reason: %r\n", >>>>> status); >>>>> return EFI_ABORTED; >>>>> } >>>>> Print(L"Found %d USB devices; enumerating\n", numHandles); >>>>> for (; i < numHandles; ++i) { >>>>> Print(L"Trying to open handle %d (%x)... ", i, handles[i]); >>>>> status =3D st->BootServices->OpenProtocol(handles[i], >>>>> &gEfiUsbIoProtocolGuid, (void**)&UsbIo, imageHandle, NULL, >>>>> EFI_OPEN_PROTOCOL_EXCLUSIVE); >>>>> if (EFI_ERROR(status)) { >>>>> Print(L"%r, skipping\n", status); >>>>> continue; >>>>> } >>>>> // ... >>>>> ``` >>>>> I've done my best to follow SEI secure C coding standards, like >>>>> initializing all variables, regardless of type -- e.g. initializing >>>>> pointers to 0/NULL. But I will definitely try that idea. >>>>> >>>>> On 7/17/21, Andrew Fish wrote: >>>>>> >>>>>> >>>>>>> On Jul 17, 2021, at 9:41 AM, Ethin Probst >>>>>>> wrote: >>>>>>> >>>>>>> Hey all, >>>>>>> >>>>>>> So my UsbAudio.efi app has hit a bit of a roadblock. This code: >>>>>>> >>>>>>> ```C >>>>>>> status =3D st->BootServices->OpenProtocol(handles[i], >>>>>>> &gEfiUsbIoProtocolGuid, (void**)&UsbIo, imageHandle, NULL, >>>>>>> EFI_OPEN_PROTOCOL_EXCLUSIVE); >>>>>>> if (EFI_ERROR(status)) { >>>>>>> Print(L"%r, skipping\n", status); >>>>>>> continue; >>>>>>> } >>>>>>> ``` >>>>>> >>>>>> How are you constructing handle[]? Could it have gotten stale? You >>>>>> could >>>>>> print out the value of handle[I] on the failure. >>>>>> >>>>>> The contents of a handle are not defined, but the current >>>>>> implementation >>>>>> is >>>>>> a pointer to an IHANDLE internal data structure in the DXE Core. If >>>>>> you >>>>>> are >>>>>> at the UEFI Shell and you `dh -v it will show the >>>>>> >>>>>> and the value. >>>>>> >>>>>> Shell> dh -v 98 >>>>>> 98: 6d5CF18 >>>>>> =E2=80=A6. >>>>>> >>>>>> I think you can `dh -p UsbIo=E2=80=99 to get the list of the UsbIo = handles. >>>>>> >>>>>> So you can poke around and see what is happening on that handle. >>>>>> >>>>>> I guess the handle[] array could be getting corrupted? So you could >>>>>> check >>>>>> for that? >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Andrew Fish >>>>>> >>>>>>> Is giving me EFI_INVALID_PARAMETER and I don=E2=80=99t know why. I= don't >>>>>>> think >>>>>>> I'm violating any of its constraints, according to the >>>>>>> specification, >>>>>>> and I haven't touched this code since it was written. It also >>>>>>> happens >>>>>>> irregularly: sometimes it happens on the USB audio streaming devic= e, >>>>>>> or if I have a device plugged in it might happen on that device, y= ou >>>>>>> get the idea. But it doesn't consistently fail. Does anybody have >>>>>>> any >>>>>>> idea what's going on? >>>>>>> >>>>>>> -- >>>>>>> Signed, >>>>>>> Ethin D. Probst >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> Signed, >>>>> Ethin D. Probst >>>>> >>>> >>>> >>>> -- >>>> Signed, >>>> Ethin D. Probst >>>> >>>> >>>> >>>> >>>> >>> >>> >> >> >> -- >> Signed, >> Ethin D. Probst >> >> >>=20 > > --=20 Signed, Ethin D. Probst