From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 6DE14215F7B for ; Thu, 9 Jan 2025 10:58:06 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=217.140.110.172 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1736420289; cv=none; b=D5+zoQNs6F5X82tai3ZwTLhEBLXZ3GrW4y4e1NdkDmalGGj76JervLoaG8cjvRMv/PFGe0LVDlzXV9KUoGJraZz5bQyQm518Cc1yrDdKJVL/+6fI2e+jY5s0Tj+sFoW+7+uDx/cd9Er7jBK8ainhOz62T2NP669TDU9039jxIYM= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1736420289; c=relaxed/simple; bh=c1pKRioKDCfE0aZNJYi/N6ci56jgUBpTY2cdHCYOBAs=; h=Message-ID:Date:MIME-Version:Subject:From:To:Cc:References: In-Reply-To:Content-Type; b=VcK2LgiIZXWPp30XEgBs5D4hxwkms5Xy9Umq3K+bCRfLddCFQixKGs9q0u67GKDSsv2xm6LwJtPdcNcCc/3z3POkOEdRI4SwCO1Rjy0lwZs5R53sxB7nb4GPMih8iHMiCq37OTFR8AvPrNavWA0uAAYH4m7Nmds30sYQgWlKgpI= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com; spf=pass smtp.mailfrom=arm.com; arc=none smtp.client-ip=217.140.110.172 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=arm.com Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id AB11413D5; Thu, 9 Jan 2025 02:58:33 -0800 (PST) Received: from [10.57.32.219] (unknown [10.57.32.219]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPA id A96303F673; Thu, 9 Jan 2025 02:58:03 -0800 (PST) Message-ID: Date: Thu, 9 Jan 2025 10:58:02 +0000 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] hwtracing: Switch back to struct platform_driver::remove() Content-Language: en-GB From: Suzuki K Poulose To: Alexander Shishkin , =?UTF-8?Q?Uwe_Kleine-K=C3=B6nig?= Cc: Mike Leach , James Clark , Maxime Coquelin , Alexandre Torgue , coresight@lists.linaro.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linux-stm32@st-md-mailman.stormreply.com References: <20241111110922.334610-2-u.kleine-koenig@baylibre.com> <87h68duaez.fsf@ubik.fi.intel.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 11/11/2024 14:47, Suzuki K Poulose wrote: > Hi > > On 11/11/2024 14:12, Alexander Shishkin wrote: >> Uwe Kleine-König writes: >> >>> After commit 0edb555a65d1 ("platform: Make platform_driver::remove() >>> return void") .remove() is (again) the right callback to implement for >>> platform drivers. >>> >>> Convert all platform drivers below drivers/hwtracing to use .remove(), >>> with the eventual goal to drop struct platform_driver::remove_new(). As >>> .remove() and .remove_new() have the same prototypes, conversion is done >>> by just changing the structure member name in the driver initializer. >>> >>> Also adapt some whitespace to make indention consistent. >>> >>> Signed-off-by: Uwe Kleine-König >> >> Acked-by: Alexander Shishkin >> >>> --- >>> Hello, >>> >>> I did a single patch for all of drivers/hwtracing. While I usually >>> prefer to do one logical change per patch, this seems to be >>> overengineering here as the individual changes are really trivial and >>> shouldn't be much in the way for stable backports. But I'll happily >>> split the patch if you prefer it split. Maybe split for coresight vs. >>> intel_th? Also if you object the indentation stuff, I can rework that. >> >> I'm fine with it as is. >> >>> This is based on today's next, if conflicts arise when you apply it at >>> some later time and don't want to resolve them, feel free to just drop >>> the changes to the conflicting files. I'll notice and followup at a >>> later time then. Or ask me for a fixed resend. (Having said that, I >>> recommend b4 am -3 + git am -3 which should resolve most conflicts just >>> fine.) >> >> Does anybody want to pick this up or should I? I'm fine either way, but >> if there are any conflicts they won't be from my end of things, so it >> might make sense to take it via the coresight path. > > I am happy to take them via coresight tree and queue them for v6.14 I see that Linus has queued this already Suzuki > > Suzuki > >> >> Thanks, >> -- >> Alex >