From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1423229AbeCBPVI (ORCPT ); Fri, 2 Mar 2018 10:21:08 -0500 Received: from mail-oi0-f50.google.com ([209.85.218.50]:45521 "EHLO mail-oi0-f50.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1422860AbeCBPVG (ORCPT ); Fri, 2 Mar 2018 10:21:06 -0500 X-Google-Smtp-Source: AG47ELsT8g0wljZrt+Olo2pEUq72VHWIwZhSAZM6NdAybVVjvbI/6dFNRp2/UYBfaAY410X2cfinkg== Date: Fri, 2 Mar 2018 09:21:04 -0600 From: Rob Herring To: Andy Shevchenko Cc: Shawn Lin , Jaehoon Chung , linux-mmc@vger.kernel.org, devicetree , Linux Kernel Mailing List , Ulf Hansson , Mark Rutland , Joachim Eastwood , dinguyen@kernel.org, Will Deacon , "xuwei (O)" Subject: Re: [PATCH 1/6] mmc: dw_mmc: remove the deprecated "clock-freq-min-max" property Message-ID: <20180302152104.gnylb6xtgy5hb7i5@rob-hp-laptop> References: <20180223064138.18401-1-jh80.chung@samsung.com> <7ba335af-3fc5-2afd-8c52-03dca5eba9a4@rock-chips.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20170609 (1.8.3) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Feb 23, 2018 at 06:16:39PM +0200, Andy Shevchenko wrote: > On Fri, Feb 23, 2018 at 4:19 PM, Shawn Lin wrote: > > On 2018/2/23 21:27, Andy Shevchenko wrote: > >> On Fri, Feb 23, 2018 at 8:41 AM, Jaehoon Chung > >> wrote: > >>> > >>> 'clock-freq-min-max' property had already deprecated. > >>> Remove the 'clock-freq-min-max' property that is kept to maintain > >>> the compatibility. > >> > >> > >> Removing a property without telling the user what to expect is a bad > >> idea and ABI breakage. > >> > > > > What's the general process to remove a property? > > > > I guess we should do: > > 1) deprecate it in the first place and remove it from all upstream DT Yes > > 2) wait some long enough days for expecting the stale of all old DTB > > containing that property Yes. How long that is depends on the platform. I think the minimum is 1 release cycle. Some stable platforms are years. If there are other DT changes with new features everyone should want/need, then that can be a decision point. Given this is a shared IP block it's harder to know, so you may need to err on the longer side. > > 3) remove the functionality of the deprecated property from the driver > > but still leave some warning there I'd say add a warning in step 1 and combine 3 and 4. > > 4) remove the left warning finally > > I don't know. Perhaps Rob can shed a light here. > But I would really OK with removal of some of such properties from > some drivers where it's more burden to keep them. > > > And for the ABI breakage, we should add something in Documentation/ABI > > /obsolete or Documentation/ABI/removed ? It is only an ABI break if someone notices. Rob