Re: [RFC v2 1/2] PCI-Express Non-Transparent Bridge Support

On Tue, Jul 31, 2012 at 9:45 AM, Bjorn Helgaas [off-list ref] wrote:

On Mon, Jul 30, 2012 at 12:15 PM, Jon Mason [off-list ref] wrote:

quoted

I've tried to make it all generic enough that non-Intel NTBs should plug in with
minimal changes to ntb_hw.c.  If their design is too divergent, then a slight
redesign of ntb_hw.c might be necessary.  But from what I've seen of other
designs on the internet, they appear to be extremely similar.  The transport and
client drivers were written with the hardware abstracted away as much as
possible to prevent the need to modify it for different hardware.  If there is
anything which is Intel hardware specific, I'd be happy to change it to make it
more generic.

That makes sense from a technical point of view, but I think it's
going to cause maintenance issues.  For example, assume PLX NTB
support is added.  Will PLX be happy about having to convince you to
accept changes?  Will Intel be happy about having to release a new

Do you mean convince Intel? Well, if we think of ntb as the class
driver then the onus is on the community to vet the changes and NOT
intel.
And since this is the first NTB part for which the support is
introduced the class driver design could be a moving target. As
someone else mentioned, the async/sync tx-dma is another hook that
could change the class driver's design.

driver for their hardware just to incorporate a PLX bug fix?  Will
users of PLX hardware accept a new driver release that only benefits
Intel users?

May be till the class driver is stable, the client(intel/PLX) drivers
might have to be modified.  This is a cue for other vendors to
chime-in and review this design?
Just thinking if this could sit in staging for some time(so that
others get a chance to review/suggest changes as well) and then get
promoted out of staging.

Chetan Loke