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=-3.9 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SIGNED_OFF_BY, SPF_HELO_NONE,SPF_PASS autolearn=no 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 629ACC432C3 for ; Fri, 29 Nov 2019 13:01:50 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 286EF21721 for ; Fri, 29 Nov 2019 13:01:50 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=linaro.org header.i=@linaro.org header.b="An+4zXCF" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726770AbfK2NBt (ORCPT ); Fri, 29 Nov 2019 08:01:49 -0500 Received: from mail-qt1-f195.google.com ([209.85.160.195]:46928 "EHLO mail-qt1-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726360AbfK2NBt (ORCPT ); Fri, 29 Nov 2019 08:01:49 -0500 Received: by mail-qt1-f195.google.com with SMTP id r20so32336182qtp.13 for ; Fri, 29 Nov 2019 05:01:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Xn54XTvcNkal14NNHB7+Vzm9BZs6YXQQ3RAQ8lYr/oc=; b=An+4zXCFdte8eMvcqUEG3vfTxzYHLztNUyO+dIju42gILkNWJLODGcoxqgrQR7mqsl OfYl8RSMNw0xmz5Bgz11IFl+yVb5ur2ssG+rt2UWWkK3GXNcN5i0+6XzLBwaYkxROqrK hf05akothfHLjS+dc3IJ2nmpGRpB4rtw7hvhHxMw/wuCu0I+T8j69hAB5WrJ0UhCECxf RMt3xTOTWuVlOuPignDWsj0EBINdiInOto4yDYiZ/CqeuULQuwnS4TQ7ua9n3EYQ1Opt cF4tfnfdW0s1OqfNGbRi1bC6J2MgQcaHGhBWzpy10bkEgFRVncoZ+2BQibA0Id+qjfm/ kEFw== 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=Xn54XTvcNkal14NNHB7+Vzm9BZs6YXQQ3RAQ8lYr/oc=; b=m21RHSOWHq3wixLrfeLM7OB5h1OXzg3saavdSZZ4j8PuFktaiQCslnDxJO3f2YQqKY Fzgioq3YW4lfdtEMB4Ip3+fJoPamZxgaTbe+UUmUQpmkjD7XFS+uT5Qdnh6BzUcrzBID O9SS6YkHu/E0ghORPR2LNrDDaxDkw1JyNd3cTDws2zrLM6TQgnz4t5zgX40DbH02iZgd 3DzuGfPBBRKOYUAp5WrTv26WxD0GUiQ8awJvbyx3W424hscGI8WWYrNj/QoQQWKjdN5i wel/4JwzVEw56xmWFmdny4+rg6fu+sbafi2CYuTsBspVNWG0VdwQG7PA6pCui93RAItZ uosA== X-Gm-Message-State: APjAAAVEEy5eZT8pGaBHhQWkKnd+P6B0It8ygTKMqUWCBsbc1B5+sY3Q 125PF2+4c3hOYxgUFcE+7HotkFWGs/XYsYUpQeeC3A== X-Google-Smtp-Source: APXvYqxnCMUzN7K5F96FwviGs9debEPUho46vDAcIfSuTnPxYu+XchM5mkJV2q7pXMOhaWj2Um8cNDKqRVhiHyGh8zE= X-Received: by 2002:ac8:41c3:: with SMTP id o3mr35156316qtm.88.1575032508294; Fri, 29 Nov 2019 05:01:48 -0800 (PST) MIME-Version: 1.0 References: <20191119231912.12768-1-mike.leach@linaro.org> <20191119231912.12768-5-mike.leach@linaro.org> In-Reply-To: From: Mike Leach Date: Fri, 29 Nov 2019 13:01:37 +0000 Message-ID: Subject: Re: [PATCH v5 04/14] coresight: cti: Add sysfs trigger / channel programming API To: Suzuki Kuruppassery Poulose Cc: Coresight ML , linux-arm-kernel , devicetree@vger.kernel.org, "open list:DOCUMENTATION" , Mathieu Poirier Content-Type: text/plain; charset="UTF-8" Sender: linux-doc-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-doc@vger.kernel.org Hi Suzuki, On Wed, 27 Nov 2019 at 18:40, Suzuki Kuruppassery Poulose wrote: > > On 19/11/2019 23:19, Mike Leach wrote: > > Adds a user API to allow programming of CTI by trigger ID and > > channel number. This will take the channel and trigger ID supplied > > by the user and program the appropriate register values. > > > > Signed-off-by: Mike Leach > > --- > > > + > > +static ssize_t chan_xtrigs_view_show(struct device *dev, > > + struct device_attribute *attr, > > + char *buf) > > +{ > > + struct cti_drvdata *drvdata = dev_get_drvdata(dev->parent); > > + struct cti_config *cfg = &drvdata->config; > > + int used = 0, reg_idx; > > + int buf_sz = PAGE_SIZE; > > + u32 chan_mask = BIT(cfg->xtrig_rchan_sel); > > + > > + used += scnprintf(buf, buf_sz, "[%d] IN: ", cfg->xtrig_rchan_sel); > > + for (reg_idx = 0; > > + reg_idx < drvdata->config.nr_trig_max; > > + reg_idx++) { > > + if (chan_mask & cfg->ctiinen[reg_idx]) { > > + used += scnprintf(buf + used, buf_sz - used, "%d ", > > + reg_idx); > > + } > > + } > > As a security measure, we must make sure that we have space left in the > buffer. We could end up passing "negative" numbers for the size > argument, in the worst case. > The return value from scnprintf() is always the _actual_ number of characters added to the buffer, not as per snprintf() which returns the number that could have been printed if there were sufficient space. Thus used can never exceed the buffer size. Regards Mike > > + > > + used += scnprintf(buf + used, buf_sz - used, "OUT: "); > > + for (reg_idx = 0; > > + reg_idx < drvdata->config.nr_trig_max; > > + reg_idx++) { > > + if (chan_mask & cfg->ctiouten[reg_idx]) { > > + used += scnprintf(buf + used, buf_sz - used, "%d ", > > + reg_idx); > > + } > > + } > > + used += scnprintf(buf + used, buf_sz - used, "\n"); > > + return used; > > +} > > +static DEVICE_ATTR_RW(chan_xtrigs_view); > > > The rest looks fine to me. > > Suzuki -- Mike Leach Principal Engineer, ARM Ltd. Manchester Design Centre. UK