Hi Paolo,
> On Tue, 2023-08-29 at 14:11 +0200, Lukasz Majewski wrote:
> > Information about HSR aware ports in a DSA switch can be helpful
> > when one needs tags to be adjusted before the HSR frame is sent.
> >
> > For example - with ksz9477 switch - the TAG needs to be adjusted to
> > have both HSR ports marked in tag to allow execution of HW based
> > frame duplication.
> >
> > Signed-off-by: Lukasz Majewski <[email protected]>
> > ---
> > include/net/dsa.h | 3 +++
> > 1 file changed, 3 insertions(+)
> >
> > diff --git a/include/net/dsa.h b/include/net/dsa.h
> > index d309ee7ed04b..15274afc42bb 100644
> > --- a/include/net/dsa.h
> > +++ b/include/net/dsa.h
> > @@ -470,6 +470,9 @@ struct dsa_switch {
> > /* Number of switch port queues */
> > unsigned int num_tx_queues;
> >
> > + /* Bitmask indicating ports supporting HSR */
> > + u16 hsr_ports;
> > +
> > /* Drivers that benefit from having an ID associated with
> > each
> > * offloaded LAG should set this to the maximum number of
> > * supported IDs. DSA will then maintain a mapping of _at
>
> Out of sheer ignorance, I think this new field does not belong to
> dsa_switch, at least not in this form. AFAICS there is no current hard
> limitation on the number of ports a DSA switch can handle at the API
> level, and this will introduce an hard one.
>
> I think you are better off keeping this field in the KSZ-specific
> struct.
That was mine first idea - to move it to struct ksz_device from
./drivers/net/dsa/ksz_common.h
However, this file and this struct is not easily accessible from
net/dsa/tag_ksz.c
One idea was to use an exported function - e.g. ksz_get_hsr_ports() and
in it I would read the hsr_ports member ?
Another option would be to loop through all switch ports with
hsr_for_each_port(), but this would affect overall network performance.
> If you really want to keep it here you should remove the above
> limitation somehow (possibly a query op to check if a given port is
> HSR aware???)
I will use the idea of exported helper function to get HSR members
ports.
>
> In any case this series looks like net-next material, does not apply
> correctly to net-next and net-next is currently closed. You can share
> a new version as RFC or wait for net-next to re-open in ~2w.
>
I will prepare v2 and then adjust it to net-next when required.
> Cheers,
>
> Paolo
>
Best regards,
Lukasz Majewski
--
DENX Software Engineering GmbH, Managing Director: Erika Unter
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: [email protected]