From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755881AbdKCKIL (ORCPT ); Fri, 3 Nov 2017 06:08:11 -0400 Received: from foss.arm.com ([217.140.101.70]:40252 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752780AbdKCKIK (ORCPT ); Fri, 3 Nov 2017 06:08:10 -0400 Subject: Re: [PATCH 11/17] coresight etr: Handle driver mode specific ETR buffers To: Mathieu Poirier Cc: linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, robert.walker@arm.com, mike.leach@linaro.org, coresight@lists.linaro.org References: <20171019171553.24056-1-suzuki.poulose@arm.com> <20171019171553.24056-12-suzuki.poulose@arm.com> <20171102202658.GD23320@xps15> From: Suzuki K Poulose Message-ID: Date: Fri, 3 Nov 2017 10:08:07 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <20171102202658.GD23320@xps15> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 02/11/17 20:26, Mathieu Poirier wrote: > On Thu, Oct 19, 2017 at 06:15:47PM +0100, Suzuki K Poulose wrote: >> Since the ETR could be driven either by SYSFS or by perf, it >> becomes complicated how we deal with the buffers used for each >> of these modes. The ETR driver cannot simply free the current >> attached buffer without knowing the provider (i.e, sysfs vs perf). >> >> To solve this issue, we provide: >> 1) the driver-mode specific etr buffer to be retained in the drvdata >> 2) the etr_buf for a session should be passed on when enabling the >> hardware, which will be stored in drvdata->etr_buf. This will be >> replaced (not free'd) as soon as the hardware is disabled, after >> necessary sync operation. > > If I get you right the problem you're trying to solve is what to do with a sysFS > buffer that hasn't been read (and freed) when a perf session is requested. In > my opinion it should simply be freed. Indeed the user probably doesn't care > much about that sysFS buffer, if it did the data would have been harvested. Not only that. If we simply use the drvdata->etr_buf, we cannot track the mode which uses it. If we keep the etr_buf around, how do the new mode user decide how to free the existing one ? (e.g, the perf etr_buf could be associated with other perf data structures). This change would allow us to leave the handling of the etr_buf to its respective modes. And whether to keep the sysfs etr_buf around is a separate decision from the above. Cheers Suzuki