Received: by 2002:a05:6a10:a852:0:0:0:0 with SMTP id d18csp3579116pxy; Tue, 4 May 2021 05:35:59 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxDYVrW4PiKCSdBizJn/HV0ebvnc+J5YYPn+4tYlyqM6eeET+MRcamDe5gtfnM/sIrOjDbw X-Received: by 2002:aa7:c9cf:: with SMTP id i15mr26271507edt.4.1620131759344; Tue, 04 May 2021 05:35:59 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1620131759; cv=none; d=google.com; s=arc-20160816; b=MKAEaGCJvHXmxxtE3iStA1Xues/P3SWjMhOjrBQ7iACbbEnv7sJXL0oVGNzHwJkfzy ZIqg4erUFJ6piWQL3/vT8TPyIz4fZbdqbf+atNc+Gj3OlBRtcEoQy2HXuu0wb2kpVcim HF2gqIqPVdLXrzicJv/7DrL5tFiEfxTY7P5inHE87YFSnpF3BjsYjvzXpqYAR7lvhmpX M6CJd33cl7uktEjDujXMQHi/M9fiio5kvol2TmetEqm0A4BfMDRItXRuqz0pTqqKH9oi 3bHPb5/2NwJfgkZoQOhpNjBkKNT2i/mOO9DlalHG1w8s0WdUonZHN0El5DOqMdDxR3fP 4vNg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date; bh=ndKRq8aZbFYAx/oJt8ccAi5HcWc0qEaDxFUJ3Toz3T8=; b=PndfoidZbt/6Fx/0AXG3wgv8e7NZIIoE3qBLXx6J9to8dewwSqfynv4fQBhFVGptOB RQ3IhXi62GWs0H6DQdz0Omwpewhov6vTem7PvO02Nara4zNqV+BwjXJUvnvVd0NUJGdP TQDlZP1NLzxIFkiBXsMG9Jsi3fJplcggtxHA/AOTR6N6+cdMOp2XxExb//qwSmLz0qlj eBs4O80mlCwbxKjYiPpsGScjnqpoiUvgP0HSn8Y/vKNJEBnpTDZIIj1PEYHHsN/Q0MfT wPiAwPFIJ88e9L58101sb/CjDs7TJuL6Ek7ghRkKtqgzwLFJx7MVdFbtsMh3RDnpKfKT Lxug== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id o7si2384986ejm.741.2021.05.04.05.35.32; Tue, 04 May 2021 05:35:59 -0700 (PDT) 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; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230366AbhEDMcu (ORCPT + 99 others); Tue, 4 May 2021 08:32:50 -0400 Received: from vps0.lunn.ch ([185.16.172.187]:52298 "EHLO vps0.lunn.ch" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230110AbhEDMcq (ORCPT ); Tue, 4 May 2021 08:32:46 -0400 Received: from andrew by vps0.lunn.ch with local (Exim 4.94) (envelope-from ) id 1lduD8-002Tjq-Qa; Tue, 04 May 2021 14:31:34 +0200 Date: Tue, 4 May 2021 14:31:34 +0200 From: Andrew Lunn To: Colin Foster Cc: Rob Herring , Vladimir Oltean , Claudiu Manoil , Alexandre Belloni , "supporter:OCELOT ETHERNET SWITCH DRIVER" , Vivien Didelot , Florian Fainelli , "David S. Miller" , Jakub Kicinski , Russell King , "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" , open list , "open list:OCELOT ETHERNET SWITCH DRIVER" Subject: Re: [RFC PATCH vN net-next 2/2] net: mscc: ocelot: add support for VSC75XX SPI control Message-ID: References: <20210504051130.1207550-1-colin.foster@in-advantage.com> <20210504051130.1207550-2-colin.foster@in-advantage.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210504051130.1207550-2-colin.foster@in-advantage.com> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, May 03, 2021 at 10:11:27PM -0700, Colin Foster wrote: > Add support for control for VSC75XX chips over SPI control. Starting with the > VSC9959 code, this will utilize a spi bus instead of PCIe or memory-mapped IO to > control the chip. Hi Colin Please fix your subject line for the next version. vN should of been v1. The number is important so we can tell revisions apart. > > Signed-off-by: Colin Foster > --- > arch/arm/boot/dts/rpi-vsc7512-spi-overlay.dts | 124 ++ > drivers/net/dsa/ocelot/Kconfig | 11 + > drivers/net/dsa/ocelot/Makefile | 5 + > drivers/net/dsa/ocelot/felix_vsc7512_spi.c | 1214 +++++++++++++++++ > include/soc/mscc/ocelot.h | 15 + Please split this patch up. The DT overlay will probably be merged via ARM SOC, not netdev. You also need to document the device tree binding, as a separate patch. > + fragment@3 { > + target = <&spi0>; > + __overlay__ { > + #address-cells = <1>; > + #size-cells = <0>; > + cs-gpios = <&gpio 8 1>; > + status = "okay"; > + > + vsc7512: vsc7512@0{ > + compatible = "mscc,vsc7512"; > + spi-max-frequency = <250000>; > + reg = <0>; > + > + ports { > + #address-cells = <1>; > + #size-cells = <0>; > + > + port@0 { > + reg = <0>; > + ethernet = <ðernet>; > + phy-mode = "internal"; > + > + fixed-link { > + speed = <1000>; > + full-duplex; > + }; > + }; > + > + port@1 { > + reg = <1>; > + label = "swp1"; > + status = "disabled"; > + }; > + > + port@2 { > + reg = <2>; > + label = "swp2"; > + status = "disabled"; > + }; I'm surprised all the ports are disabled. I could understand that for a DTSI file, but a DTS overlay? > +++ b/drivers/net/dsa/ocelot/felix_vsc7512_spi.c > @@ -0,0 +1,1214 @@ > +// SPDX-License-Identifier: (GPL-2.0 OR MIT) > +/* Copyright 2017 Microsemi Corporation > + * Copyright 2018-2019 NXP Semiconductors > + */ > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include "felix.h" > + > +#define VSC7512_TAS_GCL_ENTRY_MAX 63 > + > +// Note: These addresses and offsets are all shifted down > +// by two. This is because the SPI protocol needs them to > +// be before they get sent out. > +// > +// An alternative is to keep them standardized, but then > +// a separate spi_bus regmap would need to be defined. > +// > +// That might be optimal though. The 'Read' protocol of > +// the VSC driver might be much quicker if we add padding > +// bytes, which I don't think regmap supports. C style comments please. > +static void vsc7512_phylink_validate(struct ocelot *ocelot, int port, > + unsigned long *supported, > + struct phylink_link_state *state) > +{ > + struct ocelot_port *ocelot_port = ocelot->ports[port]; > + __ETHTOOL_DECLARE_LINK_MODE_MASK(mask) = { > + 0, > + }; This function seems out of place. Why would SPI access change what the ports are capable of doing? Please split this up into more patches. Keep the focus of this patch as being adding SPI support. Andrew