> -----Original Message----- > From: Bounine, Alexandre [mailto:alexandre.boun...@idt.com] > Sent: Wednesday, September 15, 2010 11:53 AM > To: Anderson, Trevor; Andrew Morton > Cc: linux-ker...@vger.kernel.org; Thomas Moll; linuxppc-dev@lists.ozlabs.org > Subject: RE: [PATCH v2 09/10] RapidIO: Add support for IDT CPS Gen2 switches > > Anderson, Trevor <tander...@curtisswright.com> wrote: > > > > Keep it in please. We lurkers in the embedded community do use the > per-port routing tables. > > One of the problems with SRIO switch tables is that access to routes > is not atomic; we can use > > restricted access to per-port routing tables to reduce the risk of > interference. And we still use > > the Global table during enumeration. > > > Will it help if I add sysfs attribute(s) to handle per-port routes?
I don't think so - not from my perspective, at least. All of our routes are programmed using the broadcast table; but we use the private tables as a safer method of reading the routes that have been programmed, when we need to know that. _______________________________________________________________________ This e-mail and any files transmitted with it are proprietary and intended solely for the use of the individual or entity to whom they are addressed. If you have reason to believe that you have received this e-mail in error, please notify the sender and destroy this email and any attached files. Please note that any views or opinions presented in this e-mail are solely those of the author and do not necessarily represent those of the Curtiss-Wright Corporation or any of its subsidiaries. Documents attached hereto may contain technology subject to government export regulations. Recipient is solely responsible for ensuring that any re-export, transfer or disclosure of this information is in accordance with applicable government export regulations. The recipient should check this e-mail and any attachments for the presence of viruses. Curtiss-Wright Corporation and its subsidiaries accept no liability for any damage caused by any virus transmitted by this e-mail. _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
