From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.9 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_PASS autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 3C9A7C43381 for ; Sun, 24 Feb 2019 21:42:14 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 04EC720842 for ; Sun, 24 Feb 2019 21:42:13 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="JEqymaVm" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726494AbfBXVmM (ORCPT ); Sun, 24 Feb 2019 16:42:12 -0500 Received: from mail-wm1-f68.google.com ([209.85.128.68]:52721 "EHLO mail-wm1-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725911AbfBXVmM (ORCPT ); Sun, 24 Feb 2019 16:42:12 -0500 Received: by mail-wm1-f68.google.com with SMTP id m1so6316166wml.2 for ; Sun, 24 Feb 2019 13:42:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=V2tSwItwHRQaeg84fgQcwrXiUS1qjD1ltH5JfL+Q81g=; b=JEqymaVm+fF+68HQXJ9NkkrE0AhfunVUZlqzOW/vKtW7+gkuRcEiEXKKptIEL+VoMq YHsIl0lUHAlPyHuDGNf7py2AvBB+S4ytyAB54gat1KKoe/1rA3gYglExMb7fqHEITgWD Xuqr4VAA318Qf73vn+9sf52m/FIkgMxAD5M0IahJgyDkpjUrt2Q9mbvuhKFE8J3rvD0J 4btXfDnV7AKal0+TlCRF8MwGa05LVQVxfe1u3X8bHnKpLRNnTCDeKbSurbSlJ60gIcIr Epn9jaFZWEd1f7KtZB7T7foBYQFzMyRseogA9Tvhwt/ChyUWecTC/xD5gO5DEnFR/PmQ f5uw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=V2tSwItwHRQaeg84fgQcwrXiUS1qjD1ltH5JfL+Q81g=; b=Hp+NWKRXVcBD/G+/IBg3SALOowxNmkY7l8/ym1CYn+EZ6fWlIBYvdZWgYpawyImrih 2LkZdgi/kKJ3hAF722xCL9ttP8Bc6ha4Zf/XS3cuHaauxb0P0KgaCpm6vDSbJrn+01Px dnnEZ/BpNcn8dRkfVKN5prDcZXj+Dr/8IkBrcVBm/bLPEbqYeVNPYDYwfs0AeKSFXbpZ 5oT7X6fwyDGE6Z/ooiYAkAEu05mVDc7zV5f+2PSRvwfert1pDU3RTBo9AJKg0afo4Pho 65A0gRI3rebyXK5HoF2qugwQddIBgXV3JlZvVf75+hnfmyierBmvxPZ5k6Bx0wwQxb3p OluA== X-Gm-Message-State: AHQUAuZA1R2Ln2epfaJHSuH9hBetjCsWsOPXzzZ+zqp18y8+7LwZouwb 4JzzMvyM87tPHXf+0cTXqN5NjM3f X-Google-Smtp-Source: AHgI3Ib4dCLzDqQx79Mroc0BvsnW0rN0GRPtdqKsduZ5bASDJHLLZbY/1D3RKH5H28nNbEeiIUstGw== X-Received: by 2002:a1c:14e:: with SMTP id 75mr8167951wmb.48.1551044529574; Sun, 24 Feb 2019 13:42:09 -0800 (PST) Received: from ?IPv6:2003:ea:8bf1:e200:1133:81d:72d3:c59f? (p200300EA8BF1E2001133081D72D3C59F.dip0.t-ipconnect.de. [2003:ea:8bf1:e200:1133:81d:72d3:c59f]) by smtp.googlemail.com with ESMTPSA id d21sm25195415wrc.44.2019.02.24.13.42.08 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 24 Feb 2019 13:42:08 -0800 (PST) Subject: Re: No traffic with Marvell switch and latest linux-next To: Florian Fainelli , Andrew Lunn Cc: Russell King - ARM Linux admin , "netdev@vger.kernel.org" References: <188fcef7-81fe-cffc-af71-1f37725b8611@gmail.com> <20190223234235.GA26626@lunn.ch> <6dd3f82a-eea0-c9b4-8dd6-f2f313578b1f@gmail.com> <20190224150403.GF26626@lunn.ch> <20190224151555.xsopwkuicsop65rw@shell.armlinux.org.uk> <403607a0-16d8-15b6-f0aa-b8b13793d401@gmail.com> <20190224153449.gg3c3fyryztdj3vm@shell.armlinux.org.uk> <20190224154900.jmjuh4uz2lvtankg@shell.armlinux.org.uk> <7005686d-45cb-a8af-de34-873c9e34a021@gmail.com> <20190224170455.GH26626@lunn.ch> <2B512084-E971-482D-81FC-B3CEEC1C26C5@gmail.com> From: Heiner Kallweit Message-ID: Date: Sun, 24 Feb 2019 22:42:03 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.5.1 MIME-Version: 1.0 In-Reply-To: <2B512084-E971-482D-81FC-B3CEEC1C26C5@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On 24.02.2019 22:26, Florian Fainelli wrote: > > > On February 24, 2019 9:04:55 AM PST, Andrew Lunn wrote: >>> The added difficulty here and the reason why Andrew went with the >>> approach that is used by the code currently is because neither do the >>> CPU or DSA ports are backed by a net_device. It is somewhere on my >> TODO >>> to permit the use of PHYLINK without the need of a net_device to >> cover >>> those specific DSA cases unless we just brute force the whole thing >> and >>> allocate a net_device structure but not register that net_device? Yes >> in >>> fact, why don't we do that? >> >> Hi Florian >> >> At the moment, we are using a phydev which is not connected to a >> MAC. That is rather odd, but the phylib maintainers mostly know about >> this, and keep an eye out for changes which might break any >> assumptions. And the phylib API is quite small. > > I would argue that this very thread is a proof against your argument since we all failed to predict that Heiner's changes would change those assumptions. Having a certain of assumptions is fine but given all the recent PHYLIB helpers that have been added I am not sure how well that will scale. > >> >> How many assumptions are going to break with a netdev which is not >> registered? The API is much bigger, more people hack on it, and it is >> going to be much harder to review changes to make sure assumptions are >> not changed. > > A non registered net_device appears easier to manage and debug since there is state tracking all over the network stack for those cases. > >> >> If we are going to do something odd, we should keep the scope as small >> as possible. > > Hence my suggestion to allocate a dummy net_device object just so calls to netif_carrier_{on,off} (and possibly more in the future) do nothing. I don't think that teaching either PHYLIB or PHYLINK about a NULL net_device is going to scale really well over time nor make it easier for respective maintainers. If we make the net_device optional, it will be harder to review changes as well as make sure that we do not create locking/object interactions issues. > > Another approach could be to define a minimal network port object (struct devlink, maybe?) which could be used independently from a net_device, or a lightweight net_device with no visibility into existing namespaces. None of these ideas are new though and would probably require several cycles to get done right. > > Heiner, Russell, which approach would you take? > Given my 2 days of experience with DSA (feels like 3 already) I would like to spend few more minutes on thinking before I answer. Heiner