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 4D469148FED for ; Thu, 6 Feb 2025 16:17:05 +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=1738858627; cv=none; b=Dd2AlW7tJYq6BCObrtSYNolZSaKt2q+/taC9MYmvnyXnAu2jaDfiDTWqFTpHGBb6TWV4wYcDGw/YMjE22YK0pOH1oydCb12fmy36A8vru+4qUrK3BB7x9SOQP1PYdNvyMSwB5Pdghp0p1N8NuHgb30gfHsa3IhNVbbuHXv72HpQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1738858627; c=relaxed/simple; bh=07oSBwgh/00XqU8S9NwC+z5K2Q1ohr8OmAinlMr1GuU=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=e1KG+zDM6T85M0IQ6Sc8bsfNwSn14zqmB2v3+IeW/3Gk0uVp8Cop6RqjEydGBSDQoBHLOpgk4COBKu0hQk1NF7hbVha7GLmMvko44T/MZSNDCmJrrGohTKg2M6Hu/YrOy2l8uJlxVIR84htkomiUSdoxyaISyr5jAr3ldRWuAww= 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 AAA9912FC; Thu, 6 Feb 2025 08:17:27 -0800 (PST) Received: from bogus (e133711.arm.com [10.1.196.55]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 660E43F63F; Thu, 6 Feb 2025 08:17:01 -0800 (PST) Date: Thu, 6 Feb 2025 16:16:58 +0000 From: Sudeep Holla To: Peng Fan , "Peng Fan (OSS)" Cc: Dario Binacchi , Michael Turquette , Stephen Boyd , Russell King , Cristian Marussi , Abel Vesa , "linux-clk@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "arm-scmi@vger.kernel.org" , "linux-arm-kernel@lists.infradead.org" , Rob Herring , Krzysztof Kozlowski , Shawn Guo , Sascha Hauer , Pengutronix Kernel Team , Fabio Estevam , "imx@lists.linux.dev" Subject: Re: [PATCH v2 3/4] clk: imx: pll14xx: support spread spectrum clock generation Message-ID: References: <20250205-clk-ssc-v2-0-fa73083caa92@nxp.com> <20250205-clk-ssc-v2-3-fa73083caa92@nxp.com> Precedence: bulk X-Mailing-List: imx@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Hi Peng, I apologise in advance for exploiting this thread to make my point. On Thu, Feb 06, 2025 at 04:31:46PM +0100, Dario Binacchi wrote: > > Sorry if I miscounted the lines, but here we are not considering who > actually implemented > the algorithmic part of the SSC management and all the time spent > testing the code on more > than one platform/board with each submission of the series for all 9 versions. > > [1] https://lore.kernel.org/all/20250118124044.157308-18-dario.binacchi@amarulasolutions.com/ > > Your changes, which are unnecessary for the clk-scmi.c changes, only > serve to support the > DT binding `assigned-clock-sscs`, which, as Krzysztof also reiterated: > > https://github.com/devicetree-org/dt-schema/pull/154 > > you should have proposed during the review of series [1]. You are the > NXP reviewer. > > > > > If you think it is not fair, I could drop this patch in V3 and leave it to you to handle. > > I take this patch in the patchset, mainly to ease your work and make > > Sorry for quoting Krzysztof again, but: > "Three months iMX8 patchsets, multiple reviews and no single comment > from you till January!" > > So please, if you really want to ease my work, then remove this patch > from this series and resume > reviewing series [1]. > I had complained once in the past. I am repeating that again. You are not new to the kernel development, yet at times I get really surprised with the way you manage your patches and create so much confusion. It gets extremely difficult to track what is happening if one doesn't follow all your patches for a week(week is too lenient IMO, you manage sometime to create same amount of confusion in just 2 days). And as usually you ignore merge window and post a whole set of new series on the first day of merge window. Which is fine especially if you are new to kernel development(not true in your case though) or even otherwise if you don't regularly track upstream cycle so much because of corporate commitments(which may be true in your case and I am fine with that). But you need to wait at-least a few days after the merge window so you give every one a chance to follow your work. And in this case, I would have avoided scmi changes are you have non-scmi specific driver to get the core clock changes review first and then added SCMI as it is OEM specific and we need to analyse it without other things in flux or under discussion. -- Regards, Sudeep