All of lore.kernel.org
 help / color / mirror / Atom feed
From: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
To: Damien Le Moal <dlemoal@kernel.org>
Cc: "Lorenzo Pieralisi" <lpieralisi@kernel.org>,
	"Kishon Vijay Abraham I" <kishon@kernel.org>,
	"Shawn Lin" <shawn.lin@rock-chips.com>,
	"Krzysztof Wilczyński" <kw@linux.com>,
	"Bjorn Helgaas" <bhelgaas@google.com>,
	"Heiko Stuebner" <heiko@sntech.de>,
	linux-pci@vger.kernel.org, "Rob Herring" <robh@kernel.org>,
	"Krzysztof Kozlowski" <krzysztof.kozlowski+dt@linaro.org>,
	"Conor Dooley" <conor+dt@kernel.org>,
	devicetree@vger.kernel.org, linux-rockchip@lists.infradead.org,
	linux-arm-kernel@lists.infradead.org,
	"Rick Wertenbroek" <rick.wertenbroek@gmail.com>,
	"Wilfred Mallawa" <wilfred.mallawa@wdc.com>,
	"Niklas Cassel" <cassel@kernel.org>
Subject: Re: [PATCH v2 03/18] PCI: endpoint: Introduce pci_epc_mem_map()/unmap()
Date: Wed, 3 Apr 2024 15:18:40 +0530	[thread overview]
Message-ID: <20240403094840.GI25309@thinkpad> (raw)
In-Reply-To: <20240330041928.1555578-4-dlemoal@kernel.org>

On Sat, Mar 30, 2024 at 01:19:13PM +0900, Damien Le Moal wrote:
> Introduce the function pci_epc_mem_map() to facilitate controller memory
> address allocation and mapping to a RC PCI address region in endpoint
> function drivers.
> 
> This function first uses pci_epc_map_align() to determine the controller
> memory address alignment (offset and size) constraints. The result of
> this function is used to allocate a controller physical memory region
> using pci_epc_mem_alloc_addr() and map it to the RC PCI address
> space with pci_epc_map_addr(). Since pci_epc_map_align() may indicate
> that a mapping can be smaller than the requested size, pci_epc_mem_map()
> may only partially map the RC PCI address region specified and return
> a smaller size for the effective mapping.
> 
> The counterpart of pci_epc_mem_map() to unmap and free the controller
> memory address region is pci_epc_mem_unmap().
> 
> Both functions operate using struct pci_epc_map data structure which is
> extended to contain the physical and virtual addresses of the allocated
> controller memory. Endpoint function drivers can use struct pci_epc_map
> to implement read/write accesses within the mapped RC PCI address region
> using the ->virt_addr and ->size fields.
> 
> This commit contains contributions from Rick Wertenbroek
> <rick.wertenbroek@gmail.com>.
> 

Adding 'Co-developed-by && Signed-off-by' tags would give the due credit.

> Signed-off-by: Damien Le Moal <dlemoal@kernel.org>
> ---
>  drivers/pci/endpoint/pci-epc-core.c | 68 +++++++++++++++++++++++++++++
>  include/linux/pci-epc.h             |  6 +++
>  2 files changed, 74 insertions(+)
> 
> diff --git a/drivers/pci/endpoint/pci-epc-core.c b/drivers/pci/endpoint/pci-epc-core.c
> index 37758ca91d7f..0095b54bdf9e 100644
> --- a/drivers/pci/endpoint/pci-epc-core.c
> +++ b/drivers/pci/endpoint/pci-epc-core.c
> @@ -530,6 +530,74 @@ int pci_epc_map_addr(struct pci_epc *epc, u8 func_no, u8 vfunc_no,
>  }
>  EXPORT_SYMBOL_GPL(pci_epc_map_addr);
>  
> +/**
> + * pci_epc_mem_map() - allocate and map CPU address to PCI address

How about, 'pci_epc_alloc_map()'? I think the 'mem' prefix was added to the
existing APIs since the function definitions are in pci-epc-mem driver, but
not needed here.

> + * @epc: the EPC device on which the CPU address is to be allocated and mapped
> + * @func_no: the physical endpoint function number in the EPC device
> + * @vfunc_no: the virtual endpoint function number in the physical function
> + * @pci_addr: PCI address to which the CPU address should be mapped
> + * @size: the number of bytes to map starting from @pci_addr
> + * @map: where to return the mapping information
> + *
> + * Allocate a controller physical address region and map it to a RC PCI address

"Allocate an EPC address space region..."

> + * region, taking into account the controller physical address mapping
> + * constraints (if any). Returns the effective size of the mapping, which may

Return value should be specified separately for Kdoc.

> + * be less than @size, or a negative error code in case of error.
> + */
> +ssize_t pci_epc_mem_map(struct pci_epc *epc, u8 func_no, u8 vfunc_no,
> +			u64 pci_addr, size_t size, struct pci_epc_map *map)
> +{
> +	int ret;
> +
> +	ret = pci_epc_map_align(epc, func_no, vfunc_no, pci_addr, size, map);
> +	if (ret)
> +		return ret;
> +
> +	map->virt_base = pci_epc_mem_alloc_addr(epc, &map->phys_base,
> +						map->map_size);

It'd be nice to move pci_epc_map_align() inside the existing
pci_epc_mem_alloc_addr() API to make sure that the allocated memory follows the
constraints of the EPC.

Would that make sense?

- Mani

> +	if (!map->virt_base)
> +		return -ENOMEM;
> +
> +	map->phys_addr = map->phys_base + map->map_ofst;
> +	map->virt_addr = map->virt_base + map->map_ofst;
> +
> +	ret = pci_epc_map_addr(epc, func_no, vfunc_no, map->phys_base,
> +			       map->map_pci_addr, map->map_size);
> +	if (ret) {
> +		pci_epc_mem_free_addr(epc, map->phys_base, map->virt_base,
> +				      map->map_size);
> +		return ret;
> +	}
> +
> +	return map->pci_size;
> +}
> +EXPORT_SYMBOL_GPL(pci_epc_mem_map);
> +
> +/**
> + * pci_epc_mem_unmap() - unmap from PCI address and free a CPU address region
> + * @epc: the EPC device on which the CPU address is allocated and mapped
> + * @func_no: the physical endpoint function number in the EPC device
> + * @vfunc_no: the virtual endpoint function number in the physical function
> + * @map: the mapping information
> + *
> + * Allocate and map local CPU address to a PCI address, accounting for the
> + * controller local CPU address alignment constraints.
> + */
> +void pci_epc_mem_unmap(struct pci_epc *epc, u8 func_no, u8 vfunc_no,
> +		       struct pci_epc_map *map)
> +{
> +	if (!pci_epc_function_is_valid(epc, func_no, vfunc_no))
> +		return;
> +
> +	if (!map || !map->pci_size)
> +		return;
> +
> +	pci_epc_unmap_addr(epc, func_no, vfunc_no, map->phys_base);
> +	pci_epc_mem_free_addr(epc, map->phys_base, map->virt_base,
> +			      map->map_size);
> +}
> +EXPORT_SYMBOL_GPL(pci_epc_mem_unmap);
> +
>  /**
>   * pci_epc_clear_bar() - reset the BAR
>   * @epc: the EPC device for which the BAR has to be cleared
> diff --git a/include/linux/pci-epc.h b/include/linux/pci-epc.h
> index 8cfb4aaf2628..86397a500b54 100644
> --- a/include/linux/pci-epc.h
> +++ b/include/linux/pci-epc.h
> @@ -304,4 +304,10 @@ void __iomem *pci_epc_mem_alloc_addr(struct pci_epc *epc,
>  				     phys_addr_t *phys_addr, size_t size);
>  void pci_epc_mem_free_addr(struct pci_epc *epc, phys_addr_t phys_addr,
>  			   void __iomem *virt_addr, size_t size);
> +
> +ssize_t pci_epc_mem_map(struct pci_epc *epc, u8 func_no, u8 vfunc_no,
> +			u64 pci_addr, size_t size, struct pci_epc_map *map);
> +void pci_epc_mem_unmap(struct pci_epc *epc, u8 func_no, u8 vfunc_no,
> +		       struct pci_epc_map *map);
> +
>  #endif /* __LINUX_PCI_EPC_H */
> -- 
> 2.44.0
> 

-- 
மணிவண்ணன் சதாசிவம்

WARNING: multiple messages have this Message-ID (diff)
From: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
To: Damien Le Moal <dlemoal@kernel.org>
Cc: "Lorenzo Pieralisi" <lpieralisi@kernel.org>,
	"Kishon Vijay Abraham I" <kishon@kernel.org>,
	"Shawn Lin" <shawn.lin@rock-chips.com>,
	"Krzysztof Wilczyński" <kw@linux.com>,
	"Bjorn Helgaas" <bhelgaas@google.com>,
	"Heiko Stuebner" <heiko@sntech.de>,
	linux-pci@vger.kernel.org, "Rob Herring" <robh@kernel.org>,
	"Krzysztof Kozlowski" <krzysztof.kozlowski+dt@linaro.org>,
	"Conor Dooley" <conor+dt@kernel.org>,
	devicetree@vger.kernel.org, linux-rockchip@lists.infradead.org,
	linux-arm-kernel@lists.infradead.org,
	"Rick Wertenbroek" <rick.wertenbroek@gmail.com>,
	"Wilfred Mallawa" <wilfred.mallawa@wdc.com>,
	"Niklas Cassel" <cassel@kernel.org>
Subject: Re: [PATCH v2 03/18] PCI: endpoint: Introduce pci_epc_mem_map()/unmap()
Date: Wed, 3 Apr 2024 15:18:40 +0530	[thread overview]
Message-ID: <20240403094840.GI25309@thinkpad> (raw)
In-Reply-To: <20240330041928.1555578-4-dlemoal@kernel.org>

On Sat, Mar 30, 2024 at 01:19:13PM +0900, Damien Le Moal wrote:
> Introduce the function pci_epc_mem_map() to facilitate controller memory
> address allocation and mapping to a RC PCI address region in endpoint
> function drivers.
> 
> This function first uses pci_epc_map_align() to determine the controller
> memory address alignment (offset and size) constraints. The result of
> this function is used to allocate a controller physical memory region
> using pci_epc_mem_alloc_addr() and map it to the RC PCI address
> space with pci_epc_map_addr(). Since pci_epc_map_align() may indicate
> that a mapping can be smaller than the requested size, pci_epc_mem_map()
> may only partially map the RC PCI address region specified and return
> a smaller size for the effective mapping.
> 
> The counterpart of pci_epc_mem_map() to unmap and free the controller
> memory address region is pci_epc_mem_unmap().
> 
> Both functions operate using struct pci_epc_map data structure which is
> extended to contain the physical and virtual addresses of the allocated
> controller memory. Endpoint function drivers can use struct pci_epc_map
> to implement read/write accesses within the mapped RC PCI address region
> using the ->virt_addr and ->size fields.
> 
> This commit contains contributions from Rick Wertenbroek
> <rick.wertenbroek@gmail.com>.
> 

Adding 'Co-developed-by && Signed-off-by' tags would give the due credit.

> Signed-off-by: Damien Le Moal <dlemoal@kernel.org>
> ---
>  drivers/pci/endpoint/pci-epc-core.c | 68 +++++++++++++++++++++++++++++
>  include/linux/pci-epc.h             |  6 +++
>  2 files changed, 74 insertions(+)
> 
> diff --git a/drivers/pci/endpoint/pci-epc-core.c b/drivers/pci/endpoint/pci-epc-core.c
> index 37758ca91d7f..0095b54bdf9e 100644
> --- a/drivers/pci/endpoint/pci-epc-core.c
> +++ b/drivers/pci/endpoint/pci-epc-core.c
> @@ -530,6 +530,74 @@ int pci_epc_map_addr(struct pci_epc *epc, u8 func_no, u8 vfunc_no,
>  }
>  EXPORT_SYMBOL_GPL(pci_epc_map_addr);
>  
> +/**
> + * pci_epc_mem_map() - allocate and map CPU address to PCI address

How about, 'pci_epc_alloc_map()'? I think the 'mem' prefix was added to the
existing APIs since the function definitions are in pci-epc-mem driver, but
not needed here.

> + * @epc: the EPC device on which the CPU address is to be allocated and mapped
> + * @func_no: the physical endpoint function number in the EPC device
> + * @vfunc_no: the virtual endpoint function number in the physical function
> + * @pci_addr: PCI address to which the CPU address should be mapped
> + * @size: the number of bytes to map starting from @pci_addr
> + * @map: where to return the mapping information
> + *
> + * Allocate a controller physical address region and map it to a RC PCI address

"Allocate an EPC address space region..."

> + * region, taking into account the controller physical address mapping
> + * constraints (if any). Returns the effective size of the mapping, which may

Return value should be specified separately for Kdoc.

> + * be less than @size, or a negative error code in case of error.
> + */
> +ssize_t pci_epc_mem_map(struct pci_epc *epc, u8 func_no, u8 vfunc_no,
> +			u64 pci_addr, size_t size, struct pci_epc_map *map)
> +{
> +	int ret;
> +
> +	ret = pci_epc_map_align(epc, func_no, vfunc_no, pci_addr, size, map);
> +	if (ret)
> +		return ret;
> +
> +	map->virt_base = pci_epc_mem_alloc_addr(epc, &map->phys_base,
> +						map->map_size);

It'd be nice to move pci_epc_map_align() inside the existing
pci_epc_mem_alloc_addr() API to make sure that the allocated memory follows the
constraints of the EPC.

Would that make sense?

- Mani

> +	if (!map->virt_base)
> +		return -ENOMEM;
> +
> +	map->phys_addr = map->phys_base + map->map_ofst;
> +	map->virt_addr = map->virt_base + map->map_ofst;
> +
> +	ret = pci_epc_map_addr(epc, func_no, vfunc_no, map->phys_base,
> +			       map->map_pci_addr, map->map_size);
> +	if (ret) {
> +		pci_epc_mem_free_addr(epc, map->phys_base, map->virt_base,
> +				      map->map_size);
> +		return ret;
> +	}
> +
> +	return map->pci_size;
> +}
> +EXPORT_SYMBOL_GPL(pci_epc_mem_map);
> +
> +/**
> + * pci_epc_mem_unmap() - unmap from PCI address and free a CPU address region
> + * @epc: the EPC device on which the CPU address is allocated and mapped
> + * @func_no: the physical endpoint function number in the EPC device
> + * @vfunc_no: the virtual endpoint function number in the physical function
> + * @map: the mapping information
> + *
> + * Allocate and map local CPU address to a PCI address, accounting for the
> + * controller local CPU address alignment constraints.
> + */
> +void pci_epc_mem_unmap(struct pci_epc *epc, u8 func_no, u8 vfunc_no,
> +		       struct pci_epc_map *map)
> +{
> +	if (!pci_epc_function_is_valid(epc, func_no, vfunc_no))
> +		return;
> +
> +	if (!map || !map->pci_size)
> +		return;
> +
> +	pci_epc_unmap_addr(epc, func_no, vfunc_no, map->phys_base);
> +	pci_epc_mem_free_addr(epc, map->phys_base, map->virt_base,
> +			      map->map_size);
> +}
> +EXPORT_SYMBOL_GPL(pci_epc_mem_unmap);
> +
>  /**
>   * pci_epc_clear_bar() - reset the BAR
>   * @epc: the EPC device for which the BAR has to be cleared
> diff --git a/include/linux/pci-epc.h b/include/linux/pci-epc.h
> index 8cfb4aaf2628..86397a500b54 100644
> --- a/include/linux/pci-epc.h
> +++ b/include/linux/pci-epc.h
> @@ -304,4 +304,10 @@ void __iomem *pci_epc_mem_alloc_addr(struct pci_epc *epc,
>  				     phys_addr_t *phys_addr, size_t size);
>  void pci_epc_mem_free_addr(struct pci_epc *epc, phys_addr_t phys_addr,
>  			   void __iomem *virt_addr, size_t size);
> +
> +ssize_t pci_epc_mem_map(struct pci_epc *epc, u8 func_no, u8 vfunc_no,
> +			u64 pci_addr, size_t size, struct pci_epc_map *map);
> +void pci_epc_mem_unmap(struct pci_epc *epc, u8 func_no, u8 vfunc_no,
> +		       struct pci_epc_map *map);
> +
>  #endif /* __LINUX_PCI_EPC_H */
> -- 
> 2.44.0
> 

-- 
மணிவண்ணன் சதாசிவம்

_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip

WARNING: multiple messages have this Message-ID (diff)
From: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
To: Damien Le Moal <dlemoal@kernel.org>
Cc: "Lorenzo Pieralisi" <lpieralisi@kernel.org>,
	"Kishon Vijay Abraham I" <kishon@kernel.org>,
	"Shawn Lin" <shawn.lin@rock-chips.com>,
	"Krzysztof Wilczyński" <kw@linux.com>,
	"Bjorn Helgaas" <bhelgaas@google.com>,
	"Heiko Stuebner" <heiko@sntech.de>,
	linux-pci@vger.kernel.org, "Rob Herring" <robh@kernel.org>,
	"Krzysztof Kozlowski" <krzysztof.kozlowski+dt@linaro.org>,
	"Conor Dooley" <conor+dt@kernel.org>,
	devicetree@vger.kernel.org, linux-rockchip@lists.infradead.org,
	linux-arm-kernel@lists.infradead.org,
	"Rick Wertenbroek" <rick.wertenbroek@gmail.com>,
	"Wilfred Mallawa" <wilfred.mallawa@wdc.com>,
	"Niklas Cassel" <cassel@kernel.org>
Subject: Re: [PATCH v2 03/18] PCI: endpoint: Introduce pci_epc_mem_map()/unmap()
Date: Wed, 3 Apr 2024 15:18:40 +0530	[thread overview]
Message-ID: <20240403094840.GI25309@thinkpad> (raw)
In-Reply-To: <20240330041928.1555578-4-dlemoal@kernel.org>

On Sat, Mar 30, 2024 at 01:19:13PM +0900, Damien Le Moal wrote:
> Introduce the function pci_epc_mem_map() to facilitate controller memory
> address allocation and mapping to a RC PCI address region in endpoint
> function drivers.
> 
> This function first uses pci_epc_map_align() to determine the controller
> memory address alignment (offset and size) constraints. The result of
> this function is used to allocate a controller physical memory region
> using pci_epc_mem_alloc_addr() and map it to the RC PCI address
> space with pci_epc_map_addr(). Since pci_epc_map_align() may indicate
> that a mapping can be smaller than the requested size, pci_epc_mem_map()
> may only partially map the RC PCI address region specified and return
> a smaller size for the effective mapping.
> 
> The counterpart of pci_epc_mem_map() to unmap and free the controller
> memory address region is pci_epc_mem_unmap().
> 
> Both functions operate using struct pci_epc_map data structure which is
> extended to contain the physical and virtual addresses of the allocated
> controller memory. Endpoint function drivers can use struct pci_epc_map
> to implement read/write accesses within the mapped RC PCI address region
> using the ->virt_addr and ->size fields.
> 
> This commit contains contributions from Rick Wertenbroek
> <rick.wertenbroek@gmail.com>.
> 

Adding 'Co-developed-by && Signed-off-by' tags would give the due credit.

> Signed-off-by: Damien Le Moal <dlemoal@kernel.org>
> ---
>  drivers/pci/endpoint/pci-epc-core.c | 68 +++++++++++++++++++++++++++++
>  include/linux/pci-epc.h             |  6 +++
>  2 files changed, 74 insertions(+)
> 
> diff --git a/drivers/pci/endpoint/pci-epc-core.c b/drivers/pci/endpoint/pci-epc-core.c
> index 37758ca91d7f..0095b54bdf9e 100644
> --- a/drivers/pci/endpoint/pci-epc-core.c
> +++ b/drivers/pci/endpoint/pci-epc-core.c
> @@ -530,6 +530,74 @@ int pci_epc_map_addr(struct pci_epc *epc, u8 func_no, u8 vfunc_no,
>  }
>  EXPORT_SYMBOL_GPL(pci_epc_map_addr);
>  
> +/**
> + * pci_epc_mem_map() - allocate and map CPU address to PCI address

How about, 'pci_epc_alloc_map()'? I think the 'mem' prefix was added to the
existing APIs since the function definitions are in pci-epc-mem driver, but
not needed here.

> + * @epc: the EPC device on which the CPU address is to be allocated and mapped
> + * @func_no: the physical endpoint function number in the EPC device
> + * @vfunc_no: the virtual endpoint function number in the physical function
> + * @pci_addr: PCI address to which the CPU address should be mapped
> + * @size: the number of bytes to map starting from @pci_addr
> + * @map: where to return the mapping information
> + *
> + * Allocate a controller physical address region and map it to a RC PCI address

"Allocate an EPC address space region..."

> + * region, taking into account the controller physical address mapping
> + * constraints (if any). Returns the effective size of the mapping, which may

Return value should be specified separately for Kdoc.

> + * be less than @size, or a negative error code in case of error.
> + */
> +ssize_t pci_epc_mem_map(struct pci_epc *epc, u8 func_no, u8 vfunc_no,
> +			u64 pci_addr, size_t size, struct pci_epc_map *map)
> +{
> +	int ret;
> +
> +	ret = pci_epc_map_align(epc, func_no, vfunc_no, pci_addr, size, map);
> +	if (ret)
> +		return ret;
> +
> +	map->virt_base = pci_epc_mem_alloc_addr(epc, &map->phys_base,
> +						map->map_size);

It'd be nice to move pci_epc_map_align() inside the existing
pci_epc_mem_alloc_addr() API to make sure that the allocated memory follows the
constraints of the EPC.

Would that make sense?

- Mani

> +	if (!map->virt_base)
> +		return -ENOMEM;
> +
> +	map->phys_addr = map->phys_base + map->map_ofst;
> +	map->virt_addr = map->virt_base + map->map_ofst;
> +
> +	ret = pci_epc_map_addr(epc, func_no, vfunc_no, map->phys_base,
> +			       map->map_pci_addr, map->map_size);
> +	if (ret) {
> +		pci_epc_mem_free_addr(epc, map->phys_base, map->virt_base,
> +				      map->map_size);
> +		return ret;
> +	}
> +
> +	return map->pci_size;
> +}
> +EXPORT_SYMBOL_GPL(pci_epc_mem_map);
> +
> +/**
> + * pci_epc_mem_unmap() - unmap from PCI address and free a CPU address region
> + * @epc: the EPC device on which the CPU address is allocated and mapped
> + * @func_no: the physical endpoint function number in the EPC device
> + * @vfunc_no: the virtual endpoint function number in the physical function
> + * @map: the mapping information
> + *
> + * Allocate and map local CPU address to a PCI address, accounting for the
> + * controller local CPU address alignment constraints.
> + */
> +void pci_epc_mem_unmap(struct pci_epc *epc, u8 func_no, u8 vfunc_no,
> +		       struct pci_epc_map *map)
> +{
> +	if (!pci_epc_function_is_valid(epc, func_no, vfunc_no))
> +		return;
> +
> +	if (!map || !map->pci_size)
> +		return;
> +
> +	pci_epc_unmap_addr(epc, func_no, vfunc_no, map->phys_base);
> +	pci_epc_mem_free_addr(epc, map->phys_base, map->virt_base,
> +			      map->map_size);
> +}
> +EXPORT_SYMBOL_GPL(pci_epc_mem_unmap);
> +
>  /**
>   * pci_epc_clear_bar() - reset the BAR
>   * @epc: the EPC device for which the BAR has to be cleared
> diff --git a/include/linux/pci-epc.h b/include/linux/pci-epc.h
> index 8cfb4aaf2628..86397a500b54 100644
> --- a/include/linux/pci-epc.h
> +++ b/include/linux/pci-epc.h
> @@ -304,4 +304,10 @@ void __iomem *pci_epc_mem_alloc_addr(struct pci_epc *epc,
>  				     phys_addr_t *phys_addr, size_t size);
>  void pci_epc_mem_free_addr(struct pci_epc *epc, phys_addr_t phys_addr,
>  			   void __iomem *virt_addr, size_t size);
> +
> +ssize_t pci_epc_mem_map(struct pci_epc *epc, u8 func_no, u8 vfunc_no,
> +			u64 pci_addr, size_t size, struct pci_epc_map *map);
> +void pci_epc_mem_unmap(struct pci_epc *epc, u8 func_no, u8 vfunc_no,
> +		       struct pci_epc_map *map);
> +
>  #endif /* __LINUX_PCI_EPC_H */
> -- 
> 2.44.0
> 

-- 
மணிவண்ணன் சதாசிவம்

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2024-04-03  9:48 UTC|newest]

Thread overview: 162+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-03-30  4:19 [PATCH v2 00/18] Improve PCI memory mapping API Damien Le Moal
2024-03-30  4:19 ` Damien Le Moal
2024-03-30  4:19 ` Damien Le Moal
2024-03-30  4:19 ` [PATCH v2 01/18] PCI: endpoint: Introduce pci_epc_function_is_valid() Damien Le Moal
2024-03-30  4:19   ` Damien Le Moal
2024-03-30  4:19   ` Damien Le Moal
2024-04-03  6:46   ` Manivannan Sadhasivam
2024-04-03  6:46     ` Manivannan Sadhasivam
2024-04-03  6:46     ` Manivannan Sadhasivam
2024-04-05 13:33   ` Niklas Cassel
2024-04-05 13:33     ` Niklas Cassel
2024-04-05 13:33     ` Niklas Cassel
2024-03-30  4:19 ` [PATCH v2 02/18] PCI: endpoint: Introduce pci_epc_map_align() Damien Le Moal
2024-03-30  4:19   ` Damien Le Moal
2024-03-30  4:19   ` Damien Le Moal
2024-04-03  7:45   ` Manivannan Sadhasivam
2024-04-03  7:45     ` Manivannan Sadhasivam
2024-04-03  7:45     ` Manivannan Sadhasivam
2024-04-03  7:54     ` Damien Le Moal
2024-04-03  7:54       ` Damien Le Moal
2024-04-03  7:54       ` Damien Le Moal
2024-04-03  9:21       ` Manivannan Sadhasivam
2024-04-03  9:21         ` Manivannan Sadhasivam
2024-04-03  9:21         ` Manivannan Sadhasivam
2024-04-03 12:33   ` Kishon Vijay Abraham I
2024-04-03 12:33     ` Kishon Vijay Abraham I
2024-04-03 12:33     ` Kishon Vijay Abraham I
2024-04-04  2:43     ` Damien Le Moal
2024-04-04  2:43       ` Damien Le Moal
2024-04-04  2:43       ` Damien Le Moal
2024-04-05 12:20       ` Niklas Cassel
2024-04-05 12:20         ` Niklas Cassel
2024-04-05 12:20         ` Niklas Cassel
2024-04-05 12:43         ` Damien Le Moal
2024-04-05 12:43           ` Damien Le Moal
2024-04-05 12:43           ` Damien Le Moal
2024-04-05 15:18           ` Niklas Cassel
2024-04-05 15:18             ` Niklas Cassel
2024-04-05 15:18             ` Niklas Cassel
2024-04-10 11:57         ` Kishon Vijay Abraham I
2024-04-10 11:57           ` Kishon Vijay Abraham I
2024-04-10 11:57           ` Kishon Vijay Abraham I
2024-04-05  8:38   ` Dan Carpenter
2024-04-05  8:38     ` Dan Carpenter
2024-04-05  8:38     ` Dan Carpenter
2024-03-30  4:19 ` [PATCH v2 03/18] PCI: endpoint: Introduce pci_epc_mem_map()/unmap() Damien Le Moal
2024-03-30  4:19   ` Damien Le Moal
2024-03-30  4:19   ` Damien Le Moal
2024-04-03  9:48   ` Manivannan Sadhasivam [this message]
2024-04-03  9:48     ` Manivannan Sadhasivam
2024-04-03  9:48     ` Manivannan Sadhasivam
2024-04-05 14:10   ` Niklas Cassel
2024-04-05 14:10     ` Niklas Cassel
2024-04-05 14:10     ` Niklas Cassel
2024-03-30  4:19 ` [PATCH v2 04/18] PCI: endpoint: test: Use pci_epc_mem_map/unmap() Damien Le Moal
2024-03-30  4:19   ` Damien Le Moal
2024-03-30  4:19   ` Damien Le Moal
2024-04-05 13:37   ` Niklas Cassel
2024-04-05 13:37     ` Niklas Cassel
2024-04-05 13:37     ` Niklas Cassel
2024-03-30  4:19 ` [PATCH v2 05/18] PCI: endpoint: test: Synchronously cancel command handler work Damien Le Moal
2024-03-30  4:19   ` Damien Le Moal
2024-03-30  4:19   ` Damien Le Moal
2024-04-03  7:47   ` Manivannan Sadhasivam
2024-04-03  7:47     ` Manivannan Sadhasivam
2024-04-03  7:47     ` Manivannan Sadhasivam
2024-04-05 13:41     ` Niklas Cassel
2024-04-05 13:41       ` Niklas Cassel
2024-04-05 13:41       ` Niklas Cassel
2024-03-30  4:19 ` [PATCH v2 06/18] PCI: endpoint: test: Implement link_down event operation Damien Le Moal
2024-03-30  4:19   ` Damien Le Moal
2024-03-30  4:19   ` Damien Le Moal
2024-04-03  7:48   ` Manivannan Sadhasivam
2024-04-03  7:48     ` Manivannan Sadhasivam
2024-04-03  7:48     ` Manivannan Sadhasivam
2024-04-05 13:39     ` Niklas Cassel
2024-04-05 13:39       ` Niklas Cassel
2024-04-05 13:39       ` Niklas Cassel
2024-04-06  2:24       ` Manivannan Sadhasivam
2024-04-06  2:24         ` Manivannan Sadhasivam
2024-04-06  2:24         ` Manivannan Sadhasivam
2024-03-30  4:19 ` [PATCH v2 07/18] PCI: rockchip-ep: Fix address translation unit programming Damien Le Moal
2024-03-30  4:19   ` Damien Le Moal
2024-03-30  4:19   ` Damien Le Moal
2024-03-30  4:19 ` [PATCH v2 08/18] PCI: rockchip-ep: Use a macro to define EP controller .align feature Damien Le Moal
2024-03-30  4:19   ` Damien Le Moal
2024-03-30  4:19   ` Damien Le Moal
2024-03-30  4:19 ` [PATCH v2 09/18] PCI: rockchip-ep: Improve rockchip_pcie_ep_unmap_addr() Damien Le Moal
2024-03-30  4:19   ` Damien Le Moal
2024-03-30  4:19   ` Damien Le Moal
2024-03-30  4:19 ` [PATCH v2 10/18] PCI: rockchip-ep: Improve rockchip_pcie_ep_map_addr() Damien Le Moal
2024-03-30  4:19   ` Damien Le Moal
2024-03-30  4:19   ` Damien Le Moal
2024-03-30  4:19 ` [PATCH v2 11/18] PCI: rockchip-ep: Implement the map_align endpoint controller operation Damien Le Moal
2024-03-30  4:19   ` Damien Le Moal
2024-03-30  4:19   ` Damien Le Moal
2024-03-30  4:19 ` [PATCH v2 12/18] PCI: rockchip-ep: Refactor rockchip_pcie_ep_probe() memory allocations Damien Le Moal
2024-03-30  4:19   ` Damien Le Moal
2024-03-30  4:19   ` Damien Le Moal
2024-03-30  4:19 ` [PATCH v2 13/18] PCI: rockchip-ep: Refactor rockchip_pcie_ep_probe() MSI-X hiding Damien Le Moal
2024-03-30  4:19   ` Damien Le Moal
2024-03-30  4:19   ` Damien Le Moal
2024-03-30  4:19 ` [PATCH v2 14/18] PCI: rockchip-ep: Refactor endpoint link training enable Damien Le Moal
2024-03-30  4:19   ` Damien Le Moal
2024-03-30  4:19   ` Damien Le Moal
2024-03-30  4:19 ` [PATCH v2 15/18] PCI: rockship-ep: Introduce rockchip_pcie_ep_stop() Damien Le Moal
2024-03-30  4:19   ` Damien Le Moal
2024-03-30  4:19   ` Damien Le Moal
2024-03-30  4:19 ` [PATCH v2 16/18] PCI: rockchip-ep: Improve link training Damien Le Moal
2024-03-30  4:19   ` Damien Le Moal
2024-03-30  4:19   ` Damien Le Moal
2024-04-03 11:54   ` Rick Wertenbroek
2024-04-03 11:54     ` Rick Wertenbroek
2024-04-03 11:54     ` Rick Wertenbroek
2024-03-30  4:19 ` [PATCH v2 17/18] dt-bindings: pci: rockchip,rk3399-pcie-ep: Add ep-gpios property Damien Le Moal
2024-03-30  4:19   ` Damien Le Moal
2024-03-30  4:19   ` Damien Le Moal
2024-03-30  9:16   ` Krzysztof Kozlowski
2024-03-30  9:16     ` Krzysztof Kozlowski
2024-03-30  9:16     ` Krzysztof Kozlowski
2024-03-31 23:06     ` Damien Le Moal
2024-03-31 23:06       ` Damien Le Moal
2024-03-31 23:06       ` Damien Le Moal
2024-04-01  9:57       ` Krzysztof Kozlowski
2024-04-01  9:57         ` Krzysztof Kozlowski
2024-04-01  9:57         ` Krzysztof Kozlowski
2024-04-01 23:36         ` Damien Le Moal
2024-04-01 23:36           ` Damien Le Moal
2024-04-01 23:36           ` Damien Le Moal
2024-04-02  7:33           ` Krzysztof Kozlowski
2024-04-02  7:33             ` Krzysztof Kozlowski
2024-04-02  7:33             ` Krzysztof Kozlowski
2024-04-02  7:38             ` Damien Le Moal
2024-04-02  7:38               ` Damien Le Moal
2024-04-02  7:38               ` Damien Le Moal
2024-04-02  7:55               ` Damien Le Moal
2024-04-02  7:55                 ` Damien Le Moal
2024-04-02  7:55                 ` Damien Le Moal
2024-04-02 18:10                 ` Krzysztof Kozlowski
2024-04-02 18:10                   ` Krzysztof Kozlowski
2024-04-02 18:10                   ` Krzysztof Kozlowski
2024-04-02 23:23                   ` Damien Le Moal
2024-04-02 23:23                     ` Damien Le Moal
2024-04-02 23:23                     ` Damien Le Moal
2024-04-02  7:38             ` Damien Le Moal
2024-04-02  7:38               ` Damien Le Moal
2024-04-02  7:38               ` Damien Le Moal
2024-03-30  4:19 ` [PATCH v2 18/18] PCI: rockchip-ep: Handle PERST# signal in endpoint mode Damien Le Moal
2024-03-30  4:19   ` Damien Le Moal
2024-03-30  4:19   ` Damien Le Moal
2024-04-02 12:36 ` [PATCH v2 00/18] Improve PCI memory mapping API Rick Wertenbroek
2024-04-02 12:36   ` Rick Wertenbroek
2024-04-02 12:36   ` Rick Wertenbroek
2024-04-03  7:50 ` Manivannan Sadhasivam
2024-04-03  7:50   ` Manivannan Sadhasivam
2024-04-03  7:50   ` Manivannan Sadhasivam
2024-04-03  7:58   ` Damien Le Moal
2024-04-03  7:58     ` Damien Le Moal
2024-04-03  7:58     ` Damien Le Moal
2024-04-03  9:25     ` Manivannan Sadhasivam
2024-04-03  9:25       ` Manivannan Sadhasivam
2024-04-03  9:25       ` Manivannan Sadhasivam

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20240403094840.GI25309@thinkpad \
    --to=manivannan.sadhasivam@linaro.org \
    --cc=bhelgaas@google.com \
    --cc=cassel@kernel.org \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=dlemoal@kernel.org \
    --cc=heiko@sntech.de \
    --cc=kishon@kernel.org \
    --cc=krzysztof.kozlowski+dt@linaro.org \
    --cc=kw@linux.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=linux-rockchip@lists.infradead.org \
    --cc=lpieralisi@kernel.org \
    --cc=rick.wertenbroek@gmail.com \
    --cc=robh@kernel.org \
    --cc=shawn.lin@rock-chips.com \
    --cc=wilfred.mallawa@wdc.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.