On Fri, Feb 23, 2018 at 06:16:39PM +0200, Andy Shevchenko wrote: > On Fri, Feb 23, 2018 at 4:19 PM, Shawn Lin <shawn.lin@xxxxxxxxxxxxxx> wrote: > > On 2018/2/23 21:27, Andy Shevchenko wrote: > >> On Fri, Feb 23, 2018 at 8:41 AM, Jaehoon Chung <jh80.chung@xxxxxxxxxxx> > >> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
