Hi,
Shaohua Li wrote:
On Wed, 2005-08-03 at 23:16 +0200, matthieu castet wrote:
There are drivers/acpi/motherboard.c that done some stuff already handle
by pnp/system.c.
Yes, it should be disabled if pnpacpi is enabled.
But even if pnpacpi is disabled, pnp/system.c sould work with pnpbios.
Bjorn Helgaas wrote:
On Thursday 04 August 2005 6:38 am, matthieu castet wrote:
Bjorn Helgaas wrote:
On Wednesday 03 August 2005 3:16 pm, matthieu castet wrote:
Bjorn Helgaas wrote:
drivers/char/hpet.c
This probably should be converted to PNP. I'll
On Thursday 04 August 2005 6:38 am, matthieu castet wrote:
> Bjorn Helgaas wrote:
> > On Wednesday 03 August 2005 3:16 pm, matthieu castet wrote:
> >>Bjorn Helgaas wrote:
> >> > drivers/char/hpet.c
> >> > This probably should be converted to PNP. I'll
> >> > look into doing this
Hi,
Bjorn Helgaas wrote:
On Wednesday 03 August 2005 3:16 pm, matthieu castet wrote:
Bjorn Helgaas wrote:
>drivers/char/hpet.c
>This probably should be converted to PNP. I'll
>look into doing this.
IIRC, I am not sure that the pnp layer was able to pass the 64 bits
Hi Bjorn,
Thank you very much for the new patch
and I'm very sorry for troubling you.
The patch looks very good to me.
Thanks,
Kenji Kaneshige
Bjorn Helgaas wrote:
On Tuesday 02 August 2005 7:05 pm, Kenji Kaneshige wrote:
This breaks the following patch that is already included into -mm
tr
On Wed, 2005-08-03 at 23:16 +0200, matthieu castet wrote:
>
> There are drivers/acpi/motherboard.c that done some stuff already handle
> by pnp/system.c.
Yes, it should be disabled if pnpacpi is enabled. The only concern is
motherboard.c also request some ACPI resources, which might not declaim
i
On Wed, 2005-08-03 at 09:20 -0600, Bjorn Helgaas wrote:
> On Tuesday 02 August 2005 7:01 pm, Shaohua Li wrote:
> > On Tue, 2005-08-02 at 09:55 -0600, Bjorn Helgaas wrote:
> > > Any objections to the patch below? I posted it last Wednesday,
> > > but haven't heard anything. Once we have this fix,
On Wednesday 03 August 2005 3:16 pm, matthieu castet wrote:
> Bjorn Helgaas wrote:
> > On Tuesday 02 August 2005 7:01 pm, Shaohua Li wrote:
> >>Did you have plan to remove other
> >>legacy acpi drivers?
> > No, I didn't -- which ones are you thinking about? Looking at
> > the callers of acpi_
Hi,
Bjorn Helgaas wrote:
> On Tuesday 02 August 2005 7:01 pm, Shaohua Li wrote:
>
>
>>Did you have plan to remove other
>>legacy acpi drivers?
>
>
> No, I didn't -- which ones are you thinking about? Looking at
> the callers of acpi_bus_register_driver(), I see:
looking for METHOD_NAME__CRS is
On Tuesday 02 August 2005 7:05 pm, Kenji Kaneshige wrote:
> This breaks the following patch that is already included into -mm
> tree.
>
> http://sourceforge.net/mailarchive/forum.php?thread_id=7844247&forum_id=6102
>
> I think we need to check if acpi_register_gsi() succeeded or not.
You're abso
On Tuesday 02 August 2005 7:01 pm, Shaohua Li wrote:
> On Tue, 2005-08-02 at 09:55 -0600, Bjorn Helgaas wrote:
> > Any objections to the patch below? I posted it last Wednesday,
> > but haven't heard anything. Once we have this fix, 8250_pnp
> > should have sufficient functionality that we can ge
Hi Bjorn,
static void
-pnpacpi_parse_allocated_irqresource(struct pnp_resource_table * res, int irq)
+pnpacpi_parse_allocated_irqresource(struct pnp_resource_table * res, u32 irq)
{
int i = 0;
while (!(res->irq_resource[i].flags & IORESOURCE_UNSET) &&
@@ -85,13 +85,13 @@
On Tue, 2005-08-02 at 09:55 -0600, Bjorn Helgaas wrote:
> Any objections to the patch below? I posted it last Wednesday,
> but haven't heard anything. Once we have this fix, 8250_pnp
> should have sufficient functionality that we can get rid of
> 8250_acpi.
>
>
>
> Use types that match the ACP
Any objections to the patch below? I posted it last Wednesday,
but haven't heard anything. Once we have this fix, 8250_pnp
should have sufficient functionality that we can get rid of
8250_acpi.
Use types that match the ACPI resource structures. Previously
the u64 value from an RSTYPE_ADDRESS6
14 matches
Mail list logo
