<div dir="ltr"><div><div><div>Tested with 9ed6fc but the result is the same: 0x0700-0x07fe. <br><br></div>I ran a quick test with linux too, where cat /proc/ioports | grep gmux shows: <br><br></div>0700 - 07fd : Apple gmux<br><br></div><div>Interesting. . .<br><br></div><div>Cheers<br><br></div><div>Peeter<br><br>--<br><br></div><div><br></div><div><div><br><br></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Aug 25, 2016 at 4:50 AM, Sepherosa Ziehau <span dir="ltr"><<a href="mailto:sepherosa@gmail.com" target="_blank">sepherosa@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I have pushed a slightly different one to the master; it should fix<br>
this problem too.  Please test.<br>
<br>
Thanks,<br>
sephe<br>
<div class="HOEnZb"><div class="h5"><br>
On Thu, Aug 25, 2016 at 9:24 AM, Sepherosa Ziehau <<a href="mailto:sepherosa@gmail.com">sepherosa@gmail.com</a>> wrote:<br>
> On Thu, Aug 25, 2016 at 2:43 AM, karu.pruun <<a href="mailto:karu.pruun@gmail.com">karu.pruun@gmail.com</a>> wrote:<br>
>> Yay, it works!<br>
>><br>
>> # kldload ./gmux_off_acpi.ko<br>
>><br>
>> gives:<br>
>> gmux_off_acpi0: <apple gmux controller> port 0x700-0x7fe on acpi0<br>
><br>
> Grrr, this looks a bit weird, probably should be 0x700~0x7ff :).  Let<br>
> me check the acpi spec, and update the patch, stay tuned.<br>
><br>
>><br>
>> And the dmesg does not contain the unsupported range message any more.<br>
>><br>
>> Will you commit this to master?<br>
>><br>
>> Many thanks again!<br>
>><br>
>> Peeter<br>
>><br>
>> --<br>
>><br>
>><br>
>><br>
>><br>
>> On Wed, Aug 24, 2016 at 11:22 AM, Sepherosa Ziehau <<a href="mailto:sepherosa@gmail.com">sepherosa@gmail.com</a>><br>
>> wrote:<br>
>>><br>
>>> Try this patch:<br>
>>> <a href="https://leaf.dragonflybsd.org/~sephe/acpi_iorange.diff" rel="noreferrer" target="_blank">https://leaf.dragonflybsd.org/<wbr>~sephe/acpi_iorange.diff</a><br>
>>><br>
>>> On Wed, Aug 24, 2016 at 4:16 PM, Veiko Palge <<a href="mailto:veiko.palge@gmail.com">veiko.palge@gmail.com</a>><br>
>>> wrote:<br>
>>> > dmesg attached --- yes, there is one:<br>
>>> ><br>
>>> > unknown: I/O range not supported<br>
>>> ><br>
>>> > I should also mention that I am not loading the driver at boot time; I<br>
>>> > do kldload and kldunload after boot.<br>
>>> ><br>
>>> ><br>
>>> > Peeter<br>
>>> ><br>
>>> > --<br>
>>> ><br>
>>> ><br>
>>> > On 24 August 2016 at 11:06, Sepherosa Ziehau <<a href="mailto:sepherosa@gmail.com">sepherosa@gmail.com</a>><br>
>>> > wrote:<br>
>>> >> Did you get any "I/O range not supported" in your dmesg?<br>
>>> >><br>
>>> >> Thanks,<br>
>>> >> sephe<br>
>>> >><br>
>>> >> On Tue, Aug 23, 2016 at 9:23 PM, karu.pruun <<a href="mailto:karu.pruun@gmail.com">karu.pruun@gmail.com</a>><br>
>>> >> wrote:<br>
>>> >>> Hello<br>
>>> >>><br>
>>> >>> This is a newbie question: I am trying to write a simple DragonFly<br>
>>> >>> kernel<br>
>>> >>> module for the gmux device that is attached to the LPC bus. Probing<br>
>>> >>> works<br>
>>> >>> fine but I am stuck with the attachment routine: I can't allocate IO<br>
>>> >>> ports<br>
>>> >>> for the device.<br>
>>> >>><br>
>>> >>> The device shows up in the device tree but is not attached:<br>
>>> >>><br>
>>> >>> ---<br>
>>> >>> # devinfo -rv | grep GMUX:<br>
>>> >>><br>
>>> >>> unknown pnpinfo _HID=APP000B _UID=0 at handle=\_SB_.PCI0.LPCB.GMUX<br>
>>> >>> ---<br>
>>> >>><br>
>>> >>> I looked up acpi tables (acpidump etc), the IO resources for GMUX seem<br>
>>> >>> to be<br>
>>> >>> there:<br>
>>> >>><br>
>>> >>> --- ---<br>
>>> >>>     Scope (\_SB.PCI0.LPCB)<br>
>>> >>>     {<br>
>>> >>>         Device (GMUX)<br>
>>> >>>         {<br>
>>> >>>             Name (_HID, EisaId ("APP000B"))  // _HID: Hardware ID<br>
>>> >>>             Name (_CID, "gmux")  // _CID: Compatible ID<br>
>>> >>>             Name (_STA, 0x0B)  // _STA: Status<br>
>>> >>>             Name (_CRS, ResourceTemplate ()  // _CRS: Current Resource<br>
>>> >>> Settings<br>
>>> >>>             {<br>
>>> >>>                 IO (Decode16,<br>
>>> >>>                     0x0700,             // Range Minimum<br>
>>> >>>                     0x07FF,             // Range Maximum<br>
>>> >>>                     0x01,               // Alignment<br>
>>> >>>                     0xFF,               // Length<br>
>>> >>>                     )<br>
>>> >>>             })<br>
>>> >>> --- ---<br>
>>> >>><br>
>>> >>> Also, looking devinfo -rv shows that the range 0x0700 to 0x07FF has<br>
>>> >>> been set<br>
>>> >>> aside by the kernel:<br>
>>> >>><br>
>>> >>> ---<br>
>>> >>> # devinfo -u<br>
>>> >>><br>
>>> >>> . . .<br>
>>> >>> I/O ports:<br>
>>> >>>     . . .<br>
>>> >>>     0x400 - 0x1fff (root0)<br>
>>> >>>     . . .<br>
>>> >>> ---<br>
>>> >>><br>
>>> >>> So am I right supposing that bus_alloc_resource_any should be able to<br>
>>> >>> claim<br>
>>> >>> the range 0x700 to 0x7FF for the gmux device? At the moment, trying to<br>
>>> >>> allocate IO ports with bus_alloc_resource returns NULL.<br>
>>> >>><br>
>>> >>> I wonder if anyone has suggestions about what has gone wrong or where<br>
>>> >>> to dig<br>
>>> >>> further? I attach the code.<br>
>>> >>><br>
>>> >>> Thanks<br>
>>> >>><br>
>>> >>> Peeter<br>
>>> >>><br>
>>> >>> --<br>
>>> >>><br>
>>> >><br>
>>> >><br>
>>> >><br>
>>> >> --<br>
>>> >> Tomorrow Will Never Die<br>
>>><br>
>>><br>
>>><br>
>>> --<br>
>>> Tomorrow Will Never Die<br>
>><br>
>><br>
><br>
><br>
><br>
> --<br>
> Tomorrow Will Never Die<br>
<br>
<br>
<br>
--<br>
Tomorrow Will Never Die<br>
</div></div></blockquote></div><br></div>