From: Serge Semin
> 3) IDT driver redevelopment will take a lot of time, since I don't have much
> free time to
> do it. It may be half of year or even more.
>
> From my side, such an improvement will significantly complicate the NTB
> Kernel API. Since
> you are the subsystem maintainer it's yo
Allen,
There is no any comment below, just this one.
After a short meditation I realized what you are trying to achieve. Your
primary intentions
was to unify the NTB interface so it would fit both Inte/AMD and IDT hardware
without doing
any abstraction. You may understand why I so eager in refus
Hello Allen,
Sorry for the delay with response and thanks for thoughtful review.
On Mon, Aug 08, 2016 at 05:48:42PM -0400, Allen Hubbe
wrote:
> From: Serge Semin
> > Hello Allen.
> >
> > Thanks for your careful review. Going through this mailing thread I hope
> > we'll come up
> > with solutio
From: Serge Semin
> Hello Allen.
>
> Thanks for your careful review. Going through this mailing thread I hope
> we'll come up
> with solutions, which improve the driver code as well as extend the Linux
> kernel support
> of new devices like IDT PCIe-swtiches.
>
> Before getting to the inline co
Hello Allen.
Thanks for your careful review. Going through this mailing thread I hope we'll
come up with solutions, which improve the driver code as well as extend the
Linux kernel support of new devices like IDT PCIe-swtiches.
Before getting to the inline commentaries I need to give some intro
From: Serge Semin
> Currently supported AMD and Intel Non-transparent PCIe-bridges are synchronous
> devices, so translated base address of memory windows can be direcly written
> to peer registers. But there are some IDT PCIe-switches which implement
> complex interfaces using Lookup Tables of tra
6 matches
Mail list logo
