bug-hurd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [RFC PATCH hurd] pci: Add RPCs for taking and freeing io ports by BA


From: Samuel Thibault
Subject: Re: [RFC PATCH hurd] pci: Add RPCs for taking and freeing io ports by BAR
Date: Mon, 17 Jul 2023 10:47:34 +0200
User-agent: NeoMutt/20170609 (1.8.3)

Hello,

Thanks for working on this :)

Damien Zammit, le sam. 15 juil. 2023 16:09:57 +0000, a ecrit:
> +/*
> + * Request io ports for BAR 0-5 for a given device.
> + * Only works on bars that correspond to IO ports.
> + */
> +routine pci_take_io_ports(
> +     master: pci_t;
> +     bar: int
> +);

> @@ -273,3 +274,69 @@ S_pci_get_dev_rom (struct protid * master, char **data, 
> mach_msg_type_number_t *
>  
>    return 0;
>  }
> +
> +error_t
> +toggle_io_ports (struct pcifs_dirent *e, int bar, int turn_on)
> +{
> +  uint16_t iobase, iosize;
> +
> +  if ((bar < 0) || (bar > 5))
> +    return EINVAL;
> +
> +  if (!e->device->regions[bar].is_IO)
> +    /* This operation only works on IO bars */
> +    return EINVAL;
> +
> +  iobase = e->device->regions[bar].base_addr;
> +  iosize = e->device->regions[bar].size;
> +
> +  if (!ioperm(iobase, iobase + iosize - 1, turn_on))

? It's not pci-arbiter which needs to enable access to the I/O
ports on its own mach task. We probably need to make it call
i386_io_perm_create and return the port to the caller, so the caller can
call i386_io_perm_modify at will.

Samuel



reply via email to

[Prev in Thread] Current Thread [Next in Thread]