problem with attaching device to LPC bus
Sepherosa Ziehau
sepherosa at gmail.com
Wed Aug 24 18:50:09 PDT 2016
I have pushed a slightly different one to the master; it should fix
this problem too. Please test.
Thanks,
sephe
On Thu, Aug 25, 2016 at 9:24 AM, Sepherosa Ziehau <sepherosa at gmail.com> wrote:
> On Thu, Aug 25, 2016 at 2:43 AM, karu.pruun <karu.pruun at gmail.com> wrote:
>> Yay, it works!
>>
>> # kldload ./gmux_off_acpi.ko
>>
>> gives:
>> gmux_off_acpi0: <apple gmux controller> port 0x700-0x7fe on acpi0
>
> Grrr, this looks a bit weird, probably should be 0x700~0x7ff :). Let
> me check the acpi spec, and update the patch, stay tuned.
>
>>
>> And the dmesg does not contain the unsupported range message any more.
>>
>> Will you commit this to master?
>>
>> Many thanks again!
>>
>> Peeter
>>
>> --
>>
>>
>>
>>
>> On Wed, Aug 24, 2016 at 11:22 AM, Sepherosa Ziehau <sepherosa at gmail.com>
>> wrote:
>>>
>>> Try this patch:
>>> https://leaf.dragonflybsd.org/~sephe/acpi_iorange.diff
>>>
>>> On Wed, Aug 24, 2016 at 4:16 PM, Veiko Palge <veiko.palge at 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 <sepherosa at 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.pruun at 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
>>
>>
>
>
>
> --
> Tomorrow Will Never Die
--
Tomorrow Will Never Die
More information about the Kernel
mailing list