From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 8DD9F21B191 for ; Sat, 2 May 2026 01:08:45 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777684125; cv=none; b=iDPfTXhViVwvSkBIWtoQJA6Mg0ueEuyQ6yj4hSoSSMxyLCaSjMfzdKMVCa2wMhozZOL0jm1GD1ZtMwrcZFATnLBnxBE0s4KoPYRrjRgWvK4dbPlKEGahYrCefDyW8aJPnC6rU6vQ0MtK0MYPhm7sMCUan4JV5it6J+n7NtzYs8s= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777684125; c=relaxed/simple; bh=GE7ayZZUnp1+H5pAYeXAy6WshAkBccp/jibpYS9WOQ4=; h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=FsaRAwn9V/okHVi2iCExceo5IXaWk7RfpD9frKZCVlMmMvogStyfvUVh0m7EQNhZsfPd2RztaPDMYHjbqulIkQz/WVq2dpaq1JbWP5K5FgROxh2V/XaHXrLyjN0xnJv/r0Q83zWk7vop1LcK6zw3cLsDHmAHWMOjEEfAgZTM6A8= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=gdKJhbY3; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="gdKJhbY3" Received: by smtp.kernel.org (Postfix) with ESMTPSA id EA547C2BCB4; Sat, 2 May 2026 01:08:44 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1777684125; bh=GE7ayZZUnp1+H5pAYeXAy6WshAkBccp/jibpYS9WOQ4=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=gdKJhbY3EH+xSFrApv2Ujvp9eXLClNlnoaLsDRYTTpew5AG1azLVai0NyjX0Tu/fP JE4IKsgQ3A5D2bbxvZZnFXCVaCOVkP+0QX2TJ+9e8QPGwLSfS4VgIrUo665qL7XeRq wGKIIuBdfwDFB91+uhcCeRvpK/nKzahVHyPhq4FMg9ZSGXiaWbC4mwYBsAHM6UQm4G P6UEQyOSEMpenyGYSl9tIhXJkkef2S8Pnms4ftgqallP+51hYwwgdhRTw8Y8reqxcF 7e6kQP31BfQRP/tIH6i1U1xG775TYMkqIIjgJAPo9Gd7C16k4HR961GBcZKjxEdg5R QzWja4y3+2j1A== Date: Fri, 1 May 2026 18:08:43 -0700 From: Jakub Kicinski To: Ido Schimmel Cc: netdev@vger.kernel.org, davem@davemloft.net, pabeni@redhat.com, edumazet@google.com, andrew+netdev@lunn.ch, horms@kernel.org, petrm@nvidia.com Subject: Re: [PATCH net-next 1/3] net: Do not unconditionally turn on carrier when clearing protodown Message-ID: <20260501180843.069635aa@kernel.org> In-Reply-To: <20260429124624.835335-2-idosch@nvidia.com> References: <20260429124624.835335-1-idosch@nvidia.com> <20260429124624.835335-2-idosch@nvidia.com> Precedence: bulk X-Mailing-List: netdev@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit On Wed, 29 Apr 2026 15:46:22 +0300 Ido Schimmel wrote: > Solve this by adding a new NDO that allows different drivers to react > differently to protodown being cleared. Change the core to invoke the > NDO and implement it for vxlan and macvlan. Maintain the current > behavior for the former, but for macvlan implement the NDO by > transferring the operational state from its lower device. Maybe just me but an NDO for this seems like an overkill. Isn't our range of options for the callback either follow lower or carrier on? Do you expect more complex logic?