Try this patch:
https://leaf.dragonflybsd.org/~sephe/acpi_iorange.diff
On Wed, Aug 24, 2016 at 4:16 PM, Veiko Palge <veiko.pa...@gmail.com> wrote:
> dmesg attached --- yes, there is one:
>
> unknown: I/O range not supported
>
> I should also mention that I am not loading the driver at boot time; I
> do kldload and kldunload after boot.
>
>
> Peeter
>
> --
>
>
> On 24 August 2016 at 11:06, Sepherosa Ziehau <sepher...@gmail.com> wrote:
>> Did you get any "I/O range not supported" in your dmesg?
>>
>> Thanks,
>> sephe
>>
>> On Tue, Aug 23, 2016 at 9:23 PM, karu.pruun <karu.pr...@gmail.com> wrote:
>>> Hello
>>>
>>> This is a newbie question: I am trying to write a simple DragonFly kernel
>>> module for the gmux device that is attached to the LPC bus. Probing works
>>> fine but I am stuck with the attachment routine: I can't allocate IO ports
>>> for the device.
>>>
>>> The device shows up in the device tree but is not attached:
>>>
>>> ---
>>> # devinfo -rv | grep GMUX:
>>>
>>> unknown pnpinfo _HID=APP000B _UID=0 at handle=\_SB_.PCI0.LPCB.GMUX
>>> ---
>>>
>>> I looked up acpi tables (acpidump etc), the IO resources for GMUX seem to be
>>> there:
>>>
>>> --- ---
>>> Scope (\_SB.PCI0.LPCB)
>>> {
>>> Device (GMUX)
>>> {
>>> Name (_HID, EisaId ("APP000B")) // _HID: Hardware ID
>>> Name (_CID, "gmux") // _CID: Compatible ID
>>> Name (_STA, 0x0B) // _STA: Status
>>> Name (_CRS, ResourceTemplate () // _CRS: Current Resource
>>> Settings
>>> {
>>> IO (Decode16,
>>> 0x0700, // Range Minimum
>>> 0x07FF, // Range Maximum
>>> 0x01, // Alignment
>>> 0xFF, // Length
>>> )
>>> })
>>> --- ---
>>>
>>> Also, looking devinfo -rv shows that the range 0x0700 to 0x07FF has been set
>>> aside by the kernel:
>>>
>>> ---
>>> # devinfo -u
>>>
>>> . . .
>>> I/O ports:
>>> . . .
>>> 0x400 - 0x1fff (root0)
>>> . . .
>>> ---
>>>
>>> So am I right supposing that bus_alloc_resource_any should be able to claim
>>> the range 0x700 to 0x7FF for the gmux device? At the moment, trying to
>>> allocate IO ports with bus_alloc_resource returns NULL.
>>>
>>> I wonder if anyone has suggestions about what has gone wrong or where to dig
>>> further? I attach the code.
>>>
>>> Thanks
>>>
>>> Peeter
>>>
>>> --
>>>
>>
>>
>>
>> --
>> Tomorrow Will Never Die
--
Tomorrow Will Never Die
