lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20211116153208.GB8651@DESKTOP-LAINLKC.localdomain>
Date:   Tue, 16 Nov 2021 07:32:08 -0800
From:   Colin Foster <colin.foster@...advantage.com>
To:     Vladimir Oltean <vladimir.oltean@....com>
Cc:     "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "linux-arm-kernel@...ts.infradead.org" 
        <linux-arm-kernel@...ts.infradead.org>,
        "linux-gpio@...r.kernel.org" <linux-gpio@...r.kernel.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        "Rafael J. Wysocki" <rafael@...nel.org>,
        Claudiu Manoil <claudiu.manoil@....com>,
        Alexandre Belloni <alexandre.belloni@...tlin.com>,
        "UNGLinuxDriver@...rochip.com" <UNGLinuxDriver@...rochip.com>,
        Andrew Lunn <andrew@...n.ch>,
        Vivien Didelot <vivien.didelot@...il.com>,
        Florian Fainelli <f.fainelli@...il.com>,
        "David S. Miller" <davem@...emloft.net>,
        Jakub Kicinski <kuba@...nel.org>,
        Ioana Ciornei <ioana.ciornei@....com>,
        Heiner Kallweit <hkallweit1@...il.com>,
        Russell King <linux@...linux.org.uk>,
        Lars Povlsen <lars.povlsen@...rochip.com>,
        Steen Hegelund <Steen.Hegelund@...rochip.com>,
        Linus Walleij <linus.walleij@...aro.org>,
        Philipp Zabel <p.zabel@...gutronix.de>,
        Heikki Krogerus <heikki.krogerus@...ux.intel.com>,
        Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
Subject: Re: [RFC PATCH v4 net-next 00/23] add support for VSC75XX control
 over SPI

On Tue, Nov 16, 2021 at 11:10:59AM +0000, Vladimir Oltean wrote:
> On Mon, Nov 15, 2021 at 10:23:05PM -0800, Colin Foster wrote:
> > My apologies for this next RFC taking so long. Life got in the way.
> > 
> > 
> > The patch set in general is to add support for the VSC7511, VSC7512,
> > VSC7513 and VSC7514 devices controlled over SPI. The driver is
> > relatively functional for the internal phy ports (0-3) on the VSC7512.
> > As I'll discuss, it is not yet functional for other ports yet.
> > 
> > I still think there are enough updates to bounce by the community
> > in case I'm terribly off base or doomed to chase my tail.
> > 
> 
> I would try to get rid of some of the patches now, instead of gathering
> a larger and larger pile. Here is a list of patches that I think could
> be submitted right away (possibly as part of independent series;
> parallelize as much as you can):
> 
> [01/23] net: dsa: ocelot: remove unnecessary pci_bar variables
> [02/23] net: mdio: mscc-miim: convert to a regmap implementation
> [03/23] net: dsa: ocelot: seville: utilize of_mdiobus_register
> [04/23] net: dsa: ocelot: felix: switch to mdio-mscc-miim driver for indirect mdio …
> [05/23] net: dsa: ocelot: felix: Remove requirement for PCS in felix devices
> [06/23] net: dsa: ocelot: felix: add interface for custom regmaps
> [07/23] net: dsa: ocelot: felix: add per-device-per-port quirks
> [08/23] net: mscc: ocelot: split register definitions to a separate file
> [09/23] net: mscc: ocelot: expose ocelot wm functions
> [18/23] net: phy: lynx: refactor Lynx PCS module to use generic phylink_pcs
> [19/23] net: dsa: felix: name change for clarity from pcs to mdio_device
> [20/23] net: dsa: seville: name change for clarity from pcs to mdio_device
> [21/23] net: ethernet: enetc: name change for clarity from pcs to mdio_device
> [22/23] net: pcs: lynx: use a common naming scheme for all lynx_pcs variables
> 
> Now that you've submitted them all already, let's wait for some feedback
> before resending smaller chunks.

Thank you for your response as always!

This will make v5 a lot easier for me to keep straight. I think this one
might also be a good one to submit earlier, since it actually does
change behavior:

pinctrl: ocelot: update pinctrl to automatic base address

I'd probably want to drag this trivial one along as well:

pinctrl: ocelot: combine get resource and ioremap into single call

> 
> > 
> > The main changes for V4 are trying to get pinctrl-ocelot and
> > pinctrl-microchip-sgpio functional. Without pinctrl-ocelot,
> > communication to external phys won't work. Without communication to
> > external phys, PCS ports 4-7 on the dev board won't work. Nor will any
> > fiber ports. 
> > 
> > 
> > The hardware setup I'm using for development is a beaglebone black, with
> > jumpers from SPI0 to the microchip VSC7512 dev board. The microchip dev 
> > board has been modified to not boot from flash, but wait for SPI. An
> > ethernet cable is connected from the beaglebone ethernet to port 0 of
> > the dev board.
> > 
> > 
> > The device tree I'm using for the VSC7512 is below. Note that ports 4-7
> > are still not expected to work, but left in as placeholders for when
> > they do.
> > 
> > 
> > &spi0 {
> > 	#address-cells = <1>;
> > 	#size-cells = <0>;
> > 	status = "okay";
> > 
> > 	ethernet-switch@0{
> > 		 compatible = "mscc,vsc7512";
> > 		 spi-max-frequency = <250000>;
> 
> Can't go faster than 250 KHz? That's sad.

Haven't tried faster speeds. During the early days there was an error on
my setup due to too long of wires. Crosstalk / capacitance... I slowed
the SPI bus to a crawl while debugging that and never turned it back up. 

If it'll help anyone: transitions on the MOSI I believe were causing
glitches on the CS line. This made the VSC7512 sad.

> 
> > 		 reg = <0>;
> > 
> > 		 ports {
> 
> there's an extra preceding space here, for all 4 lines from "compatible" to "ports".

I'll fix it. Thanks.

> 
> > 			#address-cells = <1>;
> > 			#size-cells = <0>;
> > 
> > 			port@0 {
> > 				reg = <0>;
> > 				label = "cpu";
> > 				status = "okay";
> > 				ethernet = <&mac_sw>;
> > 				phy-handle = <&sw_phy0>;
> > 				phy-mode = "internal";
> > 			};
> > 
> > 			port@1 {
> > 				reg = <1>;
> > 				label = "swp1";
> > 				status = "okay";
> > 				phy-handle = <&sw_phy1>;
> > 				phy-mode = "internal";
> > 			};
> > 
> > 			port@4 {
> > 				reg = <4>;
> > 				label = "swp4";
> > 				status = "okay";
> > 				phy-handle = <&sw_phy4>;
> > 				phy-mode = "sgmii";
> > 			};
> > 		};
> > 
> > 		mdio {
> > 			#address-cells = <1>;
> > 			#size-cells = <0>;
> > 
> > 			sw_phy0: ethernet-phy@0 {
> > 				#address-cells = <1>;
> > 				#size-cells = <0>;
> 
> PHY nodes don't need #address-cells and #size-cells.

Thank you. I'll remove these and the ones below.

> 
> > 				reg = <0x0>;
> > 			};
> > 
> > 			sw_phy1: ethernet-phy@1 {
> > 				#address-cells = <1>;
> > 				#size-cells = <0>;
> > 				reg = <0x1>;
> > 			};
> > 
> > 			sw_phy2: ethernet-phy@2 {
> > 				#address-cells = <1>;
> > 				#size-cells = <0>;
> > 				reg = <0x2>;
> > 			};
> > 
> > 			sw_phy3: ethernet-phy@3 {
> > 				#address-cells = <1>;
> > 				#size-cells = <0>;
> > 				reg = <0x3>;
> > 			};
> > 
> > 			sw_phy4: ethernet-phy@4 {
> > 				#address-cells = <1>;
> > 				#size-cells = <0>;
> > 				reg = <0x4>;
> > 			};
> > 
> > 			sw_phy5: ethernet-phy@5 {
> > 				#address-cells = <1>;
> > 				#size-cells = <0>;
> > 				reg = <0x5>;
> > 			};
> > 
> > 			sw_phy6: ethernet-phy@6 {
> > 				#address-cells = <1>;
> > 				#size-cells = <0>;
> > 				reg = <0x6>;
> > 			};
> > 
> > 			sw_phy7: ethernet-phy@7 {
> > 				#address-cells = <1>;
> > 				#size-cells = <0>;
> > 				reg = <0x7>;
> > 			};
> > 		};
> > 
> > 		gpio: pinctrl {
> > 			compatible = "mscc,ocelot-pinctrl";
> > 			#address-cells = <1>;
> > 			#size-cells = <0>;
> 
> I don't think that #address-cells and #size-cells are needed here, since
> "led-shift-reg-pins" does not have any address unit.
> 
> > 			#gpio_cells = <2>;
> > 			gpio-ranges = <&gpio 0 0 22>;
> > 
> > 			led_shift_reg_pins: led-shift-reg-pins {
> > 				pins = "GPIO_0", "GPIO_1", "GPIO_2", "GPIO_3";
> > 				function = "sg0";
> > 			};
> > 		};
> > 
> > 		sgpio: sgpio {
> > 			compatible = "mscc,ocelot-sgpio";
> > 			#address-cells = <1>;
> > 			#size-cells = <0>;
> > 			bus-frequency=<12500000>;
> > 			clocks = <&ocelot_clock>;
> > 			microchip,sgpio-port-ranges = <0 31>;
> > 
> > 			sgpio_in0: sgpio@0 {
> > 				compatible = "microchip,sparx5-sgpio-bank";
> > 				reg = <0>;
> > 				gpio-controller;
> > 				#gpio-cells = <3>;
> > 				ngpios = <32>;
> > 			};
> > 
> > 			sgpio_out1: sgpio@1 {
> > 				compatible = "microchip,sparx5-sgpio-bank";
> > 				reg = <1>;
> > 				gpio-controller;
> > 				gpio-cells = <3>;
> > 				ngpios = <32>;
> > 			};
> > 		};
> > 	};
> > };
> > 
> > 
> > My main focus is getting the ocelot-pinctrl driver fully functional. My
> > current hope is that it would correctly set GPIO pins 0-3 into the "sg0"
> > state. That is not the case right now, and I'll be looking into why. The
> > behavior I'm hoping for is to be able to configure the sgpio LEDs for
> > activity at the very least. Link status would be a bonus.
> > 
> > 
> > I do have pinctrl by way of debugfs and sysfs. There aren't any debug
> > LEDs that are attached to unused pins, unfortunately. That would've been
> > really helpful. So there's a key takeaway for dev-board manufacturers.
> > 
> > 
> > As you'll see, the main changes to the three drivers I'm utilizing
> > (mscc_miim, pinctrl-ocelot, and pinctrl-microchip-sgpio) follow a
> > similar path. First, convert everything to regmap. Second, expose
> > whatever functions are necessary to fully utilize an external regmap.
> > 
> > 
> > One thing to note: I've been following a pattern of adding "offset"
> > variables to these drivers. I'm looking for feedback here, because I
> > don't like it - however I feel like it is the "least bad" interface I
> > could come up with. 
> > 
> > 
> > Specifically, ocelot has a regmap for GCB. ocelot-pinctrl would create a
> > smaller regmap at an address of "GCB + 0x34".
> > 
> > 
> > There are three options I saw here:
> > 1. Have vsc7512_spi create a new regmap at GCB + 0x34 and pass that to
> > ocelot-pinctrl
> > 2. Give ocelot-pinctrl the concept of a "parent bus" by which it could
> > request a regmap. 
> > 3. Keep the same GCB regmap, but pass in 0x34 as an offset.
> > 
> > 
> > I will admit that option 2 sounds very enticing, but I don't know if
> > that type of interaction exists. If not, implementing it is probably
> > outside the scope of a first patch set. As such, I opted for option 3.
> 
> I think that type of interaction is called "mfd", potentially even "syscon".

Before diving in, I'd come across mfd and thought that might be the
answer. I'll reconsider it now that I have several months of staring at
kernel code under my belt. Maybe an mfd that does SPI setup and chip
resetting. Then I could remove all SPI code from ocelot_vsc7512_spi.

> 
> > 
> > 
> > Version 4 also fixes some logic for MDIO probing. It wasn't using the
> > device tree by way of of_mdiobus_register. Now it is.
> > 
> > 
> > The relevant boot log for the switch / MDIO bus is here. As expected,
> > devices 4-7 are missing. If nothing else, that is telling me that the
> > device tree is working.
> > 
> > [    4.005195] mdio_bus spi0.0-mii:03: using lookup tables for GPIO lookup
> > [    4.005205] mdio_bus spi0.0-mii:03: No GPIO consumer reset found
> > [    4.006586] mdio_bus spi0.0-mii: MDIO device at address 4 is missing.
> > [    4.014333] mdio_bus spi0.0-mii: MDIO device at address 5 is missing.
> > [    4.022009] mdio_bus spi0.0-mii: MDIO device at address 6 is missing.
> > [    4.029573] mdio_bus spi0.0-mii: MDIO device at address 7 is missing.
> > [    8.386624] vsc7512 spi0.0: PHY [spi0.0-mii:00] driver [Generic PHY] (irq=POLL)
> > [    8.397222] vsc7512 spi0.0: configuring for phy/internal link mode
> > [    8.419484] vsc7512 spi0.0 swp1 (uninitialized): PHY [spi0.0-mii:01] driver [Generic PHY] (irq=POLL)
> > [    8.437278] vsc7512 spi0.0 swp2 (uninitialized): PHY [spi0.0-mii:02] driver [Generic PHY] (irq=POLL)
> > [    8.452867] vsc7512 spi0.0 swp3 (uninitialized): PHY [spi0.0-mii:03] driver [Generic PHY] (irq=POLL)
> > [    8.465007] vsc7512 spi0.0 swp4 (uninitialized): no phy at 4
> > [    8.470721] vsc7512 spi0.0 swp4 (uninitialized): failed to connect to PHY: -ENODEV
> > [    8.478388] vsc7512 spi0.0 swp4 (uninitialized): error -19 setting up PHY for tree 0, switch 0, port 4
> > [    8.489636] vsc7512 spi0.0 swp5 (uninitialized): no phy at 5
> > [    8.495371] vsc7512 spi0.0 swp5 (uninitialized): failed to connect to PHY: -ENODEV
> > [    8.502996] vsc7512 spi0.0 swp5 (uninitialized): error -19 setting up PHY for tree 0, switch 0, port 5
> > [    8.514186] vsc7512 spi0.0 swp6 (uninitialized): no phy at 6
> > [    8.519882] vsc7512 spi0.0 swp6 (uninitialized): failed to connect to PHY: -ENODEV
> > [    8.527539] vsc7512 spi0.0 swp6 (uninitialized): error -19 setting up PHY for tree 0, switch 0, port 6
> > [    8.538716] vsc7512 spi0.0 swp7 (uninitialized): no phy at 7
> > [    8.544451] vsc7512 spi0.0 swp7 (uninitialized): failed to connect to PHY: -ENODEV
> > [    8.552079] vsc7512 spi0.0 swp7 (uninitialized): error -19 setting up PHY for tree 0, switch 0, port 7
> > [    8.571962] device eth0 entered promiscuous mode
> > [    8.576684] DSA: tree 0 setup
> > [   10.490093] vsc7512 spi0.0: Link is Up - 100Mbps/Full - flow control off
> > 
> > 
> > Much later on, I created a bridge with STP (and two ports jumped
> > together) as a test. Everything seems to be working as expected. 
> > 
> > 
> > [59839.920340] cpsw-switch 4a100000.switch: starting ndev. mode: dual_mac
> > [59840.013636] SMSC LAN8710/LAN8720 4a101000.mdio:00: attached PHY driver (mii_bus:phy_addr=4a101000.mdio:00, irq=POLL)
> > [59840.031444] 8021q: adding VLAN 0 to HW filter on device eth0
> > [59840.057406] vsc7512 spi0.0 swp1: configuring for phy/internal link mode
> > [59840.089302] vsc7512 spi0.0 swp2: configuring for phy/internal link mode
> > [59840.121514] vsc7512 spi0.0 swp3: configuring for phy/internal link mode
> > [59840.167589] br0: port 1(swp1) entered blocking state
> > [59840.172818] br0: port 1(swp1) entered disabled state
> > [59840.191078] device swp1 entered promiscuous mode
> > [59840.224855] br0: port 2(swp2) entered blocking state
> > [59840.229893] br0: port 2(swp2) entered disabled state
> > [59840.245844] device swp2 entered promiscuous mode
> > [59840.270839] br0: port 3(swp3) entered blocking state
> > [59840.276003] br0: port 3(swp3) entered disabled state
> > [59840.291674] device swp3 entered promiscuous mode
> > [59840.663239] vsc7512 spi0.0: Link is Down
> > [59841.691641] vsc7512 spi0.0: Link is Up - 100Mbps/Full - flow control off
> > [59842.167897] cpsw-switch 4a100000.switch eth0: Link is Up - 100Mbps/Full - flow control off
> > [59842.176481] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
> > [59843.216121] vsc7512 spi0.0 swp1: Link is Up - 1Gbps/Full - flow control rx/tx
> > [59843.231076] IPv6: ADDRCONF(NETDEV_CHANGE): swp1: link becomes ready
> > [59843.237593] br0: port 1(swp1) entered blocking state
> > [59843.242629] br0: port 1(swp1) entered listening state
> > [59843.301447] vsc7512 spi0.0 swp3: Link is Up - 1Gbps/Full - flow control rx/tx
> > [59843.309027] IPv6: ADDRCONF(NETDEV_CHANGE): swp3: link becomes ready
> > [59843.315544] br0: port 3(swp3) entered blocking state
> > [59843.320545] br0: port 3(swp3) entered listening state
> > [59845.042058] br0: port 3(swp3) entered blocking state
> > [59858.401566] br0: port 1(swp1) entered learning state
> > [59871.841910] br0: received packet on swp1 with own address as source address (addr:24:76:25:76:35:37, vlan:0)
> > [59873.761495] br0: port 1(swp1) entered forwarding state
> > [59873.766703] br0: topology change detected, propagating
> > [59873.776278] IPv6: ADDRCONF(NETDEV_CHANGE): br0: link becomes ready
> > [59902.561908] br0: received packet on swp1 with own address as source address (addr:24:76:25:76:35:37, vlan:0)
> > [59926.494446] vsc7512 spi0.0 swp2: Link is Up - 1Gbps/Full - flow control rx/tx
> > [59926.501959] IPv6: ADDRCONF(NETDEV_CHANGE): swp2: link becomes ready
> > [59926.508702] br0: port 2(swp2) entered blocking state
> > [59926.513868] br0: port 2(swp2) entered listening state
> > [59941.601540] br0: port 2(swp2) entered learning state
> > [59956.961493] br0: port 2(swp2) entered forwarding state
> > [59956.966711] br0: topology change detected, propagating
> > [59968.481839] br0: received packet on swp1 with own address as source address (addr:24:76:25:76:35:37, vlan:0)
> > 
> > 
> > In order to make this work, I have modified the cpsw driver, and now the
> > cpsw_new driver, to allow for frames over 1500 bytes. Otherwise the
> > tagging protocol will not work between the beaglebone and the VSC7512. I
> > plan to eventually try to get those changes in mainline, but I don't
> > want to get distracted from my initial goal.
> > 
> > 
> > RFC history:
> > v1 (accidentally named vN)
> > 	* Initial architecture. Not functional
> > 	* General concepts laid out
> > 
> > v2
> > 	* Near functional. No CPU port communication, but control over all
> > 	external ports
> > 	* Cleaned up regmap implementation from v1
> > 
> > v3
> > 	* Functional
> > 	* Shared MDIO transactions routed through mdio-mscc-miim
> > 	* CPU / NPI port enabled by way of vsc7512_enable_npi_port /
> > 	felix->info->enable_npi_port
> > 	* NPI port tagging functional - Requires a CPU port driver that supports
> > 	frames of 1520 bytes. Verified with a patch to the cpsw driver
> > 
> > v4
> >     * Functional
> >     * Device tree fixes
> >     * Add hooks for pinctrl-ocelot - some functionality by way of sysfs
> >     * Add hooks for pinctrl-microsemi-sgpio - not yet fully functional
> >     * Remove lynx_pcs interface for a generic phylink_pcs. The goal here
> >     is to have an ocelot_pcs that will work for each configuration of
> >     every port. 
> > 
> > 
> > 
> > Colin Foster (23):
> >   net: dsa: ocelot: remove unnecessary pci_bar variables
> >   net: mdio: mscc-miim: convert to a regmap implementation
> >   net: dsa: ocelot: seville: utilize of_mdiobus_register
> >   net: dsa: ocelot: felix: switch to mdio-mscc-miim driver for indirect
> >     mdio access
> >   net: dsa: ocelot: felix: Remove requirement for PCS in felix devices
> >   net: dsa: ocelot: felix: add interface for custom regmaps
> >   net: dsa: ocelot: felix: add per-device-per-port quirks
> >   net: mscc: ocelot: split register definitions to a separate file
> >   net: mscc: ocelot: expose ocelot wm functions
> >   pinctrl: ocelot: combine get resource and ioremap into single call
> >   pinctrl: ocelot: update pinctrl to automatic base address
> >   pinctrl: ocelot: convert pinctrl to regmap
> >   pinctrl: ocelot: expose ocelot_pinctrl_core_probe interface
> >   pinctrl: microchip-sgpio: update to support regmap
> >   device property: add helper function fwnode_get_child_node_count
> >   pinctrl: microchip-sgpio: change device tree matches to use nodes
> >     instead of device
> >   pinctrl: microchip-sgpio: expose microchip_sgpio_core_probe interface
> >   net: phy: lynx: refactor Lynx PCS module to use generic phylink_pcs
> >   net: dsa: felix: name change for clarity from pcs to mdio_device
> >   net: dsa: seville: name change for clarity from pcs to mdio_device
> >   net: ethernet: enetc: name change for clarity from pcs to mdio_device
> >   net: pcs: lynx: use a common naming scheme for all lynx_pcs variables
> >   net: dsa: ocelot: felix: add support for VSC75XX control over SPI
> > 
> >  drivers/base/property.c                       |  20 +-
> >  drivers/net/dsa/ocelot/Kconfig                |  16 +
> >  drivers/net/dsa/ocelot/Makefile               |   7 +
> >  drivers/net/dsa/ocelot/felix.c                |  29 +-
> >  drivers/net/dsa/ocelot/felix.h                |  10 +-
> >  drivers/net/dsa/ocelot/felix_mdio.c           |  54 +
> >  drivers/net/dsa/ocelot/felix_mdio.h           |  13 +
> >  drivers/net/dsa/ocelot/felix_vsc9959.c        |  38 +-
> >  drivers/net/dsa/ocelot/ocelot_vsc7512_spi.c   | 946 ++++++++++++++++++
> >  drivers/net/dsa/ocelot/seville_vsc9953.c      | 136 +--
> >  .../net/ethernet/freescale/dpaa2/dpaa2-mac.c  |  12 +-
> >  .../net/ethernet/freescale/dpaa2/dpaa2-mac.h  |   3 +-
> >  .../net/ethernet/freescale/enetc/enetc_pf.c   |  27 +-
> >  .../net/ethernet/freescale/enetc/enetc_pf.h   |   4 +-
> >  drivers/net/ethernet/mscc/Makefile            |   3 +-
> >  drivers/net/ethernet/mscc/ocelot.c            |   8 +
> >  drivers/net/ethernet/mscc/ocelot_devlink.c    |  31 +
> >  drivers/net/ethernet/mscc/ocelot_vsc7514.c    | 548 +---------
> >  drivers/net/ethernet/mscc/vsc7514_regs.c      | 522 ++++++++++
> >  drivers/net/mdio/mdio-mscc-miim.c             | 167 +++-
> >  drivers/net/pcs/pcs-lynx.c                    |  36 +-
> >  drivers/pinctrl/pinctrl-microchip-sgpio.c     | 127 ++-
> >  drivers/pinctrl/pinctrl-ocelot.c              | 207 ++--
> >  include/linux/mdio/mdio-mscc-miim.h           |  19 +
> >  include/linux/pcs-lynx.h                      |   9 +-
> >  include/linux/property.h                      |   1 +
> >  include/soc/mscc/ocelot.h                     |  60 ++
> >  include/soc/mscc/vsc7514_regs.h               |  27 +
> >  28 files changed, 2219 insertions(+), 861 deletions(-)
> >  create mode 100644 drivers/net/dsa/ocelot/felix_mdio.c
> >  create mode 100644 drivers/net/dsa/ocelot/felix_mdio.h
> >  create mode 100644 drivers/net/dsa/ocelot/ocelot_vsc7512_spi.c
> >  create mode 100644 drivers/net/ethernet/mscc/vsc7514_regs.c
> >  create mode 100644 include/linux/mdio/mdio-mscc-miim.h
> >  create mode 100644 include/soc/mscc/vsc7514_regs.h
> > 
> > -- 
> > 2.25.1
> >

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ