Messages in this thread | | | Date | Mon, 5 Jun 2017 09:42:30 +0300 | From | Mika Westerberg <> | Subject | Re: [PATCH v3 06/27] thunderbolt: Rework capability handling |
| |
On Sun, Jun 04, 2017 at 09:15:03PM +0300, Andy Shevchenko wrote: > On Sun, Jun 4, 2017 at 6:06 PM, Mika Westerberg > <mika.westerberg@linux.intel.com> wrote: > > On Sun, Jun 04, 2017 at 06:00:02PM +0300, Mika Westerberg wrote: > >> On Sun, Jun 04, 2017 at 03:52:29PM +0200, Lukas Wunner wrote: > >> > On Fri, Jun 02, 2017 at 05:05:03PM +0300, Mika Westerberg wrote: > >> > > Organization of the capabilities in switches and ports is not so random > >> > > after all. Rework the capability handling functionality so that it > >> > > follows how capabilities are organized and provide two new functions > >> > > (tb_switch_find_vsec_cap() and tb_port_find_cap()) which can be used to > >> > ^^^^^^^^ > >> > > >> > I assume VSEC is the same acronym as in the PCIe spec, so this naming > >> > scheme results in "vendor specific extended capability capability", > >> > which is maybe a bit odd. > >> > >> AFAIK it comes from Vendor SpEcifiC but I'm not 100% sure ;-) The Alpine > >> Ridge datasheet calls it also VSEC capability which is why we chose the > >> naming accordingly. > > > > That said, it could also come from Vendor SpEcific Capability. I can > > change it to tb_switch_find_vsec() if that works better. > > I would folllow PCI existing namings, i.e. > _vse_cap()
Indeed this sounds better.
I looked at the TBT specs again and they just use VSEC but do not open the acronym any further. I guess the "Vendor Specific Extended Capability" as Lukas pointed out is the correct one.
I'll change the patch to use tb_switch_find_vse_cap() and rename TB_VSEC_CAP_* to TB_VSE_CAP_* if there are no objections.
| |