Received: by 2002:ac0:a5a6:0:0:0:0:0 with SMTP id m35-v6csp10441imm; Thu, 30 Aug 2018 07:10:38 -0700 (PDT) X-Google-Smtp-Source: ANB0Vda+Mzm4OARpZg+r76ohXD3qUbcVJOyRDy/wKfRW9dTIfS9jcZ3HU70WZXn1InBHIKZApKRX X-Received: by 2002:a17:902:7587:: with SMTP id j7-v6mr10551897pll.256.1535638238575; Thu, 30 Aug 2018 07:10:38 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1535638238; cv=none; d=google.com; s=arc-20160816; b=i8KHZfsQNHj/TtxMOiMWKm+D2cAAqzi4JhrInX3r2CPbk5DLy0ax7+LxyGql1MSJEV lNg6+itCVPKUI1YjYmEvk0W2C4Gquzq3JZ1a8zbwNcFlMxrqP+mL3hUFHg6ZS2SSG01B XOBXdS34fDCHXdfpJpCkHU5RXd3w23iruHuY7rXavqUj62Ml8nabWo73re2xuIXTwPsr fBFdqReIjl3SmgQhfQ9YSxPGb2PE1cS3fA+Y1GXIBk8IyrnRSfDQ/2jqnSXF13m9lQnP 27/7Nsu0ZT28niGwjboFAKKJb3WFoVxMAD+UuqQXbZKy+faSbC0EkZLMIvb5r589C9xe Ixhg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:arc-authentication-results; bh=tHZHt0ye/IrA8JrqHHfSjYTcILdqtj7X4aGCmlABFZk=; b=X8K85w+ZmVXPduAyRibmgGjnK+yDFyIDxrsKieyxTC3rubnjz4Pw4nmLpWj+hfDwK8 q7NtHn9mV+iHoM6nY7Dc7eIxFf1WKkjLI8netCZ5/KNTIvcntvX3wYspcaRGl3fpf2hi nsbGAsdPjOPqMxbcvPcvU9fnN3m2kiRDTyVZdramFFAh2ingniS/1G5VFLTRNL2SFznU e32ty51OVH+9XqRNTDOlPzp7D7/eYzEesXhe3a1brBCTkY1bKK8PZMyukFU4b1uPnedB bfcdfblJAIU7thPEOBSWhjbIbpsPyCuc7yrsgNYCoVCtl45dnAONL8bINncnaz+XgFgl uGoA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id g12-v6si6312632plt.259.2018.08.30.07.10.19; Thu, 30 Aug 2018 07:10:38 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729103AbeH3SKO (ORCPT + 99 others); Thu, 30 Aug 2018 14:10:14 -0400 Received: from mail-qt0-f195.google.com ([209.85.216.195]:37408 "EHLO mail-qt0-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729000AbeH3SKO (ORCPT ); Thu, 30 Aug 2018 14:10:14 -0400 Received: by mail-qt0-f195.google.com with SMTP id n6-v6so9957534qtl.4; Thu, 30 Aug 2018 07:07:55 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=tHZHt0ye/IrA8JrqHHfSjYTcILdqtj7X4aGCmlABFZk=; b=CRPdJWyuYZGP+euD0bVjR2D9reCWEV0omFkUtLM1swH+il4OPEWKtBtWGHT/GnTlnT eHeIO2i7AZOiOcmBePLVt1/rKS5h0kMuG+EXSnTxlSybkuSViFC4sA3oBzuH1kXwNXdu 4NfDDaNOuMjiAtBoZnT9kMdxJaI9j/2RKd5fb/ypN1Td4PdPfmX5S4oIBEn9CtjuPkR4 T4S5VIIwcwvUR9yeSEFqpqkdE+7TdBTtFn3hMId5xauaebVgKW2qG8AvZqjRF9qiBEUk dmjec2eueeVuEkftT2v0gMKUNJzxkQs+qPDqzQ2bnXj2ByD0xIVCqFp1L5uHHwVwdMEF DTmA== X-Gm-Message-State: APzg51AAra8Z3xL8pUm68i6AaB1I9qqIEtrTJJjzX2k8A65lWEzvrUA2 Nb7R5T5LA/TPEy+tZKnGz5ESUI9q9x8HHpF/b7s= X-Received: by 2002:a37:6b03:: with SMTP id g3-v6mr11433010qkc.107.1535638075157; Thu, 30 Aug 2018 07:07:55 -0700 (PDT) MIME-Version: 1.0 References: <1535453838-12154-1-git-send-email-sunil.kovvuri@gmail.com> <1535453838-12154-12-git-send-email-sunil.kovvuri@gmail.com> In-Reply-To: From: Arnd Bergmann Date: Thu, 30 Aug 2018 16:07:39 +0200 Message-ID: Subject: Re: [PATCH 11/15] soc: octeontx2: Add Marvell OcteonTX2 CGX driver To: Sunil Kovvuri Cc: Linux Kernel Mailing List , Olof Johansson , Linux ARM , linux-soc@vger.kernel.org, sgoutham@marvell.com Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Aug 28, 2018 at 3:10 PM Sunil Kovvuri wrote: > > > > > If this is a regular PCI ethernet driver, why do you put it into driver/soc > > > > rather than drivers/net/ethernet/ ? > > > > > > No, this is not a ethernet driver, as mentioned in the cover letter > > > this driver and AF driver doesn't > > > handle any IO. There will be a separate ethernet driver (will submit > > > that as well in future) which will > > > communicate with these drivers for configuring hardware. > > > > > > The driver in question here is for a serdes controller which handles > > > physical ethernet interfaces. > > > Admin function driver gathers info w.r.t current state of physical > > > ethernet interfaces from this driver > > > and notifies actual ethernet driver about changes, if any. > > > > Ok. Can you describe the structure that the PCI devices appear > > in? It might help to be make the connection between the differnet > > patches to understand how things fit together. In the final > > picture, how many different pci_driver instances do you have, > > and what part are they for? > > List of PCI devices are CGX, RVU PF0-PFn SRIOV physical functions > and RVU VF0-VFn SRIOV virtual functions. No of VFs per PF is configurable > and done by low level firmware. > > List of PCI driver instances would be CGX driver, RVU PF0 (i.e admin > function) driver, > PF1-PFn either netdev driver or crypto driver, VF0-VFn functionality would be > same as their PF. > > The current plan is to have CGX driver, Admin function driver, PF > netdev driver, > VF netdev driver and PF/VF crypto drivers. Ok, I think I understand the PF/VF distinction now. One (to me) surprising aspect here is that you not just have one physical function that you can use to assign resources to multiple virtual functions, but also a second level of virtualization that is used to assign resources to "physical functions" that are less physical than the name suggests. The part that I have not grasped yet is what the split between the CGX and the AF is for, how they relate to one another, and what the software abstraction for the two is going to be. > > Is the idea that an ethernet device driver always attaches to a > > virtual function that gets created by the main driver, and that > > the two drivers share no interfaces on the kernel side, or do > > you have multiple drivers linking to each other? > > Ethernet device driver can attach to both physical function and virtual function > whose HW resources are provisioned by admin function driver. > > Yes the PF/VF ethernet drivers and these drivers won't share any > kernel interfaces. > Physical ethernet interface is owned by ethernet driver only, this driver just > configures which ethernet driver instance uses which physcial interface. Ok. Arnd