Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
From:   Vladimir Oltean <vladimir.oltean@nxp.com>
To:     Horatiu Vultur <horatiu.vultur@microchip.com>
CC:     "davem@davemloft.net" <davem@davemloft.net>,
        "kuba@kernel.org" <kuba@kernel.org>,
        "jiri@resnulli.us" <jiri@resnulli.us>,
        "ivecera@redhat.com" <ivecera@redhat.com>,
        "nikolay@nvidia.com" <nikolay@nvidia.com>,
        "roopa@nvidia.com" <roopa@nvidia.com>,
        Claudiu Manoil <claudiu.manoil@nxp.com>,
        "alexandre.belloni@bootlin.com" <alexandre.belloni@bootlin.com>,
        "UNGLinuxDriver@microchip.com" <UNGLinuxDriver@microchip.com>,
        "andrew@lunn.ch" <andrew@lunn.ch>,
        "vivien.didelot@gmail.com" <vivien.didelot@gmail.com>,
        "f.fainelli@gmail.com" <f.fainelli@gmail.com>,
        "rasmus.villemoes@prevas.dk" <rasmus.villemoes@prevas.dk>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        "netdev@vger.kernel.org" <netdev@vger.kernel.org>,
        "bridge@lists.linux-foundation.org" 
        <bridge@lists.linux-foundation.org>
Subject: Re: [PATCH net-next v4 2/8] switchdev: mrp: Extend ring_role_mrp and
 in_role_mrp
Thread-Topic: [PATCH net-next v4 2/8] switchdev: mrp: Extend ring_role_mrp and
 in_role_mrp
Thread-Index: AQHXBKy9eGp+yjutnkaeTLTu5mS83apcJ5yAgABalICAAAL5gA==
Date:   Wed, 17 Feb 2021 16:09:23 +0000
Message-ID: <20210217160923.fimumxafloc6276i@skbuf>
References: <20210216214205.32385-1-horatiu.vultur@microchip.com>
 <20210216214205.32385-3-horatiu.vultur@microchip.com>
 <20210217103433.bilnuo2tfvgvjmxy@skbuf>
 <20210217155845.oegbmsnxykkqc6um@soft-dev3.localdomain>
In-Reply-To: <20210217155845.oegbmsnxykkqc6um@soft-dev3.localdomain>
Accept-Language: en-US
Content-Language: en-US
Content-Type: text/plain; charset="us-ascii"
Content-ID: <722080CF38BD8340897DAF4CA059A370@eurprd04.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: fe81a1fd-d947-4012-a783-08d8d35e6493
X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Feb 2021 16:09:23.9430
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 686ea1d3-bc2b-4c6f-a92c-d99c5c301635
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: y62K4bBMtxrK6rfL1wtBLs/Y2g057PygdzWphd9+8YzANxdO4c1vDNFUqGz1yNB0flHkLo5QwOMP/Q06cNw1Pw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR04MB6942
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Wed, Feb 17, 2021 at 04:58:45PM +0100, Horatiu Vultur wrote:
> > If a driver implements full MRP offload for a ring/interconnect
> > manager/automanager, should it return -EOPNOTSUPP when sw_backup=3Dfals=
e?
>=20
> In that case it should return 0.
> So if the driver can:
> - fully support MRP, when sw_backup =3D false, return 0. Then end of stor=
y.
> - partially support MRP, when sw_backup =3D false, return -EOPNOTSUPP,
>                          when sw_backup =3D true, return 0.
> - no support at all, return -EOPNOTSUPP.

Damn, I asked the wrong question.
I meant to ask about what it should return when sw_backup=3Dtrue.
But you answered anyway that if it returns 0 when sw_backup=3Dfalse, it
can simply not deal with the case where sw_backup=3Dtrue, because that is
never supposed to happen.=