porting driver for Marvell switch 88E6165

I thought it was easier to use DSDT from user space than trying to port it to kernel space or write my own. I looked at DSA as few years ago and it looked to be just some minimal interfaces (virtual ethernet ports). Just enough interface for ethtools. Marvell specific features won'y be available. Might have changed since then.

I'll make a wild guess on your error message. I think the MDIO driver needs to configure or enabled or something.

Thanks Norman!

Yes, I think it would be the easiest way to use DSDT with davinci_mdio driver. I'll look davinci_mdio source code.

But I guess how to call network driver from userspace. I have had experience of working with char modules so far, not network devices.

I agree with you. Marvell DSDT code expects customer to implement the MDIO interface.

As I understood there are two methods to resolve my task:

1. Embed DSDT in kernel space and use private char driver as a bridge between user application and DSDT in kernel space.

2. Embed DSDT in user space and use default MII ioctls as a interface to the switch through mdio pins.

So, I chose the last because of lack of time. It works! I hope to try the first option when I have a free time.

Many thanks Mr. Wong!

Bakir,

I've worked with both the Mavell DSDT userspace code and the opensource DSA kernel driver.  I ultimately decided on the opensource DSA driver as it fit better with my needs.  Since then, I've greatly enhanced the capabilities of the DSA driver to expose additional 6165 functionality but have not had a chance to push them upstream.  I like you am doing all of this with an ARM platform.  If you want to do managed mode layer 2 stuff like STP, LLDP, etc, DSA is your only option in Linux  Even then, I think DSA is better as it fits better with Linux and it's netdev infrastructure.  I currently have interrupt mode support working so the kernel does not need to poll for link state changes.  I also have the temp sensor glued to the HWMON framework additional ethtool functionality added.  PM me at cphealy (at) g mail (d0t) com if you want the enhanced DSA code. 

Hi,

I am trying to configure  ethernet PHY's(Marvell 88E1111 and VSC 8641) from user space.Can anyone please help me in this.I have the driver code for Marvell and vitesse PHY's. I am using 2.6.34 kernel.

How can i call the read and write register fuctions from user space.Please guide me in this.

Thanks in advance

Arjun.

Arjun,

I'm assuming you already have the PHY connected to the MAC in your SOC via MII, GMII, or RGMII including the MDIO pins.  If this is already configured properly in the kernel and working properly, you should be able to use the standard Linux API's/apps to interface it.

There are two that I use, ethtool and mii-tool.  ethtool is current and allows performing a plethora of operations with your MAC and PHY.  mii-tool is a little older and not as well maintained.  You can try ethtool out on a Linux PC provided you have the package installed.  You can learn about it's capabilities at the following URL:  http://linuxcommand.org/man_pages/ethtool8.html

I use it to read out PHY status values as well as set PHY control values such as the link advertisement data. 

What exactly are you trying to configure?

Regards,

Chris

Hi Chris,

Thank you for the reply ..

What exactly i need to do is:

I have a validation board with different types of PHY's.(TI DP 83865,VSC8641 etc.).

I need to provide a CLI interface so that user can configure each one of them from host PC.(There should be provision for reading/writing different registers using MDIO).Can I directly use ethtool API's for this?

Thanks & Regards,

Arjun

Arjun,

What exactly does the user want to configure within the PHY's?  Does it fit within the framework of what ethtool does?  If it does, this is nice as it's in a format that easy to work with.

This validation board, does it have a MAC for each PHY or are you just connecting the MDIO interface of each PHY to the validation board?  How does the validation board connect to your PC?

Chris

Hi Chris,

Yes,as of now configuration wise ethtool will be fine.(or incase of any modification later can we add some more ethtool API's to read/write to some other cofiguration  registers also?)

There is no MAC for each PHY that we are configuring and are directly connected to the processor.

The board will be connected to the host using UART.

Regards,

Arjun.

Arjun,

So, you have some board running Linux on it that has PHYs hanging off MDIO.  The board is connected to a PC using a UART interface.  Is this all correct?  Having PHYs connected with just MDIO is not something I have done before.  (I've always had them associated with a MAC.)  This should be doable.  You should read about PHYLIB in the Linux kernel for more information.

It may not be best to use all the abstraction layers Linux provides seeing as you don't have MAC's and you might want to do more than what ethtool provides.  You may be best off providing a simple driver that exposes MDIO read/write access and implement all of your functionality in userland instead of the kernel.

Good luck,

Chris

 Hi Chris,

Yes.we have a board with all hardware connections and we are trying to port Linux in to that.As part of that i have to provide support for all the PHY's in the kernel.

Regarding the configuration part,I started in the same way as you said earlier.But i am not able to figure out any ioctl calls in PHY drivers so that i can call from user space(These PHY drivers are entirely different from Ethernet drivers or not ? no ioctl calls,no fops structure..).

or can i use mdio_mii_ioctl call(drivers/net/mdio.c) and specify the register addresses that we need to access?

If you have any idea on this please confirm that whether it will be feasible or not?

I am totally confused in deciding the way in which i have to proceed further as i have only few days of relation with Linux network drivers :(

Thanks &Regards,

Arjun

 Bakir/Chris

I am working on ethenet bring up on customize board ,which have external marvell 88e6320 switch  phy .I have got DSDT driver for switch, but not sure, how it will interact from switch in kernel space?.As you have done for same ,could you please help me to find out, how DSDT  user space driver have an  interaction with switch via default MII ioctls.  do you have your changes as part of community or anywhere in open source.

Regards

Raj

Hi Raj! 

Unfortunately I haven't  got any open resources. For calls from userspace you need to initialize mii interface from driver (QuarterDeck) init routine. Point to mii read & write procedures and run mii initialization rountine.

... 

cfg.BSPFunctions.readMii = MiiRead;
 cfg.BSPFunctions.writeMii = MiiWrite;

...

if ((status = MiiInit(dev)) != GT_OK)
{
perror("MiiInit failed");
return status;
}

...

GT_STATUS MiiInit(GT_QD_DEV* dev)
{
struct mii_ioctl_data *mii;

memset(&ifr, 0, sizeof(ifr));
strcpy(ifr.ifr_ifrn.ifrn_name, "eth0"); //set to whatever your ethernet device is
mii = (struct mii_ioctl_data *)(&ifr.ifr_ifru.ifru_data);
mii->phy_id = 1; //set to your phy's ID
mii->reg_num = 0; //the register you want to read
mii->val_in = 0;
mii->val_out = 0;

fd = socket(AF_INET, SOCK_DGRAM, 0);

if (fd < 0) {
syslog(LOG_ERR | LOG_USER, "Can't create socket for MII, error: %s", strerror(errno));
return GT_FAIL;
}

return GT_OK;
}

GT_BOOL MiiRead (GT_QD_DEV* dev, unsigned int portNumber , unsigned int MIIReg,
unsigned int* value)
{
struct mii_ioctl_data *mii;

mii = (struct mii_ioctl_data *)(&ifr.ifr_ifru.ifru_data);
mii->phy_id = portNumber;
mii->reg_num = MIIReg;
if (ioctl(fd, SIOCGMIIREG, &ifr) < 0)
{
perror("ioctl[SIOCGMIIPHY]");
return GT_FALSE;
}
*value = (unsigned int)(mii->val_out & 0xffff);

return GT_TRUE;
}

GT_BOOL MiiWrite (GT_QD_DEV* dev, unsigned int portNumber , unsigned int MIIReg,
unsigned int value)
{
struct mii_ioctl_data *mii;

mii = (struct mii_ioctl_data *)(&ifr.ifr_ifru.ifru_data);
mii->phy_id = portNumber;
mii->reg_num = MIIReg;
mii->val_in = value & 0xffff;
if (ioctl(fd, SIOCSMIIREG, &ifr) < 0)
{
perror("ioctl[SIOCSMIIPHY]");
return GT_FALSE;
}
return GT_TRUE;
}

I hope this help you :)

Bakir,

Thanks for reply ..

 It’s really useful to get start  DSDT driver from user space. Still, I have some doubt regarding DSDT driver package .

 In DSDT driver directory , I can see two directory  :switch and phy. As, i need to configure marvell switch 88E6320 ,do I still need to  touch phy driver?( part of DSDT driver package) or do I need to start phy driver first which will configure the switch phy ?.

 The DSDT configuration happens from user space. So during Kernel bootup, DHCP will not happen. Is our understanding correct ?

 As I  understand, the DSDT user space driver directly interacts with  MDIO (as per mdio.c)in the Kernel space using predefined IOCTL (SIOCSMIIREG, SIOCSMIIREG) . do I still need to customize the mdio driver  in kernel for DSDT-MDIO interaction successful on soc?

Regards

Raj

Hi Raj!

1) You don't need phy driver and its directory for your switch. See readme files.

2) As I know, DSDT doesn't support DHCP. I don't know much about DHCP service.

3) You must initialize you own mdio and mac drivers in the board support file before using these ioctls. If don't have a such driver support you will need to create them.

Regards, Bakir 

Hi Bakir,

Thanks for reply.

1) You don't need phy driver and its directory for your switch. See readme files.

As per your comment ,I have gone through the readme files.I can see both, switch and phy directory and corresponding readme files(Readme_SW and Readme_phy) as below mentioned.

DSDT_X.X/switch

<make switch>: to build switch driver image only. 

 I can see "The Switch driver suite is standalone program, which is independent of both OS and Platform. As such, applications of MSAPIs need to register platform specific functions. This is done by calling qdLoadDriver function. This function returns a pointer (*dev), which contains the device and platform information. It will then be used for each MSAPI call."

here,qdStart is the main function to initialize Switch Driver.

DSDT_X.X/phy :

<make phy>: to build phy driver image only.

I can see "The MAD is standalone program, which is independent of both OS and Platform. As such, applications of MAD APIs need to register platform specific functions. This is done by calling mdLoadDriver function. This function fills up the MAD Driver Structure (*dev) with the device and platform information. Thereafter, "*dev" is used for each MAD API call to identify a specific PHY."

<make DSDT_USE_MAD=TRUE>: to build switch and phy driver images, and switch driver uses MAD APIs.

2) As I know, DSDT doesn't support DHCP. I don't know much about DHCP service.

3) You must initialize you own mdio and mac drivers in the board support file before using these ioctls. If don't have a such driver support you will need to create them.

 In TI davinic source code, i can see that ,mdio driver in form of davinci_mdio.c file.

Dear Raj,

1) I think PHY driver is requested when you use only PHY devices. If your board consist of both SWITCH & PHY devs, then you need to use option "DSDT_USE_MAD=TRUE" to build SWITCH & PHY drivers. Is your board has PHY devices? If it doesn't, don't build PHY driver! For example, I only use SWITCH driver. I think, you should read readme files more carefully :)

2) What is the "Ethernet configuration"? If this is a PHY settings from your application, then this is not a part of a kernel. If you insert Eth. configuration to the kernel driver then you will be able to setup Eth. configuration during boot up. Imho, there is no principle difference where you store you configuration.

3) With ioctls we call to mdio driver wrapper, that redirects our requests to ti driver. There is no direct visibility between userspace and ti mdio driver.

Regards, Bakir

Hi all,

I'm writing a switch driver for Marvell 88E6176 but I have some problems when create  tagged base vlan on this switch , when i operate VTU in switch chip.

After I load a VTU entry to the VTU, I can't find it in VTU.

Is there anybody know marvell switch and did I miss some steps? please provide any help and suggest me thanks...

Hi, Pawan!

For 88E6176 you can look at gvtuAddEntry function from DSDT driver. To get the driver you must have NDA with Marvell.

Best regards, Bakir.

Hi Bakir,

Thanks for your response and next time i remember NDA also. but  i go thorough the gvtuAddEntry function and set the registers as well but after that there is a function check the add vlan id it fail to load the vtu. i have not set the sid and fid .and using the multi chip mode is not necessary to set the sid on stu  database please guide me i am struction in this issue ..

Hi Pawan and Bakir,

I am also using same Marvel switch with AM335x, what all the initial configurations you have done at the uboot level, so that you have ethernet connectivity?

Can you please share some information on the same?

Regards

Muragesh

Hi Raj!

I understand that you are trying to verify VLAN tag on Windows machine within some capture tool, aren't you? You can't get VLAN tag like that. Ethernet interface automatically cut out tag from the header. You can try to do so on linux machine ( virtual ), you will need to create VLAN interface on Ethernet port.

Bakir

Hi, does TI or anybody have the working driver for 88E6176 to share?

Thanks,

John

Hello Raj,

You can use Port mirroring feature in any external port and capture the all logs in wireshark tool. 

Thanks

Rockford

Hi Bakir/Rockford,

We are not able to send tag based vlan data form the marvell switch present on board.

Our main goal is to send/receive tag based frames, CPU connected to marvel switch can only understands untagged frames. So data coming to marvell from CPU should get tagged by switch and then switch can send tagged data to external ethernet network. In case of receive marvell switch should accept only tagged frame of specific tag and untag it send data to CPU.

We have followed some steps from the sample application present in DSDT code, however still we are not able to tag the frame and send it to tagged ethernet network.

Do we need to use TCAM in this case?

Please let me know your comments on this . 

Regards

Raj

Hi Raj/Bakir,

Even I have same requirement of tagging as you explained above.

Can you please let me know how did you achieve this?

Regards

Muragesh

Hi Rockford:

did you ever find out what the problem was?  I am having EXACTLY the same issue.  Any write to the VTU with proper sequence from the gvtuAddEntry() in the DSDT 3.3 results in the a failed return code of GT_NO_SUCH because the call tries to read back the entry and says it wasn;t there.  Subsequent calls to gvtuFindEntry() results in the same thing.  I have a setup where I can manually enter in the MDIO commands directly and the behaviour is exactly the same.  I suspect there is something else that needs to be programmed before VTU access is allowed.  Just wondering if you could share any insights with me

Best regards

Dennis

Hello dennis,

Yes this a bug in marvell switch. please set default STU table first then set the VTU table. then definitely VTU show the correct VLAN table.

if you face any problem please me know. 

Thanks 

Pawan 

Thanks Rockford and Pawan:

Will give it a try.  This is sooo much faster than going through our FAE from Marvell :>)

Cheers

Dennis

Hi  Pawan,

first, thanks for the information.

i am using MARWELL-88E6176 switch with AM335x and using switch DSDT 3.3

and trying to add dummy STU table with sid 0 before VTU table, using DSDT api-gstuAddEntry.

but this  API considering  SID of 0 as BAD value

   if((stuEntry->sid == 0) || (stuEntry->sid > 0x3F))

    {

        DBG_INFO(("GT_BAD_PARAM\n"));

        return GT_BAD_PARAM;

    }

 Ref : DSDT_3.3/switch/src/msapi/gtBrgStu.c +332

It will be very helpful if we have some sample application for the same API.

best regards

Nagendra

Hi Nagendra:

I chose a default STU SID = 1, and that seems to work.  As Pawan/Rockford  said, you have to add a default STU entry before you can program VTU entries and use SID = 1 in your gvtuAddEntry() calls.  Default the port states in the STU to FORWARDING as default.

Dennis

Bakir:

I have the DSDT driver ported under linux as part of our proprietary driver.   That was done to leverage the various chip access for the Soho line of chips.  We need the DSA driver around to handle the DSA tags (with VLAN encoding and To/From_CPU functionality).   The interface between the driver is complicated, but to get the DSA driver to detect the chip, you will have to add driver support for the chip under:

/linux/drivers/net/dsa/mv88e6????.c.  To make it part of the kernel, you have to add to the Kconfig file and the options for the 6165 are no PPU (there is really a PPU, but the interface is using 2 Global Regs 2, 18 & 19).  Copy an existing non-PPU driver and change the port count and vendor id checking to the 6165's.  This will detect the chip, but you have some work to go through the global and port setup to make sure you aren't stomping on irrelevant regs on the 6165 that was copied from the other driver.   To access the internal/external  PHYs, you have to enhance the MV88E6XXX.C common file to add the ppu access uing regs 18 & 19 (SMI control & data),

Please take note that the DSDT only has very limited support for accessing the PHYs and your driver has to still make decisions based on the chip and which sdk functions is used for that chip.  I've found that I have to go directly to the regs myself to get or set things up.  Good luck

Dennis

Hi Dennis,

thanks for the support,

i have added SID 9 using api gstuAddEntry and read it back with success.

ref code:

        GT_STU_ENTRY stu_entry;
        stu_entry.sid = 9;
        stu_entry.portState[0] = GT_PORT_FORWARDING;
        stu_entry.portState[1] = GT_PORT_FORWARDING;
        stu_entry.portState[2] = GT_PORT_FORWARDING;
        stu_entry.portState[3] = GT_PORT_FORWARDING;
        stu_entry.portState[5] = GT_PORT_FORWARDING;
        stu_entry.portState[6] = GT_PORT_FORWARDING;
       

        /* setting STU entries */
        if (gstuAddEntry(dev, &stu_entry) != GT_OK) {
                MSG_PRINT(("\ngstuAddEntry  fail.\n"));
                return 0;
        }

corresponding output :

gstuAddEntry Called.
Read from global register: regAddr 0x5, fOff 15, fLen 1, data 0x0.
Write to global register: phyAddr 0x1b, regAddr 0x8, data 0xcc0.
Write to global register: phyAddr 0x1b, regAddr 0x7, data 0xcccc.
Write to global register: phyAddr 0x1b, regAddr 0x6, data 0x1000.
Write to global register: phyAddr 0x1b, regAddr 0x3, data 0x9.
Write to global register: phyAddr 0x1b, regAddr 0x5, data 0xd000.
gstuFindSidEntry Called.
Read from global register: regAddr 0x5, fOff 15, fLen 1, data 0x0.
Write to global register: phyAddr 0x1b, regAddr 0x3, data 0x8.
Write to global register: phyAddr 0x1b, regAddr 0x5, data 0xe000.
Read from global register: regAddr 0x5, fOff 15, fLen 1, data 0x0.
Read from global register: regAddr 0x6, fOff 12, fLen 1, data 0x1.
read from global register: phyAddr 0x1b, regAddr 0x3, data 0x9.
read from global register: phyAddr 0x1b, regAddr 0x8, data 0xcc0.
read from global register: phyAddr 0x1b, regAddr 0x7, data 0xcccc.
OK.

now added sid=9 before every VTU entry api gvtuAddEntry with VID 100.

still VTU find entry gvtuFindVidEntry is failing

ref code :

    <sup><sub>vtuEntry.vid = 100;
    vtuEntry.sid = 9;
    for(i=0; i<dev->numOfPorts; i++)
    {
        port = i;
        if((i==0) || (port == dev->cpuPortNum))
            vtuEntry.vtuData.memberTagP[port] = MEMBER_EGRESS_TAGGED;
        else
            vtuEntry.vtuData.memberTagP[port] = NOT_A_MEMBER;
    }

    if((status = gvtuAddEntry(dev,&vtuEntry)) != GT_OK)
    {
        MSG_PRINT(("gvtuAddEntry returned fail.\n"));
        return status;
    }</sub></sup>

output :

802 test vlan setup
gvtuFlush Called.
Read from global register: regAddr 0x5, fOff 15, fLen 1, data 0x0.
Write to global register: phyAddr 0x1b, regAddr 0x5, data 0x9000.
OK.
gvlnSetPortVlanDot1qMode Called.
Write to port(0) register: regAddr 0x8, fieldOff 10, fieldLen 2, data 0x1.
OK.
gvlnSetPortVlanDot1qMode Called.
Write to port(2) register: regAddr 0x8, fieldOff 10, fieldLen 2, data 0x1.
OK.
gvlnSetPortVlanDot1qMode Called.
Write to port(6) register: regAddr 0x8, fieldOff 10, fieldLen 2, data 0x1.
OK.
#####gvtuAddEntry Called.
 
Read from global register: regAddr 0x5, fOff 15, fLen 1, data 0x0.
Write to global register: phyAddr 0x1b, regAddr 0x7, data 0x3332.
Write to global register: phyAddr 0x1b, regAddr 0x8, data 0x233.
Write to global register: phyAddr 0x1b, regAddr 0x9, data 0x0.
Write to global register: phyAddr 0x1b, regAddr 0x6, data 0x1064.
Write to global register: phyAddr 0x1b, regAddr 0x3, data 0x9.
Write to global register: phyAddr 0x1b, regAddr 0x2, data 0x0.
Write to global register: phyAddr 0x1b, regAddr 0x5, data 0xb000.
gvtuFindVidEntry Called.
Read from global register: regAddr 0x5, fOff 15, fLen 1, data 0x0.
Write to global register: phyAddr 0x1b, regAddr 0x6, data 0xfff.
Write to global register: phyAddr 0x1b, regAddr 0x5, data 0xc000.
Read from global register: regAddr 0x5, fOff 15, fLen 1, data 0x1.
Read from global register: regAddr 0x5, fOff 15, fLen 1, data 0x0.
read from global register: phyAddr 0x1b, regAddr 0x6, data 0xfff.
Failed.

expected vid is 0x64 (100)

what would be the wrong?

regards

Nagendra

Hi there:  sorry...I've been super busy with current projects.  The only suggestion I have is the make sure the following VTU structure is zero'd out with a memset() and you HAVE to set DBNum to a known value.  Depending on the chip MV88E6185/6095 have only 255 forwarding databases for grouping ATUs for a VLAN.  I abstracted the DBNum (Aka FDB or forwarding database id) from the VLAN id because most chips wont have a 1:1 mapping.  As my driver is asked to add a VLAN, I allocate a free DBNum and track that with the VID.  As VIDs are removed, I free the DBNum for re-use.   Hope this helps...

Dennis

typedef struct
{
    GT_U16        DBNum;
    GT_U16        vid;
    GT_VTU_DATA   vtuData;
    GT_BOOL          vidPriOverride;
    GT_U8          vidPriority;
    GT_U8          sid;
    GT_BOOL          vidPolicy;
    GT_VTU_EXT_INFO    vidExInfo;
} GT_VTU_ENTRY;

      memset(&vtu, 0, sizeof(vtu));
      vtu.vid = vlan->vid;
      vtu.DBNum = dbnum;   
      vtu.sid = 1;         // may need to be dynamic later
     

     // init al the port membership here
      init_vid_members(i, &vtu.vtuData);

      if ((rc = gvtuAddEntry(&switchDev[i], &vtu)) != GT_OK)
      {
         pr_info("PSLMV: %s(): gvtuAddEntry() adding vtu entry with no members for VID/DBNUM: 0x%x/0x%x error: %x\n",
                 __FUNCTION__, vtu.vid, vtu.DBNum, rc);
       }

this helps.

thanks a lot

I am having another question about  port  trunk of marvell switch.Somebody can help me?

When I run the port runk example code in DSDT3.3，it returns OK。But the ports in the trunk group don't work correctly。All packets egress from one port.There is no packet from the other，Even if only this port is link up。

Can Somebody tell me what is the matter?

Hi:

you also have to set the per port VLANtable so that member ports in a trunk NEVER egress frame to other members, only to other ports or other trunks.  We had the same issue.  I believe it is switch port register #6.

Dennis

I  have read the docment named "using trunk with the 88E6095 and88E6185" of marvell. And there is another two more register than DSDT port trunk example code.One is port  register #b.Its 0:6 bits determines the PAV value.The other is register #6.Its 0:6 bits determines the Port based vlan value.

The function of Port based vlan ,you say right.It can prevent trunk loop.

But my question is :the packet ingress from a port that is not a member of a trunk.The packet is broadcast.And It egress from only a confirmed port that is a  member of  the trunk.

If  the confirmed port is not link up ,and another port that is a  member of the same trunk is link up,there is no packet .

It seems that the PAV vlaue is not correct.  But it is correct.So I am confused.

We never touched the PAV register as per the documentation.  The VLANtable setting prevented the trunk loop.  You have to set up the trunk bit on each port, the trunk routing table, the load balancing and load balance algorithm.  We haven't seen any problems especially since the frame you are sending is a broadcast.  I am assuming that you did not change the default behaviour on each port to egress unknown multicast frames and the global setting for treating broadcast frames as unknown multicasts (this last setting may not exist on the 6095/6185).  I assume that you are using the DSDT function calls because its so easy to make a mistake doing this manually.  Everything I read about the PAV had to do with ATU learning and cross chip VLAN/trunking.   If you discover that these PAV bits must be set for trunking members, please post your findings

thanks

Dennis

One more thing.  The sample code that sets up cross chip trunking does not seem to modify the PAV register.  We plan to use the 6185 and 6176 and documentation in 6176 added that you should use the trunking mask table and load balancing instead of the modifying the PAV.  I believe that setting the PAV is a rudimentary way of setting up trunking that may not use load balancing.  It doesn't explain why you're not seeing the BC frame tho.

Dennis

I tried ping request unicast packet ,there is no chang.

I modified reg 6 as you saied to clear the bits of other ports in the trunk,there is also no chang.

I used function "sampleCrossChipTrunk"with the only modification of clearing casecadeVec to zero,because the trunk is in one chip.not  cross chip.Am I correct?

PAV shoud not be modified when using trunk,otherise every port in the trunk egresses same packets,like not in a trunk.

I did not use their example, but yes, you don't need to set the cascade/DSA features if only using a single chip.  We used the following routines, but our driver code is written to add and remove a port as a member of a trunk and to get and set the load balance mode and table and the trunk members.

gsysGetTrunkRouting() - get current trunk membership (optional)

gsysSetTrunkRouting() - set the trunk membership

gprtSetTrunkPort() - set the individual port(s) trunk bit

gvlnGetPortVlanPorts() - get the per-port VLANtable setting (optional)

gvlnSetPortVlanPorts() - set the per-port VLANtable setting to prevent egress between trunk member ports

gsysGetTrunkMaskTable() - get the load balance table (optional)

gsysSetTrunkMaskTable() - setup the load balance table

gsysSetHashTrunk()  - to set the load balance mode/type

Those were the only calls we had to make to get the trunking working on 2 or more trunk members.  Sorry I cannot see anything obvious

Dennis