Received: by 2002:ac0:a581:0:0:0:0:0 with SMTP id m1-v6csp3591299imm; Mon, 2 Jul 2018 01:46:58 -0700 (PDT) X-Google-Smtp-Source: ADUXVKLpniA+VEYFyysqgi8x9zsizckjWJBj7tANXFMC0ctN9xTqw+4fq6V1DOsFvGaMg8DpdcSa X-Received: by 2002:a17:902:7891:: with SMTP id q17-v6mr25323039pll.186.1530521218064; Mon, 02 Jul 2018 01:46:58 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1530521218; cv=none; d=google.com; s=arc-20160816; b=X+GEjfh/Nv2hB4ATNxzORUMwm0v8x/raxdXkqTYVkED7qgc6xHieSX/DKidxaMctOw TKVelsuDG7rRJErvIFYBhduX1yeGeVLLmUz5KXcjXmYuHOp1UpcEqNv1P59kEe8njRm2 DtilTf6ZLFiIA88fjgo96SdqNz9eHFw9UbyoV0aF7sGuXHixqCnMFQiTjStKtSqmcpVW LzlBtj4ETUEriAhiWLCNX22N3NbAmV+6xlu3oW9tG3QfjTg2YlHCqQCXmlpUIkCPqiHp uJDRyLR9ol42u8PUc8FohbtmfptRt0L+ajo7SUsOMtG/eqe3jCp1zFnl8L33ugO6bs9T 8Ntw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:user-agent:references :message-id:in-reply-to:subject:cc:to:from:date :arc-authentication-results; bh=peLwCpBvmRcFdALzu0+akJVCaAGBb+2vlnubq1jIU+o=; b=Wi6Q5gUtdnnnOVb94DS86QG+dEG2M+Yt4yBD/S7anif+me303mRYFFLxu5SoqOTOvM +CFZJ2M502vTEAF6RjVXFneEYKFsHXLugQEONvCvNXszhKEam/TpthuXHjNJCnDhFU5i 10mjccBBneVWeXv05C/Yl32Gq6S8SHwuvhZmnKoKTdltPSq/zkXEi/iYHjG+5ifZRotq gIOFt0yWxD0JAN9sBRVQXatY0h5GP7pZTS9MqxHW77thLvCIuAhCfwlsq3OCzWG6ewiL NtOV5zWrjjJYnBqScV8BFtjil8JoavmIy+kwyFdVxnToaTalN7zWKzDfKJ6QJ7DXy8Cu 2Osg== ARC-Authentication-Results: i=1; mx.google.com; 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 i9-v6si13660816pgp.568.2018.07.02.01.46.43; Mon, 02 Jul 2018 01:46:58 -0700 (PDT) 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; 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 S932396AbeGBGxG (ORCPT + 99 others); Mon, 2 Jul 2018 02:53:06 -0400 Received: from mail.steuer-voss.de ([85.183.69.95]:38288 "EHLO mail.steuer-voss.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753339AbeGBGxF (ORCPT ); Mon, 2 Jul 2018 02:53:05 -0400 X-Virus-Scanned: Debian amavisd-new at mail.steuer-voss.de Received: by mail.steuer-voss.de (Postfix, from userid 1000) id 9496E41BAC; Mon, 2 Jul 2018 08:53:00 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by mail.steuer-voss.de (Postfix) with ESMTP id 8C5CC40B88; Mon, 2 Jul 2018 08:53:00 +0200 (CEST) Date: Mon, 2 Jul 2018 08:53:00 +0200 (CEST) From: Nikolaus Voss X-X-Sender: nv@fox.voss.local To: Jonathan Cameron cc: "Voss, Dr. Nikolaus" , Hartmut Knaack , Lars-Peter Clausen , Peter Meerwald-Stadler , Lorenzo Bianconi , Linus Walleij , Xiongfeng Wang , "linux-iio@vger.kernel.org" , "linux-kernel@vger.kernel.org" Subject: Re: [PATCH 1/3] IIO: st_accel_i2c.c: Use fallback if DT/ACPI enum failed In-Reply-To: <20180630162803.3a2ad759@archlinux> Message-ID: References: <20180630162803.3a2ad759@archlinux> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sat, 30 Jun 2018, Jonathan Cameron wrote: > On Fri, 29 Jun 2018 10:10:10 +0200 > Nikolaus Voss wrote: > >> Currently, the driver bails out if not explicitly referred to in >> DT or ACPI tables. This prevents fallback mechanisms from coming >> into effect, e.g. I2C device ID table match via DT or ACPI >> PRP0001 HID. However DT/ACPI enum should take precedence over >> the fallback, so evaluate that first. >> >> Signed-off-by: Nikolaus Voss > > Is the change to probe_new actually related to the rest of the change? > > I can't immediately see why... If not I would prefer that as a separate > change. Well, it is, because the id table pointer of the old probe() is not used any more. > >> --- >> drivers/iio/accel/st_accel_i2c.c | 21 ++++++++++++--------- >> 1 file changed, 12 insertions(+), 9 deletions(-) >> >> diff --git a/drivers/iio/accel/st_accel_i2c.c b/drivers/iio/accel/st_accel_i2c.c >> index 6bdec8c451e0..e360da407027 100644 >> --- a/drivers/iio/accel/st_accel_i2c.c >> +++ b/drivers/iio/accel/st_accel_i2c.c >> @@ -138,8 +138,7 @@ static const struct i2c_device_id st_accel_id_table[] = { >> }; >> MODULE_DEVICE_TABLE(i2c, st_accel_id_table); >> >> -static int st_accel_i2c_probe(struct i2c_client *client, >> - const struct i2c_device_id *id) >> +static int st_accel_i2c_probe(struct i2c_client *client) >> { >> struct iio_dev *indio_dev; >> struct st_sensor_data *adata; >> @@ -156,14 +155,18 @@ static int st_accel_i2c_probe(struct i2c_client *client, >> client->name, sizeof(client->name)); >> } else if (ACPI_HANDLE(&client->dev)) { >> ret = st_sensors_match_acpi_device(&client->dev); >> - if ((ret < 0) || (ret >= ST_ACCEL_MAX)) >> - return -ENODEV; >> - >> - strlcpy(client->name, st_accel_id_table[ret].name, >> + if ((ret >= 0) && (ret < ST_ACCEL_MAX)) >> + strlcpy(client->name, st_accel_id_table[ret].name, >> sizeof(client->name)); >> - } else if (!id) >> - return -ENODEV; >> + } >> >> + /* >> + * If OF and ACPI enumeration failed, there could still be platform >> + * information via fallback enumeration or explicit instantiation, so >> + * check if id table has been matched via client->name. >> + */ >> + if (!client->name) >> + return -ENODEV; >> >> st_sensors_i2c_configure(indio_dev, client, adata); >> >> @@ -187,7 +190,7 @@ static struct i2c_driver st_accel_driver = { >> .of_match_table = of_match_ptr(st_accel_of_match), >> .acpi_match_table = ACPI_PTR(st_accel_acpi_match), >> }, >> - .probe = st_accel_i2c_probe, >> + .probe_new = st_accel_i2c_probe, >> .remove = st_accel_i2c_remove, >> .id_table = st_accel_id_table, >> }; > >