Received: by 2002:a05:6a10:206:0:0:0:0 with SMTP id 6csp610307pxj; Thu, 10 Jun 2021 08:30:21 -0700 (PDT) X-Google-Smtp-Source: ABdhPJySzDbfHD29eA20nJNCYd5X9+YkVcd8khfKEPxBlb3nIW8GabGr18GghC8EU7BM6wdrcaiU X-Received: by 2002:a17:906:f285:: with SMTP id gu5mr171292ejb.226.1623339021471; Thu, 10 Jun 2021 08:30:21 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1623339021; cv=none; d=google.com; s=arc-20160816; b=CxpfPpES0Jz0nwhy+b/xPyJhsL+KsNpYmMiMH/5UUzcKJ5h7jhSCuTybKVI0qJ065i uqvR2ZKbhddfDGWG/DP4qnL6xQCyXO5PhhuJuLVCP/BAtoO0ewyTjtElBIeJF5X6eXAa rieCuevUk9ye4RdObz1QkSkn/zUMWsr1JiFDOAlLLnqrdIeZN7IMhZEzDQF4JCpOaJf8 Nu9VT3x1zcDzCk4TnQzGteHRqovryxoD2ZgprJ/9ElIV1lvJyHT5Nc6zxLz9QRRXrxlw uTcJZP8IRmarAqADoYbHEbud0QJ9ARS8HtqfA2slvzaXlcnYvmF5SzsTzhWYgByrwmXD QKCQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:organization:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :ironport-sdr:ironport-sdr; bh=oUK1M8QM72y5avQZO2JNmHyO6zCHd1Vgw1EDUQuegS4=; b=LYpeFY4q4xhazbzLXeVfQlCfADYu5Wqx1sIImLcDuewgtvjjcGUMiMqZvMZ5cPT16K reRBNa3QAq2XI8cZvwAh/pF72xbMcS7M+0FLNP8Lga29AmcbecAsrBPk4+4LCKRNJCaG vkTiq99pC1k+ah5tbpUiq3vdwIWUcIfmVHe/u2DVqDNntfwYRIMNZ4GUZ0HES3UwysCE 90p8FrPqLEMXJm0KjDC9TDwjpABKkbQ0NFfqqNu+IGFxw5t1oxcX1zRfuUe8zJLrBtBf aBHMbuLwdCq2fiu0JJffkgQ02iIU/sVBAubqV7jXZ1cMoSR35gSlg6tHhn9R41rvwn1l kIiA== 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=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id y15si2674290ede.450.2021.06.10.08.29.58; Thu, 10 Jun 2021 08:30:21 -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=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231625AbhFJPac (ORCPT + 99 others); Thu, 10 Jun 2021 11:30:32 -0400 Received: from mga01.intel.com ([192.55.52.88]:38211 "EHLO mga01.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230445AbhFJPac (ORCPT ); Thu, 10 Jun 2021 11:30:32 -0400 IronPort-SDR: dRZ10piBdAzMMZBVpvEZPI/4oiR+BnOf5xz32lNudnCXs8lqoK7pIqVKEYe26VvO8p8cHJ/xhx 9H6Ly3fPH4Sg== X-IronPort-AV: E=McAfee;i="6200,9189,10011"; a="226719229" X-IronPort-AV: E=Sophos;i="5.83,263,1616482800"; d="scan'208";a="226719229" Received: from fmsmga008.fm.intel.com ([10.253.24.58]) by fmsmga101.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 10 Jun 2021 08:28:36 -0700 IronPort-SDR: EZPruktFHltxMBmWLGwqBtYUJJDYra9AstjaQrNd0NPFum4J5/A42wQ23UdzCrig9arxld13ID fEzqX7XSNeuA== X-IronPort-AV: E=Sophos;i="5.83,263,1616482800"; d="scan'208";a="450413169" Received: from smile.fi.intel.com (HELO smile) ([10.237.68.40]) by fmsmga008-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 10 Jun 2021 08:28:34 -0700 Received: from andy by smile with local (Exim 4.94) (envelope-from ) id 1lrMbf-001BkV-Qm; Thu, 10 Jun 2021 18:28:31 +0300 Date: Thu, 10 Jun 2021 18:28:31 +0300 From: Andy Shevchenko To: Henning Schild 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: References: <20210609062722.9132-1-henning.schild@siemens.com> <20210609130816.3631f0aa@md1za8fc.ad001.siemens.net> <20210610165632.0d9bb321@md1za8fc.ad001.siemens.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Jun 10, 2021 at 06:00:29PM +0300, Andy Shevchenko wrote: > On Thu, Jun 10, 2021 at 5:56 PM Henning Schild > wrote: > > > > Am Thu, 10 Jun 2021 17:32:46 +0300 > > schrieb Andy Shevchenko : > > > > > On Thu, Jun 10, 2021 at 05:25:04PM +0300, Andy Shevchenko wrote: > > > > On Wed, Jun 09, 2021 at 01:08:16PM +0200, Henning Schild wrote: > > > > > Am Wed, 9 Jun 2021 13:33:34 +0300 > > > > > schrieb Andy Shevchenko : > > > > > > > > ... > > > > > > > > > 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. > > > > > > > > From p2sb series discussion it appears that this patch is not > > > > needed. The case is when BIOS already provides an ACPI device. > > > > > > > > So, the initial bug is in that series that needs to check if the > > > > ACPI device is exposed and forbid platform device instantiation in > > > > that case. > > > > > > Actually, I'm still thinking how this ever possible. We have all > > > drivers to provide SoC data pointers. match data may be NULL if and > > > only if the ACPI device provided is a new one that doesn't provide a > > > SoC data. > > > > > > So, w/o seeing ACPI table, I'm really puzzled here. > > > > Not sure what exactly you mean. Let us kill this thread and ignore the > > patch. It was posted out of context and the NULL deref code-path does > > not exist in the kernel, so the check is not needed. > > > > I will revisit the machine where your patch-series did lead to a > > double-init and EBUSY on claiming those memory ressources. And i will > > add ACPI info there as well. > > I guess I got what's going on here. When we create a platform device > we get an associated companion device (which is parent in this case of > LPC) and that's why when we try enumerating it you have got the first > branch chosen. I have just sent another patch based on this report. Can you please test it? -- With Best Regards, Andy Shevchenko