[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH RESEND] intel/pinctrl: check capability offset is between MMIO region


  • To: Andy Shevchenko <andriy.shevchenko@xxxxxxxxx>
  • From: Roger Pau Monné <roger.pau@xxxxxxxxxx>
  • Date: Wed, 24 Mar 2021 16:13:59 +0100
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com; dkim=pass header.d=citrix.com; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=XrReSzt1viFtrrmsZHR21zzYTBDhjfiA/E7QWNDYML0=; b=MA6gjzc9keGC+CQZkFTD3Ds+G4T4q0LsCSXT71w8VfltAkVU/Y+DM+saIwhSDB1ETQ6ozDHqY+JhKoziRP08wC5A1FHQPYhTdmyjpgQWmiL/kerj+N1YbtR/cvWU6yWGdNgkPSAu05b6y0g6VAmXfHvBwyO9X3GG4Xxp0CEU52b412lxnddO5/wPHNhvdRyzUCQdk0ZdWsvx8Ecah4Lez2vh5WMx22hpJ+R4yANxomJyHkxT/vUXhwlWYJab/ID58bsYcgmJTZgHjflfrdhsTGfllpW3hMqysLC09kUVjyqL8WlfYn3/OCnFsMk6feOEPmIoXCXRhHklmewAO1lfQg==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=RN40r+sN9kfv344l5vSEJ6OaOYPkby1+i+EDj9/SpDEyDl3kTIx8tSeqreKf5Ho+ne0pB13I0/fnBNkgvcpvV8OkoW48rNRMh4svK1flHMavv43Z6Ce6rdyAoUC+WvAAhHpeetVcYgdsKPi88Ed1jgMwTAueAGuFfDvOIe0FXugXp347EXxHJP8odlyoc0O6aGeudaDHFC11404LjJRqPaNMudMMNJhcdXmsyVM6XrNA81chTuQqsRhl9Vp06JZeUtWLsFzp0fYwOdKasWs+mrcahtDBLi3imJ7v44uHocLnvZPC6NhIICH6dObY3EHi0AhYXzUXKkHPvEQL6lucrQ==
  • Authentication-results: esa2.hc3370-68.iphmx.com; dkim=pass (signature verified) header.i=@citrix.onmicrosoft.com
  • Cc: <linux-kernel@xxxxxxxxxxxxxxx>, <xen-devel@xxxxxxxxxxxxxxxxxxxx>, Mika Westerberg <mika.westerberg@xxxxxxxxxxxxxxx>, Linus Walleij <linus.walleij@xxxxxxxxxx>, <linux-gpio@xxxxxxxxxxxxxxx>
  • Delivery-date: Wed, 24 Mar 2021 15:14:24 +0000
  • Ironport-hdrordr: A9a23:yc9NWqNChxiPE8BcTxP155DYdL4zR+YMi2QD/1xtSBBTb8yTn9 2vmvNe7hPvlDMNQhgb9OyoEqPoexPh3LRy5pQcOqrnYRn+tAKTXeVfxKbB4xmlIS3x8eZByb xtGpIVNPTcBUV35PyU3CCWCNAlqePozImNpcPzi0hgVhtrbaYI1XYdNi++HldtTAdLQboVfa DshfZvnDardXQJYsnTPBBsM9TrnNHXiIngJScPGh9P0mKzpAm14733GQXw5GZ9bxpzx94ZkF TtokjCyYiI99q6zRLd0GG71eUqpPLRjuFtKebJpswcKjDHghulaoJ7S9S5zUwIidDq0nkGup 3hpAohItRS5hrqDx6IiCqo4SbM+nIP7GLv0lCRi3eLm72GeBsKT/BvqKgcVzmx0TtGgPhMlJ hl8kjcir9sSTTHpyj578igbWAQqmOE5UAMvMRWs2ZSSuIlGdlshL1axmx5OrEaEhn37Yg2ed Medv301bJtfVSWY2uxhBgX/PWcGnA6HhKxSkMfoMCi0z9PgHBjz0cDrfZv5ks9yA==
  • Ironport-sdr: WPgl8n6C1t9qqptT2KlYIcusDPet5S6aMpDU2n8dy3iid03VuoyjBToIx4kDSopOuQvyFDwxF3 1AxeTRbFgHlolX61kz1IsHfkEzbwXkoDCDbc3UbO+G3q6cnbURy0iPgfjqZoPkf1OkGMfB5CcZ ERcpJLiHGEz6LPrx9QeI7dv9PbWmTe9PcailXEMCHyZ6o0SQPFzqH16+xypp6HbPSp3qczFtRn DoWP/WcfjQhuDQuR+Uue3CWfW6elF0ZIhJ1lPsTQ+ob5hTFwRuRPlcPbVqvJQuJD8gCofZhf/s 3nM=
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On Wed, Mar 24, 2021 at 04:22:44PM +0200, Andy Shevchenko wrote:
> On Wed, Mar 24, 2021 at 02:55:15PM +0100, Roger Pau Monné wrote:
> > On Wed, Mar 24, 2021 at 02:58:07PM +0200, Andy Shevchenko wrote:
> > > On Wed, Mar 24, 2021 at 01:31:18PM +0100, Roger Pau Monne wrote:
> > > Moreover, it seems you are bailing out and basically denying driver to 
> > > load.
> > > This does look that capability is simply the first register that blows 
> > > the setup.
> > > I think you have to fix something into Xen to avoid loading these drivers 
> > > or
> > > check with something like pci_device_is_present() approach.
> > 
> > Is there a backing PCI device BAR for those MMIO regions that the
> > pinctrl driver is trying to access? AFAICT those regions are only
> > reported in the ACPI DSDT table on the _CRS method of the object (at
> > least on my system).
> 
> Unfortunately it does not expose PCI configuration space.

Are those regions supposed to be marked as reserved in the memory map,
or that's left to the discretion of the hardware vendor?

> > Doing something like pci_device_is_present would require a register
> > that we know will never return ~0 unless the device is not present. As
> > said above, maybe we could use REVID to that end?
> 
> Yes, that's good, see above.
> 
> WRT capabilities, if we crash we will see the report immediately on the
> hardware which has such an issue. (It's quite unlikely we will ever have one,
> that's why I consider it's not critical)

I would rather prefer to not crash, because I think the kernel should
only resort to crashing when there's no alternative, and here it's
perfectly fine to just print an error message and don't load the
driver. IMO I would rather boot without pinctrl than get a panic if
it turns out pinctrl capabilities list is somehow corrupted. It's a
long shot, but the check added in order to prevent this scenario is
minimal.

In any case I will send a new version with the REVID check and this
current patch.

Thanks, Roger.



 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.