Received: by 2002:a05:6a10:206:0:0:0:0 with SMTP id 6csp5032414pxj; Wed, 9 Jun 2021 07:41:11 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzaTTg9tdNsHtf3oHbrS0eE1EZkW4wcWSWcYsMnt1PaBmMaQ7giJtVwWyLSqq2dCiI3zWSL X-Received: by 2002:a17:906:1701:: with SMTP id c1mr173016eje.425.1623249671321; Wed, 09 Jun 2021 07:41:11 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1623249671; cv=none; d=google.com; s=arc-20160816; b=BIh7JqHehAjjix7GQyhV3j7eF4uzw3u3mIQe1a2C0akHZPOt22yfj6Y+Sf7/nCVXpb 1I0dRrBntA8T/zufW9KfwDARE5UZ/bk87cjXSertesWW4f3U/ZStwTPcoN25yQFcO1fU +bvgJa5MYZqwuPInP32biKiw26mDmfgG6CC4mn96s/e5bg+keejwprwIDSJvpNf9bhWH ifkA9RHwkgsBGM2U30ljwIlijPf0gZa6lJ1hrd7x6c/B+L1xBEdKkYWgywYQhSLv8qpF IO2ZESjFn21wg8MI4PxpRoaOLHRNEAuFQ4ym43+2i1noO2qFiVxgOQxZC2kN1h1KI2Es 877w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:subject:cc:to:from:date; bh=/qvDaGKNEgD2Xk5EJaxM5gU69TzcZA9pY7WWcDhOsf0=; b=x16kTGTlOI1kln/FdSzGuTAhK+kuatMAQo+3BI0PMgXQ2DzhhQpWQFz05YrsBMOk8L eolCAaF+ZyFJa4njYRZZ3OSfCRv3MOV0RoTvh8ZuqTkIBq4lk/IBO5geIOXCrtNKEywA rp28ME0+1Mq/Jli+QPQPaDKx+jfpx5KUjHyfAt0bWMYMm0VmMOs6dfz7+dNqN8gg7Hh8 +40jhvDLiKDDC5uIZM4R0g03lWtjNlYTVkgjd9YUA6Rk8GOExaPYc1ldNxF+Y0I3Td+J nqIZcvJBSDOBTHy/680njGf/93rVGaXStkxNOrLT/KX3FIaLsD6ffgBwgYRTxpWs73GD k7Fg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=siemens.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id g21si2299525edw.335.2021.06.09.07.40.47; Wed, 09 Jun 2021 07:41:11 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=siemens.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S239010AbhFILXH (ORCPT + 99 others); Wed, 9 Jun 2021 07:23:07 -0400 Received: from gecko.sbs.de ([194.138.37.40]:35422 "EHLO gecko.sbs.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S239011AbhFILXG (ORCPT ); Wed, 9 Jun 2021 07:23:06 -0400 X-Greylist: delayed 540 seconds by postgrey-1.27 at vger.kernel.org; Wed, 09 Jun 2021 07:23:05 EDT Received: from mail1.sbs.de (mail1.sbs.de [192.129.41.35]) by gecko.sbs.de (8.15.2/8.15.2) with ESMTPS id 159BBxIE010037 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 9 Jun 2021 13:11:59 +0200 Received: from md1za8fc.ad001.siemens.net ([139.22.32.109]) by mail1.sbs.de (8.15.2/8.15.2) with ESMTP id 159B8Hm0019317; Wed, 9 Jun 2021 13:08:17 +0200 Date: Wed, 9 Jun 2021 13:08:16 +0200 From: Henning Schild To: Andy Shevchenko Cc: Mika Westerberg , Linux Kernel Mailing List , "open list:GPIO SUBSYSTEM" , Andy Shevchenko , Linus Walleij Subject: Re: [PATCH] pinctrl: intel: fix NULL pointer deref Message-ID: <20210609130816.3631f0aa@md1za8fc.ad001.siemens.net> In-Reply-To: References: <20210609062722.9132-1-henning.schild@siemens.com> X-Mailer: Claws Mail 3.17.8 (GTK+ 2.24.32; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Am Wed, 9 Jun 2021 13:33:34 +0300 schrieb Andy Shevchenko : > On Wed, Jun 9, 2021 at 1:12 PM Mika Westerberg > wrote: > > On Wed, Jun 09, 2021 at 08:27:22AM +0200, Henning Schild wrote: > > > match could be NULL in which case we do not go ACPI after all > > ... > > > > adev = ACPI_COMPANION(&pdev->dev); > > > - if (adev) { > > > - const void *match = > > > device_get_match_data(&pdev->dev); - > > > + match = device_get_match_data(&pdev->dev); > > > > Actually we don't even call intel_pinctrl_get_soc_data() if the > > ACPI ID is not listed in the corresponding driver's module table. > > So I don't think match can ever be NULL. > > > > But feel free to prove me wrong ;-) > > It's possible to have bugs in this driver, but can we see the real > case here? Yes that is indeed only showing when using a kernel that has seen other patches. To be precise i applied "[rfc, PATCH v1 0/7] PCI: introduce p2sb helper" before running into the problem. Something in there must be calling the function without the ACPI ID. I am still working on a series of device drivers for Siemens PCs, adding i.e. LEDs which are in fact GPIO. Those PCs have a hidden p2sb and no ACPI entries for the LEDs. In order to use GPIO from the drivers i need to make sure "broxton-pinctrl" comes up even if p2sb is hidden. Long story short, i thought the patch was simple enough to merge even taken out of my special context. Currently intel_pinctl only works if "ps2b is not hidden by BIOS" or "ACPI tables are correct", lifting the ban on the hidden p2sb seems like a useful thing in general (i.e. sysfs gpio interface). And i was hoping Andy would take the lead on that. It is something my Siemens drivers would depend on, but really a generic thing as far as i understand it. regards, Henning