Received: by 10.223.185.116 with SMTP id b49csp50808wrg; Thu, 8 Mar 2018 12:42:24 -0800 (PST) X-Google-Smtp-Source: AG47ELtpWzWctmzRuxTv/VDFvuyHskvZCqnniEYZvB+pqKQ7fGl/KH9zH8+H4T9YpVXVaFAdumco X-Received: by 10.101.97.139 with SMTP id c11mr21656125pgv.439.1520541743951; Thu, 08 Mar 2018 12:42:23 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1520541743; cv=none; d=google.com; s=arc-20160816; b=sxr2g/DGhvXnFu/LMUI51OnEH5ErRfNyPIz0p4LEthH4NZW9KVRLLwdimKL3fUiA89 cAYurj7fA7T+W8732vroXGSC6EgYRtSbLSSi51SmNLQv6PghYgbt14WaeyXBOGgEqQkf 0174eufpKLY7BNffsVykwZc9gggFsHDou+3V3WfIs61+TCT75pMWRR/kjkbEhxy0+Tft 4JLeND3bUdnv3p3a9ieauMz2iBAnFf6Dnn27Pf3fZZvXe72q0c4CAqqYPn+XxPu5oIzD +1DxIheXL/r0zacUmOOBVpslJ5sCBVch+2NOi9BBjzlQY9PJjJN+i2UqVhBbdRNXyGET 7L4g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-language :content-transfer-encoding:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject:reply-to:dkim-signature :arc-authentication-results; bh=FoWwDx3Q45JF2yRnn2JRn/8AZBBYhUkc2DZ9fT0CpbQ=; b=tDxWMRW9132qZJ+47UnrHtvjOZMNT2RblcOIe38zDlub+C/kptBJnoHzKntHnk8oop UJRjraBdaKteHSWafpBYb10Xw9Me91/LOwEN07JITI6mgRp+jlsUL/86Ry2LfJNvm3oj UyQMwfcbvhUzR6YKYSNCfvqUZmFnrzjpvPjpRjpmNfyk4Z7P92hvixPaPElV+ZGVc8S0 WHC23S3xr9Y0A64z+2qxlM1ZHPtPvpnx/oUYaCS23WTcEuv1q5o9B03OZBh/wrKrbVBU Zpb2FFYcePSEtwpLgLPdToZBJSUK36vn2/sdoVXQH5vvTHO7o9A6LmZrOQtuHPLqJdW+ Ny5g== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@gmail.com header.s=20161025 header.b=bR9n/aHK; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id z188si16347323pfz.172.2018.03.08.12.42.09; Thu, 08 Mar 2018 12:42:23 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=fail header.i=@gmail.com header.s=20161025 header.b=bR9n/aHK; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751189AbeCHUlA (ORCPT + 99 others); Thu, 8 Mar 2018 15:41:00 -0500 Received: from mail-pf0-f175.google.com ([209.85.192.175]:45487 "EHLO mail-pf0-f175.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751157AbeCHUk7 (ORCPT ); Thu, 8 Mar 2018 15:40:59 -0500 Received: by mail-pf0-f175.google.com with SMTP id h19so376867pfd.12 for ; Thu, 08 Mar 2018 12:40:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:reply-to:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=FoWwDx3Q45JF2yRnn2JRn/8AZBBYhUkc2DZ9fT0CpbQ=; b=bR9n/aHKNIaI+5g6ZcP/8DZ2j2AWjr0ndUoqmpU+Dt8MQ0Q2InG/lxjdD3FlkBStst KbJSknshbGHrKMOq7n/4If41bxqP9Tgyx0YipkOqcvyJ4NkaR0r7ASrWpB8bu4OeXU/u /VlwMzRR2YUYN7Ukq+litIiYXaRDP5M0Lm+82g0gBwYZ1eVF+Qw+IBliyo1PavIvCgwo Aq3cbwbg27idr6keZcPkIGlal9BL+d9jMVp05fEt6V7ftkJVYPe/YIDNqWvdtGyxd7cF SN6CLxiSYRgT+ISk/Toy4JfkiJyVwVHtRvkitAQjRXRPbppLJc2k8sXECivs8bGH6GwG cW4Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:reply-to:subject:to:cc:references:from :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding:content-language; bh=FoWwDx3Q45JF2yRnn2JRn/8AZBBYhUkc2DZ9fT0CpbQ=; b=F+uQCKd7kl3yBljS75wwWuLV/auAno8ocrwSOa4kZ768v7xaO9O6gm3/t4zprrZiwy u7mGFdBmbTgmYghoT0EyZAdoPNn7im2M1aGttRSpyoc5nMT/cjwY6nExM6/9Y5wvCgau DLbLbzwR6nsh6JuUZ3r2gzgvvNGN/wDlc1MClkruBhpUeOT/irg69uP8/DV9aysk7ul2 otxSwGleF7T4maUcaImDITPqEHcwnjEZuLHBY6tRtkiYXae8Be9klFE82Wb6L52xI/J6 ZxbDhpvF9rDsi/SkWcweasl0vJ6gADuV6rFJksGpTIvmr6RJ5zwgn/ffYGwawbw/n8Wp /cJw== X-Gm-Message-State: APf1xPC8vyfTCeFVcmmxw4gVL1Cl48iP2Buee52Tz7VpUl7Oep4iGdfL GpJOQ6e5D4e9oyCy+TlOyA== X-Received: by 10.99.186.73 with SMTP id l9mr21669919pgu.83.1520541658246; Thu, 08 Mar 2018 12:40:58 -0800 (PST) Received: from serve.minyard.net (serve.minyard.net. [2001:470:b8f6:1b::1]) by smtp.gmail.com with ESMTPSA id f82sm48473236pfd.175.2018.03.08.12.40.57 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 08 Mar 2018 12:40:57 -0800 (PST) Received: from [192.168.27.3] (t430m.minyard.net [192.168.27.3]) by serve.minyard.net (Postfix) with ESMTPSA id A53D8159; Thu, 8 Mar 2018 14:40:55 -0600 (CST) Reply-To: minyard@acm.org Subject: Re: [PATCH] ipmi:ssif: Fix double probe from tryacpi and trydmi To: Jiandi An , arnd@arndb.de, gregkh@linuxfoundation.org Cc: openipmi-developer@lists.sourceforge.net, linux-kernel@vger.kernel.org References: <1520401742-29371-1-git-send-email-anjiandi@codeaurora.org> <1bc40690-c46f-e7fd-1beb-37e362cd8146@codeaurora.org> <7814a839-a718-7437-3f69-8b4f090ccbcf@acm.org> From: Corey Minyard Message-ID: Date: Thu, 8 Mar 2018 14:40:51 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-GB Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 03/08/2018 12:18 PM, Jiandi An wrote: > > > On 03/08/2018 08:10 AM, Corey Minyard wrote: >> On 03/07/2018 05:59 PM, Jiandi An wrote: >>> >>> >>> On 03/07/2018 07:34 AM, Corey Minyard wrote: >>>> On 03/06/2018 11:49 PM, Jiandi An wrote: >>>>> IPMI SSIF driver's parameter tryacpi and trydmi both >>>>> are set to true.  The addition of IPMI DMI driver to >>>>> create platform device for each IPMI device causes >>>>> SSIF probe to be done twice on the same SMB I2C address >>>>> for BMC.  Fix is to not call trydmi if tryacpi is able >>>>> to find I2C address for BMC from SPMI ACPI table and >>>>> probe successfully. >>>> >>>> Why are you trying to do this?  Is something bad happening? >>>> >>>> SPMI is not the preferred mechanism for detecting a device, >>>> the preferred mechanism should be the acpi match table or >>>> OF, followed by DMI, followed by SPMI.  In fact, it might be >>>> best to just remove SPMI. >>>> >>>> -corey >>> >>> >>> On our ARM64 platform, SSIF is the IPMI interface for host to >>> BMC communication and it is described in ACPI SPMI table including >>> the I2C address.  The driver would get the SSIF device from >>> IPI0001 ssif_acpi_match[] and probe.  It worked fine with no issues. >>> >>> Then it was reported dmidecode does not show the correct SSIF >>> device information including correct I2C address.  So SSIF device >>> description is also added in SMBIOS table.  It worked fine with no >>> issues until this patch. >>> >>> 0944d88 ipmi: Convert DMI handling over to a platform device >>> >>> We would see error message indicating trydmi via >>> platform_driver_register fails with -EEXIST during boot. >>> >>> [    9.385758] ipmi_ssif: probe of dmi-ipmi-ssif.0 failed with error >>> -17 >>> >>> This is because tryacpi ran first and successfully completed >>> new_ssif_client() (which adds address to ssif_info) and eventually >>> ssif_probe() >>> >>> ssif_tryacpi >>>     spmi_find_bmc() >>>         try_init_spmi() >>>             new_ssif_client() >>> >>> Since both tryacpi and trydmi are set to true as module parameter >>> with no permission and not exposed to /sys/module/ipmi_ssif/parameters, >>> it triggers the following path down to dmi_ipmi_probe() and >>> new_ssif_client() which fails ssif_info_find() finds the address >>> added to ssif_info already in the ssif_tryacpi path. >>> >>> ssif_trydmi >>>     platform_driver_register(&ipmi_driver) >>>         __platform_driver_register() >>>             driver_register() >>>                 bus_add_driver() >>>                     driver_attach() >>>                         bus_for_each_dev() >>>                             __driver_attach() >>>                                 driver_probe_device() >>>                                     ssif_platform_probe() >>>                                         dmi_ipmi_probe() >>>                                             new_ssif_client() >>> >>> Are you suggesting to not do tryacpi at all and just rely on >>> trydmi? >> >> Basically, yes.  SPMI is really designed for early detection of >> interfaces >> before ACPI proper comes up.  You should have the IPMI device in your >> ACPI tree. > > You meant to say I should have the IPMI SSIF device in my SMBIOS table? > Or do you mean to say I should have the IPMI SSIF device in my ACPI SPMI > table but you will remove SPMI support from the IPMI driver? I mean that you should have the IPMI SSIF device in your ACPI namespace (see section C3-2 in the IPMI spec) and that should be the preferred method for locating the system interfaces.  If it doesn't get detected by that interface, then any ACPI methods that require IPMI will not work. SMBIOS detection should be secondary.  SPMI really shouldn't be used. This is something I have been meaning to work on for a while, let me work on this a bit and I'll send you some patches. -corey > > Do you want me to remove the ssif_tryacpi logic and tryacpi module > parameter all together in that patch? > > Thanks > -Jiandi > >> >> My inclination is to remove SPMI support from the IPMI driver. >> >> -corey >> >> >>> I was looking at the following patch to understand more about >>> the added ipmi_dmi driver. >>> >>> 9f88145 ipmi: Create a platform device for a DMI-specified IPMI >>> interface >>> >>> It's creating a platform device for each IPMI device in the DMI >>> table including SSIF device, for auto-loading IPMI devices from >>> SMBIOS tables. >>> >>> Are you suggesting removing SSIF device description from ACPI >>> SPMI table and remove ssif_tryacpi logic all together? >>> >>> But the commit description mentions ... >>> >>> "This also adds the ability to extract the slave address from >>> the SMBIOS tables, so that when the driver uses ACPI-specified >>> interfaces, it can still extract the slave address from SMBIOS." >>> >>> This made me think SSIF driver can still use ACPI-specified >>> interface.  It made me think it implies SSIF device can be >>> described in ACPI SPMI table and SMBIOS table.  Both spec >>> did not say they cannot. >>> >>> What's your recommended way of fixing this double probing? >>> >>> Thanks >>> >>> >>>> >>>>> Signed-off-by: Jiandi An >>>>> --- >>>>>   drivers/char/ipmi/ipmi_ssif.c | 35 >>>>> ++++++++++++++++++++++++----------- >>>>>   1 file changed, 24 insertions(+), 11 deletions(-) >>>>> >>>>> diff --git a/drivers/char/ipmi/ipmi_ssif.c >>>>> b/drivers/char/ipmi/ipmi_ssif.c >>>>> index 9d3b0fa..5c57363 100644 >>>>> --- a/drivers/char/ipmi/ipmi_ssif.c >>>>> +++ b/drivers/char/ipmi/ipmi_ssif.c >>>>> @@ -1981,29 +1981,41 @@ static int try_init_spmi(struct SPMITable >>>>> *spmi) >>>>>       return new_ssif_client(myaddr, NULL, 0, 0, SI_SPMI, NULL); >>>>>   } >>>>> -static void spmi_find_bmc(void) >>>>> +static int spmi_find_bmc(void) >>>>>   { >>>>>       acpi_status      status; >>>>>       struct SPMITable *spmi; >>>>>       int              i; >>>>> +    int              rc = 0; >>>>>       if (acpi_disabled) >>>>> -        return; >>>>> +        return -EPERM; >>>>>       if (acpi_failure) >>>>> -        return; >>>>> +        return -ENODEV; >>>>>       for (i = 0; ; i++) { >>>>>           status = acpi_get_table(ACPI_SIG_SPMI, i+1, >>>>>                       (struct acpi_table_header **)&spmi); >>>>> -        if (status != AE_OK) >>>>> -            return; >>>>> +        if (status != AE_OK) { >>>>> +            if (i == 0) >>>>> +                return -ENODEV; >>>>> +            else >>>>> +                return 0; >>>>> +        } >>>>> -        try_init_spmi(spmi); >>>>> +        rc = try_init_spmi(spmi); >>>>> +        if (rc) >>>>> +            return rc; >>>>>       } >>>>> + >>>>> +    return 0; >>>>>   } >>>>>   #else >>>>> -static void spmi_find_bmc(void) { } >>>>> +static int spmi_find_bmc(void) >>>>> +{ >>>>> +    return -ENODEV; >>>>> +} >>>>>   #endif >>>>>   #ifdef CONFIG_DMI >>>>> @@ -2104,12 +2116,13 @@ static int init_ipmi_ssif(void) >>>>>                      addr[i]); >>>>>       } >>>>> -    if (ssif_tryacpi) >>>>> +    if (ssif_tryacpi) { >>>>>           ssif_i2c_driver.driver.acpi_match_table    = >>>>>               ACPI_PTR(ssif_acpi_match); >>>>> - >>>>> -    if (ssif_tryacpi) >>>>> -        spmi_find_bmc(); >>>>> +        rv = spmi_find_bmc(); >>>>> +        if (!rv) >>>>> +            ssif_trydmi = false; >>>>> +    } >>>>>       if (ssif_trydmi) { >>>>>           rv = platform_driver_register(&ipmi_driver); >>>> >>>> >>> >> >