From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from fgw21-7.mail.saunalahti.fi (fgw21-7.mail.saunalahti.fi [62.142.5.82]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id F054E2E416 for ; Tue, 16 Jan 2024 21:18:34 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=62.142.5.82 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1705439916; cv=none; b=SeS8ufiXNChZblkR0eXXpCq8pjBKPwVlDYQrgB2fxvEjm49dIFijywkdji0g3eYvnRe5pGHAgbFuFXPIBB62Bf6pI88vNz/4UvmCMAuKruaLhrws1vdI5Ye2XFhQUqlu2y7cN2TjMqSZMMGqCocDHcjHBW6OyidrxJlRSYVEzqI= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1705439916; c=relaxed/simple; bh=lvkTMMRuhJu5viOvzqXhbppQZAvUMGytV+uhbZeFHo0=; h=Received:From:Date:To:Cc:Subject:Message-ID:References: MIME-Version:Content-Type:Content-Disposition: Content-Transfer-Encoding:In-Reply-To; b=YFzcLNLjVn1VbNr+84Z2J8YiKVUz8YtdfpDbyVBPmdNP9kSIu0qODd44y49rgnYNoAyknSjuIZwyGkNqlUbzgbfEIpx784t+v/gUJPQLRPiXDWJG38B6J6VzFOTXmWaZjQ/+PL1Zbv0fZtJC172NofqumcaRV9+w/ktyuluyio8= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com; spf=fail smtp.mailfrom=gmail.com; arc=none smtp.client-ip=62.142.5.82 Authentication-Results: smtp.subspace.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=fail smtp.mailfrom=gmail.com Received: from localhost (88-113-24-108.elisa-laajakaista.fi [88.113.24.108]) by fgw21.mail.saunalahti.fi (Halon) with ESMTP id a42b3ea7-b4b4-11ee-abf4-005056bdd08f; Tue, 16 Jan 2024 23:17:24 +0200 (EET) From: andy.shevchenko@gmail.com Date: Tue, 16 Jan 2024 23:17:23 +0200 To: Philipp Stanner Cc: Jonathan Corbet , Hans de Goede , Maarten Lankhorst , Maxime Ripard , Thomas Zimmermann , David Airlie , Daniel Vetter , Bjorn Helgaas , Sam Ravnborg , dakr@redhat.com, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org, linux-pci@vger.kernel.org Subject: Re: [PATCH 00/10] Make PCI's devres API more consistent Message-ID: References: <20240115144655.32046-2-pstanner@redhat.com> Precedence: bulk X-Mailing-List: linux-doc@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20240115144655.32046-2-pstanner@redhat.com> Mon, Jan 15, 2024 at 03:46:11PM +0100, Philipp Stanner kirjoitti: > ¡Hola! i? Vim user? :-) > PCI's devres API suffers several weaknesses: > > 1. There are functions prefixed with pcim_. Those are always managed > counterparts to never-managed functions prefixed with pci_ – or so one > would like to think. There are some apparently unmanaged functions > (all region-request / release functions, and pci_intx()) which > suddenly become managed once the user has initialized the device with > pcim_enable_device() instead of pci_enable_device(). This "sometimes > yes, sometimes no" nature of those functions is confusing and > therefore bug-provoking. In fact, it has already caused a bug in DRM. > The last patch in this series fixes that bug. > 2. iomappings: Instead of giving each mapping its own callback, the > existing API uses a statically allocated struct tracking one mapping > per bar. This is not extensible. Especially, you can't create > _ranged_ managed mappings that way, which many drivers want. > 3. Managed request functions only exist as "plural versions" with a > bit-mask as a parameter. That's quite over-engineered considering > that each user only ever mapps one, maybe two bars. > > This series: > - add a set of new "singular" devres functions that use devres the way > its intended, with one callback per resource. > - deprecates the existing iomap-table mechanism. > - deprecates the hybrid nature of pci_ functions. > - preserves backwards compatibility so that drivers using the existing > API won't notice any changes. > - adds documentation, especially some warning users about the > complicated nature of PCI's devres. Instead of adding pcim_intx(), please provide proper one for pci_alloc_irq_vectors(). Ideally it would be nice to deprecate old IRQ management functions in PCI core and delete them in the future. -- With Best Regards, Andy Shevchenko