> *After this patch set*: goal keep things working the same as max as
> possible and get rid of TI custom tool.
We are happy to keep things the same, if they fit with the switchdev
model. Anything in your customer TI tool/model which does not fit the
switchdev model you won't be able to keep, except if we agree to
extend the model.
I can say now, sw0p0 is going to cause problems. I really do suggest
you drop it for the moment in order to get a minimal driver
accepted. sw0p0 does not fit the switchdev model.
> Below I've described some tested use cases (not include full static
> configuration),
> but regarding sw0p0 - there is work done by Ivan Khoronzhuk [1] which enables
> adds MQPRIO and CBS Qdisc and targets AVB network features. It required to
> offload MQPRIO and CBS parameters on all ports including P0. In case of P0,
> CPDMA TX channels shapers need to be configured, and in case
> of sw0p1/sw0p2 internal FIFOS.
> sw0p0 also expected to be used to configure CPDMA interface in general -
> number of tx/rx channels, rates, ring sizes.
Can this be derives from the configuration on sw0p1 and sw0p2?
sw0p1 has 1 tx channel, sw0p2 has 2 tx channels, so give p0 3 tx
channels?
> In addition there is set of global CPSW parameters (not related to P1/P2, like
> MAC Authorization Mode, OUI Deny Mode, crc ) which I've
> thought can be added to sw0p0 (using ethtool -priv-flags).
You should describe these features, and then we can figure out how
best to model them. devlink might be an option if they are switch
global.
Andrew
