From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-10.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 1543FC43214 for ; Tue, 17 Aug 2021 20:52:25 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id E536A61042 for ; Tue, 17 Aug 2021 20:52:24 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232695AbhHQUw4 (ORCPT ); Tue, 17 Aug 2021 16:52:56 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:60356 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230433AbhHQUwz (ORCPT ); Tue, 17 Aug 2021 16:52:55 -0400 Received: from perceval.ideasonboard.com (perceval.ideasonboard.com [IPv6:2001:4b98:dc2:55:216:3eff:fef7:d647]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id B392BC061764; Tue, 17 Aug 2021 13:52:21 -0700 (PDT) Received: from pendragon.ideasonboard.com (62-78-145-57.bb.dnainternet.fi [62.78.145.57]) by perceval.ideasonboard.com (Postfix) with ESMTPSA id EFF7B2C5; Tue, 17 Aug 2021 22:52:17 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ideasonboard.com; s=mail; t=1629233538; bh=Mh6GvkHbI/y4ERR91za8dX6bujaEyUKIBWREoUqz32k=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=bBmkbg51g/KHyHz2nXr7zLqTXjvE8kAhWswpMeJgm+7mRhHBuIEvmYBsSuI4nVDaB Xze+sjGWtyuILHxnE6OjIYhXtk5IY9mSqdbRu/CrAUqIftCd7R9hSnZ01C14JcdC91 Nr1EPmveULP5QjEy0AAuPb3n5dWcL8Qn+aGbwaLs= Date: Tue, 17 Aug 2021 23:52:10 +0300 From: Laurent Pinchart To: Wolfram Sang Cc: Jonathan Cameron , linux-iio@vger.kernel.org, Lars-Peter Clausen , Rob Herring , Sean Nyekjaer , devicetree@vger.kernel.org, Jose Cazarin , linux-i2c@vger.kernel.org Subject: Re: [PATCH v1.1 2/2] iio: dac: dac5571: Fix chip id detection for OF devices Message-ID: References: <20210723183114.26017-3-laurent.pinchart@ideasonboard.com> <20210724000654.23168-1-laurent.pinchart@ideasonboard.com> <20210724154308.55afb03c@jic23-huawei> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-i2c@vger.kernel.org Hi Wolfram, On Tue, Aug 17, 2021 at 10:44:20PM +0200, Wolfram Sang wrote: > > > > When matching an OF device, the match mechanism tries all components of > > > the compatible property. This can result with a device matched with a > > > compatible string that isn't the first in the compatible list. For > > > instance, with a compatible property set to > > > > > > compatible = "ti,dac081c081", "ti,dac5571"; > > > > > > the driver will match the second compatible string, as the first one > > > isn't listed in the of_device_id table. The device will however be named > > > "dac081c081" by the I2C core. > > > > > > This causes an issue when identifying the chip. The probe function > > > receives a i2c_device_id that comes from the module's I2C device ID > > > table. There is no entry in that table for "dac081c081", which results > > > in a NULL pointer passed to the probe function. > > > > > > To fix this, add chip_id information in the data field of the OF device > > > ID table, and retrieve it with of_device_get_match_data() for OF > > > devices. > > > > > > Signed-off-by: Jose Cazarin > > > Reviewed-by: Laurent Pinchart > > > Signed-off-by: Laurent Pinchart > > > > Interesting problem that I hadn't previously realised could happen. > > > > One request though, can we use device_get_match_data() here rather than > > the of specific version? Include property.h as well for that. > > > > That should allow the same issue with compatible to work correctly when > > using PRP0001 based ACPI methods. > > https://elixir.bootlin.com/linux/v5.14-rc1/source/drivers/acpi/bus.c#L891 > > Will result in acpi_of_device_get_match_data() being called which will > > match to the of_device_id table. > > Couldn't you use the "new" probe_new() callback instead which will drop > the i2c_device_id? Kieran was interested in such conversions IIRC. It's a bit unrelated to this patch, but I can add another patch to the series. While I have your attention, there's a question for you in the cover letter :-) Could you please have a look ? -- Regards, Laurent Pinchart