Received: by 2002:ac0:a5a7:0:0:0:0:0 with SMTP id m36-v6csp935505imm; Wed, 25 Jul 2018 08:37:42 -0700 (PDT) X-Google-Smtp-Source: AAOMgpc3LzPIkNbCY4DHfM/K0MDdtP6Gh0kbG5ELLah/8oq/CoUceOFW8ijTku2MCeUqG5xg32LR X-Received: by 2002:a63:5758:: with SMTP id h24-v6mr20957811pgm.432.1532533062586; Wed, 25 Jul 2018 08:37:42 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1532533062; cv=none; d=google.com; s=arc-20160816; b=wjlfb1CaSGF9ob/fB/QLV2jHmXAOn033ebXEnC8zWd3K7CUpCj0dv7tW6r5Baa56pq 2gWwdloLEyOOuHuj1+ct2xr+eXD90pbyH8nZFMKdmuva0RxvZEev2TUsS5S4cAdPPVfF LqtFU/Mx7N2ffu1W/Bpa4lcvtbsHti9Jlt2nIb5jGc6GPB1RNX6q2L+Om1RpnyUWUWyF 4EPniqFxJCTslzE3BKh/c06D2cncs8+3n7V+qD2/qO/UYKeXZFhtGXinh63eECBleOC+ EMvNEB6lv86Rjlm3LetSiVFtmFQq3VrPiWUcb62hXj23SqoyHO/XzBu7fdLMifUAyRMi kDvA== 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 :references:in-reply-to:mime-version:dkim-signature :arc-authentication-results; bh=CFpnJi8I/M/3ucNGiOuK9pEy8pI5jgFXgNNC8yIw3bs=; b=IyQEZ+exWvME8XCWFDyqH0vxTetQ5hl9zeSFth9gyHK/dHpgjdIHsMkLFG1zN1pmaU p25NPAOsv8KBuT9QyWYDwJButJ2YrUBEtMyQMpBLwsn3K5KTIWbO+q/F3+ko15VRruwz e9fGi6WfGqXtnaj4IXqCezNV4IbrHgIF/Qa3TW3IJXQ1F1x8/LCpSq2GeqMuuR7f1r4H T2uA61JHPWCXpHATyYvk1xdUNHTh40XVuM2CuvWwrmoOP0eQ+bjL09xSDRKj3rIZZK4Z +/dHsmt94spnphvME2Y4GDOLMgRr4Ng66Zs6YdSwg7921gfeDoeBa5L2Vd12Hwghnjr1 HB2g== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b="QQQLTy/G"; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id e4-v6si9987044plb.400.2018.07.25.08.37.27; Wed, 25 Jul 2018 08:37:42 -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; dkim=pass header.i=@kernel.org header.s=default header.b="QQQLTy/G"; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729164AbeGYQsB (ORCPT + 99 others); Wed, 25 Jul 2018 12:48:01 -0400 Received: from mail.kernel.org ([198.145.29.99]:39228 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728360AbeGYQsA (ORCPT ); Wed, 25 Jul 2018 12:48:00 -0400 Received: from mail-yw0-f169.google.com (mail-yw0-f169.google.com [209.85.161.169]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id D0B7C20843; Wed, 25 Jul 2018 15:35:48 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1532532949; bh=q6xHvZfVNrhZ0AGQtRkDIYb193tEbB2nQkTF3TUjfs0=; h=In-Reply-To:References:From:Date:Subject:To:Cc:From; b=QQQLTy/GqBnd2EL+y71DTqICw2F9euar6OIoBGWRcWNUsQyli9GVtoZXH9416PF4W uR0pTBPQf3R//EJUtRZFvdc2GdoC1pHI67vI3vyZGZzrMZpy2vi+AzGclWcp6d9mZH Btpr062U5azfisp5ueL1GKuZpq/r7C9Axhn1uV/c= Received: by mail-yw0-f169.google.com with SMTP id j68-v6so3016994ywg.1; Wed, 25 Jul 2018 08:35:48 -0700 (PDT) X-Gm-Message-State: AOUpUlFW3XdZLz0t2aNrJqDUWELwGHwN9JrHeI6kcUL47FJLoARgcMlt VXNeYhAcACmEvDvSXl6DkUM250aAIxA4iIjEH/E= X-Received: by 2002:a81:8047:: with SMTP id q68-v6mr11482222ywf.196.1532532948085; Wed, 25 Jul 2018 08:35:48 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a25:8182:0:0:0:0:0 with HTTP; Wed, 25 Jul 2018 08:35:07 -0700 (PDT) In-Reply-To: References: <1532441858-13507-1-git-send-email-appana.durga.rao@xilinx.com> <1532441858-13507-2-git-send-email-appana.durga.rao@xilinx.com> From: Alan Tull Date: Wed, 25 Jul 2018 10:35:07 -0500 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v3 2/2] fpga: zynq-fpga: Add support for readback To: Appana Durga Kedareswara Rao Cc: Moritz Fischer , Nava kishore Manne , Michal Simek , "linux-fpga@vger.kernel.org" , linux-arm-kernel , Linux Kernel Mailing List 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 Wed, Jul 25, 2018 at 4:12 AM, Appana Durga Kedareswara Rao wrote: > Hi Alan, > > Thanks for the review... > > >> > >> > >> >> > +static bool readback_type; >> >> > +module_param(readback_type, bool, 0644); >> >> > +MODULE_PARM_DESC(readback_type, >> >> > + "readback_type 0-configuration register read " >> >> > + "1- configuration data read (default: 0)"); >> >> >> >> Not sure a module param is the best solution here. >> > >> > Need to provide flexibility to the user to switch between reading of FPGA >> registers and configuration data. >> >> I suggested calling the attribute 'image' because I thought it would always be >> a read back of the FPGA image information. I don't think that a sysfs >> attribute's function should change. :) > > In Zynq Case it supports two types of the readback (Configuration registers, Configuration data(fpga image)) which may not be the same case for other vendors. > Since I need to support both the use cases I have differentiated them using module param in the zynq-fpga driver. > > As you said we shouldn't change the attribute's function, So in the zynq-fpga driver, > I am planning to add another debugfs attribute for reading back of configuration registers as it is vendor specific readback type. > (Configuration registers ---- Usage: /sys/kernel/debug/fpga/zynq-fpga/cfgreg_summary) Is it called '...summary' because it is not all the registers? Could just be "cfg_regs"? > (Configuration data(fpga image) ---- Usage: /sys/kernel/debug/fpga/fpga0/image) > Please let me know your thoughts for the same... > >> >> > One other option is sysfs. Do you want me to implement sysfs path??? >> > Any other suggestions??? >> >> You could implement another sysfs attribute for reading FPGA registers >> with a separate ops callback. Please clarify what it is doing (not >> all FPGAs have this function) and what that will look like when the user reads >> the from the sysfs > > AFAIK we shouldn't add another sysfs/debugfs attribute for vendor-specific readback type in the FPGA manager ops. > Please correct me if my understanding is wrong. You are not wrong :) > > Regards, > Kedar. > >> >> Alan