On 2018-04-30 20:43, Sinan Kaya wrote: > On 4/30/2018 2:40 PM, Bjorn Helgaas wrote: >> On Sat, Apr 28, 2018 at 09:28:47AM +0200, Jan Kiszka wrote: >>> On 2018-04-28 00:24, Bjorn Helgaas wrote: >>>> On Tue, Apr 24, 2018 at 05:13:39PM +0200, Jan Kiszka wrote: >>>>> From: Jan Kiszka <jan.kiszka@xxxxxxxxxxx> >>>>> >>>>> of_pci_get_host_bridge_resources allocates the resource structures it >>>>> fills dynamically, but none of its callers care to release them so far. >>>>> Rather than requiring everyone to do this explicitly, introduce a >>>>> managed version of that service. This differs API-wise only in taking a >>>>> reference to the associated device, rather than to the device tree node. >>>>> >>>>> As of_pci_get_host_bridge_resources is an exported interface, we cannot >>>>> simply drop it at this point. After converting all in-tree users to the >>>>> new API, we could phase out the unmanaged one over some grace period. >>>> >>>> It looks like it might be possible to split this into three or four >>>> patches: >>>> >>>> 1) Factor __of_pci_get_host_bridge_resources() out of >>>> of_pci_get_host_bridge_resources() >>>> >>>> 2) Add struct device * argument >>>> >>>> 3) Convert pr_info() to dev_info() >>>> >>>> 4) Add devm_of_pci_get_host_bridge_resources() >>> >>> Will do. I'm even considering >>> >>> 5) mark of_pci_get_host_bridge_resources() __deprecated, due to the leak >>> and no remaining in-tree user - what do you think? >> >> Sounds good. >> >> It'd be nice if we had some guideline about deprecation -- whether we >> actually need to mark things __deprecated, and then how long to wait >> before actually removing them, but I don't see anything in >> Documentation/. > > I'm under the impression that we don't quite care about out-of-tree drivers. > I have seen many times out-of-tree drivers to be broken due to API changes, > renames or even parameter meaning change. > > If the plan is to remove the API, just remove the API today. I've already sent a __deprecated patch on Monday [1], in v2 of this series [2]. Please vote against that there, and I will replace it with a complete removal of that API. Thanks, Jan [1] https://lkml.org/lkml/2018/4/30/22 [2] https://lkml.org/lkml/2018/4/30/24 -- Siemens AG, Corporate Technology, CT RDA IOT SES-DE Corporate Competence Center Embedded Linux
