On Tue, Aug 19, 2014 at 09:44:01AM +0800, Wei Yang wrote:

On Mon, Aug 18, 2014 at 03:25:50PM +0100, Catalin Marinas wrote:

quoted

...

quoted

Well, it will become necessary as old code gets dismantled and converted towards
this patchset. To give you an example that I'm familiar with, for arch/arm the
host bridge drivers have moved into drivers/pci/host, but they still depend/use
the bios32 infrastructure that takes care of setting up the irq. When they switch
to my version they would have to go and debug the "irq not being assigned" issue
and it is quite likely that some of the people doing the conversion will complain
about my code rather than understanding the issue. What I'm trying to do is to
make switching to my patchset as painless as possible, with a cleanup to remove
redundant operations coming after the switchover.

While the goal is fine, until we see a common pattern for what needs to
go into pcibios_add_device() I think we should have an arm64-specific
implementation (and probably an arm32 specific one as well). I can see
powerpc uses it for setting the DMA ops. Would we have a similar need on
arm64 to choose between coherent and non-coherent dma_ops?

Liviu,

I have the same feeling with Catalin. An arm64-specific implementation of
pcibios_add_device() would be better.

No more other concerns from my side.

OK, I will make the change when returning from my holiday at the beginning of September,
when I plan to send v10.

Best regards,
Liviu

quoted

Also at some point we'll get ACPI support, so I'm not sure what we do
with assigning the dev->irq here but definitely of_* functions won't
work.

-- 
Catalin

-- 
Richard Yang
Help you, Help me

--
To unsubscribe from this list: send the line "unsubscribe linux-pci" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

-- 
-------------------
   .oooO
   (   )
    \ (  Oooo.
     \_) (   )
          ) /
         (_/

 One small step
   for me ...