linux-kernel - Re: xilinx-pci driver and pci in general

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 14 Jan 2010 13:07:16 +1100
From:	Benjamin Herrenschmidt <benh@...nel.crashing.org>
To:	michal.simek@...alogix.com
Cc:	Grant Likely <grant.likely@...retlab.ca>, linuxppc-dev@...abs.org,
	thunderbird2k@....net, John Williams <john.williams@...alogix.com>,
	Arnd Bergmann <arnd@...db.de>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: xilinx-pci driver and pci in general

On Wed, 2010-01-13 at 16:23 +0100, Michal Simek wrote:

> The main problems are:
> ppc use ppc_md struct which we don't have it on Microblaze.
> xilinx-pci driver uses exclude_device function. This function is used in 
> indirect_pci.c too. There could be a way to move that function directly 
> to pci_controller structure which could be useful for other controllers 
> too. What do you think?
> 
> Then there are some other ppc_md. calling like pcibios_after_init which
> if I see correctly not used for ppc too.

We may not be using after_init() anymore in which case you are welcome
to send a patch to remove it :-)

As for the others, well ... maybe you can do wrappers for these that
call into ppc_md. on powerpc and into some kind of arch_pci_ops. that
the platform provides on microblaze ?

I'm not sure moving them into the pci_controller is the best way to go
there.

> The next thing is that some files contains asm/machdep.h which could be 
> added to asm/pci-bridge.h and the same is for asm/ppc-pci.h

Yeah, moving includes like that is ok.

> Files contains CONFIG_PPC_OF and we would like to use only CONFIG_OF.
> I remember any discuss around but not sure what was the conclusion on 
> powerpc.

I think that should be allright, Grant, any objection there ?

> Part of headers are the same that's why there will be a space to move 
> them to asm-generic.

If you can convince other archs that it makes sense to do so ? :-)

> Anyway: I look at your dma-mapping.h and you can use 
> asm-generic/dma-mapping-common.h as I am using.

Not just quite yet, there's still some stuff we need to cleanup with
the !coherent cases.

> Then I have some question about EARLY_PCI_OP in ppc_32.c. Is there any 
> reason to use early_##rw##_config_##size fucntions instead of proper 
> pci_bus_##rw##_config_##size functions?
> There is one comment that these functions are used before PCI scanning 
> is done but there are used the same function as are in driver/pci/access.c.
> Is there any "secret" reason to do it in this way?

Well, first of all, those aren't ppc32 only anymore, they are in
pci-common.c now. Then, if you look at them you'll notice that
they are just a wrapper on top of pci_bus_* which uses a fake
pci_bus structure. IE. They are meant to be used in very early
arch fixup code at a time when we may not even have the struct
pci_bus at hand. Their use is pretty rare though, maybe we -could-
get rid of them at some stage by moving some of that fixup code.

> Thanks for this early discuss. I would like to hear your opinion and 
> then I will choose solution how to add our pci support to mainline.

Cheers,
Ben.



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/